Unveiling Docker’s Inner Workings: A Deep Dive into Its Architecture

Docker Internal Build

To understand Docker’s internal build, you need to grasp three components: Docker Image, Docker Container, and Docker Repository. Understanding these concepts gives you insight into Docker’s entire lifecycle.

1) Docker Image Docker images are read‑only templates that can contain a complete OS environment (e.g., Ubuntu) with installed applications. Images are used to create containers, and you can build, update, or pull ready‑made images from others.

2) Docker Container Containers are runtime instances created from images. They can be started, stopped, and deleted, providing isolated, secure environments that include a root user, process space, user space, and network space. Note: containers add a writable layer on top of the read‑only image.

3) Docker Repository Repositories store image files. Public repositories (e.g., Docker Hub) and private repositories allow users to push and pull images. Private repositories can be hosted locally for internal use.

Docker Overall Architecture Breakdown

Docker follows a client‑server (C/S) model. The backend is loosely coupled, with modules that each perform specific duties.

The user interacts with the Docker Client, which communicates with the Docker Daemon.

The Docker Daemon hosts the Server, Engine, and Job components.

1.1 Docker Client The client (the docker executable) sends management requests to the daemon via TCP, Unix socket, or file descriptor. TLS flags can secure the communication.

1.2 Docker Daemon The daemon runs as a background process, accepting and routing client requests. It consists of the Server, Engine, and Job subsystems.

1.3 Docker Server The server receives client requests, creates a mux.Router (using the Gorilla/mux package) for HTTP routing, and spawns a goroutine to handle each request.

1.4 Engine The Engine is the core execution module that manages containers and images. It holds handlers for various jobs, such as create (mapped to daemon.ContainerCreate).

1.5 Job A Job is the smallest unit of work in Docker, analogous to a Unix process, with a name, parameters, I/O, error handling, and exit status.

1.6 Docker Registry The registry stores container images. The daemon communicates with the registry to search, pull, and push images, supporting both public (Docker Hub) and private registries.

1.7 Graph Graph manages downloaded image storage and relationships, using a lightweight SQLite‑based graph database (GraphDB) to record metadata and rootfs information.

1.8 Driver Drivers (graphdriver, networkdriver, execdriver) handle storage, networking, and execution aspects of containers. Graphdriver stores image layers; networkdriver configures bridges, virtual NICs, IPs, and port mappings; execdriver runs container processes (defaulting to the native driver).

1.9 libcontainer libcontainer is a Go library that directly interfaces with kernel container APIs, providing namespace, cgroup, AppArmor, and network management without relying on external tools like LXC.

1.10 Docker Container A Docker container is the final deliverable, created from a specified image, resource quota, network configuration, and command, resulting in an isolated, secure runtime environment.

Understanding Docker’s architecture requires hands‑on practice to fully appreciate each component’s role.