Unveiling Docker 1.2: Deep Dive into Its Architecture and Core Components

1. Docker Overview

Docker is an open‑source container engine developed by Docker Inc. in Go, licensed under Apache 2.0. It uses kernel namespaces and cgroups for isolation, offering lightweight virtualization that avoids the overhead of full VMs, improving resource utilization and I/O performance.

Because of its novel features and openness, Docker quickly attracted major vendors such as Google, Microsoft, and VMware. Google released Kubernetes for Docker scheduling, Microsoft added Kubernetes support on Azure, and VMware announced a partnership with Docker. In September Docker raised $40 million in Series C funding to advance distributed applications.

The outlook for Docker is very positive, and the following sections detail its architecture.

Docker Version Information

This analysis is based on Docker source code and runtime results for the latest 1.2 version.

2. Organization of the Architecture Analysis

The goal is to analyze Docker’s architecture based on its source code, following three steps:

1. Show the overall architecture diagram. 2. Analyze each module’s function and implementation. 3. Illustrate the runtime flow using Docker commands as examples.

3. Overall Architecture Diagram

Docker follows a client‑server (C/S) model with a loosely coupled backend. The client communicates with the Docker Daemon, which coordinates various jobs.

The client sends requests to the Docker Daemon. The daemon hosts a Server, an Engine, and Jobs. Jobs request images from the Docker Registry, store them via the graphdriver, create network environments via networkdriver, and execute commands via execdriver. libcontainer provides the low‑level container management APIs used by the drivers.

4. Detailed Module Functions and Implementation

Key modules include Docker Client, Docker Daemon, Docker Registry, Graph, Driver, libcontainer, and Docker container.

Docker Client

The Docker Client (the docker CLI) sends management requests to the Daemon over TCP, Unix socket, or file descriptor. TLS flags can secure the transport. After the request is processed, the client exits; a new client must be created for subsequent requests.

Docker Daemon

The Daemon runs as a background process, accepting and handling client requests. It consists of a Server, an Engine, and Jobs. The Server routes HTTP requests using gorilla/mux, dispatching them to appropriate handlers.

Docker Server

The Server serves the client, creating an http.Server that listens on the configured address and uses the mux router to dispatch requests to handlers, each running in its own goroutine.

Engine

The Engine is the core execution component, maintaining a map of job handlers such as {"create": daemon.ContainerCreate}.

Job

A Job is the smallest unit of work inside the Engine, analogous to a Unix process, with a name, parameters, I/O streams, and exit status.

Docker Registry

The Registry stores container images. Docker Daemon interacts with it to search, pull, and push images, supporting both the public Docker Hub and private registries.

Graph

Graph manages downloaded images and records their relationships using a lightweight SQLite‑based graph database (GraphDB). It also stores metadata, size, and rootfs information for each image.

Driver

Drivers separate container management concerns. Three drivers exist:

graphdriver – handles image storage and retrieval.

networkdriver – configures container networking, bridges, veth devices, IP allocation, and firewall rules.

execdriver – creates namespaces, enforces resource limits, and runs user commands. The default is the native driver.

libcontainer

libcontainer is a Go library that directly accesses kernel container APIs (namespaces, cgroups, AppArmor, network devices) without relying on external tools like LXC. It provides a standard interface for higher‑level components and can be used across platforms, which is why Docker is also supported on Microsoft Azure.

Docker Container

The container is the final delivery unit. Users can customize rootfs, resource quotas, network and security policies, and the command to run.

1. Specify an image to define the container’s root filesystem. 2. Allocate CPU/memory quotas. 3. Configure isolated networking and security. 4. Provide the command to execute inside the container.

5. Runtime Case Studies

docker pull

The docker pull command downloads an image from a Registry and stores it in the Graph. The flow includes client request, server routing, job creation, image download, and storage via graphdriver.

docker run

The docker run command creates a container and executes a command. It involves two HTTP requests: one to create the container (graphdriver provides the rootfs) and another to start it (networkdriver configures networking, execdriver runs the command via libcontainer).

6. Conclusion

This article examined Docker 1.2 source code, extracted an architecture diagram, analyzed each module’s role and implementation, and demonstrated internal operations through docker pull and docker run examples. Understanding Docker’s design deepens insight into container technology and informs cloud‑native PaaS development.