【docker架构系列】docker V1.12架构图
1.docker整体架构图
也就是说，一条docker命令的工作过程：
- Docker 客户端向 docker daemon 发送请求（Docker 客户端与 dockerd（docker daemon）之间就是通过 REST 的方式通信的。）
- 容器镜像的下载是由 dockerd 完成的。
- 容器的创建和运行就需要 containerd(docker-containerd) 来完成了（Dockerd 与 docker-containerd 之间是通过 grpc 协议通信的）
- 当 docker-containerd 收到 dockerd 启动容器的请求之后，会做一些初始化工作，然后启动 docker-containerd-shim 进程，并将相关配置作为参数传给它。
- docker-containerd 负责管理所有本机正在运行的容器，
- 一个 docker-containerd-shim 进程只负责管理一个运行的容器，它相当于 docker-runc 的一个封装，充当 docker-containerd 和 docker-runc 之间的桥梁，
- docker-runc 能干的就交给 docker-runc 来做，docker-runc 做不了的就放到这里来做。
2docker各个组件的说明如下
2.1、Docker CLI(docker)
docker 程序是一个客户端工具，用来把用户的请求发送给 docker daemon(dockerd)。该程序的安装路径为：
/usr/bin/docker |
2.2、Dockerd
docker daemon(dockerd)，一般也会被称为 docker engine。该程序的安装路径为：
/usr/bin/dockerd |
2.3、Containerd
/usr/bin/docker-containerd |
这里展开说一下：
从图中可以看出，docker 对容器的管理和操作基本都是通过 containerd 完成的。 那么，containerd 是什么呢？
containerd 是一个工业级标准的容器运行时，它强调简单性、健壮性和可移植性。Containerd 可以在宿主机中管理完整的容器生命周期：容器镜像的传输和存储、容器的执行和管理、存储和网络等。详细点说，Containerd 负责干下面这些事情：
- 管理容器的生命周期(从创建容器到销毁容器)
- 拉取/推送容器镜像
- 存储管理(管理镜像及容器数据的存储)
- 调用 runC 运行容器(与 runC 等容器运行时交互)
- 管理容器网络接口及网络
注意：Containerd 被设计成嵌入到一个更大的系统中，而不是直接由开发人员或终端用户使用。
为什么需要 containerd？我们可以从下面几点来理解为什么需要独立的 containerd： - 继续从整体 docker 引擎中分离出的项目(开源项目的思路)
- 可以被 Kubernets CRI 等项目使用(通用化)
- 为广泛的行业合作打下基础(就像 runC 一样)
重复一遍：Containerd 被设计成嵌入到一个更大的系统中，而不是直接由开发人员或终端用户使用。所以 containerd 具有宏大的愿景。
当 containerd 和 runC 成为标准化容器服务的基石后，上层的应用就可以直接建立在 containerd 和 runC 之上。图中展示的容器平台都已经支持 containerd 和 runC 的组合了，相信接下来会有更多类似的容器平台出现。
containerd 的技术方向和目标: - 简洁的基于 gRPC 的 API 和 client library
- 完整的 OCI 支持(runtime 和 image spec)
- 同时具备稳定性和高性能的定义良好的容器核心功能
- 一个解耦的系统(让 image、filesystem、runtime 解耦合)，实现插件式的扩展和重用
2.4 Containerd-shim
它是 containerd 的组件，是容器的运行时载体，我们在 docker 宿主机上看到的 shim 也正是代表着一个个通过调用 containerd 启动的 docker 容器。该程序的安装路径为：
/usr/bin/docker-containerd-shim |