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

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

Merged
merged 1 commit into from Feb 26, 2019
Merged

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

merged 1 commit into from Feb 26, 2019

Conversation

slowr
Copy link

@slowr slowr commented Feb 23, 2019

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

Resolves #6170

…nvironment variables from a given PATH.

Signed-off-by: Dimitrios Mavrommatis <jim.mavrommatis@gmail.com>
@chris-crone chris-crone requested a review from ulyssessouza Feb 26, 2019
Copy link
Member

@chris-crone chris-crone left a comment

LGTM! Thanks @slowr!

Copy link
Collaborator

@ulyssessouza ulyssessouza left a comment

LGTM

@ulyssessouza ulyssessouza merged commit b09d880 into docker:master Feb 26, 2019
2 checks passed
@Wirone Wirone mentioned this pull request Feb 26, 2019
@xeor
Copy link

@xeor xeor commented Mar 26, 2019

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
Copy link
Collaborator

@ulyssessouza ulyssessouza commented Mar 26, 2019

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

@omniproc
Copy link

@omniproc omniproc commented Apr 10, 2019

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
Copy link
Collaborator

@ulyssessouza ulyssessouza commented Apr 10, 2019

@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
Copy link

@Maher4Ever Maher4Ever commented Apr 25, 2019

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

@GammaGames
Copy link

@GammaGames GammaGames commented Aug 27, 2019

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
Copy link

@jakedouglas jakedouglas commented Sep 5, 2019

@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
Copy link

@entrptaher entrptaher commented Sep 17, 2019

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
Copy link

@omniproc omniproc commented Sep 17, 2019

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

@jcorry
Copy link

@jcorry jcorry commented Sep 17, 2019

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
Copy link

@entrptaher entrptaher commented Sep 17, 2019

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,
image

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
Copy link

@omniproc omniproc commented Sep 18, 2019

@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
Copy link

@entrptaher entrptaher commented Sep 18, 2019

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
Copy link

@omniproc omniproc commented Sep 18, 2019

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

@entrptaher
Copy link

@entrptaher entrptaher commented Sep 18, 2019

@M451, sure, here you go.
image

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

@omniproc
Copy link

@omniproc omniproc commented Sep 18, 2019

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
Copy link

@entrptaher entrptaher commented Sep 18, 2019

Okay, let's try that as well,
image

Again,
image

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,
image

No success for me.

@tiany
Copy link

@tiany tiany commented Feb 20, 2020

--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
Copy link

@plueschpruem plueschpruem commented Mar 12, 2022

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
Copy link

@entrptaher entrptaher commented Mar 12, 2022

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
Copy link

@plueschpruem plueschpruem commented Mar 12, 2022

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?
Bildschirmfoto 2022-03-12 um 20 13 49

This is the error I get

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

Successfully merging this pull request may close these issues.