Anatomy of an Image

In one sentence: An image is not one file but a small tree of them — a manifest that points to one config and an ordered list of layer archives — held together by cryptographic digests.

Three kinds of file

Unpack any image and you find exactly three kinds of object. The manifest is a small JSON index: "this image = this config + these layers, in this order." The config holds everything needed to run: default command, environment, working directory, exposed ports. The layers are tar archives of filesystem changes — layer 1 might be a base OS, layer 2 your runtime, layer 3 your app. Splitting run-metadata (config) from file-content (layers) is the key move: two images can share every layer yet run different commands.

flowchart LR
  TAG["tag: myapp:1.0"] --> M["manifest (JSON)
the index"]
  M -- "1 ×" --> CFG["config (JSON)
cmd, env, ports, workdir"]
  M -- "ordered list" --> L1["layer 1 (tar)
base OS files"]
  M --> L2["layer 2 (tar)
language runtime"]
  M --> L3["layer 3 (tar)
your app files"]
  style M fill:#eaf1fe,stroke:#1d63ed
    

Resolving a name to bytes

When the engine needs image myapp:1.0, it never trusts the name — it walks the tree. Tag → manifest digest, manifest → config and layer digests, digests → blobs on disk. Every arrow is a hash lookup, which Lesson 8 turns into a superpower:

sequenceDiagram
  participant E as Engine
  participant RS as Reference store (tags)
  participant BS as Blob store
  E->>RS: what is myapp:1.0?
  RS-->>E: manifest digest sha256:ab12…
  E->>BS: fetch blob ab12… (the manifest)
  BS-->>E: manifest JSON
  E->>BS: fetch config blob + each layer blob it lists
  BS-->>E: config + layers
  note over E: image fully resolved —
ready to become a rootfs (Lesson 9)