global/default ".env" file is a great feature, allowing to set defaults for env variables without hardcoding reference to it inside each and every service definition using env_file
, or having to wrap docker-compose in script to accomplish this.
However it does not seem to take folder of docker-compose.yml
file into account, as implied by the doc:
Compose supports declaring default environment variables in an environment file named .env, _and placed in the same folder as your compose file_.
Example:
docker-compose --verbose -f bin/.docker/docker-compose.yml up -d --no-recreate
compose.config.config.find: Using configuration files: ./bin/.docker/docker-compose.yml
WARNING: compose.config.environment.__getitem__: The DATABASE_USER variable is not set. Defaulting to a blank string.
WARNING: compose.config.environment.__getitem__: The DATABASE_PASSWORD variable is not set. Defaulting to a blank string.
WARNING: compose.config.environment.__getitem__: The DATABASE_NAME variable is not set. Defaulting to a blank string.
docker.auth.auth.load_config: File doesn't exist
compose.cli.command.get_client: docker-compose version 1.7.0, build 0d7bf73
Maybe it should look for it in following order _(all before loading any docker-compose.yml files)_:
pwd
_(execution folder)_This would allow dev envimrnets to override prod env in example below with .env
file in dev/
folder:
export COMPOSE_FILE="docker-compose.yml:dev/docker-compose.yml"
docker-compose up -d --no-recreate
Discussions with @dnephin on IRC revealed that this is most likely a doc issue, as it also allows setting COMPOSE_FILE
implying it by design can only be taken from current working directory.
.env
fileTrue, I was about to suggest a flag to override which env to use, but this would solve it as well.
In my opinion, changing the documentation does nit fix this issue. If you are combining multiple containers with the -f
option, there is no way to use their local .env files.
Beside that, the documentation at https://docs.docker.com/compose/compose-file/ still promotes a different (and in my opinion more useful) behavior.
In my opinion, compose should just always check for a .env in the directory where the .yml is located or give the ability within the compose yml itself to point to an env file anywhere.
As answered in #5481, the reason it works like this is because the .env
file also allows to define the COMPOSE_FILE
variable, which obviously needs to be read before we can evaluate where the Compose file is located.
Most helpful comment
In my opinion, changing the documentation does nit fix this issue. If you are combining multiple containers with the
-f
option, there is no way to use their local .env files.Beside that, the documentation at https://docs.docker.com/compose/compose-file/ still promotes a different (and in my opinion more useful) behavior.