docker篇——引擎

1.简述

docker引擎是用来运行和管理容器的核心软件。代称Docekr或者Docker平台
类比于VMware，将Docker引擎理解为ESXi的角色

2.OCI标准

基于开放容器计划，Docker引擎采用了模块化的设计原则，组件是可替换的。

3. 构成

   (1) Docker客户端（Docker Client）

   (2) Docker守护进程（Docker daemon）

   (3) containerd

   (4) runc

4. 发展

Docker首次发布时，采用的构成如下：

LXC：提供了对命名空间（Namespace）和控制组（CGroup）等基础工具的操作能力，基于Linux内核的容器虚拟化技术。

Docker daemon是单一的二进制文件，包含Docker客户端、Docker API、容器运行时、镜像构建等

LXC是基于linux的，对于一个跨平台的项目来说是一个问题。
并且，核心的组件需要依赖于外部的凭条，这会给项目带来风险。
Docker公司发明了Libcontainer的自研工具，用于替代LXC
Libcontainer的目标是成为与平台无关的工具，可基于不同内核为Docker上提供必须的容器交互工能。
docker0.9版本后，Libcontainer取代了LXC成为默认的执行驱动。

Docker daemon整体涵盖的东西过多，导致了难以变更，运行越来越慢。Docker意识到这个问题之后，开始将大而全的Docker daemon进行拆解，并将其模块化。

1. 定义：runc是一个轻量级的、针对libcontainer进行包装的命令行交互工具。
2. 作用：创建容器。（CLI包装器，实质上是一个独立的容器运行时工具）
3. 拓：runc所在的那一层，也称之为OCI层。

1. 功能：所有容器执行逻辑，主要任务是容器的生命周期管理（strat|stop|pause|rm…）
2. 位于daemon和runc所在的OCI层之间，从1.11版本之后Docker开始在linux上使用。

$ docker container run --name ctr1 -it alpine:latest sh

当使用Docekr命令行工具执行上诉命令时，Docker客户端会将其转换成为合适的API格式，并将其发送到正确的API端点。
（API实在daemon中实现的，这套功能丰富、基于版本的REST API成为Docker的标志）

一旦daemon接收到创建容器的命令，它就会向container发出调用。
（daemon使用一种CRUD风格API，通过gRPC与container进行通信）

container将Docker镜像转换成OCI bundle，并让runc基于此创建一个新的容器。

runc与操作系统内核接口进行通信，基于所有必要工具（Namespace、CGroup等）来创建容器。容器进程作为runc的子进程启动，启动完毕后，runc将会退出。

shim是实现无daemon的容器（用于将运行中的容器与daemon解耦，以便进行daemon升级等操作）不可或缺的工具。

每次创建容器，都会fork一个新的runc实例。创建容器完毕后，对应的runc进程就会退出。因此，即使运行上百个容器，也无需保持runc实例。

当然，一旦容器进程runc退出，相关联的containerd-shim进程就会成为容器的父进程。作为容器的父进程，shim的职责：

1. 保持所有STDIN和STDOUT流是开启状态，从而当daemon重启的时候，容器不会因为管道（pipe）的关闭而终止。
2. 将容器的退出状态反馈给daemon。

将所有用于启动、管理容器的逻辑和代码从daemon中移除，意味着容器运行时与Docker daemon是解耦的，有时称之为无守护进程的容器（daemonless container）

那么剩余的功能还有什么：

1. 镜像管理
2. 镜像构建
3. REST API
4. 身份验证
5. 安全
6. 核心网络
7. 编排

个人学习使用
文章总结出处