Docker组件-源码编译安装使用总结.docx

用总结Docker组件介绍，源码编译安装、使

用总结

◎UT001641/文

docker组件和历史

Docker引擎是用来运行和管理容器的核心软件。通常人们会简单地将其代指为Docker或Docker平台。如果你对VMware略知一二，那么可以将Docker引擎理解为ESXi的角色。

基于开放容器计划（OCI）相关标准的要求，Docker引擎采用了模块化的设计原则，其组件是可替换的。从多个角度来看，Docker引擎就像汽车引擎——二者都是模块化的，并且由许多可交换的部件组成。

汽车引擎由许多专用的部件协同工作，从而使汽车可以行驶，例如进气管、节气门、气缸、火花塞、排气管等。

Docker引擎由许多专用的工具协同工作，从而可以创建和运行容器，例如API、执行驱动、运行时、shim进程等。Docker引擎由如下主要的组件构成：Docker客户端（DockerClient）、Docker守护进程

（Dockerdaemon）、containerd以及runc。它们共同负责容器的创建和运行。

总体逻辑如下图所示。

Docker首次发布时，Docker引擎由两个核心组件构成：LXC和Dockerdaemon。

Dockerdaemon是单一的二进制文件，包含诸如Docker客户端、DockerAPI、容器运行时、镜像构建等。

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

下图阐释了在Docker旧版本中，Dockerdaemon、LXC和操作系统之间的交互关系。

摆脱LXC

对LXC的依赖自始至终都是个问题。

首先，LXC是基于Linux的。这对于一个立志于跨平台的项目来说是个问题。

其次，如此核心的组件依赖于外部工具，这会给项目带来巨大风险，甚至影响其发展。

因此，Docker公司开发了名为Libcontainer的自研工具，用于替代LXC。

Libcontainer的目标是成为与平台无关的工具，可基于不同内核为Docker上层提供必要的容器交互功能。

在Docker0.9版本中，Libcontainer取代LXC成为默认的执行驱动。

摒弃大而全的Dockerdaemon

随着时间的推移，Dockerdaemon的整体性带来了越来越多的问题。难于变更、运行越来越慢。这并非生态（或Docker公司）所期望的。

Docker公司意识到了这些问题，开始努力着手拆解这个大而全的Dockerdaemon进程，并将其模块化。

这项任务的目标是尽可能拆解出其中的功能特性，并用小而专的工具来实现它。这些小工具可以是可替换的，也可以被第三方拿去用于构建

图1

其他工具。

这一计划遵循了在UNIX中得以实践并验证过的一种软件哲学：小而专的工具可以组装为大型工具。这项拆解和重构Docker引擎的工作仍在进行

中。不过，所有容器执行和容器运行时的代码已经完全从daemon中移除，并重构为小而专的工具。

目前Docker引擎的架构示意图如图1所示，图中有简要的描述。

开放容器计划(OCI)的影响

当Docker公司正在进行Dockerdaemon进程的拆解和重构的时候，OCI也正在着手定义两个容器相关的规范（或者说标准）。

镜像规范和容器运行时规范，两个规范均于2017年7月发布了1.0版。

Docker公司参与了这些规范的制定工作，并贡献了许多的代码。

从Docker1.11版本（2016年初）开始，Docker引擎尽可能实现了OCI的规范。例如，Dockerdaemon不再包含任何容器运行时的代码——所有的容器运行代码在一个单独的OCI兼容层中实现。

默认情况下，Docker使用runc来实现这一点。runc是OCI容器运行时标准的参考实现。

如上图中的runc容器运行时层。runc项目的目标之一就是与OCI规范保持一致。

目前OCI规范均为1.0版本，我们不希望它们频繁地迭代，毕竟稳定胜于一切。

除此之外，Docker引擎中的containerd组件确

保了Docker镜像能够以正确的OCIBundle的格式传递给runc。

其实，在OCI规范以1.0版本正式发布之前，Docker引擎就已经遵循该规范实现了部分功能。

runc

如前所述，runc是OCI容器运行时规范的参考实现。Docker公司参与了规范的制定以及runc的开发。

去