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 行程
-
使用者自定義運維元件
富容器技術與傳統容器最明顯的差異點，即容器內部執行一個 init 行程，而傳統的容器（如 docker 容器等）將容器映象中指定的 CMD 作為容器內 pid=1 的行程。PouchContainer 的富容器樣式可以執行從三種 init 行程中選擇：
-
systemd
-
sbin/init
-
dumb-init
眾所周知，傳統容器作為一個獨立執行環境，內部行程的管理存在一定的弊端：比如無法回收僵屍行程，導致容器消耗太多行程數、消耗額外記憶體等；比如無法友好管理容器內部的系統服務行程，導致一些業務應用所需要的基本能力欠缺等，比如 cron 系統服務、syslogd 系統服務等；比如，無法支援一些系統應用的正常執行，主要原因是某些系統應用需要呼叫 systemd 來安裝 RPM 包……
富容器的 init 行程在運維樣式上，毫無疑問可以解決以上問題，給應用帶來更好的體驗。init 行程在設計時就加入了可以 wait 消亡行程的能力，即可以輕鬆解決上圖中業務行程執行過程中誕生的 Zombie 僵屍行程；同時管理系統服務也是它的本職工作之一。如果一來，一些最為基本的傳統運維能力，init 行程即幫助使用者解決了大半，為運維體系做好了堅實的基礎。
容器映象的 CMD，也就是傳統意義上我們希望在容器內部執行的業務。比如，使用者在容器化一個 Golang 的業務系統打包成映象時，肯定會在 Dockerfile 中將該業務系統的啟動命令指定為 CMD，從而保證未來透過該映象執行容器起，會執行這條 CMD 命令執行業務系統。
當然，容器映象的 CMD 代表業務應用，是整個富容器的核心部分，所有的運維適配都是為了保障業務應用更加穩定的執行。
伺服器程式設計發展了數十年，很多的業務系統開發樣式均基於裸金屬上的 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 更是希望技術可以普惠行業，幫助大量的企業在存量業務的容器化方面，贏得自己的時間，快速擁抱雲原生技術，大步邁向數字化轉型。
Kubernetes應用實戰培訓將於2018年9月14日在上海開課，3天時間帶你係統掌握Kubernetes。本次培訓包括：容器特性、映象、網路；Docker特性、架構、元件、概念、Runtime；Docker安全；Docker實踐；Kubernetes架構、核心元件、基本功能；Kubernetes設計理念、架構設計、基本功能、常用物件、設計原則；Kubernetes的實踐、執行時、網路、外掛已經落地經驗；微服務架構、DevOps等，點選下方圖片檢視詳情。
長按二維碼向我轉賬
![]()
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
![]()
微信掃一掃
使用小程式
知識星球
