Docker源码分析（一）：Docker架构-InfoQ

【编者按】在《深入浅出 Docker》系列文章的基础上，InfoQ 推出了《Docker 源码分析》系列文章。《深入浅出 Docker》系列文章更多的是从使用角度出发，帮助读者了解 Docker 的来龙去脉，而《Docker 源码分析》系列文章通过分析解读 Docker 源码，来让读者了解 Docker 的内部实现，以更好的使用 Docker。总之，我们的目标是促进 Docker 在国内的发展以及传播。另外，欢迎加入 InfoQ Docker 技术交流群，QQ 群号：272489193。

1 背景

1.1 Docker 简介

Docker 是 Docker 公司开源的一个基于轻量级虚拟化技术的容器引擎项目, 整个项目基于 Go 语言开发，并遵从 Apache 2.0 协议。目前，Docker 可以在容器内部快速自动化部署应用，并可以通过内核虚拟化技术（namespaces 及 cgroups 等）来提供容器的资源隔离与安全保障等。由于 Docker 通过操作系统层的虚拟化实现隔离，所以 Docker 容器在运行时，不需要类似虚拟机（VM）额外的操作系统开销，提高资源利用率，并且提升诸如 IO 等方面的性能。

由于众多新颖的特性以及项目本身的开放性，Docker 在不到两年的时间里迅速获得诸多厂商的青睐，其中更是包括 Google、Microsoft、VMware 等业界行业领导者。 Google 在今年六月份推出了 Kubernetes ，提供 Docker 容器的调度服务，而今年 8 月 Microsoft 宣布 Azure 上支持 Kubernetes ，随后传统虚拟化巨头VMware 宣布与Docker 强强合作。今年9 月中旬， Docker 更是获得 4000 万美元的 C 轮融资，以推动分布式应用方面的发展。

从目前的形势来看，Docker 的前景一片大好。本系列文章从源码的角度出发，详细介绍 Docker 的架构、Docker 的运行以及 Docker 的卓越特性。本文是 Docker 源码分析系列的第一篇——Docker 架构篇。

1.2 Docker 版本信息

本文关于 Docker 架构的分析都是基于 Docker 的源码与 Docker 相应版本的运行结果，其中 Docker 为最新的 1.2 版本。

2 Docker 架构分析内容安排

本文的目的是：在理解 Docker 源代码的基础上，分析 Docker 架构。分析过程中主要按照以下三个步骤进行：

Docker 的总架构图展示
Docker 架构图内部各模块功能与实现分析
以 Docker 命令的执行为例，进行 Docker 运行流程阐述

3 Docker 总架构图

学习 Docker 的源码并不是一个枯燥的过程，反而可以从中理解 Docker 架构的设计原理。Docker 对使用者来讲是一个 C/S 模式的架构，而 Docker 的后端是一个非常松耦合的架构，模块各司其职，并有机组合，支撑 Docker 的运行。

在此，先附上 Docker 总架构，如图 3.1。

图 3.1 Docker 总架构图

如图 3.1，不难看出，用户是使用 Docker Client 与 Docker Daemon 建立通信，并发送请求给后者。

而 Docker Daemon 作为 Docker 架构中的主体部分，首先提供 Server 的功能使其可以接受 Docker Client 的请求；而后 Engine 执行 Docker 内部的一系列工作，每一项工作都是以一个 Job 的形式的存在。

Job 的运行过程中，当需要容器镜像时，则从 Docker Registry 中下载镜像，并通过镜像管理驱动 graphdriver 将下载镜像以 Graph 的形式存储；当需要为 Docker 创建网络环境时，通过网络管理驱动 networkdriver 创建并配置 Docker 容器网络环境；当需要限制 Docker 容器运行资源或执行用户指令等操作时，则通过 execdriver 来完成。

而 libcontainer 是一项独立的容器管理包，networkdriver 以及 execdriver 都是通过 libcontainer 来实现具体对容器进行的操作。

当执行完运行容器的命令后，一个实际的 Docker 容器就处于运行状态，该容器拥有独立的文件系统，独立并且安全的运行环境等。

4 Docker 架构内各模块的功能与实现分析

接下来，我们将从 Docker 总架构图入手，抽离出架构内各个模块，并对各个模块进行更为细化的架构分析与功能阐述。主要的模块有：Docker Client、Docker Daemon、Docker Registry、Graph、Driver、libcontainer 以及 Docker container。

4.1 Docker Client

Docker Client 是 Docker 架构中用户用来和 Docker Daemon 建立通信的客户端。用户使用的可执行文件为 docker，通过 docker 命令行工具可以发起众多管理 container 的请求。

Docker Client 可以通过以下三种方式和 Docker Daemon 建立通信：tcp://host:port，unix://path_to_socket 和 fd://socketfd。为了简单起见，本文一律使用第一种方式作为讲述两者通信的原型。与此同时，与 Docker Daemon 建立连接并传输请求的时候，Docker Client 可以通过设置命令行 flag 参数的形式设置安全传输层协议 (TLS) 的有关参数，保证传输的安全性。

Docker Client 发送容器管理请求后，由 Docker Daemon 接受并处理请求，当 Docker Client 接收到返回的请求相应并简单处理后，Docker Client 一次完整的生命周期就结束了。当需要继续发送容器管理请求时，用户必须再次通过 docker 可执行文件创建 Docker Client。

4.2 Docker Daemon

Docker Daemon 是 Docker 架构中一个常驻在后台的系统进程，功能是：接受并处理 Docker Client 发送的请求。该守护进程在后台启动了一个 Server，Server 负责接受 Docker Client 发送的请求；接受请求后，Server 通过路由与分发调度，找到相应的 Handler 来执行请求。

Docker Daemon 启动所使用的可执行文件也为 docker，与 Docker Client 启动所使用的可执行文件 docker 相同。在 docker 命令执行时，通过传入的参数来判别 Docker Daemon 与 Docker Client。

Docker Daemon 的架构，大致可以分为以下三部分：Docker Server、Engine 和 Job。Daemon 架构如图 4.1。

图 4.1 Docker Daemon 架构示意图

4.2.1 Docker Server

Docker Server 在 Docker 架构中是专门服务于 Docker Client 的 server。该 server 的功能是：接受并调度分发 Docker Client 发送的请求。Docker Server 的架构如图 4.2。

图 4.2 Docker Server 架构示意图

在 Docker 的启动过程中，通过包 gorilla/mux，创建了一个 mux.Router，提供请求的路由功能。在 Golang 中，gorilla/mux 是一个强大的 URL 路由器以及调度分发器。该 mux.Router 中添加了众多的路由项，每一个路由项由 HTTP 请求方法（PUT、POST、GET 或 DELETE）、URL、Handler 三部分组成。

若 Docker Client 通过 HTTP 的形式访问 Docker Daemon，创建完 mux.Router 之后，Docker 将 Server 的监听地址以及 mux.Router 作为参数，创建一个 httpSrv=http.Server{}，最终执行 httpSrv.Serve() 为请求服务。

在 Server 的服务过程中，Server 在 listener 上接受 Docker Client 的访问请求，并创建一个全新的 goroutine 来服务该请求。在 goroutine 中，首先读取请求内容，然后做解析工作，接着找到相应的路由项，随后调用相应的 Handler 来处理该请求，最后 Handler 处理完请求之后回复该请求。

需要注意的是：Docker Server 的运行在 Docker 的启动过程中，是靠一个名为"serveapi"的 job 的运行来完成的。原则上，Docker Server 的运行是众多 job 中的一个，但是为了强调 Docker Server 的重要性以及为后续 job 服务的重要特性，将该"serveapi"的 job 单独抽离出来分析，理解为 Docker Server。

4.2.2 Engine

Engine 是 Docker 架构中的运行引擎，同时也 Docker 运行的核心模块。它扮演 Docker container 存储仓库的角色，并且通过执行 job 的方式来操纵管理这些容器。

在 Engine 数据结构的设计与实现过程中，有一个 handler 对象。该 handler 对象存储的都是关于众多特定 job 的 handler 处理访问。举例说明，Engine 的 handler 对象中有一项为：{“create”: daemon.ContainerCreate,}，则说明当名为"create"的 job 在运行时，执行的是 daemon.ContainerCreate 的 handler。

4.2.3 Job

一个 Job 可以认为是 Docker 架构中 Engine 内部最基本的工作执行单元。Docker 可以做的每一项工作，都可以抽象为一个 job。例如：在容器内部运行一个进程，这是一个 job；创建一个新的容器，这是一个 job，从 Internet 上下载一个文档，这是一个 job；包括之前在 Docker Server 部分说过的，创建 Server 服务于 HTTP 的 API，这也是一个 job，等等。

Job 的设计者，把 Job 设计得与 Unix 进程相仿。比如说：Job 有一个名称，有参数，有环境变量，有标准的输入输出，有错误处理，有返回状态等。

4.3 Docker Registry

Docker Registry 是一个存储容器镜像的仓库。而容器镜像是在容器被创建时，被加载用来初始化容器的文件架构与目录。

在 Docker 的运行过程中，Docker Daemon 会与 Docker Registry 通信，并实现搜索镜像、下载镜像、上传镜像三个功能，这三个功能对应的 job 名称分别为"search"，“pull” 与 “push”。

其中，在 Docker 架构中，Docker 可以使用公有的 Docker Registry，即大家熟知的 Docker Hub ，如此一来，Docker 获取容器镜像文件时，必须通过互联网访问 Docker Hub；同时 Docker 也允许用户构建本地私有的 Docker Registry，这样可以保证容器镜像的获取在内网完成。

4.4 Graph

Graph 在 Docker 架构中扮演已下载容器镜像的保管者，以及已下载容器镜像之间关系的记录者。一方面，Graph 存储着本地具有版本信息的文件系统镜像，另一方面也通过 GraphDB 记录着所有文件系统镜像彼此之间的关系。Graph 的架构如图 4.3。

图 4.3 Graph 架构示意图

其中，GraphDB 是一个构建在 SQLite 之上的小型图数据库，实现了节点的命名以及节点之间关联关系的记录。它仅仅实现了大多数图数据库所拥有的一个小的子集，但是提供了简单的接口表示节点之间的关系。

同时在 Graph 的本地目录中，关于每一个的容器镜像，具体存储的信息有：该容器镜像的元数据，容器镜像的大小信息，以及该容器镜像所代表的具体 rootfs。

4.5 Driver

Driver 是 Docker 架构中的驱动模块。通过 Driver 驱动，Docker 可以实现对 Docker 容器执行环境的定制。由于 Docker 运行的生命周期中，并非用户所有的操作都是针对 Docker 容器的管理，另外还有关于 Docker 运行信息的获取，Graph 的存储与记录等。因此，为了将 Docker 容器的管理从 Docker Daemon 内部业务逻辑中区分开来，设计了 Driver 层驱动来接管所有这部分请求。

在 Docker Driver 的实现中，可以分为以下三类驱动：graphdriver、networkdriver 和 execdriver。

graphdriver 主要用于完成容器镜像的管理，包括存储与获取。即当用户需要下载指定的容器镜像时，graphdriver 将容器镜像存储在本地的指定目录；同时当用户需要使用指定的容器镜像来创建容器的 rootfs 时，graphdriver 从本地镜像存储目录中获取指定的容器镜像。

在 graphdriver 的初始化过程之前，有 4 种文件系统或类文件系统在其内部注册，它们分别是 aufs、btrfs、vfs 和 devmapper。而 Docker 在初始化之时，通过获取系统环境变量”DOCKER_DRIVER”来提取所使用 driver 的指定类型。而之后所有的 graph 操作，都使用该 driver 来执行。

graphdriver 的架构如图 4.4：

图 4.4 graphdriver 架构示意图

networkdriver 的用途是完成 Docker 容器网络环境的配置，其中包括 Docker 启动时为 Docker 环境创建网桥；Docker 容器创建时为其创建专属虚拟网卡设备；以及为 Docker 容器分配 IP、端口并与宿主机做端口映射，设置容器防火墙策略等。networkdriver 的架构如图 4.5：

图 4. 5 networkdriver 架构示意图

execdriver 作为 Docker 容器的执行驱动，负责创建容器运行命名空间，负责容器资源使用的统计与限制，负责容器内部进程的真正运行等。在 execdriver 的实现过程中，原先可以使用 LXC 驱动调用 LXC 的接口，来操纵容器的配置以及生命周期，而现在 execdriver 默认使用 native 驱动，不依赖于 LXC。具体体现在 Daemon 启动过程中加载的 ExecDriverflag 参数，该参数在配置文件已经被设为"native"。这可以认为是 Docker 在 1.2 版本上一个很大的改变，或者说 Docker 实现跨平台的一个先兆。execdriver 架构如图 4.6：

图 4.6 execdriver 架构示意图

4.6 libcontainer

libcontainer 是 Docker 架构中一个使用 Go 语言设计实现的库，设计初衷是希望该库可以不依靠任何依赖，直接访问内核中与容器相关的 API。

正是由于 libcontainer 的存在，Docker 可以直接调用 libcontainer，而最终操纵容器的 namespace、cgroups、apparmor、网络设备以及防火墙规则等。这一系列操作的完成都不需要依赖 LXC 或者其他包。libcontainer 架构如图 4.7：

图 4.7 libcontainer 示意图

另外，libcontainer 提供了一整套标准的接口来满足上层对容器管理的需求。或者说，libcontainer 屏蔽了 Docker 上层对容器的直接管理。又由于 libcontainer 使用 Go 这种跨平台的语言开发实现，且本身又可以被上层多种不同的编程语言访问，因此很难说，未来的 Docker 就一定会紧紧地和 Linux 捆绑在一起。而于此同时，Microsoft 在其著名云计算平台 Azure 中，也添加了对 Docker 的支持，可见 Docker 的开放程度与业界的火热度。

暂不谈 Docker，由于 libcontainer 的功能以及其本身与系统的松耦合特性，很有可能会在其他以容器为原型的平台出现，同时也很有可能催生出云计算领域全新的项目。

4.7 Docker container

Docker container（Docker 容器）是 Docker 架构中服务交付的最终体现形式。

Docker 按照用户的需求与指令，订制相应的 Docker 容器：

用户通过指定容器镜像，使得 Docker 容器可以自定义 rootfs 等文件系统；
用户通过指定计算资源的配额，使得 Docker 容器使用指定的计算资源；
用户通过配置网络及其安全策略，使得 Docker 容器拥有独立且安全的网络环境；
用户通过指定运行的命令，使得 Docker 容器执行指定的工作。

Docker 容器示意图如图 4.8：

图 4.8 Docker 容器示意图

5 Docker 运行案例分析

上一章节着重于 Docker 架构中各个部分的介绍。本章的内容，将以串联 Docker 各模块来简要分析，分析原型为 Docker 中的 docker pull 与 docker run 两个命令。

5.1 docker pull

docker pull 命令的作用为：从 Docker Registry 中下载指定的容器镜像，并存储在本地的 Graph 中，以备后续创建 Docker 容器时的使用。docker pull 命令执行流程如图 5.1。

图 5.1 docker pull 命令执行流程示意图

如图，图中标记的红色箭头表示 docker pull 命令在发起后，Docker 所做的一系列运行。以下逐一分析这些步骤。

(1) Docker Client 接受 docker pull 命令，解析完请求以及收集完请求参数之后，发送一个 HTTP 请求给 Docker Server，HTTP 请求方法为 POST，请求 URL 为"/images/create? "+“xxx”；

(2) Docker Server 接受以上 HTTP 请求，并交给 mux.Router，mux.Router 通过 URL 以及请求方法来确定执行该请求的具体 handler；

(3) mux.Router 将请求路由分发至相应的 handler，具体为 PostImagesCreate；

(4) 在 PostImageCreate 这个 handler 之中，一个名为"pull"的 job 被创建，并开始执行；

(5) 名为"pull"的 job 在执行过程中，执行 pullRepository 操作，即从 Docker Registry 中下载相应的一个或者多个 image；

(6) 名为"pull"的 job 将下载的 image 交给 graphdriver；

(7) graphdriver 负责将 image 进行存储，一方创建 graph 对象，另一方面在 GraphDB 中记录 image 之间的关系。

5.2 docker run

docker run 命令的作用是在一个全新的 Docker 容器内部运行一条指令。Docker 在执行这条命令的时候，所做工作可以分为两部分：第一，创建 Docker 容器所需的 rootfs；第二，创建容器的网络等运行环境，并真正运行用户指令。因此，在整个执行流程中，Docker Client 给 Docker Server 发送了两次 HTTP 请求，第二次请求的发起取决于第一次请求的返回状态。Docker run 命令执行流程如图 5.2。

图 5.2 docker run 命令执行流程示意图

如图，图中标记的红色箭头表示 docker run 命令在发起后，Docker 所做的一系列运行。以下逐一分析这些步骤。

(1) Docker Client 接受 docker run 命令，解析完请求以及收集完请求参数之后，发送一个 HTTP 请求给 Docker Server，HTTP 请求方法为 POST，请求 URL 为"/containers/create? "+“xxx”；

(2) Docker Server 接受以上 HTTP 请求，并交给 mux.Router，mux.Router 通过 URL 以及请求方法来确定执行该请求的具体 handler；

(3) mux.Router 将请求路由分发至相应的 handler，具体为 PostContainersCreate；

(4) 在 PostImageCreate 这个 handler 之中，一个名为"create"的 job 被创建，并开始让该 job 运行；

(5) 名为"create"的 job 在运行过程中，执行 Container.Create 操作，该操作需要获取容器镜像来为 Docker 容器创建 rootfs，即调用 graphdriver；

(6) graphdriver 从 Graph 中获取创建 Docker 容器 rootfs 所需要的所有的镜像；

(7) graphdriver 将 rootfs 所有镜像，加载安装至 Docker 容器指定的文件目录下；

(8) 若以上操作全部正常执行，没有返回错误或异常，则 Docker Client 收到 Docker Server 返回状态之后，发起第二次 HTTP 请求。请求方法为"POST"，请求 URL 为"/containers/"+container_ID+"/start"；

(9) Docker Server 接受以上 HTTP 请求，并交给 mux.Router，mux.Router 通过 URL 以及请求方法来确定执行该请求的具体 handler；

(10)mux.Router 将请求路由分发至相应的 handler，具体为 PostContainersStart；

(11) 在 PostContainersStart 这个 handler 之中，名为"start"的 job 被创建，并开始执行；

(12) 名为"start"的 job 执行完初步的配置工作后，开始配置与创建网络环境，调用 networkdriver；

(13)networkdriver 需要为指定的 Docker 容器创建网络接口设备，并为其分配 IP，port，以及设置防火墙规则，相应的操作转交至 libcontainer 中的 netlink 包来完成；

(14)netlink 完成 Docker 容器的网络环境配置与创建；

(15) 返回至名为"start"的 job，执行完一些辅助性操作后，job 开始执行用户指令，调用 execdriver；

(16)execdriver 被调用，初始化 Docker 容器内部的运行环境，如命名空间，资源控制与隔离，以及用户命令的执行，相应的操作转交至 libcontainer 来完成；

(17)libcontainer 被调用，完成 Docker 容器内部的运行环境初始化，并最终执行用户要求启动的命令。

6 总结

本文从 Docker 1.2 的源码入手，分析抽象出 Docker 的架构图，并对该架构图中的各个模块进行功能与实现的分析，最后通过两个 docker 命令展示了 Docker 内部的运行。

通过对 Docker 架构的学习，可以全面深化对 Docker 设计、功能与价值的理解。同时在借助 Docker 实现用户定制的分布式系统时，也能更好地找到已有平台与 Docker 较为理想的契合点。另外，熟悉 Docker 现有架构以及设计思想，也能对云计算 PaaS 领域带来更多的启发，催生出更多实践与创新。

7 作者简介

孙宏亮， DaoCloud 初创团队成员，软件工程师，浙江大学 VLIS 实验室应届研究生。读研期间活跃在 PaaS 和 Docker 开源社区，对 Cloud Foundry 有深入研究和丰富实践，擅长底层平台代码分析，对分布式平台的架构有一定经验，撰写了大量有深度的技术博客。2014 年末以合伙人身份加入 DaoCloud 团队，致力于传播以 Docker 为主的容器的技术，推动互联网应用的容器化步伐。邮箱： allen.sun@daocloud.io