Proposal: Add "--from" to docker build for overriding base images to better support hotfix builds

[lcarstensen]

This is a request for a docker build feature to be able to override on the commandline what is defined in the Dockerfile for FROM. The driving use case is primarily in support of creating hotfixes, along the lines of the git-flow model of hotfixes:

http://nvie.com/posts/a-successful-git-branching-model/

...where we need to revert to an older version of a base image but build with new code.

FROM lines in a Dockerfile are rarely pinned to version numbers, and therefore typically infer ":latest" as their version identifier. There are times when we identify bugs in the current releases of those base images while still needing to create interim build artifacts. Alternatively, we have to create special releases of a base image to address an issue for some period of time (my/baseimage:latest v. the/baseimage:latest). In all of these cases it is desirable to not modify Dockerfile source materials but simple invoke different builds and tests.

This could of course also be used to change support structures around an image build also. For example you could have publicly shared Dockerfile repos specifying "FROM centos" and locally override builds to use "--from rhel".

[frank-dspeed]

lol this can't work man !!!! this would be amazing confusing i know what you mean but what do you expect if you got FROM ubuntu:14.10 and then do FROM rhel lol :D do you think yum and all that will work as expected?

but i have a solution for you Simply copy paste all contentent and not the FROM line from the dockerfile then you do in shell:
docker build - <<EOF
FROM choose your imageby writing
paste here now the rest and hit enter then write the word
EOF

hit enter and your done it will build :D

[lanzz]

We have a two-phase build process, where rarely-changed dependencies have their own image that is very rarely rebuilt (and its rebuild is slow, so we want to avoid it), and our actual codebase is built on top of that base image. The base image cannot have a fixed name, because our CI server is running automated builds for multiple branches that might be using different base dependencies (e.g. two branches might have introduced different new dependencies, and until they've been merged we don't have a way to build a base image that would satisfy both branches). Being able to specify a dynamically-named base image on the run would fit very well with our build process.

Generating the Dockerfile on the run is going to work, but it is a dirty workaround for a very reasonable (in my humble opinion) feature request.

[duglin]

I'm not keen on adding a new option to the docker build command-line just to override the FROM because at what point do we draw the line between build options to override what's in the Dockerfile vs just telling people to create a new Dockerfile.

@frank-dspeed 's suggestion of generating the Dockerfile on-the-fly is good one.

Another option is to have more than one Dockerfile and use the -f option to choose which one to use based on the situation. Of course, the downside to this is that you'll have to keep them all in-sync (aside from the FROM) - which will be annoying without some kind of INCLUDE feature, which has been discussed.

Anyway, another option is to use environment variables. There's a discussion in #9176 to allow for env vars to be defined just for build time. If we then allowed for you to write:

FROM ${FROM_IMAGE:-ubuntu}

Then it would default to "ubuntu" unless "FROM_IMAGE" is specified via docker build -e FROM_IMAGE=....
Of course it would also require #11149 to be merged.
But I would prefer this more generic solution than a FROM-specific one.
Thoughts?

ping @tiborvass

[lanzz]

Using environment variables to fine-tune the Dockerfile behavior sounds like a much better approach than a FROM-specific command-line option, yes.

[mapuri]

+1 for using variables/symbols expansion in Dockerfile to achieve this.

[frank-dspeed]

I think this will get trouble for the docker hub maybe but i see it as a good think at present i archive such expansion of vars via writing the Dockerfile on demand befor build via a script.

[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.

[iankoulski]

+1 I would love to have this option as well due to need to dynamically build images in different environments where the public docker registry is not available. Configuring the FROM image in a docker build is necessary in that case. Presently the only solution is to dynamically write the FROM line in the Dockerfile.

[thaJeztah]

Also related #18119 and #18585

[JamieCressey]

+1

We build from a static Dockerfile via Jenkins, so being able to provide the source image (version) as a variable at (Jenkins) build time, would be so much easier for our use case.

[flungo]

I see that the Dockerfile syntax is no longer a frozen feature on the roadmap.

I would really like to see the ability to put build-args in the FROM directive. I think similar to others the reason would be to have the ability to build from multiple base images. If I could have FROM docker:${version:-latest} then I would be able to set up CI build jobs to create images for 1.9, 1.10, 1.11 and 1.12 (as an example).

[thaJeztah]

@flungo issue #18585 is still opened, so I think we can use that for tracking

[rajivbhati12]

I see it kind of tricky because it impact the basic build principle of dockfile;
meaning:- every step of dockerfile execute in its own container and get save as a temp image for next step; with this thought; for first line to execute it has be static.
Unless we update FROM to perform extra step something like: if imagename[:tag] not found and appears to be more like variable then interpret it as variable

BTW; I am one add to people in queue waiting or this feature, as this can make CI look clean and not hacky
So, are there plans to enable this feature?

[philippe-granet]

You can now use build-time args (ARG) in FROM #31352

[thaJeztah]

With BuildKit used as the default builder, you can now use the --build-context flag to override stages;
https://docs.docker.com/engine/reference/commandline/buildx_build/#build-context

• implemented in build: support for named contexts(stages) docker/buildx#904

# syntax=docker/dockerfile:1
FROM alpine
RUN echo hello

docker build --build-context alpine=docker-image://alpine:3.18 .

Which shows that the FROM alpine stage was replaced with alpine:3.18;

[+] Building 3.0s (7/7) FINISHED
 => [internal] load build definition from Dockerfile                                                                             0.0s
 => => transferring dockerfile: 93B                                                                                              0.0s
 => resolve image config for docker.io/docker/dockerfile:1                                                                       0.6s
 => CACHED docker-image://docker.io/docker/dockerfile:1@sha256:ac85f380a63b13dfcefa89046420e1781752bab202122f8f50032edf31be0021  0.0s
 => => resolve docker.io/docker/dockerfile:1@sha256:ac85f380a63b13dfcefa89046420e1781752bab202122f8f50032edf31be0021             0.0s
 => [context alpine] load metadata for alpine:3.18                                                                               1.0s
 => [internal] load .dockerignore                                                                                                0.0s
 => => transferring context: 2B                                                                                                  0.0s
 => [context alpine] alpine:3.18                                                                                                 0.8s
 => => resolve docker.io/library/alpine:3.18                                                                                     0.2s
 => => sha256:9fda8d8052c61740409c4bea888859c141fd8cc3f58ac61943144ff6d1681b2d 3.33MB / 3.33MB                                   0.3s
 => => extracting sha256:9fda8d8052c61740409c4bea888859c141fd8cc3f58ac61943144ff6d1681b2d                                        0.3s
 => [1/2] RUN echo hello                                                                                                         0.4s