[jrockway]

I've been very close to creating something like this internally. It is easy to write a Dockerfile that produces a compact and optimal container. But it's the same lines of code over and over again. Anything we have that's a static site looks like:

    FROM node:10 AS build
    WORKDIR /foo
    COPY . .
    RUN npm i
    RUN npx webpack

    FROM nginx:whatever
    COPY nginx.conf /etc/nginx/config.d/
    COPY --from=build /foo/dist /srv
    ...

It's fine when you have one. Annoying when you have a couple. This isn't code that needs to be checked into the repository and updated. It needs to just work.

The other thing I'd like to see is the ability to output multiple containers from one Dockerfile. There is so much wasted work where I have webpack stuff and a go application that run in separate containers but are built together. There is one Dockerfile like the above to build the static part. There is another to build the go binary and copy it to an almost-pristine alpine container (including dumb-init, cacerts, tzdata, and grpc_health_probe). I don't understand why I have to have two Docker files to do that.

[chusk3]

You don't have to have separate dockerfiles. If you use multistage builds, you can name the specific terminal stages and then invoke them with 'docker build -t stagename', which will reuse the build cache as you'd expect. I've done this to export multiple app containers from a monorepo.

[krainboltgreene]

Yo, their example has multiple stages.

[rhizome]

I think they're talking about intermediates, which wouldn't have to be rebuilt every time.