Theory: Registry and image lifecycle

This reading frames what happens after a Dockerfile exists: how images move between machines and how that affects security decisions.

End-to-end flow

A typical loop is: build on a developer laptop or in CI, tag with a repository name and label, push to a registry, then pull on a server or another pipeline stage and run. Promotion often means only certain tags or digests may reach production pull credentials.

flowchart TB
    DEV["Developer or CI"] -->|"docker build"| LOC["Local image"]
    LOC -->|"docker tag"| TAG["Named image (repo:tag)"]
    TAG -->|"docker push"| REG[("Registry")]
    REG -->|"docker pull"| RUNNER["Host / orchestrator"]
    RUNNER -->|"schedule / run"| POD["Running workload"]

Build output

A successful build produces an image identified by a repository name and a tag. The tag is a mutable pointer. The same tag name can later point at a different set of layers. For audit trails, teams record the digest (sha256:...) because it identifies an exact snapshot and never changes.

Publish and consume

Push uploads a local image to a registry. Pull downloads it to another host. Registries sit on the trust path: whoever controls the registry and the push credentials can affect what runs downstream. A common split is read-only pull access for servers and a separate push role for CI pipelines.

Promotion

Many pipelines use dev, staging, and prod tags or separate repositories. Promotion means moving a tested image into an environment that production is allowed to pull. Scanning is usually part of promotion, not only the first build.

Pulling at runtime

Whatever runs your containers resolves an image reference, pulls if needed, then starts the workload. Mature setups add image signing and controls on which registries are trusted.

Next: Lab: Slim Python images.