本文全面審視了三種利用容器作為虛擬機(jī)系統(tǒng)替代方案的方式。

容器已經(jīng)在網(wǎng)絡(luò)領(lǐng)域掀起了一股潮流，其所帶來的輕量化、更為靈活的效果足以作為傳統(tǒng)虛擬機(jī)系統(tǒng)的替代方案。容器與虛擬機(jī)之間的最大差別在于，單一容器可以共享多個常用文件，而虛擬機(jī)則存在著離散性與原子性——即使存儲與網(wǎng)絡(luò)資源處于虛擬化及共享狀態(tài)。具體來講，虛擬機(jī)更像是互不關(guān)聯(lián)的孤島，而容器之間則更像是群島關(guān)系。

我們預(yù)計，終有一天大部分操作系統(tǒng)實(shí)例會由虛擬機(jī)轉(zhuǎn)向容器環(huán)境。事實(shí)上，操作系統(tǒng)供應(yīng)商們已經(jīng)開始爭先恐后地壓縮自家產(chǎn)品的體積，從而使其新版本更容易適應(yīng)容器環(huán)境下的具體要求。

那么，容器是否已經(jīng)準(zhǔn)備好在我們的網(wǎng)絡(luò)體系當(dāng)中占據(jù)核心地位?容器的優(yōu)勢與短板又分別是什么?帶著這些問題，我們測試了三款容器方案——Docker、Rocket/rkt以及openVZ/Odin(原名為Parallels)。

Docker在容器技術(shù)領(lǐng)域?qū)儆诋?dāng)之無愧的龍頭，但其中也存在著不少需要克服的潛在問題。Rocket/rkt解決了其中一部分問題，但卻尚未準(zhǔn)備好全面進(jìn)入大家的生產(chǎn)環(huán)境。

OpenVZ/Odin能夠同時提供容器方案外加一套兼容多種主流虛擬機(jī)管理平臺的“虛擬環(huán)境”，但仍然存在著一些局限。

這三套方案都具備相當(dāng)出色的實(shí)用性，但與傳統(tǒng)虛擬機(jī)管理程序及虛擬機(jī)系統(tǒng)相比，其實(shí)際水平仍然有所欠缺。不過在精心部署與認(rèn)真打理之下，三者也確實(shí)擁有著可圈可點(diǎn)的潛在發(fā)展空間。

在對三款產(chǎn)品進(jìn)行測試時，我們選擇了企業(yè)級系統(tǒng)基礎(chǔ)設(shè)施作為背景，而非DevOps及持續(xù)開發(fā)環(huán)境。不過容器背后蘊(yùn)藏的巨大能量意味著其很難脫離系統(tǒng)基礎(chǔ)設(shè)施存在，而其控制層也尚不適合或者說無法充分適應(yīng)持續(xù)開發(fā)實(shí)踐當(dāng)中的快速部署、規(guī)模調(diào)整以及設(shè)計思路。

此次測試的每一款產(chǎn)品都處于快速轉(zhuǎn)型的過程當(dāng)中，其中年紀(jì)稍長的OpenVZ/Virtuozzo扮演的角色則略有區(qū)別——其更像是一款面向服務(wù)供應(yīng)商的控制層產(chǎn)品。

容器所要解決的實(shí)際問題

容器技術(shù)的演變主要受到編排流程需求的推動，客戶需要較虛擬機(jī)部署更具輕量化優(yōu)勢的方案，但同時又能夠繼續(xù)享受到集群化、快速安裝及移除等機(jī)制所帶來的便利。此外，這一切還需要配合可靠性與安全性保障，這是每一套新型平臺需要面對的關(guān)鍵性考核標(biāo)準(zhǔn)，同時也是云計算概念發(fā)展所帶來的重要副產(chǎn)品之一。

在openVZ/Virtuozzo方案當(dāng)中，容器執(zhí)行流程與快速推出能力更多面向負(fù)責(zé)將基礎(chǔ)設(shè)施與設(shè)備進(jìn)行匹配并交付給客戶的服務(wù)供應(yīng)商。具體實(shí)例包括網(wǎng)站/電子郵件打包托管、網(wǎng)站營銷、語言高度本地化的設(shè)備型產(chǎn)品以及相關(guān)服務(wù)。在這種情況下，根據(jù)操作系統(tǒng)的多種預(yù)設(shè)置實(shí)例提供操控與計費(fèi)方案將成為拉攏客戶的關(guān)鍵所在。

作為Parallels品牌(openVZ贊助方兼Virtuozzo出品方)調(diào)整后的產(chǎn)物，Odin長久以來一直肩負(fù)著上述任務(wù)。它具備更出色的可預(yù)測性、更理想的內(nèi)置功能搭配，而且靈活性水平也足夠作為Docker的托管方案使用。

Docker提供的是一套輕量化操作系統(tǒng)環(huán)境，并通過應(yīng)用操控指令的方式嚴(yán)格保證控制措施的推行。其具體操控內(nèi)容既可立足于基礎(chǔ)性層面，也可以涉及復(fù)雜度更高、針對性更強(qiáng)的控制工作。

Rocket/rkt與Docker非常相似，但卻某些方面卻顯得更加原始(而且尚未準(zhǔn)備好正式進(jìn)入生產(chǎn)環(huán)境)。不過目前Rocket似乎已經(jīng)針對這些問題作出了改進(jìn)，并開始給Docker造成日益嚴(yán)重的競爭威脅。在實(shí)際測試中，我們發(fā)現(xiàn)rkt能夠很好地滿足我們的一部分工程技術(shù)需要，而Docker在這些方面卻顯得有些停滯不前。

Odin及其開發(fā)成果openVZ將自身標(biāo)榜成為一套虛擬環(huán)境，在這一混合模型當(dāng)中、經(jīng)過修改的內(nèi)核被用于同時承擔(dān)起傳統(tǒng)虛擬機(jī)管理程序與容器托管環(huán)境這兩大任務(wù)。舉例來說，大家完全可以將Docker或者Rocket運(yùn)行在openVZ之上。

我們發(fā)現(xiàn)，這三款產(chǎn)品使用的實(shí)現(xiàn)方式幾乎完全相同。事實(shí)上，這三個項目之間確實(shí)存在著交叉支持的現(xiàn)象，當(dāng)然此外還有很多其他貢獻(xiàn)者參與了進(jìn)來——就連主要貢獻(xiàn)者的名單都相當(dāng)驚人。三者似乎都通過多種方式為彼此作出贊助，而它們也代表著同樣的一股新興勢力——即以輕量化為主要特色的實(shí)例管理解決方案，旨在摒棄傳統(tǒng)虛擬機(jī)管理程序的“沉重”劣勢。

因此，容器托管方案到底能否徹底取代曾經(jīng)稱霸一時的虛擬機(jī)管理程序呢?就我們目前得出的答案來看，暫時還不行——它們的著眼點(diǎn)與既定目標(biāo)完全不同。不過同時需要指出的是，以CoreOS、Ubuntu Server小型實(shí)例甚至紅帽即將推出的Atomic發(fā)行版等為代表的輕量化操作系統(tǒng)都已經(jīng)在設(shè)計當(dāng)中考慮到了作為框架引入容器托管方案的可能性。而相信我們也將在Windows 10當(dāng)中見到容器技術(shù)的普及——雖然Mac OS目前還沒有在容器方面作出任何嘗試。

下面讓我們對這三大主流方案作出一一解析。

OpenVZ/Odin Virtuozzo 6.0

OpenVZ是一款Linux發(fā)行版，主要負(fù)責(zé)對虛擬機(jī)以及/或者容器訪客實(shí)例進(jìn)行托管。OpenVZ資源以現(xiàn)代3.X+版本Linux內(nèi)核為基礎(chǔ)，同時利用OpenVZ內(nèi)核實(shí)現(xiàn)下載。雖然我們可以將大量不同類型的OpenVZ組件服務(wù)安裝在Linux 3.X+當(dāng)中，但只有OpenVZ內(nèi)核的功能能夠得到全面支持。

OpenVZ訪客實(shí)例可以表現(xiàn)為虛擬機(jī)或者容器系統(tǒng)。當(dāng)大家向其中添加操控機(jī)制、計費(fèi)以及管理面板時，則需要用到另一款商用產(chǎn)品——Odin Virtuozzo。順帶一提，Odin是Parallels這家瑞士企業(yè)進(jìn)行品牌調(diào)整之后的產(chǎn)物。

我們早在2008年就曾經(jīng)對Virtuozzo的Windows版本進(jìn)行過評測。當(dāng)時Virtuozzo只適用于32位服務(wù)器環(huán)境，由此帶來的內(nèi)存容量局限嚴(yán)重影響了它的實(shí)用性。雖然這款Windows產(chǎn)品目前仍然存在，但Virtuozzo如今已經(jīng)能夠使用共享內(nèi)核，從而在Linux平臺之上順暢打理容器系統(tǒng)。

我們下載到openVZ并將其安裝到了一臺聯(lián)想ThinkServer RD640設(shè)備之上。由于這套方案所使用的Linux內(nèi)核已經(jīng)相當(dāng)古老，所以我們需要盡可能考量其兼容性水平，確保其能夠與硬件設(shè)備順利協(xié)作。根據(jù)說明，我們擁有大量服務(wù)器功能可供選擇——雖然尚未在測試中得到證實(shí)——而且任何能夠與Red Hat 6相兼容的服務(wù)器硬件，都將能支持openVZ或者Odin。

雖然我們已經(jīng)證實(shí)了openVZ與Odin能夠順利使用RAID，但大家仍然只能從HBA以及JBOD磁盤組合當(dāng)中直接進(jìn)行選擇。此外，我們通過測試發(fā)現(xiàn)其支持“硬”IPv6虛擬機(jī)/容器地址，但總體而言IPv6支持能力仍然有所局限。

Virtuozzo是一套虛擬環(huán)境，而且在我們的測試當(dāng)中，托管虛擬機(jī)為典型的Windows Server。Linux及FreeBSD最好是以容器的方式處理。Virtuozzo通過一款Web應(yīng)用實(shí)現(xiàn)控制，而且在正常UI之外還提供必要的命令行組件。如果大家愿意，幾乎可以完全通過命令行界面完成全部控制操作。

容器可以由Docker、Rocket或者LinuXContainers/LXC生成。此外，大家也可以使用下載自O(shè)din的OpenVZ/VIrtuozzo容器庫。

OpenVZ的使用方式與Docker以及rkt非常相似。虛擬環(huán)境的安裝非常簡便，其硬件性能表現(xiàn)也與VMware 5.5下的同等配置保持一致。我們并沒有使用泛用式基準(zhǔn)測試檢查其性能表現(xiàn)，此次選擇的只有作為火狐35性能指標(biāo)的SciMark瀏覽器測試——這是考慮到其擁有類似的工作負(fù)載以及使用背景。

從這個角度來看，OpenVZ在很大程度上類似于虛擬機(jī)管理程序，只不過在整體處理強(qiáng)度方面低于VMware——或者說其更接近Windows Hyper-V。值得一提的是，OpenVZ并不具備VMware ESXi 5.X提供的專用功能集——或者成本水平。

測試OpenVZ與Virtuozzo

我們首先嘗試了OpenVZ/OVZ。安裝完成后提供兩套庫，其一面向各類紅帽式發(fā)行版，另一套則面向Debian各發(fā)行版。下面所使用的分支版本已經(jīng)過預(yù)sysctrl，因此可作為后sysctrl參考。各個分支版本在功能性方面基本一致，因為安裝基礎(chǔ)中的二進(jìn)制文件非常相近。

相關(guān)說明文件適用于熟悉Linux的使用者，不過在新手看來內(nèi)容似乎還不夠完備。

OpenVZ傾向于配合裸機(jī)，但也能夠以虛擬機(jī)方式運(yùn)行。在使用裸機(jī)時，其性能水平能夠得到顯著提升。我們強(qiáng)烈建議大家不要使用OpenVZ或者VIrtuozzo作為虛擬機(jī)方案，這將導(dǎo)致性能水平急劇下滑——特別是在資源分配過度時，主機(jī)整體都會出現(xiàn)卡頓。

OpenVZ容器，或者稱其為“虛擬環(huán)境”，的基礎(chǔ)定位為一項cgroup-demoted服務(wù)。如果我們利用OpenVZ內(nèi)核來替代標(biāo)準(zhǔn)Linux內(nèi)核，則可以使用一套名為ploop的文件系統(tǒng)，并借此降低需要使用的Linux節(jié)點(diǎn)數(shù)量。

在選定文件系統(tǒng)類型之后，我們隨后需要安裝主容器控制器vzctl，接下來是負(fù)責(zé)控制容器資源量/配額的vzquota。其中vzctl應(yīng)用能夠被用于部署來自openvz.org網(wǎng)站的各類容器鏡像。這些容器在初始體積非常小巧，我們能夠以壓縮包的形式將其解壓到緩存目錄當(dāng)中并加以部署。

在這里我們要提醒大家，Linux 3.x新版本內(nèi)核中所使用的內(nèi)核并非全部能夠支持內(nèi)存與CPU控制(除了OpenVZ的內(nèi)核)。我們在運(yùn)行過程中并沒有發(fā)現(xiàn)問題，但可以想象肯定會出現(xiàn)某種內(nèi)核無法由OpenVZ全部實(shí)現(xiàn)編譯的情況，這會導(dǎo)致主機(jī)內(nèi)的虛擬機(jī)或者容器系統(tǒng)單純依賴于OpenVZ內(nèi)核。從表面上看，在必要的情況下任意內(nèi)核都能夠通過重新編譯啟用全部功能，但我們并沒有在測試中加以檢驗。

各容器鏡像在發(fā)送中還配合一條GPG密鑰，用于對該鏡像進(jìn)行驗證。這一點(diǎn)非常重要。根據(jù)具體需求，大家可以構(gòu)建自己的鏡像，當(dāng)然目前也已經(jīng)有大量OpenVZ源Linux鏡像供我們選擇。已經(jīng)下載完成的鏡像可以通過鏡像緩存直接進(jìn)行部署，不過在我們的測試環(huán)境下，其速度并不像Docker配合CentOS那么出色。部署過程的時間差異幾乎可以忽略不計，多次部署之間的時差大約為數(shù)秒，這可能是因為ploop需要花點(diǎn)時間創(chuàng)建自己的文件系統(tǒng)。

Odin Virtuozzo 6 SP1

Odin的Virtuozzo屬于OpenVZ的商業(yè)檢測版本，其在我們的測試當(dāng)中擁有非常接近于Red Hat 6的實(shí)際表現(xiàn)。Virtuozzo的安裝過程耗時相當(dāng)長，但最終還是識別出了我們使用的iSCSI存儲機(jī)制——雖然我們發(fā)現(xiàn)，iSCSI會拖慢Virtuozzo的速度表現(xiàn)。NFS也受到支持，而且在測試當(dāng)中其速度僅比iSCSI稍微快上一點(diǎn)。

Virtuozzo提供一套網(wǎng)絡(luò)頁面，用于對IP配置(IPv4)進(jìn)行操控，其中包括虛擬網(wǎng)卡及VLAN。其具體方式類似于Xen/XenServer與VMware對網(wǎng)絡(luò)機(jī)制的處理思路，同時支持多租戶配置方案。

我們可以通過兩種方式創(chuàng)建Odin虛擬環(huán)境，其一為采用本地虛擬機(jī)管理程序——這意味著任何擁有良好處理器/平臺支持效果的操作系統(tǒng)——另一種則專門針對Linux容器負(fù)載所設(shè)計。

這些有效載荷可以由ploop文件系統(tǒng)負(fù)責(zé)承載，但pfcached/ParallelsFileCacheDaemon也可以在自己的ploop文件系統(tǒng)緩存當(dāng)中對文件執(zhí)行常見的重復(fù)數(shù)據(jù)刪除操作。其中pfcached利用一套算法選擇如何及何時執(zhí)行重復(fù)數(shù)據(jù)刪除操作，但我們估計這不太可能帶來顯著的初始性能提升——因為該算法需要經(jīng)過相當(dāng)長的適應(yīng)時間才能帶來明確成效。

OpenVZ/Virtuozzo容器由于由vzctl或者prctl負(fù)責(zé)控制的實(shí)例。大家可以通過各種常見方式與之進(jìn)行對接，包括ssh、RDP或者控制臺。反過來，容器會自主執(zhí)行相關(guān)任務(wù)，包括處理工作、處理并存儲數(shù)據(jù)，或者生成一套網(wǎng)絡(luò)頁面等。

容器或者虛擬機(jī)可以通過虛擬以太網(wǎng)進(jìn)行隔離，而且不支持內(nèi)部容器或者虛擬機(jī)通信連接; 要實(shí)現(xiàn)這些功能，大家需要自己想辦法完成，包括使用Puppet、Chef或者其它方案。虛擬USB、磁盤驅(qū)動器以及DVD一應(yīng)俱全，不過只支持原始視頻。我們可能需要構(gòu)建起多臺硬件服務(wù)器并加以對接，才能實(shí)現(xiàn)高可用性目標(biāo)，不過此次測試并沒有就此進(jìn)行嘗試。

我們安裝了四套測試Windows及Linux ISO庫(使用是我們自己的ISO源)來充當(dāng)訪客虛擬機(jī)，全部獲得成功。我們并沒有嘗試高級圖形處理、虛擬USB端口以及音頻端口。我們還測試了幾套來自同一套Linux發(fā)行版的Odin鏡像，并發(fā)現(xiàn)不同發(fā)行版之間的安裝過程并無差別(我們使用的實(shí)例為Ubuntu 14.04與Odin提供的Ubuntu 14.04)。

在OpenVZ當(dāng)中，用戶可以隨時下載鏡像，并將其部署在主機(jī)之上。使用預(yù)格式化模板、由用戶制作或者OpenVZ/Parallels/Odin提供的鏡像都能夠充分享受內(nèi)存優(yōu)化帶來的效果，不過周期性出現(xiàn)的負(fù)載峰值可能導(dǎo)致虛擬機(jī)或者容器出現(xiàn)運(yùn)行緩慢狀況——當(dāng)然，此類情況在其它預(yù)設(shè)有性能上限的虛擬機(jī)管理程序當(dāng)中也很常見。

CPU MHz(即時鐘頻率)、性能峰值以及CPU數(shù)量皆可隨意分配。OpenVZ不提供CPU親和力選項，這可能是因為我們很難在Linux內(nèi)核那孱弱的CPU任務(wù)親和水平之上實(shí)現(xiàn)此類效果。

在使用ploop的情況下，我們能夠輕松實(shí)現(xiàn)文件系統(tǒng)快照保存，而這也是VIrtuozzo實(shí)現(xiàn)虛擬機(jī)或者容器實(shí)時遷移的前提所在。事實(shí)上，虛擬機(jī)或者容器文件系統(tǒng)被打包成為一個巨大的對象，而非一系列由各類sysctl操作控制的分散文件、文件夾以及索引節(jié)點(diǎn)。不過我們并沒有測試其實(shí)時遷移效果。

使用感受

我們可以在Virtuozzo當(dāng)中塞進(jìn)數(shù)量驚人的容器及虛擬機(jī)系統(tǒng)。訪問操作起效正常，而且該操作系統(tǒng)能夠識別出主機(jī)上的全部24個CPU計算核心，并允許我們將其分配給虛擬機(jī)或者容器。由于我們的存儲資源只有數(shù)TB、內(nèi)存則為128 GB，因此我們不清楚運(yùn)行當(dāng)中到底是哪種資源先達(dá)到瓶頸——處理器還是存儲機(jī)制。我們可以對磁盤及內(nèi)存進(jìn)行過度分配，并在測試當(dāng)中發(fā)現(xiàn)部分虛擬機(jī)因此出現(xiàn)了異常。

我們在測試當(dāng)中收到了一條來自虛擬機(jī)或者容器的異常狀態(tài)通知消息。雖然有些失落，但這類問題其實(shí)并不罕見。我們無法在虛擬機(jī)已經(jīng)停機(jī)的情況下通過設(shè)置最低CPU閾值來觸發(fā)警報，因為其只適用于追蹤C(jī)PU的使用量峰值。IPMI消息收發(fā)或者負(fù)責(zé)向檢測機(jī)制發(fā)送主機(jī)狀態(tài)的類似API集能夠起到很好的提示作用，而且我們應(yīng)該能夠在必要時將nagios或者其它監(jiān)控工具嵌入到虛擬機(jī)/窗口負(fù)載當(dāng)中。然而，我們發(fā)現(xiàn)磁盤作為資源類型之一也面臨著同樣的問題——我們會在磁盤被寫滿之后收到消息，但其連續(xù)24個小時未進(jìn)入活動狀態(tài)卻不會提供任何通知(這可能意味著主機(jī)已經(jīng)發(fā)生故障)。盡管Virtuozzo在定位上不同于VMware XenServer或者Hyper-V，但我們?nèi)匀挥斜匾峁┻@類功能以滿足多租戶內(nèi)部云或者將其作為云平臺的小型/中型服務(wù)供應(yīng)商的實(shí)際需求。

OpenVZ的容器也可以采取Docker形式并在Docker環(huán)境下運(yùn)行，這就使其能夠與Docker生態(tài)系統(tǒng)順利對接。由于Parallels擁有自己的多種容器形式，我們發(fā)現(xiàn)Docker容器格式的存在有些多余，但我們?nèi)匀辉贑entOS系統(tǒng)之下測試了主機(jī)平臺與Docker的協(xié)作效果。在原始SciMark基準(zhǔn)測試當(dāng)中，執(zhí)行時間大概要比原生容器運(yùn)行時間長18%，但與運(yùn)行同類虛擬機(jī)比較時耗只長15%。所以，大家可以選擇使用Docker，但我們并不推薦這么做，因為這相當(dāng)于硬性弄出了一套影響性能的套娃結(jié)構(gòu)。

Docker 1.6

Docker能夠運(yùn)行在數(shù)量繁多的Linux發(fā)行版、Mac OS版本以及實(shí)驗性微軟平臺之上。我們在測試中嘗試中四個Linux主機(jī)版本外加一臺Mac OS主機(jī)。這種強(qiáng)大的兼容能力其實(shí)有好處也有壞處。畢竟Docker之所以具備這么高的人氣，主要是由于其便捷性以及通過同一套控制機(jī)制對各類相似及差異化容器加以編排的能力。

大部分現(xiàn)有Linux內(nèi)核以及MacOS都能夠運(yùn)行Docker容器。我們可以將Docker安裝在主機(jī)平臺之上，而后再在Docker控制“之內(nèi)”啟動一套操作系統(tǒng)實(shí)例。Docker在托管操作系統(tǒng)實(shí)例時擁有諸多便捷特性，換句話說，我們可以輕松將Docker編排之下的虛擬機(jī)資源進(jìn)行拆分。

Docker的價值之一在于，我們可以從Docker庫中規(guī)模龐大的實(shí)例類型中作出選擇。大家可以從Docker.com網(wǎng)站處獲取庫及容器選項，其中不少都擁有搶眼的知名應(yīng)用開發(fā)商“官方”標(biāo)記。其中一部分由Docker網(wǎng)站托管，也有一部分可以通過GitHub獲得?？傮w而言，陳列在我們面前的是數(shù)量繁多的開發(fā)平臺以及經(jīng)過打包的應(yīng)用方案(包括WordPress衍生版本以及Hadoop集群組件等等)。

Ubuntu 14.04服務(wù)器可以算是一類典型的Docker實(shí)例了，其使用的主機(jī)資源相對比較有限。容器當(dāng)中運(yùn)行的可以是Linux/Apache/MySQL/PHP/Perl(LAMP)等實(shí)例，而且此類可選實(shí)例數(shù)量繁多且類型多樣。我們現(xiàn)在能夠從Canonical或者紅帽公司那里得到大量經(jīng)過體積縮減的鏡像，其中一部分鏡像甚至通過刻意精簡來防止未使用進(jìn)程從容器中搶奪CPU計算周期。

只需要使用docker run命令，我們就能輕松讓一切運(yùn)轉(zhuǎn)起來。這條命令會將容器/虛擬機(jī)實(shí)例化，并使用目錄用于數(shù)據(jù)存儲——與會對安全水平造成影響的Linux chroot命令不同，這更接近于OpenVZ/Virtuozzo。

Docker容器鏡像使用union文件系統(tǒng)，或者簡稱unionfs，其會為容器制作出文件夾基礎(chǔ)體系。與OpenVZ/VIrtuozzo類似，Docker會通過unionfs為每套利用Docker運(yùn)行的容器提供分層結(jié)構(gòu)。這就使得類似的鏡像之間能夠通過一次更新就共享到同樣的基礎(chǔ)文件，而且會在需要保存鏡像快照或者更新鏡像時節(jié)約存儲空間。舉例來說，我們可以一次性更新openssh并將效果推廣到20套容器當(dāng)中，因為它們依賴于同一套已完成更新的鏡像。

使用unionfs能夠顯著提高Docker的執(zhí)行效率，但這同時也可能由于源鏡像損壞而令大量容器陷入癱瘓——業(yè)界對此一直提出尖銳的批評。我們也可以利用RESTful put/get在user-initiator命令當(dāng)中對Docker的容器鏡像加以控制。不過這條命令與root user一樣，非常強(qiáng)大但也非常危險。通過這種方式，我們能夠?qū)崿F(xiàn)對訪問、密碼、SSH密鑰安全庫以及其它強(qiáng)烈推薦使用的標(biāo)準(zhǔn)安全機(jī)制的控制。這種控制方式有限松散但卻速度很快，而且充滿樂趣。

ISO鏡像也能夠以自動化方式構(gòu)建，這樣企業(yè)用戶就能夠更為高效地維護(hù)自己的鏡像結(jié)構(gòu)并在符合安全要求的前提下實(shí)現(xiàn)鏡像控制。

我們可以通過ssh通信或者其它API訪問Docker內(nèi)部，包括使用Puppet等通信結(jié)構(gòu)。存儲經(jīng)過降級，而且可以通過user security加以進(jìn)一步控制(例如chroot、chmod或者其它規(guī)定的文件限制/元數(shù)據(jù)控制機(jī)制)。在某些情況下，大家也可以使用ploop或者其它文件系統(tǒng)來享受到我們之前在OpenVZ/Virtuozzo章節(jié)中提到的便利效果。

利用Docker生成容器環(huán)境

Docker并不像OpenVZ/VIrtuozzo那樣專注于幫助常規(guī)容器節(jié)約存儲空間，例如對常規(guī)存儲文件進(jìn)行重復(fù)數(shù)據(jù)刪除。在理論上講，OpenVZ/Virtuozzo能夠以更為緊湊的方式對容器進(jìn)行打包。也就是說，在同樣的硬件平臺之上，我們可以利用OpenVZ/Virtuozzo承載大量Docker容器實(shí)例，而且實(shí)現(xiàn)方式也很簡單。

而且Docker也不像Virtuozzo那樣提供控制層檢測機(jī)制。Docker要求我們使用控制腳本及密鑰完成管理工作，相比之下Virtuozzo的方式顯然更為便捷。目前市面上存在大量能夠完成此類任務(wù)的第三方應(yīng)用產(chǎn)品，但我們并沒有在測試中加以嘗試。

管理大量容器主機(jī)并不是什么難事，不過這對于管理員的評估技能提出了一些要求。Docker Swarm是一款A(yù)PI，允許大家將一組Docker容器視為單一對象加以操作，這意味著整套容器集群都能夠?qū)崿F(xiàn)單點(diǎn)控制。這不僅將實(shí)例的快速向外擴(kuò)展變?yōu)榭赡埽瑫r也為實(shí)例預(yù)留了更為可觀的運(yùn)行空間。

測試流程里最讓我們樂在其中的部分，就是嘗試?yán)米约旱拿畋ＷC容器步調(diào)一致。這部分功能還不夠完善，而且我們需要提醒大家，即使能夠輕松玩轉(zhuǎn)Docker Swarm、您也有可能在調(diào)度工作中使一部分容器進(jìn)入休眠狀態(tài)。

將大量容器匯總成單一托管對象會給管理員帶來巨大的職責(zé)壓力。值得一提的是，我們可以利用Apach Mesos之類的應(yīng)用對集群化容器這樣的大規(guī)模數(shù)據(jù)集進(jìn)行嚴(yán)格控制。從企業(yè)安全的角度出發(fā)，大家必須非常謹(jǐn)慎地處理這方面工作，否則資源暴露的直接后果就是發(fā)生資源劫持。

Rocket/rkt 0.5.4

Rocket的出現(xiàn)與發(fā)展幾乎一直伴隨著CoreOS的前進(jìn)腳步。CoreOS是一款經(jīng)過嚴(yán)格修整的操作系統(tǒng)，專注于減少攻擊面并為Docker提供高效的運(yùn)行基礎(chǔ)。CoreOS在GitHub的項目描述中將自己形容為一套App容器運(yùn)行時(系統(tǒng))，這是一套體積小巧但穩(wěn)定性極高的應(yīng)用平臺。

Rocket lacks some key components and requires more construction savvy than either Docker or Virtuozzo. We were pleased to see that it focuses on security with source image provenance and payload control.

立足于Linux內(nèi)核，CoreOS的發(fā)展速度稍微落后于Docker，這是因為它更多作為一款集群操作系統(tǒng)存在、而非控制層。CoreOS是rkt項目的贊助商之一，但該項目目前還沒有作好進(jìn)入生產(chǎn)環(huán)境的準(zhǔn)備。從原則角度講，我們一般不會在審查當(dāng)中對這類產(chǎn)品提出太高的要求，因為技術(shù)業(yè)界普遍認(rèn)為beta測試版本并不適用于實(shí)際生產(chǎn)。

由于這三款容器解決方案都采用幾乎同樣的成熟Linux組件，我們會更多地關(guān)注rkt的設(shè)計思路而非其實(shí)踐表現(xiàn)。平心而論，rkt同樣非常復(fù)雜，但考慮到其在各個層級采用的嚴(yán)格安全措施，我們認(rèn)為它的潛在安全風(fēng)險更低一些。

Rocket在容器實(shí)例構(gòu)建管理機(jī)制當(dāng)中納入了嚴(yán)格的監(jiān)控手段，這意味著鏡像在由rkt加以啟動之前，必須以特定方式進(jìn)行構(gòu)建。這一點(diǎn)與OpenVZ以及Docker的管理方式有所不同，因為二者所使用的容器控制器都能夠直接使用現(xiàn)成的ISO鏡像——包括來自當(dāng)前正在運(yùn)行的系統(tǒng)、容器控制器庫/注冊庫或者隔壁好友的鏡像。但這些在Rocket當(dāng)中都無法實(shí)現(xiàn)。

在測試當(dāng)中，我們發(fā)現(xiàn)rkt在容器運(yùn)行時控制方面的基礎(chǔ)效果與Docker及OpenVZ非常接近：使用守護(hù)程序控制容器數(shù)量，并在整個生命周期之內(nèi)對容器實(shí)例加以管理。由于執(zhí)行標(biāo)準(zhǔn)更為嚴(yán)格，因為rkt的安全性水平要比Docker更高。

從歷史角度看，業(yè)界對于Docker安全性/可靠性的質(zhì)疑催生了Rocket/rkt的出現(xiàn)乃至發(fā)展。事實(shí)上，rkt所遵循的原則體現(xiàn)了其不同于其它容器技術(shù)方案的核心價值觀。由此產(chǎn)生的App Container(簡稱appc)正是一項專門的規(guī)范，用于解決Docker安全性薄弱的問題。而系統(tǒng)內(nèi)在可靠性也必須被納入優(yōu)先級考量，無論實(shí)際接受管理的容器數(shù)量是多是少——盡管rkt允許重載，這一前提也絲毫沒有動搖。

考慮到以上原則，appc規(guī)范專注于確保所下載的鏡像擁有可靠的簽名出處以及正確的組裝方法完整性。下面我們引述幾條來自GitHub的appc規(guī)范要求：

這項規(guī)范的核心目標(biāo)包括：

設(shè)計出下載及啟動速度更快的App Container

確保鏡像擁有加密驗證以及理想的可緩存能力

通過設(shè)計確保實(shí)現(xiàn)手段的可組合性與獨(dú)立性

使用常見技術(shù)進(jìn)行加密、歸檔、壓縮以及傳輸

利用DNS命名空間對鏡像進(jìn)行命名與發(fā)現(xiàn)

Rocket將自身作為上述規(guī)范的典型實(shí)現(xiàn)機(jī)制，而其它多家廠商也對這一定位表示認(rèn)同，具體包括紅帽、谷歌、VMware以及Apcera等。而且盡管CoreOS+rkt這一組合與appc規(guī)范要求基本屬于同一含義，但rkt在實(shí)現(xiàn)方案角度的地位同VMware(Lightwave/Photon)以及Apcera(Continuum)等同——雖然截至測試之時，后兩者尚未正式推出。

Rkt遵循appc方法生成tar(即Tape Archive)格式的鏡像文件而非ISO，因此其GPG密鑰會同ISO本身一同進(jìn)行散列處理，從而保證容器底層鏡像經(jīng)過嚴(yán)格驗證。通過這種方式，源文件的完整性與安全性更具保障(幾乎不可能出現(xiàn)文件替換、補(bǔ)丁等級錯誤、惡意軟件、軟件包損壞以及其它可能影響ISO使用的情況)。而且每套鏡像都擁有一個獨(dú)一無二的ImageID。

我們可以創(chuàng)建一個文件夾，并將其作為rkt的rootfs或者頂層文件系統(tǒng)。我們并未對鏡像進(jìn)行壓縮，如果大家需要采取這種處理方式，請記得預(yù)先在未壓縮的鏡像當(dāng)中插入JSON格式的鏡像manifest。大家也可以根據(jù)需求選擇其它的壓縮步驟，包括在鏡像在解壓/解密時擁有密鑰作為保護(hù)(我們推薦使用AES-256)。我們還在等待能夠直接完成上述操作而無需使用命令行界面的控制層機(jī)制——不過直接使用命令行也不是很復(fù)雜。

一旦完成了加密過程并將JSON manifest插入到鏡像當(dāng)中，我們即可將其投入執(zhí)行。鏡像在啟動后會作為pod存在，其本質(zhì)上也就是容器，但“pod”這個語用來形容鏡像似乎更為形象。

所謂pod當(dāng)中包含有一整套擁有自己ID的可執(zhí)行文件，并會作為單一對象使用UUID(遵循IETF RFC 4122)對所執(zhí)行pod的功能進(jìn)行操作。該UUID擁有自己的命名空間，由rkt創(chuàng)建并進(jìn)行持續(xù)管理; 通過這種方式，也就實(shí)現(xiàn)了實(shí)例控制。隨后rkt會通過初始化操作為該UUID創(chuàng)建一個rootfs，其中包含與JSON manifest相關(guān)文件夾的一份白名單。每一次容器對象開始啟動，它都會創(chuàng)建一個一次性的新文件系統(tǒng)，從而確保不存在痕跡殘留。

我們發(fā)現(xiàn)，manifest在其中起到了關(guān)鍵性作用。如果manifest存在問題，那么整套方案都無法正常起效。不過在創(chuàng)建完成之后，它會重新審查該源的真實(shí)性。在最新版本當(dāng)中，其適用范圍更是將Docker鏡像涵蓋于其中?？傮w而言，我們覺得這樣嚴(yán)格的制度還是物有所值的，而檢測監(jiān)控機(jī)制的效果將成為決定其未來發(fā)展的核心所在。

測試Rkt

我們使用OpenVZ/Virtuozzo章節(jié)中提到過的同一套聯(lián)想平臺建立起一臺CentOS 6測試主機(jī)，為了方便起見這次我們使用了最低主機(jī)環(huán)境而非CoreOS。我們制作了兩套鏡像，其一是來自TrunKeyLinux的WordPress鏡像——我們特意選擇了WordPress 4.2.2版本，另一套則是通用型Ubuntu 14.04服務(wù)器鏡像——其經(jīng)過一次更新，專門用于建立最小化服務(wù)。接下來，我們找到了幾套適用于這兩套平臺的庫鏡像。

我們可以通過基于命令行的rkt命令對資源(例如pod所需要的內(nèi)存分配機(jī)制)、帶寬等進(jìn)行分配。由于rkt不具備檢測機(jī)制，因此目前我們必須使用腳本——為此我們還專門復(fù)習(xí)了一下JSON語法。

此次接受測試的版本允許我們通過簡單的http用戶名/密碼下載來自Docker(或者類Docker)注冊庫中的鏡像。這也意味著整套庫都可以供我們使用，并通過安全覆寫方式修改優(yōu)先級鏈，從而擺脫審計/合規(guī)的相關(guān)要求——當(dāng)然，除非日志嚴(yán)格監(jiān)控我們的行為并執(zhí)行錯誤修正。

我們編寫出的這些腳本隨后被快速復(fù)制到我們的聯(lián)想主機(jī)服務(wù)器之上。我們開始運(yùn)行這些用于生成實(shí)例的腳本，利用嵌入其中的偽指令啟動系統(tǒng)，并在創(chuàng)建實(shí)例的同時為這臺聯(lián)想設(shè)備設(shè)定了用于應(yīng)對暫時性卡頓的解決方案——接下來要做的就是專注觀察其反應(yīng)了。

但我們忘記設(shè)定CPU資源分配策略了，因此在啟動全部實(shí)例的同時，巨大的啟動資源需求量直擊主機(jī)計算核心。沒有任何一臺服務(wù)器能夠在這樣的沖擊之下幸存。但幸運(yùn)的是，我們通過重啟修正了腳本當(dāng)中的錯誤。

在實(shí)踐過程中，我們從Docker那邊獲得了兩套鏡像，并經(jīng)過一系列調(diào)整使其能夠在rkt運(yùn)行時中執(zhí)行。我們還以腳本方式設(shè)定了多套容器的啟動流程，并得以執(zhí)行了一次向外擴(kuò)展執(zhí)行實(shí)驗——但這同樣耗費(fèi)了我們大量精力。而且值得強(qiáng)調(diào)的是，第三方工具確實(shí)能夠為rkt提供幫助。

批評意見

這三款應(yīng)用都以root方式運(yùn)行，因為它們需要直接從內(nèi)核獲取處理速度。三套方案的說明文檔中只是稍微提到了AppArmor與SELinux，但三者都能夠利用這些沙箱機(jī)制將容器隔離起來，從而避免其破壞或者大量占用系統(tǒng)資源。

用于承載容器系統(tǒng)的集群/主機(jī)硬件平臺無法避免某套受到感染的容器利用其安全權(quán)限接入其它存在于同一平臺上的容器，同樣的情況也會發(fā)生在立足于同一安裝基礎(chǔ)的不同容器之間。因此，容器的安全保障只作用于其內(nèi)部工作流程當(dāng)中。

從集群/主機(jī)的層面出發(fā)，由守護(hù)程序負(fù)責(zé)控制容器進(jìn)程，而其它負(fù)責(zé)控制這些守護(hù)程序的進(jìn)程必須得到嚴(yán)格保護(hù)——這種作法在大部分企業(yè)當(dāng)中已經(jīng)成為安全工作的核心要點(diǎn)。接下來則要提到密鑰控制，在這方面Virtuozzo的表現(xiàn)非常不錯，但仍然不夠全面。我們需要的是一套能夠妥善管理SSH密鑰，同時對各容器運(yùn)行進(jìn)程所需要的通信層加以控制的整體架構(gòu)。Virtuozzo無疑帶來了良好的開端。當(dāng)然，對這三套方案來講，還需要配合其它內(nèi)部軟件定義網(wǎng)絡(luò)機(jī)制才能真正步入成熟。

不過在目前的主流虛擬機(jī)管理程序當(dāng)中，還沒有密度與效率兼?zhèn)涞南壤霈F(xiàn)，特別是同時對存儲文件及執(zhí)行文件進(jìn)行重復(fù)數(shù)據(jù)刪除處理。從這個角度看，容器屬于裸機(jī)實(shí)例與虛擬化技術(shù)相結(jié)合的混合產(chǎn)物。基于虛擬機(jī)管理程序的虛擬機(jī)系統(tǒng)彼此相互隔離，通常屬于離散實(shí)例，但容器則無需受到此類限制。虛擬機(jī)管理程序能夠從底層角度出發(fā)，保護(hù)實(shí)例免受資源劫持的困擾。而虛擬機(jī)對于沙箱技術(shù)的應(yīng)用在理論上遠(yuǎn)高于容器——當(dāng)然，安全失誤同樣有可能輕易摧毀這兩類實(shí)例苦心構(gòu)建而成的防御體系。

總結(jié)

容器技術(shù)確實(shí)非常便捷，而且允許操作系統(tǒng)實(shí)例與可執(zhí)行文件以簡單的方式進(jìn)行交換，并實(shí)現(xiàn)資源共享(在操作系統(tǒng)層級)。容器在根源上講，包括補(bǔ)丁/修復(fù)級別，并非完全不透明，但除非采用嚴(yán)格的方法來進(jìn)行審計及日志記錄，否則其很容易為惡意人士所利用。

不過我們必須承認(rèn)，容器技術(shù)讓實(shí)例的快速向外擴(kuò)展/向上擴(kuò)展成為可能，而這也將成為其沖擊市場的主要賣點(diǎn)。在我們看來，OpenVZ是目前容器領(lǐng)域最為成熟的解決方案，而且其采用的完全虛擬化或者容器化混合模式也足以在目標(biāo)市場上——即互聯(lián)網(wǎng)服務(wù)供應(yīng)商及托管服務(wù)供應(yīng)商——受到追捧。

Docker則是一套值得認(rèn)真考量的方案，其發(fā)展背后擁有極為強(qiáng)大的推動力量。從GitHub參與者數(shù)量的角度看，Docker開發(fā)工作中擁有著大量活躍技術(shù)支持者群體。但我們同時注意到，大量參與者的涌入讓Docker注冊庫中的源鏡像出現(xiàn)了一些問題，這甚至體現(xiàn)在了我們所選擇的測試樣本當(dāng)中。這種狀況讓我們非常緊張，因為容器本身非常難于探測，其組合與獨(dú)立組件很難直接查看、權(quán)威來源也很難得到審計——即使對大型企業(yè)來說也是如此。

這反過來讓我們更加專注于appc規(guī)范的發(fā)展以及rkt項目的前進(jìn)走勢。毫無疑問，rkt的嚴(yán)格監(jiān)管與appc合規(guī)機(jī)制的出現(xiàn)值得我們?yōu)橹恼?，不過rkt本身并沒有作好從實(shí)驗階段走向?qū)嵺`部署的萬全準(zhǔn)備。

容器技術(shù)是什么?其與虛擬機(jī)有何區(qū)別?

容器化應(yīng)用能夠擺脫虛擬機(jī)管理程序的束縛。容器當(dāng)中的實(shí)例執(zhí)行方式與傳統(tǒng)虛擬機(jī)管理程序的執(zhí)行方式有所差別，其中每一套容器都能夠共享通用文件，而非各自擁有獨(dú)立的離散操作系統(tǒng)/應(yīng)用組合。

從概念上講，容器中的實(shí)例構(gòu)成元素包括操作系統(tǒng)、應(yīng)用程序代碼、通信連接以及臨時及永久性數(shù)據(jù)存儲。

與半虛擬化虛擬機(jī)實(shí)例類似，容器利用接口通過容器管理器的管理設(shè)置將通信及存儲需求(必要時)同外部環(huán)境相連。

容器環(huán)境被介入式安全墻同主機(jī)的計算核心及root進(jìn)程隔離開來，且通常與其它容器共同運(yùn)作在同一臺主機(jī)之上。

容器可以包含獨(dú)立的指定主機(jī)操作系統(tǒng)，同時也能夠以可互換機(jī)制構(gòu)建，這就讓采用Ubuntu、Red Hat Atomic、CoreOS以及SUSE乃至其它操作系統(tǒng)建立容器混合體變成可能。除非有意連接，否則容器主機(jī)對于容器內(nèi)的運(yùn)行狀況一無所知。

反過來，這就使得設(shè)備與進(jìn)程分別存在于彼此隔離的世界，并能夠以對象的方式在主機(jī)之間往來遷移。此類主機(jī)通常采用Linux操作系統(tǒng)，但Docker也能運(yùn)行在蘋果、BSD等環(huán)境當(dāng)中。微軟公司最近演示了利用微軟.Net將Docker鏡像由Windows服務(wù)器平臺遷移至Linux主機(jī)的過程——前提是各主機(jī)所使用的CPU為同一類別(是的，我們還不能將在ARM上開發(fā)出的容器運(yùn)行在英特爾/AMD平臺當(dāng)中)。主機(jī)平臺的這種互換能力正是系統(tǒng)設(shè)計師們所追求的目標(biāo)，他們希望把容器像樂高積木那樣隨意調(diào)遣。

我們的主要批評意見是：目前容器系統(tǒng)能夠接受未知來源或者不具備權(quán)威創(chuàng)建者信息的容器鏡像。作為大量共享源應(yīng)用的平臺方案，一款應(yīng)用遭受滲透或者突破有可能讓容器之上的所有實(shí)例出現(xiàn)問題。

這是因為除非由注冊庫發(fā)布的某套容器鏡像能夠從零開始依次組裝，或者擁有權(quán)威可信的來源，否則我們必須首先將其視為可疑對象。而對基于容器的通用文件進(jìn)行更新管理也需要配合更為嚴(yán)格的控制手段。

而在另一方面，我們的一次操作即可恢復(fù)、升級或者重新配置一組容器的功能甚至特性——這種能力同樣有利有弊。

原文標(biāo)題：Docker vs. Rocket vs. Odin: Containers compared