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]>
62 lines
2.7 KiB
Markdown
62 lines
2.7 KiB
Markdown
# Container Storage
|
|
|
|
## The default: a disposable writable layer
|
|
|
|
Every running container gets its own writable layer sitting on top of its image's read-only
|
|
layers. Anything written there — a log file, a temp file, application data — exists ONLY as long
|
|
as that specific container does. Destroy the container, and that data is gone permanently. This
|
|
is ROOT 02's "persistent vs. temporary" question, given a hard default answer: by default,
|
|
everything in a container is temporary.
|
|
|
|
## Bind mounts: sharing a specific host path
|
|
|
|
A **bind mount** connects a specific path on the HOST filesystem directly into the container:
|
|
|
|
```
|
|
docker run -v /host/path:/container/path myimage
|
|
```
|
|
|
|
Changes are visible on BOTH sides immediately — useful for development (edit code on the host,
|
|
see changes in the container instantly) but tightly coupled to that exact host's filesystem
|
|
layout, which makes it a poor choice for portable, production data.
|
|
|
|
## Named volumes: Docker-managed persistent storage
|
|
|
|
A **named volume** is storage Docker manages for you, independent of any specific host path:
|
|
|
|
```
|
|
docker volume create my-data
|
|
docker run -v my-data:/container/path myimage
|
|
```
|
|
|
|
A named volume's data survives container destruction AND recreation — attaching the SAME volume
|
|
to a brand-new container gives that new container access to exactly the same data the old one
|
|
left behind. This is the deliberate, production-appropriate way to persist container data.
|
|
|
|
## The test that actually proves persistence
|
|
|
|
Claiming "this data persists" isn't convincing without proof: write data, DESTROY the container
|
|
completely, create a brand new one attached to the same volume, and confirm the data is still
|
|
there. This module's Lab requires exactly that proof, not just a claim.
|
|
|
|
## Bridge to Kubernetes
|
|
|
|
A Kubernetes `PersistentVolume`/`PersistentVolumeClaim` is the same idea generalized across an
|
|
entire cluster instead of one machine — the exact concept this module teaches, just orchestrated
|
|
at a larger scale, which Kubernetes courses build on directly.
|
|
|
|
## Instructor Notes
|
|
|
|
**Lesson goal:** Make "containers are disposable, volumes are not" a hard, memorable
|
|
distinction — directly building on ROOT 02's persistent/temporary framing.
|
|
|
|
**Approximate timing:** 15 minutes read; 10 minutes live.
|
|
|
|
**Common misconception to watch for:** assuming ANY container data survives by default — the
|
|
default is the OPPOSITE; persistence requires deliberate action (a volume or bind mount).
|
|
|
|
**Discussion question:** "Why might a named volume be preferred over a bind mount for
|
|
production data, even though both technically 'persist' data?" (Answer: a named volume isn't
|
|
tied to one specific host's exact filesystem path, making it more portable across different
|
|
hosts/environments.)
|