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 進程，用戶自定義的運維組件，能夠如往常健康穩定的運行，提供運維能力。

富容器啓停執行 hook

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

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

咱們能夠發現，富容器內部的啓停 hook，對容器的運維能力又作了一層拔高，大大釋放了運維團隊對應用的靈活管理能力。

總結

通過阿里巴巴內部大量業務的錘鍊，PouchContainer 已經幫助超大致量的互聯網公司實現了全部在線業務的容器化。毫無疑問，富容器技術是最爲實用、對應用開發以及應用運維沒有任何侵入性的一項技術。開源的PouchContainer 更是但願技術能夠普惠行業，幫助大量的企業在存量業務的容器化方面，贏得本身的時間，快速擁抱雲原生技術，大步邁向數字化轉型。

本文做者：孫宏亮

閱讀原文

本文來自雲棲社區合做夥伴「阿里技術」，如需轉載請聯繫原做者。