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

[[144601]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#p#

OpenVZ/Odin Virtuozzo 6.0

OpenVZ是一款Linux發(fā)行版，主要負(fù)責(zé)對(duì)虛擬機(jī)以及/或者容器訪客實(shí)例進(jìn)行托管。OpenVZ資源以現(xiàn)代3.X+版本Linux內(nèi)核為基礎(chǔ)，同時(shí)利用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ī)制、計(jì)費(fèi)以及管理面板時(shí)，則需要用到另一款商用產(chǎn)品——Odin Virtuozzo。順帶一提，Odin是Parallels這家瑞士企業(yè)進(jìn)行品牌調(diào)整之后的產(chǎn)物。

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

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

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

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

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

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

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

測(cè)試OpenVZ與Virtuozzo

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

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

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

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

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

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

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

Odin Virtuozzo 6 SP1

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

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

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

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

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

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

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

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

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

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

使用感受

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

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

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

#p#

Docker 1.6

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

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

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

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

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

Docker容器鏡像使用union文件系統(tǒng)，或者簡(jiǎn)稱unionfs，其會(huì)為容器制作出文件夾基礎(chǔ)體系。與OpenVZ/VIrtuozzo類似，Docker會(huì)通過(guò)unionfs為每套利用Docker運(yùn)行的容器提供分層結(jié)構(gòu)。這就使得類似的鏡像之間能夠通過(guò)一次更新就共享到同樣的基礎(chǔ)文件，而且會(huì)在需要保存鏡像快照或者更新鏡像時(shí)節(jié)約存儲(chǔ)空間。舉例來(lái)說(shuō)，我們可以一次性更新openssh并將效果推廣到20套容器當(dāng)中，因?yàn)樗鼈円蕾囉谕惶滓淹瓿筛碌溺R像。

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

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

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

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

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

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

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

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

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

#p#

Rocket/rkt 0.5.4

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

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，這是因?yàn)樗嘧鳛橐豢罴翰僮飨到y(tǒng)存在、而非控制層。CoreOS是rkt項(xiàng)目的贊助商之一，但該項(xiàng)目目前還沒(méi)有作好進(jìn)入生產(chǎn)環(huán)境的準(zhǔn)備。從原則角度講，我們一般不會(huì)在審查當(dāng)中對(duì)這類產(chǎn)品提出太高的要求，因?yàn)榧夹g(shù)業(yè)界普遍認(rèn)為beta測(cè)試版本并不適用于實(shí)際生產(chǎn)。

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

Rocket在容器實(shí)例構(gòu)建管理機(jī)制當(dāng)中納入了嚴(yán)格的監(jiān)控手段，這意味著鏡像在由rkt加以啟動(dòng)之前，必須以特定方式進(jìn)行構(gòu)建。這一點(diǎn)與OpenVZ以及Docker的管理方式有所不同，因?yàn)槎咚褂玫娜萜骺刂破鞫寄軌蛑苯邮褂矛F(xiàn)成的ISO鏡像——包括來(lái)自當(dāng)前正在運(yùn)行的系統(tǒng)、容器控制器庫(kù)/注冊(cè)庫(kù)或者隔壁好友的鏡像。但這些在Rocket當(dāng)中都無(wú)法實(shí)現(xiàn)。

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

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

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

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

• 設(shè)計(jì)出下載及啟動(dòng)速度更快的App Container
• 確保鏡像擁有加密驗(yàn)證以及理想的可緩存能力
•  通過(guò)設(shè)計(jì)確保實(shí)現(xiàn)手段的可組合性與獨(dú)立性
• 使用常見(jiàn)技術(shù)進(jìn)行加密、歸檔、壓縮以及傳輸
• 利用DNS命名空間對(duì)鏡像進(jìn)行命名與發(fā)現(xiàn)

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

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

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

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

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

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

測(cè)試Rkt

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

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

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

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

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

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

批評(píng)意見(jiàn)

這三款應(yīng)用都以root方式運(yùn)行，因?yàn)樗鼈冃枰苯訌膬?nèi)核獲取處理速度。三套方案的說(shuō)明文檔中只是稍微提到了AppArmor與SELinux，但三者都能夠利用這些沙箱機(jī)制將容器隔離起來(lái)，從而避免其破壞或者大量占用系統(tǒng)資源。

用于承載容器系統(tǒng)的集群/主機(jī)硬件平臺(tái)無(wú)法避免某套受到感染的容器利用其安全權(quán)限接入其它存在于同一平臺(tái)上的容器，同樣的情況也會(huì)發(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)。接下來(lái)則要提到密鑰控制，在這方面Virtuozzo的表現(xiàn)非常不錯(cuò)，但仍然不夠全面。我們需要的是一套能夠妥善管理SSH密鑰，同時(shí)對(duì)各容器運(yùn)行進(jìn)程所需要的通信層加以控制的整體架構(gòu)。Virtuozzo無(wú)疑帶來(lái)了良好的開(kāi)端。當(dāng)然，對(duì)這三套方案來(lái)講，還需要配合其它內(nèi)部軟件定義網(wǎng)絡(luò)機(jī)制才能真正步入成熟。

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

#p#

總結(jié)

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

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

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

這反過(guò)來(lái)讓我們更加專注于appc規(guī)范的發(fā)展以及rkt項(xiàng)目的前進(jìn)走勢(shì)。毫無(wú)疑問(wèn)，rkt的嚴(yán)格監(jiān)管與appc合規(guī)機(jī)制的出現(xiàn)值得我們?yōu)橹恼疲贿^(guò)rkt本身并沒(méi)有作好從實(shí)驗(yàn)階段走向?qū)嵺`部署的萬(wàn)全準(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í)及永久性數(shù)據(jù)存儲(chǔ)。

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

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

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

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

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

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

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

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