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
2.8 KiB
Markdown
52 lines
2.8 KiB
Markdown
# Why Containers Exist
|
|
|
|
## "It works on my machine"
|
|
|
|
Every engineer has heard this sentence, and it names a real, expensive problem: an application
|
|
that runs perfectly on one machine fails on another because of differences in installed
|
|
libraries, OS versions, configuration, or dozens of other environmental details that are easy to
|
|
overlook and hard to fully document.
|
|
|
|
## The problem, precisely
|
|
|
|
- **Dependency inconsistency** — an app needs Python 3.11 and a specific set of libraries; the
|
|
production server has Python 3.9 and different library versions.
|
|
- **Non-repeatability** — setting up a working environment by hand, following a README, drifts
|
|
over time and between people — "works on my machine" is often true because "my machine" has
|
|
accumulated years of undocumented manual setup.
|
|
- **Deployment friction** — moving an application from a developer's laptop to a test server to
|
|
production means repeating fragile manual setup multiple times, each an opportunity for drift.
|
|
|
|
## Containers: package the application AND everything it needs, together
|
|
|
|
A **container** packages an application with its exact dependencies, libraries, and
|
|
configuration into one deployable unit — the same container that ran on a developer's laptop
|
|
runs, byte-for-byte identically, on a test server or in production. "It works on my machine"
|
|
becomes "it works in this container," which is true everywhere that container runs.
|
|
|
|
## VM vs. container — genuinely different, not just "containers are lighter VMs"
|
|
|
|
A **virtual machine** virtualizes an entire computer, including its own full operating system
|
|
kernel — heavier, slower to start, but with very strong isolation. A **container** shares the
|
|
HOST machine's kernel and only isolates the application's process, filesystem view, and network
|
|
— dramatically lighter and faster to start (seconds vs. minutes), with somewhat different
|
|
isolation properties than a full VM (a well-understood, documented tradeoff, not a hidden flaw).
|
|
Neither is strictly "better" — they solve overlapping but distinct problems, and real production
|
|
systems often use both together (VMs providing strong host isolation, containers providing fast,
|
|
consistent application packaging on top).
|
|
|
|
## Instructor Notes
|
|
|
|
**Lesson goal:** Motivate containers through the real, felt problem ("it works on my machine")
|
|
before any Docker command — mirrors ROOT 03's "why version control exists" opener.
|
|
|
|
**Approximate timing:** 12 minutes read; 8 minutes live.
|
|
|
|
**Common misconception to watch for:** describing containers as simply "lightweight VMs" —
|
|
they share the host kernel, which is a genuine architectural difference, not just a size
|
|
difference.
|
|
|
|
**Discussion question:** "Has anyone experienced 'it works on my machine' personally, on either
|
|
side of that conversation?" (Real stories make this lesson's premise concrete before the
|
|
technical content begins.)
|