compose: Environment Variable is not set. Defaulting to a blank string.

A similar question has been floating around stackoverflow and github. Yet, I am not able to solve this problem, I hope somebody can point me in the right direction.

lsb_release

Distributor ID: Debian
Release:        8.8
Codename:       jessie

docker-compose -v docker-compose version 1.9.0, build 2585387

docker -v Docker version 17.05.0-ce, build 89658be

/etc/environment

http_proxy=http://10.50.2.67:3128/
https_proxy=http://10.50.2.67:3128/

/etc/sudoers

...
Defaults        env_keep += "http_proxy"
Defaults        env_keep += "https_proxy"
...

In my docker compose, I’d like to pass both http_proxy and https_proxy as e vars.

...
web:
  environment:
    - http_proxy=$http_proxy
    - https_proxy=$https_proxy

on docker-compose up I get

WARNING: The http_proxy variable is not set. Defaulting to a blank string. I get the same error with any variables in env list.

What am I doing wrong?

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 6
Comments: 25

Most upvoted comments

@olegstepura You can do COMPOSE_OPTIONS="-e ENV1=$ENV1 -e ENV2=$ENV2 -e ENVn=$ENVn" docker-compose <command>

shin- on Mar 20, 2018

@sebas5384 $PWD is a shell variable, not an environment variable. You will have to explicitly include it in the environment (e.g. PWD=$PWD docker-compose up) for it to work.

@rommik 1.9.0 is pretty old as far as docker-compose goes. Can you try upgrading to 1.14.0 and see if anything changes?

shin- on Jul 10, 2017

My present work around is a script like this

#!/bin/bash
cp /etc/environment .env
docker-compose up -d --remove-orphans --force-recreate

I set http_proxy and https_proxy in /etc/environment by another process. Then, I call my script to copy them into .env and spin up my containers. This works fine, but I don’t understand why.

rommik on Jul 10, 2017

I also have an issue with variables in command. My test container (version 3 of compose file):

container:
    image: debian
    command: echo ${FOO}

Run using:

docker-compose up --remove-orphans --force-recreate container

Working fine if I pass variables in .env file or cli:

FOO=cli docker-compose up --remove-orphans --force-recreate container

Not working if I try to set them in named env file secrets.env or directly in docker-compose:

container:
    image: debian
    command: echo ${FOO}
    env_file: secrets.env
    environment:
      FOO: bar

In each scenario, printenv is showing FOO. WARNING: The FOO variable is not set. Defaulting to a blank string. is printed even before the container was downloaded.

docker-compose version 1.14.0, build c7bdf9e
Docker CE Version 17.06.0-ce-mac19 (18663)

Jastrzebowski on Aug 22, 2017

In my case, after updating my docker-composer version to the last one (1.18.0, I was using before 1.14.0, so no suspicion of being the problem, but just in case) and being doing test for a while. Then I realized that my problem came that I have my docker-compose installed as a container, so the service was trying to take the env vars from my docker-compose container, not my local env vars.

I have something like:

service:
    environment:
        FOO

$FOO was present on local environment (I do it in several ways), visible with printenv and from python REPL but wasn’t on docker-compose container.

I write it down because I guess it could be enlightening for others.

barraquito on Jan 10, 2018

@daten-kieker Are you using docker-compose with sudo? It’s hard to imagine why Compose wouldn’t pick up your env variables.

shin- on Jul 27, 2017

I don’t understand why someone hasn’t modified python’s variable substitution code to map $UID and $GID to calls to os.getuid() and os.getgid() on POSIX hosts. Windows doesn’t have a similar concept so this wouldn’t work on windows instances of docker compose, but that would be dealing with a completely different permission model in any case.

jimmyharris on Aug 3, 2017

@sebas5384 In that specific example, replacing ${PWD} with . in your volume definition would work just as well.

I tried reproducing the issue locally (with 1.13 as well) but it works fine for me. Did you make sure $PWD is actually defined locally (i.e. shows up printenv output?) What OS are you running on?

shin- on Jul 10, 2017