skip to content

Registries & Distribution

Moving an image between a build and a runtime: the push and pull exchange, credentials in ~/.docker/config.json, tag versus digest addressing, and signing. Asked because every deploy starts with a pull that must be authenticated, fast and reproducible.

part ofDockeroverview, primer and where to startread it →
on this pageshow

questions

page 2 of 2

Using `docker buildx imagetools inspect`, how do you read an image's provenance and SBOM attestations?

level: middleimportance: nice to knowfreq 32%

basics

~10 s

docker buildx imagetools inspect <ref> --format '{{ json .Provenance }}' and the same with .SBOM decode the attestation payloads straight from the registry. --raw prints the underlying index JSON. No local pull is needed.

open as a page

What does setting the environment variable `DOCKER_CONTENT_TRUST=1` actually change about `docker push` and `docker pull`, how does the key hierarchy behind it work, and why have most teams moved to something else?

level: middleimportance: nice to knowfreq 26%

basics

~20 s

It turns on Docker Content Trust: pushes get signed via a Notary server and pulls or FROM references refuse unsigned or unverified tags. It uses TUF roles — an offline root key, a per-repository targets key, plus server-held snapshot and timestamp keys. Teams moved on because it is tag-scoped, Docker-client-only and painful to operate.

open as a page

Why tag a container image with the short git commit SHA rather than an incrementing build number?

level: middleimportance: nice to knowfreq 34%

basics

~20 s

A commit SHA ties the image to the source that produced it, needs no shared counter, and stays unique across branches and parallel builds. Its weakness is that SHAs carry no order, so many teams combine a build number with the SHA.

open as a page

What do lazy-pull container image formats such as eStargz and SOCI change about container start-up?

level: seniorimportance: nice to knowfreq 17%

basics

~20 s

They make image layers seekable, so a container starts before its image has finished transferring and file content is fetched on demand. Both need a containerd snapshotter on the node, and they trade a faster start for a live registry dependency while running.

open as a page

How would you query a registry's HTTP API v2 directly with curl to see which manifest a tag currently resolves to and whether a given layer blob exists, and when is doing that worth the trouble?

level: seniorimportance: nice to knowfreq 26%

basics

~20 s

Get a bearer token, then GET /v2/<repo>/manifests/<tag> with an Accept header listing acceptable manifest media types — the response body plus the Docker-Content-Digest header give you the manifest and digest. HEAD /v2/<repo>/blobs/<digest> reports whether a blob exists.

open as a page

When a container image supports several CPU architectures, what does its tag actually point at, and how does that change which sha256 digest you should record when pinning?

level: seniorimportance: nice to knowfreq 30%

basics

~20 s

The tag points at an image index (manifest list) — a small document listing one manifest digest per platform. Pin the index digest: it stays immutable while still resolving per architecture. A per-platform manifest digest also works but hard-codes one CPU architecture.

open as a page

Design the image supply strategy for an air-gapped environment: build agents and runtime hosts on a network with no route to the public internet still need upstream container images, kept reasonably current. What is your approach and what are the tradeoffs?

level: principalimportance: nice to knowfreq 26%

basics

~20 s

Run an internal registry as the single source of truth. On a connected staging host, copy an explicit, digest-pinned allowlist of images with a tool like skopeo or crane, transfer them across the boundary (registry-to-registry sync or tarball), and re-tag them into the internal registry. Rewrite all references internally; schedule refreshes.

open as a page

showing 31–37 of 37