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]>
28 lines
1.3 KiB
Markdown
28 lines
1.3 KiB
Markdown
# Reflection: You Proved Persistence, You Didn't Just Trust It
|
|
|
|
## Reflection questions
|
|
|
|
1. Before this module, would you have assumed container data persists by default? How
|
|
expensive would that wrong assumption be in a real production incident?
|
|
2. 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.
|