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.
- Concepts
- Questions
- Sort and link
- 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.jsand rundocker buildagain. 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 . ., whilenpm cistays cached - All of them, from
FROMtoCMD, as in the first build RUN npm ciandCOPY . ., since the install also readsserver.js- None:
server.jsis not listed in aCOPYinstruction
Show the answer
Only
COPY . ., whilenpm cistays cachedThe 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 ciis reused.COPY . .seesserver.jschange, and it is the last layer rebuilt (CMDis only metadata).- Only
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 buildnames the stage;--from=buildcopies 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:20with 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
gzipbefore pushing it - Switch to the
latestbase, 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.- Chain all the