Docker容器的将来，将继续充分利用Linux功能

点关注，不迷路；持续更新Java架构相关技术及资讯热文！！！

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年以来容器开发已经成熟了不少，但仍有工做要作。“从咱们过去几年到如今，我认为会看到不少相同类型的东西，咱们仍然会关注稳定性和性能。”

写在最后

最后，欢迎作Java的工程师朋友们加入Java高级架构进阶Qqun：963944895

群内有技术大咖指点难题，还提供免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）

比你优秀的对手在学习，你的仇人在磨刀，你的闺蜜在减肥，隔壁老王在练腰， 咱们必须不断学习，不然咱们将被学习者超越！

趁年轻，使劲拼，给将来的本身一个交代！