To be productive, developers require local development environments which mirror their dev / staging / production counterparts.
Below is an example workflow for developers when getting started.
The following local developer architecture is built to:
- Mimic production
- Enable Xdebug ONLY when required
- Decoupled Web/CLI architecture
- Frontend developers get their own image/toolchain
Config per OS
Not all "Docker for X" environments are equal eg.
- OSX has file performance issues and needs special configuration.
- Windows requires different slash for paths.
- Linux allows for us to run our services in the same network namespace as the host (eg. localhost)
To fix this we have setup a hierarchy to managing the differences for each OS.
To manage this we recommend you setup aliases
# Linux alias dc="docker-compose -f docker-compose.yml -f docker-compose.linux.yml" # OSX alias dc="docker-compose -f docker-compose.yml -f docker-compose.osx.yml" # OSX - Catalina alias dc="docker-compose -f docker-compose.yml -f docker-compose.osx.yml -f docker-compose.catalina.yml" # Helper commands. # NOTE: We will use these later in the document. alias dcu="dc up" alias dcr="dc run"
Command Line Containers
Skpr decouples the web and CLI containers to provide a smaller attack surface for environments (see shell for more info).
To mimic this locally we have setup "run" services which can be used with the
dcr alias from above.
Running a PHP command
dcr php-cli composer install
Running a NodeJS command
dcr frontend yarn install
Spinning up the environment
To spin up the environment run the following command:
The environment will be available via http://localhost:8080