阿里自研容器技術Pouch前景如何？

01-05

阿里搜索業務容器化中的一些經驗和思考-博客-雲棲社區-阿里雲
從去年阿里雙十一的技術分享來看，阿里不是一直都是docker嗎？突然冒出一個"嬰兒車"來，這個輪子滾的遠嗎？

感謝題主對這個問題感興趣。今年雲棲大會上《阿里巴巴容器技術現狀與未來路線》的演講，也正是我做的。目前Pouch的代碼已經開源：alibaba/pouch

首先介紹一下我自己，我個人是Docker的深度開發者，也對Docker貢獻過很多代碼，同時是Docker社區的maintainer，目前在阿里巴巴系統軟體部做阿里容器技術Pouch的相關開源工作。

首先我先來回答「阿里不是一直都是Docker嗎」這個問題。

阿里並不是一直都是Docker。阿里早在11年的時候，基於LXC研發了容器技術t4，並在當時以產品形態給集團提供服務。國內其他的公司，據我所知，如百度、網易、騰訊也是如此。只不過，在使用標準上遠沒有達到工業化標準的程度，因此在行業中傳播得比較有限。Docker對行業產生深遠影響的是Docker鏡像，這一點對於大型的互聯網公司而言，相信肯定深有感觸。因此，Docker鏡像流行開來之後，阿里巴巴沒有理由不去接受這種給行業帶來大價值的技術。這也就回到了「阿里容器技術融合Docker鏡像」的這一事實上。

另外，我再來說一下，開源版本的Docker與大型互聯網公司之間的關係。

阿里巴巴不是一家軟體公司，而且一家業務驅動的公司。因此在業務的變化之下，需要技術能夠很快速靈活的應對。社區版本的Docker，的確是一個業界數一數二的軟體，但是在面對一些場景時，難免存在開源軟體的弊端。比如，開源軟體有明確有計劃的發布周期，這樣的周期在面對快速變化的業務時，幾乎是沒有任何辦法的。本著業務第一的角度，始終要在「follow開源軟體」和「自研軟體自主可控」方面做出一個選擇。

很顯然，絕大多數大型互聯網公司，都會選擇後者，或者是fork開源版本之後，很大程度上很難繼續follow社區版，自行維護一個版本。而阿里巴巴在容器技術方面的選擇是：兼容Docker鏡像標準，兼容Docker的API, 引擎層面完全自主可控自研。由於API層面的兼容，集團系統軟體對外界用戶暴露的介面與Docker無差別，因此很早的時候，集團也會以Docker、AliDocker來稱呼。關於自主可控自研方面，阿里容器技術就誕生了很多與社區容器技術有差異化的地方，比如：富容器，比如更好的隔離（用戶態、內核態的都有），比如內核兼容性，比如P2P鏡像分發等。後來發展的話，相信大家也就清楚了。現在Pouch的話，走開源之路與行業交流共進。

後續會有補充，不到之處，還望各位提出斧正。

Pouch項目開源路線圖

如果題主是圈裡的，可以在Pouch今年雙11開源之後可以閱讀源碼。

不過題主似乎不是。事實上去年阿里雙11分享的是AliDocker，並非社區版Docker，二者是有區別的。

對Docker和T4都做了一些修改整合後，將兩者融合為了一個產品，相當於既讓T4具備了Docker的鏡像能力，又讓Docker具備了T4對內部運維體系的友好性，並且能夠運行在內部早期的AliOS5u和2.6內核上。這個產品在內部稱為AliDocker，在去年8月份推出了第一個雛形版本。

詳情可以看《集團AliDocker化雙11總結》

今年雲棲大會公布，Pouch的特點如下：

首先Pouch是一種富容器技術，內部應用體驗類似虛擬機，擁有init進程，富含多種系統服務；
其次通過內核加固與輕量級虛擬機支持，Pouch提供豐富的安全隔離保障和隔離維度；
在鏡像分發上，特別是超大規模場景下可通過P2P的方式緩解網路負載；
在內核兼容性方面，更加符合企業現狀，考慮到大部分企業IT系統內核的升級緩慢、版本較低，最大限度適配現有底層基礎設施。

這和之前的AliDocker介紹是吻合的，所以Pouch就是AliDocker改名開源的軟體，畢竟開源了還叫Ali不合適。

開源Pouch是否有前景，從技術、社區、生態等方面來看：

源碼未知，無從解析，但經過阿里集團業務驗證是事實。
富容器在現階段是有需求的，比Docker更適合某些業務，但這似乎與Unix設計哲學不符，可能是一種過渡的技術，Docker的缺陷，Docker社區也會不斷解決。
阿里有大量官方參與或主導開源項目的經驗，並且挖了容器社區大牛孫宏亮來推動這個事情，潛力十足。
Pouch似乎已經得到Kubernetes的支持（浙大在國內Kubernetes社區貢獻代碼量是比較多的），這是一個好消息。

作為Pouch項目的第一個合作夥伴，浙江大學將與阿里巴巴在Pouch項目的Kubernetes支持和增強容器運行時等領域展開密切合作。

來反駁下 b開頭的某用戶的回答，簡直就是一派胡言。

集團大規模推廣t4容器技術時（現在應該還能搜到畢大師13年的宣講ppt），螞蟻當時還在用xen虛擬化技術，哪裡來的第一個容器化。

後續集團這邊開始fork docker替換t4的時候（最早的動力是為了讓docker能在rhel5上也能跑起來），當時螞蟻的容器化速度也是非常緩慢的，後面隨著部署範圍越來越光，alidocker改的東西越來越多，且有了開源打算，才有了pouch。

一些人就喜歡假裝寫一些道聽途說的小道消息來博取眼球，呵呵。

謝邀。

T4容器的代碼我以前確實了解的比較多，現在叫Pouch了也是想單獨運作。

=== 補充更新 ===

看了下放出來的代碼，不得不說這東西跟當年我們做T4那種簡潔高效的路線差別還是挺大的。路線圖把市面上容器相關的技術都給畫進去了。。。看來誰也不想得罪？這種思路其實是有很大問題的。

=============

必須澄清的是阿里公司裡面搞容器的團隊4、5個，但是技術保障部（現在都叫系統軟體事業部了，呵呵）這邊勢力最大，實力也最強，啟動最早，這個沒啥好爭的。反對 @belupreda 的說法。如果你聽不懂我在說什麼，那你就記住Pouch不是Docker！不是Docker！不是Docker！它是T4容器+Docker鏡像！

而且相比一味捧Docker公司臭腳的阿里雲，搞T4的同學們技術視野顯然更靠譜一些。

但這終究是個挑戰Docker的事情，難度非常大，rkt失敗的例子在先。Pouch相比rkt並沒有特殊的技術先進性。胖容器並不是太值得炫耀的功能，說白了就是為了兼容遺留應用的無奈之舉。虛擬化級別的隔離是Intel和Hyper他們的技術，也是人家玩了快兩年的東西了。

而且相比CoreOS，團隊參與和運作國際化開源社區的能力非常弱。新來的幾位「容器專家」么……不說也罷。

長遠來看，跟Kubernetes集成應該是帶動Pouch最好的方法。然而阿里集團內部根本沒法推進Kubernetes。可以說前期阿里雲那些人的戰略失誤應該負主要責任，一幫不懂技術的PM帶頭選擇了swarm這個現在半死不活的項目。導致集團內部搞容器的團隊都得往swarm上靠，現在都傻眼了。

所以，打開國際社區應該沒啥可能。國內小範圍用戶試用，能有些小場景落地吧，比如國內那些也喜歡『自研』的公司。

我說點對於轟轟烈烈的「容器運動」的看法，，

什麼公司和業務需要容器？

說實在的，過去我一直做的原生語言的服務開發，一直不明白多個網路服務同機混合部署有什麼大不了的困難的，幹嘛需要做硬性的隔離和資源分配，讓線程做下cpu親和之類的不就行了嘛。。後來聽了個講座，問了幾個問題，，（假裝）覺得我懂了:

用虛擬機語言來做服務的，GC 經常要把整個機器內存吃光才執行一下。。所以很容易造成A進程把B進程弄的很卡。。

服務治理做的差的，少數進程動不動跑滿cpu也沒做親和的，混合部署的時候很容易互相影響還沒有監控到。服務治理差到了，混合部署的服務經常發生扯皮之類的破事，事故找不到責任歸屬人，容器方便直白的看清楚是誰把機器弄死機的。

發布卸載調度系統做的差的，服務部署和移除運維嫌太費勁，還不如直接用「虛擬機」來「發布」。

服務對環境配置依賴過於深重，而且變更和部署過程都有很多手工操作，新機器配置起來太麻煩，還不如直接用「虛擬機」來「鏡像拷貝」。

打算把機器進行分時使用。比如騰訊的傳媒類業務，早上上班路上大家看騰訊新聞，晚上大家下班回去看騰訊視頻，兩個業務的請求量高峰是錯峰的，完全可以找些機器白天給新聞用晚上給視頻用。業務跨度太大部署環境要求可能區別也很大，到下午臨時的卸載一大堆新聞服務然後再啟動一大堆視頻的服務，風險太大，中途有任何環節出錯都可能讓這個機臨時不可用了，人工處理問題也降低了自動化程度，不如用容器來做「凈室部署」。

線上反攻擊，有時候需要考慮在線上準備「蜜罐」來診斷一些流量，但是又希望不影響線上服務。容器有他特定的用途。

還有多個服務實例非得占同1個80埠？

個人的觀點是：這東西可以帶來某些方便，尤其方便了一些java服務的線上混合部署，但是絕非什麼萬金油，如果貴司業務把我上面說的前面幾點做的很好了，包括服務治理做的很好，發布部署自動化管理系統做的很好，業務監控也做的很好了，那麼根本沒啥必要去上容器。不過對於初創的公司，使用容器可以避開我前面說的那些要求，對混合部署的穩定性提升是有幫助的。

當然這真的是我個人的一點不成熟的觀點，因為我也沒真正的用上容器，不知道他到底有啥魔力讓這麼多人這麼狂熱。。有不同意見的還請多多指正，謝謝。

emmm....怎麼說呢，總覺得阿里開源的技術，看上去很可以，但總覺得另有意圖。

要麼是內部員工想拿獎金，要麼是想未來大家都依賴他的技術，想以後賺錢。

公司內部鼓勵一下員工，推出新技術，就發發獎金升升職什麼的。

開源以後再搞成閉源的很容易啊。

閉源以後，收收費，打打官司。

發現有個問題樓上的幾位阿里的大牛們都沒回答~~~為什麼大家要放棄docker來用你家pouch

一想到第一版是我身邊同學寫的代碼，不敢用是肯定的。。。。又一個libvirt

不了解pouch。從發布的新聞看，說是經歷了阿里集團內部的大規模考驗。

不過，從我目前知道，阿里內部其實有好幾波團隊搞容器。pouch具體是在哪個部門實證，並不清楚。不過，至少不是在螞蟻金服。

螞蟻金服在阿里內部是最早上了容器，單一集群5000台物理機，裸機跑容器，而不是虛擬機內跑容器。螞蟻金服所有業務，除了oceanDB沒有部署在容器，其他全部容器化。

螞蟻金服的容器是自己修訂了容器的bug。解決了許多網路與存儲的問題。

問過螞蟻金服的相關人員，pouch是什麼，回答是不知道。

所以，pouch這個，吹的成分不少。

====================================

有人覺得我是在黑，而且還是在造謠。我再把事實陳述下

1。Pouch 在宣傳中，說是大規模驗證了，但並沒說到底在哪個部門哪個項目下，單一集群規模多大。回復中，也沒有人說出具體數字。

2。螞蟻金服全線都沒有用Pouch部署，這點是確認的。至於為什麼不用Pouch,也不能說明pouch不好。大公司內部團隊之間也有競爭，很正常。但沒用就是沒用，我說的是事實。

另外，我覺得容器發現到目前，未來方嚮應該是這樣：

1。促進操作系統更輕量化

2。促進集群資源調度，簡便，安全

3。應用在單個容器無狀態，但在集群下可保持狀態