Stop 07 · Containers & DockerTopics · 3/9

Docker Images & Layers

In short

Ever wondered why one build takes 4 minutes and the next takes 4 seconds? It's all layers. Once you can picture them, you can make every build fast on purpose.

Docker images are built from a stack of read-only layers, each corresponding to a Dockerfile instruction — understanding layer caching explains why build order matters for speed.

The mascot places a fresh top tier on a stacked cake while the lower tiers stay untouched.

Think of it like this

The tiered cake

A three-tier cake is built bottom up. Want new decoration on top? Swap only the top tier. But if you change the bottom sponge, every tier above has to be rebuilt. Image layers work exactly like this, and the cache is the baker's memory.

Watch it happen

Building, then changing one file

push(FROM node:22-alpine)

FROM node:22-alpine

Top of the stack is coloured

1/6The base image's layers come first. They're shared with every other image built on the same base.

The big ideas

What you need to know

Instructions make layers

RUN, COPY and ADD each create a filesystem layer. The image is all of them stacked, read-only.

A change rebuilds everything above

When one layer changes, every layer after it is rebuilt. That's why order matters so much.

Deleting later doesn't shrink

Removing a file in a later layer only hides it. The bytes still live in the earlier layer. Clean up in the same RUN.

Digests never lie

Tags like 1.0 can be moved. A digest like @sha256:… always points to the exact same image.

See it in code

Walk through the code

bash

1# Build twice and watch the cache work2docker build -t myapp:1 .3# edit server.js, then build again4docker build -t myapp:2 .5 6# See every layer and its size7docker history myapp:28docker image inspect myapp:2 --format '{{.RootFS.Layers}}'

1/3The first build runs every step and stores each layer.

On the second build, look for CACHED next to the early steps in the output. Only the steps after your change actually run.

Save yourself the pain

Common mistakes

Oops

Writing RUN apt-get update on one line and RUN apt-get install on the next.

Do this instead

Combine them: RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*. One layer, cleaned up inside it.

Oops

Assuming a smaller-looking Dockerfile means a smaller image.

Do this instead

Check docker history. One careless COPY of a big folder can add hundreds of MB, however short the file looks.

Your mission

Find the fat layer

~20 min

Quick check

Your Dockerfile has RUN wget big.zip, then a later RUN rm big.zip. Is the image smaller?

Go deeper

1Use docker history on an image to see its layer structure.
2Reorder a Dockerfile's instructions to maximize cache reuse on rebuilds.
3Learn why placing frequently-changing instructions (like copying source code) late in the file speeds up builds.