Docker Architecture Overview and Component Analysis

01 Docker Overall Architecture

Docker follows a client‑server (C/S) model where the Docker Client communicates with the Docker Daemon. The architecture is loosely coupled, with each module performing a specific function.

1. The user uses the Docker Client to send requests to the Docker Daemon. 2. Docker Daemon acts as the server, receiving and dispatching client requests. 3. Docker Engine executes a series of jobs that constitute Docker's internal work. 4. When a job requires an image, it is pulled from Docker Registry and stored via the Graphdriver. 5. Networkdriver creates and configures the container network environment. 6. Execdriver handles resource limits and command execution. 7. Libcontainer provides the underlying container management functions used by Networkdriver and Execdriver.

02 Docker Component Analysis

2.1 Docker Client – Request Initiator

The Docker Client (the docker CLI) establishes communication with the Docker Daemon via tcp://host:port, unix://pathtosocket, or fd://socketfd. It sends container management commands (e.g., docker images) and receives responses, completing a request lifecycle of send → process → reply.

2.2 Docker Daemon – Background Service

The Daemon (Docker Server) receives requests from the client, routes them using a gorilla/mux router, creates an http.Server, and spawns a goroutine to handle each request. Handlers parse the request, invoke the appropriate logic, and return results.

2.3 Docker Engine

Docker Engine is the core execution engine. It treats each operation as a Job (e.g., container creation, image pull). Handlers for specific jobs are stored in a map such as {"create": daemon.ContainerCreate}. Jobs are designed similarly to Unix processes, with names, arguments, environment, I/O, and exit status.

2.4 Docker Registry (Image Repository)

The Registry is a storage service for container images. It can be public (Docker Hub) or private. Docker Daemon interacts with the Registry to search, pull, and push images, using jobs named “search”, “pull”, and “push”.

2.5 Graph – Docker’s Internal Metadata Store

Graph maintains metadata about downloaded images, including repository information, tags, size, and root filesystem details. It records relationships between images and containers.

2.6 Drivers – Execution Layer

Graphdriver manages image storage and retrieval. Networkdriver creates bridge networks, virtual NICs, IP allocation, port mapping, and firewall rules for containers. Execdriver creates namespaces, tracks resource usage, and runs container processes. The default Execdriver is the native driver, not dependent on LXC.

2.7 Libcontainer – Go Library

Libcontainer is a Go library that directly interfaces with kernel APIs for namespaces, cgroups, AppArmor, networking, and firewall rules, providing a clean abstraction for Docker’s upper layers.

2.8 Docker Container – Final Service Delivery

A Docker Container is the end‑result of the architecture. Users specify an image, resource quotas, network configuration, and the command to run, resulting in an isolated, reproducible runtime environment.

All the above information is compiled from the original "Docker source code analysis" and organized for readers.