[[123415]] 

從一項(xiàng)顛覆性的技術(shù)成果轉(zhuǎn)化并衍生出一整套社區(qū)體系，Docker在發(fā)展速度上打破了一個(gè)又一個(gè)歷史紀(jì)錄。然而，Docker項(xiàng)目在采納與普及方面表現(xiàn)出驚人態(tài)勢(shì)的同時(shí)，也給我們帶來(lái)了一系列疑問與困惑。

在今天的文章中，我希望將注意力集中在朋友們最為關(guān)注的評(píng)論議題身上。隨著Docker項(xiàng)目在人氣方面的持續(xù)飆升，很快剛剛接觸這一新生事物的讀者在實(shí)踐過(guò)程中不禁產(chǎn)生了這樣的疑問：如果已經(jīng)決定使用Docker，是否還有必要同時(shí)使用OpenStack？

在給出自己的觀點(diǎn)之前，我打算首先就背景信息入手為各位進(jìn)行講解，從而更為透徹地認(rèn)清這個(gè)命題背后所隱藏的理論基礎(chǔ)。

背景信息

從最為簡(jiǎn)單的構(gòu)成形式出發(fā)，Docker實(shí)際上旨在提供一套能夠在共享式基礎(chǔ)設(shè)施之上對(duì)軟件工作負(fù)載進(jìn)行管理的容器環(huán)境，但同時(shí)又確保不同負(fù)載之間彼此隔離且互不影響。以KVM為代表的虛擬機(jī)系統(tǒng)所做的工作也差不多：創(chuàng)建一套完整的操作系統(tǒng)堆棧，通過(guò)虛擬機(jī)管理程序?qū)⑴c該系統(tǒng)相關(guān)的設(shè)備囊括進(jìn)來(lái)。然而與虛擬機(jī)解決方案的區(qū)別在于，Docker在很大程度上依賴于Linux操作系統(tǒng)所內(nèi)置的一項(xiàng)功能——名為L(zhǎng)XC（即Linux容器）。LXC利用內(nèi)置于操作系統(tǒng)當(dāng)中的各項(xiàng)功能將不同進(jìn)程的內(nèi)存進(jìn)行劃分，甚至能夠在一定程度上拆分CPU與網(wǎng)絡(luò)資源。Docker鏡像不需要像一套全新操作系統(tǒng)那樣進(jìn)行完整的引導(dǎo)過(guò)程，這樣一來(lái)軟件包的體積就能得到大幅壓縮、應(yīng)用程序運(yùn)行在共享式計(jì)算資源之上時(shí)也將具備更為顯著的輕量化優(yōu)勢(shì)。除此之外，Docker還允許工作負(fù)載直接訪問設(shè)備驅(qū)動(dòng)程序、從而帶來(lái)遠(yuǎn)超過(guò)虛擬機(jī)管理程序方案的I/O運(yùn)行速度。在這種情況下，我們得以直接在裸機(jī)設(shè)備上使用Docker，而這就帶來(lái)了前面提到的核心問題：如果已經(jīng)使用了Docker，我們還有必要同時(shí)使用OpenStack等云方案嗎？

前面的結(jié)論絕非信口開河，Boden Russell最近針對(duì)Docker與KVM等虛擬機(jī)管理程序在性能表現(xiàn)上的差異進(jìn)行了基準(zhǔn)測(cè)試，并在DockerCon大會(huì)上公布了測(cè)試結(jié)果。

本次基準(zhǔn)測(cè)試提供相當(dāng)詳盡的具體數(shù)據(jù)，而且如預(yù)期一樣，測(cè)試結(jié)果顯示引導(dǎo)KVM虛擬機(jī)管理程序與引導(dǎo)Docker容器之間存在著顯著的時(shí)間消耗差異。本次測(cè)試同時(shí)表明，二者之間在內(nèi)在與CPU利用率方面同樣存在著巨大區(qū)別，具體情況如下圖所示。

紅色線條為KVM，藍(lán)色線條為Docker。

這種在性能表現(xiàn)上的顯著區(qū)別代表著兩套目的相近的解決方案在資源密度與整體利用率方面大相徑庭。而這樣的差異也將直接體現(xiàn)在運(yùn)行特定工作負(fù)載所需要的資源總量上，并最終反映到實(shí)際使用成本當(dāng)中。

結(jié)論整理

·上述結(jié)論并不單純指向OpenStack，但卻適用于OpenStack以及其它與之類似的云基礎(chǔ)設(shè)施解決方案。在我看來(lái)，之所以問題的矛頭往往最終會(huì)被指向OpenStack，是因?yàn)镺penStack項(xiàng)目事實(shí)上已經(jīng)在私有云環(huán)境領(lǐng)域具備相當(dāng)高的人氣，同時(shí)也是目前我們惟一會(huì)考慮作為Docker替代方案的技術(shù)成果。

·問題的核心不在于OpenStack，而在于虛擬機(jī)管理程序！

很多性能基準(zhǔn)測(cè)試都將Docker與KVM放在了天秤的兩端，但卻很少將OpenStack牽涉于其中。事實(shí)上，前面提到的這次專項(xiàng)基準(zhǔn)測(cè)試同時(shí)將OpenStack運(yùn)行在KVM鏡像與Docker容器環(huán)境之下，結(jié)果顯示這兩類技術(shù)成果能夠帶來(lái)理想的協(xié)作效果?？紤]到這樣的情況，當(dāng)我們選擇將OpenStack運(yùn)行在基于Docker的Nova堆棧當(dāng)中時(shí)——正如OpenStack說(shuō)明文檔提供的下圖所示——那些資源利用率參數(shù)將變得無(wú)關(guān)緊要。

·在這種情況下，云基礎(chǔ)設(shè)施能夠在容器或者虛擬機(jī)管理程序當(dāng)中提供一套完整的數(shù)據(jù)中心管理解決方案，而這僅僅屬于龐大系統(tǒng)整體當(dāng)中的組成部分之一。以O(shè)penStack為代表的云基礎(chǔ)設(shè)施方案當(dāng)中包含多租戶安全性與隔離、管理與監(jiān)控、存儲(chǔ)及網(wǎng)絡(luò)外加其它多種功能設(shè)置。任何云/數(shù)據(jù)中心管理體系都不能脫離這些服務(wù)而獨(dú)立存在，但對(duì)于Docker或者是KVM基礎(chǔ)環(huán)境卻不會(huì)做出過(guò)多要求。

·就目前來(lái)講，Docker還不算是一套功能全面的虛擬化環(huán)境，在安全性方面存在多種嚴(yán)重局限，缺乏對(duì)Windows系統(tǒng)的支持能力，而且因此暫時(shí)無(wú)法作為一套真正可行的KVM備用方案。盡管正在持續(xù)進(jìn)行當(dāng)中的后續(xù)開發(fā)工作將逐步彌合這些差距，但抱持著相對(duì)保守的心態(tài)，這些問題的解決恐怕也同時(shí)意味著容器技術(shù)將在性能表現(xiàn)方面有所妥協(xié)。

·另外需要注意的是，原始虛擬機(jī)管理程序與經(jīng)過(guò)容器化的實(shí)際應(yīng)用程序性能同樣存在著巨大差異，而且下面這幅來(lái)自基準(zhǔn)測(cè)試的圖表清楚地說(shuō)明了這一點(diǎn)。目前可能合理的解釋在于，應(yīng)用程序通常會(huì)利用緩存技術(shù)來(lái)降低I/O資源開銷，而這大大影響了測(cè)試結(jié)果對(duì)真實(shí)環(huán)境中運(yùn)行狀態(tài)的準(zhǔn)確反映。

·如果我們將Docker容器打包在KVM鏡像當(dāng)中，那么二者之間的差異將變得可以忽略不計(jì)。這套架構(gòu)通常利用虛擬機(jī)管理程序負(fù)責(zé)對(duì)云計(jì)算資源的控制，同時(shí)利用Heat、Cloudify或者Kubernetes等流程層在虛擬機(jī)資源的容納范圍之內(nèi)進(jìn)行容器管理。

總結(jié)

由此我得出了這樣的結(jié)論：要想正確地看待OpenStack、KVM以及Docker三者之間的關(guān)系，正確的出發(fā)點(diǎn)是將其視為一整套輔助堆棧——其中OpenStack扮演整體數(shù)據(jù)中心管理方案的角色，KVM作為多租戶計(jì)算資源管理工具，而Docker容器則負(fù)責(zé)與應(yīng)用部署包相關(guān)的工作。

在這樣的情況下，我們可以匯總出一套通用型解決模式，其中Docker分別充當(dāng)以下幾種角色：

·Docker提供經(jīng)過(guò)認(rèn)證的軟件包，并保證其能夠與穩(wěn)定不變的現(xiàn)有基礎(chǔ)設(shè)施模型順利協(xié)作。

·Docker為微服務(wù)POD提供出色的容器化運(yùn)行環(huán)境。

·在OpenStack之上使用Docker，并將其作用與裸機(jī)環(huán)境等同的運(yùn)行平臺(tái)。

前面說(shuō)了這么多，我確實(shí)親眼見證過(guò)不少經(jīng)過(guò)精確定義的工作負(fù)載實(shí)例，對(duì)于它們來(lái)說(shuō)是否使用云基礎(chǔ)設(shè)施僅僅是種自由選項(xiàng)而非強(qiáng)制要求。舉例來(lái)說(shuō)，如果我出于DevOps的目的而考慮建立一套小型自動(dòng)化開發(fā)與測(cè)試環(huán)境，那么我個(gè)人更傾向于在裸機(jī)環(huán)境上直接使用Docker機(jī)制。

而虛擬機(jī)與容器這兩類環(huán)境之間，流程層將成為一套***的抽象對(duì)接工具。

將流程框架與Docker共同使用的一大優(yōu)勢(shì)在于，我們能夠根據(jù)實(shí)際需求、隨時(shí)在OpenStack以及裸機(jī)環(huán)境之間進(jìn)行切換。通過(guò)這種方式，我們將能夠選擇任意一種解決選項(xiàng)——只要其切實(shí)符合我們流程引擎對(duì)于目標(biāo)環(huán)境的具體需要。OpenStack Orchestration（即Heat）在***發(fā)布的Icehouse版本當(dāng)中已經(jīng)明確表示支持Docker環(huán)境。Cloudify作為一款基于TOSCA的開源流程框架，原本適用于OpenStack以及VMware、AWS乃至裸機(jī)等云環(huán)境，而最近也開始將Docker支持納入自身。谷歌Kubernetes主要面向的是GCE協(xié)作目標(biāo)，但我們也能夠通過(guò)自定義來(lái)使其適應(yīng)其它云或者運(yùn)行環(huán)境。

英文：http://opensource.com/business/14/11/do-i-need-openstack-if-i-use-docker