Container Image
A layered, content-addressed filesystem bundle plus metadata, from which containers are instantiated — immutable by construction and identified by digest.
The properties that make containers useful in architecture are properties of the image rather than of the runtime.
Immutability. An image cannot be changed; a new build produces a new image. This is what makes deployments reproducible and rollback trivial — you run the previous digest, and it is byte-identical to what ran before.
Layering and content addressing. Each instruction produces a layer identified by its content hash, so unchanged layers are reused and not retransferred. Ordering the build so that rarely-changed things (base image, system packages, dependencies) come before frequently-changed things (application code) is what makes builds and pulls fast; getting it backwards invalidates the cache on every commit.
Digest versus tag. A tag is a mutable pointer — :latest and even :v1.2.3 can be repointed at
different content. A digest (sha256:…) identifies exact bytes. Deploying by tag means you cannot
be certain what ran; deploying by digest means you can, which matters for both rollback and supply
chain provenance.
The size discipline is worth keeping: a smaller image pulls faster, starts faster and has less to scan for vulnerabilities. Multi-stage builds and minimal or distroless base images typically reduce a 1 GB image to tens of megabytes, removing an entire class of CVEs along with the shell.