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]>
59 lines
2.8 KiB
Markdown
59 lines
2.8 KiB
Markdown
# Container Networking
|
|
|
|
## This module is ROOT 02's networking model, one layer up
|
|
|
|
Every concept here is a direct application of ROOT 02 Module 3's host-to-application chain —
|
|
just with a container standing in for "host."
|
|
|
|
## Every container gets its own IP
|
|
|
|
By default, Docker gives each container its own IP address on a private, internal Docker
|
|
network — exactly like a real host has an IP on a real network (ROOT 02 Module 3). Containers on
|
|
the SAME Docker network can reach each other directly by that IP.
|
|
|
|
## Container-to-container DNS: reach a container by NAME
|
|
|
|
Docker runs its own internal DNS for user-defined networks — containers on the same network can
|
|
resolve each other by CONTAINER NAME, not just IP. If a `web` container needs to reach an `api`
|
|
container, it can simply connect to hostname `api` — Docker resolves it automatically. This is
|
|
the exact "getent hosts" concept from ROOT 02, just automated for you.
|
|
|
|
## Publishing a port: the host/container boundary
|
|
|
|
A container's ports are, by default, only reachable from OTHER containers on the same Docker
|
|
network — NOT from the host machine, and NOT from outside. **Publishing** a port
|
|
(`-p hostPort:containerPort`) explicitly creates a mapping: traffic arriving at the HOST's
|
|
`hostPort` gets forwarded to the CONTAINER's `containerPort`. This is set at container CREATION
|
|
time — you cannot add it to an already-running container; it must be recreated.
|
|
|
|
```
|
|
docker run -d -p 8080:80 nginx:alpine
|
|
```
|
|
|
|
Host port 8080 → this container's port 80. `curl http://localhost:8080/` from the host now
|
|
reaches it; `curl http://localhost:80/` from the host does NOT (the host's own port 80 was never
|
|
touched).
|
|
|
|
## A working app that's still unreachable is a real, common failure
|
|
|
|
Exactly like ROOT 02's networking-diagnosis modules: a container can be perfectly healthy
|
|
internally (`docker exec <container> curl localhost:80` succeeds) while being completely
|
|
unreachable from the host, because publishing was never configured. This is one of the single
|
|
most common container networking mistakes — and this module's Lab makes you diagnose and fix
|
|
it for real.
|
|
|
|
## Instructor Notes
|
|
|
|
**Lesson goal:** Explicitly connect every idea here back to ROOT 02's networking model — this
|
|
module should feel like recognition, not new material, reinforcing the curriculum's continuity.
|
|
|
|
**Approximate timing:** 15 minutes read; 10 minutes live.
|
|
|
|
**Common misconception to watch for:** assuming a container's port is automatically reachable
|
|
from the host just because the container itself works fine — this exact misconception is what
|
|
this module's Lab is built to correct through direct experience.
|
|
|
|
**Discussion question:** "Why might Docker default to NOT exposing container ports to the host
|
|
automatically?" (Good answer: explicit opt-in is safer — you don't want every container's every
|
|
port accidentally reachable from outside by default.)
|