MiniDock Build 34: Prove One Release and Parcel Flow End to End

Capstone: The Full Map

Design claim: A container engine remains understandable when each subsystem owns one contract and composes with the others through narrow interfaces.

The whole system is a chain of promises

One release and one parcel flow must cross build, distribution, runtime, storage, networking, orchestration, and operations without any subsystem becoming universal authority. Production evidence and authority cross every subsystem, so the completed design must preserve meaning at each seam rather than rely on a privileged center.

The tempting shortcut is straightforward: treat the engine as one daemon implementation detail or reason about each subsystem in isolation. The shortcut collapses distinct signals or controls into one convenient component and hides which promise failed. Centralized hidden ownership makes failure recovery and replacement impossible to reason about, while isolated subsystem knowledge misses the end-to-end invariants. Compromise or host loss shows why independent evidence, refusal, and recovery paths must remain visible.

Narrow waists keep the map composable

Read it top to bottom as a life story: intent enters at the CLI or a compose file; the daemon resolves names to content, content to mounted filesystems; the runtime chain turns a bundle into a kernel-isolated process; storage and networking plug in from the sides; observability taps every seam; and above it all, an orchestrator repeats one loop that keeps many machines honest.

The completed model connects content-addressed images, controlled distribution, lifecycle custody, pluggable storage and networking, reconciliation, security, and evidence through narrow waists. The mechanism composes narrow contracts: each subsystem owns its decision, exports evidence, and limits the authority granted across the seam.

Read the map end to end, but stop at every boundary to identify its owner, input, output, and refusal behavior.

  flowchart TB
    subgraph CP["control (P7)"]
      ORCH["orchestrator: observe→diff→act (L37)"]
      RAFT[("Raft state store (L36)")]
      ORCH --- RAFT
    end
    CLI["CLI / compose file (L1, L34)"] --> D["daemon (L1–3)"]
    ORCH --> D
    subgraph IMGS["images + distribution (P2–3)"]
      REG[("registry (L14–16)")]
      STORES[("ref · image · layer stores (L13)")]
      BLD["builder + cache (L10–12)"]
    end
    D --> BLD
    D <--> REG
    D --> STORES
    subgraph RT["runtime (P1, P4)"]
      MGR["manager → shim → OCI runtime (L3)"]
      K["kernel: namespaces (L4) · cgroups (L5) · sandwich (L6)"]
      CTN["container: lifecycle (L18) · health (L24) · supervision (L21)"]
      MGR --> K --> CTN
    end
    D --> MGR
    STORES -- "overlay mounts (L9, L20)" --> RT
    subgraph SIDE["storage + network (P5–6)"]
      VOL[("volumes (L25–27)")]
      NET["CNM: bridge · ports · DNS · overlay (L28–33)"]
    end
    VOL --> CTN
    NET --> CTN
    OBS["events · logs · metrics (L38)"]
    D -.-> OBS
    CTN -.-> OBS
    SEC["hardening wraps every seam (L39)"]
    style SEC fill:#f0faf2,stroke:#1f7a34
      

It assembles control, image, distribution, runtime, storage, networking, observability, and security relationships into one map. Its central claim is that end-to-end correctness is the composition of explicit subsystem invariants, not the presence of one all-knowing component; the labels therefore describe authority rather than decorative grouping.

Trace one release from intent to service

Forty lessons compress to five principles you can reuse on any system: narrow waists (the bundle, the driver seams, the registry API — small interfaces that decouple worlds); content addressing (names that can't lie make caching, dedup, and trust one mechanism); lifecycle as state machine (events move the needle; reality outranks intent); declarative convergence (diff desired against actual, forever); and layered defense (independent walls, so one failure isn't the story). Docker is one arrangement of these; you now own the pieces to arrange your own.

Intent enters through a client, resolves to verified content, becomes mounted and isolated process state, joins durable and network resources, and is continually observed and reconciled. A successful path is convincing only when the same ownership map explains interruption and recovery.

Recovery belongs to the same owners as normal work

A host disappears during a release while clients still send parcels, so authority, content, durable data, replacement tasks, and evidence must each recover through their own contract. The boundary test should activate several independent controls without turning any one of them into universal authority.

End-to-end correctness is the composition of explicit subsystem invariants, not the presence of one all-knowing component. The final rule is compositional: system correctness comes from explicit local guarantees that continue to hold together.

Use the map as a reasoning tool

MiniDock is complete when a reviewer can trace one release and one parcel through every boundary and explain who owns recovery at each failure. MiniDock is complete when the whole ParcelFlow path can be explained from those contracts.