ch10 · operator · 85-120 min

containers and runtime debugging

Inspect container lifecycle, logs, ports, volumes, exec boundaries, and Compose state.

You can debug a local container stack without reaching for random rebuilds.

dockercomposecontainerslogsports
Teaching diagramch10 · mental model
Debug from the outside in read evidence before you enter ps / ps -a name status ports logs --tail 100 port / inspect ports mounts exec -it sh only on a hypothesis compose: ps / logs / config services networks volumes as one system down stops, keeps named data down -v deletes volumes left to right = cheaper, reversible evidence first; rebuild is a last resort

shows: The outside-in debugging order — ps, logs, ports/mounts, then exec only on a hypothesis — plus the Compose lifecycle from down (keeps named volumes) to down --volumes (destroys them).

does not prove: The order tells you where to look, not what is wrong; a clean log and a present port mapping narrow the cause but do not by themselves prove the service is healthy.

Lessons in this chapter

  1. ch10/l01 Images, containers, names, and state docker ps Know the difference between an image, a container, and a running process.
  2. ch10/l02 Logs, exec, ports, and volumes docker logs Inspect the outside evidence before entering the container.
  3. ch10/l03 Compose state and cleanup docker compose logs Treat a Compose project as a small system with services, networks, volumes, and lifecycle.
capstone

container inspection loop

Debug a sample container failure by collecting name, status, ports, logs, mounts, Compose config, and cleanup plan.

Deliverable

A packet that explains the next action without rebuilding first.

Success criteria

  • Logs are checked before exec.
  • Ports and volumes are documented.
  • Cleanup states exactly what it removes.
Terminal Drill companion

Containers

After you can map container names, ports, volumes, logs, and cleanup.

Train after the lesson