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]>
51 lines
2.6 KiB
Markdown
51 lines
2.6 KiB
Markdown
# Dockerfile and Image Build
|
|
|
|
## A Dockerfile is a recipe for an image
|
|
|
|
Every image you've used so far (`nginx:alpine`, `alpine:3.19`) was itself BUILT from a
|
|
Dockerfile by someone else. This module teaches you to write your own.
|
|
|
|
## The core instructions
|
|
|
|
- **`FROM <image>`** — every Dockerfile starts by choosing a base image to build on top of.
|
|
Almost nothing is built completely from scratch.
|
|
- **`WORKDIR <path>`** — sets the working directory for every instruction that follows it (and
|
|
for the container's default working directory when it runs).
|
|
- **`COPY <host-path> <image-path>`** — copies files from your BUILD CONTEXT (the directory you
|
|
run `docker build` from) into the image.
|
|
- **`RUN <command>`** — executes a command DURING the build, creating a new layer with its
|
|
result (installing a package, for example).
|
|
- **`CMD <command>`** (conceptually) — sets the DEFAULT command a container runs when started
|
|
from this image, if nothing else is specified.
|
|
- **`ENTRYPOINT <command>`** (conceptually) — similar to `CMD`, but harder to override at
|
|
`docker run` time — the two are often combined (`ENTRYPOINT` as the fixed program,
|
|
`CMD` as its default arguments).
|
|
|
|
## Build context and `.dockerignore`
|
|
|
|
`docker build -t mytag .` — that final `.` is the **build context**: the directory Docker can
|
|
see and copy files FROM during the build. A `.dockerignore` file (same idea as `.gitignore` from
|
|
ROOT 03) excludes files from the build context — keeping large or irrelevant files (like a local
|
|
`.git` folder or dependency caches) out of your image and speeding up builds.
|
|
|
|
## Layers, again
|
|
|
|
Each instruction in a Dockerfile creates one layer, cached individually. Docker reuses cached
|
|
layers for instructions that haven't changed since the last build — which is why the ORDER of
|
|
instructions matters for build speed: put things that change rarely (like `FROM` and installing
|
|
dependencies) before things that change often (like copying your actual application code), so a
|
|
small code change doesn't invalidate expensive earlier layers.
|
|
|
|
## Instructor Notes
|
|
|
|
**Lesson goal:** Give students enough Dockerfile literacy to write a real, small, working image
|
|
— not exhaustive coverage of every possible instruction.
|
|
|
|
**Approximate timing:** 18 minutes read; 10 minutes live.
|
|
|
|
**Common misconception to watch for:** copying application code before installing dependencies
|
|
— reinforce the "changes-rarely-first" layer-ordering principle with a concrete example.
|
|
|
|
**Demo idea:** build the same Dockerfile twice with no changes, showing the second build using
|
|
fully cached layers (`CACHED` in the output) and finishing almost instantly.
|