Terminal.Drill Get the app
ch10/l03

Compose state and cleanup

Treat a Compose project as a small system with services, networks, volumes, and lifecycle.

docker compose logs 20 min read, 30 min lab operator

Compose coordinates multiple containers. `ps`, `logs`, `config`, and `down` tell you what exists and how it was defined. Cleanup should be explicit about containers, networks, and volumes.

In the field

A local stack works once, then fails after a restart because stale volume state remains.

Worked command

$ docker compose ps$ docker compose logs --tail 100 api$ docker compose config$ docker compose down$ docker compose down --volumes
Anti-pattern

Do not delete volumes casually; they may contain the data you need to inspect.

Safer pattern

Name what cleanup removes before running it.

Knowledge check

A stack works once but breaks after a restart due to stale state. You run `docker compose down --volumes`. What extra risk does the --volumes flag add over plain down?

  • A None; it only stops containers and removes the network faster
  • B It deletes named and anonymous volumes, destroying persisted data
  • C It forces an image rebuild on the next up command
  • D It removes only anonymous volumes, so named data is always safe
Show the answer

Correct: B. It deletes named and anonymous volumes, destroying persisted data

Why

down --volumes removes the project's named and anonymous volumes, so any data you needed to inspect for the stale-state bug is gone. The trap is assuming named data is safe; plain down stops containers and removes the network but keeps volumes, which is why it is the reversible default.

Practice checklist

  1. Inspect a disposable Compose project or sample output.
  2. Collect ps/logs/config evidence.
  3. Write a cleanup command and what it removes.

Deliverable evidence

  • Compose inspection packet and cleanup note.
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.

Memorize this

Commit these to memory, then drill them until recall is automatic.

docker compose pslogsconfigdown--volumes

Reference

docker compose logs
Recall practice · Meaning -> command

cue Compose: tear down the stack but keep volume data intact

show recall target

docker compose down

See this drill type Practice recall in the app