What are you proposing? How should it be implemented?
I'm proposing to use ENV and ARG to make Dockerfiles dynamic and just have 1 compose file at project root for both local and production. One can pass in an env variable to docker-compose that can then be used to create all compose services, networks, and volume definitions adaptive while also using the same arg to build specific images as the case may be.
Eg
BUILD_ENV=production docker-compose up --build
Will go ahead and make production environment images and also use production environment env_files and bring up all production services.
While,
BUILD_ENV=dev docker-compose up --build
Will go ahead and make dev environment images and also use dev environment env_files and bring up all dev services.
This will make the project structure much more simple and really cut down the number of files to be managed and will make everything dynamic and flexible.
Rationale
Why should this feature be implemented?
This would make the docker aspect of this template much more understandable and much easier to use and modify. It will also make it a lot more dynamic as well. Currently, there are a lot of files that need to be understood and for most files the only difference between production and development environments are using the correct env_file and/or the env specific image.
Please let me know if there is any interest in this because I can implement and raise a PR for the same.
Description
What are you proposing? How should it be implemented?
I'm proposing to use
ENV
andARG
to make Dockerfiles dynamic and just have 1 compose file at project root for both local and production. One can pass in an env variable to docker-compose that can then be used to create all compose services, networks, and volume definitions adaptive while also using the same arg to build specific images as the case may be.Eg
BUILD_ENV=production docker-compose up --build
Will go ahead and make production environment images and also use production environment env_files and bring up all production services.While,
BUILD_ENV=dev docker-compose up --build
Will go ahead and make dev environment images and also use dev environment env_files and bring up all dev services.This will make the project structure much more simple and really cut down the number of files to be managed and will make everything dynamic and flexible.
Rationale
Why should this feature be implemented?
This would make the docker aspect of this template much more understandable and much easier to use and modify. It will also make it a lot more dynamic as well. Currently, there are a lot of files that need to be understood and for most files the only difference between
production
anddevelopment
environments are using the correct env_file and/or the env specific image.Please let me know if there is any interest in this because I can implement and raise a PR for the same.
Example, django service would go
from:
to
And the new Django Dockerfile would now use the
BUILD_ENVIRONMENT
ARG and install the appropriaterequirements
file.