04.04 · Concept
Images and Reproducibility
Explain layered images and what makes a build deterministic or not.
No video curated for this lesson yet
This lesson is written, ordered and part of the path - the video slot is the only thing still open. We are working through Deployment lesson by lesson; 29 of 56 have their video so far.
The written notes below cover this idea in full - you lose nothing by reading instead of watching.
Container images are immutable layer stacks, but builds are only repeatable when every input is fixed: base image digest, dependencies, build arguments, tools and metadata. Mutable tags, network package indexes, unpinned installs, timestamps and broad cache invalidation can make the same source produce different image digests and runtime behaviour.
What this lesson answers
- how do container image layers work
- why are Docker image tags not reproducible
- what makes a Docker build deterministic
Notes
Images and Reproducibility — Container images exist to package an application, filesystem, and metadata into repeatable layers; without reproducible images, the same source code can produce different runtime behavior, failed rollbacks, or untraceable production bugs.
Key Concepts: - A container image is a stack of immutable layers, where each Dockerfile instruction such as `RUN apt-get install curl` creates a new content-addressed layer. - Image layers are identified by cryptographic digests such as `sha256:3b1c...`, not just human-readable tags like `node:20`.
References
Common questions
- Why should I pin a container image by digest?
- A tag is a name that can be moved to another image later. A digest identifies one exact image by its content. Pinning by digest means every deploy, rollback and replica uses the same artifact, rather than whatever the registry currently serves for a mutable tag.
- What commonly makes a Docker build non-deterministic?
- Non-determinism usually comes from inputs that change outside the source tree: package indexes, floating base image tags, unpinned dependency ranges, network downloads, generated timestamps and random identifiers. If those inputs are not fixed, the same commit can produce a different filesystem or metadata on another build.
- How does layer caching affect reproducible image builds?
- Layer caching reuses a previous layer only when the instruction and the layer before it match. If you copy the whole repository before installing dependencies, an unrelated file change can invalidate the dependency layer and force a fresh install, increasing both build time and the chance of changed output.
Short definition: what is Images and Reproducibility?