Day 32: Images, layers & union filesystems (OverlayFS)
An image is a stack of read-only layers
Each instruction in a Dockerfile (FROM, RUN, COPY...) produces a new, immutable layer — a diff against the layer below it. An image is just an ordered list of these layers. When you run a container, Docker adds one thin writable layer on top of the image's read-only layers — this is exactly the copy-on-write principle from Phase 0, Day 6, applied to a filesystem.
OverlayFS is the union filesystem that makes this stacking work: it presents multiple directories (the layers) as a single merged view. Reads fall through to whichever layer actually has the file; writes go only to the top writable layer, and if a file from a lower layer is modified, OverlayFS copies it up first (copy-up) before writing.
Why this makes containers cheap and images shareable
If ten containers all run from the same base image, they share the exact same read-only layers on disk — only their thin writable layers differ. This is why pulling an image you've already pulled a similar version of is fast: Docker only downloads layers you don't already have.
docker history node:20-slim
docker inspect node:20-slim --format '{{.RootFS.Layers}}'Key terms
- Layer
- An immutable diff produced by one Dockerfile instruction; images are a stack of layers.
- OverlayFS
- The union filesystem that merges multiple layer directories into one view, with copy-up on write.
- Writable layer
- A container's own thin read-write layer on top of its image's read-only layers.
Why is pulling a new image fast if it shares a base with an image you already have?
