I have a development environment setup that uses compose, and some of the environment variables are provided through a .env
file. When I run docker-compose up
from the folder where the .env
is, everything works fine. When I run up
from a subdirectory, the .env
variables aren't picked up.
It would make more sense to me if the .env
file was expected to be in the same directory as docker-compose.yml
and that docker-compose
would only look there for the .env
file.
Thank you for the feedback! However, the feature currently works as documented, and it is not something we intend to change for the foreseeable future.
Oh! Okay, I missed that. I'll make sure to document in my own project. Thank you for your response!
Just to give some context, the reason it works like that 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. :)
Ahhhh. That makes some sense. Thanks!
I stumbled also on this.
Out of curiosity, what would be the use case for defining a COMPOSE_FILE in an .env-file?
Actually I would rather prefer if the docker-compose.yml would point to an environment-file and make the file ".env" present in the same directory as the docker-compose.yml the default. The rationale would be that users of docker-compose seem to be trained that the default entrypoint for looking up the configuration by docker-compose is the first docker-compose.yml found if going up the directory structure. Surprisingly this behaviour suddenly changes if an .env-file comes into play. Without a strong use case for the deviation from the intuitively anticipated behaviour it feels like a flaw in the user interface.
Still I understand that it might be problematic to change from that, therefore after some thoughts on this:
It would be nice if the .env file would be looked up the same way the docker-compose.yml is looked up. In other words, if .env is not present in the current-directory, climb up until the first of .env or docker-compose.yml is found. This would almost preserve the current behaviour. Additionally an output that states which .env-file is actually in effect would provide the user with some information on the effective configuration.
In addition to the .env file search mechanism as describe above. It would help to have a commandline option like "--env-file FILENAME", - a file specified that way should have precedence over any other environment-file.
@shin- Sorry... but I found this feature first in this page https://docs.docker.com/compose/environment-variables/#the-env-file and is not really well documented, due is not explicit about the "current directory" of execution. In addition, is not linked to the previous page...
I think @t-hofmann solution works for our use case.
+1 to --env-file FILENAME parameter.
Just had the same problem as @sir-gon - a note in https://docs.docker.com/compose/environment-variables/#the-env-file would be helpful. (Yes, I "could have just clicked the link to "environment file" - but the fact that I'm not the only one who run into this seems to justify the request somewhat ;))
This is not user friendly.
Please implement --env-file FILENAME
[...]
Actually I would rather prefer if the docker-compose.yml would point to an environment-file and make the file ".env" present in the same directory as the docker-compose.yml the default. The rationale would be that users of docker-compose seem to be trained that the default entrypoint for looking up the configuration by docker-compose is the first docker-compose.yml found if going up the directory structure. Surprisingly this behaviour suddenly changes if an .env-file comes into play. Without a strong use case for the deviation from the intuitively anticipated behaviour it feels like a flaw in the user interface.
[...]
It would be nice if the .env file would be looked up the same way the docker-compose.yml is looked up. In other words, if .env is not present in the current-directory, climb up until the first of .env or docker-compose.yml is found. This would almost preserve the current behaviour.
[...]
I totally agree with @t-hofmann's thought sabout what user would expect. I was actually trying to specify the path to the .env file in docker-compose.yml and would never had expected that I should do it the other way round.
The solution he proposes (looking up in the directory tree until an .env file is found) would be the perfect solution imho as it is aligned with the logic of .gitignore and (in my case) package.json of npm.
Ahh, I finally understand why things weren't working the last couple of hours. The behavior deviates from env_file
lookup. Who would have guessed. I actually did read the docs a couple of times. I guess I skipped over the the very first line where it reads:
... placed in the folder where the docker-compose command is executed (current working directory).
My suggestion would be when deviating from expectation (namely similar behavior to env_file
specified files), the doc should have a big different colored section with an exclamation mark. No one _reads_ the docs; we all _scan_ the docs.
I know this issue is old but I stumbled upon it because I was having the same issue. There's no --env-file
option but you can use the --project-directory
to set the current working dir to the directory where the .env
file is located along with the docker-compose.yml
and it works that way.
For my use case the command looks like this:
docker-compose -f .my_docker_folder/docker-compose.yml --project-directory=.my_docker_folder config
@axelitus thank you for sharing. This helps me out.
@axelitus 馃 I was looking for that today, it's very helpful when building in CI
Would be nice if there was a way to specify it in docker-compose.yml
...
I realized that I've been always using docker-compose commands from a sub-directory, which worked fine.
I have a project containing a docker-compose configuration to launch a development environment, which seems a pretty common use-case.
I recently added a private git repo as a project dependancy. The dockerfile build process now require ssh credentials to do npm install to be able to access the private repo.
After looking around, the only way for the differents dev to be able to specify the path to their own ssh private key would be to have it in a .env, and pass it as a build ARG. However, doing so means that now, if docker-compose commands are ran in a subfolder, it will now crash...
--env-file PATH Specify an alternate environment file
docker-compose --env-file /opt/docker/.env -f /opt/docker/docker-compose.yml config
Command is added to docker-compose, working as desired.
docker-compose version 1.25.4, build 8d51620a
Most helpful comment
In addition to the .env file search mechanism as describe above. It would help to have a commandline option like "--env-file FILENAME", - a file specified that way should have precedence over any other environment-file.