Compose environments
A "compose environment" is an all-in-one (development) environment to get you started quickly and without worries.
It uses a window manager (like tmux, screen or byobu) to create a seperate "environment", for each project. It also adds some helper script to your $PATH, so they can be accessed anywhere in your environment.
We currently have the following working compose environments:
Getting started
You'll need the latest versions of docker and docker-compose.
When using Ubuntu (17.04 and up) you can use this Github gist.
To be able to connect to the docker containers, you need a way to resolve dns to the nginx container. This can be done in a number of ways, but we prefer the use of the docker-developer-dns, provided by BlackIkeEagle.
Docker developer dns
See the documentation on Github https://github.com/BlackIkeEagle/docker-developer-dns on how to install this.
If you used the Github gist, the docker-developer-dns is already installed.
Mac OS X
For this environment to work properly you should install gnu coreutils
using homebrew:
$ brew install coreutils
On macOS you could just install docker from the docker site and run like this. But our experience is that the native docker install is fairly slow to use. We would suggest you to install dinghy.
Install Dinghy and install the VM technology you want to use. If you want native xhyve support you can additionally install xhyve driver for docker machine
Goal
Docker-compose
When using a framework (symfony, laravel,...) or a product (Magento, Pimcore,...) on docker in development, you need a combination of different docker images working together.
Our compose environments are a collection of docker images, needed to run the framework/product, using docker-compose.
Helpers
We also provide helper scripts, to run common tasks like php cli, composer, node, mysql,...
To give you access to those helper scripts in a native way, we have created the "dockerwest compose environments". These will start a window manager (tmux, screen, byobu,...) of your choise, with a modified $PATH variable. Allowing you to use the helper scripts as native commands. (eg. "php" will point to the bin/php script in your compose folder).
The great thing about this is, you don't need to worry about installing different pieces of software (like php, composer, node,...) onto your local machine. Everything you need to run the framework/product is already provided, in docker. These helper scripts just make it easy to access them.
Tips and known issues
Tmux starts the shells as loginshells, that means that for example bash is going to load the `profile` files. This sort of behaviour triggers the path_helper that will move our added PATH to the end. This is not the behaviour we want.
To fix this you can change the if for the path helper in your `/etc/profile` to the following:
if [ -z $TMUX ] && [ -x /usr/libexec/path_helper ]; then eval `/usr/libexec/path_helper -s` fi
Oh-my-zsh users should check if there is no fixed setting
for $PATH in their ~/.zshrc. If that is the case you can safely comment it
out. If somewhere in your shell startup $PATH is forced you lose the features
the ./environment script brings to you.