Docker Architecture Overview
Docker is built as a client-server application. The Docker CLI (client) sends commands to the Docker daemon (server), which does the actual work of building images, running containers, and managing networks and volumes. Understanding this architecture makes it much easier to reason about what happens when you type a command like docker run.
Cricket analogy: The Docker CLI is like a captain calling out field placements from the boundary, while the Docker daemon is like the twelfth man who actually runs onto the field and repositions the fielders; understanding this split makes it clear who does the real work when you shout a command like 'docker run'.
The Docker Daemon (dockerd)
The Docker daemon, dockerd, is a background process that listens for API requests and manages Docker objects such as images, containers, networks, and volumes. It can listen on a Unix socket (the default, /var/run/docker.sock) or a network socket. Most docker CLI commands are simply REST API calls sent to this daemon.
Cricket analogy: The Docker daemon dockerd is like the ground curator who's always on-site managing the pitch, nets, and equipment store, listening for requests from any team official, whether they walk up in person (Unix socket) or call in from another city (network socket).
The docker command you type in your terminal is the client. It translates your commands into API calls and sends them to the daemon, which can be running locally or on a remote host. A single client can communicate with multiple daemons, which is how tools like Docker Contexts let you target different environments.
Cricket analogy: The docker client is like the team manager phoning instructions to different grounds; one manager can call the curator of the home ground or a touring ground remotely, which is how a single manager can coordinate multiple venues, similar to Docker Contexts.
# Inspect how the client talks to the daemon
$ docker version
Client: Docker Engine - Community
Version: 25.0.3
API version: 1.44
Server: Docker Engine - Community
Engine:
Version: 25.0.3
API version: 1.44 (minimum version 1.24)
Kernel Version: 6.5.0-genericcontainerd and runc
Under the hood, dockerd does not directly create containers itself — it delegates to containerd, a high-level container runtime that manages the container lifecycle (image transfer, storage, execution). containerd, in turn, uses runc, a low-level OCI-compliant runtime that does the actual work of creating namespaces, cgroups, and starting the container process. This layered design follows the Open Container Initiative (OCI) standards, which is why images built by Docker can also run under other OCI-compatible tools like Podman or Kubernetes' containerd/CRI-O runtimes.
Cricket analogy: dockerd is like the team's head coach who doesn't personally bowl the nets but delegates to the bowling coach (containerd), who in turn hands the ball to the actual net bowler (runc) who does the real work of delivering each delivery under standardized ICC rules, which is why practice drills also work with other certified coaching staff.
The chain of responsibility is: Docker CLI → dockerd (REST API) → containerd (lifecycle management) → runc (creates namespaces/cgroups and starts the process). Each layer has a narrower, more specialized job than the one above it.
Images, Containers, and Registries
A Docker image is a read-only template built from a Dockerfile, made up of stacked, cacheable layers. A container is a runnable instance of an image with a thin writable layer on top. A registry (such as Docker Hub, GitHub Container Registry, or Amazon ECR) is a storage and distribution service for images, organized into repositories and tags.
Cricket analogy: A Docker image is like a printed team strategy playbook that never changes once published, a container is like a live match being played out from that playbook with its own scorecard being written in real time, and a registry like Docker Hub is like the league's official archive where every team's playbooks are stored and versioned by season.
# Pull an image from a registry, then run a container from it
$ docker pull nginx:1.25-alpine
$ docker run -d --name web -p 8080:80 nginx:1.25-alpine
$ docker ps
CONTAINER ID IMAGE COMMAND STATUS PORTS
a1b2c3d4e5f6 nginx:1.25-alpine "/docker-entrypoint.…" Up 5 seconds 0.0.0.0:8080->80/tcpThe default Docker daemon socket (/var/run/docker.sock) is typically only accessible to root and members of the docker group. Granting a user access to this socket is effectively equivalent to giving them root on the host, because the daemon runs with root privileges — treat docker group membership as a security-sensitive permission. Putting it together: when you run docker run -d --name web -p 8080:80 nginx:1.25-alpine, the CLI sends a request to dockerd, which pulls the image if needed, asks containerd to create and start the container, containerd calls runc to set up namespaces and cgroups and launch the process, and finally dockerd sets up networking (port 8080 on the host mapped to port 80 in the container).
- Docker uses a client-server architecture: the docker CLI talks to the dockerd daemon over a REST API.
- dockerd delegates container lifecycle management to containerd, which uses runc to create namespaces/cgroups.
- This layered design follows OCI standards, enabling interoperability with other container runtimes.
- Images are read-only, layered templates; containers are running instances with a writable layer.
- Registries like Docker Hub store and distribute images, organized as repositories and tags.
- Access to the Docker socket is equivalent to root access on the host, so it must be tightly controlled.
Practice what you learned
1. What is the role of the `docker` CLI in Docker's architecture?
2. Which component actually creates namespaces and cgroups to start a container process?
3. What does containerd manage in the Docker architecture?
4. What is a Docker registry?
5. Why is access to the Docker daemon socket considered a security-sensitive permission?
Was this page helpful?
You May Also Like
What Is Containerization?
An introduction to containerization as a lightweight, OS-level virtualization technique for packaging and running applications with their dependencies.
Installing and Using the Docker CLI
A practical guide to installing Docker and using its core CLI commands for pulling images, running containers, and inspecting Docker's state.
Docker Images Explained
An introduction to what Docker images are, how they differ from containers, and how their layered, read-only filesystem structure works.
Container Registries
How container registries store, version, and distribute Docker images, covering tagging conventions, authentication, and push/pull workflows.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics