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]>
65 lines
1.7 KiB
Markdown
65 lines
1.7 KiB
Markdown
# Demonstration: One File, Two Containers, One Network — Automatically
|
|
|
|
## OBSERVE
|
|
|
|
```yaml
|
|
services:
|
|
web:
|
|
image: nginx:alpine
|
|
ports:
|
|
- "8080:80"
|
|
cache:
|
|
image: redis:alpine
|
|
```
|
|
|
|
## HYPOTHESIS
|
|
|
|
Predict: without running `docker network create` yourself, will `web` be able to reach `cache`
|
|
by name after `docker compose up`?
|
|
|
|
## INSPECT
|
|
|
|
```
|
|
$ docker compose up -d
|
|
$ docker compose exec web sh -c "wget -qO- http://cache:6379/ 2>&1 | head -1"
|
|
```
|
|
|
|
(Redis doesn't speak HTTP, so this specific request looks odd, but the connection ITSELF
|
|
succeeding or failing tells you whether name resolution and network reachability work — a
|
|
`Connection refused` here would mean it REACHED `cache` but Redis rejected the protocol
|
|
mismatch, which is actually proof the network worked.)
|
|
|
|
## CHANGE
|
|
|
|
```
|
|
$ docker compose ps
|
|
NAME IMAGE STATUS
|
|
web-1 nginx:alpine Up
|
|
cache-1 redis:alpine Up
|
|
$ docker network ls | grep compose
|
|
xyz123 myproject_default bridge
|
|
```
|
|
|
|
Compose created a network automatically, named after the project directory, with no manual step.
|
|
|
|
## VERIFY
|
|
|
|
```
|
|
$ docker compose down
|
|
$ docker network ls | grep compose
|
|
(nothing)
|
|
```
|
|
|
|
`docker compose down` cleaned up EVERYTHING Compose created — containers AND the network — in
|
|
one command.
|
|
|
|
## Instructor Notes
|
|
|
|
**Demo goal:** Show the automatic networking as a real, observable fact (a real network exists,
|
|
named and scoped to the project) rather than an assumed convenience.
|
|
|
|
**Approximate timing:** 8 minutes live.
|
|
|
|
**Common mistake to watch for:** forgetting `docker compose down` and accumulating orphaned
|
|
networks/containers across multiple exercises — a good habit to reinforce explicitly.
|