Vscode-remote-release: Remote-Container (docker-compose) Support for .env and/or COMPOSE_PROJECT_NAME variable

[quertenmont]

Hello,

Currently, VSCode try to recreate the entire docker-compose stack using the base directory as a project name (docker-compose default) because it ignores the .env file containing the actual project name to use in docker-compose.
Would be nice to either consider COMPOSE_* variables defined in the .env file (as docker-compose does it), or simply give us the possibility to provide that env variable directly in the .devcontainer.json file

Thanks in advance,
Loic

[hareku]

I specify the mysql port etc in the env file, and compose loads it.
Can't read the env file yet?

[nolazybits]

I hit the same issue, I am using the following structure

.devcontainer
    devcontainer.json  
docker-environemnent
    docker-compose.yml  
    .env

I am specifying the correct docker-compose path in the devcontainer.json and the context to also be ../docker-environment

but when reopening folder in container it errors as it can't find the env used in docker-compose.yml defined in the .env file

Really looking forward to have support for this.
Soooo close to have the perfect dev env 👍

edit: maybe an option to pass through args to docker-compose would be even better?

[Chuxel]

@nolazybits @hareku The default .env file is based on where Docker Compose is executed.
This is happening because the context property is not currently used for dockerComposeFile and your .env file is in a sub-folder.

It would work if you put it in the root of your project, but you can also add an env_file property to your service in docker-compose.yml. This makes it relative to the docker-compose file instead of the location that the command is executed.

env_file: .env

@chrmarti This is a bit confusing, so probably a good reason to support the context property.

[chrmarti]

We currently use the project folder as the working directory for all command executions. We could change that to the folder of the docker-compose.yml, but that would break setups where the .env file is currently correctly read from the project folder.

Does setting env_file solve the issue? That only affects individual containers from what I see.

The context property is using as the context when building a Dockerfile, it would be confusing to reuse that here, I think.

[Chuxel]

@chrmarti Yes, you'd have to add it to every service, so it does solve the issue, but is a cumbersome solution. I've seen people ask about environment variables like this before due to how their command line workflow functions. Allowing context to work would give people the option to retain their current workflow.

[chrmarti]

I think the context property is a different concept that only applies to building an image. 🤔

Do we need a way to change the directory from which commands are run? (Reading https://docs.docker.com/compose/env-file/.)

[Chuxel]

@chrmarti Yep, that's actually what context does for the Dockerfile case - it sets the working directory. This would be the same scenario which is why I can see why @nolazybits tried to use it.

[Chuxel]

@chrmarti In fact, I wonder if we should't be including an env file our dev container definitions - particularly existing docker-compose / dockerfile to make this pattern a bit more obvious.

[nolazybits]

My 2 cents - maybe using the context would be a good idea and then leave it to docker compose so you don't have to play catch if anything changes on their side (multiple env file for instance etc).
The context coming from docker is a natural way for a dev to try to specify the working directory as you said for the docker file so felt natural here to try to specify the docker compose directory...
Thanks again

[chrmarti]

Documentation and my tests show that .env is only supported by docker-compose and it is read from the current working directory. These variables are then substituted in the docker-compose.yml and applied to docker-compose itself if they apply (e.g., COMPOSE_PROJECT_NAME).

context is a docker build concept that represents the folder and its contents available for ADD and COPY at build time. I wouldn't want to mix that with the above.

The feature request here is asking for supporting .env for docker-compose. That is already supported if you place the .env file in the project's root folder because that is the current working directory when we run docker-compose.

To expand on this we could add support for changing the current working directory when running docker-compose. Let's keep this issue for that and open new issues for additional requests.

[Lastwisher]

We are experiencing same issue on our side, we are developing Laravel on laradock, laravel using .env file for own config at project directory.

At laradock ( docker template) also .env file at their directory

Our folders

• laravelsite2
• laravelsite1
• Laradock

In this case when we try to launch at vsCode in container, its reads .env file of laravel.

Using env_file is not option for us, we need ENV config on build of docker compose (docker-compose.yml : https://github.com/laradock/laradock/blob/master/docker-compose.yml )

Here is some suggestions
1) If we have a option like "startUpDirectory" or "runDirectory" at devcontainer.json we can easily setup our docker env.

2) Also another option can be "env-file" option for docker compose, docker-compose have --env-file option at 1.25 version

3) "composeArgs" can be a another option we can pass like
"composeArgs" : ["--env-file=custom.env"]

Also at here is mentioned : https://github.com/microsoft/vscode-remote-release/issues/1299

[hholst80]

tl,dr; Using .env file is the same thing as saying COMPOSE_PROJECT_NAME=foo docker-compose ...

Note that .env and --env-file does not work exactly in the same way. --env-file passes environment variables to the instantiated container whereas .env files exposes environment variables to docker-compose and variable interpolation in its configuration files. those variables will not be passed to the instantiated container unless specified explicitly in an environment block.

[rawtaz]

The feature request here is asking for supporting .env for docker-compose. That is already supported if you place the .env file in the project's root folder because that is the current working directory when we run docker-compose.

Unfortunately this doesn't seem to be true. I have two completely identical projects here, the only difference is the actual source code for the two applications.

Each project has, directly in the root folder of the project, .devcontainer.json, Dockerfile, docker-compose.yaml, .env (with COMPOSE_PROJECT_NAME=... in it).

In the file explorer of the project windows, I see "SOURCE" as the heading, because "source" is the name of the folder that all these files and the application source code resides in. These files are listed as being directly that, which I believe means they are "in the root folder of the project" (there's no place higher up they can be and still be shown in the file explorer).

The two projects have different COMPOSE_PROJECT_NAME values in the .env file, yet when I start them through "Remote-Containers: Reopen in Container", the two projects collide (image/network/volume/container names are all based on a project name "source" for both projects - file explorer contents is the same in both project windows, and they interfere with each other).

We really need to make this extension aware of and use COMPOSE_PROJECT_NAME in .env files that are located in the same directory as the docker-compose.yaml file that's being used. Isn't that a really simple thing to do?

We know where the docker-compose.yaml file is located and are using it, so why not just look for a file named .env in the same directory as that file, and if found load and supply the environment variables that are in it when executing the docker-compose command? Should solve the problem once and for all, I think. I don't understand what we're waiting for :)

BTW, if it's not clear, I can verify that if I docker-compose up manually these two projects, they don't collide at all.

[rawtaz]

@Chuxel This is currently labeled as a feature request, but considering it's such a problem when using multiple projects and how common the use of COMPOSE_PROJECT_NAME in .env is (in particular to solve the problem of colliding project names), can you please relabel this to "bug" or something, so that it gets attention?

The fixes that both I and others have suggested (simply look for a .env in the same folder as docker-compose.yaml and use the environment variables in it when calling docker-compose) should be pretty small and simple to implement I guess, and it would solve the problem straight away. As I wrote above, moving the .env file to the root folder of the project does not work around the issue.

I fear that as long as this is called just a "feature request" it won't get any attention, and it's really a bug that it's not working properly with the project names defined in accordance with official Docker Compose documentation.

[dantman]

This vscode remote containers bug is really bothering me. I've tried putting a .env with COMPOSE_PROJECT_NAME=foo, in both the project root and in .devcontainer and even added env_file to every container in docker-compose. No matter what I do I still get containers with foldername_devcontainer_containername instead of myapp_containername.

[rawtaz]

Yeah. Considering how insanely easy this problem is to fix, it's baffling that Microsoft doesn't fix it, despite all these comments and clear evidence that it's a real problem and makes serious docker compose usage impossible.

[rawtaz]

Got a mail today; "Closed #222 via 7b7aa9a5991f7c6a61ac228b064d9051a3732b59".

[enjibby]

OMG is this closed and due out soon? AWESOME 😀

[art-in]

i have docker-compose.yml and .env for it outside current project folder.
i'm using several env vars inside docker-compose.yml, not only for container_name

so now i have to copy that .env to current project folder so it's used by docker-compose
i would like to avoid that copy and reuse same .env

should i file another issue for this case?

[chrmarti]

@art-in Yes, please file a new issue. Thanks.