docker：架构拆解

 近期很多朋友都在学习docker，笔者也是在慢慢学习中。当大家在终端飞快的敲击docker的这些命令时：
  docker ps
  docker run
  docker image
  docker pull
  ......

 大家有没有思考过，当使用这些命令时究竟发生了什么？它是一个怎样的执行流程、它的架构又是怎样呢？一起来了解一下吧。

Docker架构

 Docker使用了传统的cs架构模式（cilent-server），架构图如下图所示。用户通过Docker client与Docker daemon建立通信，并将请求发送给后者。而Docker的后端是松耦合结构，不同模块各司其职，有机组合，完成用户的请求。

 从上图中可以看出，Docker daemon是Docker架构中的主要用户接口。首先，它提供了API Server用于接收来自于Docker client的请求，其后根据不同的请求分发给Docker daemon的不同模块执行相应的工作，其中对容器运行时、volume、镜像以及网络方面的具体实现放在daemon以外的模块或项目中（其中libcontainer、libnetwork已经成为单独项目，独立于docker项目。而volimedriver、distribution、registry、layer、image、reference只是相对独立的代码模块）。值得注意的是，Docker一直致力于将其进一步解耦，削减Docker daemon的功能，熟悉Docker早期版本的朋友在对照上面的架构图时一定要注意到了这种变化。

 Docker通过driver模块来实现对Docker容器执行环境的创建和管理：

• 当需要创建Docker容器时，可通过镜像管理（image management）部分的distribution和registry模块从Docker registry中下载镜像，并通过镜像管理的image、refernce和layer存储镜像的元数据，通过镜像存储驱动graphdriver将镜像文件存储于具体的文件中；

• 当需要为容器创建数据卷volume时，通过volume模块来调用某个具体的volumedriver，来创建一个数据卷并负责后续的挂载操作；

• 当需要限制Docker容器运行资源或执行用户指令等操作时， 则通过execdriver来完成。libcontainer是对cgroups和namespace的二次封装，execdriver是通过libcontainer来实现对容器的具体管理，包括利用UTS、IPC、PID、Netwrok、Mount、User等namespace实现容器之间的资源隔离和利用cgoups实现对容器的资源限制。

 当运行容器的命令执行完毕后，一个实际的容器就处于运行状态，该容器拥有独立的文件系统、相对安全且相互隔离的运行环境。Docker 1.9版本以后，volume、network的生命周期都是独立于容器的，与容器一样是Docker中的一等公民，Docker用户可以单独增删改查volume或network，然后在创建容器的时候根据需要配置给容器。

  下面对各个模块的功能进行介绍一下。

Docker daemon

 Docker daemon是Docker最核心的后台进程，它负责响应来自Docker client的请求，然后将这些请求翻译成系统调用完成容器管理操作。该进程会在后台启动一个API Server，负责接收由Docker client发送的请求；接收到的请求将通过Docker daemon分发调度，再由具体的函数来执行请求。

Docker client

 Docker client是一个泛称，用来向Docker daemon发起请求，执行相应的容器管理操作。它既可以是命令行工具docker，也可以是任何遵循了Docker API的客户端。目前，社区中维护着的Docker client种类非常丰富，涵盖了包括C#、 Java、Go、Ruby、JavaScript等常用语言，甚至还有使用Angular库编写的WebUI格式的客户端，足以满足大多数据用户的需求。

image management

 Docker通过distribution、registry、layer、image、reference等模块实现了Docker镜像的管理，我们将这些模块统称为镜像管理（image management）。在Docker 1.10以前的版本中，这一功能通过graph组件来完成的。下面简单介绍一下：

• distribution负责与Docker registry交互，上传下载镜像以及存储v2 registry有关的元数据。
• registry模块负责与Docker registry有关的身份验证、镜像查找、镜像验证以及管理registry mirror等交互操作。
• image模块负责与镜像元数据有关的存储、查找，镜像层的索引、查找以及镜像tar包有关的导入、导出等操作。
• reference负责存储本地所有镜像的repository和tag名，并维护与镜像ID之间的映射关系。
• layer模块负责与镜像层和容器层元数据有关的增删查改，并负责将镜像层的增删查改操作映射到实际存储镜像层文件系统的graphdriver模块。

execdriver、volumedriver、graphdriver

 前面提到，Docker daemon负责将用户请求转译成系统调用，进而创建和管理容器。而在具体实现过程中，为了将这些系统调用抽象成为统一的操作接口方便调用者使用，Docker把这些操作分成了容器执行驱动、volume存储驱动、镜像存储驱动这3种，分别对应execdriver、volumedriver、graphdriver：

• execdriver是对Linux系统的namespaces、cgroups、apparmor、SELinux等容器运行所需的系统操作进行的一层二次封装，其本质作用类似于LXC，但是功能要更全面。这也就是为什么LXC会作为execdriver的一种实现而存在。当然，execdriver最主要的实现，也是现在的默认实现，是Docker官方编写的libcontainer库。
• volumedriver是volume数据卷存储操作的最终执行者，负责volume的增删改查，屏蔽不同驱动实现的区别，为上层调用者提供一个统一的接口。Docker中作为默认实现的volumedriver是local，默认将文件存储于Docker根目录下的volume文件夹里。其他的volumedriver均是通过外部插件实现的。
• graphdriver是所有与容器镜像相关操作的最终执行者。graphdriver会在Docker工作目录下维护一组与镜像层对应的目录，并记下镜像层之间的关系以及与具体的graphdriver实现相关的元数据。这样，用户对镜像的操作最终会被映射成对应这些目录文件以及元数据的增删改查，从而屏蔽掉不同文件存储实现对于上层调用者的影响。在Linux环境下，目前Docker已经支持graphdriver包括aufs、btrfs、zfs、overlay和vfs。

network

 在Docker 1.9版本以前，网络是通过networkdriver模块以及libcontainer库完成的，现在这部分功能已经分离成一个libnetwork库独立维护了，可参考 https://github.com/docker/libnetwork 。libnetwork抽象出了一个容器网络模型（Container Network Model，CNM），并给调用者提供了一个抽象接口，其目标不权限于Docker容器。CNM模型对真实的容器网络抽象出了沙盒（sandbox）、端点（endpoint）、网络（network）这3种对象，由具体网络驱动（包括内置的Bridge、Host、None和overlay驱动以及通过插件配置的外部驱动）操作对象，并通过网络控制器提供一个统一接口供调用者管理网络。网络驱动负责实现具体的操作，包括创建容器通信所需的网络，容器的network namespace，这个网络所需的虚拟网卡，分配通信所需的IP，服务访问的端口和容器与宿主机之间的端口映射，设置hosts、resolv.conf、iptables等。

喜欢我的文章，请点击最上方右角处的《关注》支持一下！