CoreOS發(fā)起的AppC一定是好事？聽紅帽怎么說
對于CoreOS Fest大會上，紅帽、VMware等公司都宣布支持AppC，很多人還都覺得CoreOS的春天來了，更有甚者說，競爭是好事，避免一家獨大。不過紅帽的riekrh同學可不這么認為。他認為AppC的成員里都沒有目前發(fā)展***的Docker，這很明顯就是商業(yè)之間的競爭。從行業(yè)的發(fā)展角度來看，AppC的出現(xiàn)很可能會讓行業(yè)里出現(xiàn)多種容器打包格式，這很有可能會阻礙容器技術的發(fā)展。
本周洛杉磯舉行的CoreOS Fest大會上，主題演講之后的***個討論會里，CoreOS不出意外地傾情推出應用容器規(guī)范(Application Container Spec，AppC)及其***版實現(xiàn)，rkt，并展望了該規(guī)范未來被廣泛采用的光明前景。
Red Hat在做技術決策時，都會本著選出上游社區(qū)所支持的***技術方案的原則，持續(xù)評估所有可能的技術選擇。這也是為什么Red Hat決定投入AppC并且積極為該規(guī)范做出貢獻的原因。
Red Hat參與了很多上游社區(qū)。但是這樣的參與并不代表將全力支持，或者只是覺得AppC或rkt可能能用于企業(yè)級IT，也或者永遠也無法用于企業(yè)級?；诖?，下面是今天我參加完討論會后的一些心得：
rkt有很多招人喜歡的優(yōu)點，比如圍繞systemd的干凈的執(zhí)行模型，開放的開發(fā)和監(jiān)管模型，或者規(guī)范本身。
我們一起來看看規(guī)范吧。
AppC(應用容器規(guī)范)絕對是朝著正確的方向邁出了一大步，它有效的解決了Docker v1在技術和部署模型上的缺陷。應用容器規(guī)范花了很多篇幅講述容器規(guī)范可以做些什么，我覺得企業(yè)容器領域很需要這樣的規(guī)范。同時我也覺得CoreOS有著構建規(guī)范及其周邊社區(qū)的***動力。
除了。。。
時至今日，AppC還是只涵蓋了基于容器、應用中心模型的很小一部分內(nèi)容。容器將會重新定義操作系統(tǒng)，也許很多人都低估了這一點。這是個告別傳統(tǒng)的單實例，宏內(nèi)核，UNIX用戶空間，進入到使用容器和增量打包技術實現(xiàn)的多實例，多版本環(huán)境新紀元的轉折點。我們現(xiàn)在討論的事情是要去改變軟件行業(yè)已經(jīng)使用了20年甚至40年的核心范式。
還有很多正在演化的領域，比如安全(security)、syscall、信號(signals)等等。AppC規(guī)范需要涵蓋比現(xiàn)在更多的領域，它需要更加深入地定義兼容性，對底層系統(tǒng)的依賴性，操作系統(tǒng)，聯(lián)合存儲庫命名空間和服務發(fā)現(xiàn)等領域。
另外一個很重要的方面可能被規(guī)范名字的關鍵字“應用”弱化了，目前，AppC只包含了單個容器和單個pod，這也是Docker為什么要做集群，因為只有很少的應用能在單個容器/單個pod里就可以運行。今天的討論會里也提到了這個問題。同樣，AppC在應用的可移植方面考慮也欠妥。Nulecule(發(fā)音類似：newly-cool)規(guī)范的初稿里嘗試解決這個問題，將可移植性的概念拓展到整個應用，或者未來可以聚合的組件所提供的服務，并且允許描述多容器應用及其所有依賴組件。
因此組委會需要在AppC中解決這些問題，目前我們只是剛剛開始漫漫旅程，Red Hat會通過社區(qū)對此持續(xù)跟進。
要注意，AppC目前還不成熟，但與之相比更讓人憂慮之處是rkt在推出Docker模型兼容接口的同時，還推出了自己的容器打包格式。我一直認為Docker提出了非常棒的想法將增量打包，鏡像分層和容器組合在一起。這個工具改變了業(yè)界軟件交付的方式。而由于項目之間競爭而產(chǎn)生的多種不同的打包格式可能會給這個領域帶來風險，并放緩技術發(fā)展的節(jié)奏。這將意味著生態(tài)系統(tǒng)的碎片化，給實際提供容器內(nèi)容的公司帶來痛苦，這些公司包括Red Hat，我們的ISV合作伙伴以及想要嘗試引入容器化的用戶們。
在更為底層的組件級別，我們不得不使用dpkg，rpm和一些其他的東西，長期忍受這樣的碎片化?；剡^頭看看apt/dpkg和yum/rpm的 PK， 不難發(fā)現(xiàn)兩種組件之間的競爭并不會給用戶帶來巨大的好處，相反會有副作用。因為這意味著用戶需要用多種格式提供相同的內(nèi)容，要么enable整個工具鏈，在系統(tǒng)架構里同時管理這兩種高度冗余的格式，要么更為糟糕地強制用戶在這兩種生態(tài)系統(tǒng)中選擇其中一種。容器層高級別的聚合只是輕微地改善了這個問題，但是又增加了高層的復雜性，和與現(xiàn)代分布式系統(tǒng)的深度集成。
AppC不支持Docker，主導討論并且控制格式的公司會很快主宰容器打包標準。甚至沒給Docker公司發(fā)表自己觀點的機會。這并不是過分指責Docker或者CoreOS，每個公司都有做自己想做的事情的權利。實際上，我們現(xiàn)在有兩個直接競爭的公司來推動容器標準化，他們使用競爭的工具鏈，競爭的規(guī)范和互不兼容的打包格式。這看上去就像Groundhog Day的火車相撞的慢鏡頭。我們，在廣義的Linux和開源社區(qū)里，過去十五年已經(jīng)發(fā)生過很多次類似的事情了，尤其在打包格式領域。
雖然需要更多的時間和空間來驗證，但是兩個創(chuàng)業(yè)公司各自推出不兼容的規(guī)范，試圖差異化同時又直接競爭，這不是什么好事情。如果CoreOS和 Docker能夠通力合作推出標準化的通用規(guī)范，鏡像格式和分布式協(xié)議，那么會更有益于社區(qū)和所有需要使用這些技術的人們。目前，Red Hat會繼續(xù)參與并推進這兩種方式，期望以后能夠合并統(tǒng)一。
