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
Images and Containers
The single most important distinction in this course
An image is a packaged, read-only ARTIFACT. A container is a RUNNING INSTANCE of an image. This is exactly analogous to a program's executable file (the image) versus a running process of that program (the container) — a distinction ROOT 01's process module already gave you vocabulary for. You can run the SAME image many times, producing many independent containers, the same way you can run the same program multiple times as separate processes.
Layers: how an image is actually built
An image is built from a stack of layers, each representing one change (install a package,
copy in application code, set a configuration). Layers are cached and shared — if two images
both start FROM alpine:3.19, they share that base layer on disk rather than duplicating it,
which is why pulling a new image that shares layers with one you already have is often much
faster than the total image size suggests.
Registries, repositories, and tags
- Registry — a server that stores and distributes images (Docker Hub is the default public one; a company might run a private registry).
- Repository — a named collection of related images (e.g.
nginx). - Tag — a specific version within a repository (
nginx:alpine,nginx:1.25,nginx:latest).latestis just a conventional tag name, not automatically "the newest" in any enforced sense — relying on it in production is a common, avoidable source of surprise.
The core commands, mapped to the model
docker pull <image>— download an image from a registry, without running it.docker run <image>— create and start a NEW container from an image (pulls automatically if not already present locally).docker stop <container>— gracefully stop a running container (its process, not the image).docker rm <container>— delete a stopped container. This does NOT delete the image it was created from.
Instructor Notes
Lesson goal: Land the image/container distinction as concretely as possible — nearly every later confusion in this course traces back to conflating the two.
Approximate timing: 15 minutes read; 10 minutes live.
Common misconception to watch for: using "image" and "container" interchangeably in casual speech — gently correct this early and often, since precise vocabulary here prevents real confusion later (e.g., "did you delete the container or the image?" matters).
Discussion question: "If you run docker run nginx:alpine three times, how many images
exist afterward? How many containers?" (Answer: 1 image, 3 containers — a good check before
moving to the hands-on Lab.)