Docker Architecture Overview and Component Analysis

1. Docker Overall Architecture

Docker follows a client‑server (C/S) model where the Docker Client communicates with the Docker Daemon, which coordinates various internal modules to manage containers, images, networks and resources.

The Docker Client sends requests to the Docker Daemon via tcp://host:port , unix://path_to_socket or fd://socketfd .

The Docker Daemon receives the request, schedules it through the Engine, and may interact with the Docker Registry to pull or push images.

The Engine executes jobs; each job represents a unit of work such as creating a container, pulling an image, or serving the API.

When an image is needed, the Daemon downloads it from the Docker Registry and stores it using the graphdriver .

Network configuration is handled by the networkdriver , and resource limits or command execution are managed by the execdriver .

The low‑level library libcontainer provides the actual namespace, cgroup, AppArmor and network device operations used by the drivers.

2. Detailed Component Analysis

(1) Docker Client

The client is the docker executable; users invoke commands such as docker images or docker run. It establishes communication with the daemon using one of the three endpoints mentioned above, sends the request, receives the response and terminates.

(2) Docker Daemon

The daemon hosts the Docker Server, which creates a mux.Router (from the gorilla/mux package) to route HTTP methods (PUT, POST, GET, DELETE) to appropriate handlers. An http.Server instance runs Serve() to accept client connections, spawning a goroutine per request to parse, route and handle it.

(3) Engine

The Engine is the core runtime that stores containers and executes jobs. Handlers such as {"create": daemon.ContainerCreate} map job names to Go functions that perform the actual work.

(4) Job

A Job is the smallest execution unit in Docker, analogous to a Unix process, with a name, arguments, environment, I/O streams and exit status. Examples include image pull, container creation, and the server’s own serveapi job.

(5) Docker Registry

The Registry is a remote image store accessed via docker pull and docker push. It supports public (Docker Hub) and private repositories, identified by [repository]:[tag].

(6) Graph (Docker’s internal database)

Graph manages image storage (AUFS, devicemapper, Btrfs, etc.) and metadata. It consists of a Repository layer that tracks downloaded images and a GraphDB built on SQLite that records relationships between images.

(7) Drivers

Three drivers implement specific functions:

graphdriver stores and retrieves image layers.

networkdriver creates bridge networks, virtual NICs, IP allocation and port mapping.

execdriver (default native) creates namespaces, enforces resource limits and runs container processes.

(8) libcontainer

libcontainer

is a Go library that directly interfaces with kernel APIs for namespaces, cgroups, AppArmor and networking, providing a clean abstraction for the higher‑level Docker components.

(9) Docker Container

The final deliverable is a Docker container, built from an image, configured with specific resources, network policies and a command to execute.

Reference: “Docker Source Code Analysis”.