Dockerfile Multiple Inheritance with nested builds

[theypsilon]

I would like to initiate a discussion about a different approach of solving the same issue that many people want to fix with those Mixins or Include proposals.

Here is a list of those referred discussions:
#24445
#3378
#735

My two cents. The approach of using nested builds would be actually pretty simple. Inside the Dockerfile there would be a new command for running another build (from now, I'll refer to it as the subbuild), and that subbuild would be as isolated as any other build, it will be in fact a build running externally in its own build context. Additionally, you declare which paths of the subbuild will be copied into the parent build.

Example:

FROM nginx:1.11.1
BUILDCOPY ["Dockerfile.node-artifact"]:/dist /usr/share/nginx/html
# This syntax is just to illustrate the example, I'm not proposing any syntax here

In the example you can see that we are taking nginx:1.11.1 as base image, and in the second line we are: 1. building the Dockerfile named "Dockerfile.node-artifact" located in the host to create a subbuild image, and 2. copying the folder "/dist" of the subbuild image to the location "/usr/share/nginx/html" of the resulting parent intermediate image

Also, because of the existing --build-arg feature, there is a very nice opportunity to:

1. Change the subbuild Dockerfile depending on an ARG/ENV variable.

   Example:

   ARG SUB_BUILD=Dockerfile.production
   BUILDCOPY ["${SUB_BUILD}"]:/subbuild/path /parent/path
   

2. Influence the subbuild from the parent build by passing arguments, so the subbuild can be generic if that makes sense for a given use case.

   Example:

   BUILDCOPY --build-args NAME=${NAME} ["Dockerfile.base"]:/subbuild/path /parent/path
   

Another extra could be using already existing images instead of Dockerfiles.

Example:

FROMCOPY ["nginx:1.11.1"]:/subbuild/path /parent/path

The main advantage of this approach vs include-like solutions is that the builds are still isolated. In one hand, the subbuilds keep their own cache, and can be built and tested without the parent build. And in the other, the input/output bounds are explicit and clear from the parent build perspective, and wouldn't produce conflicts between images.

Other things that needs discussion and I didn't mention yet about this proposal:

• subbuild context
• syntax
• recursion
• subbuild intermediate image references

I think implementation of this feature wouldn't be that complicated, as this would translate into another docker build, docker cp in the host system, followed by a COPY within the Dockerfile.

[thaJeztah]

I think this is a duplicate of #7115, which proposes nested builds; could you have a look if that is indeed what you're proposing?

[theypsilon]

It is very similar @thaJeztah indeed.

I think there is still a very key difference, this proposal handles nested builds as external builds. They can be built on their own and they are isolated, they have no special syntax nor any other special properties. #7115 on the other hand, makes them to be part of the parent build declaration.

[jmahowald]

For me, this Docker Make did the 80/20 rule for similar features. You get mixins, but it works by generating the docerkfiles

[thaJeztah]

I think this is mostly covered by multi-stage builds, and BuildKit allowing multiple stages to be built and used as source for COPY --from=.... Let me close this ticket for now.