Terminal.Drill Get the app
ch10/l02

Logs, exec, ports, and volumes

Inspect the outside evidence before entering the container.

docker logs 25 min read, 30 min lab operator

Logs and inspect output often answer the question without `exec`. Port mappings and volume mounts explain why a service is unreachable or data appears missing.

In the field

The app container is up but requests fail.

Worked command

$ docker logs --tail 100 web$ docker port web$ docker inspect --format '{{json .Mounts}}' web$ docker exec -it web sh
Anti-pattern

Do not debug inside the container before reading logs and mappings.

Safer pattern

Check logs, ports, mounts, then exec only for a specific hypothesis.

Knowledge check

The container is up and `docker port web` shows 0.0.0.0:8080->80/tcp, but requests still fail. What does that mapping actually prove?

  • A The app inside is listening on port 80 and serving traffic
  • B Only that the host port is forwarded; the app may not be listening yet
  • C Nothing useful; port output is unreliable without exec
  • D The service is healthy and the failure must be in the client
Show the answer

Correct: B. Only that the host port is forwarded; the app may not be listening yet

Why

A port mapping proves the host-to-container forwarding is configured, not that a process inside is bound to that port or ready. The trap is reading it as proof the app is listening, which sends you debugging the client when the container's own log usually names the real fault.

Practice checklist

  1. Use a lab container or sample output.
  2. Collect logs, port map, and mount list.
  3. Write the hypothesis that would justify exec.

Deliverable evidence

  • Logs/ports/mounts packet.
  • A reasoned exec plan.
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 logsdocker portdocker inspectdocker exec

Reference

docker psdocker compose logs
Recall practice · Scenario -> next check

cue Container is up but requests fail — what to read before exec

show recall target

docker logs --tail 100 <name>, then docker port and docker inspect mounts

See this drill type Practice recall in the app