Advanced Docker: lean images

Building in several stages, choosing a minimal base image, ordering layers to benefit from the cache, excluding what has no place in the image, pulling by digest and pushing to a private registry.

  • 28 cards
  • 4 topics
  • Free

The outline, topic by topic

Each topic is weighted the way the exam weighs it.

  1. Concepts
  2. Questions
  3. Sort and link
  4. Scenarios

A few cards from the deck

  • Multi-stage build: what is it?

    Show the answer

    A Dockerfile with several FROM instructions: one stage compiles with all its tools, the final stage only takes the result over with COPY --from.

    Only the last stage becomes the delivered image. The compiler, sources and caches of earlier stages are absent: for a Go binary, the image goes from several hundred MB to a few MB.

  • This Dockerfile is built once. You then modify only server.js and run docker build again. Which instructions are rebuilt?

    ```dockerfile
    FROM node:20-alpine
    WORKDIR /app
    COPY package.json package-lock.json ./
    RUN npm ci
    COPY . .
    CMD ["node", "server.js"]
    `

    • Only COPY . ., while npm ci stays cached
    • All of them, from FROM to CMD, as in the first build
    • RUN npm ci and COPY . ., since the install also reads server.js
    • None: server.js is not listed in a COPY instruction
    Show the answer

    Only COPY . ., while npm ci stays cached

    The cache invalidates from the first instruction whose inputs change. Copying only the dependency files comes before the install: as long as they are intact, npm ci is reused. COPY . . sees server.js change, and it is the last layer rebuilt (CMD is only metadata).

  • In a multi-stage Dockerfile, the build stage is named with … and a file is taken from it into the final stage with ….

    Show the answer

    In a multi-stage Dockerfile, the build stage is named with FROM golang:1.22 AS build and a file is taken from it into the final stage with COPY --from=build.

    AS build names the stage; --from=build copies from that stage's file system rather than from the build context.

  • Base image: what is it?

    Show the answer

    The image named by FROM, on which all the layers of a Dockerfile are stacked; it sets the system, the tools and a large part of the weight.

    The more tools it holds (shell, package manager), the heavier the image and the more there is to update or exploit. Common variants: full, slim, alpine, distroless, scratch.

  • A Node API with 40 MB of code comes out as a 1.1 GB image, built on node:20 with its build tools. Which improvement reduces the size most without changing the application?

    • Chain all the RUNs into one to reduce the number of layers
    • Compress the image with gzip before pushing it
    • Switch to the latest base, which is newer hence smaller
    • A multi-stage build whose final stage starts from an alpine or slim base
    Show the answer

    A multi-stage build whose final stage starts from an alpine or slim base

    The weight mostly comes from the base and the build tools: the final stage keeps only the code and its runtime dependencies, on a minimal base. Merging RUNs does not remove the tools, and images are already compressed when sent.