Before any tool, the problem. Containers were not invented because someone wanted a new thing to learn. They were invented because of a specific, boring, expensive kind of pain that shows up everywhere software is written.

Picture a few situations you have probably already lived through.

A NEW PERSON JOINS THE TEAM. Their first day is supposed to be writing code. Instead it is three days of installing things: the right language version, a database, some tool nobody remembers needing. The setup guide is nine months out of date. Two steps fail for reasons specific to their laptop.

TWO PROJECTS DISAGREE. One needs Node 18. The other needs Node 24. They are both on your machine. You now maintain a version manager and think about it every time you switch folders.

IT WORKS HERE BUT NOT THERE. The tests pass on your machine and fail in CI. Nobody can explain why, so someone spends an afternoon adding print statements to a build server.

THE HANDOFF. You finish something and give it to whoever runs the servers. They ask what it needs. You write a list. The list is wrong, because you have forgotten the four things you installed months ago and now take for granted.

Every one of these is the same problem wearing different clothes: a program needs a specific world around it to run, that world is mostly invisible to the person who built it, and describing it in prose does not work.

A container is that world, captured. Not described in a README, not reproduced by hand, but packaged into one thing that behaves the same wherever it runs. That is genuinely the whole idea. Everything else in this course is detail.

The next lessons assume you have never run a Docker command. You will run someone else's container, pause to understand what that was, keep one running so you can look at it, then build one of your own. If you already know Docker and only want this project's fleet, skip ahead to "The system you're about to learn on".