玩過幾套 Container Manager 之後，今天來介紹一下比較複雜與強大的 Cloud Foundry Project。

1. sj@toright.com
https://blog.toright.com
Cloud Foundry Introduction

2. Cloud Foundry History
2008 年有一個由 Chris Richardson 所主導的 Cloud Foundry，當時這個 PaaS 專案透過 Java 進行設計，構築
在 Amazon EC2，並且於 2009 年引入了 Spring Framework。
真正的起源是 VMware 2009 年由 Derek Collison 所主導的小型專案，當時的專案代號為 B29，同年
VMware 花了 4.2 億鎂收購 SpringSource，Cloud Foundry 整合由 VMware 進行發展。
2011 年 Cloud Foundry 問世，2012 年 BOSH 也加入 Cloud Foundry, 2013 年由 EMC 與 VMware 共同發布
了 PCF, Pivotal Cloud Foundry 走向商業化。
2015 年成立非營利組織 Cloud Foundry Foundation，將部份 Component Source Code 以 Apache License 2.0
釋出，主要透過Ruby, Go, Java 實作。

3. Cloud Foundry - PaaS 是什麼？
假設沒有任何幫助的情況下，有一天你想要開發「自動駕駛」，第一步你要先有台車。那你可能要
先製造輪子、車體、引擎等等，才可以開始你的「自動駕駛」 產品開發。這樣太慢了，如果可以有人
幫忙處理這些事情，那該有多好？
以 IaaS 的角色來說，可以想像 IaaS 直接提供你廠房 (Memory)、工人 (Cpu) 與電力等等基礎建設，
在雲端我們可以統稱 VM (Virtual Machime)。
但有了這些還不 夠快，如果可以直接提供你做好的輪子、車體、引擎這些典型既有功能的 產品，
可以想像成大家開發都會用的資料庫、網路服務與儲存空間等等。此外，你還可以請 PaaS 將零件
組合成為車子，東西壞了還幫你修理，連停車位都幫你處理好了。有了 PaaS 你只要專心開發你的
「自動駕駛」功能即可，開發完成也可以幫你生 產產品。從開發、生產到營運都提供了完善的協助
，我們在 IT 稱為 DevOps。

4. Container Manager 與 PaaS
Cloud Foundry 可以提供你建立自己的 PaaS 平台，如果您用過 AWS 雲服務，Cloud Foundry 差不多
就是 AWS 基於 EC2 之上的 PaaS 服務管理平台，只是目前功能與元件非常基本。由於 Cloud
Foundry 是 Linux Container Base，相較於 Docker Swarm 與 K8S (Kubernates) 這兩個常見的 Container
Manager，Cloud Foundry 功能更為複雜也強大。除了提供了基本的容器管理，還提供了應用服務管
理，可以開發自己需要的應用與 PaaS 功能。
選擇適合的 PaaS 平台很重要，可別殺雞用牛刀了！

5. Cloud Foundry 目的 提供 PaaS 解決方案，加速產品開發與上市

6. PCF 商業版 Pivotal Cloud Foundry Differs from Open Source Cloud Foundry
以 Open Source Component 來
看，最缺乏的就是「管理功能」
相關的 Component。
提供的 Service 目前也只有
MySQL，其他可以自行開發
Service 來滿足需求。

7. Cloud Foundry 架構介紹

8. Cloud Foundry Component
基本組件包含了產品開發、佈
署、維運這幾個層面。提供的功
能都是最基本需求，更多的應用
需要自己實現，官方提供的PCF
有 Market 可以直接購買付費應
用與服務。
對於系統與架構不熟悉的開發
者，可以節省許多時間。

9. Cloud Foundry Component - Router
負責維護與派送連線到對應的
Service 與 Application，那麼
Routing 如何協同錯綜複雜的服務
與應用？
運作機制：Router 會三不五時去看
看 BBS (Diego Bulletin Board
System) 這個公佈欄寫了什麼？應
用會把自己的聯繫方式主動更新
到這個公佈欄。

10. Cloud Foundry Component - Authentication
簡稱 UAA (全名是 User Account and
Authentication)，實作了標準的 OAuth 2.0 規範，此
外 Login Server 也提供了 API 進行帳戶管理與操
作。
目前 UUA 已經封裝成為 WAR File，可以輕易的
進行佈署。可以透過 CF CLI 直接佈署，透過 CF
內建的 Spring MVC 快速整合與安裝到 Cloud
Foundry。
什麼是 Spring MVC？
Spring 底層實踐了 IoC/DI 與 AoP 機制，透過這個
機制構築了 MVC 架構。

11. Cloud Foundry Component - App Lifecycle
Cloud Controller (簡稱 CC) 用來佈署 Application，
有點像是麥當勞餐廳的點餐櫃台，當櫃台收到訂
單後，透過 CC-Bridge 委派廚房進行製作餐點。
應用程式最終是執行在 VM 中的 Garden
Containers，Container 透過 Diego Brain 進行管理
與監控，執行 Container 的個體稱為 Diego Cell。
然而每一個 Application 的執行狀態會自己回報到
BBS 這個公佈欄中，也會傳遞 Stream Log 至
Loggregator。
●

12. CC 如何在成千上萬的 Diego Cell 中管理 Apps？
其實 CC 本身不負責 Container 的管理，只負責發
布命令。
nsync 用來接收 CC 的指令，比如收到 Create/Scale
App 的指令後，就會建立記錄為 DesireLRPs。
Call Rep 會隨時監控 Containers/Apps 的狀態，並更
新最新的狀態至 ActualLRPs。
Converger 負責調度讓 DesireLRPs 與 ActualLRPs
保持一致性，多就退少就補。
LRP = Long-Running Processes

13. Cloud Foundry Component - App Storage & Execution
Blobstore 用來存放一些二進位檔案，可以整合
S3 或者存放於自身的 Storage。
Garden 算是一個管理與執行 Container 的叢集，
執行於 Garden 的 Container 需要實作 Backend
Interface (功能與 docker 能用的差不多)。目前的
版本所使用的 Backend 是 Garden-runC (之前用
garden-linux)。
Garden 使用了 Garden RootFS，Garden RootFS 是
基於 OverlayFS 的實作，可以管理 Container
Image, Volume, ID Map, Quota...

14. Cloud Foundry Component - Service
Service Brokers 負責提供特定的
服務，比如 MySql 服務，當有
Application 需要時，Service
Broker 會負責建立提供服務的實
體。

15. Cloud Foundry Component - Messaging
每個 Component 彼此透過 HTTPs 進
行溝通與資料交換。Consul server 負
責管理 IP 位置，並且維持Component
正確運作。
Bulletin Board System 負責管理Apps
狀態、工作、Heartbeat 等等，資料儲存
於 MySQL。

16. Cloud Foundry Component - Metrics & Logging
Metrics Collector 蒐集 Component 狀態的
統計資料，可以用來監控使用狀態
Loggregator (Log Aggregator) 可以蒐集
Stream Log 協助開發者進行維運

17. Container 之間如何通信？
透過 Overlay Network (與 Docker Swarm 相同)
實現了 VXLAN (RFC 7348)，相較於 VLAN，VXLAN 可以在不更動硬體設定的情況下實現Virtual LAN 配
置，通訊時使用UDP 4789。
Policies 控制各個 Container 之間的防火牆，不需重新啟動 Application 即可變
更設定。
規模驗證：25w Container, 1250 Diego Cell, 305 node, 28TB Memory

18. Buildpacks
在 CF 中的所有Application 是執行在 Container 中，但是 CF 的架構下，將Application 與執行環境進行隔離，好讓執
行環境可以廣泛的被應用。可以想像CF Buildpacks 像是一個運動場管理員，提供了不同的運動場地，像是草地、室
內運動場、PU 跑道等等設施。
今天當有一個體育活動(Application) 需要進行時，會依序尋找適合的場地。比如足球在草地、羽球在室內運動場、
跑步在 PU 跑道等等。當CF 決定要使用哪一種場地(Buildpack) 時，就會建立場地讓運動員準備使用。到這裡
Buildpack 的任務就算是完成了。
寫好的 Code 要在 Container 執行，必須透過Buildpacks 找到適合的執行環境，封裝為一個乾淨的Image 來執行，其
中的概念有點類似Dockerfile 建構 Image。Dockerfile: 建立 Docker Image 的腳本，透過堆疊的方式建構Container
環境。可以透過buildpack 自訂更多程式語言執行的環境。

19. Buildpacks 內建支援的程式執行環境
CF 官方提供的 Buildpacks：Binary, Go, Java, .NET Core,
Node.js, PHP, Python, Ruby, Staticfile, NGINX, HWC
除了官方提供的Buildpacks，也有許多 OpenSource
(Community Buildpacks) 可以使用，您也可以自己動手
打造 Buildpacks。

20. How to staged app? 1. 開發者在專案資料夾中透過 CF
Push 發布 App
2. CF CLI 呼叫 CC API 建立 App
3. CC 建立 App Metadat 包含：app
name, number of instances , user
specified, buildpack, etc…
4. 上傳程式，這一個動作會透過
Resource Cache 判斷有差異的檔案
，加速上傳作業
5. 合併上傳檔案與 Resource Cache 封
裝為 package 存到 Blodsotre

21. App life cycle
6. CF CLI 呼叫 CC 啟動 App
7. CC 發布一個 Task 到排程中，被委派的 Cell
會執行 Task，尋找 App 對應的 Buildpack，然後
進行建制
8. 將執行過程 Stream Output 給開發者，好進行
錯誤排除
9. 建制過程中產生的檔案以 tarball 方式封裝為
Droplet (類似 Image Layer) 然後存到 Blobstore
10. 在 15min 以內，如果可以建制完成，就會回
報給 CC
11. 當 App 正確 Staged 之後，就會啟動，這時候
Container 才真正被執行
12. 執行後持續回報狀態到 CC

22. Diego Balances App 做什麼用？
使用 GO 語言所編寫的Auction Algorithm 與平衡機制，可以讓Diego Cell 提供的執行資源（CPU, Memory）
被有效利用。透過Auction 機制決定如何執行Tasks 與 Long-Running Processes。
Tasks 指的是一次性的工作，像是Staged App, Upgrade Database, etc... Job 如果執行失敗，將不會被重新分派
執行，真的只做一次喔！
Long-Running Processes 就是常常看到的LRP，表示一個持續性的App，運作時可以同時建立多個實體，分別
跑在不同的VM、實體 Server、甚至不同的區域，藉此平衡負載與高可用性。
Diego Balances App Processes

23. Auctioneer (排賣師) 的責任：透過Auction Algorithm 掌管 Task 與 LRP 分派工作，運作實需要透過
Consul/Locket 處理個節點之間的同步問題。
Ordering the Auction Batch 實行原則 (競標順序)
● 每個 LRP 最少一個實例被執行
● 每次都會分配所有任務
● 盡可能讓每個VM 都執行實例，盡可能在每一個區域分散實例
分配原則：先求有再求好、人人有功練、雞蛋不要放在同一個籃子
Diego Auction 機制

24. Ordering the Auction Batch (建立拍賣清單)
1. 一開始有兩組LRP 需要配置
2. 依據原則進行排序
3. 中間如果有Task 分派需
求，會重新調整排序

25. 流標的 Job 會在下一次的拍賣會被重新
排序進行拍賣
何時舉辦拍賣會？
BBS 發現 LRP 與期望的不同，不夠就舉
行拍賣會，超過就砍掉 App，確保實例
與期望相符
發生 Cell Fail，對應的 Job List 需要重新
進行拍賣
Auction (舉行拍賣會)

26. Volume Service 管理微服務資料
既然 Cloud Foundry 都是透過 Container 執行，當微服務執行在沙箱中，然而Container 在眾多的 Cell 移動，
那要如何保存資料呢？
Cloud Foundry 提供的 Volumes Service 讓這些到處跑的Container 可以將資料集中儲存，透過Container
Volume API 實現整合 Volumes Service。目前 Volumes Service 提供以下四種方式，可以透過Bosh 進行安裝：
1. Bosh-Lite / Local Volume Service (單機版)
2. NFSv3 Service
3. Amazon EFS Service (NFSv4)
4. CephFS Service

27. Volume Service 與 Application 整合過程
1. 佈署 Volume Service Broker
2. 建立 Volume Service (產生
Volume Instance)
3. Application Bind Volume Service

28. Cloud Foundry CLI - Deploy Docker
Cloud Foundry CLI 可以想像為 Docker CLI，可以讓開發者在本機 Push
Docker Image 到 Cloud Foundry 上面執行、管理與監控。
對於大量的 Docker Image 組態管理，可以透過 manifest.xml 達到類似於
docker-compose 的批量 Docker 組態功能。
啟動 Docker 之後透過「health check type」確認 Application 啟動狀態，其實功
能與原本 Docker 提供的差不多。

29. Thanks
sj@toright.com
https://blog.toright.com