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]>
68 lines
2.4 KiB
Markdown
68 lines
2.4 KiB
Markdown
# Docker CLI
|
|
|
|
## The commands you'll use constantly
|
|
|
|
Module 2 introduced pull/run/stop/rm conceptually. This module adds the rest of the everyday
|
|
toolkit — and every one of them maps directly to a Linux concept you already have from ROOT 01.
|
|
|
|
## `docker ps` — what's running right now
|
|
|
|
```
|
|
$ docker ps
|
|
CONTAINER ID IMAGE STATUS NAMES
|
|
a1b2c3d4e5f6 nginx:alpine Up 2 minutes web
|
|
```
|
|
|
|
This is the container-level equivalent of ROOT 02's `ps aux` — "what's actually running." Add
|
|
`-a` to see stopped containers too, not just running ones.
|
|
|
|
## `docker logs` — what has it been saying?
|
|
|
|
```
|
|
$ docker logs web
|
|
```
|
|
|
|
The container-level equivalent of reading a service's log file from ROOT 02 — except Docker
|
|
captures a container's stdout/stderr automatically, so there's no config needed to find WHERE
|
|
the logs live, unlike a traditional service.
|
|
|
|
## `docker exec` — run a NEW command inside an ALREADY-running container
|
|
|
|
```
|
|
$ docker exec web sh -c 'cat /etc/nginx/nginx.conf'
|
|
```
|
|
|
|
Different from `docker run`, which creates a brand-new container — `exec` reaches INTO an
|
|
existing, running one, exactly like ROOT 01's `ps`/inspection commands but scoped to one
|
|
specific container's process namespace.
|
|
|
|
## `docker inspect` — the full, detailed truth about a container
|
|
|
|
```
|
|
$ docker inspect web --format '{{.State.Running}}'
|
|
true
|
|
```
|
|
|
|
Returns a large JSON document with everything Docker knows about a container — `--format` lets
|
|
you extract just the one field you care about, rather than reading the whole thing.
|
|
|
|
## `docker stop` vs `docker rm`
|
|
|
|
`docker stop` gracefully stops a running container (sends SIGTERM, then SIGKILL after a grace
|
|
period — literally ROOT 01's process-signals lesson, applied to a container's main process).
|
|
`docker rm` deletes a STOPPED container entirely — `docker rm -f` combines both (force-stop then
|
|
remove) in one step.
|
|
|
|
## Instructor Notes
|
|
|
|
**Lesson goal:** Explicitly map every Docker CLI command back to the equivalent ROOT 01/02
|
|
Linux concept students already have — this is a translation exercise, not new material.
|
|
|
|
**Approximate timing:** 15 minutes read; 10 minutes live.
|
|
|
|
**Common misconception to watch for:** confusing `docker run` (creates a new container) with
|
|
`docker exec` (runs a command in an existing one) — a very common early mixup.
|
|
|
|
**Demo idea:** run `docker exec` against a container, then immediately `docker run` the same
|
|
image again, and compare `docker ps` before/after to show the difference concretely.
|