Image

Definition

A Moby image is an OCI image: a manifest pointing to a config blob plus an ordered list of layer descriptors. The repo carries two implementations of the image concept:

• Modern (containerd-backed): image records and content live in containerd's content + image stores. Code: daemon/containerd/.
• Legacy: image config JSON in daemon/internal/image/, layer chain in daemon/internal/layer/, references (tags) in daemon/internal/refstore/.

Both are accessed through the ImageService interface declared in daemon/image_service.go.

Wire types

api/types/image/ holds the API representations:

Type	Purpose
Summary	Row in docker images.
Image (InspectResponse)	Detailed inspect payload.
History	One entry of the build history.
LoadResponse, SaveOptions	docker save/load.
Manifest	Multi-platform manifest list.
PullOptions, PushOptions, PruneOptions, ListOptions, ...	API option structs.

Internal types

In the legacy store, the central type is image.Image (daemon/internal/image/image.go) — the parsed config JSON augmented with derived fields like RootFS.DiffIDs and OS. The store (daemon/internal/image/store.go) is content-addressed: image IDs are SHA-256 of the config JSON.

In the containerd store, images are just rows in containerd's image table; chain/diff IDs live on the manifest descriptors.

Reference resolution

github.com/distribution/reference parses references (registry/repo:tag@digest). Both stores use it for normalization. Tags are resolved through:

• Legacy: daemon/internal/refstore/, persisted as JSON in <data-root>/image/<driver>/repositories.json.
• containerd: containerd's own image table.

Identity cache

The containerd path caches resolved chain IDs in daemon/containerd/identitycache/. Building this cache up front avoids repeated layer scans when the daemon lists images or computes disk usage.

Manifests and platforms

Images can be multi-platform manifest lists. The daemon picks a manifest matching the host platform when running, and exposes the full list in docker manifest inspect-style flows. Helpers live in daemon/internal/platform/.

See also

• Image management for the picker and lifecycle.
• Distribution for the legacy registry client.
• Layer for the legacy layer chain.