基于Docker的PaaS平臺：Flynn初探

Flynn是一個開源的PaaS平臺，可自動構建部署任何應用到Docker容器集群上運行，其功能特性與組件設計大量參考了傳統的PaaS平臺Heroku。本文旨在從使用動機、基本對象、層次架構、功能組件、基本工作流這幾個方面對Flynn做總體的介紹。

為什么需要Flynn

為了便于理解Flynn的作用與功能，讓我們先來看看應用程序從開發到構建再到部署再到運行分別需要經歷的幾個實體狀態：

更具體一點，以一個Java程序為例來描述：

• 源代碼：包括*.java、log4j.properties、pom.xml等文件。

• 發布包：源代碼被編譯打包后生成一個JAR包，這個就是發布包。

• 部署配置：比如每個進程的啟動命令、環境變量、系統屬性等。通常，這些配置會寫在一個啟動腳本里面。

• 進程：運行Java程序的實體。一個Java程序可以起多個進程，每個進程啟動不同的主類(實現了main()方法的類，一個JAR包可以包含多個主類）。

引入Docker后，發布包變成封裝了JAR包與JDK環境的鏡像，進程變成在相互隔 離的容器里運行。但是，從源代碼到鏡像、從鏡像到運行容器這兩步轉換過程需要用戶人工的操作。尤其是后者的轉換，涉及到集群資源調度、自動部署、配置管 理、容器管控等一系列的復雜流程。更進一步，在運行階段還涉及擴縮容、日志查看、錯誤處理、運行監控等運維需求，如果全部人工操作將耗費巨大的工作量。

這時候類似Flynn這樣的PaaS出場了，基于Docker之上進一步封裝了整個構建、部署、運行工作流，使得用戶只需簡單地提交代碼即可完成開發到運行的快速轉換：

• 開發到構建：用戶通過git提交源代碼，由Flynn自動構建鏡像，并提供版本的管理——用戶可以創建新版本(提交新代碼或修改部署配置)、回滾老版本等。

• 部署到運行：Flynn自動選擇運行機器，為每個進程副本部署啟動單獨的容器，并提供進程的管理——用戶可以做擴縮容、查看日志、監控狀態等。

Flynn的基本對象

下面我們來看看發布包、部署配置、進程這三個實體在Flynn中是如何抽象的。如下圖所示是其基本對象的關系描述：

• App：表示一個應用，所有其他對象都是圍繞App而展開。

• Artifact：表示應用的發布包，實際上對應一個Docker鏡像。

• Process：表示應用的進程。通過一個鏡像可以啟動多個不同的進程，每個進程運行在自己單獨的容器里。

• Release：是應用發布態的 抽象表示。它在Artifact的基礎上增加了一些不可變(immutable)的靜態配置，比如每個進程的啟動命令行、環境變量、綁定端口、等。要修改 這些配置，需要生成一個新Release。Release這種不可變性是為了方便做Rollback，即應用隨時可以回退到之前的Release。

• Formation: 是應用運行態的抽象表示。它在Release的基礎上增加了可變(mutable)的動態配置，即每個進程的副本(replica)個數。

• Job: 是進程副本的抽象表示，每個Job對應一個運行容器。因此，在后文中可以看到，Job是資源調度的基本單元。

Flynn的層次架構

如下圖所示，Flynn的架構自下而上分為兩個層級——Layer 0和Layer 1。簡單地理解，可以認為Layer 1負責接受用戶請求，封裝成應用的運行指令，再由Layer 0解決在哪里運行、以什么方式運行的問題。具體一點講，Layer 0面向的對象是Formation，負責將底層的集群資源封裝成可執行Formation的一臺主機；Layer 1面向的對象是App，負責將App從源代碼構建成Artifact，進而封裝成Formation提交給Layer 0去執行。

這種分工明確的層次劃分，使整個系統非常靈活，相互松耦合，便于任意組件的替換(比如，甚至可以把Layer 0替換成不用容器去執行Formation)。

Flynn的功能組件

下面總結一下組成兩個層級的各個組件及其功能(所有組件自身都可以運行在容器里)：

Layer 0

• Scheduler: 資源調度器，定期從Layer 1獲取Formation的更新，再根據每個Formation的部署配置生成一個個的Job，最后從集群中選擇合適的機器去運行這些Job。

• Host Service: 運行在集群每臺機器上的agent，負責管控運行在本機的容器，并收集運行狀態信息。

• Host Leader：一個特殊的Host Service，做為"cluster leader"，負責維護整個集群的狀態信息(比如有哪些機器、每臺機器上運行的Job等)，并提供給Scheduler用于資源調度。

• Discoverd：基于etcd的服務發現模塊，提供容器間的發現機制。實際上，Flynn自身的組件間通訊也是通過Discoverd來相互發現的。

Layer 1

• CLI：提供給用戶使用的命令行工具。

• Controller：為Flynn系統的入口， 封裝了核心對象(比如app/artifact/release/job)的增刪改查操作，以RESTFul接口方式提供給外部客戶和內部組件調用。它維 護的REST對象將持久化到postgre數據庫。Layer 0的Scheduler就是通過Controller的接口來獲取Formation更新的。

• GitReceiver：接受用戶git push源代碼的SSH服務器。接受到git push后將觸發Receiver。

• Receiver：基于buildpack機制， 利用SlugBuilder從源代碼包構建slug包。buildpack和slug都是從Heroku借鑒過來的概念。簡單地理解，buildpack 是一組用于構建源代碼的腳本，buildpack可以多種多樣，每個buildpack可構建某種類型的源代碼，這種類型可以是不同的語言(比如 Java、PHP)、不同的構建方式(比如maven、gradle)；而slug則是buildpack構建生成的部署包，包含了編譯輸出文件、依賴庫 文件等運行環境。

• BlobStore: HTTP文件服務器，用于上傳/下載slug包。

• SlugBuilder：接受源代碼包，基于某種buildpack構建生成slug包。選擇哪一種buildpack可以顯式地指定，也可以由SlugBuilder根據源文件自動匹配。

• SlugRunner：運行slug包，會從BlobStore下載應用的slug包。

Flynn的工作流

下面通過一個例子來展示Flynn各個組件的工作流。使用Flynn來構建部署應用最基本的流程是以下三步：

用戶創建app：

用戶提交app代碼：

用戶擴容app的進程：

對比Kubernetes

Kubernetes是Google開源的Docker容器集群管理系統，為容器化的應用提供資源調度、部署運行、服務發現、擴容縮容等整一套功能，更詳細地介紹請參考作者的另一篇文章《Kubernetes初探：原理及實踐應用》。

在應用的抽象上，Flynn與Kubernetes有本質的區別：Flynn的應用管 理單元是App，只對應一個Docker鏡像，但可以由這個鏡像來啟動多個進程，并且每個進程可以單獨擴縮容；而Kubernetes的應用管理單元是 Pod，可對應多個不同的Docker鏡像，并且Pod內的各個容器保證會運行在相同的機器上，整個Pod作為擴縮容的基本單位。

另外一個根本的區別是Kubernetes不提供鏡像構建與版本管理的功能。因此，Kubernetes只能看成是面向容器而不是面向應用的系統。當然，我們可以在Kubernetes之上擴充這些功能。

對比Deis

與Flynn類似，Deis也是受到Heroku的啟發，基于Docker之上構建的PaaS平臺。因此，從功能特性到應用抽象，兩者是大同小異。

至于兩者的差異，了解不是很多，這里提三點：第一，Deis是用Python開發的， 而Flynn是Go；第二，Deis依賴于CoreOS，而Flynn因為所有組件都可運行在容器里，沒有OS的依賴；第三，Deis在構建階段，除了 buildpack方式構建外，還支持Dockerfile與鏡像直接上傳兩種方式，相對Flynn更為靈活。

來自：http://blog.csdn.net/zhangjun2915/article/details/41266133