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]>
30 lines
1.3 KiB
Markdown
30 lines
1.3 KiB
Markdown
# Guided Exercise: Predict What Survives Before You Test It
|
|
|
|
This is a paper exercise — commit to predictions before working in the Lab.
|
|
|
|
## Your task
|
|
|
|
For each scenario, predict whether the data survives a `docker rm -f` followed by recreating a
|
|
container with the same name and image:
|
|
|
|
1. Data written to `/tmp/file.txt` inside a container with no volumes configured.
|
|
2. Data written to `/data/file.txt`, where `/data` is mounted from a named volume.
|
|
3. Data written to `/data/file.txt` in scenario 2, but this time you ALSO run
|
|
`docker volume rm <the-volume>` before recreating the container.
|
|
|
|
## A worked shape to check yourself against
|
|
|
|
1. Lost — no volume, so it lived only in the disposable writable layer.
|
|
2. Survives — the volume itself is untouched by the container's destruction, and the new
|
|
container reattaches to the same volume.
|
|
3. Lost — the volume itself was explicitly deleted, not just the container. Persistence depends
|
|
on the VOLUME surviving, not just avoiding container destruction.
|
|
|
|
## Instructor Notes
|
|
|
|
**Facilitation:** Item 3 is the important trick question — students who've internalized
|
|
"volumes always persist" without qualification should be corrected here: the volume itself can
|
|
still be deleted deliberately.
|
|
|
|
**Approximate timing:** 8-10 minutes live discussion; 5 minutes self-paced.
|