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]>
41 lines
1.4 KiB
Markdown
41 lines
1.4 KiB
Markdown
# Knowledge Check: Docker Compose
|
|
|
|
---
|
|
|
|
**1. What does `depends_on` actually guarantee — and NOT guarantee?**
|
|
|
|
*Answer:* It guarantees START order (the dependency's container is started before the dependent
|
|
service's). It does NOT guarantee the dependency is actually READY/healthy yet — a real,
|
|
common source of race conditions in production Compose files.
|
|
|
|
---
|
|
|
|
**2. Do you need to manually run `docker network create` for services in the same Compose file
|
|
to reach each other by name?**
|
|
|
|
*Answer:* No — Compose automatically creates a shared network for all services defined in the
|
|
file, and they can reach each other by service name immediately.
|
|
|
|
---
|
|
|
|
**3. What does `docker compose down` clean up, that plain `docker compose stop` would not?**
|
|
|
|
*Answer:* `down` removes the containers AND the network Compose created; `stop` only stops the
|
|
containers, leaving them (and the network) in place to be restarted later.
|
|
|
|
---
|
|
|
|
**4. Does Compose introduce any concept that isn't already just automating `docker run`/
|
|
`docker network` commands you already know?**
|
|
|
|
*Answer:* No — every Compose service maps directly onto concepts already covered
|
|
(image, ports, networking); Compose automates and declaratively describes them, it doesn't add
|
|
new underlying mechanisms.
|
|
|
|
## Instructor Notes
|
|
|
|
**Facilitation:** Question 1 is worth real emphasis — it's a genuine, common production
|
|
mistake worth preventing early.
|
|
|
|
**Approximate timing:** 5 minutes.
|