Docker & Containers · Self-assessment
Knowledge checks
Every knowledge check in this course, in curriculum order. Each link opens the page at its quiz. The questions are auto-graded in the browser and nothing is recorded — a wrong answer costs you only the explanation, which is the part worth reading.
- Knowledge checks
- 242
- Parts covered
- 38
- Of all lessons
- 100%
Part I
Foundations
6 checks
- Welcome to Docker & Containers for Production SysadminsWhat this course assumes, what Docker changes about a Linux host you are responsible for, and how to read the rest of it.→
- Containers vs virtual machinesDistinguish a container from a VM at every layer of the stack.→
- The OCI ecosystemruntime-spec, image-spec, distribution-spec — where each one stops, what lives in the gaps between them, and why media types decide whether your push succeeds.→
- Docker architecture at a glanceCLI, daemon, containerd, shim, runc — who does what, which process holds which state, and what each one taking a restart actually costs you.→
- What production-readiness means hereThe lens that distinguishes this course from a Docker quickstart — with the checks that turn each principle into something a host can fail.→
- The Linux primitives behind a containerThe five kernel features Docker arranges, and how to see each one on a running container.→
Part II
Linux Internals
8 checks
- Linux namespaces — the foundation of every containerPID, mount, network, UTS, IPC, user — the kernel features that make isolation possible.→
- cgroups v2 — the resource side of container isolationThe unified cgroup hierarchy that limits CPU, memory, I/O, PIDs for every container.→
- OverlayFS — the filesystem underneath every containerHow Docker composes container filesystems from image layers.→
- Linux capabilities — fine-grained rootWhy containers do not need full root, and how to drop most capabilities safely.→
- Processes, signals, and PID 1Why the init process of a container is special, and what happens when you ignore SIGTERM.→
- Seccomp and AppArmor — restricting what a container can doBeyond capabilities: syscall filters and mandatory access control for containers.→
- User namespaces and rootless DockerWhy UID 0 inside the container is not UID 0 on the host.→
- Container startup from CLI to running processEnd-to-end trace of `docker run nginx`: every daemon, runtime, kernel call, and side effect.→
Part III
Installation & Daemon
7 checks
- Supported installation methodsDocker Engine from the official repository, from distro packages, from binaries, rootless, and Desktop — what each one commits you to at upgrade time.→
- Repository setup and version pinningAdding the Docker repository correctly, pinning docker-ce across a fleet, and what an unpinned engine actually costs when something breaks.→
- Docker Engine, containerd, runc — what is in the packageFive packages, four binaries in the call chain, and one of them is not running right now — which is the fact that makes container troubleshooting make sense.→
- systemd integration — managing dockerd as a unitHow systemd supervises dockerd, containerd and the shims, why the cgroup drivers must match, and what a start-rate-limited daemon looks like.→
- daemon.json — every production-relevant keyThe centralised configuration for dockerd, which keys reload on SIGHUP, which need a restart, and how a one-character edit takes a host down.→
- Log drivers at the daemon leveljson-file, journald, syslog and the remote drivers — which ones docker logs can read, why the default fills disks, and how blocking mode hangs your application.→
- Live restore — surviving daemon restartsWhat live-restore actually keeps alive, the four documented cases where it does not, and how to prove it worked.→
Part IV
Images
6 checks
- Layers and the copy-on-write filesystemWhat an image actually is, and how containers are born from it.→
- Manifests, digests, and content addressingThe three different hashes people all call "the image digest", what each one covers, and why a tag is not a reference you can trust.→
- Tags — mutable references to digestsWhat a tag actually is to the daemon, the four separate ways `latest` bites in production, and how to detect tag drift across a fleet.→
- Multi-platform imagesThe image index, the three ways to build for an architecture you are not on, and why the client picks the platform rather than the registry.→
- Inspecting an imagedocker image inspect, docker history and dive — which question each one answers, and why a deleted file still costs you 400 MB.→
- Image lifecycle — pull, tag, push, prune, retainHow images move between registries and hosts, what "unused" really means to prune, and the maintenance window that deletes the image you need to roll back to.→
Part V
Dockerfiles & BuildKit
8 checks
- Dockerfile instructions — every operator-relevant instructionFROM, RUN, COPY, ADD, USER, ENTRYPOINT, CMD — operational implications of each.→
- BuildKit — the modern builderWhat BuildKit is, where it actually runs, why the driver you choose changes where your image ends up, and how the syntax directive upgrades the builder without upgrading Docker.→
- Build caching — when it hits and when it does notWhat BuildKit actually hashes for each instruction, why COPY . . before RUN npm ci destroys the cache, and the cache-mount concurrency trap.→
- Multi-stage builds — separating build from runtimeHow to ship a tiny runtime image while keeping a fat build image — and where the build stage actually goes when it is not in the final image.→
- Build secrets and SSH mountsHow to handle credentials during builds without baking them into layers — and why a secret passed as ARG is in the image history for as long as the image exists.→
- Reproducibility — pinned bases, deterministic layersWhat SOURCE_DATE_EPOCH actually rewrites, what it does not, and where the honest ceiling on reproducible container builds sits.→
- Minimal images — distroless, scratch, and when to use whichChoose the smallest base that runs your workload — and know what you gave up when the container will not start and there is no shell to ask.→
- Secure image constructionBake security into the image: non-root, no secrets, scan-friendly defaults, and attestations attached to the digest you actually deploy.→
Part VI
Container Lifecycle
6 checks
- Container lifecycle, signals, and graceful shutdownHow containers start, run, stop, and react to signals — the operational foundation of every Docker lesson that follows.→
- create and start — the two-phase lifecycle and what is immutableWhy docker run is two operations, what is frozen at create time, and why changing a container means replacing it.→
- exec and attach — working inside a running containerHow docker exec joins a running container, why it is not PID 1, and why every change you make with it is temporary.→
- stop, kill, and pause — the three ways to interrupt a containerThe full stop path, which timeout wins, what STOPSIGNAL changes, and why pause is not a lightweight stop.→
- Container states, exit codes, and the event streamThe seven states a container can be in, what its exit code is telling you, and how to watch transitions as they happen.→
- Removing and recreating containers — what removal destroysWhat docker rm actually deletes, what survives it, and why --rm is the flag that costs you the post-mortem.→
Part VII
Networking
8 checks
- Docker networking primitives — namespaces, veth, bridgesHow packets actually move from the host to a container.→
- Bridge networks — the default and how to use them wellHow user-defined bridges differ from the default and why you almost always want user-defined.→
- Host networking — when to break out of isolationWhat --network host actually removes, the port conflict it guarantees, and the two subsystems that stop behaving.→
- macvlan and ipvlan — when you need L2 adjacencyPut containers directly on the LAN, and learn the kernel restriction that will surprise you an hour later.→
- DNS and the embedded resolverWhy container name resolution works on one network and not on another, and how to configure it without inventing options.→
- Published ports and the userland proxyWhat docker-proxy is still for, what pure DNAT does instead, and why the container sees the wrong source IP.→
- Network troubleshooting — packet flow and toolsDiagnose "container cannot be reached" with the right tools, in the right order.→
- The none network driver — when to disconnect a containerA container with a network namespace and nothing in it, and what that is genuinely worth.→
Part VIII
Storage
7 checks
- Storage drivers — overlay2 and what the others are forHow the storage driver composes image layers and container writables, what overlay2 writes under /var/lib/docker, and why Engine 29 stopped saying "overlay2".→
- Volumes — named, anonymous, lifecycleHow persistent storage works in Docker, what happens to the image content underneath a mount point, and why a volume is the one object whose deletion loses data forever.→
- Bind mounts — host paths in containersWhen and how to use bind mounts, why they silently shadow whatever the image had at that path, and how a typo in the source path becomes an empty directory instead of an error.→
- tmpfs mounts — ephemeral, fast storageWhen tmpfs is the right choice, why an unsized tmpfs will OOM-kill the container that owns it, and why "never touches disk" is only true if you turned off swap.→
- Permissions and ownership — the UID/GID trapWhy containers fail with Permission denied on a mounted directory, why the kernel never sees your usernames, and why chown -R on the host is the wrong reflex.→
- Network and shared storage — NFS, CIFS, Ceph, iSCSIHow the local volume driver reaches a network filesystem, which options are real, and why two containers on one database file over NFS is the classic silent-corruption incident.→
- Storage performance — overlay2, drivers, and tuningWhy containers sometimes feel slow: what copy-up actually costs when a container rewrites a large file, how to measure per-container I/O from cgroup v2, and which host tuning is already done for you.→
Part IX
Docker Compose
7 checks
- Compose v2 architecture — the plugin, the project modelHow Compose v2 finds a project, how the project name is derived, and why two stacks can silently end up on the same network.→
- Services, networks, volumes — the three primitivesThe minimal Compose vocabulary, what each primitive becomes on the daemon, and how up decides which containers to replace.→
- Healthchecks in Compose — and what they do not doHow the daemon runs a healthcheck, what every field actually controls, and the three ways a healthcheck lies to you.→
- Dependencies and startup orderWhy depends_on alone races the database on every cold boot, what condition: service_healthy actually waits for, and how to verify the wait instead of hoping for it.→
- Secrets in ComposeWhat Compose secrets actually are — a read-only file mount, not a vault — and what that means for your threat model.→
- Profiles — optional services in one fileWhat a profile actually gates, why docker compose down leaves profiled services running, and where profiles are the wrong tool.→
- Production Compose patterns — what works at scaleThe deploy procedure, the replacement window Compose cannot hide, and the two commands that turn a redeploy into a data-loss event.→
Part X
Production Architecture
6 checks
- Docker host design — single host, multi host, edge casesLaying out a Docker host so that /var/lib/docker filling up is an alert rather than an outage, and the management plane survives the data plane.→
- Reverse proxy, TLS, and the edgeWhere TLS terminates, what that costs you in client identity, and how X-Forwarded-For turns into a spoofable header if you trust it wrongly.→
- Network segmentation and management accessSeparating the management plane from the data plane, and why the host firewall you wrote does not filter published container ports.→
- Capacity planning — CPU, RAM, disk, networkSizing a Docker host from measured working set, shared image layers and log growth, rather than from the sum of the limits you wrote down.→
- Operational boundaries — when Docker stops being the right toolThe technical boundary where single-host Compose runs out, the ownership boundary that decides who gets paged, and how to tell which one you have hit.→
- Where state lives — stateful services on a production Docker hostThe architecture decision that determines your backup, migration and failure domain.→
Part XI
Container & Host Security
6 checks
- Linux security modules — AppArmor and SELinux for containersWhere MAC fits in the container security stack and how to apply it.→
- User namespaces and rootless Docker (security perspective)Why user namespaces are the single largest security improvement available.→
- Read-only root filesystems and no-new-privilegesTwo of the cheapest, highest-impact container hardening options.→
- The Docker socket — the most dangerous API on the hostWhy mounting /var/run/docker.sock is almost equivalent to host root.→
- Privileged containers and the security boundaryWhen and why --privileged exists, and why you should never use it in production.→
- Device access and bind mount risksHow scoped permissions become host compromise.→
Part XII
Supply Chain
6 checks
- Image provenance — SLSA, attestations, and what they proveWhat BuildKit provenance records, what the SLSA build levels actually claim, and why self-attested provenance from a builder you control proves less than people think.→
- SBOM — software bill of materials for imagesGenerating an SBOM is the easy half. This is the other half: where it is stored, how it is queried, and why an unindexed SBOM answers no questions at all.→
- CVE scanning — Trivy, Grype, Docker ScoutWhat a scanner can and cannot see, why two scanners disagree about the same image, and how to gate a pipeline on findings you can actually act on.→
- Image signing — Cosign, Sigstore, and verificationWhat a signature actually attests, why keyless signing removes the key-management problem rather than the trust problem, and the verification that accepts anything.→
- Registry trust — pulling from who you think you areThe chain from DNS to bytes, which link each control actually protects, and why TLS authenticates the server rather than the image.→
- Supply-chain incident response — finding every affected image and containerAn advisory has landed. Where is it running, what did it touch, and how fast can you answer?→
Part XIII
Registries
6 checks
- Docker Hub — limits, namespaces, official imagesOperating within Docker Hub: how a pull is counted, why the rate limit is a CI outage rather than an inconvenience, and the pull-through cache that removes the dependency.→
- Private registries — Distribution, Harbor, GitLab, QuayChoosing and operating your own registry: what the storage backend actually holds, what breaks when it is unavailable, and the health check that distinguishes "up" from "serving".→
- Registry authentication — basic, token, OIDCHow registry authentication works, where the credential actually lands on disk, why base64 is not encryption, and how to rotate without an outage.→
- Immutable digests — why tags are not enoughWhat actually breaks when a mutable tag moves under a running fleet, how to pin by digest without losing multi-platform support, and how to detect a split fleet before a user reports it.→
- Retention policies — keeping your registry from filling the diskWhy deleting a tag frees nothing, how mark-and-sweep garbage collection can destroy an image that is being pushed, and the read-only window that prevents it.→
- Registry backup and restoreWhat a registry backup must contain — blobs and metadata, not one of them — the snapshot order that avoids dangling references, and a restore test that can actually fail.→
Part XIV
Secrets
6 checks
- Why environment variables are not secretsThe six places a secret in an environment variable ends up, each demonstrated, and what file-based delivery actually buys you.→
- Docker build secrets and runtime secretsBuildKit secret mounts, Compose secrets, and the three ways a secret that was correctly mounted still ends up in the image or on disk.→
- External secret managers — Vault, AWS SM, Doppler, InfisicalHow to choose a secret manager, the three ways it reaches a container, and the bootstrap credential nobody talks about.→
- Secret rotation — without breaking productionWhat rotation actually requires: the application must re-read the secret, or you must restart it. Everything else is a variation on that one fact.→
- A secret is already in the image — layer forensics and remediationFinding credentials baked into layers, and the only remediation that actually works.→
- Preventing the leak — build context hygiene and CI secret scanningWhat actually reaches your image, and how to make the pipeline refuse a credential.→
Part XV
Resource Controls
6 checks
- CPU shares, quotas, and pinningCPU resource controls for containers.→
- Memory limits and OOM behaviourHow memory limits interact with the OOM killer.→
- PIDs limit and process controlsWhy every container needs a process limit.→
- I/O controls and block device limitsBlock I/O bandwidth and IOPS limits for containers.→
- Noisy neighbours and how to prevent themThe discipline of resource limits on shared hosts.→
- Auditing resource limits — proving the limit you set is the limit in forceFour places a limit can be lost between the Compose file and the kernel, and the counters that settle it.→
Part XVI
Performance
6 checks
- Storage drivers and image layoutHow overlay2 composes image layers, what copy-up actually costs, the backing-filesystem requirement that silently corrupts data, and which drivers still exist.→
- Image size and the cost of layersExactly what image size buys and what it does not, the three different numbers all called size, and why deleting a file in a later layer makes the image bigger.→
- Linux performance tools for containersWhy top inside a container lies, how to scope host tools to one cgroup or one namespace, and which numbers are actually the container.→
- Container startup time — what dominates and how to measureDecomposing `docker run` into pull, extract, snapshot prepare, runc create and application init, then measuring each one instead of guessing.→
- eBPF — an introduction for container operatorsSandboxed kernel programs, what they let you observe about containers, and an honest account of the kernel versions and privileges they require.→
- Container network performance — the datapath and how to measure itWhere throughput and latency go on a Docker host, and how to attribute a loss to a hop.→
Part XVII
Logging
6 checks
- Stdout and stderr — the container logging contractWhy an application that writes to a file inside the container is invisible to the platform, how the two streams actually reach the daemon, and the buffering trap that makes a healthy container look silent.→
- Logging drivers — json-file, local, journald, and the remote onesThe complete driver list, what each costs, why a blocking driver with an unreachable endpoint can hang your application, and which drivers let you read logs back.→
- Log rotation and disk consumptionThe default json-file driver has no size limit at all. What that costs, where the files live, how to cap them, and why the cap does not apply to the containers you already have.→
- Central log collection — Fluent Bit, Vector, LokiThree collection topologies, the coupling each one creates, and the rotation race that silently drops lines before they ever reach the store.→
- Failure lab — unbounded logs fill the diskReproduce the outage on purpose, measure the growth rate, prove why rm does not free the space, and verify the fix with a check that can fail.→
- journald and syslog — container logs where the host already looksRouting container output into the host log pipeline, and the three ways it silently loses messages.→
Part XVIII
Monitoring
6 checks
- What to monitor — host, Docker, container, applicationWhich signal tells you which failure: restart counts, OOM kills, healthcheck transitions, pull failures and the four things inside /var/lib/docker that grow.→
- Prometheus + node_exporter + cAdvisor + GrafanaThe canonical Docker monitoring stack, with an annotated scrape config, the real metric names each exporter publishes, and the overlaps that make people scrape the same number three times.→
- What the daemon can tell you — stats, events, healthchecks, /metricsThe four signals Docker itself emits, what each is good for, and where each one stops.→
- Where the numbers come from — cgroup v2 metric sourcesThe kernel files behind docker stats and cAdvisor, and the three metrics almost nobody collects.→
- Alerting rules that page — and the ones that should notTurning container metrics into alerts with owners, thresholds and runbooks.→
- Blind spots — what the monitoring stack cannot seeShort-lived containers, shared failure domains, empty queries and the cost of the exporters themselves.→
Part XIX
Observability
6 checks
- Distributed tracing with OpenTelemetryThe span model, context propagation across container boundaries, and the two configuration mistakes that account for most "no traces are appearing" incidents on a Docker host.→
- End-to-end correlation — request IDs across signalsMinting an ID at the true edge, threading it through five containers, putting it in logs but never in a metric label, and the exemplar mechanism that connects a metric to a trace without destroying your cardinality.→
- The three pillars of observabilityMetrics, logs and traces — what each answers, what each is blind to, and an honest account of what each costs, including the cardinality maths that decides whether your Prometheus survives the next deploy.→
- Running the OpenTelemetry Collector on a Docker hostDeploying, configuring and verifying the collector that carries your telemetry.→
- Tempo — storing and querying tracesDeploying Grafana Tempo in Docker, and asking it useful questions with TraceQL.→
- Sampling — head, tail, and what you stop being able to seeCutting trace volume without cutting the traces you needed.→
Part XX
Health & Failure Detection
6 checks
- Health checks — what they can and cannot doThe false green, the state machine nobody reads, the arithmetic behind detection time, and the single largest misconception: an unhealthy container is not restarted by Docker.→
- Restart policies — no, always, unless-stopped, on-failureWhat each policy does on exit, on daemon restart and on host reboot, the exponential backoff nobody documents in runbooks, and why a restart policy is not a fix for an unhealthy container.→
- Dependency failures and cascading outagesHow one unavailable container becomes an outage in five: the three distinct connection failures Docker produces, the connection pool full of dead sockets, and the retry storm that keeps a recovering database down.→
- Healthcheck timing — the detection-latency budgetInterval, timeout, retries and start period, and the arithmetic that connects them to how fast you notice.→
- Reading health state — inspect, events, and acting on transitionsGetting the health signal out of the daemon and into something that reacts.→
- Failure lab — the container that stayed healthy through an outageA total service outage with every container green, and how to find the lie.→
Part XXI
Backup
6 checks
- Why `docker commit` is not a backupThe command captures the writable layer and explicitly excludes every mounted volume — which is exactly the data you were trying to protect. The restore looks like it worked.→
- Volume backups — tar, restic, BorgCopying a live volume gives you a smear, not a snapshot. What the three tools actually do, and why the tar of a running database restores cleanly in testing and fails in production.→
- Bind mount backups — preserving the host path layoutBind mounts are the part of a container that the container does not own. What tar preserves, what it silently drops, and why the restored application cannot read its own files.→
- Application-consistent backups — quiesce and snapshotThree ways to get a copy the database will actually open: stop it, ask it, or snapshot it atomically. The differences between them are the difference between a restore and a recovery.→
- Offsite copies and the 3-2-1 ruleThree copies stops being three copies the moment one credential can delete all of them. What "offsite" has to mean to survive ransomware, and how to prove your copies are actually independent.→
- Restore validation — the part most teams skipA backup that has never been restored is a hypothesis. This is the procedure that tests it, written so that the result can be FAIL — with the four checks that actually distinguish a restored database from an empty one.→
Part XXII
Disaster Recovery
6 checks
- Disaster recovery — the production host is goneThe honest inventory of what "host gone" means you must rebuild: engine, daemon.json, images, volumes, Compose files, secrets, TLS material, DNS. Most of it is not in any backup, because nobody ever decided it was data.→
- RPO and RTO — defining recovery objectivesTwo numbers that only mean something when they are derived from what the business loses per hour. Worked end to end for a single-host Docker deployment, including why the honest RTO is usually four times the committed one.→
- Backup strategy and restore testingTurning scattered backup commands into a strategy: classify what you hold, derive a schedule from RPO, and monitor the backup job itself — because a backup that stopped running six weeks ago produces no output at all.→
- What is actually stateful — and why /var/lib/docker is not the answerBuilding the inventory of things a rebuild cannot recreate, and the backup trap that looks like the easy option.→
- Rebuilding a host from images plus volume backupsThe executable version of the recovery procedure, and the ordering mistake that costs you the data.→
- DR exercises — levels, cadence and the findings they produceA green backup job is not a restore test, and a restore test is not a disaster recovery exercise.→
Part XXIII
High Availability
6 checks
- Standalone Docker limits — when one host is not enoughStandalone Docker has no failover. `restart: always` restarts a container on a host that is still alive and does exactly nothing when the host dies. Where the real ceiling is, and what each step past it costs.→
- External load balancing — HA without an orchestratorTwo Compose hosts behind a proxy is the cheapest real availability improvement available. The two things that decide whether it works are what the health check actually tests, and whether the proxy drains connections or cuts them.→
- Availability arithmetic — what a nine actually costsTurning "make it highly available" into a number you can check a design against.→
- What restart policies and healthchecks cannot recoverA failure taxonomy, the layer that catches each mode, and the ones nothing on this host catches.→
- Zero-downtime deploys without an orchestratorBlue/green with two Compose projects, a proxy, and a health-gated cutover.→
- Failover, VIPs, and split-brain across two hostsMoving an address between Docker hosts, and the failure mode two nodes cannot solve.→
Part XXIV
Reverse Proxies & TLS
6 checks
- nginx as a Docker reverse proxyA production nginx configuration in front of containers: upstream DNS that goes stale, passive-only health checking, the timeout arithmetic behind 502 and 504, and how to drain a backend on deploy.→
- HAProxy — TCP and HTTP load balancingThe proxy with a runtime API and real active health checks: check arithmetic, DNS-based container discovery, draining without a reload, and why the certificate has to be one concatenated file.→
- Traefik — container-native reverse proxyLabel-driven discovery, automatic ACME, and an honest account of what mounting the Docker socket into a proxy actually grants — including why `:ro` is not the mitigation people think it is.→
- Caddy — automatic HTTPS by defaultWhat "automatic" actually costs: the data volume that must survive `docker compose down`, forwarded headers that are ignored until you say otherwise, and a response timeout that is off by default.→
- Client IP through a proxy — X-Forwarded-For and the trust boundaryRecovering the real client address, and why believing the header is a security hole.→
- HTTP versions through a reverse proxy — 1.1, 2, 3 and WebSocket upgradesThe protocol is negotiated per hop, and the hop you forgot is HTTP/1.0.→
Part XXV
Certificates & PKI
6 checks
- TLS termination, ACME, and Let's EncryptWhere the certificate lives, how ACME proves you own the name, and the proxy rule that quietly breaks renewal.→
- Expired-certificate troubleshooting scenariosReproduce the outage on purpose, then work the incident: symptom, diagnosis, recovery, and the reason renewal stopped.→
- CA trust inside the container — works on the host, fails in the imageThe trust store is part of the image, and most base images barely have one.→
- Registry TLS — certs.d, private CAs, and the insecure escape hatchWhy docker pull fails with x509 when curl on the same host succeeds.→
- Protecting the daemon socket with mutual TLSThe Docker API is root on the host. Exposing it needs client certificates, not just encryption.→
- Delivering and rotating certificates into running containersThe renewal succeeded, the file on disk is new, and the service is still serving the old certificate.→
Part XXVI
DNS & Service Discovery
6 checks
- Embedded DNS — how service name resolution worksThe registry behind 127.0.0.11: what it knows, when it learns it, and what it will never tell you.→
- Custom DNS for service discoveryRunning CoreDNS beside Docker: the address problem, the port conflict, and the forwarding loop.→
- Building the resolver — where a container gets /etc/resolv.confThe precedence chain that decides which nameservers a container actually uses.→
- Search domains and ndots — the lookups you did not ask forWhy `api` becomes `api.corp.example.com` and answers with the wrong address.→
- Names, aliases, and what breaks when they changeThe five names a container answers to, and who keeps using the old one.→
- Resolver behaviour and timeouts — glibc, musl, and slow lookupsWhy the same image resolves differently on Alpine, and why a DNS outage looks like a thread-pool outage.→
Part XXVII
Firewalls
6 checks
- nftables and iptables — the host firewall in the Docker eraThe chains Docker creates, the chain your firewall writes to, and why they are not the same path.→
- Verifying actual network exposureWhy docker ps, ss and the firewall ruleset can all agree with each other and all be wrong.→
- Published ports bypass the host firewallWhy -p 5432:5432 is reachable from the internet on a host with ufw default deny incoming.→
- The DOCKER-USER chain, and making rules survive a rebootThe supported place to filter container traffic, and why the rule you added is gone after the next boot.→
- nftables hosts — which ruleset is actually in chargeiptables-nft, native nftables, and the two rulesets that each think they are the firewall.→
- Limiting exposure by designThe firewall rule you do not have to write is the port you never published.→
Part XXVIII
Maintenance
6 checks
- Where the disk went — reading `docker system df` correctlyThe four categories Docker accounts for, what ACTIVE and RECLAIMABLE really mean, and the three kinds of disk usage the command does not show you.→
- Prune semantics — exactly what each variant deletesThe precise scope of docker system prune, -a and --volumes, why -a is the most dangerous flag in routine Docker operations, and how to make a prune reversible.→
- Build cache maintenance — the quiet largest consumerWhy BuildKit cache grows without bound on a build host, how to measure it, and how to configure garbage collection so you never have to prune it by hand.→
- Image hygiene on the host — a retention policy you can defendDeciding which images a production host keeps, expressing that decision as labels and filters, and never deleting the one you need to roll back to.→
- Volume lifecycle — orphans, anonymous volumes, and safe reclamationWhere the 64-character volume names come from, how a host accumulates dozens of them, and how to tell an orphan from a database before you delete it.→
- A maintenance schedule you can actually leave runningTurning the prune commands into a systemd timer that reports before it deletes, alerts on thresholds, and refuses to touch the things that must stay manual.→
Part XXIX
Docker Upgrades
6 checks
- What actually moves in a Docker upgradeFive packages, four version numbers and one API negotiation. Knowing which component a change lives in tells you what the upgrade will disturb.→
- Change review — what to read before you touch the packagesTurning release notes and a deprecation list into a per-host statement of what will actually change, and validating the daemon config against the new version before it runs.→
- Pre-upgrade capture — what to save and what it is actually worthThe five artefacts that let you rebuild a Docker host after a failed upgrade, and an honest assessment of what copying /var/lib/docker does and does not buy you.→
- The in-place daemon upgrade — what happens to running containersWhy the package postinstall restarts the daemon whether you wanted it to or not, what live restore does and does not carry across, and the exact command sequence for an upgrade with a known blast radius.→
- Rollback — putting Docker back the way it wasDowngrading the packages, why some state does not come back with them, and the three rollback strategies ranked by how much they actually recover.→
- Running the maintenance windowThe go/no-go gate, the ordered runbook, the abort criteria written before you start, and what "done" means when the packages are already installed.→
Part XXX
Host Maintenance
6 checks
- Host patching strategy — what a Docker host needs and how oftenWhich host packages actually reach into containers, why unattended upgrades and Docker are a bad default combination, and how to configure automatic patching that cannot restart your daemon.→
- Kernel updates — what every container inherits from the hostContainers have no kernel of their own. What that means when you patch one, why the reboot is not optional, and how to tell a host that installed a kernel from one that is running it.→
- Planned reboot — what happens to containers, in orderWhy live restore does not survive a reboot, the three timeouts that decide whether your containers shut down gracefully or get killed, and which restart policies bring them back.→
- Draining a Docker host before maintenanceWhat "drain" means when there is no orchestrator to do it for you: removing the host from the load balancer, letting in-flight work finish, and stopping in dependency order.→
- Filesystem maintenance for /var/lib/dockerWhy the Docker data root belongs on its own filesystem, the inode exhaustion nobody monitors, trimming SSDs under a copy-on-write workload, and how to move the data root without losing everything.→
- Post-maintenance verification — proving the host came backThe seven layers to check after any host maintenance, in the order that finds problems fastest, and why "docker ps looks fine" is the weakest evidence available.→
Part XXXI
Troubleshooting
6 checks
- Troubleshooting framework — the systematic approachA tree whose every branch has a discriminating command, and a rule about what to capture before you touch anything.→
- Container won't start — diagnosisSix genuinely different causes with six different signatures. The exit code narrows it to two; `docker inspect` picks between them.→
- Networking failures — packets not reaching the containerBisect the path from client to process. Every hop has a command whose output rules that hop in or out.→
- Storage failures — out of disk, permission deniedENOSPC has four causes and only one is 'the disk is full'. Permission denied has five and only one is a mode bit.→
- Image pull failures — registry, auth, networkThe HTTP status code is the diagnosis. Get it out of the daemon rather than guessing from the CLI string.→
- Performance problems — slow application, container, hostThrottling is invisible in `docker stats`. So is page-cache-driven memory. This is where the numbers actually are.→
Part XXXII
Docker Internals
6 checks
- dockerd internals — what the daemon actually doesThe process tree, the on-disk state, and the exact boundary between "dockerd is broken" and "the container is broken".→
- containerd and shims — the supervisor layerWhy a process exists whose only job is to be a parent, and what it holds that nothing else can rebuild.→
- runc and the OCI runtimeA one-shot binary that builds a container, execs into it, and exits. It is never running when your container is.→
- The storage driver on disk — overlay2, and what replaced itHow dockerd turns image layers into a rootfs, where it puts them, and why GraphDriver can be null.→
- Inspecting a container from the host — PIDs, namespaces, cgroupsThe three-way mapping between a container ID, a host PID and a kernel namespace, and how to debug without docker exec.→
- The Engine API — what the CLI is really doingHTTP over a unix socket, versioned paths, negotiation, and the compatibility floor that breaks tooling on upgrade.→
Part XXXIII
Incident Response
6 checks
- Triage — the first 15 minutes of an incidentA sequence with a clock on it, and the ninety seconds of capture that has to happen before the first mitigation.→
- Incident review — what makes a useful postmortemA blameless review with a machine-reconstructed timeline, and action items that name a configuration key rather than a feeling.→
- Evidence capture — what docker restart destroysNinety seconds of collection that decides whether the postmortem can be written at all.→
- Containment — shrinking the blast radius without losing the evidenceA ladder of actions from stopping traffic at the edge to removing the container, and when to stop climbing.→
- Communication — roles, cadence, and the channel as the recordWho decides, who types, who tells everyone else, and why the incident channel is your timeline.→
- Recovery — restart, roll back, restore, or rebuildFour moves, one decision, and a definition of "resolved" that is not "the container is up".→
Part XXXIV
Capacity Planning
6 checks
- Capacity planning for Docker hostsWorked arithmetic for memory headroom, image and log growth, and the date the disk fills — with the measurement commands that produce each input.→
- Memory capacity — sizing limits against what the cgroup actually countsWhy memory.current is not the working set, and how to turn measurement into a defensible memory limit.→
- CPU capacity — quota, throttling, and the utilisation you can actually useSizing --cpus from measured demand, and finding the throttling that low average CPU hides.→
- Disk capacity — modelling how /var/lib/docker growsWhere Docker disk actually goes, why docker system df double-counts, and how to size a filesystem that will not fill.→
- Network capacity — bandwidth, connections, and the tables that fill upSizing throughput, conntrack entries and ephemeral ports before one of them runs out.→
- Growth, headroom, and the quarterly capacity reviewTurning measurements into a date, and reserving the headroom that a host failure will need.→
Part XXXV
Production Hardening
6 checks
- Host hardening — the production baselineEach control mapped to the attack it stops and the command that proves it took effect, plus the generic hardening steps that quietly break Docker.→
- Daemon hardening — and the evidence that it took effectEvery daemon.json control paired with the command that proves the running daemon actually has it.→
- Auditing the running fleet — container controls and their proofA per-container hardening audit that reads the kernel, not the intent.→
- Network and storage hardening — proving the boundaries holdVerifying published ports, segmentation, firewall precedence, mount options and volume ownership.→
- Image and secret hardening — proving nothing leakedEvidence that an image ships no credentials, no root default and no unpinned reference, and that secrets reach the container only at runtime.→
- Keeping the posture — drift detection, audit trails and backup as a controlTurning a one-off hardening pass into a continuously verified state, with a dated evidence trail.→
Part XXXVI
Automation
6 checks
- Automation with shell, systemd, and AnsibleThe idempotence problem that shell scripts cannot solve, systemd unit design for containers, and why running docker run -d from a unit supervises the wrong process.→
- CI/CD for Docker images — build, scan, sign, pushWhy stage order decides whether the pipeline is a control or a formality, and the awkward fact that you cannot sign an image before you push it.→
- systemd units for Compose stacks — boot ordering and the racesManaging a Compose stack as a systemd unit, and the four ordering mistakes that only show up on a reboot.→
- Idempotent shell automation — scripts that can run twiceWriting Docker shell automation that converges, fails loudly, and does not corrupt anything when two copies run at once.→
- Ansible for Docker hosts — and the tasks that are not idempotentHow community.docker decides whether to recreate a container, and the three ways a playbook reports success while changing nothing.→
- CI/CD failure modes — the green pipeline that ships a broken imageSeven ways an image pipeline passes every check and still puts the wrong bits into production.→
Part XXXVII
Orchestration Transition
6 checks
- Orchestration — when Compose is not enoughThe four things single-host Docker genuinely cannot do, the real cost of the tools that can, and how to tell which side of the line you are on.→
- What an orchestrator actually does — the reconciliation loopThe one mechanism every orchestrator shares, what it changes about day-to-day operations, and what it costs to run.→
- Cross-host networking and service discovery — the hard partWhat changes when containers on different hosts have to talk: overlays, encapsulation, MTU, and the failures that only affect large payloads.→
- Docker Swarm at a glance — what you get and what it costsThe shortest path from Compose to multi-host, its defaults that surprise people, and an honest account of the risks of choosing it.→
- Kubernetes at a glance — the object model and the operational billWhat the objects mean, what the control plane is made of, and an honest account of the recurring cost of running it.→
- Nomad at a glance, and choosing between the threeThe third option, a decision you can defend in writing, and the case for not migrating at all.→
Part XXXVIII
Capstone
6 checks
- Capstone — the production Docker environmentA complete production-style Docker environment as the course capstone.→
- Capstone stage 1 — the host under the environmentProvisioning and proving the single host that the capstone stack will run on.→
- Capstone stage 2 — building and pinning the three imagesProducing web, api and worker images that are small, non-root, attested, scanned and referenced by digest.→
- Capstone stage 3 — data plane, edge, and the first requestBringing the stack up in dependency order, wiring secrets and segmentation, and proving the first end-to-end request.→
- Capstone stage 4 — wiring observability to an SLOScraping the capstone stack, shipping its logs and traces, and deriving alerts from an error budget rather than from thresholds.→
- Capstone stage 5 — the DR drill and the go-live sign-offFour rehearsed failures, measured RTO and RPO, and the evidence pack that closes the capstone.→
Toolkit
Runbooks
5 checks
- Runbook: dockerd will not startA diagnostic tree for a Docker daemon that refuses to start, ordered by how often each cause is the real one, with a discriminating check for each.→
- Runbook: Drain a Docker host for maintenanceTake a Docker host out of service without dropping requests or corrupting state: pull it from the load balancer first, stop containers in dependency order, and prove nothing is still serving.→
- Runbook: Reclaim Docker disk space safelyAccount for the space first, then delete the narrowest thing that frees it. The precise difference between docker system prune, -a and --volumes, and why --volumes can end your afternoon.→
- Runbook: Recover a corrupt image store or overlay2 layerRecover from "failed to mount", "invalid argument" and missing parent layer errors: capture evidence, isolate the affected images, re-pull or rebuild, and understand what the last-resort path destroys.→
- Runbook: Upgrade Docker Engine on a production hostUpgrade Docker Engine with the containers still running where that is possible, and with an honest account of when live restore does not save you.→