Terminal.Drill Get the app
ch10/l01

Images, containers, names, and state

Know the difference between an image, a container, and a running process.

docker ps 20 min read, 25 min lab operator

An image is a template. A container is a created runtime instance. `docker ps` shows running containers; `docker ps -a` includes stopped ones. Names, ports, and status are the first facts to capture.

In the field

A local service is not responding and you need to know whether the container is running.

Worked command

$ docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'$ docker ps -a$ docker inspect web
Anti-pattern

Do not rebuild before checking whether the container is stopped, unhealthy, or unbound from the expected port.

Safer pattern

Record name, image, status, ports, and health first.

Knowledge check

Your service is unreachable and `docker ps` shows nothing for it. What is the most likely reason, and the right next command?

  • A The image was never built; run docker build to recreate it
  • B The container is stopped or exited; run docker ps -a to see it
  • C Docker daemon is down; restart Docker before anything else
  • D The container is fine; ps only omits healthy containers
Show the answer

Correct: B. The container is stopped or exited; run docker ps -a to see it

Why

docker ps lists only running containers, so a stopped or exited container is hidden until you add -a. The trap is jumping to docker build, which assumes the image is gone and rebuilds before you have even confirmed the container exists.

Practice checklist

  1. Use a disposable container or sample output.
  2. List running and stopped containers.
  3. Identify name, status, and ports.

Deliverable evidence

  • Container inventory table.
  • A note explaining image vs container.
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 psdocker ps -adocker inspectimagecontainer

Reference

docker ps
Recall practice · Meaning -> command

cue Show stopped and exited containers, not just running ones

show recall target

docker ps -a

See this drill type Practice recall in the app