理解事物是如何运作的核心机制能带来清晰，将死记硬背转化为真正的理解和掌握。

• 为什么这很重要：理解这些基础知识能帮助我们看清全貌并做出明智的决定。
• 演化：了解某事物的发展历程能解释其当前状态。

可以期待的内容：

读完本文后，你将深入了解Docker引擎的结构和功能。

Docker Engine 正如名字所暗示的，是 Docker 的核心。它是驱动 Docker 并处理所有繁重工作的组件。在本文中，我们将深入探讨这个关键组件是如何运作的，了解 Docker 在内部是如何运作的。你将了解 Docker Engine 的发展过程，并全面了解其设计和功能，从内到外。

本文是《Docker 之旅》系列的第二篇文章，在这里我们将深入探讨 Docker 的组件、设计及其功能。如果错过了第一部分，其中探讨了 Docker 的历史，你可以在这里查看这里。

Docker 最初是一个巨型单一项目，所有代码都被塞进了一个项目里。想象一下，这就像一位音乐家试图同时演奏所有的乐器。这对背后的公司 dotCloud 来说非常有效。因此他们决定放弃所有其他服务，并把所有的希望都寄托在 Docker 上，甚至将公司名称改为了 Docker, Inc。这真是一次大胆的决定，对吧？

最初，Docker 是一个庞大但混乱的应用程序。随着时间的推移，他们发现这不可持续。他们需要将它拆分。为什么？为了能够更好地发展和持续。

• 单独发展每个部分 — 就像把乐队拆成个人，让每个成员可以专注于自己的职业发展。
• 轻松升级零件 — 将旧件替换为新件。
• 让社区参与其中 — 较小的模块意味着更多的人可以参与。
• 全球扩张 — 他们希望Docker不仅能在Linux上运行，更希望它能在所有平台上运行。

第一次被移除的是客户模块。他们将其从大应用中移出，并赋予了它一个新的职责：将用户的命令翻译成剩余Docker引擎的指令，基本上就是原来的程序内核。

到这个时候，Docker Engine 包含主要由两部分组成。

• 守护进程：负责管理容器、网络和卷的多任务处理器。
• LXC：Docker 和 Linux 内核之间的桥梁。

但这里有个问题：这个设置有问题。

• LXC 只在 Linux 上运行。如果你希望 Docker 能在 Windows 或 macOS 上运行，这就有点麻烦了。
• Daemon 过于劳累且不堪重负。它任务太多，需要休息一下。

所以，Docker 淘汰了 LXC，并用 libcontainer 取而代之，这个新工具更灵活且更加平台友好。他们还减轻了守护程序的工作负担，使其成为一个更简单的 API，方便客户端通信。

但他们并没有就此停下脚步。Libcontainer 还是太大太笨重。因此，Docker 就像用锤子一样把 Libcontainer 拆开了，将其拆分成更小的部分：docker-init（简称），runc（简称），containerd（简称），和 shim（简称）。每个部分只有一个任务，这就意味着：

• 更好的团队协作：社区可以专注于特定的组件。
• 自由实验的权利：开发人员可以像玩乐高积木一样灵活地替换部件。
• 更简洁的设计：不再有杂乱无章的设计。

Docker Engine 的发展

还记得我们在上一篇文章里讨论过的标准吗？它们就像容器界的交通规则，让一切都能井井有条地合作。Docker Engine 严格遵守 OCI（开放容器倡议） 协议和标准。这意味着你在 Docker Engine 上搭建的任何镜像都可以在其他遵循 OCI 标准的容器平台上运行。这就像用通用乐高积木搭建一样——你的作品可以放到任何地方。

Docker Engine 帮助你构建、打包和运行符合 OCI 兼容标准的镜像。这三步由三个主要标准指导。

• 镜像规范 (Image-Spec)
  这个标准定义了容器镜像是如何创建的。可以把它看作是内部的依赖项、配置等的详细蓝图。
• 分发规范 (Distribution-Spec)
  这个规范涵盖了容器镜像的共享和分发。就像定义了一个运输网络的规则一样，确保你的容器能够从点A平滑地到达点B。
• 运行时规范 (Runtime-Spec)
  这个标准规定了容器从启动和停止到与主机操作系统的交互，都是关于容器在实时运行中的行为表现。

关于历史的部分就到这里吧。现在来聊聊更有趣的内容吧！在接下来的部分中，我们将一步步深入了解Docker当前的架构，并弄清楚它是怎么工作的。系好安全带——真正的精彩马上开始！

我们来拆解一下当你运行像这样的一个 Docker 命令时发生了什么

    docker start my-container

启动名为my-container的容器

这是你在和 Docker CLI（也叫 Docker 客户端）对话。CLI 就像你的贴心小助手——它会把你的命令转换成 Docker 守护程序能理解的形式。

就这样：

或

下面说重点：

根据上下文选择最合适的表达。

• 命令翻译
  Docker CLI 接收你的命令并将其转换为 API 调用。Docker 守护进程没有读心术，它只懂 REST 或 gRPC，因此 CLI 会将你的输入转换成 REST 或 gRPC 格式之一。
• 发送请求的过程
  翻译完成后，CLI 将请求发送给 Docker 守护进程。守护进程是整个操作的指挥中心——它接收请求、处理请求并在幕后完成相应的任务。

所以，当你输入 docker start my-container 时，CLI 会将其转换为一个类似 "嘿，守护进程！启动名为 ‘my-container’ 的容器" 的 API 请求，并将其发送过去。守护进程就开始忙活起来，协调所有需要的操作，让你的容器活过来。是不是很棒，对吧？

Docker系统的命令

Daemon 可以看作是 Docker 的友好接待员。它提供了客户端（如 Docker CLI）与 Docker 引擎进行交互的接口，使用诸如 API 调用或远程过程调用这样的高级抽象。当 Daemon 接收到一个请求，比如启动名为 my-container 的容器时，它会验证并处理这条命令，然后将请求转换为给 containerd 模块的稍低级别的指令。

你知道吗？这里有一个有趣的冷知识：

• **c**是小写：这是风格上的选择，让它显得更贴近Unix风格。
• **d**代表后台进程：确实，它在后台运行，默默地管理容器。

Docker Engine 是按照模块化设计的，这意味着它被分割成更小的组件。这种模块化设计很棒，因为它使 Docker 更加灵活和可扩展——你可以在不影响整个系统的情况下替换、更新或扩展单个组件。

containerd具体做了什么？

Containerd 是一个高级运行时，负责全面管理容器整个生命周期中的各个细节。在 Docker 中，它就像是一个项目经理。

• 新建、启动、停止和删除容器
• 管理网络和存储卷
• 下载镜像
• 满足容器级别的需求

当Daemon发送命令到containerd（例如，“启动这个容器”）时，containerd 会准备该容器。然而，containerd 并不会直接运行容器。它依赖于一个名为 runc 的专用运行时来做具体的工作。

将 containerd 想象成优步——它为你提供了一个简洁易用的体验来管理容器。你选择起点和终点，然后点一下“叫车”。接着，优步为你安排司机处理运输。

类似地，containerd 负责整个过程：管理容器、协调它们的生命周期管理并确保一切井井有条。当需要运行一个容器时，它会将任务委托给 runc，也就是专注于启动和运行遵循 OCI 标准的容器的 runc。

通过将职责分工模块化，Docker 因此实现了更高的效率、灵活性和可维护性。

这里的文本似乎不完整，可能是“The runc”，请核实。

• **r**是小写，这是对Unix传统的致敬。
• **c**意思是容器，简单直接。

runc 是干什么的？

runc 的唯一重点是：运行 OCI 容器。当我们说 OCI（开放容器倡议）时，我们指的是符合行业标准协议，确保兼容性和互操作性的容器和镜像。

将 runc 视为设置并启动容器的工具，遵循开放容器倡议（OCI）运行时规范中定义的一套规则。它的主要任务是：

• 搭建容器环境
• 启动容器
• 确保容器在主机环境里正常运行

虽然runc必不可少，containerd与其交互的方式却增加了灵活性。containerd通过一个叫作shim的抽象层与runc通信。

垫片

在 containerd 的环境中，shim 是一个轻量级的进程，位于 containerd 和实际的容器运行时（如 runc）之间。它的主要作用是将 containerd 和运行时解耦，确保灵活性和独立性的同时。这使得 containerd 可以独立管理容器，而不必与特定的运行时紧密绑定。

当 containerd 启动容器时，它会启动一个 shim 进程。shim 进程接着会调用运行时，比如 runc，来设置容器。runc 负责大部分工作，例如：

• 设置命名空间和 cgroups（控制组）。
• 挂载文件系统。
• 启动容器内的进程。

然而，一旦容器开始运行，runc 就会退出，由shim管理容器的生命周期和交互。shim将负责以下任务：

• 进程管理：确保容器进程持续运行，并处理信号（如停止、重启等）。
• 输入输出流：管理日志并转发容器与 containerd 之间的输入输出流。
• 生命周期事件：监控并报告容器生命周期中的事件，如终止。

如果所有低级运行时，如 runc ， crun ，和 Kata Containers ，都遵循OCI运行时规范，为什么 containerd 需要一个shim呢 ，答案在于模块化和职责分离这两个概念。

• 解耦：该shim抽象了特定于容器的操作，因此 containerd 可以专注于管理多个容器、它们的网络和卷，而不必处理每个容器的繁琐细节。
• 灵活性：shim允许你用遵循OCI标准的其他运行时替换 runc，这使得架构能够适应新的技术。
• 简化：每个shim只处理一个容器。这种分离确保了一个容器中的问题不会扩散到其他容器。

一旦 shim 接管，它将继续管理容器的生命周期。然而，Docker 引擎还需要与容器内的进程互动，例如，处理日志、信号和资源等，保证它们得到适当的管理。这时，docker-init 就发挥作用了。它作为容器内的“PID 1”进程，负责管理和清理这些应用的资源。

每个容器内部，PID 1 进程扮演核心角色，它是第一个也是最重要的进程。它是容器生命周期中的关键。当 containerd 需要停止或终止一个容器时，它依赖 PID 1 来清理所有相关进程。如果 PID 1 退出，所有与它关联的进程都会被自动结束。

docker-init 的一个关键作用是清理僵尸进程——那些在完成任务后被遗忘的子进程。如果这些进程不被处理，它们会占用系统资源或拖慢系统。Docker-init 确保这些进程被快速清理掉，保持容器环境整洁高效，避免资源浪费。

另一个重要的任务是处理系统信号，如 SIGTERM 或 SIGINT。许多容器化应用程序本身处理得不好，这可能导致突然或不完全的关闭。Docker-init 则会介入捕获这些信号并适当地转发，确保容器内的应用程序可以优雅地退出。

作为 PID 1，docker-init 为容器化应用的稳定运行提供了可预测和稳定的基石。它的存在简化了容器的生命周期管理，确保其高效且稳定运行。

在本质上，docker-init 确保容器保持整洁、反应迅速且管理得当。它的作用让容器更加可靠和有效。

Docker Engine 不仅仅是软件，而是一个由模块化组件精心设计的系统，使容器高效、可扩展且便携。从你在 CLI 中输入的命令到由 runc、shim 和 docker-init 处理的底层操作，每个元素都发挥着独特且重要的作用。

通过遵循严格的OCI标准，Docker确保其生态系统不仅强大，而且具有普遍兼容性。这种对标准的遵守建立了信任，为开发人员和企业提供了一个稳定的基石。它的模块化设计不仅简化了容器管理，还促进了创新，使每个组件能够独立地发展和改进。

理解 Docker Engine 并不仅仅停留在了解容器的工作原理上。更重要的是认识到背后的精心设计——这种设计使现代软件开发更快、更高效，并且更具可访问性，适合所有人。Docker 不仅是一个工具；它是一个平台，为无限可能打开了大门。

下次你用 Docker 的时候，不妨稍微停一下，感受一下它简单背后的复杂性和精准性吧。现在你知道驱动容器背后引擎的是什么了。