1. The Problem Docker Solves
"It works on my machine!" — the oldest excuse in software. Your app needs a specific Python version, specific libraries, specific config. The server has different ones. Docker fixes this by packing the app plus everything it needs into one sealed box — a container — that runs identically on any machine with Docker installed.
📦 Shipping analogy (the actual origin of the logo): Before shipping containers, loading a ship took days — barrels here, crates there, everything handled differently. The standardized shipping container changed everything: pack anything inside, and every crane, truck and ship in the world can handle it. Docker does that for software: your app is packed once, and any laptop, server or cloud can run it.
2. Containers vs Virtual Machines
A VM ships a whole guest operating system for each app. Containers share the host's OS kernel and isolate only what's needed — so they start in seconds and weigh megabytes, not gigabytes:
| Virtual Machine | Container | |
|---|---|---|
| Boot time | Minutes | Seconds (often < 1s) |
| Size | Gigabytes | Megabytes |
| OS | Full guest OS each | Shares host kernel |
| Isolation | Hardware-level (stronger) | Process-level (lighter) |
| Density | A few per server | Dozens–hundreds per server |
3. The Architecture — Client, Daemon, Registry
Three players are involved every time you use Docker:
- Docker CLI (client) — the
dockercommand you type. It does nothing itself; it just sends requests. - Docker daemon (dockerd) — the engine running in the background. It builds images, starts containers, does all the real work.
- Registry (Docker Hub) — the "app store" of images. The daemon pulls images from it and can push yours to it.
4. Animated: What Happens on docker run nginx
Press ▶ Play and follow the request through the whole system:
Ready — press Play to run "docker run nginx".
✅ The 5 steps: ① CLI sends the request to the daemon → ② daemon checks local images → ③ not found? pull from Docker Hub → ④ create a container from the image → ⑤ start the process inside it. Second time you run it, step ③ is skipped — the image is cached locally.
5. Image vs Container — the #1 Beginner Confusion
🎂 Analogy: An image is the recipe + all ingredients, frozen (read-only, shareable, stored on disk). A container is the cake actually baking — a live, running instance. From one image you can run 10 containers, just like one recipe can bake 10 cakes.
| Image | Container | |
|---|---|---|
| State | Read-only template | Live, running (or stopped) instance |
| Created by | docker build / docker pull | docker run / docker create |
| Listed with | docker images | docker ps -a |
| How many | One per app version | As many as you want from the same image |
6. Vocabulary You'll See Everywhere
| Term | Meaning | Analogy |
|---|---|---|
| Image | Read-only app template (app + libs + OS files) | Frozen recipe |
| Container | Running instance of an image | Cake being baked |
| Dockerfile | Text file with instructions to build an image | The written recipe |
| Registry | Server storing/sharing images (Docker Hub) | Cookbook store |
| Tag | Version label on an image (nginx:1.25) | Edition number |
| Daemon | Background engine doing the real work | The kitchen staff |
| Volume | Persistent storage outside the container | The pantry (survives) |