Windows Server Containers 支持 Windows 开发者使用 Docker
在過去幾年里,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)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 第六期.Net开源社群联合分享--除了情
- 下一篇: 监控——《微服务设计》读书笔记