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]>
63 lines
1.6 KiB
Markdown
63 lines
1.6 KiB
Markdown
# Demonstration: Watching Layer Caching Actually Work
|
|
|
|
## OBSERVE
|
|
|
|
```
|
|
$ docker build -t demo:1 .
|
|
Step 1/3 : FROM alpine:3.19
|
|
Step 2/3 : WORKDIR /app
|
|
Step 3/3 : COPY greeting.txt .
|
|
Successfully tagged demo:1
|
|
```
|
|
|
|
## HYPOTHESIS
|
|
|
|
Predict: if you run the EXACT same build again with no changes, will it take the same amount of
|
|
time?
|
|
|
|
## INSPECT
|
|
|
|
```
|
|
$ docker build -t demo:1 .
|
|
Step 1/3 : FROM alpine:3.19
|
|
Step 2/3 : WORKDIR /app
|
|
---> Using cache
|
|
Step 3/3 : COPY greeting.txt .
|
|
---> Using cache
|
|
Successfully tagged demo:1
|
|
```
|
|
|
|
`Using cache` — nearly instant, because nothing actually changed since the last build.
|
|
|
|
## CHANGE
|
|
|
|
Now change `greeting.txt`'s content and rebuild:
|
|
|
|
```
|
|
$ echo "updated" > greeting.txt
|
|
$ docker build -t demo:1 .
|
|
Step 2/3 : WORKDIR /app
|
|
---> Using cache
|
|
Step 3/3 : COPY greeting.txt .
|
|
---> (this step re-runs — the file changed)
|
|
```
|
|
|
|
Only the step AFTER the change re-runs — `WORKDIR` (unaffected) still used its cache.
|
|
|
|
## VERIFY
|
|
|
|
This is exactly why instruction ORDER matters: everything before the first changed instruction
|
|
stays cached; everything from that point onward must rebuild. Put your least-frequently-changing
|
|
instructions first.
|
|
|
|
## Instructor Notes
|
|
|
|
**Demo goal:** Make layer caching a directly OBSERVED behavior (via real build output), not an
|
|
abstract efficiency claim.
|
|
|
|
**Approximate timing:** 8 minutes live.
|
|
|
|
**Common mistake to watch for:** ordering a Dockerfile with frequently-changing application code
|
|
copied BEFORE installing rarely-changing dependencies — invalidates the expensive dependency-
|
|
install cache on every trivial code change.
|