Files
ced4568andClaude Sonnet 5 682ef2de47 feat(root04): author Containers & Docker
Adds all 8 ROOT 04 modules (why containers exist, images & containers, Docker CLI, container
networking, container storage, Dockerfile & image build, Docker Compose, containers →
Kubernetes) — 43 activities, using the nested Docker Engine Phase 6D built and tested. Modules
1, 2, and 8 are conceptual (no lab by design) — the honest bridge module (M8) explicitly names
what Kubernetes adds beyond what this course already taught, without re-teaching Kubernetes
itself.

Adds 5 new hands-on Docker scenarios plus 2 MCQs, all against the real nested Docker Engine:
docker-cli-basics (run/exec/inspect a real container), docker-container-networking (a genuine
"works internally, unreachable from host" port-publishing failure, diagnosed and fixed by
recreating the container with the correct `-p` flag), docker-container-storage (a real
destroy/recreate cycle proving named-volume persistence, not just described), docker-build-image
(a real Dockerfile, a real build, a real custom image run), and docker-compose-multiservice (a
real two-service Compose application with a real published port). All tested end-to-end via the
real scenario-validation API, including negative tests.

Wires rootnode-containers-assessment (2 required + 4 random-draw scenarios) using the existing
Phase 3B assessment engine.

This completes the entire ROOT_ Foundations sequence (ROOT 01-04) — see
docs/PHASE6E_ROOT_FOUNDATIONS_COMPLETION.md.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
2026-08-26 17:08:14 -05:00

1.8 KiB

Demonstration: Proving Data Loss, Then Proving Persistence

OBSERVE

$ docker run -d --name no-volume alpine:3.19 sleep 300
$ docker exec no-volume sh -c "echo important-data > /tmp/data.txt"
$ docker exec no-volume cat /tmp/data.txt
important-data

Data exists — but is it actually safe?

HYPOTHESIS

Predict: will /tmp/data.txt still exist if this exact container is destroyed and an identical new one is started?

INSPECT

$ docker rm -f no-volume
$ docker run -d --name no-volume alpine:3.19 sleep 300
$ docker exec no-volume cat /tmp/data.txt
cat: /tmp/data.txt: No such file or directory

Gone — proven, not assumed. The "new" container is a completely fresh writable layer, even though it has the exact same name and image.

CHANGE

Now with a named volume instead:

$ docker rm -f no-volume
$ docker volume create demo-vol
$ docker run -d --name with-volume -v demo-vol:/data alpine:3.19 sleep 300
$ docker exec with-volume sh -c "echo important-data > /data/data.txt"
$ docker rm -f with-volume
$ docker run -d --name with-volume -v demo-vol:/data alpine:3.19 sleep 300

VERIFY

$ docker exec with-volume cat /data/data.txt
important-data

Proven, not assumed — the exact same destroy-and-recreate sequence, but this time the data survived, because it lived in the volume, not the container's disposable writable layer.

Instructor Notes

Demo goal: Prove BOTH the loss and the persistence with real destroy/recreate cycles — the contrast is what makes this lesson land, not either half alone.

Approximate timing: 10 minutes live.

Common mistake to watch for: stopping (not removing) a container and concluding "data persists" — docker stop doesn't touch the writable layer at all; only docker rm (destroying the container entirely) actually tests real persistence.