Let's say you've pasted a docker run line from a README fifty times and it worked. What it did: created a brand new container from the image and started it, downloading the image first if needed.

Nothing is reused from last time's container. Every run leaves a container behind, even after it exits. Add --rm on a scratch machine and it deletes itself on exit. Long-running services get a --name, so you can talk to them later.

Containers are disposable. Names are how you find them.

Let's say a port is taken and nothing seems to be using it. The first move is docker ps, the list of what's actually running, with the names you'll use in stop, logs, and exec. It's also where a container's port mapping shows up.

The trap is what the list leaves out. ps hides the stopped containers, and they stay on disk forever until you remove them. ps -a shows the whole pile, which is how you find the six forgotten pgtest containers. Filters help when the pile is big: --filter name=web, --filter status=exited. Everything docker does next starts with reading this list.

Run it before you type anything else.

Let's say the disk is filling and you suspect the images. docker images lists every top-level image with tag, ID and size. The reading half of housekeeping, and it costs nothing.

The list hides things: intermediate and dangling images only appear with -a, and <none> tags are usually old builds nobody renamed. Sizes look bigger than they are because images share base layers, stored once. Knowing what's on disk beats guessing at it.

Images share layers. The list under-reports the mess.

Let's say the demo starts in two minutes and the network picks now to die. docker pull downloads the image layer by layer and stores it locally, so run has nothing left to fetch.

Layers you already have are skipped, across versions and across images, which is why a refreshed tag pulls in seconds. No tag means latest, and latest on your laptop and latest next month are different images. --platform pins the architecture.

Pull early. Pin the tag.

Let's say the container starts and dies three seconds later. Read what it said first: docker logs shows everything the main process printed to stdout and stderr.

-f streams new lines, tail keeps it short, --since 30m is gold at 3am. Logs belong to the container, so a crashed container's last words are still there for the reading. Apps logging to a file inside the container lose the file with the container.

Logs first. Restarts second.

Let's say every build takes four minutes and you've stopped shipping small fixes. The cache is the way out: docker build reuses a layer for every instruction whose inputs haven't changed.

The moment one instruction changes, its layer rebuilds, and everything after it loses the cache too, changed or not. That's why dependency files come before source. -t names the result. Reordering the file turns four minutes into forty seconds, permanently.

Cache is earned by instruction order.

Let's say local setup is five README steps. One compose file replaces it: services, ports, volumes, wiring. docker compose up builds, creates, starts and attaches to every service in one go.

-d detaches and leaves the stack running. The command is idempotent in the useful way: unchanged services stay up, changed ones get recreated. The hyphenated docker-compose is the old v1 binary; the space is the real spelling now.

One file, one command, the whole app.

Let's say df says gigabytes are reclaimable. docker system prune clears stopped containers, unused networks, dangling images and build cache in one go, and asks before it touches anything.

-a widens images from dangling-only to every unused one. --volumes adds anonymous volumes, and there's no undo for data; Docker 23.0 stopped pruning them by default for exactly that reason. docker cp out anything you need before the y.

Read the prompt. It's a contract.