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]>
52 lines
1.5 KiB
Markdown
52 lines
1.5 KiB
Markdown
# Demonstration: Reaching a Container By Name, Not IP
|
|
|
|
## OBSERVE
|
|
|
|
```
|
|
$ docker network create demo-net
|
|
$ docker run -d --name api-server --network demo-net nginx:alpine
|
|
```
|
|
|
|
## HYPOTHESIS
|
|
|
|
Predict: can another container on `demo-net` reach `api-server` using its NAME as a hostname,
|
|
without knowing its IP?
|
|
|
|
## INSPECT
|
|
|
|
```
|
|
$ docker run --rm --network demo-net alpine:3.19 sh -c "wget -qO- http://api-server:80/ | head -1"
|
|
<!DOCTYPE html>
|
|
```
|
|
|
|
Yes — Docker's built-in DNS resolved `api-server` (a container NAME) directly, no IP address
|
|
needed anywhere in that command.
|
|
|
|
## CHANGE
|
|
|
|
Now try reaching it from a container that is NOT on the same network:
|
|
|
|
```
|
|
$ docker run --rm alpine:3.19 sh -c "wget -qO- http://api-server:80/ 2>&1 | head -1"
|
|
wget: bad address 'api-server'
|
|
```
|
|
|
|
Name resolution fails entirely — the container isn't even on the same Docker network, so there's
|
|
no DNS entry for it there.
|
|
|
|
## VERIFY
|
|
|
|
Container-to-container name resolution is scoped to a SPECIFIC Docker network, not global —
|
|
exactly like ROOT 02's subnet concept: reachability depends on which network you're actually on.
|
|
|
|
## Instructor Notes
|
|
|
|
**Demo goal:** Show container-name DNS resolution as a real, working feature — and show it
|
|
explicitly FAILING when containers aren't on the same network, reinforcing that this isn't
|
|
magic, it's scoped.
|
|
|
|
**Approximate timing:** 8 minutes live.
|
|
|
|
**Common mistake to watch for:** assuming any two containers can always reach each other by name
|
|
regardless of network — reinforce the "same network required" rule explicitly.
|