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
Knowledge Check: Images and Containers
1. State the image/container distinction in one sentence.
Answer: An image is a packaged, read-only artifact; a container is a running instance created from an image — the same relationship as a program file and a running process of it.
2. You run docker rm -f my-container. Does this delete the image it was created from?
Answer: No — removing a container never removes the image; they have independent lifecycles
and separate removal commands (docker rm vs. docker rmi).
3. What does the latest tag actually guarantee?
Answer: Nothing enforced — it's just a conventional tag name, not automatically "the newest version" in any technical sense. Relying on it in production is a common source of surprise.
4. What's a layer, and why does layer sharing matter practically?
Answer: A layer is one recorded change in an image's build (installing something, copying files, etc.). Layers are cached and shared between images that share a base — meaning pulling a new image that shares layers with one you already have can be much faster than its total reported size suggests.
Instructor Notes
Facilitation: Question 2 directly reinforces the previous demo — worth confirming everyone got it right before moving on.
Approximate timing: 5 minutes.