🥞 Images & Layers

An image is not one big blob — it's a stack of read-only layers. Understanding this makes builds fast and images small.

1. An Image Is a Stack of Layers

Every instruction that changes files during a build creates a new layer — a read-only "diff" of what changed. The final image is all layers stacked together. Press the button to stack them up:

Layer 1 · FROM ubuntu:22.04 base OS files · 78 MB Layer 2 · RUN apt install python3 + python files · 25 MB Layer 3 · COPY app.py /app/ + your code · 0.1 MB Layer 4 · RUN pip install flask + libraries · 12 MB ✏️ Writable container layer added ONLY when a container runs — deleted with it
The stack is empty — press "Add next layer".
🥞 Analogy: An image is a stack of pancakes. Each pancake (layer) is cooked once and never changed. Ten students can share the same bottom pancakes (base OS) — only the top pancake differs. When a container runs, Docker puts a sheet of baking paper on top (the writable layer): the container scribbles on the paper, never on the pancakes. Throw the container away → only the paper is lost.

2. Why Layers Matter: Sharing & Caching

3 images on one machine… app-A code app-B code app-C code python:3.12 layer — stored ONCE, shared by all 3 ubuntu base layer — stored ONCE, shared by all 3 ✅ Disk used: base layers counted one time, not three ⚡ Build cache You change ONE line of app code and rebuild: • unchanged layers → reused from cache (instant) • only the changed layer + those above it rebuild Result: rebuilds take seconds, not minutes.
Practical rule that follows: in a Dockerfile, put things that rarely change (OS, dependencies) early, and things that change often (your code) late — so most layers stay cached on every rebuild. Chapter 3 shows this in action.

3. Names & Tags — Identifying Images

registry.io/team / studentfees : v2.1 WHERE it lives (registry/namespace) WHAT it is (repository name) WHICH version (tag)
⚠️ The "latest" trap: latest is just the default tag name — it is NOT automatically the newest version, and it changes over time. In real deployments always pin a specific tag like nginx:1.25, never nginx:latest.

4. Moving Images Around — pull, push, build

Dockerfile your recipe (text file) lives in your git repo build 💾 Local image on your machine docker images push ↑ pull ↓ ☁️ Registry Docker Hub / private shared with the team & servers The full cycle: build on your laptop → push to the registry → servers pull and run it.
# The three commands of the cycle:
docker build -t team/studentfees:v2.1 .   # Dockerfile → local image
docker push team/studentfees:v2.1         # local image → registry
docker pull team/studentfees:v2.1         # registry → any other machine

5. Inspecting What You Have

CommandShows you
docker imagesAll images on this machine (name, tag, size)
docker history nginxThe layers of an image and which instruction made each
docker inspect nginxFull JSON details (env vars, ports, entrypoint…)
docker rmi nginx:1.25— removes an image (frees disk)
docker system dfHow much disk images/containers/volumes use

🧠 Checkpoint

Answer all 3, then check. Explanations appear either way.
1. What does each layer of an image actually store?
Layers are deltas. That is why the tenth image built on the same base costs almost no extra disk, and why pulling a related image downloads only the missing pieces.
2. `docker images` shows five images of 200 MB each. Is 1 GB of disk in use?
The SIZE column counts every layer belonging to that image, including ones shared with other images. Use `docker system df` for the honest number.
3. Why does the ORDER of instructions in a Dockerfile affect build speed?
Layers are cached in order. Change something near the top and everything below is rebuilt — which is why dependencies go before source code.
🔓 You're reading a free chapter of Docker — the first two are open.
Unlock the rest of this course with a one-time payment.
Unlock this course →
🔓 See course prices