Docker架构及组件剖析
Docker整体架构
Docker 整体架构采用 C/S（客户端 / 服务器）模式，主要由客户端和服务端两大部分组成。客户端负责发送操作指令，服务端负责接收和处理指令。客户端和服务端通信有多种方式，既可以在同一台机器上通过UNIX套接字通信，也可以通过网络连接远程通信。
Docker 客户端
Docker 客户端其实是一种泛称。其中 docker 命令是 Docker 用户与 Docker 服务端交互的主要方式。除了使用 docker 命令的方式，还可以使用直接请求 REST API 的方式与 Docker 服务端交互，甚至还可以使用各种语言的 SDK 与 Docker 服务端交互。目前社区维护着 Go、Java、Python、PHP 等数十种语言的 SDK，足以满足你的日常需求。
Docker 服务端
Docker 服务端是 Docker 所有后台服务的统称。其中 dockerd 是一个非常重要的后台管理进程，它负责响应和处理来自 Docker 客户端的请求，然后将客户端的请求转化为 Docker 的具体操作。例如镜像、容器、网络和挂载卷等具体对象的操作和管理。
Docker 从诞生到现在，服务端经历了多次架构重构。起初，服务端的组件是全部集成在 docker 二进制里。但是从 1.11 版本开始， dockerd 已经成了独立的二进制，此时的容器也不是直接由 dockerd 来启动了，而是集成了 containerd、runC 等多个组件。
虽然 Docker 的架构在不停重构，但是各个模块的基本功能和定位并没有变化。它和一般的 C/S 架构系统一样，Docker 服务端模块负责和 Docker 客户端交互，并管理 Docker 的容器、镜像、网络等资源。
Docker 组件剖析
下面，我以 Docker 的 18.09.2 版本为例，看下 Docker 都有哪些工具和组件。Docker 的二进制默认安装在 /usr/bin/ 目录下，在此路径执行 ls 命令可以看到以下与 docker 有关的二进制文件 。
注：该目录下有非常多文件，以下列出的只是跟docker有关的二进制文件。
-rwxr-xr-x 1 root root 27941976 Dec 12 2019 containerd -rwxr-xr-x 1 root root 4964704 Dec 12 2019 containerd-shim -rwxr-xr-x 1 root root 15678392 Dec 12 2019 ctr -rwxr-xr-x 1 root root 50683148 Dec 12 2019 docker -rwxr-xr-x 1 root root 764144 Dec 12 2019 docker-init -rwxr-xr-x 1 root root 2837280 Dec 12 2019 docker-proxy -rwxr-xr-x 1 root root 54320560 Dec 12 2019 dockerd -rwxr-xr-x 1 root root 7522464 Dec 12 2019 runc
可以看到，Docker 目前已经有了非常多的组件和工具。
这些组件根据工作职责可以分为以下三大类。
- Docker 相关的组件：docker、dockerd、docker-init 和 docker-proxy
- containerd 相关的组件：containerd、containerd-shim 和 ctr
- 容器运行时相关的组件：runc
下面我们就逐一了解。
Docker 相关的组件
(1) docker
docker 是 Docker 客户端的一个完整实现，它是一个二进制文件，对用户可见的操作形式为 docker 命令，通过 docker 命令可以完成所有的 Docker 客户端与服务端的通信（还可以通过 REST API、SDK 等多种形式与 Docker 服务端通信）。
Docker 客户端与服务端的交互过程是：docker 组件向服务端发送请求后，服务端根据请求执行具体的动作并将结果返回给 docker，docker 解析服务端的返回结果，并将结果通过命令行标准输出展示给用户。这样一次完整的客户端服务端请求就完成了。
(2) dockerd
dockerd 是 Docker 服务端的后台常驻进程，用来接收客户端发送的请求，执行具体的处理任务，处理完成后将结果返回给客户端。
Docker 客户端可以通过多种方式向 dockerd 发送请求，我们常用的 Docker 客户端与 dockerd 的交互方式有三种。
- 通过 UNIX 套接字与服务端通信：配置格式为unix://socket_path，默认 dockerd 生成的 socket 文件路径为 /var/run/docker.sock，该文件只有 root 用户或者 docker 用户组的用户才可以访问，这就是为什么 Docker 刚安装完成后只有 root 用户才能使用 docker 命令的原因。
- 通过 TCP 与服务端通信：配置格式为tcp://host:port，通过这种方式可以实现客户端远程连接服务端，但是在方便的同时也带有安全隐患，因此在生产环境中如果你要使用 TCP 的方式与 Docker 服务端通信，推荐使用 TLS 认证，可以通过设置 Docker 的 TLS 相关参数，来保证数据传输的安全。
- 通过文件描述符的方式与服务端通信：配置格式为：fd://这种格式一般用于 systemd 管理的系统中。
Docker 客户端和服务端的通信形式必须保持一致，否则将无法通信，只有当 dockerd 监听了 UNIX 套接字客户端才可以使用 UNIX 套接字的方式与服务端通信，UNIX 套接字也是 Docker 默认的通信方式，如果你想要通过远程的方式访问 dockerd，可以在 dockerd 启动的时候添加 -H 参数指定监听的 HOST 和 PORT。
(3) docker-init
如果你熟悉 Linux 系统，你应该知道在 Linux 系统中，1 号进程是 init 进程，是所有进程的父进程。主机上的进程出现问题时，init 进程可以帮我们回收这些问题进程。同样的，在容器内部，当我们自己的业务进程没有回收子进程的能力时，在执行 docker run 启动容器时可以添加 --init 参数，此时 Docker 会使用 docker-init 作为1号进程，帮你管理容器内子进程，例如回收僵尸进程等。
下面我们通过启动一个 busybox 容器来演示下：
$ docker run -it busybox sh / # ps aux PID USER TIME COMMAND 1 root 0:00 sh 6 root 0:00 ps aux / #
可以看到容器启动时如果没有添加 --init 参数，1 号进程就是 sh 进程。
我们使用 Crtl + D 退出当前容器，重新启动一个新的容器并添加 --init 参数，然后看下进程：
$ docker run -it --init busybox sh / # ps aux PID USER TIME COMMAND 1 root 0:00 /sbin/docker-init -- sh 6 root 0:00 sh 7 root 0:00 ps aux
可以看到此时容器内的 1 号进程已经变为 /sbin/docker-init，而不再是 sh 了。
(4) docker-proxy
docker-proxy 主要是用来做端口映射的。当我们使用 docker run 命令启动容器时，如果使用了 -p 参数，docker-proxy 组件就会把容器内相应的端口映射到主机上来，底层是依赖于 iptables 实现的。
下面我们通过一个实例演示下。
使用以下命令启动一个 nginx 容器并把容器的 80 端口映射到主机的 8080 端口。（因为nginx的默认端口是80）
$ docker run --name=nginx -d -p 8080:80 nginx
然后通过以下命令查看一下启动的容器 IP：
$ docker inspect --format '{{ .NetworkSettings.IPAddress }}' nginx 172.17.0.2
可以看到，我们启动的 nginx 容器 IP 为 172.17.0.2。
此时，我们使用 ps 命令查看一下主机上是否有 docker-proxy 进程：
$ sudo ps aux |grep docker-proxy root 9100 0.0 0.0 290772 9160 ? Sl 07:48 0:00 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 8080 -container-ip 172.17.0.2 -container-port 80 root 9192 0.0 0.0 112784 992 pts/0 S+ 07:51 0:00 grep --color=auto docker-proxy
可以看到当我们启动一个容器时需要端口映射时， Docker 为我们创建了一个 docker-proxy 进程，并且通过参数把我们的容器 IP 和端口传递给 docker-proxy 进程，然后 docker-proxy 通过 iptables 实现了 nat 转发。
我们通过以下命令查看一下主机上 iptables nat 表的规则：
$ sudo iptables -L -nv -t nat Chain PREROUTING (policy ACCEPT 35 packets, 2214 bytes) pkts bytes target prot opt in out source destination 398 21882 DOCKER all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type LOCAL Chain INPUT (policy ACCEPT 35 packets, 2214 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 1 packets, 76 bytes) pkts bytes target prot opt in out source destination 0 0 DOCKER all -- * * 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE match dst-type LOCAL Chain POSTROUTING (policy ACCEPT 1 packets, 76 bytes) pkts bytes target prot opt in out source destination 0 0 MASQUERADE all -- * !docker0 172.17.0.0/16 0.0.0.0/0 0 0 MASQUERADE tcp -- * * 172.17.0.2 172.17.0.2 tcp dpt:80 Chain DOCKER (2 references) pkts bytes target prot opt in out source destination 0 0 RETURN all -- docker0 * 0.0.0.0/0 0.0.0.0/0 0 0 DNAT tcp -- !docker0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 to:172.17.0.2:80
通过最后一行规则我们可以得知，当我们访问主机的 8080 端口时，iptables 会把流量转发到 172.17.0.2 的 80 端口，从而实现了我们从主机上可以直接访问到容器内的业务。
我们通过 curl 命令访问一下 nginx 容器：
$ curl http://localhost:8080 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html>
通过上面的输出可以得知我们已经成功访问到了 nginx 容器。
总体来说，docker 是官方实现的标准客户端，dockerd 是 Docker 服务端的入口，负责接收客户端发送的指令并返回相应结果，而 docker-init 在业务主进程没有进程回收功能时则十分有用，docker-proxy 组件则是实现 Docker 网络访问的重要组件。
了解完 docker 相关的组件，下面我来介绍下 containerd 相关的组件。
containerd 相关的组件
（1）containerd
containerd 不仅负责容器生命周期的管理，同时还负责一些其他的功能：
- 镜像的管理，例如容器运行前从镜像仓库拉取镜像到本地；
- 接收 dockerd 的请求，通过适当的参数调用 runc 启动容器；
- 管理存储相关资源；
- 管理网络相关资源。
containerd 包含一个后台常驻进程，默认的 socket 路径为 /run/containerd/containerd.sock，dockerd 通过 UNIX 套接字向 containerd 发送请求，containerd 接收到请求后负责执行相关的动作并把执行结果返回给 dockerd。
如果你不想使用 dockerd，也可以直接使用 containerd 来管理容器，由于 containerd 更加简单和轻量，生产环境中越来越多的人开始直接使用 containerd 来管理容器。
（2）containerd-shim
containerd-shim 的意思是垫片，类似于拧螺丝时夹在螺丝和螺母之间的垫片。containerd-shim 的主要作用是将 containerd 和真正的容器进程解耦，使用 containerd-shim 作为容器进程的父进程，从而实现重启 dockerd或containerd 不影响已经启动的容器进程。
（3）ctr
ctr 实际上是 containerd-ctr，它是 containerd 的客户端，主要用来开发和调试，在没有 dockerd 的环境中，ctr 可以充当 docker 客户端的部分角色，直接向 containerd 守护进程发送操作容器的请求。
了解完 containerd 相关的组件，我们来了解一下容器的真正运行时 runc。
容器运行时组件runc
runc 是一个标准的 OCI 容器运行时的实现，它是一个命令行工具，可以直接用来创建和运行容器。
下面我们通过一个实例来演示一下 runc 的神奇之处。
第一步，准备容器运行时文件：进入 /home/centos 目录下，创建 runc 文件夹，并导入 busybox 镜像文件。
$ cd /home/centos
## 创建 runc 运行根目录
$ mkdir runc
## 导入 rootfs 镜像文件
$ mkdir rootfs && docker export $(docker create busybox) | tar -C rootfs -xvf -
第二步，生成 runc config 文件。我们可以使用 runc spec 命令根据文件系统生成对应的 config.json 文件。命令如下：
$ runc spec
此时会在当前目录下生成 config.json 文件，我们可以使用 cat 命令查看一下 config.json 的内容：
$ cat config.json { "ociVersion": "1.0.1-dev", "process": { "terminal": true, "user": { "uid": 0, "gid": 0 }, "args": [ "sh" ], "env": [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "TERM=xterm" ], //后面部分省略...
config.json 文件定义了 runc 启动容器时的一些配置，如根目录的路径，文件挂载路径等配置。
第三步，使用 runc 启动容器。我们可以使用 runc run 命令直接启动 busybox 容器。
$ runc run busybox
/ #
此时，我们已经创建并启动了一个 busybox 容器。
我们新打开一个命令行窗口，可以使用 run list 命令看到刚才启动的容器。
$ cd /home/centos/runc/ $ runc list D PID STATUS BUNDLE CREATED OWNER busybox 9778 running /home/centos/runc 2020-09-06T09:25:32.441957273Z root
通过上面的输出，我们可以看到，当前已经有一个 busybox 容器处于运行状态。
总体来说，Docker 的组件虽然很多，但每个组件都有自己清晰的工作职责，Docker 相关的组件负责发送和接受 Docker 请求，contianerd 相关的组件负责管理容器的生命周期，而 runc 负责真正意义上创建和启动容器。这些组件相互配合，才使得 Docker 顺利完成了容器的管理工作。
Docker 各组件之间的关系
首先通过以下命令来启动一个 busybox 容器：
$ docker run -d busybox sleep 3600
容器启动后，通过以下命令查看一下 dockerd 的 PID：
$ sudo ps aux |grep dockerd
root 4147 0.3 0.2 1447892 83236 ? Ssl Jul09 245:59 /usr/bin/dockerd
通过上面的输出结果可以得知 dockerd 的 PID 为 4147。为了验证图 3 中 Docker 各组件之间的调用关系，下面使用 pstree 命令查看一下进程父子关系：
$ sudo pstree -l -a -A 4147
dockerd
|-containerd --config /var/run/docker/containerd/containerd.toml --log-level info
| |-containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/d14d20507073e5743e607efd616571c834f1a914f903db6279b8de4b5ba3a45a -address /var/run/docker/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc
| | |-sleep 3600
事实上，dockerd 启动的时候， containerd 就随之启动了，dockerd 与 containerd 一直存在。当执行 docker run 命令（通过 busybox 镜像创建并启动容器）时，containerd 会创建 containerd-shim 充当 “垫片”进程，然后启动容器的真正进程 sleep 3600 。(containerd-shim 的主要作用是将 containerd 和真正的容器进程解耦，使用 containerd-shim 作为容器进程的父进程，从而实现重启 dockerd或containerd 不影响已经启动的容器进程)。这个过程和架构图是完全一致的。
注意： docker 19.03.12 版本的 dockerd 和containerd 组件已经不是父子关系，可以使用以下命令查看，sudo ps aux |grep containerd , 然后使用 pstree 查看 containerd 的 PID。
本文源自：拉勾教育课程：由浅入深吃透 Docker，讲师：郭少 前 360 高级容器技术专家
