Visual walkthrough — Containerization with Docker

We build on Containerization with Docker and lean on Reproducibility in ML for why we care so much about identical rebuilds.

Step 1 — What "building an image" even means

WHAT. When you run docker build, Docker reads your Dockerfile top to bottom, one instruction at a time. Each instruction produces a new layer — think of it as one thin, frozen sheet of "changes to the filesystem". Stack the sheets and you have the whole image.

WHY start here. Before we can talk about cost we must agree on the unit that costs something. That unit is a layer. No layers, no formula.

PICTURE. Below, each Dockerfile line becomes one pancake in a stack. The bottom pancake (FROM python:3.11-slim) is the base OS + Python; the top pancake (COPY . .) is your code. The whole tower — read from bottom up — is the image.

Step 2 — Each layer has a build cost $c_i$

WHAT. Cooking a pancake takes time. pip install -r requirements.txt might take 90 seconds; COPY . . takes a fraction of a second. We give layer number $i$ a number $c_i$ — the seconds it takes to build that one layer.

WHY a symbol. We want to add up time. To add things you must first name them. We name the $i$-th layer's build time $c_i$ so that later a sum like $c_3+c_4+\dots$ means something concrete.

PICTURE. Same tower, now with a number pinned to each pancake. Notice the fat red number: the dependency-install layer is by far the most expensive.

Step 3 — Every layer carries a fingerprint (a hash)

WHAT. Docker gives each layer a fingerprint — a short string computed from (a) the instruction text and (b) the fingerprint of the layer below it. This fingerprint is called a hash. Same inputs → same hash. Change anything → different hash.

WHY this tool and not just "compare the files"? Docker needs a fast way to ask "is this layer identical to one I built before?" Comparing whole filesystems byte-by-byte would be slow. A hash squashes any input into one short string, so equality is a one-line string compare. That is exactly the question a hash is built to answer.

PICTURE. Each pancake now wears a tag like a1b2…. Crucially, the arrow shows each tag is computed from the tag beneath it plus its own instruction — the fingerprints are chained.

Step 4 — The cache: reuse a layer if its fingerprint already exists

WHAT. Before cooking a pancake, Docker checks: "do I already have a layer with this exact fingerprint?" If yes, it skips cooking and reuses the frozen one — a cache hit, cost $0$. If no, it must build it — a cache miss, cost $c_i$.

WHY. This is the entire payoff of hashing. A build where nothing changed is free because every fingerprint matches a stored layer.

PICTURE. Two towers side by side: last build (all green ✓ cache hits) vs a rebuild where nothing changed — every layer is reused, total new work $\approx 0$.

Step 5 — One change poisons everything above it

WHAT. Here is the crux. Suppose you edit app.py. That changes the COPY . . instruction's inputs, so its fingerprint changes. But recall Step 3: every layer's fingerprint is built from the one below it. So the changed fingerprint feeds the next layer up, changing its fingerprint too — and so on to the top.

Let $k$ be the index of the first changed layer. Then layer $k$ is a miss, and because its hash changed, layers $k+1,k+2,\dots ,n$ all get new parent-hashes → all misses. Layers below $k$ are untouched → all hits (cost $0$).

WHY. This chaining is not a bug; it guarantees an image is reproducible top-to-bottom. But it means a change ripples upward only, never downward.

PICTURE. The red pancake at position $k$ is edited. Watch the red "invalidation" wave travel upward, re-cooking $k$ and everything above; everything below stays frozen-green.

Step 6 — The design lever: make $k$ as high as possible

WHAT. You cannot change that the wave goes upward. But you choose the order of your Dockerfile instructions, and that choice sets which layer the daily change lands on — i.e. it sets $k$. Push the thing that changes every commit (your source code) to the top, so $k=n$ and the wave has almost nothing to travel through.

WHY this tool — ordering, not something fancier. The sum ${\sum }_{i=k}^n{c}_i$ shrinks when $k$ grows and when the expensive $c_i$ sit below $k$. Both are achieved by one free action: reordering lines. No caching flags, no tricks — just put deps early, code late.

PICTURE. Two Dockerfiles, same instructions, different order. Left (COPY . . early): editing code lands at a low $k$, so the red wave re-cooks the pricey pip layer — slow. Right (requirements.txt first): the same edit lands at the top, red wave is tiny — fast.

Step 7 — Edge & degenerate cases (never leave the reader stranded)

WHAT. Real builds hit corners. Each below is a special value of $k$.

Case A — nothing changed ($k$ does not exist / is "past the top"). No layer's fingerprint differs, so the sum has no terms: $C_{\text{rebuild}}=0$. This is the all-green tower of Step 4. Fully cached rebuild = free.

Case B — the base changed ($k=1$). You edited FROM python:3.11-slim → 3.12. The bottom layer changes, so the wave covers everything: $C_{\text{rebuild}}={\sum }_{i=1}^n{c}_i$ — a full rebuild. This is the worst case and it is unavoidable: a new base genuinely invalidates all that sits on it.

Case C — a dependency changed but code did not ($k$ = pip layer). Editing requirements.txt changes the pip layer and everything above it (the code copy). So you pay the 90 s plus the tiny copy on top — correctly, because your installed packages really are different now.

Case D — the "latest" trap (hidden change with $k=1$). If your base is python:latest instead of a pinned tag, the base's fingerprint can change without you editing anything, silently forcing $k=1$ tomorrow. This is why Reproducibility in ML and the parent note both scream: pin an immutable tag. Compare with Container Registries, where the same image digest guarantees the same bytes.

PICTURE. Four mini-towers, one per case, colored by how far the red wave climbs: A (none), C (from the middle), B & D (from the floor).

The one-picture summary

Everything above is one law: the red invalidation wave only climbs, so keep the volatile line at the top and the expensive line at the bottom. The figure compresses the whole derivation — the chained fingerprints, the wave, the sum ${\sum }_{i=k}^n{c}_i$, and the design lever — into a single frame.

Connections

• Containerization with Docker — the parent; this page derives its layer-cost formula.
• CI-CD Pipelines — every commit triggers a rebuild; layer order is the speed knob there.
• Container Registries — layers are shared by hash, so a good base is pulled once.
• Reproducibility in ML — immutable tags keep $k$ from moving behind your back.
• Kubernetes Orchestration — pulls the finished image; smaller cached layers = faster rollouts.