Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split docker-compose.yml and env-example into smaller files #1053

Closed
vwchu opened this issue Jul 9, 2017 · 2 comments
Closed

Split docker-compose.yml and env-example into smaller files #1053

vwchu opened this issue Jul 9, 2017 · 2 comments

Comments

@vwchu
Copy link

vwchu commented Jul 9, 2017

Currently, the docker-compose.yml is one large file for all the containers defined and the env-example is one large file that contains all the environment variables. As the number of images and containers continues to increase this becomes more and more difficult manage, maintain and extend easily.

Originally, I tried to reorder the sections in the env-example based on the ordering in the docker-compose.yml, but I thought they still will be two very large files. So, why not split the docker-compose.yml into smaller files, one for each image, and split the env-example similarly, one for each docker-compose.yml, approximately.

The docker-compose.yml files can be composed together using the -f option in the docker-compose command and the env-example files can concatenated together via a shell script or the laradock/cli.

This way it is more modular and we can add new images by adding a docker-compose.yml and .env.example and registering the module in the shell script.

scripts/laradock.sh environvars:template --output .env
docker-compose $(scripts/laradock.sh dockercompose:args) up

Other benefits:

I can choose which modules to include when generating my .env and composing my docker-compose.yml, keeping my .env relatively small with only the modules I need. For instance:

MODULES=workspace nginx php-fpm mysql
scripts/laradock.sh environvars:template --output .env ${MODULES}
docker-compose $(scripts/laradock.sh dockercompose:args ${MODULES}) up ${MODULES}

I can write an .env.example with only the variables that I want to modify and override the default
variables in the modules that I chose to include. For example:

../.env.example:

APPLICATION=../../
DATA_SAVE_PATH=../.data
MODULES=workspace nginx php-fpm mysql
TEMPLATE=$(scripts/laradock.sh environvars:template ${MODULES})
echo "$TEMPLATE" | scripts/laradock.sh environvars:evaluate --output ../.env --template /dev/stdin ../.env.example
docker-compose $(scripts/laradock.sh dockercompose:args ${MODULES}) up ${MODULES}

Currently, it is a work in progress, here: https://github.com/vwchu/laradock/tree/feat-split-configs

Any thoughts?

@a-h-abid
Copy link

While I'm on board with splitting up docker-compose file, I'm not OK with env file being separated. It may become big, I don't want to go around all folder and update env file. It will become frustrating when setting up on a server environment. Also I think any new developer or beginner coming to laradock will see this as a hassle.

@vwchu
Copy link
Author

vwchu commented Jul 16, 2017

@a-h-abid Thanks for the feedback. I think splitting up the docker-compose file and the env file will actually make the project much more maintainable and scalable. It will make it possible to plugin new images with no changing to the docker-compose and env file that affects other images.

In terms of user experience, it should be all that different from it is now. With the additional of a CLI, editing project specific environment variables shouldn't be different from editing the env file currently. The CLI will handle the merging and combining of the env files behind the scene. The user is abstracted away from that and doesn't need to know how that happens. But also we get benefits such as only including containers, images and variables that we need for our specific projects, automatic dependency management for which docker-compose and env files to be included, etc.

Unfortunately, I have to admit that my implementation of the CLI is kind of clumsy and not very elegant or easy to use. I need a more user-friendly interface.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants