歡迎光臨
每天分享高質量文章

深度解析阿裡百萬級開源容器引擎 PouchContainer 的富容器技術

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 更是希望技術可以普惠行業,幫助大量的企業在存量業務的容器化方面,贏得自己的時間,快速擁抱雲原生技術,大步邁向數字化轉型。

3天Kubernetes線下實戰培訓

Kubernetes應用實戰培訓將於2018年9月14日在上海開課,3天時間帶你系統掌握Kubernetes本次培訓包括:容器特性、鏡像、網絡;Docker特性、架構、組件、概念、Runtime;Docker安全;Docker實踐;Kubernetes架構、核心組件、基本功能;Kubernetes設計理念、架構設計、基本功能、常用物件、設計原則;Kubernetes的實踐、運行時、網絡、插件已經落地經驗;微服務架構、DevOps等,點擊下方圖片查看詳情。

赞(0)

分享創造快樂