When you type docker run nginx, what is actually happening across the system? Docker is not a single monolithic binary ā it's a distributed client-server architecture composed of several cooperating components.
Component 1: The Docker CLI (docker)
The docker binary is a pure client ā it does no actual container work. Its only job is:
- Accept your commands (
docker run,docker build,docker ps) - Translate them into REST API calls
- Send those calls to the Docker Daemon via a Unix socket
Component 2: The Docker Daemon (dockerd)
The daemon is the heavy-lifting background process. It:
- Listens on the Unix socket (or TCP) for API requests
- Manages the lifecycle of images, containers, networks, and volumes
- Delegates actual container creation to
containerd - Handles image layer downloading, verification, and caching
On Mac and Windows: Docker Desktop runs a lightweight Linux VM (using HyperKit/WSL2), and the Docker Daemon runs inside that VM. Your docker CLI on the Mac talks to the daemon inside the Linux VM.
Component 3: containerd and runc
Under the hood, dockerd delegates the actual container creation to two additional components:
- containerd: An industry-standard container runtime supervisor. It manages the full container lifecycle (create, start, stop, delete), handles image storage, and manages container snapshots. It's also used directly by Kubernetes.
- runc: The lowest-level component.
runcis a CLI tool that actually calls the Linux kernel'sclone()syscall to create namespaces and sets up cgroups. Every container you run is ultimately oneruncprocess.
Component 4: Docker Registry
A registry is a server that stores and distributes Docker images. The default is Docker Hub (docker.io).
Image Naming Convention
Images vs Containers: The Critical Distinction
This is the most important conceptual distinction in Docker:
| Image | Container | |
|---|---|---|
| State | Static, immutable | Running, mutable |
| Analogy | Recipe / Blueprint | The baked cake |
| Disk | Shared read-only layers | +Thin writable layer |
| Lives on | Disk (not running) | CPU + Memory |
| Create from | docker build or docker pull | docker run |
| Delete | docker rmi | docker rm |
| Multiple instances | One image ā 100 containers | Each is independent |
The Image Layer Cache
Images are stored as layers on disk. Docker caches every layer by its SHA256 digest. If two different images share a common layer (e.g., both start with FROM node:20-alpine), that layer is stored once and shared:
This is why updating your app's image to v2 is fast ā only the changed layers are downloaded, not the entire image.
Summary
Docker's architecture has four main components:
- Docker CLI (
docker): Pure client ā translates commands to REST API calls, sends to the daemon - Docker Daemon (
dockerd): The server ā manages images, containers, networks, volumes; delegates to containerd - containerd + runc: The actual container engine ā creates Linux namespaces + cgroups for isolation
- Registry: Image storage and distribution ā Docker Hub is the public default; GHCR, ECR, GAR for private/org images
The Image is the static, read-only blueprint (layers on disk). A Container is a running instance of an image with its own thin writable layer on top. You can run 100 containers from one image ā they all share the image's read-only layers.
In the next lesson, you will run your first container and master the essential Docker CLI commands.