Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Enable Dockerfiles to build, and tag, multiple images #5726
Dockerfiles are almost ideal for building code from source into binaries in a deterministic containerized environment. (In this sense, they serve as a more flexible version of a buildpack.)
However, currently, the result of this build is always a docker image which descends linearly from the source-image, and which thus contains the toolchain used to compile it. In some few cases, this is acceptable--when there is no difference between the toolchain required to operate on the source, and the runtime required to execute the binaries, the toolchain image can "specialize" into the runtime image without any sort of heavy removals.
But this case is rare. More often, your runtime will be a tiny VM or library, but the toolchain will depend on the ability to compile dependencies written in other languages (e.g. C), which themselves require -devel versions of libraries, and so forth. None of this stuff is necessary at runtime, but for compilation to succeed, it must be part of the toolchain, and thus the toolchain must be a multi-gigabyte image that would be ridiculous to pull down to your production cloud-instances et al.
People currently sidestep this problem in a number of ways:
None of these workarounds obey the spirit of Dockerfile builds: deterministically turning a source image, plus a context, into a destination image.
I propose an alternative, which would look something like the following:
This presumes one additional Dockerfile stanza, and one change-in-behavior of a current Dockerfile stanza:
Together, these two alterations allow you to have a Dockerfile which creates multiple images, keeping state from the creation of one to the next. If you ran this Dockerfile using
Besides the potential workflow presented in the Dockerfile above, a few more possibilities open up by allowing for a third stanza:
Then you could do something like this:
This stanza would require a slight change in the behavior of
For backwards compatibility,
Then from there, patches/features like this can be re-thought. Hope you can understand.