Michael Crosby是如今最有影响力的Docker容器开发人员之一，他帮助领导containerd的开发以及担任Open Container Initiative（OCI）技术监督主席。近日，他在DockerCon 19上，Crosby在演讲中概述了Docker的过去，现在以及未来。Docker的早期历史与Linux密切相关，事实证明，Docker的未来也是如此。

Crosby指出，Docker在2013年开始使用LXC作为其基础，但在过去的六年中，它已经超越了这一点，首先是由docker主导的libcontainer工作，以及最近在Linux基金会的相关方面OCI的工作，它开发了一个容器运行时的开放规范。该规范包括runc容器运行时，它是Crosby帮助领导的开源容器项目的核心。Containerd是云计算原生基金会（CNCF）的托管项目，是Kubernetes等少数项目之一，已经“毕业”，在项目稳定性和成熟度方面将其置于CNCF层次结构的顶层。

Docker 19.03

Docker既有缓慢发展的企业版，也有更快速发布的社区版。在DockerCon 19上，基于Docker Community Edition（CE）18.09里程碑宣布了Docker Enterprise 3.0。Docker开发人员目前正在努力完成版本为19.03的Docker CE的下一个主要版本。

Docker CE发布的基于时间的命名意味着19.03应该是在2019年3月发布，但事实并非如此。Docker的编号发布周期有所延迟，最近的发布日期与实际的一般可用性不匹配。例如，目前的Docker CE 18.09里程碑在2018年11月普遍可用，而不是2018年9月。但是，当前的Docker CE编号与版本的功能冻结日期更紧密地对齐。Docker CE的GitHub存储库指出19.03版本的功能冻结直到3月22日才发生。测试版4的发布时间是5月13日，最终的一般可用性发布日期在5月某个时候列为“待定”。

Crosby表示，在Docker CE 19.03中出现的新功能中，全面支持英伟达GPU，这标志着Docker首次以无缝方式集成了GPU支持。Crosby补充说，英伟达GPU支持将使容器工作负载能够充分利用这些GPU提供的额外处理能力，这通常是人工智能和机器学习用例所需要的。

Containerd也得到了提升，推进了Docker CE中的1.2版本。Containerd 1.2受益于多个错误修复和性能提升。此版本中的新功能包括一个更新的运行时，它集成了一个gRPC接口，旨在简化容器管理。总体而言，Crosby评论说Docker的许多常见基础元素随着时间的推移保持不变。

“尽管我们在2013年在Docker中拥有了相同的原型，但它们已经过优化，而且预趋成熟了，”Crosby说。

Docker的未来

Docker容器最初都是为了充分利用Linux功能。就像Docker容器基于一系列Linux内核功能开始一样，Docker的未来就是充分利用更新的内核功能。Crosby说，“容器由各种内核功能组成，如cgroups，命名空间，LSM和seccomp。我们必须把所有这些东西捆绑在一起，以创造我们现在所知的容器。

期待容器和Docker的下一步，Crosby表示，这完全是为了处理近年来出现的不同需求。这些要求之一是需要利用Linux 5.0及更高版本中的现代内核功能，以及处理不同类型的新工作负载，包括状态工作负载，这需要一定程度的持久性，而无状态工作负载中不存在这种持续性。用于网络边缘部署的边缘工作负载，是另一个新兴的用例，而不仅仅是云。物联网（IoT）和小型设备和工业设置中的嵌入式工作负载也是Docker在2019年的一个重要用例。

Docker将在未来充分利用的Linux内核功能之一是eBPF，它有一天可用于编写seccomp过滤器。Crosby解释说，seccomp和BPF允许在内核中进行灵活的系统调用拦截，这为容器的新控制和安全机会打开了大门。

控制组（cgroups）v2是Docker即将从中受益的另一个Linux功能。自Linux 4.5发布以来，Cgroups v2一直在内核中，但Docker并没有立即采用它作为支持技术。该项目并不是唯一一个不立即支持cgroups v2，红帽的Fedora社区Linux发行版也没有集成cgroups v2，尽管它计划发布目前定于11月发布的Fedora 31版本。Crosby表示，cgroups v2将为Docker提供更好的资源隔离和管理功能。

作为无根容器更广泛努力的一部分，Docker的路线图也增强了用户名称空间支持；通过默认情况下不过度配置权限来运行容器，它将有助于提高安全性。使用用户命名空间运行无根Docker容器的想法并不是一个新概念，但它很快就会成为技术现实。“最后，经过这么多年，用户名称空间处于一个我们可以真正构建它们并启用无特权容器的地方，”Crosby说。

未来还将向Docker提供更多内核安全支持。Crosby表示，SELinux和AppArmor不再是开发人员想要的唯一Linux安全模块（LSM）。Docker开发人员正在努力支持的新兴的LSM是Landlock。Crosby补充说，开发人员还可以使用eBPF编写自己的自定义LSM。此外，他强调了seccomp BPF的出现。

使容器更有状态

Crosby最感兴趣的领域之一是Docker的状态功能，他认为目前这些功能相对有限。更好的有状态功能包括单个容器的备份，还原，克隆和迁移功能。Crosby解释说，今天Docker中的有状态管理通常依赖于存储卷而不是实际的容器本身。

Crosby提到，“我们现在理解镜像是可移植的，但我也想将容器视为可以从一台机器移动到另一台机器的镜像。我们希望RW [读/写]层可以与容器一起移动，而不必依赖存储卷。”他还希望确保不仅链接容器的文件系统数据，还要确保容器配置，包括用户级数据和网络信息。

重新思考容器镜像传递

今天的容器镜像主要通过容器注册表提供，例如用于公共访问的Docker Hub，或组织内的内部注册表部署。Crosby解释说，Docker镜像是用一个名称来标识的，这个名称基本上是指向给定容器注册表中内容的指针。每个容器镜像都归结为摘要，摘要是镜像中包含的JSON文件和图层的内容地址哈希。Crosby和Docker现在正在考虑的是一种方法，即通过跨节点的某种形式的点对点（P2P）传输方法来访问和共享容器镜像，而不是依靠集中式注册表来分发镜像。

Crosby解释说，仍然需要一个注册表来处理镜像的命名，但内容地址blob可以从一台机器转移到另一台机器，而无需直接与注册表交互。在用于镜像传递的P2P模型中，注册表可以将容器镜像发送到一个节点，然后用户可以使用诸如BitTorrent同步之类的东西来共享和分发镜像。Crosby说，虽然自2013年以来容器开发已经成熟了很多，但仍有工作要做。“从我们过去几年到现在，我认为会看到很多相同类型的东西，我们仍然会关注稳定性和性能。”