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]>
50 lines
1.5 KiB
Markdown
50 lines
1.5 KiB
Markdown
# Demonstration: What "Shares the Host Kernel" Actually Looks Like
|
|
|
|
## OBSERVE
|
|
|
|
```
|
|
$ uname -r
|
|
5.15.0-real-host-kernel
|
|
$ docker run --rm alpine:3.19 uname -r
|
|
5.15.0-real-host-kernel
|
|
```
|
|
|
|
## HYPOTHESIS
|
|
|
|
Predict: would a real virtual machine show the SAME kernel version as its host, the way this
|
|
container just did?
|
|
|
|
## INSPECT
|
|
|
|
A real VM runs its OWN independent kernel — it would very likely show a DIFFERENT version (or
|
|
even a different OS entirely) than its host, because a VM virtualizes the hardware and boots a
|
|
complete, separate operating system on top of it.
|
|
|
|
## CHANGE
|
|
|
|
```
|
|
$ docker run --rm ubuntu:22.04 uname -r
|
|
5.15.0-real-host-kernel
|
|
```
|
|
|
|
Even a completely different container OS (`ubuntu` here, vs. `alpine` before) STILL reports the
|
|
exact same kernel version — because there's only ONE real kernel involved, the host's.
|
|
|
|
## VERIFY
|
|
|
|
This is the concrete, observable meaning of "containers share the host kernel": no matter what
|
|
container image you run, `uname -r` always reports the same real kernel underneath — this is
|
|
exactly why containers start in a fraction of a second (no separate kernel to boot) and exactly
|
|
the tradeoff the lesson named.
|
|
|
|
## Instructor Notes
|
|
|
|
**Demo goal:** Make "shares the host kernel" a concrete, checkable fact rather than an abstract
|
|
architectural claim.
|
|
|
|
**Approximate timing:** 8 minutes live.
|
|
|
|
**Common mistake to watch for:** assuming different container images run different kernels
|
|
because their USERSPACE (installed tools, package manager) looks completely different — the
|
|
kernel underneath is unified regardless.
|