出品丨Docker公司（ID：docker-cn）

編譯丨小東

每週一、三、五晚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雲實例的混合叢集節點。在這個叢集中，他們展示了在混合叢集中使用基於清單列表的映象部署服務和堆疊，支援跨這些架構和平臺的單視窗管理。對於多平臺的支援來說，這確實是一個很好的時機，也許我們離實現多平臺工作負載可移植性的目標又近了一步。

點選下列標題，閱讀更多幹貨

如果本文對你有幫助，歡迎分享到朋友圈！獲取更多Docker實用技巧，掃描下圖二維碼！