Docker Architecture Overview: Overall Structure and Component Analysis

Docker follows a client‑server (C/S) model with a loosely coupled backend where each module has a distinct responsibility. The overall architecture consists of Docker Client, Docker Daemon (Server), Docker Engine, Docker Registry, storage and network drivers, Libcontainer, and Docker Containers.

Docker Client is the command‑line executable (e.g., docker images) that communicates with Docker Daemon via tcp://host:port, unix://path-to-socket, or fd://socketfd. It sends container‑management requests and terminates after receiving the response.

Docker Daemon (Server) receives these requests, uses the gorilla/mux router to map HTTP methods and URLs to handlers, creates an http.Server, and processes each request in a separate goroutine, ultimately returning the result to the client.

Docker Engine executes the core work of Docker as a series of Jobs. Each Job represents an atomic operation (e.g., creating a container, pulling an image) and is handled by a specific function defined in a handler map such as {"create": daemon.ContainerCreate}.

Docker Registry acts as a repository for container images, supporting search, pull, and push operations. It can be public (Docker Hub) or private, and images are identified by [repository]:[tag].

The Graph component stores metadata of downloaded images, while GraphDB, built on SQLite, records relationships between images and containers.

Drivers provide the execution layer: Graphdriver manages image storage and retrieval; Networkdriver configures container networking (bridge creation, virtual NICs, IP/port mapping, firewall rules); Execdriver (default native driver) creates namespaces, limits resources, and runs container processes.

Libcontainer is a Go library that directly interfaces with kernel APIs to manage namespaces, cgroups, AppArmor, network devices, and firewall rules, offering a standardized interface for higher‑level Docker components.

Docker Container is the final delivery unit. Users define the image, resource quotas, network settings, and the command to run, resulting in an isolated, reproducible runtime environment.