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.1 KiB
Reflection: Same Diagnosis, New Layer
Reflection questions
- How much of this module's Lab did you solve using pure Docker knowledge, versus reasoning you already had from ROOT 02?
- Where do you expect "published port" reasoning to matter again later in ROOT 05+?
Real Ops takeaway
"Works internally, unreachable externally" is one of the single most common real-world container networking incidents — and you just diagnosed and fixed a real one. The exact reasoning you used here (confirm internal health, check what's actually published, verify the published mapping works) is the same reasoning you'll use again for Kubernetes Services later — "published port" becomes "Service," but the underlying question (is anything actually routing traffic to this workload?) doesn't change.
This module is complete. Continue to the next module.
Instructor Notes
Discussion questions for a live classroom: question 2 previews Kubernetes Services directly — worth naming that connection explicitly without teaching Services yet.
Approximate timing: 5-8 minutes live discussion; 5 minutes self-paced writing.