docker

Docker, containers as a system

Past 'write a Dockerfile' into how images, namespaces, BuildKit and registries actually work — and how containers behave in production.

10 units·34 lessons·~9 h

Start track →

Images and layers

An image is content-addressed, stacked, read-only filesystem layers plus a config — not a tarball of a running machine.

01 What an image actually is: a config plus a stack of content-addressed layers, not a machine snapshot 15 min 02 Layers and content-addressing: diff_id vs descriptor digest, chain_id, and the gzip non-determinism trap 16 min 03 The OCI image spec: index, manifest, config and layers as a Merkle DAG of descriptors 16 min 04 Dockerfile mechanics: which instructions become layers, how the cache keys each step, and why order matters 17 min

Runtime internals

A container is a normal Linux process fenced by namespaces and cgroups — isolation, not virtualization.

01 Namespaces: the kernel view a container is allowed to see 16 min 02 Cgroups: the resource budget the kernel actually enforces 17 min 03 Capabilities and seccomp: why container root is a declawed root 17 min 04 The container lifecycle: from docker run to a reaped exit 16 min

Container networking

Container networking is network namespaces wired through a bridge, with NAT and an embedded DNS doing the rest.

01 Network namespaces and bridges: what 'docker run' actually wires up 16 min 02 Publishing ports and the embedded DNS: DNAT, bind addresses, and 127.0.0.11 17 min 03 Container-to-container: same host, cross host, and the overlay illusion 16 min

Storage and volumes

The writable layer is ephemeral copy-on-write; durable state lives in volumes, not the container.

01 The writable layer: copy-on-write, the upperdir, and why container state evaporates 16 min 02 Volumes, bind mounts, and tmpfs: three ways to escape the writable layer 17 min 03 Storage drivers: overlay2, copy-up granularity, and the inode trap 16 min

BuildKit and cache

BuildKit turns a Dockerfile into a parallel, content-addressed build graph — cache hits are about digests, not line numbers.

01 BuildKit as a build graph: LLB, content-addressed cache keys, and why a build is a DAG not a script 16 min 02 Multi-stage builds: a fat builder, a thin runtime, and how COPY --from collapses 1.2 GB into 28 MB 16 min 03 Cache mounts and build secrets: --mount=type=cache keeps downloads warm, --mount=type=secret keeps tokens out of layers 16 min 04 Reproducible builds: SOURCE_DATE_EPOCH, digest-pinned bases, and why a churning layer digest breaks signing 16 min

Compose and local dev

Compose declares a multi-container topology so a local environment is a file, not a wiki page of commands.

01 The Compose model: a project, a network, and services that find each other by name 16 min 02 Startup order is not readiness: depends_on, healthchecks, and restart policies 17 min 03 The dev loop: overrides, watch/sync, profiles, and not drifting from prod 17 min

Container security

Default containers run too privileged; rootless, dropped capabilities, scanning and signed supply chains close the gap.

01 Rootless Docker and user namespaces: why container root is host root, and how to break the link 16 min 02 Image scanning: why a fat base ships a CVE backlog, and what Trivy and Grype actually measure 15 min 03 Secrets and the supply chain: keeping secrets out of layers, and signing images so they cannot be swapped 17 min

Registries and distribution

A registry is a content-addressed blob store behind a pull/push protocol; tags move, digests do not.

01 The registry pull/push protocol: manifests, blobs, and content-addressed distribution 16 min 02 Tags move, digests do not: pinning and signing for a verifiable supply chain 17 min 03 Pull-through caches and mirrors: surviving rate limits without serving stale images 15 min

Debugging containers

You debug a container by joining its namespaces — exec, inspect, logs and events expose what a black box is doing.

01 docker exec and inspect: joining a container's namespaces and reading the engine's ground truth 16 min 02 docker logs and events: the rotation that eats your evidence and the daemon stream that kept it 16 min 03 Debugging distroless: no shell, no exec — bringing your own tools into another container's namespaces 17 min

Production patterns

Production containers are about bounded resources, honest health, slim images and a graceful lifecycle under an orchestrator.

01 Resource limits and OOM: cgroup ceilings, exit 137, and runtimes that ignore them 16 min 02 Health and lifecycle: honest probes, the SIGTERM grace window, and preStop 16 min 03 Image slimming: multi-stage, distroless, and layers that pull in seconds 16 min 04 Capstone: a mini-PaaS — registry, build, run, health, and zero-downtime rollout 18 min

Build with this track

Guided projects that exercise what you learn here.

◆ Projects

Homelab Secure Stack

Stand up a self-hosted media and home-server stack on nas01.example where five services share a single VPN container's network namespace — the kill-switch drops all traffic the moment the tunnel dies, a split-tunnel whitelist carves out LAN access, and three layered access rings (localhost / LAN 10.0.0.0/24 / mesh-VPN 100.64.0.30) keep the right doors open to the right people. Harden the host with SSH key-only auth, fail2ban, and unattended security upgrades; write a rotating, age-encrypted off-site backup; and walk away knowing the stack stays dark if anything breaks.

◆ Projects

Three-Tier App on AWS, by IaC

Stand up a real three-tier system on AWS — a load balancer in front, a compute tier in the middle, a managed Postgres behind it, and S3 for objects — entirely from code you can re-run. The point isn't to click through a console once; it's to express the whole topology, its IAM, and its network boundaries as Terraform (or CDK) you could hand to a teammate, destroy, and recreate byte-for-byte. This is the project where 'infrastructure' stops being a pile of consoles and becomes a reviewable artifact.

Next track

Security Foundations

The cross-cutting base every engineer needs to reason about security: threat modeling, cryptography you can actually use, identity, network security, and access-control models.