過去快20年的經驗裡，很少看到有哪個技術在短短的三年就可以發展成這個樣子的... 半年前剛開始研究 Docker 時，就想找個好用的 WEB / GUI 管理工具，結果都沒滿意的，沒想到現在就一堆選擇了...
這次要介紹的 Rancher, 除了是套完整的 Docker Engine 管理工具之外，也是個 Docker Cluster 管理工具及平台，讓你在佈署 Containers 的時候，不用去傷腦筋你要怎麼分配資源等等瑣碎的事情，你只管把你的 Container 組態設定好，丟上去就行了。這感覺跟當年 (2009) 初次接觸到 Winows Azure 的 Cloud Service 一樣令人感動。當年只要把你的 Application 打包成 Cloud Service Package，開發階段設定好組態，佈署階段可直接手動或自動的設定 Scale，具備 Production / Staging Environment 切換上線，可以不中斷服務的升級系統...，整個就是靠 Visual Studio Deploy 就足以取代過去要 OP team 搞半天的升級程序。
只可惜 Azure Cloud Service 的種種優異的管理及佈署能力，至今都還只限於 Azure Only，沒有下放到地面版本的 Platform ... 真的是 "此物只應天上有" 啊... 但是站在地上的凡人沒機會用啊... 現在看到 Docker Cluster + Management Tools 的發展，這種威力已經變成隨手可得了... 為了紀念一下當年 Microsoft 早在 Azure 就達成的成就 (而且早已商業化)，這次的實作案例就拿 Azure 示範位於公有雲的 Production Environment，如何做到服務的管理及升級程序吧!
過去開始用 Docker 時，其實我就一直在找合用的 Web UI，來取代每次都要打一堆指令的管理方式。過去都還停在單機版的時代，按照我使用的順序，我嘗試過這幾套:
- Synology Docker Station (內建在 NAS 內的 Docker 套件)
- Docker UI (實在有點陽春... 已放棄)
- Shipyard (一樣用不順手，連安裝都沒完全搞定就放棄了)
- Docker Swarm (Docker 官方內建的 solution)
- Cattle (Rancher 內建的 infrastruction orchestration platform)
- Apache Mesos
- Kubernetes (Google 的方案)
- Docker Cloud (前身: Tutum, 被 docker 併購的線上託管服務)
- Rancher
- Tutum, 被 docker 收購後變成 docker cloud
- Azure Container Service (using Mesos or Swarm)
- ...
- 要錢! 免費版本只提供管理 1 node，每多一個 node 每個月就要 USD $15..
- 缺少資源使用的統計或是 dashboard，想知道 CPU / RAM / DISK 的使用狀況，得另外想辦法
- (大推) UI 介面合我的胃口.. 更重要的是提供詳細的硬體資源使用狀況，也提供每個 Container 的資源使用狀況
- (大推) 支援 In-Service Upgrade
- (大推) 內建 Load Balancer
- 安裝容易，同時也提供了專為執行 Docker 而發行的專用 Linux: Rancher OS
- 支援多種 Orchestration Platform, 包括 Docker Swarm / Mesos
- 支援 Windows Azure 及其他 Cloud 服務商
- 支援多個環境 (Environment) 的管理，可以切割幾個完全獨立的 Cluster 個別負責不同的任務，或是隔離測試環境等
STEP #0, Planning
- 佈署 WordPress 服務，區分 WEB 及 DB 兩個 container, WEB 需要透過 Load Balance 達到 HA 的要求
- Scale Out, 將 Web Nodes 從 2 個升級到 3 個
- 進行升級，在升級 WEB 的過程中必須持續提供服務 (In-Service Upgrade)
STEP #1, 架設 Rancher Server
這邊開始前，先說明一下 Rancher 的基本觀念 (可參考這篇)。Rancher Server 本身是套 Docker Cluster 的管理介面，但是他本身也被包裝成 Container, 所以你為了執行它，你也是得找個 Docker Engine 來安置它。雞生蛋蛋生雞的問題來了，所以我還是得架設一台 Linux + Docker 嗎? Rancher Labs 提供了另一個好選擇，就是 Rancher OS。 簡單的說，Rancher OS 是個特別為了執行 Docker 所發行的 Linux, 它拿掉所有不必要的服務，也因此整個 image 非常小，只有 28mb. Docker Engine 在 Rancher OS 的地位很高，系統啟動後第一個執行的就是 Docker (PID : 1) .. 當然你可能需要些其他標準 Linux OS 有的功能，這些通通都可用 Container 的方式外掛上去，維持 OS 本身的簡潔... 因此，這次我的動作就是先用 Rancher OS 搞定我第一個 Docker Engine, 並且在上面跑 Rancher Server。這部分我就不多說，很多前輩 & 官網都寫得比我還清楚，我直接貼參考連結就好 :D- 如何將 Rancher OS 安裝到 HDD ? > Installing RancherOS to Disk
- 如何安裝 Rancher Server ? > 視覺化管理眾多 Docker 容器與部署的好工具：Rancher
圖: Rancher Server 預設安裝的畫面[/caption]
Rancher Server 跑起來不算輕快，Container Started 之後要等一兩分鐘才能完全啟動，請有耐心點等待，別以為你裝壞了。Rancher Server 用了不少 Java 開發的套件，啟動慢是正常的 @@，請別用太糟糕的規格給 Rancher Server, 官方建議是至少 1GB+ RAM, 我自己觀察，最後給了 2GB RAM 比較剛好，這個 VM 就只執行 Rancher OS + Rancher Server 這個 Container 而已，本身我並沒有讓他加入 Cluster，往後要佈署的服務也不會被放到這台 VM 上，單純當 Master 來使用。
這步驟完成之後，就可以開始建立你的 Docker Cluster 了，請繼續看下去!
STEP #2, 架設 Local Environment
這邊有些準備動作要先做，我想建立一組 Docker Engine Cluster, 專供內部的 Development Team 使用，步驟是先準備好 Docker Engine 環境，然後按照 Rancher Server 的指示，執行 "Add Host" 的步驟，把這個 Docker Engine 納入 Cluster 的管控。這邊我比照前面的步驟，用 Rancher OS 建了三台 VM，分別是 Rancher Host #1 ~ #3。
STEP #3, 架設 Azure Environment
接下來要準備正式上線的環境了。正式環境當然不是自己在家亂搞一通就 OK。這部分我選擇把他配置在 Azure 的 Data Center 內，卻保有良好的服務品質。這部分的執行方式，其實跟 STEP #2 沒甚麼不同，只是 VM 環境改成 Azure 而已。 比較特別的是，Rancher 直接支援各大 IaaS 的環境，Microsoft Azure 也在支援之內。支援的意思是你不在需要自己手工從 VM 建立到加入 HOST 都一步一步慢慢來，可以在一個畫面內一次搞定所有的配置需求。在 Azure 上面佈署多台 HOST 的動作，整個過程都已經自動化，我只要把我的 certification 貼進去，告訴它我需要幾台 VM (之後等著付錢) 就搞定了! 一樣，先準備 Azure Environment，切換過去後，從 Infrastructure > Hosts > Add Host ，輸入你 Azure 上的資訊，還有你要開設的 VM 規格及數量後:
"At your service! Sir!"
-- 這邊穿插一下，其實 Rancher Server 直接原生的支援 Docker Swarm, 只是目前版本還沒辦法 "匯入" 已經建立好的 Swarm Cluster. 也就是你必須透過 Ranhcer Server, 從頭建立 Host(s). 官網說正在努力這件事啦，完成後就可以匯入現有的 Docker Swarm Cluster. 為什麼我要補充這個? 因為同樣這個月才 GA (General Available) 的 Azure Container Service, 可以讓你 Click 幾下就把整個 Docker Swarm Cluster 搞定... Orz, 怎麼四月份這麼熱鬧? @@ 步驟一樣很簡單... 就跟在 PCHome 上面買東西一樣... 從 Marketplace 挑選: Containers > Azure Container Service..
we are working with the Docker team to extend Swarm so that a cluster can be created outside of Rancher and automatically imported into Rancher for management.
OK，官方都這樣說了... 只好等了~STEP #4, Deploy "Hello World" Service
其實，到這個步驟為止，環境就建立好了，接下來就可以真正的體驗一下，如何把你的 Application Deploy 上去。稍後我會用了大家用到爛的 WordPress 當範例，來示範整個過程。但是現在我想先展示內建的 Load Balance 功能，為了方便觀察，我先用 Tutum 提供的 Hello World 來熱身一下! 前面 STEP #2 #3 個別建立了 Local 及 Azure 兩個 Environment，這要做甚麼用? 兩個 Environment 各自獨立的兩組 infrastructure, 接下來的佈署動作你可以任意指定其中一個 environment 來執行。也就是本篇文章後面的操作你都可以任選一個地方來執行。 怎麼切換? 很簡單，右上角的 Environment 選單選完就好了...
STEP #5, Scale Out Your Service
如果你的服務要正式上線，通常 Scale Out, 設定 Load Balancer 提高服務能力，及提高可靠度都是必要的動作。到這個 Service 的頁面，Scale 的數值設定成你要的值，然後就靜靜地等 Rancher 幫你擴充 container 的數量就完成了 :D
STEP #6, In-Service Upgrade
服務上線之後，升級開始是個頭痛的問題了。這些線上服務，大概都沒辦法等你停個幾個小時升級後重新上線... 因此升級系統的程序也是件很頭痛的問題。Rancher 在這邊提供了一個不錯的功能: In-Service Upgrade (不知怎麼翻譯? 就地更新?)。 先來看看怎麼做吧，回頭再來說背後的原理... 這邊假定你的服務都是透過 Stack 的方式佈署，也就是背後都會有對應的 docker compose 設定檔。所以如何指派你的更新內容? 當然就是異動你的 docker compose 設定了。透過新的 docker compose 設定，Rancher 會替你把更新的 container 拉回來，替代你現在正在運作的服務。
- Finish Upgrade 如果升級過後，你的服務一切正常，你就可以選擇 "Finish Upgrade"，告訴 Rancher 服務升級成功。它會替你回收舊的資源，也就是前面步驟被停掉的 containers.
- Rollback 當然升級也有可能失敗，一旦失敗的話，你可以選擇 Rollback，Rancher 會立刻幫你還原成升級前的樣子 (簡單的說，就是把新的 containers 停掉並且刪除，把原有的 containers 啟動)
右上角的服務狀態，變成 "Finishing Upgrade"，而經過 user 的確認之後，原有的 containers 就變成 Removing 的狀態，Rancher 開始替你刪除回收這些資源...
一切都完成後，服務狀態又回到正常的 "Active"，原有的 container 也已被移除，如果你畫面還沒刷新，那它會標示 "Removed"，如果你重新整理畫面，就會發現原有的 containers 完全消失了。
整個 Upgrade 程序，到這裡告一段落。這是我覺得最有用的部分，因為它大大解決了日常維運最常碰到的困擾啊... 其實整個流程並不難理解，但是過去同樣的動作，我都得自己下一堆指令... 下指令不是什麼難事，難就難在只要是人就醫訂有機會犯錯... 尤其在線上運作時，這些錯誤更難以接受... 這個功能就真的幫上大忙了!
回到前面說到 upgrade 的三個重要參數，就是告訴 Rancher 該用甚麼樣的 process 來替你執行升級的過程。看過這整個程序，在回過頭來看這三個參數，大概就不難理解它的意義了吧?
- Batch Size: 批次執行的數量。以上例來說，Batch Size = 1 代表一次只處理一個 container, 整個服務 scale 設為 3，代表你有 3 個 container 要處理，一次處理一個，完成了再進行下一個...。這部分要留意，如果你很在意線上服務不能中斷的話，切記這個數值不能太大，必須小於你的 scale 數值。否則升級的過程中可能某個關鍵服務的 containers 全部被你停掉了，或是留下可運作的 containers 數量太小，無法乘載升級期間的用量..
- Batch Interval (sec): 顧名思義，批次處理過程中要間隔多久? 視你的服務需要多少時間 init 而定。
- Start Before Stopping: 新的 container 要先啟動? 還是原有的 container 要先停用? 有些服務你不希望新舊同時運作，有些服務你希望能不間斷的接軌... 是你需要而定。
Upgrade 版本上線前，沒有地方讓我先測試啊...
這點用過 Azure 的就知道我在講什麼，只能讚嘆 Microsoft Azure 的 architect 實在太厲害，在六七年前 Azure 就能推出這樣等級的服務，當年 Azure Cloud Service 就已經有 Production / Staging Environment 的設計, 不用正式上線你就可以先行測試。測試滿意後只要 switch，一瞬間就切換上線了。不滿意再 switch 就 rollback ，這動作可以不斷的重複。進化到現在，Azure WebAPP 甚至可以讓你建立多組環境，不限於 Production / Staging 這兩套... 這點對服務中斷的程度，做的比 Rancher 還要徹底... Rancher 沒做到這個地步，算是有點小遺憾... 這是美中不足的地方。 最後，補一下 Rancher 官方的說明文件 (Upgrading Services with Rancher Compose)。雖然是搭配命令列操作的說明 (不是 GUI)，不過很多參數跟觀念說明的很清楚，有興趣可以參考。