Docker Community Forums

Share and learn in the Docker community.

Build-time env vars


(Brian Clements) #1

I wanted to continue a discussion from a bug report here regarding build-time env vars.

I’ve been told that something like this:

build-env

VERSION=stable

Dockerfile

FROM radial/axle-base:latest
ADD build-env /build-env
RUN source build-env && mkdir /$VERSION
RUN ls /

is bad practice for Dockerfiles because it breaks “reproducibility”. But how? Can someone please give me a use case where this is a security problem? What is the downside? The use case here is where someone would like to use the same dockerfile to build from source code, by dynamically, at build time, specify a version to build (which could be pulled, compiled, copied, tagged using this same version info etc.)

The point I was trying to make on the bug report was that what if I’m packaging “build-env” along with my source code in my repo? How is this different conceptually then what I “should” do which is make separate Dockerfiles? It’s specifying a value in a file, and uploading it into the container via build time, it affects the end result which is captured as a docker image with a tag. How is that any different then changing a configuration file for my binary, then rebuilding? This is more of a “templating” use of Dockerfiles, yes, whereby instead of editing my dockerfile manually, or forking it and modifying it, I just do this with a drop-in file at build time.

What is the effective difference between three different Dockerfiles, each with manually selected $VERSION variables, vs. one Dockerfile that uses my hack above to produce 3 different image results? I always thought the reproducibility concern was around doing something like SSH into a running container and tinkering while it’s running rather then how we built the image.

Thanks!


(Sven Dowideit) #2

mmm, wow - I suspect there’s a bit of confusion going on - I suspect that like me, @erikh misread your example to be about out of context env vars, which we’re struggling to design safely.

I think there is a PR that basically suggests doing a variation on this using a ENVFILE instruction - I’ll look it up and see where that goes.

the main problem is that there’s a long discussion on that issue, which is only tangentially related to the issue.


(Sven Dowideit) #3

ah - https://github.com/docker/docker/pull/9190

so really, instead of adding your question to an existing and closed issue, you could make a proposal pull request that we can use to persuade the reviewers that its important and useful :slight_smile:

edit<

and then I read that there is https://github.com/docker/docker/issues/7688 - which is the proposal for it


(Brian Clements) #4

Ah, this is great. Thanks sven, I’ll know where to go on this issue now, thanks!