CONTAINERS / A CONCEPT NOTE
Container Layers
how images are built from stacked, cached snapshots
Overview · mechanism
pitfall · examples
01 / THE SHORT VERSION
The idea in a few sentences.
Every RUN, COPY, or ADD in a Dockerfile creates an immutable layer. Layers stack to form the image. When you rebuild, only changed layers are recreated; unchanged layers come from cache. At runtime, a thin writable layer sits on top — changes never modify the underlying image.
02 / FOLLOW THE MECHANISM
How a layered build works
Build kit
reads the Dockerfile and executes each instruction sequentially.
Each RUN
creates a new layer by running the command in a temporary container and snapshotting its filesystem.
Each COPY
adds a layer containing just the copied files and their metadata.
Cache lookup
before executing, Docker checks if a layer with the same parent + instruction hash already exists.
Final image
is the union of all read-only layers, with metadata (CMD, ENTRYPOINT, ports) from the last layer.
04 / COMMAND NOTES
Read the command, then the result.
Inspect the flags and arguments before trying an example. Snippets can need local setup, replacement values, or resources in your own environment.
inspect every layer in an image
docker history IMAGE_NAMEsee full image metadata and layer digests
docker image inspect IMAGE_NAME05 / CHECK YOURSELF
Could you explain Container Layers to a teammate?
Try it out loud in two sentences: what it is, and the one detail that changes the picture. If you stall, the gap is the part to reread.
Up next in Containers & KubernetesHelmkubernetes package manager — templated charts for complex apps