[[123415]] 

從一項顛覆性的技術成果轉化并衍生出一整套社區體系，Docker在發展速度上打破了一個又一個歷史紀錄。然而，Docker項目在采納與普及方面表現出驚人態勢的同時，也給我們帶來了一系列疑問與困惑。

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

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

背景信息

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

前面的結論絕非信口開河，Boden Russell最近針對Docker與KVM等虛擬機管理程序在性能表現上的差異進行了基準測試，并在DockerCon大會上公布了測試結果。

本次基準測試提供相當詳盡的具體數據，而且如預期一樣，測試結果顯示引導KVM虛擬機管理程序與引導Docker容器之間存在著顯著的時間消耗差異。本次測試同時表明，二者之間在內在與CPU利用率方面同樣存在著巨大區別，具體情況如下圖所示。

紅色線條為KVM，藍色線條為Docker。

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

結論整理

·上述結論并不單純指向OpenStack，但卻適用于OpenStack以及其它與之類似的云基礎設施解決方案。在我看來，之所以問題的矛頭往往最終會被指向OpenStack，是因為OpenStack項目事實上已經在私有云環境領域具備相當高的人氣，同時也是目前我們惟一會考慮作為Docker替代方案的技術成果。

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

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

·在這種情況下，云基礎設施能夠在容器或者虛擬機管理程序當中提供一套完整的數據中心管理解決方案，而這僅僅屬于龐大系統整體當中的組成部分之一。以OpenStack為代表的云基礎設施方案當中包含多租戶安全性與隔離、管理與監控、存儲及網絡外加其它多種功能設置。任何云/數據中心管理體系都不能脫離這些服務而獨立存在，但對于Docker或者是KVM基礎環境卻不會做出過多要求。

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

·另外需要注意的是，原始虛擬機管理程序與經過容器化的實際應用程序性能同樣存在著巨大差異，而且下面這幅來自基準測試的圖表清楚地說明了這一點。目前可能合理的解釋在于，應用程序通常會利用緩存技術來降低I/O資源開銷，而這大大影響了測試結果對真實環境中運行狀態的準確反映。

·如果我們將Docker容器打包在KVM鏡像當中，那么二者之間的差異將變得可以忽略不計。這套架構通常利用虛擬機管理程序負責對云計算資源的控制，同時利用Heat、Cloudify或者Kubernetes等流程層在虛擬機資源的容納范圍之內進行容器管理。

總結

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

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

·Docker提供經過認證的軟件包，并保證其能夠與穩定不變的現有基礎設施模型順利協作。

·Docker為微服務POD提供出色的容器化運行環境。

·在OpenStack之上使用Docker，并將其作用與裸機環境等同的運行平臺。

前面說了這么多，我確實親眼見證過不少經過精確定義的工作負載實例，對于它們來說是否使用云基礎設施僅僅是種自由選項而非強制要求。舉例來說，如果我出于DevOps的目的而考慮建立一套小型自動化開發與測試環境，那么我個人更傾向于在裸機環境上直接使用Docker機制。

而虛擬機與容器這兩類環境之間，流程層將成為一套***的抽象對接工具。

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

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