How to Learn Docker (Without Copy-Pasting Commands You Don't Understand)

My first year with Docker was mostly copy and paste. A README said docker run -d -p 5432:5432 postgres, I ran it, Postgres showed up, and I moved on. When something broke I searched the error, pasted whatever fixed it for someone on Stack Overflow, and hoped.

That works until the day a container won't start, your disk is full of images you've never heard of, and a teammate asks why the app can't reach the database. Then you find out you know a lot of commands and almost none of the model underneath them.

What finally helped was learning Docker in a different order than most tutorials teach it.

Start with the two nouns

Nearly every confusing moment I had came from mixing up images and containers.

An image is a read-only snapshot of a filesystem plus some metadata, like which command to run by default. A container is a running (or stopped) process started from that image, with its own thin writable layer on top. You can start ten containers from one image. Deleting a container doesn't touch the image. Deleting an image doesn't work while a container still uses it.

Once that clicked, a bunch of commands sorted themselves into two piles. docker images, docker pull, docker build and docker rmi are about images. docker ps, docker run, docker stop, docker logs and docker exec are about containers. I stopped guessing which one I needed.

Run things and look inside them

Reading about isolation didn't teach me much. Poking at it did. Try this:

docker run -it --rm alpine sh

You're now in a shell inside a tiny Linux container. Run ps, and you'll see almost nothing, because the container only sees its own processes. Create a file, exit, and run the same command again. The file is gone, since --rm threw away the container and its writable layer.

Then run it without --rm, create a file, exit, and use docker ps -a to find the stopped container. docker start -ai <id> brings it back and the file is still there. Ten minutes of this taught me more about container state than any diagram.

Write a Dockerfile before you need one

I used to only read other people's Dockerfiles. Writing a small one for a toy app is where layers started making sense:

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
CMD ["node", "server.js"]

Build it, change one line of server.js, and build again. Notice that the npm ci step says it used the cache. Now move COPY . . above the RUN npm ci line and rebuild after a small change. Every build reinstalls dependencies, because changing any file invalidates that layer and everything after it.

That one experiment explains most "why is my build so slow" questions you'll ever have. It's also why people copy the lockfile first.

Learn ports, volumes and networks by breaking them

These three cause most beginner bugs, and each one is easier to remember after you've seen it fail.

For ports, run a web server with no -p flag and try to open it in your browser. It won't load. Add -p 8080:80 and it will. The left number is your machine, the right number is the container. I say "host colon container" in my head every time.

For volumes, start Postgres without a volume, create a table, remove the container, start a new one. The table is gone. Then do it again with -v pgdata:/var/lib/postgresql/data and watch the data survive.

For networks, put two containers on the default bridge and try to reach one from the other by name. Then create a network with docker network create and attach both. Names resolve now. This is the thing Docker Compose quietly does for you, and knowing it makes Compose files much less magical.

Then move to Compose

Once single containers feel normal, write a docker-compose.yml for an app and a database. You'll recognize every piece: image or build, ports, volumes, environment, and a network you never had to create by hand. docker compose up, docker compose logs -f and docker compose down -v cover most of what I do day to day.

Keep a short list of the commands you actually use

Docker has a huge CLI, and I don't try to remember all of it. I keep a short note of the commands and flags I've needed more than once, each with a one-line reason. A few from mine:

• docker system df shows what's eating disk space.
• docker system prune clears stopped containers, unused networks and dangling images.
• docker exec -it <name> sh opens a shell in a running container.
• docker logs --tail 50 -f <name> follows recent logs without dumping everything.
• docker inspect <name> shows the real config when something isn't doing what you expected.

The reason part matters more than the command. "Prune clears stopped containers" sticks better than a bare string of flags.

Come back to it before you forget

The hardest part for me wasn't learning Docker once. It was that I'd go two months without writing a Dockerfile, and by then the layer caching rules and the volume syntax had faded again.

A lot of what eventually made it stick came from conference talks and short videos, which I used to watch once and lose. That's part of why I built Recl. You share a video, reel, podcast or article to it from your phone or the Chrome extension, it summarizes the key points, files it under a topic like "Docker", and brings it back on a spaced schedule so you review it before it slips away. You don't need an app for this, though. A notes file you reread every week or two does a lot of the same job.

If you're starting now, I'd skip the cheat sheet and spend an evening on the experiments above: images versus containers, a Dockerfile you rebuild with the layers in the wrong order, and a database you lose because you forgot the volume. You'll remember those mistakes much longer than any command you copied.

---

I build Recl, an AI learning app that saves your videos, reels, podcasts and articles, summarizes them, sorts them into topics, and uses spaced repetition so you remember what you learned.