Images and layers

In the last lecture, an image was a “template” for containers. This lecture opens it up. An image is not one big file — it is a stack of layers, and understanding them is the key to fast builds, small images and fewer surprises in production.

A Dockerfile, line by line

Images are built from a recipe called a Dockerfile. Here is a typical one for a Python web service:

# Start from a small official base image
FROM python:3.12-slim
# Working directory inside the image
WORKDIR /app
# Copy only the dependency list, then install dependencies
COPY requirements.txt .
RUN pip install -r requirements.txt
# Then copy the application source
COPY . .
# Default command when a container starts
CMD ["python", "app.py"]

Note that Dockerfile comments must be on their own line — a # after an instruction is treated as part of it.

docker build -t shop-web:1.4.2 .

Each instruction that changes the file system — FROM, COPY, RUN — produces a new layer containing just the files it added or changed. WORKDIR and CMD only record settings.

A container sees all the layers merged into one file system. Explore an image built from a slightly careless version of this Dockerfile — one that copied a .env file and then deleted it:

Layers and the build cache

Layers are content-addressed and cached. When you build again, Docker walks through the instructions and reuses a cached layer as long as nothing it depends on has changed. At the first instruction whose inputs changed — a different file copied, a different command — the cache is broken, and that instruction and every one after it runs again.

That makes the order of instructions decisive. Compare two Dockerfiles below: build once, then simulate editing app.py and rebuild.

With dependencies installed first, a code change rebuilds only the final copy step — seconds. Copy the source first, and every code change reinstalls all dependencies — minutes on every build, multiplied across every developer and every CI run.

Keeping images small and safe

Image size affects how fast deployments roll out, how much storage and bandwidth you pay for, and how many vulnerabilities you ship. A few habits go a long way:

Slim base images

Start from minimal variants such as -slim or distroless images instead of full operating-system images.

.dockerignore

Exclude .git, local environments, test data and build output from the build context, so COPY . . stays small and doesn’t leak files.

Multi-stage builds

Compile or bundle in a builder stage with all the tools, then copy only the finished artefact into a small runtime stage.

Pinned versions

Tag images with explicit versions (shop-web:1.4.2) or digests, never just latest, so a deployment is reproducible.

Non-root user

Add a USER instruction so the application doesn’t run as root inside the container.

# Multi-stage build for a Go service
FROM golang:1.23 AS build
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o /out/api ./cmd/api

FROM gcr.io/distroless/static-debian12
COPY --from=build /out/api /api
USER nonroot
ENTRYPOINT ["/api"]

The final image contains a single binary and almost nothing else — often only a few tens of megabytes.

Pinning matters more than it looks. Here is what can happen to a Deployment that uses latest:

An image is a static artefact. Next, we run containers and connect them — to users, to each other and to storage that outlives them.