Multi stage Dockerfile leads to running out of space

Question

As my code (nodeJS-application) is changing more often than the (npm) dependencies do, I've tried to build something like a cache in my CI.

I'm using a multi-stage Dockerfile. In that I run npm install for all, and only, prod dependencies. Later they are copied to the final image so that it is much smaller. Great.

Also the build get super fast if no dependency has been changed.

However, over time the hd gets full so I have to run docker prune ... to get the space back. But, when I do this, the cache is gone.

So if I run a prune after each pipeline in my CI, I do not get the 'cache functionality' of the multi-stage Dockerfile.

### 1. Build
FROM node:10.13 AS build
WORKDIR /home/node/app

COPY ./package*.json ./
COPY ./.babelrc ./

RUN npm set progress=false \
    && npm config set depth 0 \
    && npm install --only=production --silent \
    && cp -R node_modules prod_node_modules
RUN npm install --silent

COPY ./src ./src
RUN ./node_modules/.bin/babel ./src/ -d ./dist/ --copy-files

### 2. Run
FROM node:10.13-alpine
RUN apk --no-cache add --virtual \
      builds-deps \
      build-base \
      python
WORKDIR /home/node/app

COPY --from=build /home/node/app/prod_node_modules ./node_modules
COPY --from=build /home/node/app/dist .

EXPOSE 3000
ENV NODE_ENV production
CMD ["node", "app.js"]

Answer 1

If your CI system lets you have multiple docker build steps, you could split this into two Dockerfiles.

# Dockerfile.dependencies
# docker build -f Dockerfile.dependencies -t me/dependencies .
FROM node:10.13
...
RUN npm install

# Dockerfile
# docker build -t me/application .
FROM me/dependencies:latest AS build
COPY ./src ./src
RUN ./node_modules/.bin/babel ./src/ -d ./dist/ --copy-files

FROM node:10.13-alpine
...
CMD ["node", "app.js"]

If you do this, then you can delete unused images after each build:

docker image prune

The most recent build of the dependencies image will have a label, so it won't be "dangling" and won't appear in the image listing. On each build its label will get "taken from" the previous build (if it changed) and so this sequence will clean up previous builds. This will also delete the "build" images, though as you note if anything changed to trigger a build it will probably be in the src tree and so forcing a rebuild there is reasonable.

In this specific circumstance, just using the latest tag is appropriate. If the final built images have some more unique tag (based on a version number or timestamp, say) and they're stacking up then you might need to do some more creative filtering of that image list to clean them up.