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]>
40 lines
1.3 KiB
Markdown
40 lines
1.3 KiB
Markdown
# Knowledge Check: Docker CLI
|
|
|
|
---
|
|
|
|
**1. What's the real difference between `docker run` and `docker exec`?**
|
|
|
|
*Answer:* `docker run` always creates a brand-new container from an image. `docker exec` runs a
|
|
new command inside an ALREADY-running container — no new container is created.
|
|
|
|
---
|
|
|
|
**2. Which command is the container-level equivalent of ROOT 02's "what's running" question
|
|
(`ps aux` / service inspection)?**
|
|
|
|
*Answer:* `docker ps` (add `-a` to include stopped containers too).
|
|
|
|
---
|
|
|
|
**3. Why doesn't `docker logs` require you to know a specific log file path, unlike a
|
|
traditional Linux service?**
|
|
|
|
*Answer:* Docker automatically captures a container's stdout/stderr output — there's no
|
|
separate log file configuration needed the way ROOT 02's services required.
|
|
|
|
---
|
|
|
|
**4. What does `docker stop` actually send to a container's main process, and why does that
|
|
matter?**
|
|
|
|
*Answer:* SIGTERM first (a polite shutdown request, giving the process a chance to clean up),
|
|
then SIGKILL after a grace period if it hasn't exited — the exact same signal discipline ROOT 01
|
|
taught for regular Linux processes, applied here to a container's main process.
|
|
|
|
## Instructor Notes
|
|
|
|
**Facilitation:** Question 1 is the single most important check in this module — revisit the
|
|
demo if students get it wrong.
|
|
|
|
**Approximate timing:** 5 minutes.
|