Cloud Foundry Introduction

Transcript

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