背景
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 程序，使用者自定義的運維元件，可以如往常健康穩定的運作，提供運維能力。
富容器啟停執行 hook
最終富容器内部運作的任務程序，可以保障應用的運作時穩定正常，然而對于運維團隊而言，負責内容的範疇往往要比單一的運作時廣得多。通俗而言，運維的職責還需要覆寫運作時之前的環境準備工作，以及運作時結束後的善後工作。對于應用而言，也就是我們通常意義上提到的 prestart hook 以及 poststop hook。
PouchContainer 的富容器模式，可以允許使用者非常友善的指定應用的啟停執行 hook： prestart hook 以及 poststop hook。 運維團隊指定 prestart hook，可以幫助應用在運作之前，在容器内部做符合運維需求的一些初始化操作，比如：初始化網絡路由表、擷取應用執行權限、下載下傳運作時所需的證書等。運維團隊指定 poststop hook，可以幫助應用在運作結束或者異常退出之後，執行統一的善後工作，比如，對中間資料的清理以便下一次啟動時的純淨環境；倘若是異常退出的話，可以即時彙報出錯資訊，滿足運維需求等。
我們可以發現，富容器内部的啟停 hook，對容器的運維能力又做了一層拔高，大大釋放了運維團隊對應用的靈活管理能力。
總結
經過阿裡巴巴内部大量業務的錘煉，PouchContainer 已經幫助超大體量的網際網路公司實作了所有線上業務的容器化。毫無疑問，富容器技術是最為實用、對應用開發以及應用運維沒有任何侵入性的一項技術。開源的PouchContainer 更是希望技術可以普惠行業，幫助大量的企業在存量業務的容器化方面，赢得自己的時間，快速擁抱雲原生技術，大步邁向數字化轉型。
原文釋出時間為：2018-09-4
本文作者：孫宏亮
本文來自雲栖社群合作夥伴“
阿裡技術”，了解相關資訊可以關注“
”。