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

容器的歷史和 Docker 的起源

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

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

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

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

到 2013 年中旬，Hykes 及其團(tuán)隊(duì)生成的 Docker 工具集開始流行，成為 GitHub 上的熱門趨勢項(xiàng)目之一，并正式推出了 Docker 品牌。Hykes 的工作重心從 DotCloud 轉(zhuǎn)移到 Docker 上，他最終從 DotCloud 業(yè)務(wù)中獨(dú)立出來，但仍是 Docker Inc. 的 CTO。

Windows Server Containers

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

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

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

對密度造成的影響是最小的，因?yàn)槿萜鞅舜酥g以及與主機(jī)共享只讀內(nèi)存，所以只有專用內(nèi)存是按容器分配的。不過，啟動時間是我們面臨的巨大挑戰(zhàn)，我們也多次質(zhì)疑了這項(xiàng)決定；當(dāng)我們在 Build 2015 開發(fā)者大會的主題發(fā)言階段首次展示 Windows Server Containers 時，啟動時間為幾秒鐘，主要是由于系統(tǒng)服務(wù)的啟動時間所致。不過，Windows Server 性能團(tuán)隊(duì)也加入進(jìn)來。他們進(jìn)行了剖析和分析，并與 Windows 團(tuán)隊(duì)協(xié)作，共同加快服務(wù)運(yùn)行速度，并減少依賴項(xiàng)，從而提高并行度。這項(xiàng)工作的成果是，不僅容器可以更快啟動，實(shí)際上還縮短了 Windows 啟動時間。（如果你的 Xbox 或 Surface 從去年開始啟動速度更快了，這就要?dú)w功于容器了。） 在不到一年的時間里，容器啟動時間從大約七八秒縮短為亞秒級，而且縮短啟動時間的趨勢即使今天也仍在延續(xù)。

Hyper-V 隔離

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

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

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

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

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

我們發(fā)現(xiàn) Hyper-V 隔離具有另一價值，即通過為在 Windows 10 計(jì)算機(jī)上生成容器化應(yīng)用程序的開發(fā)者對容器運(yùn)行不同的內(nèi)核，我們?nèi)钥梢赃\(yùn)行服務(wù)器內(nèi)核，以確保這些開發(fā)者的應(yīng)用程序在生產(chǎn)環(huán)境和開發(fā)計(jì)算機(jī)中的運(yùn)行方式相同。因此，在 Windows 10 周年更新中，我們啟用了提供 Hyper-V 隔離的 Windows Server Containers，并在用于 Windows 的 Docker 中結(jié)合使用 Docker，以便充分利用這一面向開發(fā)者的新技術(shù)。

Docker 和 Windows Server Containers

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

?
圖 1：比較容器和 Docker 在 Windows 和 Linux 上的基本體系結(jié)構(gòu)

綜述

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

在接手容器時，我就知道這將是一個高壓項(xiàng)目。我知道將要加班到很晚，甚至還要在周末加班，需要付出巨大努力，但這一切都是值得的，因?yàn)榭梢詭椭鷶?shù)以百萬計(jì)的開發(fā)者更快速地生成更多應(yīng)用。我也知道自己會樂在其中，因?yàn)橛袡C(jī)會真正改變?nèi)藗冊?Windows 上開發(fā)和運(yùn)行應(yīng)用程序的方式。這比我預(yù)想的要更有趣，但同時付出的努力也超出預(yù)期，這段經(jīng)歷對我來說是無價的。回憶起此項(xiàng)目初期的一個周末，我正在辦公室加班，從窗戶向外望去，外面夏日炎炎，這時我在心里對自己說：“我相信并希望人們會使用這款產(chǎn)品…”

---

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

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

---

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。