PouchContainer 是阿裏巴巴集團開源的高效、輕量級企業級富容器引擎技術，擁有隔離性強、可移植性高、資源占用少等特性。可以幫助企業快速實現存量業務容器化，同時提高超大規模下數據中心的物理資源利用率。

PouchContainer 源自阿裏巴巴內部場景，誕生初期，在如何為互聯網應用保駕護航方面，傾盡了阿裏巴巴工程師們的設計心血。PouchContainer 的強隔離、富容器等技術特性是最好的證明。在阿裏巴巴的體量規模下，PouchContainer 對業務的支撐得到雙 11 史無前例的檢驗，開源之後，阿裏容器成為一項普惠技術，定位於「助力企業快速實現存量業務容器化」。

初次接觸容器技術時，阿裏巴巴內部有著驚人規模的存量業務，如何通過技術快速容器化存量業務，是阿裏容器技術當年在內部鋪開時的重點難題。發展到今天，開源容器技術逐漸普及，面對落地，相信不少存在大量存量業務的企業，同樣為這些業務的如何容器化而犯愁。雲原生領域，CNCF 基金會推崇的眾多先進理念，絕大多數都建立在業務容器化的基礎之上。倘若企業業務在雲原生的入口容器化方面沒有踩準步點，後續的容器編排、Service Mesh 等行業開源技術紅利更是無從談起。

通過七年的實踐經驗，阿裏巴巴容器技術 PouchContainer 用事實向行業傳遞這樣的信息 —— 富容器是實現企業存量業務快速容器化的首選技術。

富容器是企業打包業務應用、實現業務容器化過程中，采用的一種容器模式。此模式可以幫助企業IT技術人員打包業務應用時，幾乎不費吹灰之力。通過富容器技術打包的業務應用可以達到以下兩個目的：

• 容器鏡像實現業務的快速交付

• 容器環境兼容企業原有運維體系

技術角度而言，富容器提供了有效路徑，幫助業務在單個容器鏡像中除了業務應用本身之外，還打包更多業務所需的運維套件、系統服務等；同時相比於較為簡單的單進程容器，富容器在進程組織結構層面，也有著巨大的變革：容器運行時內部自動運行 systemd 等管家進程。如此一來，富容器模式下的應用，有能力在不改變任何業務代碼、運維代碼的情況下，像在物理機上運行一模一樣。可以說，這是一種更為通用的「面向應用」的模式。

換言之，富容器在保障業務交付效率的同時，在開發和運維層面對應用沒有任何的侵入性，從而有能力幫助 IT 人員更多聚焦業務創新。

富容器的適用場景極廣。可以說企業幾乎所有的存量業務，都可以采納富容器作為容器化方案首選。容器技術流行之前，有接近二十年的時間，企業 IT 服務運行在裸金屬或者虛擬機中。企業業務的穩定運行，有非常大的功勞來源於運維工作，如果細分，包括「基礎設施運維」以及「業務運維」。所有的應用運行，都依賴於物理資源；所有的業務穩定，都仰仗於監控系統、日誌服務等運維體系。那麽，我們有理由相信，在業務容器化過程中，企業堅決不能對運維體系置之不理，否則後果可想而知。

因此，存量業務容器化過程中，需要考慮兼容企業原有運維體系的場景，都在 PouchContainer 富容器技術的使用範圍之內。

既然可以業務兼容原有運維體系，那麽富容器技術又是通過什麽樣的技術來實現的呢？下圖清晰的描述了富容器技術的內部情況。

富容器技術可以完全百分百兼容社區的 OCI 鏡像，容器啟動時將鏡像的文件系統作為容器的 rootfs。運行模式上，功能層面，除了內部運行進程，同時還包括容器啟停時的鉤子方法（prestart hook 和 poststop hook）。

如果從內部運行進程的角度來看待 PouchContainer 的富容器技術，我們可以把內部運行進程分為 4 類：

• pid=1 的 init 進程

• 容器鏡像的 CMD

• 容器內部的系統 service 進程

• 用戶自定義運維組件

pid=1 的 init 進程

富容器技術與傳統容器最明顯的差異點，即容器內部運行一個 init 進程，而傳統的容器（如 docker 容器等）將容器鏡像中指定的 CMD 作為容器內 pid=1 的進程。PouchContainer 的富容器模式可以運行從三種 init 進程中選擇：

• systemd

• sbin/init

• dumb-init

眾所周知，傳統容器作為一個獨立運行環境，內部進程的管理存在一定的弊端：比如無法回收僵屍進程，導致容器消耗太多進程數、消耗額外內存等；比如無法友好管理容器內部的系統服務進程，導致一些業務應用所需要的基本能力欠缺等，比如 cron 系統服務、syslogd 系統服務等；比如，無法支持一些系統應用的正常運行，主要原因是某些系統應用需要調用 systemd 來安裝 RPM 包……

富容器的 init 進程在運維模式上，毫無疑問可以解決以上問題，給應用帶來更好的體驗。init 進程在設計時就加入了可以 wait 消亡進程的能力，即可以輕松解決上圖中業務進程運行過程中誕生的 Zombie 僵屍進程；同時管理系統服務也是它的本職工作之一。如果一來，一些最為基本的傳統運維能力，init 進程即幫助用戶解決了大半，為運維體系做好了堅實的基礎。

容器鏡像的CMD

容器鏡像的 CMD，也就是傳統意義上我們希望在容器內部運行的業務。比如，用戶在容器化一個 Golang 的業務系統打包成鏡像時，肯定會在 Dockerfile 中將該業務系統的啟動命令指定為 CMD，從而保證未來通過該鏡像運行容器起，會執行這條 CMD 命令運行業務系統。

當然，容器鏡像的 CMD 代表業務應用，是整個富容器的核心部分，所有的運維適配都是為了保障業務應用更加穩定的運行。

容器內系統 service 進程

服務器編程發展了數十年，很多的業務系統開發模式均基於裸金屬上的 Linux 操作系統，或者虛擬化環境的下的 Linux 環境。長此以往，很多業務應用的開發範式，會非常頻繁地與系統服務進程交互。比如，使用 Java 編程語言編寫的應用程序，很有可能通過 log4j 來配置日誌的管理方式，也可以通過 log4j.properties 配置把應用日誌重定向到運行環境中的 syslogd，倘若應用運行環境中沒有 syslogd 的運行，則極有可能影響業務的啟動運行；再比如，業務應用需要通過 crond 來管理業務需要的周期性任務，倘若應用運行環境中沒有 crond 系統守護進程，業務應用也就不可能通過 crontab 來配置周期任務；再比如，容器內部的 sshd 系統服務系統，可以快速幫助運維工程師快速進度應用運行現場，定位並解決問題等。

PouchContainer 的富容器模式，考慮到了行業大量有需求和系統服務交付的應用，富容器內部的 init 進程有能力非常方面的原生管理多種系統服務進程。

用戶自定義運維組件

系統服務的存在可以輔助業務的正常運行，但是很多情況下這還不夠，企業自身針對基礎設施以及應用配備的運維組件，同時起到為業務保駕護航的作用。比如，企業運維團隊需要統一化的為業務應用貼近配置監控組件；運維團隊必須通過自定義的日誌 agent 來管理容器內部的應用日誌；運維團隊需要自定義自己的基礎運維工具，以便要求應用運行環境符合內部的審計要求等。

正因為富容器內部存在 init 進程，用戶自定義的運維組件，可以如往常健康穩定的運行，提供運維能力。

最終富容器內部運行的任務進程，可以保障應用的運行時穩定正常，然而對於運維團隊而言，負責內容的範疇往往要比單一的運行時廣得多。通俗而言，運維的職責還需要覆蓋運行時之前的環境準備工作，以及運行時結束後的善後工作。對於應用而言，也就是我們通常意義上提到的 prestart hook 以及 poststop hook。

PouchContainer 的富容器模式，可以允許用戶非常方便的指定應用的啟停執行 hook： prestart hook 以及 poststop hook。 運維團隊指定 prestart hook，可以幫助應用在運行之前，在容器內部做符合運維需求的一些初始化操作，比如：初始化網絡路由表、獲取應用執行權限、下載運行時所需的證書等。運維團隊指定 poststop hook，可以幫助應用在運行結束或者異常退出之後，執行統一的善後工作，比如，對中間數據的清理以便下一次啟動時的純凈環境；倘若是異常退出的話，可以即時匯報出錯信息，滿足運維需求等。

我們可以發現，富容器內部的啟停 hook，對容器的運維能力又做了一層拔高，大大釋放了運維團隊對應用的靈活管理能力。

經過阿裏巴巴內部大量業務的錘煉，PouchContainer 已經幫助超大體量的互聯網公司實現了所有在線業務的容器化。毫無疑問，富容器技術是最為實用、對應用開發以及應用運維沒有任何侵入性的一項技術。

開源的PouchContainer 更是希望技術可以普惠行業，幫助大量的企業在存量業務的容器化方面，贏得自己的時間，快速擁抱雲原生技術，大步邁向數字化轉型。