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]>
2.8 KiB
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.)