Chapter 1 — What is Docker, and why does it matter?

Course: Docker (Zero to Hero) · Chapter: 1 of 8 Read on the website: learn.bazardev.com/docker/01-what-is-docker

🇧🇩 Prefer Bangla? Read this chapter in Bangla →

Nothing to install for this chapter — it's pure concept. But get this right, because every later chapter builds on it.

1. The problem Docker solves

Every developer has lived through this:

• You build something on your laptop. It works perfectly.
• You deploy it to a server — and it breaks. "It works on my machine", but not here.
• The reason: your laptop has PHP 8.3, the server has PHP 8.1. A library is installed locally but missing on the server. Your OS is Ubuntu, your teammate's is Windows.

This is the classic "works on my machine" problem — one of the most common and most frustrating issues in software development.

The old solutions:

• Virtual Machines (VMs) — spin up a whole virtual computer, full OS included. It works, but it's heavy: a single VM can need 2-4 GB of RAM, takes minutes to boot, and running 5-6 VMs on one server eats all the resources.
• A detailed setup document — "follow these steps to set up the server." Manual, error-prone, and goes stale the moment someone forgets to update it.

Docker solves this problem differently — lightweight, fast, and guaranteed to be consistent.

2. What is a container (the concept)

A container packages an application — its code, dependencies (libraries, runtime versions), and configuration — into a single box, so that wherever that box runs (laptop, server, cloud), it behaves exactly the same way.

A simple analogy: the shipping container. Before standardized shipping containers, cargo of every shape and size had to be loaded and unloaded by hand — slow and inefficient. Then came the standard-size shipping container: whatever is inside — cloth, electronics, food — it all goes into the same-shaped box. Any ship, truck, or train can handle that same box, because the shape is fixed. A Docker container does the same thing for software — whatever it is, it gets packaged into the same kind of "box," so it runs the same way everywhere.

VM vs Container — what's actually different?

Common misconception: a container is not a "mini VM." A container actually shares the host machine's same OS kernel — it just wraps processes in an isolated "bubble" (its own filesystem, network, process list) while sharing the kernel underneath. That's exactly why containers are so lightweight and fast.

3. What is Docker, specifically?

"Container" is a general concept — built on Linux kernel features (namespaces + cgroups) that Docker did not invent. But Docker built the tool that made containers genuinely easy to use — so well, in fact, that "container" and "Docker" are now almost synonymous in everyday conversation.

Docker is made up of a few parts:

• Docker Engine — a background service (dockerd) that actually creates, runs, and stops containers.
• Docker CLI — when you type docker run or docker build in your terminal, the CLI acts as a client telling the Engine what to do.
• Docker Image — a read-only "blueprint" / snapshot: your app plus its dependencies plus the OS files it needs. (Covered in depth in Chapter 3.)
• Docker Container — the live, running instance you get when you "run" an image. (You can run multiple containers from the same image.)
• Docker Hub — an online registry (like GitHub, but for images) where you can download (pull) ready-made images, and upload (push) your own.

The simplest way to put it:

Image = a recipe (instructions + ingredients) Container = the actual plate of food made from that recipe

Cook from the same recipe (image) as many times as you want, and the result (container) tastes the same every time — predictable and consistent.

4. Docker's architecture — how it actually works

 ┌──────────────┐        commands       ┌───────────────────┐
 │  Docker CLI   │ ────────────────────▶ │   Docker Daemon     │
 │ (docker run..)│                       │     (dockerd)        │
 └──────────────┘                       └─────────┬───────────┘
                                                     │
                            ┌────────────────────────┼─────────────────────────┐
                            ▼                        ▼                         ▼
                     ┌─────────────┐          ┌─────────────┐           ┌─────────────┐
                     │  Image A     │          │  Container 1 │           │  Container 2 │
                     │ (blueprint)  │ ───run──▶│ (running)    │           │ (running)     │
                     └─────────────┘          └─────────────┘           └─────────────┘
                            ▲
                            │ pull / push
                     ┌─────────────┐
                     │ Docker Hub   │  (registry — images stored online)
                     └─────────────┘

The flow is always the same:

1. You give the CLI a command (e.g. docker run nginx).
2. The CLI forwards it to the Daemon.
3. The Daemon checks whether the image already exists locally — if not, it pulls it from Docker Hub.
4. A container starts from that image — a running, isolated process.

5. Why companies and developers actually use Docker

• Consistency — no more "works on my machine." Dev, staging, and production all run the same container, so behavior is identical everywhere.
• Fast onboarding — a new teammate joins, runs docker compose up, and every service (app, database, cache) comes up together — no manual setup documentation needed.
• Microservices-friendly — splitting a large app into smaller services (payment service, auth service, notification service) and running each in its own container is straightforward.
• Built for CI/CD — automated testing and deployment pipelines can guarantee the test environment and the production environment are exactly the same.
• Resource efficient — far more services fit on the same hardware compared to VMs, which lowers hosting costs.
• Easy rollback — if a new version has a problem, going back to the container built from the previous image is simple.

6. What's ahead in this course (roadmap preview)

7. Key takeaways

• A container packages an app + its dependencies + its config into one portable "box."
• A VM virtualizes a full OS (heavy); a container shares the host's OS kernel (light, fast).
• Docker is the most popular tool for building/running/managing containers (Engine + CLI + Image + Container + Hub).
• An image is the static blueprint; a container is the live, running instance.
• The core benefit: consistency — run it anywhere, get the same behavior.

8. Test yourself (exam prep)

Ask yourself these — if you can't answer, re-read the relevant section above.

9. Free resources

• Official docs: Docker Get Started guide
• YouTube: "Docker Tutorial for Beginners [FULL COURSE in 3 Hours]" — channel: TechWorld with Nana
• YouTube: "Docker Tutorial for Beginners - A Full DevOps Course" — channel: freeCodeCamp.org

Next: Chapter 2 — Install Docker + Your First Container → (coming soon)