Docker run: Passthrough environment variables do not get passed through

[jon-shipley]

Problem description

Passthrough environment variables do not get passed through; the documentation says they do.

Problem location

• I saw a problem on the following URL: https://github.com/docker/docker/blob/master/docs/reference/commandline/run.md

# pass through this variable from the caller
TEST_PASSTHROUGH
$ TEST_PASSTHROUGH=howdy docker run --env-file ./env.list busybox env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=5198e0745561
TEST_FOO=BAR
TEST_APP_DEST_HOST=10.10.0.127
TEST_APP_DEST_PORT=8888
_TEST_BAR=FOO
TEST_APP_42=magic
helloWorld=true
TEST_PASSTHROUGH=howdy
HOME=/root
123qwe=bar
org.spring.config=something

Project version(s) affected

Observed in Ubuntu Xenial

$ docker --version
Docker version 17.03.0-ce, build 60ccb22

and macOS

Version 17.03.0-ce-mac2 (15654)
Channel: stable
1d7d97bbbd

The TEST_PASSTHROUGH environment variable does not seem to be passed through:

$  TEST_PASSTHROUGH=howdy docker run busybox env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=2566c262240f
HOME=/root

My reading of the docs suggested it would get passed through. I am not sure if this is a documentation error, a bug, or my misunderstanding.

[joaofnfernandes]

I think the example is outdated or confusing. You can set environment variables like

# option 1, set the value in the command
docker run -e TEST_VAR=value --env-file env.list  alpine env

# option 2.1, use an existing variable
TEST_VAR=value docker run -e TEST_VAR --env-file env.list  alpine env

# option 2.2, use an existing variable
export TEST_VAR=value
docker run -e TEST_VAR --env-file env.list  alpine env

# option 3, use an existing file
cat <<EOL > env.list
TEST_VAR=value
EOL

docker run -e TEST_VAR --env-file env.list  alpine env

You can also mix it all together, and use --env-file and -e at the same time. If the same environment variable is defined both in a file and the environment, the container will be set with the value from the environment.

[jon-shipley]

Hi @joaofnfernandes - Thanks for the workarounds, that may be useful for others who read this issue.

The specific issue is that the PASSTHROUGH method is documented as working, and doesn't in the the versions I tested.

I think this documentation just needs to be updated from the upstream version.

[johndmulhausen]

Fixed by @joaofnfernandes back in March. Thanks!

[brokenthorn]

I'm sorry but I can't seem to get this to work either. A simple test of docker run -e TEST_VAR=1234 --env TEST_VAR2=1234 alpine env reveals the variables in the guest, but docker build -t stockwebservice . && docker run --env JDBC_USERNAME=user --env JDBC_PASSWORD=1234 --env API_PASSWORD=1234 --name stockwebservice stockwebservice refuses to set the environment correctly!

Even changing the Dockerfile to run env instead of my app doesn't work so I'm thinking that the Dockerfile must be the problem.

# We select the base image from. Locally available or from https://hub.docker.com/
FROM openjdk:8-jre-alpine

# Expose TCP port
EXPOSE 8080:8080

# We define the user we will use in this instance to prevent using root that even in a container, can be a security risk.
ARG APPLICATION_USER=ktor

# We define a distribution name as created by gradle's application plugin.
# This distribution will be added to the container.
ARG DISTRIBUTION=stockwebservice-0.1

# Then we add the user, create the /app folder and give permissions to our user.
RUN adduser -D -g '' $APPLICATION_USER
RUN mkdir /app
RUN chown -R $APPLICATION_USER /app

# Marks this container to use the specified $APPLICATION_USER
USER $APPLICATION_USER

# We copy the FAT Jar we built into the /app folder and sets that folder as the working directory.
ADD "./build/distributions/$DISTRIBUTION.tar" /app
WORKDIR /app

RUN env
RUN "./$DISTRIBUTION/bin/stockwebservice"

[osomanden]

Use .env file instead?

[docker-robott]

Closed issues are locked after 30 days of inactivity. This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

/lifecycle locked