ced4568andClaude Sonnet 5
682ef2de47
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]>
1.3 KiB
Reflection: You Proved Persistence, You Didn't Just Trust It
Reflection questions
- Before this module, would you have assumed container data persists by default? How expensive would that wrong assumption be in a real production incident?
- Why did this module insist on actually DESTROYING a container to test persistence, rather than just describing the concept?
Real Ops takeaway
"I assumed it would persist" is one of the most expensive assumptions in real operations work. You didn't just learn that volumes persist data — you personally destroyed a container and confirmed data loss, then destroyed another and confirmed data survival, with the SAME sequence of commands each time except for one deliberate volume configuration. That's the level of confidence "verify, don't assume" is supposed to give you, and it's exactly the discipline ROOT 02's troubleshooting framework already built.
This module is complete. Continue to the next module.
Instructor Notes
Discussion questions for a live classroom: question 1 works well as a real cautionary example — ask if anyone has heard of (or experienced) a real data-loss incident caused by this exact wrong assumption.
Approximate timing: 5-8 minutes live discussion; 5 minutes self-paced writing.