microsoft / vscode-remote-release

Visual Studio Code Remote Development: Open any folder in WSL, in a Docker container, or on a remote machine using SSH and take advantage of VS Code's full feature set.
https://aka.ms/vscode-remote
Other
3.65k stars 285 forks source link

Docker-Compose: Support --env-file option #4885

Open Waelder opened 3 years ago

Waelder commented 3 years ago

Hi,

want have a multi container app ( db, python, react). I want to run it locally in docker, and connect to the python as well as to the react container. The last obstacle is the automatically generated "compose project name" which is different.

Following the documentation i created a .env file to create a name for docker compose. otherwise the 2nd. open folder in container would fire up a complete new compose stack.

Unfortunately when i follow this documentation, i had to create copy of .env file in the folder wich i opened with the 2nd windows in the container. Probably because then the subfolder is then considered as project root.

Kind regards

chrmarti commented 3 years ago

Adding support for --env-file would solve your request from what I see. (Updating the issue's title.)

Waelder commented 3 years ago

yes, sounds good, however the documentation suggest that it "just somehow magically works" but with the --env-file at least we can achieve the goal.but it would require a documenation update as well, for other newbies like me.

PONzu-0529 commented 3 years ago

I have a similar problem.

I'm using Docker Desktop, when using Docker Compose V2, I had to change the location of .env. It is possible to load .env in the container with docker-compose.yml, but it cannot load when docker-compose is ran.

So, I would like to be able to load .env at build in the devcontainer.json.

fyyyyy commented 3 years ago

I want to load an .env file at build time without docker-compose, this seems not possible atm ?

chrmarti commented 3 years ago

@fyyyyy Correct, we don't have the env-file option yet and, unlike docker-compose, the docker CLI does not read the .env file from the current folder by default.

fyyyyy commented 3 years ago

Ok, nevermind. So env-file is only supported at runtime by docker cli, not at build time.

~There are 2 options to pass env variables in the docker cli. One is via --env, the other via --env-file Passing those via --env seems to work with devContainers at BUILD time. However passing an --env-file in runArgs makes them available AFTER the build. This difference of outcomes confuses me.~

docker run -e MYVAR1 --env MYVAR2=foo --env-file ./env.list ubuntu bash

fyyyyy commented 3 years ago

❓ It would be nice if VScode devcontainer.json supports reading build args from a file. So we won't need this workaround

As this is off-topic ( I'm not using docker-compose), i've created a new feature request #5475

bgloss commented 1 year ago

https://github.com/orgs/devcontainers/discussions/36

bgloss commented 1 year ago

vscode executes docker compose from the folder of the first docker-compose.yml file in the list.

When you place an empty docker-compose.yml into the root folder of your projects and list it as the first docker-compose.yml to use, you get what you want.

Two nice side-effects:

my devontainer.json looks like this:

    "dockerComposeFile": [
        "../../docker-compose.yml",
        "../../environments/dev_local/postgres/docker-compose.yml",
        "./docker-compose.yml"
    ],

The docker-compose.yml in the root folder is this:

version: '3.8'
# intentionally empty

What makes it a bit quirky is that the paths of the docker-compose files are relative to the project and the paths inside the docker-compose.yml files are relative to the root of the projects.

It is just a work-around. I think a proper solution is needed in devcontainer.json to mange it.

bgloss commented 1 year ago

To add to the feature request ... I think just adding a method to provide the --env-file option into the docker compose scenario is not enough.

As it is already established for the "Image and Dockerfile Scenario" a similar approach to control and externalize key settings in the "Docker Compose Scenario" would be needed.

Just for comparison: This is how a devcontainer.json looks like when using the Dockerfile scenario:

    "build": {
        "dockerfile": "Dockerfile",
        "context": "..",
        "args": { 
            "VARIANT": "3.10-bullseye",
            "NODE_VERSION": "lts/*"
        },
    },
        "runArgs": [ "--env-file=../.env" ]

similar methods to specifiy context, args and runArgs would be needed.

metaskills commented 1 year ago

So my needs align more with (https://github.com/microsoft/vscode-remote-release/issues/5324) which was closed as a duplicate and now this issues title "using --env-file" may not. Let me explain.

I would like our base .devcontainer folder to work for Codespaces and our CI/CD via GitHub Actions (using devcontainers/ci). As such, the devcontainer.json would leverage a "dockerComposeFile": ["docker-compose.yml"] and a key part of the compose service would be an Oracle DB. This DB does not work on arm64 (Apple Silicon) and there is a need to run our devcontainers locally. I would like a way for users to configure a non git committed file to remove the Oracle DB service. My hope was something like this:

  1. Commit a .devcontainer/docker-compose-local.yml file. (contents below)
  2. Git ignore the .devcontiner/.env file.
  3. Have Mac users create the .devcontiner/.env with a COMPOSE_FILE env variable (seen below)
# .devcontainer/docker-compose-local.yml
services:
  oracle:
    image: hello-world
    restart: "no"
    volumes: []
# .devcontiner/.env
COMPOSE_FILE=docker-compose.yml:docker-compose-local.yml

Would the solutions proposed here help me with that or should we open this back up?

gislerro commented 1 week ago

I'd suggest to extend the devcontainer compose spec to include a dockerComposeArgs option, which are then passed to the docker compose command:

{
    "dockerComposeFile": ["a.compose.yaml", "b.compose.yaml"],
    "dockerComposeArgs": ["--env-file custom.env"]
}

should result in docker compose -f a.compose.yaml -f b.compose.yaml --env-file custom.env

So the docker compose files will be interpolated based on custom.env.

I guess some compose args may interfere with how vscode sets up the container or just don't make sense (--dry-run for example). So allowing a subset of the args would be ideal