Docker Course
What is Docker
Somewhere right now, a developer is saying "it works on my machine" while the server is on fire. Docker exists to make that sentence extinct — and by the end of this lesson, you'll understand exactly how.
Before we touch a single command, let's talk about the real problem Docker solves. Because Docker isn't just a tool — it's the answer to a question that has tortured development teams for decades: why does software behave differently depending on where it runs?
You install Node 18 on your laptop. The server is running Node 14. Your app uses a library that behaves differently on Ubuntu vs macOS. A new team member spends their entire first day just trying to get the project to run locally. Sound familiar? This is the environment problem, and it is as old as software itself.
The Shipping Container Analogy
Think about global shipping before the 1950s. Every ship was a different size. Every port had different cranes. Loading cargo was a custom operation every single time — slow, expensive, and error-prone. Then the shipping container was invented. A standard steel box that looked the same, loaded the same, and unloaded the same — no matter if the ship was leaving Shanghai, Rotterdam, or New York.
Docker does exactly this for software. It packages your application — your code, its dependencies, its runtime, its configuration — into a single standardized unit called a container. That container runs identically on your laptop, your colleague's machine, a test server in Germany, and a production cluster on AWS. The environment stops being a variable.
Images vs Containers — The Recipe and the Cake
Two terms you'll hear constantly: image and container. They are different things, and confusing them is the number-one beginner mistake.
A Docker image is like a cake recipe. It contains all the instructions — what ingredients you need, in what order to combine them, at what temperature to bake. The recipe itself doesn't feed anyone. But you can follow it as many times as you want to produce identical cakes.
A Docker container is the actual cake you baked from that recipe. It's a running, live instance. You can bake a hundred cakes from one recipe — and each one is identical. You can run a hundred containers from one image, and each one behaves the same way.
Images are stored and shared. Containers are created, run, stopped, and deleted. Images are static. Containers are alive.
How Docker Actually Works — The Three-Part Architecture
When you type a Docker command, three things are involved. Understanding this architecture prevents a lot of confusion later on.
The CLI sends your command to the Daemon via a REST API. The Daemon builds, runs, and manages containers. When it needs an image, it pulls from a Registry.
The Docker CLI is what you interact with — the docker commands you type in your terminal. It doesn't actually do anything itself. It's a messenger that forwards your instructions to the real engine.
The Docker Daemon (also called dockerd) is a background process running on your machine. It's the brain — it builds images, creates containers, manages networks, handles storage. When you type docker run, the CLI calls the Daemon, and the Daemon makes it happen.
The Registry is where images are stored and shared. Docker Hub is the public registry — think of it like GitHub but for Docker images. When you run an image you don't have locally, Docker pulls it from the registry automatically.
Seeing It in Action — Your First docker run
The scenario: You're a backend developer who just joined a startup. Your tech lead says "just run the app with Docker — one command and you're done." You've never used Docker before. You're looking at a terminal and wondering what happens next. This is that moment.
docker run hello-world
# docker → the CLI tool we're using
# run → tell the Daemon to create and start a container
# hello-world → the name of the image to use (pulled from Docker Hub if not local)
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
719385e32844: Pull complete
Digest: sha256:88ec0acaa3ec199d3b7efd73ee5f0002f9b6bab36d57c93d2d7c2bdc3e01c2
Status: Downloaded newer image for hello-world:latest
Hello from Docker!
This message shows that your installation appears to be working correctly.
To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.
What just happened?
The first line — "Unable to find image locally" — is Docker telling you it checked your machine first and didn't find hello-world. So it went to Docker Hub (the public registry) and pulled it down. That's the pull step.
Then it created a container from that image and ran it. The container printed its message and exited. The whole thing — pull, create, run, exit — happened in one command. That's the power of docker run. It's not just "run a container" — it's "find the image, pull it if needed, create a container, and start it." Four steps, one command.
Run the same command again right now and notice something: the "Pulling" lines disappear. Docker already has the image locally — so it skips the pull entirely and just runs the container. This is the image cache at work.
Running Something More Interesting
The scenario: Your team's documentation site runs on nginx. You need to spin up a local copy to test a CSS change — right now, on your laptop — without installing nginx, without touching your system config, without asking DevOps for access to the test server. You need it in 30 seconds.
docker run -d -p 8080:80 --name docs-preview nginx
# -d → detached mode: run the container in the background, not blocking our terminal
# -p 8080:80 → port mapping: forward requests on our machine's port 8080 to port 80 inside the container
# --name → give the container a human-readable name instead of a random one
# docs-preview → our chosen container name
# nginx → the image to use (official nginx image from Docker Hub)Unable to find image 'nginx:latest' locally latest: Pulling from library/nginx 09f376ebb190: Pull complete 5529e0792248: Pull complete 9b3addd3eb3d: Pull complete 57910a8c4316: Pull complete Digest: sha256:32da30332506740a2f7c34d5dc70467b7f14ec67d6f819779a03b3b95ba5 Status: Downloaded newer image for nginx:latest a3f2c8d91e44b7e1a4c52f889201cd3f
What just happened?
The long string at the end — a3f2c8d91e44... — is the container ID. Docker prints it to confirm the container was created and is running. That's it. nginx is now running inside a container on your machine.
The -d flag is why your terminal prompt came back immediately. Without it, the terminal would be locked — nginx would run in the foreground and you couldn't type anything else. Detached mode is how you run long-lived services like web servers, databases, and APIs.
The -p 8080:80 flag is the bridge between your machine and the container. The container has its own isolated network — by default nothing can reach it from outside. Port mapping opens a door: traffic hitting port 8080 on your laptop gets forwarded to port 80 inside the container where nginx is listening. Open your browser right now and go to http://localhost:8080. You'll see the nginx welcome page — served from inside a container.
Checking What's Running
docker ps
# docker ps → list all currently RUNNING containers
# (use docker ps -a to also see stopped and exited containers)CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a3f2c8d91e44 nginx "/docker-entrypoint.…" 3 minutes ago Up 3 minutes 0.0.0.0:8080->80/tcp docs-preview
What just happened?
docker ps is your window into what's currently running. The output table is something you'll read dozens of times a day as a Docker user. The columns that matter most: STATUS (is it actually up?), PORTS (what ports are exposed?), and NAMES (which container is which).
See 0.0.0.0:8080->80/tcp in the PORTS column? That's the port mapping we set — your machine's port 8080 is forwarding to the container's port 80. The arrow tells the whole story. And the container name docs-preview is there because we gave it one with --name. Without that flag, Docker would have generated something random like elegant_hopper or cranky_turing.
BEFORE Docker — The Pain
- New team member: half a day setting up their environment
- "Works on my machine" — broken on the server
- Python 3.9 on dev, Python 3.11 on prod — subtle bugs everywhere
- Installing software directly onto your system — conflicts pile up
- Onboarding doc is 47 steps long and always out of date
AFTER Docker — The Fix
- New team member:
docker runand they're running in 2 minutes - Same container image runs identically everywhere
- Exact versions locked inside the image — no drift
- Containers are isolated — nothing touches your system
- Onboarding is one command in a README
Teacher's Note
Stop thinking about software as something you install — start thinking about it as something you package and ship. That one shift changes how you build everything from here on.
Practice Questions
1. A Docker image is like a recipe. What do we call the running instance created from that image?
2. What flag do you add to docker run to start a container in the background (detached mode)?
3. What command lists all currently running containers?
Quiz
1. You run docker run nginx on a machine that has never used Docker before. What happens?
2. Which part of Docker's architecture actually builds images and manages running containers?
3. What is the key difference between a Docker image and a Docker container?
Up Next · Lesson 2
Problems with Traditional Deployment
See exactly what breaks in a world without Docker — and why every team hits the same wall eventually.