Tell Module 16/18 learners the container engine/daemon must be running #46

Closed
opened 2026-06-22 14:24:00 -04:00 by claude · 0 comments
Contributor

Problem

Module 16 verifies Docker only with docker --version, which succeeds even when Docker Desktop/the engine isn't running. The next command, docker build, then fails with "Cannot connect to the Docker daemon" — confusing for someone who just verified Docker "works." On macOS/Windows this is a near-universal first stumble, and it carries into Module 18's deploy lab. The module is the first-time Docker onboarding ("You do not need Docker installed yet — that's the first step of the lab").

Evidence

modules/16-containers-and-reproducible-environments/README.md "You'll need": "Verify with docker --version"; Part A immediately runs docker build -t tasks-app . with no mention of starting the daemon. No mention of "daemon"/"docker info"/"engine running" in M16 or M18.

Why it matters

"docker --version works but docker build can't connect to the daemon" is the most common first-run Docker failure, and the version check gives false reassurance.

Proposed change

Add a tool-agnostic line (the module is Podman-friendly): "On macOS/Windows, make sure your container engine is running before building (start Docker Desktop, or podman machine start) — docker --version reports the client version even when the engine is stopped; docker info confirms the daemon is up."

Acceptance criteria

  • Module 16 tells the learner the engine must be running before docker build, and how to confirm (docker info).
  • The note is engine-agnostic (Docker/Podman).

Affected files

  • modules/16-containers-and-reproducible-environments/README.md

References

Source finding F57 (realVotes 3/3).


Filed from an adversarial multi-agent course review (217 raw findings → 54 adversarially-verified survivors). Scoped for manual review; intentionally not auto-assigned to an agent.

## Problem Module 16 verifies Docker only with `docker --version`, which succeeds even when Docker Desktop/the engine isn't running. The next command, `docker build`, then fails with "Cannot connect to the Docker daemon" — confusing for someone who just verified Docker "works." On macOS/Windows this is a near-universal first stumble, and it carries into Module 18's deploy lab. The module is the first-time Docker onboarding ("You do not need Docker installed yet — that's the first step of the lab"). ## Evidence `modules/16-containers-and-reproducible-environments/README.md` "You'll need": "Verify with `docker --version`"; Part A immediately runs `docker build -t tasks-app .` with no mention of starting the daemon. No mention of "daemon"/"docker info"/"engine running" in M16 or M18. ## Why it matters "docker --version works but docker build can't connect to the daemon" is the most common first-run Docker failure, and the version check gives false reassurance. ## Proposed change Add a tool-agnostic line (the module is Podman-friendly): "On macOS/Windows, make sure your container engine is running before building (start Docker Desktop, or `podman machine start`) — `docker --version` reports the client version even when the engine is stopped; `docker info` confirms the daemon is up." ## Acceptance criteria - [ ] Module 16 tells the learner the engine must be running before `docker build`, and how to confirm (`docker info`). - [ ] The note is engine-agnostic (Docker/Podman). ## Affected files - `modules/16-containers-and-reproducible-environments/README.md` ## References Source finding F57 (realVotes 3/3). --- *Filed from an adversarial multi-agent course review (217 raw findings → 54 adversarially-verified survivors). Scoped for manual review; intentionally not auto-assigned to an agent.*
claude added the ai-readyP2feature labels 2026-06-22 14:24:00 -04:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: justin/ai-workflow-course#46