在過去幾年里，Docker 和容器已成為全球開發界和企業最熱門的話題之一。去年秋天發布的 Windows Server 2016 支持 Windows 開發者使用容器，使得這一熱門話題再次升溫。Windows 和 Docker 是如何走到一起的？ 一切始于 2014 年隆重舉辦的普吉特海灣夏令營，當時 Windows Base 團隊啟動了一個新項目，最終推出了 Windows Server Containers。這是代碼背后的故事，讓我們得以瞥見 Windows Server 2016 中一項熱門新功能的推出過程。

容器的歷史和 Docker 的起源

2013 年，容器迅速引起了 Solomon Hykes 的興趣，他當時是平臺即服務 (PaaS) 創業公司 DotCloud 的 CTO 和創始人。Hykes 選擇了一組相對復雜難懂且難用的 Linux 內核功能，并使用他稱為 Docker 的開放源代碼工具將它們匯集到一起。他并不是有意成為容器方面的佼佼者，只是為了尋找解決方案來解決困擾 DotCloud 的問題： 開發者如何確保代碼在服務器上的運行方式與其在工作環境中的一樣？?

困擾 DotCloud 等服務的真正問題是由客戶想要部署大量各種各樣的軟件應用程序引起的，這些軟件根據不同的開發流程、修補程序周期和要求用不同的語言（代碼和口頭語言）編寫而成，包含各種依賴項。硬件虛擬化（即虛擬機 (VM)）是可用的最佳工具，但對將軟件從開發者筆記本電腦交付到生產環境提出了挑戰。要么必須使用開發者的完全配置 VM，但這會導致擴展和管理難以進行；要么必須讓部署工具和腳本能夠評估 VM 并安裝開發者的應用程序，但這樣做的靈活性不是很高且不可靠。

Hykes 認為 Docker 可以解決此問題，現在回想起來，他當時的想法確實很有意義。不過，他的公司并不是第一家涉足容器的云服務公司；事實上是另一家云服務公司 Google 根據需要開創了整個概念。2006 年，Google 工程師 Rohit Seth 提交了一個 Linux 內核修補程序，其支持借助他稱為 cgroups 功能中的一系列常見資源控制將進程匯集到一起。Seth 開始對此修補程序的描述如下： “商品硬件越來越強大。這樣一來，可以在同一平臺上運行不同的工作負載，從而更好地利用硬件資源”(bit.ly/2mhatrp)。雖然 cgroups 解決了資源隔離的問題，但并沒有解決分發不一致的問題。正因為如此，Docker 不僅使用 cgroups，還使用另一種 Linux 技術，就是命名空間。

命名空間于 2002 年被引入 Linux 內核，提供了一種用于控制進程可以查看的資源以及控制調用哪些資源的方法。命名空間與訪問控制大不相同，因為進程甚至不知道資源是否存在或是否在使用它們的某個版本。與此相關的一個簡單例子是進程列表：服務器上可以運行 20 個進程，而在命名空間中運行的進程可能只看到其中五個進程，其余的進程均已隱藏。再例如，某進程可能會認為它正從根目錄讀取內容，而實際上它是從另一獨立位置虛擬化而來。易用的開放源代碼產品中結合了 cgroups、命名空間和寫入時復制 (CoW) 文件系統技術，這成為了 Docker 的基礎所在。

到 2013 年中旬，Hykes 及其團隊生成的 Docker 工具集開始流行，成為 GitHub 上的熱門趨勢項目之一，并正式推出了 Docker 品牌。Hykes 的工作重心從 DotCloud 轉移到 Docker 上，他最終從 DotCloud 業務中獨立出來，但仍是 Docker Inc. 的 CTO。

Windows Server Containers

在 Docker 受到 Linux 界重視的同一時期，Windows Base 團隊一直在想方設法隔離執行客戶或第三方代碼的 Microsoft Azure 服務并提高其效率。代號為“Drawbridge”的 Microsoft 研究原型提供了一種研究渠道；此項目生成了可利用庫操作系統的進程隔離容器 (bit.ly/2aCOQxP)。遺憾的是，Drawbridge 在可維護性、性能和應用程序兼容性方面存在限制，導致其不適合作為常規用途解決方案。另一項稱為“服務器接收器”的更早原型技術一開始好像還是值得研究的。接收器擴展了現有的 Windows 作業對象方法，此方法可提供進程分組和資源控制（與 Linux 中的 cgroups 類似）(bit.ly/2lK1AbI)。服務器接收器原型新增的是獨立執行環境，包括文件系統、注冊表和對象命名空間（類似于 Linux 中的命名空間）。由于出現了 VM，服務器接收器原型被擱置多年，但現在被重新定義為 Windows Server Containers 的基礎。

服務器接收器原型代碼多年無人問津。甚至沒有進行編譯，更別提運行了。編寫此原型代碼的初衷是為了證明這項技術在 Windows 中是可行的，但距離生產還有很大一段距離。Windows Base 團隊面臨的選擇是，從頭開始還是嘗試恢復原型并繼續研究下去。我們選擇了后者。最初開發此原型時，只安排了一小組的開發者來證明這項技術的可行性，但現在是集 Windows 工程團隊的全部力量來開發此項目。來自 Windows 的架構師和工程師們應征而來助陣。存儲團隊生成了文件系統虛擬化；網絡團隊生成了網絡隔離；內核團隊生成了內存管理和計劃抽象；等等。

一些大的架構性問題依然存在；尤其是我們該如何處理系統進程？ 在 Linux 中，容器通常只運行一個進程，用于將內核中的系統服務與主機和其他容器共享。然而，為了提高可維護性和安全性，Windows 多年來一直在努力將代碼從內核移到用戶模式進程中。這就給我們的團隊帶來了一個問題： 要么共享所有系統服務（必須將所有系統服務更改為能夠發現容器），要么在每個容器中生成用戶模式系統服務的新副本。這是一個很為難的決定，因為我們擔心在每個容器中生成所有用戶模式服務的新實例會對密度和啟動時間造成影響。另一方面，我們還擔心在 Windows 中更新所有系統服務不僅操作起來十分復雜，而且還要承擔持續成本，無論是我們還是 Windows 外部開發者。最后，我們綜合了這兩種方法，精選了一組服務使其能夠發現容器，但大多數服務仍在每個容器中運行。

對密度造成的影響是最小的，因為容器彼此之間以及與主機共享只讀內存，所以只有專用內存是按容器分配的。不過，啟動時間是我們面臨的巨大挑戰，我們也多次質疑了這項決定；當我們在 Build 2015 開發者大會的主題發言階段首次展示 Windows Server Containers 時，啟動時間為幾秒鐘，主要是由于系統服務的啟動時間所致。不過，Windows Server 性能團隊也加入進來。他們進行了剖析和分析，并與 Windows 團隊協作，共同加快服務運行速度，并減少依賴項，從而提高并行度。這項工作的成果是，不僅容器可以更快啟動，實際上還縮短了 Windows 啟動時間。（如果你的 Xbox 或 Surface 從去年開始啟動速度更快了，這就要歸功于容器了。） 在不到一年的時間里，容器啟動時間從大約七八秒縮短為亞秒級，而且縮短啟動時間的趨勢即使今天也仍在延續。

Hyper-V 隔離

關于 Hyper-V 隔離，提出的第一個問題經常是：“容器還沒有提供隔離嗎？ 那我還需要 Hyper-V 做什么？” 容器確實提供隔離，并且在大多數情況下隔離很可能完全夠用。不過，存在以下風險：如果攻擊者能夠入侵內核，就可能會脫離容器，并影響其他容器或主機。由于內核攻擊在 Windows 中相對常見（每年通常都會有幾次），因此對于在共享的基礎結構上使用和執行最終用戶或第三方代碼的服務（如 Azure 自動化或 Azure 機器學習）而言，風險就太高了，不能只依賴內核隔離。生成和運行這些類型服務的團隊要么必須管理所有 VM 的密度和啟動成本，要么必須生成不同的安全和隔離技術。需要的是常規用途隔離機制，不僅能夠防御入侵者，還提供多租戶安全性： 即提供 Hyper-V 隔離的 Windows Server Containers。

我們的團隊為推出 Windows Server Containers 而不懈努力，這為生成這些服務的團隊提供了很好的體驗和管理模型。通過將技術與經過良好測試的 Hyper-V 隔離相結合，我們可以提供所需的安全性。不過，我們需要應對 VM 歷來都會帶來的啟動時間和密度挑戰。

與大多數虛擬化平臺一樣，Hyper-V 旨在通過各種操作系統（無論新舊）來運行來賓。目標是讓行為盡可能與硬件類似。為了實現這些目標，大多數虛擬化平臺選擇的解決方案都是仿真常見硬件。然而，隨著虛擬化的普及化，操作系統變得“開放”（經過具體修改，可作為來賓 VM 良好運行），這樣也就不再需要那么多的仿真。與此有關的一個良好示例是 Hyper-V 第 2 代 VM，它為了縮短啟動時間并提升性能而放棄了仿真，但仍實現了行為與直接在硬件上運行來賓一樣的同一目標 (bit.ly/2lPpdAg)。

對于容器，我們的需求和目標都不同： 我們不需要運行任何舊版操作系統，我們明確知道 VM 內將要執行的工作負載，就是容器。因此，我們生成了一種新型 VM，即旨在運行容器的 VM。為了滿足快速啟動的需求，我們生成了克隆技術。對于傳統 VM 來說，這一直都是一項挑戰，因為操作系統專精于主機名和標識等方面，所以如果不重啟，就無法輕松進行更改。不過，由于容器有自己的主機名和標識，因此這不再是問題。克隆也有助于應對密度挑戰，但我們必須深入下去： 我們需要的是內存共享。

共享內存的方法有兩種。可以查找多個 VM 共用的內存，并有效刪除重復內存（盡管大多數內核中的內存隨機化技術讓這難以實現）。也可以采用內核使用的方法，將只讀（公共）內存與讀寫（專用）內存區分開來。后一種方法通常要求來賓 VM 中的內存管理程序彼此交互，但這與隔離要求相背。不過，通過更改 VM 啟動和訪問文件的方式，我們發現了一種方法，使得主機不必信任來賓，來賓也不必相互信任。VM 不是從虛擬硬盤啟動和訪問文件，而是直接從主機文件系統啟動和訪問文件。也就是說，主機可以提供相同的只讀（公共）內存共享功能。這是將密度擴大多個數量級的關鍵所在，以便我們可以在未來幾年里繼續擴大密度。

我們發現 Hyper-V 隔離具有另一價值，即通過為在 Windows 10 計算機上生成容器化應用程序的開發者對容器運行不同的內核，我們仍可以運行服務器內核，以確保這些開發者的應用程序在生產環境和開發計算機中的運行方式相同。因此，在 Windows 10 周年更新中，我們啟用了提供 Hyper-V 隔離的 Windows Server Containers，并在用于 Windows 的 Docker 中結合使用 Docker，以便充分利用這一面向開發者的新技術。

Docker 和 Windows Server Containers

還有一個問題仍未解決，就是用戶該如何與這種新平臺技術進行交互？ 在 Linux 界，Docker 備受贊譽，迅速成為約定俗成的容器管理標準。為什么不讓用戶以同樣的方式使用 Windows Server Containers 呢？ 在飛到舊金山初次接觸到 Docker 的那個秋天，我完全不確定那家公司是否會想到基于 Windows 的容器，也不確定它是否有興趣在 Windows 基礎之上進行生成。讓我感到驚訝的是： Solomon 認為 Windows 容器的想法非常棒！ 但這家公司是否會在 Windows 基礎之上進行生成呢？ 那次談話徹底改變了項目面貌。Solomon 直接回應說：“大家都知道 Docker 是一款開放源代碼工具，當然可以添加代碼，使之適用于 Windows，我們將會提供幫助。”然后，我們就這樣做了。從那以后，Hyper-V 團隊的軟件工程師 John Howard 就成為了 Docker 項目的維護人員，他實際上已上升到排名第四的全職代碼參與者 (bit.ly/2lAmaZX)。圖 1?展示了容器和 Docker 在 Windows 和 Linux 上的基本體系結構。

?
圖 1：比較容器和 Docker 在 Windows 和 Linux 上的基本體系結構

綜述

四個月前，在 Microsoft Ignite，我們推出了 Windows Server 2016，并宣布擴展了與 Docker 的合作伙伴關系。也就是說，Docker 將為 Windows Server 客戶提供其商業版 Docker Engine，而不額外收取任何費用。從那以后，事務應接不暇。Tyco 等客戶一直在使用 Docker 和 Windows Server Containers 來徹底改變他們生成軟件的方式，并使現有應用程序現代化，所有這些工作都是在同一平臺上完成的 (bit.ly/2dWqIFM)。Visual Studio 2017 完全集成了 Windows 和 Linux 容器工具，包括 F5 調試；Visual Studio Code 內置了 Dockerfile 和撰寫支持。Azure 和 Amazon 的容器服務都新增了對 Windows Server Containers 的支持，從 Docker Hub 拉取的基于 Windows 的容器映像已超過 1 百萬個。為了實現端到端安全性和業務流程，Docker 數據中心為開發者和系統管理員提供了可隨時隨地生成、交付和運行已分發應用程序的平臺。借助 Docker，組織可以將應用程序交付時間從幾個月縮短到幾分鐘、在數據中心和云之間順暢地移動工作負載，并讓計算資源的使用效率提高超過 20 倍。

在接手容器時，我就知道這將是一個高壓項目。我知道將要加班到很晚，甚至還要在周末加班，需要付出巨大努力，但這一切都是值得的，因為可以幫助數以百萬計的開發者更快速地生成更多應用。我也知道自己會樂在其中，因為有機會真正改變人們在 Windows 上開發和運行應用程序的方式。這比我預想的要更有趣，但同時付出的努力也超出預期，這段經歷對我來說是無價的。回憶起此項目初期的一個周末，我正在辦公室加班，從窗戶向外望去，外面夏日炎炎，這時我在心里對自己說：“我相信并希望人們會使用這款產品…”

---

Taylor Brown?是 Microsoft Windows 和設備組的項目管理主要負責人。作為 Windows Base 工程團隊的一員，他負責制定 Windows Server 開發者策略，尤其是專精于容器技術，包括 Windows Server Containers。Brown 的職業生涯始于 Windows，最開始負責研發 Windows 2003 的 1394/Firewire 堆棧，在加入新組建的虛擬機團隊之前，他致力于 Windows Server 2003 SP1 的 ACPI/電源管理。從那以后，他參與了 Microsoft 發布的每一項 VM 技術（包括虛擬 PC、虛擬服務器和每一版 Hyper-V）的開發工作，這讓他成為虛擬化技術領域的行業專家。可通過?taylorb@microsoft.com?與他聯系。

原文地址：https://msdn.microsoft.com/en-us/magazine/mt797649

---

.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注

總結

以上是生活随笔為你收集整理的Windows Server Containers 支持 Windows 开发者使用 Docker的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。