vscode dev container environment variables not exposing to docker-compose

Viewed 1935

My docker-compose.yml looks like this

version: "3.8"
services: 
  vscode:
    volumes:
      - ..:/workspace:cached
      - $SSH_AUTH_SOCK:/ssh-agent
      - /var/run/docker.sock:/var/run/docker.sock
    environment: 
      - SSH_AUTH_SOCK=/ssh-agent

Problem is that vscode does not want to give any kind of possibility to do an equivalent of docker-compose run --env ... thus I'm left with

WARNING: The SSH_AUTH_SOCK variable is not set. Defaulting to a blank string.

Is there any way for me to expose my variables from my host to the dev container without using an .env file or anything like that?

3 Answers

I have opened an issue on github yesterday. The outcome is that if you use WSL, then you need to export this variable through your ~/.profile or ~/.bash_profile.

We are using a non-interactive login shell to probe the environment variables in WSL and use these as the "local" variables.

https://github.com/microsoft/vscode-remote-release/issues/5806

I just had a similar issue so this may help.

I would run the following:

export VARIABLE=VALUE
sudo docker-compose up

The problem was that I was exporting the environment variable as my user and then running docker-compose as sudo so it wouldn't have the same environment variables.

This can be solved by either adding yourself to the docker group so you can run without sudo

or exporting the variable as root(not recommended)

To expose environment variables from the host through a container, as per the documentation

You can pass environment variables from your shell straight through to a service’s containers with the ‘environment’ key by not giving them a value, just like with docker run -e VARIABLE ...:

web:
 environment:
   - DEBUG

The value of the DEBUG variable in the container is taken from the value for the same variable in the shell in which Compose is run.

Regarding specifically SSH_AUTH_SOCK you should have a look at SSH Agent forwarding inside docker compose container.

Example

Right, problem is that environment variables are not being exposed properly even with doing that.

A simple service using a variable DEBUG.

services:
  test:
    image: busybox
    command: ["echo", "${DEBUG}"]
    environment:
      - DEBUG

Using it without exporting the variable, it does not work a warning is displayed in the output.

# running the service
docker-compose up

# WARNING: The DEBUG variable is not set. Defaulting to a blank string.
# Starting d-compose-env_test_1 ... done
# Attaching to d-compose-env_test_1
# test_1  | 
# d-compose-env_test_1 exited with code 0

Now exporting the variable on the host before running it, and it works, the value of the variable is printed.

# exporting the variable
export DEBUG=test
# running the service
docker-compose up

# Recreating d-compose-env_test_1 ... done
# Attaching to d-compose-env_test_1
# test_1  | test
# d-compose-env_test_1 exited with code 0
Related