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]>
2.7 KiB
Docker Compose
Real applications are rarely just one container
A web app usually needs a database, maybe a cache, maybe a background worker — several
containers that need to be created, networked together, and started in a sensible order. Doing
this manually with individual docker run commands works, but gets tedious and error-prone fast,
especially remembering the exact flags every time.
One file, the whole application
Docker Compose describes an entire multi-container application in one YAML file:
services:
web:
image: nginx:alpine
ports:
- "8080:80"
depends_on:
- api
api:
image: my-api:1
services— each entry is one container, using the exact same concepts (image, ports, etc.) you already know from plaindocker run.depends_on— controls STARTUP order (api starts before web) — note this ensures order, not that the dependency is fully READY yet, a subtlety real applications often need extra handling for.- Networking is automatic — Compose creates a shared network for all services in the file by
default, so
webcan reachapiby name immediately, no manualdocker network createneeded.
The commands
docker compose up -d # start every service defined in the file, in the background
docker compose ps # see the status of every service
docker compose logs # see logs from every service, or docker compose logs <service>
docker compose down # stop and remove everything Compose created
Compose doesn't replace anything you've learned — it automates it
Every Compose service maps directly onto a docker run command you could write by hand; Compose
just describes the whole set declaratively in one file instead of remembering and re-typing
several long commands correctly, every time, in the right order.
Instructor Notes
Lesson goal: Frame Compose as automation of already-understood concepts, not new magic —
students should be able to mentally translate a services: block back into individual
docker run commands.
Approximate timing: 15 minutes read; 10 minutes live.
Common misconception to watch for: treating depends_on as "waits until fully healthy" —
it only controls START order, not readiness; worth flagging as a real, common source of race
conditions in actual production Compose files.
Discussion question: "Why might describing your application declaratively in one file be
better than a shell script that runs several docker run commands in sequence?" (Good answer:
reviewable, versionable, and Compose itself understands the relationships between services,
rather than just blindly executing a sequence.)