Support for --env-file option for docker-compose

[slowr]

Added additional argument (--env-file) for docker-compose to import environment variables from a given file.

Resolves #6170

[chris-crone]

LGTM! Thanks @slowr!

[ulyssessouza]

LGTM

[xeor]

As noticed in #6170 (comment), this PR doesn't allow for multiple environment-files to be loaded at the same time.. Will that be added to a future PR, or was it forgotten about, or not in scope?

Sorry for adding this comment too late. But I'm curious if there are plans for adding multi-env support..

[ulyssessouza]

This was considered out of scope for now but we can investigate it.
And as always... PRs are welcome 😺

[omniproc]

Uhm, didn't this make it into 1.24.0? It was commited nearly 2 months ago but I can't find it in the commits for rc1 or rc3 of 1.24.0 and rc2 is missing in the release history.

[ulyssessouza]

@M451 You are right. The reason is that the focus of 1.24.0 was around stability in some aspects.
This feature will be present when we release a version based on master.

[Maher4Ever]

@ulyssessouza Will this feature be added to the next release?

[GammaGames]

It's been a while since the last comment, but I have 1.25.0-rc2, build 661ac20e installed and I still don't see this feature anywhere. Is it going to be in 1.25?

[jakedouglas]

@GammaGames it took me a while to figure out, but it looks like it actually is there. It just doesn't appear in the help output for subcommands, e.g. docker-compose help up. docker-compose help does show it though, and it appears to work for me.

[entrptaher]

Does not work for me on latest version. :(

--env-file does not read the .env file at all. The env_file: inside the compose file works. But that's a pain if I have 10+ services in a single docker-compose.yml file

[omniproc]

Strange. It works for me. What version does your docker-compose report?

[jcorry]

This is the ridiculous sort of thing we have to do to compensate for this not being here:

# Makefile
start_local:
	cp ./local.env ./.env
	docker-compose up

start_test:
	cp ./test.env ./.env
	docker-compose up

[entrptaher]

Strange. It works for me. What version does your docker-compose report?

➜ ~ docker-compose --version
docker-compose version 1.25.0-rc2, build 661ac20

This worked for me,

ENV_FILE=.env.production.local docker-compose -f docker-compose.prod.yml up --build

These did not work

• docker-compose up --env-file=
• docker-compose --env-file=.env up
• env $(cat .env) docker-compose up
• BAR=foo docker-compose up
• changing/upgrading docker compose (few other version upto 1.25)
• setting the compose version to 3, 3.4, 3.7 etc.

did not work!

[omniproc]

@entrptaher I don't have it in front of me right now but I think if you look at the source it's a global parameter to docker-compose, so as far as I remember I had to use docker-compose --env-file=foo up. See #6800

[entrptaher]

Yes, that's what I said above, docker-compose up --env-file=foo did not work. See the These did not work points listed on my comment. :)

[omniproc]

@entrptaher docker-compose up --env-file=foo is not the same as docker-compose --env-file=foo up

[entrptaher]

@M451, sure, here you go.

I tested with every combination available on the issue section of this repo.

[omniproc]

actually, it's docker-compose --env-file foo.env up without the = char. Works for me on docker-compose version 1.25.0-rc2, build 661ac20e.

[entrptaher]

Okay, let's try that as well,

Again,

And,

➜ docker-test docker-compose --env-file .env up --build --force-recreate
Recreating docker-test_api_1 ... done
Attaching to docker-test_api_1
api_1  | { PATH: '/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin',
api_1  |   HOSTNAME: '1ea458106f5a',
api_1  |   NODE_VERSION: '6.17.1',
api_1  |   YARN_VERSION: '1.15.2',
api_1  |   HOME: '/root' }
docker-test_api_1 exited with code 0

Tried different node versions and yml file version,

No success for me.

[tiany]

--env-file in the command line is not working as the env_file in the docker-compose.yml.
--env-file will pass the environment variables to the docker-composer but not the container, you can refer to the environment variables in your docker-compose.yml file.

refer to this and this.

[plueschpruem]

I hope this is the right place to ask this…
I am building a workflow to use a single docker-compose.yml to manage several similar projects.
I want to solve that with several .env files to use with the --env-file shell option:
docker-compose --env-file ./Docker_Config/env_files/test1.env -f ./Docker_Config/docker-compose.yml --project-name test1 up -d --build
Inside the test1.env is this:
DOCKER_NAME=test1

File structure:
root
— Docker_Config
—— env_files
——— test1.env
—— docker-compose.yml

This works as expected, the app builds, starts, all containers are correctly named via the variabel – so far so dandy.
But when I try to stop the app (with the STOP button in Docker Desktop / Apps), I get an error that Docker Desktop could not find the test1.env file.
It seems that Docker is always prepending the full folder of the docker-compose.yml to the .env.
So in my case it tries to open the file at […]Docker_Config/Docker_Config/env_files/test1.env
To confirm I also moved my .yml a level further into another folder – that then also got prepended.
So basically the ONLY possibility to use this new (and frankly very useful) option is to keep all your docker-compose.yml and .env files in the root level. But I guess this is an error, not the desired functionality?

Additionally the app console echos some of these on startup:
time="2022-03-12T19:19:25+01:00" level=warning msg="The \"DOCKER_NAME\" variable is not set. Defaulting to a blank string."
Guess that could be connected? Because I only used that var in the docker-config.yml, not in the app itself. It is never passed to the containers and all the functionality the var does provide to the docker-config.yml is working as expectd.

I am on the latest OSX, with Docker Desktop 4.5.0 (74594) / Docker version 20.10.12, build e91ed57 | Docker Compose version v2.2.3

[entrptaher]

I hope this is the right place to ask this… I am building a workflow to use a single docker-compose.yml to manage several similar projects. I want to solve that with several .env files to use with the --env-file shell option: docker-compose --env-file ./Docker_Config/env_files/test1.env -f ./Docker_Config/docker-compose.yml --project-name test1 up -d --build Inside the test1.env is this: DOCKER_NAME=test1

File structure: root — Docker_Config —— env_files ——— test1.env —— docker-compose.yml

This works as expected, the app builds, starts, all containers are correctly named via the variabel – so far so dandy. But when I try to stop the app (with the STOP button in Docker Desktop / Apps), I get an error that Docker Desktop could not find the test1.env file. It seems that Docker is always prepending the full folder of the docker-compose.yml to the .env. So in my case it tries to open the file at […]Docker_Config/Docker_Config/env_files/test1.env To confirm I also moved my .yml a level further into another folder – that then also got prepended. So basically the ONLY possibility to use this new (and frankly very useful) option is to keep all your docker-compose.yml and .env files in the root level. But I guess this is an error, not the desired functionality?

Additionally the app console echos some of these on startup: time="2022-03-12T19:19:25+01:00" level=warning msg="The \"DOCKER_NAME\" variable is not set. Defaulting to a blank string." Guess that could be connected? Because I only used that var in the docker-config.yml, not in the app itself. It is never passed to the containers and all the functionality the var does provide to the docker-config.yml is working as expectd.

I am on the latest OSX, with Docker Desktop 4.5.0 (74594) / Docker version 20.10.12, build e91ed57 | Docker Compose version v2.2.3

Can you try this one?

alias project="docker-compose --env-file ./Docker_Config/env_files/test1.env -f ./Docker_Config/docker-compose.yml --project-name"

project test1 up --build -d
project test1 down

Basically pass all arguments every time.

[plueschpruem]

Gives the same error in the Desktop App when I use stop instead of (delete) down (deleting does still work in the GUI, failed to mention it).
The shell command project test1 down works – it lists all containers and takes them down one by one.

So I guess the error lies in the way the desktop app looks for the file maybe?

This is the error I get

[XDavidT]

Is there any option to use more than one --env-file flag and let docker compose merge it?