Cloud Foundry中warden的架構與實現

        在Cloud Foundry中，當應用開發者的應用由Cloud Foundry的組件DEA來運行時，應用的資源隔離與控制顯得尤爲重要，而warden的存在很好得解決了這個問題。

        Cloud Foundry中warden項目的首要目的是提供一套簡易的接口來管理隔離的環境，這些隔離的環境可以被稱爲“容器”，他們可以在CPU使用，內存使用，磁盤使用以及設備訪問權限方面做相應的限制。

        本文將從四個方面進行探討分析warden的實現：

1. warden的功能介紹及框架實現
2. warden框架的對外接口及實現
3. warden框架的內部模塊及實現
4. warden的運行示例

warden的功能介紹及框架實現

warden功能介紹

        

        由於Cloud Foundry v1中DEA組件運行應用程序時，自身設計存在一定的缺陷，即同一個DEA上運行的應用不能很好的實現運行過程中資源的隔離與限制，故在Cloud Foundry v2中引入了warden這一模塊。

        warden專門接收DEA組件發送的關於應用的管理請求，在處理這部分管理請求時，藉助輕量級虛擬化技術，將宿主機操作系統進行虛擬化，在容器內部執行請求的具體內容。warden的具體使用效果爲應用程序之間互不感知，資源間完成隔離，各自的資源使用存在上限。假設Cloud Foundry不存在應用程序資源的隔離與限制機制，則在同一個DEA上運行的多個應用程序，在負載增加的時候，會出現竭力競爭資源的情況，當資源消耗殆盡時，大大降低應用程序的可用性與安全性。

        在資源隔離與限制方面，warden主要提供3個維度的用戶自定義隔離與限制：內存、磁盤、網絡帶寬；另外warden還提供以下維度的資源隔離與限制，但僅提供默認值，不提供用戶自定義設置：CPU、CPUACCT、Devices。

        同時，warden作爲一個虛擬化容器，還提供衆多的API命令，供用戶完成對warden container的管理。主要的命令如下：copy in、copy out、create、destroy、echo、error 、info、limit_bandwidth、limit_disk、limit_memory、limit_cpu、link 、list、message、net in、net out、ping、run、spawn、stop和stream等 。這些命令的功能介紹可以簡單參見：James Bayer對於warden與docker的比較文檔。

warden框架實現

        在涉及warden框架的具體實現時，需要先申明和warden相關的多個概念：

• warden：在Cloud Foundry中實現應用資源隔離與控制的框架，其中包括，warden_client、warden_server、warden_protocol和warden container；
• warden server：warden框架中server端的實現，主要負責接收client端請求，以及請求的處理執行；
• warden client：warden框架中client端的實現，被Cloud Foundry中被dea_ng組件調用，實現給warden_server發送具體請求；
• warden protocol：warden框架中定義warden_client與warden_server通信時的消息請求協議；
  
• warden container：warden框架中管理與運行應用程序的容器，資源的隔離與限制以容器爲單位。

        warden框架的實現爲典型的C/S架構，如下圖：

warden框架的對外接口及實現

        雖然warden模塊是Cloud Foundry中不可或缺的一部分，但是如果不借助Cloud Foundry的話，warden依然可以用來管理warden container，並在container內部運行應用程序等。

        若warden運行在Cloud Foundry內部，則dea_ng組件內嵌warden_client，並以warden_client與warden_server建立通信，分發應用的管理請求；若warden單獨存在，則可以通過warden的REPL（Read-Eval-Print Loop）命令行工具瑞與warden_server進行通信，用戶通過命令行發起container的管理請求。本章將以以上兩個方式闡述warden框架的對外接口及實現。

warden與dea_ng通信

       
        warden在Cloud Foundry中的使用，幾乎完全是和dea_ng一起捆綁使用。在部署dea_ng時，不論Cloud Foundry集羣中安裝了多個dea_ng組件，每個dea_ng組件所在的節點上都會安裝一個warden，由此可見warden與dea_ng的存在爲一一對應關係。

        以下是warden與dea_ng的交互示意圖：


        由以上示意圖可知，從dea_ng接受請求，分發container請求，主要分爲以下幾個步驟：

1. dea_ng通過消息中間件NATS獲取app的管理請求；
2. dea_ng根據請求類型，並通過Warden::Protocol協議創建出相對應的container請求；
3. dea_ng通過已經和warden_server建立連接的waren_client發送container請求。

warden與REPL命令行交互

        warden也可以單獨安裝在某個機器上，當需要管理warden時，可以通過REPL命令行的方式，啓動一個進程，創建warden_client，並負責接收用戶在命令行輸入的warden container管理命令，然後通過warden_client給warden_server發送請求。

        從上可知，REPL和dea_ng與warden的通信方式幾乎相同，區別僅僅在兩者的使用方式。以下是warden與repl命令行交互的示意圖：

warden框架的內部模塊及實現

       
        上文已經提及warden框架爲C/S架構，抽象而言，它的運行包括：1.通過warden_client給warden_server發送container request；2.由warden_server接收請求並處理；3.warden_server針對warden container執行請求。

        以下是warden框架的簡單示意圖：

warden_server的框架實現

        warden_server的主要功能爲接收warden_client的請求，並分發處理。warden_server的具體實現爲，通過EventMachine啓動一個server，並監聽本地的一個unix domain socket文件，最終將所有接收到的請求轉發給ClientConnection句柄來處理。ClientConnection首先從監聽的sock文件中讀取數據，然後從讀出的數據中讀取請求，隨後辨別請求的類型，最後通過請求的類型，執行相應的操作。如果請求針對某一個具體的warden container，則需要從container註冊過的registry中先找出相應的warden container，隨後對該warden container執行相應的shell 腳本。

        warden_server在disptach請求的時候，主要是完成對請求的分發。請求類型主要可以分爲兩類，一類爲針對容器內部的具體操作，比如針對創建warden container請求執行新建container操作，對指定container執行運行某任務的操作，對指定container執行銷燬操作等：；另一類爲容器信息的獲取，比如對warden container的ping操作，獲取所有的container hanles信息，對warden執行echo命令等。以下闡述warden_server的請求類型。

warden container的實現

        warden_server主要負責管理warden container的管理，包括創建，設置，銷燬等。當warden container創建完畢並且設置完畢後，由warden container負責自身的運行。運行在warden container內部的應用程序，由於warden container提供資源隔離和控制的環境，從而實現應用程序的資源隔離與限制。

        warden的資源隔離與限制是整個Cloud Foundry的核心，其中warden container的資源隔離與限制主要通過Linux內核的cgroup機制，quota以及tc（traffic controller）來實現。

        這一部分將從warden container的文件結構、生命週期，網絡配置入手，闡述warden container的部分實現。

warden container的文件結構

        

        warden container可以認爲是一個簡易版的操作系統，故也存在自己內部的文件目錄，剛創建完畢的時候，其內部的文件結構主要有以下6個文件夾：/bin、/etc、/jobs、/lib、/run、/tmp、/mnt。

 

        其中/bin文件下主要是一些可執行文件，比如：wshd，wsh，iomux-spawn，iomux-link等，該部分可執行文件的用途，下文或以後會進行闡述。

        /etc則是存放與主機相關的文件和目錄。這些文件包括系統的配置文件，包括系統的主機名，網絡設置參數等。

        /jobs存放從warden container外部傳輸進來的job信息。

        /libs存放系統重要的庫文件等。

        /run存放容器內運行的任務。

        /tmp主要存放一些臨時文件，該文件下主要有一個rootfs文件夾，rootfs文件夾下有一個精簡的系統。

        /mnt主要用於mount文件目錄，並存放容器創建時添加的設備文件。

warden container的生命週期

        warden container的生命週期主要包括，創建、使用、刪除這三個流程，其中在使用過程中會涉及衆多有關warden container的具體操作。

        首先是warden container的創建。warden server 收到創建warden container的請求之後，通過執行腳本來實現創建容器。這部分腳本的作用可以概括爲以下幾部分：初始化文件系統、配置容器屬性、配置容器網絡以及運行warden container中最重要的守護進程wshd。在創建完warden container之後，關於每一個warden container，都會生成一個container的handle，便於container的記錄。

        隨後是warden container的使用。warden container的使用包括兩種情況，一種情況是用戶請求通過warden_client,然後經過warden_server進行管理，比如用戶對warden container進行配置資源限制，用戶給warden container內部傳輸文件等；另一種情況是當warden container內部運行着web應用時，warden container外部用戶通過應用提供的服務訪問內部應用。在第一種情況中，都是通過warden container 內部的washd進程fork出shell進程，而用戶命令通過wsh傳輸給wshd，wshd又將命令交由shell執行。

        在warden container的生命週期中還包括其自身的刪除。刪除過程中，首先讓wshd給container內部所有進程發送一個pkill -TERM請求，並等待進程的結束，若沒有結束，則直接殺死進程，隨後wshd進程退出，並清除container文件目錄。

warden container的網絡配置

        warden container的網絡配置如下圖：

        首先，warden爲每一個容器創建一個虛擬網卡，並通過warden的宿主機作端口映射。如宿主機對於本地指定端口上的請求，通過DNAT轉發至指定warden container內部。當warden container對外發送請求時，通過自身的虛擬網卡對外發送請求，發送至宿主機另外虛擬出的虛擬網卡上，並將該虛擬網卡作爲container的網關，進行請求處理，最終通過宿主機發送至外網。

       


        以上便是warden架構的簡要介紹。

關於作者：

孫宏亮，DAOCLOUD軟件工程師。兩年來在雲計算方面主要研究PaaS領域的相關知識與技術。堅信輕量級虛擬化容器的技術，會給PaaS領域帶來深度影響，甚至決定未來PaaS技術的走向。

轉載請註明出處。

本文更多出於我本人的理解，肯定在一些地方存在不足和錯誤。希望本文能夠對接觸warden架構與實現的人有些幫助，如果你對這方面感興趣，並有更好的想法和建議，也請聯繫我。

我的郵箱：[email protected]

新浪微博：@蓮子弗如清