Allow to import ENV from file

[davinkevin]

duplicates / older tickets related to this;

• Proposal: ENVFILE instruction : Allow to create multiple environment variables from a file moby#7688
• Dockerfile support for ENVFILE ./.env?  moby#28617
• Allow to import ENV from file moby#49399

Description

Description

Hello 👋

I'd like to report a feature request about a pain point we (and I, in multiple companies) face about ENV.

To detail the problem, we deliver images as a team or company, but sometimes we must have multiple versions of the same image (different base images, different tools inside like nonroot-debug…). If I describe it with an example, it could be like this:

FROM distroless/java:…

COPY app.jar /app.jar
ENV MY_MANDOATORY_JVM_ENV=foo

ENTRYPOINT ["java", "/app.jar"]

But, if we want to deliver a :slim version of the resulting image, we need to do something like this:

FROM distroless/java:… AS standard

COPY app.jar /app.jar
ENV MY_MANDOATORY_JVM_ENV=foo

ENTRYPOINT ["java", "/app.jar"]

FROM chainguard/java:… as slim

COPY --from=standard app.jar /app.jar
ENV MY_MANDOATORY_JVM_ENV=foo

ENTRYPOINT ["java", "/app.jar"]

We see the ENV parameter is duplicated and can't be inherited because the base images are different. For simplicity, we use a multi-stage build with different targets during docker build….

Worse, when a customer of ours wants to alter our images or build their own on top of us (like IronBank for American Defense), everything is done in another CI with no possibility of sharing a Dockerfile.

With that context set, I'd like to ask if a solution could be evaluated to load the ENV variable from an external source. Something like this would solve our problem, for example:

FROM distroless/java:… AS standard

COPY app.jar /app.jar
ENV --from="our-dot-env-file.env"

ENTRYPOINT ["java", "/app.jar"]

FROM chainguard/java:… as slim

COPY --from=standard app.jar /app.jar
ENV --from="our-dot-env-file.env"

ENTRYPOINT ["java", "/app.jar"]

With this approach, we could store in the git repo the our-dot-env-file.env with this content:

MY_MANDOATORY_JVM_ENV=foo

And, with convention, it could be shared with external customers willing to alter our images (for hardening purposes, like done by IronBank, for example).

NOTE This feature is already available in docker run and docker compose, so it being available in docker build would make sense too.

Thank you. I'm available for a call to discuss in-depth cases like this in the system we/I encountered.

Regards

PS: Originally opened here

[thaJeztah]

I added some of the duplicates to the ticket description. Just to link things together; for inheriting options from "parent" stages, there's also;

• [RFC] Allow defining mounts for whole stage #1209
• Proposal: add IMPORT/EXPORT commands to Dockerfile #5707

[davinkevin]

Thank you @thaJeztah. I didn't identified them as potential solutions, but you're right they could cover it!