We have a fairly similar setup and it works pretty good for local development when you add following several productivity/devUX tips. :)
Use local overrides: we heavily depend ondocker-compose.override.yml to allow all local overrides, port exposures and additional services (ie., phpMyAdmin, exposing db, etc.).
We provide docker-compose.override.yml.dist whose main purpose is to be a distribution file that can be c/p for local setup. Naturally, docker-compose.override.yml is git-ignored. :)
With this approach we allow developers to "flavor" their own local development: some devs use DataGrid to access db so they need exposed port, some use phpMyAdmin and access it through network, some like to query the db directly through the terminal; some want to mount volumes for everything they have, some refresh the whole project from fixtures every couple of days, etc.
Basically they can add whatever they want without risking an accidental addition to base setup when commiting their work. :) Huge disclaimer: we also use this same setup on production, so we need to extract port exposing and similar functionalities from base docker-compose.yml :)
Pre-build your base images: if you run full installation of additional dependencies for PHP, you risk having different .dll versions between your developers just because they built their project a couple of days apart (this can be even a couple of months if it is a longer project due to the fact that most of us rarely rebuild everything). If you don't have any additional extensions for language, great, then this approach is perfect. :)
But if you have, consider building these images and deploy them to either a private registry or docker.io (it's free so, why not :) ).
We have a hybrid approach: our base image is prebuilt, but we allow additional expansions of local development through the same approach as you have. For instance, xDebug is an optional extension that we have inside of our Dockerfile behind a "feature flag" (we have some projects that where we feel heavy impact its presence even though listeners are turned off).
Create a Makefile (or something similar) to automate these things: having a simple make up command will allow automation of this whole process. And it is directly in your project :D
If you want, you can also organise it as a questionnaire with default values so it can speed up project setup.
Check out Traefik (traefik.io/): it's great in combination with docker-compose.override.yml since you can basically setup custom local domains and avoid a lot of port exposing and have multiple project running in parallel (if that is something that you need). It's based around custom labels on Docker containers so you can pre-populate these at the beginning of your project and have actual local domains. Additional plus: if you ever need to allow CORS if you're providing your backend to frontend developers, it is one label away (which can also be turned on by default). :D
Of course, this works for us and isn't something that will definitely work for everyone, but there are some useful concepts that I think should be shared with the community. :)
Thanks a lot for your thorough comment and suggestions!
I think there's a lot I can exploit here right away:
point 4 - exactly what I am looking for at the moment, because of some issues and blockers I've encountered when locally integrating 3rd party social login providers where you need to register a domain on which requests will be redirected to, and localhost is not working
point 1 - I'm usually extracting a lot of variables into .env files and I admit it's starting to get annoying to build/run a container with --env-file=.env.local option each time. I have a (non-versioned) .env.local file with a ton of Docker-related stuff and I think I can gain a lot from this .override.yaml file.
Also, automating the build process and adding a script in form of a wizard is something that's accomplished in the later stages of the referenced tutorial, and also in Laravel Sail which is recently definitely a way to go with Laravel's local setup, so I might give it a go, too.
Once again, thank you, this will be extremely helpful!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great material and post!
We have a fairly similar setup and it works pretty good for local development when you add following several productivity/devUX tips. :)
Use local overrides: we heavily depend on
docker-compose.override.ymlto allow all local overrides, port exposures and additional services (ie., phpMyAdmin, exposing db, etc.).We provide
docker-compose.override.yml.distwhose main purpose is to be a distribution file that can be c/p for local setup. Naturally,docker-compose.override.ymlis git-ignored. :)With this approach we allow developers to "flavor" their own local development: some devs use DataGrid to access db so they need exposed port, some use phpMyAdmin and access it through network, some like to query the db directly through the terminal; some want to mount volumes for everything they have, some refresh the whole project from fixtures every couple of days, etc.
Basically they can add whatever they want without risking an accidental addition to base setup when commiting their work. :)
Huge disclaimer: we also use this same setup on production, so we need to extract port exposing and similar functionalities from base docker-compose.yml :)
Pre-build your base images: if you run full installation of additional dependencies for PHP, you risk having different .dll versions between your developers just because they built their project a couple of days apart (this can be even a couple of months if it is a longer project due to the fact that most of us rarely rebuild everything). If you don't have any additional extensions for language, great, then this approach is perfect. :)
But if you have, consider building these images and deploy them to either a private registry or docker.io (it's free so, why not :) ).
We have a hybrid approach: our base image is prebuilt, but we allow additional expansions of local development through the same approach as you have. For instance, xDebug is an optional extension that we have inside of our Dockerfile behind a "feature flag" (we have some projects that where we feel heavy impact its presence even though listeners are turned off).
Create a Makefile (or something similar) to automate these things: having a simple
make upcommand will allow automation of this whole process. And it is directly in your project :DIf you want, you can also organise it as a questionnaire with default values so it can speed up project setup.
Check out Traefik (traefik.io/): it's great in combination with
docker-compose.override.ymlsince you can basically setup custom local domains and avoid a lot of port exposing and have multiple project running in parallel (if that is something that you need). It's based around custom labels on Docker containers so you can pre-populate these at the beginning of your project and have actual local domains. Additional plus: if you ever need to allow CORS if you're providing your backend to frontend developers, it is one label away (which can also be turned on by default). :DOf course, this works for us and isn't something that will definitely work for everyone, but there are some useful concepts that I think should be shared with the community. :)
Thanks a lot for your thorough comment and suggestions!
I think there's a lot I can exploit here right away:
point 4 - exactly what I am looking for at the moment, because of some issues and blockers I've encountered when locally integrating 3rd party social login providers where you need to register a domain on which requests will be redirected to, and
localhostis not workingpoint 1 - I'm usually extracting a lot of variables into
.envfiles and I admit it's starting to get annoying to build/run a container with--env-file=.env.localoption each time. I have a (non-versioned).env.localfile with a ton of Docker-related stuff and I think I can gain a lot from this.override.yamlfile.Also, automating the build process and adding a script in form of a wizard is something that's accomplished in the later stages of the referenced tutorial, and also in Laravel Sail which is recently definitely a way to go with Laravel's local setup, so I might give it a go, too.
Once again, thank you, this will be extremely helpful!