Production Capstone: Build, Secure, Publish, Operate, Observe, and Recover a Complete Dockerized Application: Requirements, Constraints, and Target Architecture

1. Capstone mission: prove the delivery system, not just the container

The final chapter integrates the course into one reviewable system. The target is a small HTTP application whose source is committed, whose base image is resolved to a digest, whose release is built once as a multi-platform image index, whose SBOM/provenance and signature are bound to the release digest, whose runtime is deployed by digest, whose state survives container replacement, and whose failure/restore behavior is measurable.

Success means another engineer can independently answer: what source produced these bytes, who/what built them, what software is inside, what identity is running, where state and secrets live, which ports and networks exist, how health/resource/log contracts are configured, what backup was restored, and which exact evidence proves each claim?

2. Constraints and excluded dependencies

3. Synthetic application

The app is deliberately small: Python standard library HTTP + SQLite, with no pip packages. GET /health reports process/data readiness, GET / returns the greeting and current counter, and authenticated POST /increment mutates the SQLite counter using a fake token mounted as a runtime secret. A marker file in the state volume can intentionally make health fail for the incident drill.

The container runs as numeric UID/GID 10001, uses a read-only root filesystem, writes only to /data and /tmp, drops all Linux capabilities, enables no-new-privileges, publishes only to loopback, rotates local logs, and has explicit CPU/memory/PID limits. A companion observer can reach the app only over an operations network and records health without receiving the app secret.

4. Target architecture and trust flow

flowchart TD
  S[Git source SHA + pinned base digest] --> B[Disposable Buildx / BuildKit builder]
  B --> I[Multi-platform image index digest]
  B --> A[SBOM + SLSA provenance]
  I --> R[127.0.0.1 local registry]
  A --> R
  R --> V[Scan + signature verification]
  V --> P[Release alias points to same digest]
  P --> C[Compose deploys immutable digest]
  C --> N[frontend + ops networks]
  C --> D[named data volume]
  C --> Q[config + fake runtime secret]
  C --> O[health + bounded logs + resources]
  D --> BK[backup checksum]
  C --> F[failure drills]
  BK --> RR[restore volume + recovery verification]
  RR --> H[handoff evidence packet]
            

The important causal boundary is that the registry digest is the release subject. SBOM, provenance, signature, deployment, rollback, scan results, and incident notes all point back to that immutable subject. A tag can help humans find it, but a tag is never the final identity.

5. Threat model

6. Recovery objectives

Set explicit learning objectives rather than invented enterprise guarantees. The lab target is RPO = backup point: writes after the archive timestamp may be lost. The target RTO is measured, not promised: start a timer before restore-volume creation and stop it only after the recovered app returns the expected persisted counter from the same release digest. Record host and workload conditions so the timing is not presented as universal.

7. Requirements-to-evidence matrix

8. Version and platform freeze

Before implementation, capture actual local versions. The course reference baseline is Engine 29.8.1, BuildKit 0.33.0, Buildx 0.37.1, Compose 5.5.1, Trivy 0.74.0, and Cosign 3.1.3. Do not silently substitute these for what your machine runs.

mkdir -p evidence
{
  date -u +%Y-%m-%dT%H:%M:%SZ
  docker context show
  docker version
  docker info
  docker compose version
  docker buildx version
  trivy --version 2>/dev/null || true
  cosign version 2>/dev/null || true
} > evidence/toolchain.txt

9. Clean-room object namespace

All generated Docker state uses the ch42 prefix or Compose project ch42cap. The registry is 127.0.0.1:5000, the Buildx builder is ch42-builder, registry storage is ch42_registry_data, application state is ch42cap_state, and restore state is ch42_state_restore. This is not cosmetic: cleanup and incident commands can select exact identities.

10. Production boundaries not simulated away

This lab does not claim to provide HA scheduling, external TLS, managed KMS/HSM signing, centralized log/metric retention, multi-node databases, enterprise identity, admission control, or cross-region backups. The handoff must name those gaps and map them to Kubernetes/Helm/OpenShift, an external secret manager, a managed/HA registry, a real observability platform, and production backup infrastructure where appropriate.

11. Go/no-go gate before implementation

12. What Lesson 1 freezes

The architecture, evidence matrix, threat assumptions, RPO/RTO interpretation, object namespace, and excluded production dependencies now exist before any release is built. Lesson 2 implements this contract and captures evidence after every major transition rather than reconstructing history at the end.

Knowledge check

Official references and version notes

• Docker Engine 29 release notes — current Engine 29.8.1 behavior, fixes, known issues, and component changes.
• Docker Docs — Multi-platform builds — image indexes, native/emulated/cross-compilation strategies, and platform verification.
• Docker Docs — Build attestations — BuildKit SBOM and provenance metadata and image-store/registry requirements.
• Docker Docs — SBOM attestations — SPDX SBOM creation and inspection with Buildx imagetools.
• Docker Docs — Provenance attestations — SLSA provenance modes and inspection.
• docker buildx imagetools inspect — digest, platform, SBOM, and provenance inspection.
• Docker Docs — Use Compose in production — single-host production guidance and production-specific overrides.
• Docker Docs — Use secrets in Compose — runtime secret files and scope; local Compose secrets are not a substitute for an external encrypted secret manager.
• Docker Docs — Volumes — persistent data lifecycle, backup patterns, and container replacement semantics.
• Docker Docs — Resource constraints — CPU, memory, and runtime governance.
• Docker Docs — Configure logging drivers — bounded log retention and driver tradeoffs.
• Docker Docs — Seccomp security profiles — default syscall filtering and safer customization guidance.
• Docker Docs — Rootless mode — threat reduction and operational limits.
• dockerd reference — local registry trust behavior; 127.0.0.0/8 local registries are treated as insecure for testing, but production registries should use trusted TLS.
• Trivy releases — free local vulnerability scanner version identity used in the capstone.
• Cosign releases — signature tooling version identity used in the capstone.
• Open Container Initiative — image/runtime/distribution specifications underlying Docker artifact and runtime interoperability.