Docker打破单一架构、平台限制，便捷移植即刻拥有！

编译丨小东

每周一、三、五晚6点10分 与您不见不散

说在前面

真正多平台工作负载的可移植性一直是企业追求的目标。多年来，为了达到不同程度上满足使用需求的性能或可用性，出现了各式各样的虚拟化策略。一方面，虚拟机和硬件虚拟化足够灵活，您可以在同一台主机上混合使用操作系统（甚至是CPU架构），但是它们会带来很多间接费用。另一方面，基于语言的虚拟运行机制并不具备封装所有系统级应用程序相关的打包格式，这使得它们不适合进行通用的部署和配置管理。

Docker以一种独特的虚拟化形式出现在用户面前，它只对容器进程中的操作系统进行虚拟化。Docker使用现有的Linux内核特性来提供类似于使虚拟机运行的隔离特性。这种类似“标准的集装箱运输”并与隔离基元（primitives）相结合的模式，立即引起了开发人员的兴趣。有了这个全新的运输比喻，速度和敏捷性就会打破原有虚拟机的大小和速度限制，从而影响开发人员的工作流程，极大程度的提升了开发人员的效率。从那以后，容器化的热潮就像野火燎原一样快速发展起来，但让我们回到亨利·福特式的难题：“只要是在Linux的x86_64 CPU架构上，你就可以在任何地方运行容器。”

随着人们对Docker和容器的兴趣不断增长，许多其它UNIX和Linux的社区用户，包括树莓派狂热者、FreeBSD、Solaris、ARM微服务器、OpenPOWER和z/Linux社区，都渴望加入到容器热潮中，并将Docker容器引擎和其他必需组件加入到他们的UNIX和/或CPU特定的体系结构中。微软也加入进来，并在Windows Server内核中增加了容器化功能，与Docker合作，将Docker引擎移植到Windows上。在哥本哈根的DockerCon上，Michael Friis分享了这次多平台的旅程。

这篇文章可以归结为以下3点内容：

将Docker容器运行机制组件移植到x86架构以外的CPU架构以及非Linux操作系统上。

制定一个容器镜像类型，该镜像类型通多单一命名方式就可以代表多平台特定的镜像，并在镜像仓库中实现此支持。

为广泛支持的平台和体系结构提供通用镜像，并帮助镜像打包者了解为多平台构建和打包软件的好处。

我们已经提到，许多社区和供应商早在最初几年甚至是Docker出现之前就在处理这些问题。今天，几个ARM变种，像Power、z / Linux和Microsoft Windows，它们都配备了支持Docker运行机制的CPU平台和操作环境。

为了处理多架构和多操作系统的需求，规范容器镜像的表现形式，在2015年和2016年初，Docker发布项目并与社区一同创建了v2.2镜像规范，该规范使用新的清单列表来表示一系列的架构/平台，并指向运行时使用的特定于平台的容器镜像内容。在Docker引擎和Docker镜像仓库项目开启之后不久，DockerHub也随之实现了对清单列表这一全新概念的全部支持。

这个多平台难题的最后一部分是镜像打包者利用这个新功能在镜像仓库中创建内容，这些在仓库中的镜像可以由Docker运行在各种平台上。首先，需要一个工具来创建清单列表条目，我创建了一个生成清单列表的工具项目来填补这个空白，您也可以使用它直到Docker客户端更新出具有相同功能的工具。其次，在2017年夏季末期，Docker Hub上所有官方创建和支持的镜像都转而使用清单列表条目，其中大部分支持两种或更多架构。现在这个转变已经发生了，工作扩大到对更多架构和平台上的流行镜像的支持。这提高了Docker在许多架构和平台上的可用性，而不再需要这种引导用户添加特定的架构前缀来对镜像命名的工作方法了。在对话环节中，Michael和我也讨论了镜像创建者和软件包制作者如何开始处理CI系统增加的复杂性和交叉编译，以处理他们自己所创建的镜像清单条目。

在Docker生态系统中多平台的现状是一次巨大的前进，并实现了多年来社区一直渴望的成果。由于这一进展，和我能够展示Docker企业版（EE）控制平面来管理同时运行Windows Server、在大型机虚拟机上持续运行的z / Linux以及两个标准x86_64云实例的混合集群节点。在这个集群中，他们展示了在混合集群中使用基于清单列表的镜像部署服务和堆栈，支持跨这些架构和平台的单窗口管理。对于多平台的支持来说，这确实是一个很好的时机，也许我们离实现多平台工作负载可移植性的目标又近了一步。