[[123216]]

Flynn是一個(gè)開源的PaaS平臺(tái)，可自動(dòng)構(gòu)建部署任何應(yīng)用到Docker容器集群上運(yùn)行，其功能特性與組件設(shè)計(jì)大量參考了傳統(tǒng)的PaaS平臺(tái)Heroku。本文旨在從使用動(dòng)機(jī)、基本對(duì)象、層次架構(gòu)、功能組件、基本工作流這幾個(gè)方面對(duì)Flynn做總體的介紹。

為什么需要Flynn

為了便于理解Flynn的作用與功能，讓我們先來看看應(yīng)用程序從開發(fā)到構(gòu)建再到部署再到運(yùn)行分別需要經(jīng)歷的幾個(gè)實(shí)體狀態(tài)：

更具體一點(diǎn)，以一個(gè)Java程序?yàn)槔齺砻枋觯?/p>

• 源代碼：包括*.java、log4j.properties、pom.xml等文件。
• 發(fā)布包：源代碼被編譯打包后生成一個(gè)JAR包，這個(gè)就是發(fā)布包。
• 部署配置：比如每個(gè)進(jìn)程的啟動(dòng)命令、環(huán)境變量、系統(tǒng)屬性等。通常，這些配置會(huì)寫在一個(gè)啟動(dòng)腳本里面。
• 進(jìn)程：運(yùn)行Java程序的實(shí)體。一個(gè)Java程序可以起多個(gè)進(jìn)程，每個(gè)進(jìn)程啟動(dòng)不同的主類(實(shí)現(xiàn)了main()方法的類，一個(gè)JAR包可以包含多個(gè)主類）。

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

這時(shí)候類似Flynn這樣的PaaS出場(chǎng)了，基于Docker之上進(jìn)一步封裝了整個(gè)構(gòu)建、部署、運(yùn)行工作流，使得用戶只需簡(jiǎn)單地提交代碼即可完成開發(fā)到運(yùn)行的快速轉(zhuǎn)換：

• 開發(fā)到構(gòu)建：用戶通過git提交源代碼，由Flynn自動(dòng)構(gòu)建鏡像，并提供版本的管理——用戶可以創(chuàng)建新版本(提交新代碼或修改部署配置)、回滾老版本等。
• 部署到運(yùn)行：Flynn自動(dòng)選擇運(yùn)行機(jī)器，為每個(gè)進(jìn)程副本部署啟動(dòng)單獨(dú)的容器，并提供進(jìn)程的管理——用戶可以做擴(kuò)縮容、查看日志、監(jiān)控狀態(tài)等。

Flynn的基本對(duì)象

下面我們來看看發(fā)布包、部署配置、進(jìn)程這三個(gè)實(shí)體在Flynn中是如何抽象的。如下圖所示是其基本對(duì)象的關(guān)系描述：

• App：表示一個(gè)應(yīng)用，所有其他對(duì)象都是圍繞App而展開。
• Artifact：表示應(yīng)用的發(fā)布包，實(shí)際上對(duì)應(yīng)一個(gè)Docker鏡像。
• Process：表示應(yīng)用的進(jìn)程。通過一個(gè)鏡像可以啟動(dòng)多個(gè)不同的進(jìn)程，每個(gè)進(jìn)程運(yùn)行在自己?jiǎn)为?dú)的容器里。
• Release：是應(yīng)用發(fā)布態(tài)的 抽象表示。它在Artifact的基礎(chǔ)上增加了一些不可變(immutable)的靜態(tài)配置，比如每個(gè)進(jìn)程的啟動(dòng)命令行、環(huán)境變量、綁定端口、等。要修改 這些配置，需要生成一個(gè)新Release。Release這種不可變性是為了方便做Rollback，即應(yīng)用隨時(shí)可以回退到之前的Release。
• Formation: 是應(yīng)用運(yùn)行態(tài)的抽象表示。它在Release的基礎(chǔ)上增加了可變(mutable)的動(dòng)態(tài)配置，即每個(gè)進(jìn)程的副本(replica)個(gè)數(shù)。
• Job: 是進(jìn)程副本的抽象表示，每個(gè)Job對(duì)應(yīng)一個(gè)運(yùn)行容器。因此，在后文中可以看到，Job是資源調(diào)度的基本單元。
•  

Flynn的層次架構(gòu)

如下圖所示，F(xiàn)lynn的架構(gòu)自下而上分為兩個(gè)層級(jí)——Layer 0和Layer 1。簡(jiǎn)單地理解，可以認(rèn)為L(zhǎng)ayer 1負(fù)責(zé)接受用戶請(qǐng)求，封裝成應(yīng)用的運(yùn)行指令，再由Layer 0解決在哪里運(yùn)行、以什么方式運(yùn)行的問題。具體一點(diǎn)講，Layer 0面向的對(duì)象是Formation，負(fù)責(zé)將底層的集群資源封裝成可執(zhí)行Formation的一臺(tái)主機(jī)；Layer 1面向的對(duì)象是App，負(fù)責(zé)將App從源代碼構(gòu)建成Artifact，進(jìn)而封裝成Formation提交給Layer 0去執(zhí)行。

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

Flynn的功能組件

下面總結(jié)一下組成兩個(gè)層級(jí)的各個(gè)組件及其功能(所有組件自身都可以運(yùn)行在容器里)：

Layer 0

• Scheduler: 資源調(diào)度器，定期從Layer 1獲取Formation的更新，再根據(jù)每個(gè)Formation的部署配置生成一個(gè)個(gè)的Job，***從集群中選擇合適的機(jī)器去運(yùn)行這些Job。
• Host Service: 運(yùn)行在集群每臺(tái)機(jī)器上的agent，負(fù)責(zé)管控運(yùn)行在本機(jī)的容器，并收集運(yùn)行狀態(tài)信息。
• Host Leader：一個(gè)特殊的Host Service，做為"cluster leader"，負(fù)責(zé)維護(hù)整個(gè)集群的狀態(tài)信息(比如有哪些機(jī)器、每臺(tái)機(jī)器上運(yùn)行的Job等)，并提供給Scheduler用于資源調(diào)度。
• Discoverd：基于etcd的服務(wù)發(fā)現(xiàn)模塊，提供容器間的發(fā)現(xiàn)機(jī)制。實(shí)際上，F(xiàn)lynn自身的組件間通訊也是通過Discoverd來相互發(fā)現(xiàn)的。

Layer 1

• CLI：提供給用戶使用的命令行工具。
• Controller：為Flynn系統(tǒng)的入口， 封裝了核心對(duì)象(比如app/artifact/release/job)的增刪改查操作，以RESTFul接口方式提供給外部客戶和內(nèi)部組件調(diào)用。它維 護(hù)的REST對(duì)象將持久化到postgre數(shù)據(jù)庫。Layer 0的Scheduler就是通過Controller的接口來獲取Formation更新的。
• GitReceiver：接受用戶git push源代碼的SSH服務(wù)器。接受到git push后將觸發(fā)Receiver。
• Receiver：基于buildpack機(jī)制， 利用SlugBuilder從源代碼包構(gòu)建slug包。buildpack和slug都是從Heroku借鑒過來的概念。簡(jiǎn)單地理解，buildpack 是一組用于構(gòu)建源代碼的腳本，buildpack可以多種多樣，每個(gè)buildpack可構(gòu)建某種類型的源代碼，這種類型可以是不同的語言(比如 Java、PHP)、不同的構(gòu)建方式(比如maven、gradle)；而slug則是buildpack構(gòu)建生成的部署包，包含了編譯輸出文件、依賴庫 文件等運(yùn)行環(huán)境。
• BlobStore: HTTP文件服務(wù)器，用于上傳/下載slug包。
• SlugBuilder：接受源代碼包，基于某種buildpack構(gòu)建生成slug包。選擇哪一種buildpack可以顯式地指定，也可以由SlugBuilder根據(jù)源文件自動(dòng)匹配。
• SlugRunner：運(yùn)行slug包，會(huì)從BlobStore下載應(yīng)用的slug包。

Flynn的工作流

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

用戶創(chuàng)建app：

flynn create myapp 

用戶提交app代碼：

git push flynn master 

用戶擴(kuò)容app的進(jìn)程：

flynn scale web=2 

對(duì)比Kubernetes

Kubernetes是Google開源的Docker容器集群管理系統(tǒng)，為容器化的應(yīng)用提供資源調(diào)度、部署運(yùn)行、服務(wù)發(fā)現(xiàn)、擴(kuò)容縮容等整一套功能，更詳細(xì)地介紹請(qǐng)參考作者的另一篇文章《Kubernetes初探：原理及實(shí)踐應(yīng)用》。

在應(yīng)用的抽象上，F(xiàn)lynn與Kubernetes有本質(zhì)的區(qū)別：Flynn的應(yīng)用管 理單元是App，只對(duì)應(yīng)一個(gè)Docker鏡像，但可以由這個(gè)鏡像來啟動(dòng)多個(gè)進(jìn)程，并且每個(gè)進(jìn)程可以單獨(dú)擴(kuò)縮容；而Kubernetes的應(yīng)用管理單元是 Pod，可對(duì)應(yīng)多個(gè)不同的Docker鏡像，并且Pod內(nèi)的各個(gè)容器保證會(huì)運(yùn)行在相同的機(jī)器上，整個(gè)Pod作為擴(kuò)縮容的基本單位。

另外一個(gè)根本的區(qū)別是Kubernetes不提供鏡像構(gòu)建與版本管理的功能。因此，Kubernetes只能看成是面向容器而不是面向應(yīng)用的系統(tǒng)。當(dāng)然，我們可以在Kubernetes之上擴(kuò)充這些功能。

對(duì)比Deis

與Flynn類似，Deis也是受到Heroku的啟發(fā)，基于Docker之上構(gòu)建的PaaS平臺(tái)。因此，從功能特性到應(yīng)用抽象，兩者是大同小異。

至于兩者的差異，了解不是很多，這里提三點(diǎn)：***，Deis是用Python開發(fā)的， 而Flynn是Go；第二，Deis依賴于CoreOS，而Flynn因?yàn)樗薪M件都可運(yùn)行在容器里，沒有OS的依賴；第三，Deis在構(gòu)建階段，除了 buildpack方式構(gòu)建外，還支持Dockerfile與鏡像直接上傳兩種方式，相對(duì)Flynn更為靈活。

原文出自：http://blog.csdn.net/zhangjun2915/article/details/41266133