Proposal: ENVFILE instruction : Allow to create multiple environment variables from a file

[coolsvap]

Use case: Allow ENV to import a file containing variables to be exported

Issue: I am currently trying to create a container image for my application which on its installation generates a text file with all the exports that are needed by it. This file can be sourced and used ahead to perform operations using the application.
Currently I am not able to source the file with RUN source filename, instead I have to do a ENV operation.

Please find the reference Dockerfile at [1] and its build output at [2]

I think the ENV instruction can be extended to have file as parameter.

[1] https://github.com/coolsvap/docker-source-issue/blob/master/Dockerfile
[2] https://registry.hub.docker.com/u/coolsvap/docker-source-issue/build_id/13901/code/blbeyqt8cekrqrngp8hbaqa/

[coolsvap]

Tried the same thing with Fedora and same result

[cpuguy83]

@coolsvap source is a bash built-in, RUN is using /bin/sh.
You'd need to do . path/to/envfile; <your command>

Though being able to import envs from a file in a Dockerfile would be awesome and is already supported on docker run

[wyaeld]

we do this thing a lot using the

ENTRYPOINT ["docker-entrypoint.sh"]

pattern that you'll find in a number of the supported images. At that point, we can construct variables from auto-exposed database link variables, source variables from files, and do any of those sort of things you're probably attempting.

doing it with the entrypoint is more useful I find for setting up environment, since it doesn't get ignored if you override CMD.

[coolsvap]

@wyaeld but I think this use case makes sense for long term, where image builders can easily build images with ENV variables generated on the fly with ENV instruction in dockerfile.

also, can you give me an example dockerfile? I could not find any, I will try that as a workaround

[erikh]

I think this is a good approach. ENV files should be kept in the context, but yeah, this is not a bad idea at all.

Proposing a new verb though: either SOURCE or ENVFILE

-Erik

On Aug 22, 2014, at 12:44 PM, Swapnil Kulkarni notifications@github.com wrote:

Use case: Allow ENV to import a file containing variables to be exported

Issue: I am currently trying to create a container image for my application which on its installation generates a text file with all the exports that are needed by it. This file can be sourced and used ahead to perform operations using the application.
Currently I am not able to source the file with RUN source filename, instead I have to do a ENV operation.

Please find the reference Dockerfile at [1] and its build output at [2]

I think the ENV instruction can be extended to have file as parameter.

[1] https://github.com/coolsvap/docker-source-issue/blob/master/Dockerfile https://github.com/coolsvap/docker-source-issue/blob/master/Dockerfile
[2] https://registry.hub.docker.com/u/coolsvap/docker-source-issue/build_id/13901/code/blbeyqt8cekrqrngp8hbaqa/ https://registry.hub.docker.com/u/coolsvap/docker-source-issue/build_id/13901/code/blbeyqt8cekrqrngp8hbaqa/
—
Reply to this email directly or view it on GitHub #7688.

[cpuguy83]

ENVIFLE +1
SOURCE would imply too much.... unless we litterally did call the source'd items before each RUN command.

[erikh]

I’m torn on that. SOURCE basically has no advantages over RUN other than it persists the environment. It might just be smarter to make RUN more powerful at that point.

On Aug 23, 2014, at 12:00 PM, Brian Goff notifications@github.com wrote:

ENVIFLE +1
SOURCE would imply too much.... unless we litterally did call the source'd items before each RUN command.

—
Reply to this email directly or view it on GitHub #7688 (comment).

[wyaeld]

@coolsvap https://github.com/docker-library/wordpress is an example of a Docker repo doing the entrypoint trick.

[coolsvap]

@erikh I completely agree. I am using RUN to execute some commands which depend on the source file my application generates run-time. I would be more happy if we can make RUN more powerful to persist environment or temporarily use the environment config from some place.

@wyaeld Thanks for the suggestion, let me try that out as a workaround for my current work. Being said that I believe we can use the ENTRYPOINT only once, am I correct? I am asking this since I have a next application which I want to automate with dockerfile which generates 2 source files, one for normal user and one for administrator, where the approach suggested by @erikh to make RUN more powerful could be very helpful.

[jessfraz]

Hello!
We are no longer accepting patches to the Dockerfile syntax as you can read about here: https://github.com/docker/docker/blob/master/ROADMAP.md#22-dockerfile-syntax

Mainly:

Allowing the Builder to be implemented as a separate utility consuming the Engine's API will open the door for many possibilities, such as offering alternate syntaxes or DSL for existing languages without cluttering the Engine's codebase

Then from there, patches/features like this can be re-thought. Hope you can understand.