對(duì)于CoreOS Fest大會(huì)上，紅帽、VMware等公司都宣布支持AppC，很多人還都覺(jué)得CoreOS的春天來(lái)了，更有甚者說(shuō)，競(jìng)爭(zhēng)是好事，避免一家獨(dú)大。不過(guò)紅帽的riekrh同學(xué)可不這么認(rèn)為。他認(rèn)為AppC的成員里都沒(méi)有目前發(fā)展***的Docker，這很明顯就是商業(yè)之間的競(jìng)爭(zhēng)。從行業(yè)的發(fā)展角度來(lái)看，AppC的出現(xiàn)很可能會(huì)讓行業(yè)里出現(xiàn)多種容器打包格式，這很有可能會(huì)阻礙容器技術(shù)的發(fā)展。

[[133583]]

本周洛杉磯舉行的CoreOS Fest大會(huì)上，主題演講之后的***個(gè)討論會(huì)里，CoreOS不出意外地傾情推出應(yīng)用容器規(guī)范(Application Container Spec，AppC)及其***版實(shí)現(xiàn)，rkt，并展望了該規(guī)范未來(lái)被廣泛采用的光明前景。

Red Hat在做技術(shù)決策時(shí)，都會(huì)本著選出上游社區(qū)所支持的***技術(shù)方案的原則，持續(xù)評(píng)估所有可能的技術(shù)選擇。這也是為什么Red Hat決定投入AppC并且積極為該規(guī)范做出貢獻(xiàn)的原因。

Red Hat參與了很多上游社區(qū)。但是這樣的參與并不代表將全力支持，或者只是覺(jué)得AppC或rkt可能能用于企業(yè)級(jí)IT，也或者永遠(yuǎn)也無(wú)法用于企業(yè)級(jí)?；诖耍旅媸墙裉煳覅⒓油暧懻摃?huì)后的一些心得：

rkt有很多招人喜歡的優(yōu)點(diǎn)，比如圍繞systemd的干凈的執(zhí)行模型，開(kāi)放的開(kāi)發(fā)和監(jiān)管模型，或者規(guī)范本身。

我們一起來(lái)看看規(guī)范吧。

AppC(應(yīng)用容器規(guī)范)絕對(duì)是朝著正確的方向邁出了一大步，它有效的解決了Docker v1在技術(shù)和部署模型上的缺陷。應(yīng)用容器規(guī)范花了很多篇幅講述容器規(guī)范可以做些什么，我覺(jué)得企業(yè)容器領(lǐng)域很需要這樣的規(guī)范。同時(shí)我也覺(jué)得CoreOS有著構(gòu)建規(guī)范及其周邊社區(qū)的***動(dòng)力。

除了。。。

時(shí)至今日，AppC還是只涵蓋了基于容器、應(yīng)用中心模型的很小一部分內(nèi)容。容器將會(huì)重新定義操作系統(tǒng)，也許很多人都低估了這一點(diǎn)。這是個(gè)告別傳統(tǒng)的單實(shí)例，宏內(nèi)核，UNIX用戶空間，進(jìn)入到使用容器和增量打包技術(shù)實(shí)現(xiàn)的多實(shí)例，多版本環(huán)境新紀(jì)元的轉(zhuǎn)折點(diǎn)。我們現(xiàn)在討論的事情是要去改變軟件行業(yè)已經(jīng)使用了20年甚至40年的核心范式。

還有很多正在演化的領(lǐng)域，比如安全(security)、syscall、信號(hào)(signals)等等。AppC規(guī)范需要涵蓋比現(xiàn)在更多的領(lǐng)域，它需要更加深入地定義兼容性，對(duì)底層系統(tǒng)的依賴性，操作系統(tǒng)，聯(lián)合存儲(chǔ)庫(kù)命名空間和服務(wù)發(fā)現(xiàn)等領(lǐng)域。

另外一個(gè)很重要的方面可能被規(guī)范名字的關(guān)鍵字“應(yīng)用”弱化了，目前，AppC只包含了單個(gè)容器和單個(gè)pod，這也是Docker為什么要做集群，因?yàn)橹挥泻苌俚膽?yīng)用能在單個(gè)容器/單個(gè)pod里就可以運(yùn)行。今天的討論會(huì)里也提到了這個(gè)問(wèn)題。同樣，AppC在應(yīng)用的可移植方面考慮也欠妥。Nulecule(發(fā)音類似：newly-cool)規(guī)范的初稿里嘗試解決這個(gè)問(wèn)題，將可移植性的概念拓展到整個(gè)應(yīng)用，或者未來(lái)可以聚合的組件所提供的服務(wù)，并且允許描述多容器應(yīng)用及其所有依賴組件。

因此組委會(huì)需要在AppC中解決這些問(wèn)題，目前我們只是剛剛開(kāi)始漫漫旅程，Red Hat會(huì)通過(guò)社區(qū)對(duì)此持續(xù)跟進(jìn)。

要注意，AppC目前還不成熟，但與之相比更讓人憂慮之處是rkt在推出Docker模型兼容接口的同時(shí)，還推出了自己的容器打包格式。我一直認(rèn)為Docker提出了非常棒的想法將增量打包，鏡像分層和容器組合在一起。這個(gè)工具改變了業(yè)界軟件交付的方式。而由于項(xiàng)目之間競(jìng)爭(zhēng)而產(chǎn)生的多種不同的打包格式可能會(huì)給這個(gè)領(lǐng)域帶來(lái)風(fēng)險(xiǎn)，并放緩技術(shù)發(fā)展的節(jié)奏。這將意味著生態(tài)系統(tǒng)的碎片化，給實(shí)際提供容器內(nèi)容的公司帶來(lái)痛苦，這些公司包括Red Hat，我們的ISV合作伙伴以及想要嘗試引入容器化的用戶們。

在更為底層的組件級(jí)別，我們不得不使用dpkg，rpm和一些其他的東西，長(zhǎng)期忍受這樣的碎片化。回過(guò)頭看看apt/dpkg和yum/rpm的 PK， 不難發(fā)現(xiàn)兩種組件之間的競(jìng)爭(zhēng)并不會(huì)給用戶帶來(lái)巨大的好處，相反會(huì)有副作用。因?yàn)檫@意味著用戶需要用多種格式提供相同的內(nèi)容，要么enable整個(gè)工具鏈，在系統(tǒng)架構(gòu)里同時(shí)管理這兩種高度冗余的格式，要么更為糟糕地強(qiáng)制用戶在這兩種生態(tài)系統(tǒng)中選擇其中一種。容器層高級(jí)別的聚合只是輕微地改善了這個(gè)問(wèn)題，但是又增加了高層的復(fù)雜性，和與現(xiàn)代分布式系統(tǒng)的深度集成。

AppC不支持Docker，主導(dǎo)討論并且控制格式的公司會(huì)很快主宰容器打包標(biāo)準(zhǔn)。甚至沒(méi)給Docker公司發(fā)表自己觀點(diǎn)的機(jī)會(huì)。這并不是過(guò)分指責(zé)Docker或者CoreOS，每個(gè)公司都有做自己想做的事情的權(quán)利。實(shí)際上，我們現(xiàn)在有兩個(gè)直接競(jìng)爭(zhēng)的公司來(lái)推動(dòng)容器標(biāo)準(zhǔn)化，他們使用競(jìng)爭(zhēng)的工具鏈，競(jìng)爭(zhēng)的規(guī)范和互不兼容的打包格式。這看上去就像Groundhog Day的火車相撞的慢鏡頭。我們，在廣義的Linux和開(kāi)源社區(qū)里，過(guò)去十五年已經(jīng)發(fā)生過(guò)很多次類似的事情了，尤其在打包格式領(lǐng)域。

雖然需要更多的時(shí)間和空間來(lái)驗(yàn)證，但是兩個(gè)創(chuàng)業(yè)公司各自推出不兼容的規(guī)范，試圖差異化同時(shí)又直接競(jìng)爭(zhēng)，這不是什么好事情。如果CoreOS和 Docker能夠通力合作推出標(biāo)準(zhǔn)化的通用規(guī)范，鏡像格式和分布式協(xié)議，那么會(huì)更有益于社區(qū)和所有需要使用這些技術(shù)的人們。目前，Red Hat會(huì)繼續(xù)參與并推進(jìn)這兩種方式，期望以后能夠合并統(tǒng)一。

原文鏈接：http://dockone.io/article/360