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

docker-compose does not set environment variables #7423

Closed
Kytech opened this issue May 4, 2020 · 47 comments
Closed

docker-compose does not set environment variables #7423

Kytech opened this issue May 4, 2020 · 47 comments
Labels

Comments

@Kytech
Copy link

Kytech commented May 4, 2020

Description of the issue

When using docker-compose up or docker-compose run -e ENVIRONMENT_VAR=value, environment variables are not being applied either through the -e command line parameters or from the docker-compose.yml file.

The docker-compose.yml file I am using is as follows:

version: '3'
services:
    nginx-reverse-proxy:
        image: nginx
        volumes:
         - C:/Users/<Username>/nginx-reverse-proxy/configdir:/etc/nginx/conf.d/
        ports:
         - "80:80"
        environment:
            NGINX_SERVER_NAME: "test.mysite.org"
            NGINX_REMOTE_URL: "http://remote.mysiteengine.somehost.com:13345"

Context information (for bug reports)

Output of docker-compose version

docker-compose version 1.25.5, build 8a1c60f6

Output of docker version

Client: Docker Engine - Community
 Version:           19.03.8
 API version:       1.40
 Go version:        go1.12.17
 Git commit:        afacb8b
 Built:             Wed Mar 11 01:23:10 2020
 OS/Arch:           windows/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.8
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.17
  Git commit:       afacb8b
  Built:            Wed Mar 11 01:29:16 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.2.13
  GitCommit:        7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Output of docker-compose config

WARNING: The NGINX_SERVER_NAME variable is not set. Defaulting to a blank string.
WARNING: The NGINX_REMOTE_URL variable is not set. Defaulting to a blank string.
services:
  nginx-reverse-proxy:
    environment:
      NGINX_SERVER_NAME: "test.mysite.org"
      NGINX_REMOTE_URL: "http://remote.mysiteengine.somehost.com:13345"
    image: nginx
    ports:
    - 80:80/tcp
    volumes:
    - C:\Users\<Username>\nginx-reverse-proxy\configdir:/etc/nginx/conf.d/:rw
version: '3.0'

Steps to reproduce the issue

  1. Create a docker-compose.yml file that sets environment variables
  2. Run docker-compose up

Observed result

Environment Variables are not applied

Expected result

Environment variables should be applied to containers started by docker-compose

Stacktrace / full error message

WARNING: The NGINX_SERVER_NAME variable is not set. Defaulting to a blank string.
WARNING: The NGINX_REMOTE_URL variable is not set. Defaulting to a blank string.
Creating network "nginx-reverse-proxy_default" with the default driver

Additional information

OS Version: Windows 10 Pro v1909,
docker-compose install method: Docker Desktop for Windows Installer, followed by manual upgrade of docker-compose (Issue occurred on docker-compose version 1.25.4 which was included with Docker Desktop and with manual upgrade to 1.25.5)

@Kytech Kytech added the kind/bug label May 4, 2020
@hholst80
Copy link

???
This yaml is broken. Please post the actual yaml you are deploying with.

        volumes:
         - C:/Users/<Username>/nginx-reverse-proxy/configdir:/etc/nginx/conf.d/

@Kytech
Copy link
Author

Kytech commented May 11, 2020

???
This yaml is broken. Please post the actual yaml you are deploying with.

        volumes:
         - C:/Users/<Username>/nginx-reverse-proxy/configdir:/etc/nginx/conf.d/

This is the yaml I am using. It works exactly as expected on my local machine when I don't have environment variables included. I am using docker for Windows, so the file path format is different than with linux. I have not included my PC username for privacy purposes.

@kravchenkoloznia
Copy link

Facing the same issue.

And I found that environment variables are working only from .env file placed in the folder where the docker-compose command is executed (current working directory).

Providing environment variables from command line giving the same warnings as @Kytech mentioned.

$ docker-compose run -e PRODUCT=1 all
WARNING: The PRODUCT variable is not set. Defaulting to a blank string.

Providing environment variables from user-specific docker-compose.env file still resulting with the same warnings

$ cat docker-compose.env 
PRODUCT=1
RELEASE=0
FLASH=0
DEBUG=3

$ cat docker-compose.yml 
version: '3'
services:
  all:
    image: 82100_src:latest
    env_file: ./docker-compose.env
    volumes:
      - .:/home/user
    command: make PRODUCT=${PRODUCT} all RELEASE=${RELEASE} FLASH=${FLASH} DEBUG=${DEBUG}

$ docker-compose run all
WARNING: The PRODUCT variable is not set. Defaulting to a blank string.
WARNING: The RELEASE variable is not set. Defaulting to a blank string.
WARNING: The FLASH variable is not set. Defaulting to a blank string.
WARNING: The DEBUG variable is not set. Defaulting to a blank string.

I'm using Linux Debian 10 with next versions of Docker and Docker-compose:

$ docker-compose version
docker-compose version 1.23.2, build 1110ad01
docker-py version: 3.6.0
CPython version: 3.6.7
OpenSSL version: OpenSSL 1.1.0f  25 May 2017

$ docker version
Client: Docker Engine - Community
 Version:           19.03.9
 API version:       1.40
 Go version:        go1.13.10
 Git commit:        9d988398e7
 Built:             Fri May 15 00:25:25 2020
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.9
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.13.10
  Git commit:       9d988398e7
  Built:            Fri May 15 00:23:57 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.2.13
  GitCommit:        7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

@hholst80
Copy link

.env file and env_file have different semantics. If you want to use variable interpolation in your compose file you have to use the .env file.

@hholst80
Copy link

My conclusion here is that the -e environment variables are treated with the same semantics as env_file. Consistent with docker cli run cmd.

@kravchenkoloznia
Copy link

@hholst80 indeed, my mistake.

After reading docker documentation one more time and few additional articles, it's now obvious for me that for substitution in docker-compose file itself used environment variables of my current shell, and to send environment variables inside docker container I may use either docker run CLI or env_file.

Thanks!

@Kytech
Copy link
Author

Kytech commented May 28, 2020

@kravchenkoloznia that should be a good workaround in the meantime.

I hope the docker team fixes this since it's broken just about every docker-compose file I've been using that specifies environment variables in the docker-compose.yml

@azryelryvel
Copy link

azryelryvel commented Jun 4, 2020

Nothing is working for me, I can't use any environment variable :

/tmp/test$ curl -SsL "https://github.com/docker/compose/releases/download/1.26.0/docker-compose-$(uname -s)-$(uname -m)" -o docker-compose
/tmp/test$ ls -a
.  ..  docker-compose  docker-compose.yml
/tmp/test$ cat docker-compose.yml
version: '3'
services:
  test:
    image: 'busybox'
    command: env
    environment:
      - HELLO=WORLD
/tmp/test$ sudo ./docker-compose down
Removing network test_default
WARNING: Network test_default not found.
/tmp/test$ sudo ./docker-compose up -d
Creating network "test_default" with the default driver
Creating test_test_1 ... done
/tmp/test$ sudo docker logs test_test_1
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=b68e605e609d
HOME=/root

It doesn't work with env_file, .env or docker run -e either

EDIT: The problem disappeared after updating docker to 18.09.8

@Mahima-ai
Copy link

Mahima-ai commented Jul 31, 2020

Hey, While working on docker with Celery and Rabbitmq integration, I also faced the issue where the environment variables were not used up (set) though they can be seen using the env command in the container. I solved the issue by taking the below two steps.

  1. I uninstalled the older docker-compose and installed the latest by following https://docs.docker.com/compose/install/
  2. I renamed the service for which the environment variables were defined in the docker-compose.yml.

Later on, I rechecked with the old service name and found that the issue reappeared. Then I removed the older container and again did docker-compose up. This solved the issue. So I think, it might be the old container which does not let us see the new changes.

I am using Docker Engine v19.03.12 and docker-compose v 1.26.2

The contents (related to the issue) of my docker-compose.yml are:

version: "3.8"

services:  
  rabbit:
    hostname: rabbit
    image: rabbitmq:management
    environment:
      - RABBITMQ_DEFAULT_USER=user1
      - RABBITMQ_DEFAULT_PASS=password1
    ports:
      - "5672:5672"
      - "15672:15672"

@agovindaraju
Copy link

agovindaraju commented Oct 1, 2020

I am on the latest version of docker compose 1.27.4. I still see the same issue as other users have described above.

@michaelpburt
Copy link

I am also experiencing the same problem on the latest version of Docker (2.4.0.0).

@kerolos-sss
Copy link

I have encountered the same issue,
My issue was caused by running docker-compose in a different python virtual environment.

I hope this could help.

It seems that by running on a different python virtual env, I ruined the docker-compose dependency pythondotenv

@zachsa
Copy link

zachsa commented Oct 20, 2020

I ran into this problem trying to use docker-compose to recreate a Mongo container.

MONGO_USER=me MONGO_PSWD=somepswd docker-compose up -d --force-recreate --build

This works, providing volumes associated with the resultant container are recreated (delete the volumes that the container will use and recreate)

@MatteoGioioso
Copy link

I have the same exact bug with the latest version of Docker 20.10 and Docker-compose 1.27 on Mac OS

@namighajiyev
Copy link

In my case only newly added one environment variable is not set in running container others get set normally.

     environment:
           Api__ConnectionString: ${Api_Docker__ConnectionString}
           Api__Recaptcha__Secret: ${Api_Docker__Recaptcha__Secret}
           ASPNETCORE_URLS: 'https://+;http://+'
           ASPNETCORE_HTTPS_PORT: 10081
           ASPNETCORE_Kestrel__Certificates__Default__Password: ${Api__Kestrel__Certificates__Default__Password}
           ASPNETCORE_Kestrel__Certificates__Default__Path: /https/Api/api.pfx

I run printenv command inside running Linux container and verified that the Api__Recaptcha__Secret variable doesn't get set.

@JonnyWaffles
Copy link

This same incredibly confusing issue is occurring to me. Some of my environmental variables set in my yaml file are respected during the runtime execution, and others are missing and my runtime script validation functions terminate the container. Awkwardly, I can see all of the variables properly set in the PyCharm Environmental Variables Docker inspection. Like @namighajiyev reports above, it appears my more recent environmental variables are not being respected during runtime.

I tried docker-compose build --no-cache but that doesn't resolve the issue either.

@JonnyWaffles
Copy link

So while trying to debug this strange issue, I came up with this awkward workaround. I deleted the docker compose deployment using the docker dashboard so I can reuse the same compose definition and not have any container name conflicts.

I then copied the project to another directory. Executing docker-compose up now works! So I try the aforementioned workflow again, cp the working project folder to a new home, and now docker-compose fails like previous. I am completely stumped. It seems so random.

@joma74
Copy link

joma74 commented Nov 17, 2021

Had some luck by starting docker-compose in non daemon mode after a change to environment setting(via environment section in docker-compose.yml). Then stop that and start in daemon mode again, environment settings are kept.

@franklinchou
Copy link

Any update on this? Seems that docker-compose is still not picking up .env files?

@ndeloof
Copy link
Contributor

ndeloof commented Jan 3, 2022

Please give Compose v2 a try and let me know if this issue persists with the new codebase

@ubiuser
Copy link

ubiuser commented Jan 13, 2022

docker compose up --build <your-container> fixed the issue for me.

@Lhamide00
Copy link

Any update on this?

I have the exact same bug with Docker version 20.10.11 and Docker-compose 1.29.2 on Mac OS.

Removing and re-building the containers did not help. Doesn't matter whether I docker-compose up with or without -d flag either; bug remains!

@qalinn
Copy link

qalinn commented Feb 10, 2022

Hello!
I have the same issue. Any update on this?

@ubiuser
Copy link

ubiuser commented Feb 17, 2022

@Lhamide00 @qalinn As earlier said by @ndeloof, please try using v2, so call docker compose instead of docker-compose.

@qalinn
Copy link

qalinn commented Mar 1, 2022

Hello @ubiuser, I tried how you suggested but it didn't work. I don't have any clue what should I try.
Do you have another suggestion?

@JonnyWaffles
Copy link

Hi friends, we once again encountered this mysterious error even when using docker compose instead of docker-compose. Random environmental variables vanish.

@palunel
Copy link

palunel commented Apr 19, 2022

Same here.

I have the following docker-compose.yml:

version: "3.9"

services:
  compute:
    build: .
    ports:
      - "27030:27030"
    environment:
      - COMPUTE_HOST=$COMPUTE_HOST
      - COMPUTE_PORT=$COMPUTE_PORT

In my .env file I have the following:

COMPUTE_HOST="0.0.0.0"
COMPUTE_PORT=27030

This is to start up a flask api, but what I get when I run the container with:

docker compose --env-file .env up --build

or

docker-compose --env-file .env up --build

is this:

apv_compute-compute-1  | APV server starting on port None ...
apv_compute-compute-1  |  * Serving Flask app 'api' (lazy loading)
apv_compute-compute-1  |  * Environment: production
apv_compute-compute-1  |    WARNING: This is a development server. Do not use it in a production deployment.
apv_compute-compute-1  |    Use a production WSGI server instead.
apv_compute-compute-1  |  * Debug mode: on
apv_compute-compute-1  |  * Running on http://127.0.0.1:5000 (Press CTRL+C to quit)
apv_compute-compute-1  |  * Restarting with stat
apv_compute-compute-1  |  * Debugger is active!
apv_compute-compute-1  |  * Debugger PIN: 483-995-326

The api insists on starting on 127.0.0.1:5000 suggesting that the environment variables are not set at all.

It also does not work if I change my compose file as follows:

    environment:
      - COMPUTE_HOST="0.0.0.0"
      - COMPUTE_PORT=27036

When running the app outside of docker it works perfectly fine. Does anyone have a sensible workaround?

Docker version 20.10.14, build a224086

@ndeloof
Copy link
Contributor

ndeloof commented Apr 19, 2022

@palunel can you check docker-compose exec <service> env ?

@palunel
Copy link

palunel commented Apr 19, 2022

@ndeloof Interesting:

PATH=/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=42a08ea9f254
COMPUTE_HOST="0.0.0.0"
COMPUTE_PORT=27036
GPG_KEY=E3FF2839C048B25C084DEBE9B26995E310250568
PYTHON_VERSION=3.9.12
PYTHON_PIP_VERSION=22.0.4
PYTHON_SETUPTOOLS_VERSION=58.1.0
PYTHON_GET_PIP_URL=https://github.com/pypa/get-pip/raw/38e54e5de07c66e875c11a1ebbdb938854625dd8/public/get-pip.py
PYTHON_GET_PIP_SHA256=e235c437e5c7d7524fbce3880ca39b917a73dc565e0c813465b7a7a329bb279a
HOME=/home/app

@ndeloof
Copy link
Contributor

ndeloof commented Apr 19, 2022

ok, so this is an application issue then :P

@Kytech
Copy link
Author

Kytech commented Jun 2, 2022

Just to add my two cents as the original author if this issue, I've been able to successfully set env variables in docker compose for a little while now. Not sure what fixed it, but it seems newer versions resolved the issues I was having.

@Bakanych
Copy link

Bakanych commented Jun 2, 2022

Having similar issue right now
Docker version 20.10.14, build a224086

@Azbesciak
Copy link

Azbesciak commented Jul 22, 2022

Same as me, casual docker-compose, after update on windows to 4.8.1 (docker for windows) env variables are not passed to the container, even if in inspect mode these are visible...
but printenv does not print anything like this.

@michael-gates-techngs
Copy link

Experiencing this issue on Docker 20.10.17 build 100c701 on an M1 Mac.

@unRARed
Copy link

unRARed commented Aug 10, 2022

Experiencing this issue on Docker 20.10.17 build 100c701 on an M1 Mac.

same build, same issue on an Intel Mac this afternoon.

@andremarcondesteixeira
Copy link

I have the same problem, using docker compose v2
extremely frustrated! :(

@glours
Copy link
Contributor

glours commented Sep 23, 2022

@andremarcondesteixeira feel free to open a new issue with an example that allows us to reproduce the problem (compose file, dockerfile, try to use official images...)

@gopar
Copy link

gopar commented Jan 31, 2023

Any updates on this? Running into this today as well.
Tried re-installing and did not work.

Extremely unfortunate

gopar$docker version

Client:
 Cloud integration: v1.0.29
 Version:           20.10.22
 API version:       1.41
 Go version:        go1.18.9
 Git commit:        3a2c30b
 Built:             Thu Dec 15 22:28:41 2022
 OS/Arch:           darwin/arm64
 Context:           default
 Experimental:      true

Server: Docker Desktop 4.16.2 (95914)
 Engine:
  Version:          20.10.22
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.18.9
  Git commit:       42c8b31
  Built:            Thu Dec 15 22:25:43 2022
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.6.14
  GitCommit:        9ba4b250366a5ddde94bb7c9d1def331423aa323
 runc:
  Version:          1.1.4
  GitCommit:        v1.1.4-0-g5fd4c4d
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

gopar$ docker-compose version
Docker Compose version v2.15.1

@glours
Copy link
Contributor

glours commented Jan 31, 2023

Hello @gopar
Can you open a new issue with a reproducible example?

@HansBambel
Copy link

I had a similar issue, but substituting RUN with CMD for the last command made the environment variables discoverable. This Stackoverflow post helped me with this.

@phutaneVinayak
Copy link

Any update on this ?

@ndeloof
Copy link
Contributor

ndeloof commented Feb 6, 2024

@phutaneVinayak :

Can you open a new issue with a reproducible example?

@ihass
Copy link

ihass commented Feb 7, 2024

Please also note environment variables concatenation in docker-compose is not working. Expl below, KC_HOSTPORT and KC_DUMMY can never be reused in the following environment variables (KC_COLON_HOSTPORT, KC_DUMMY2, KC_DUMMY3, ...). I tried a lot of combination. (My tech environment : Windows 11, Spring Boot, Gradle/Kotlin, Docker Desktop, IntelliJ)

version: "3.8"

x-common-variables:
  &common-variables
  KC_HOSTNAME: localhost
  KC_HOSTPORT: 8080

services:
  my-backend:
    environment:
      <<: *common-variables
      KC_PROTOCOL: http
      KC_DUMMY: dummy
      KC_DUMMY2: "$KC_DUMMY" #KO
      KC_DUMMY3: "${KC_DUMMY}" #KO
      KC_DUMMY4: "$${KC_DUMMY}" #KO
      KC_COLON_HOSTPORT: ":${KC_HOSTPORT}" #KO
       ...

@ndeloof
Copy link
Contributor

ndeloof commented Feb 7, 2024

@ihass you expect compose to replace ${XX} with other variables set by environment. Variable interpolation does not relies on this, but only uses variables set in your local environment (os.Env) and local .env file.

@phutaneVinayak
Copy link

phutaneVinayak commented Feb 7, 2024 via email

@mmngreco
Copy link

This worked for me:

services:
  test:
    image: alpine
    # command: echo MYVAR=$MYVAR  # Not working
    # command: echo MYVAR=$$MYVAR  # Not working
    command: sh -c "echo MYVAR=$$MYVAR"
    environment:
      MYVAR: "asfd"

@justinabrahms
Copy link

Just noting for others, docker-compose restart $mycontainer isn't adequate to have it pick up envvars. docker-compose up --force-recreate --build $mycontainer does appear to be adequate.

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

No branches or pull requests