架構程式碼的實施工具
目錄
前言
前幾週向大家簡介了基礎架構即程式碼的概念與編譯方法。一個專案採用基礎架構即程式碼來實施 DevOps 流程，主要就是要達成以下的最佳實踐理念：
- 所有的虛擬機房部署與雲端服務參數配置都是在架構程式碼中設定的，直接經由部署脚本 (如 Shell Script、Puppet manifests、Ansilbe Playbooks、或Terraform Config file) 執行。部署過程中，任何人都不能登入到伺服器上做即時調整 (直接自動化）。
- 所有的雲端服務執行程序和日誌都會被紀錄下來。
- 所有的架構程式碼都可以做版本管理。
- 強調漸進式修改，不斷測試的流水線（DevOps pipeline），實現持續整合與持續交付。
- 保持服務持續可用性：越來越多的雲端服務不能承受升级或修復時的停機，因此，藍綠部署（Green-Blue Deployment）和平行變化（Parallel Change）的技術就可以幫助我們在不喪失可用性的前提下做小幅度更新。
今天我們來討論幾個在編譯架構程式碼時常使用到的工具。首先要指出的是，架構程式碼的編譯工具不勝其數，我選了三個在不同的實施模式上各有其代表性的工具：Puppet 是很傳統的主從模式（master-slave）架構。Ansible 是不需要代理人（agent）的。Terraform 則是較新一代的 IaC 工具，它比較重視程式碼所代表的雲端服務生命週期（Cloud Service Lifecycle）。
另外強調的是，這篇文章主要目的不是介紹工具的功能，而是討論它們在 DevOps 流程上的部署，以及配置的實施模式。
Puppet 簡介
Puppet 是比較傳統，但又被廣泛使用的架構程式碼編譯工具。它在 2005年就開始發行，目前的主要版本已經是 6.8。Puppet 是一個配置管理系統，它並不是用來安裝 OS 軟體，也不可以經由 Hypervisor 安裝系統映像檔（OS image）。
Puppet 是主從式架構（Master Slave architecture），所有配置的體現方式（manifests）都是存在 Master Server 上。每個伺服器節點上都會裝一個 agent。
Puppet 的架構略述如下：
- Puppet 算是「宣示式」的架構程式碼。Puppet catalog 是一個描述被部署節點最終狀態的文檔。它包括了在節點上需部署的軟體，與各模組間的相關連性。
- 每個部署節點上的 agent 會把伺服器節點的特定資訊（Facts）傳回給 Master， Master 會根據這些 Facts 去生出該節點的 catalog，再把 catalog 傳回給節點上的 agent，再由 agent 在節點上安裝軟體、配置參數。
- Agent 安裝完畢後，會把結果傳回 Master node 上的報告收集程式（Report Collector），作為審核日誌。
Puppet 的配置架構
Puppet 的配置架構，相對簡單。如圖二所示，Puppet Manifest 是用來記錄雲端服務所有節點需要安裝的程式及其次序，這也就是雲端服務的部署腳本。
根據這個 manifest，Puppet Master 會根據部署節點傳回來的 Facts，編譯出節點需要的 catalog，送到節點上的 Agent。
同理，Puppet Master 可以對多個節點上的 Agent 同時進行安裝配置，如圖三所示。然後 Puppet Collector 集中收集所有節點的安裝結果，來判斷雲端服務是否有正常啟動。
順帶一提的是 Chef。Chef 跟 Puppet 很相像，也是 Master Slave 架構，但 Chef 是比較接近於「指令式」的架構程式碼。使用者需要編譯如何在每個節點上安裝所需的程式以及參數。相對應於 Puppet 的 Catalog 與 Manifest，Chef 稱它們為 Recipe 與 Cookbook。
Ansible 簡介
Ansible 是另一個被廣泛使用的架構程式碼工具。它創始於 2012 年，目前的主要版本是 2.8。Ansible 本來也是一個配置管理系統，最大的分別是它並非 Master Slave 架構，但 是在 2015 年，Redhat 併購了 Ansible，並加入了虛擬機房部署的功能，所以 Ansible 也可以用在各個公有雲上部署虛擬主機、虛擬存儲或虛擬網路。另外，Redhat 還加了一個 Ansible Tower 模組，從中央處理分布在各地的伺服器。
Ansible 的系統架構如下：
- Ansible的部署模式不需要依靠代理程式（agent），與 Puppet 的拉取（Pull model）屬性相比，Ansible 的屬性則為推播式（Push model）。
- Ansible 不需要透過架設額外的 Master 主機來主導部署過程（除非使用 Ansible Tower)，Ansible 只需透過SSH協定，即可對遠端伺服器進行控制或部署，而這樣的設計，因為不必為所有管理節點預先安裝代理程式，因而方便了使用者。
Ansible 的系統架構如圖四：
Ansible Modules
Ansible Modules，簡單來說，就是把一組 Ansible 任務綁在一起的 script，既可以單獨呼叫，也可在 Ansible Playbook 中執行。Ansible Modules 可以分為任務套件（Task Plugin），以及函式庫套件（Library Plugins）。常用的 Ansible Modules 包括有 APT、SERVICE、COPY、GIT、DEBUG 等等，但使用者也可以客製化自己的模組。
Ansible Plugins
Ansible Plugins 是用來擴充 Ansible 核心功能（core functions）的。Ansible Plugins 和Ansible Modules 不同，Ansible Plugins 是運行在 Ansible Process 之內的。舉例來說，使用者可以寫一個插件去資料庫讀取庫存函數，或者把 Ansible output 存在另外指定的地方。
Ansible Inventory
Ansible Inventory 是用來紀錄雲端服務各個子系統（e.g. DB server, web server）的主機。因為同一個子系統的主機部署跟配置都是很相近的，所以使用者可以把 Ansible Playbook 套到同一子系統的主機組上。
Ansible Playbooks
Ansible Playbooks 就是用來告訴 Ansible 要對每一個管理節點（managed node）做些什麼事。Ansible Playbooks 是用 YAML 撰寫的，所以可讀性非常高，容易管理，或直接用來記錄要部署節點的規格，以及配置服務的參數。
Ansible 部署配置架構
當使用者要以 Ansible 來部署專案時，使用者需要把各個雲端服務子系統，例如 web server、application server、authentication server、micorservices、DB server 等等，註冊到 Ansible Inventory 之內，每個子系統組合會列出它所需要的伺服器與IP。
此外，使用者會透過 Ansible Playbook 以及 Ansible Module，對節點進行部署管理。Ansible Playbook 是Ansible 的配置、部署及編排使用的語言，用於描述某個透過遠端主機執行命令的方案，或者一組程序運作的命令集合。在基礎層面的應用上，Ansible Playbook 可以被用於管理部署到遠端伺服器的組態管理文件。而在更高層面上，Ansible Playbook 可以依序對多層式架構的伺服器執行滾動更新（Rolling Upgrade），或是將任務指派給其他主機，例如監控伺服器或平衡負載設備。
Ansible 部署架構如圖五：
Terraform 簡介
Terraform 是在 2014年，由一家新創公司 HashiCorp 所發布出來的。由於它的部署架構 與 DevOps 開發生命週期緊密結合，又與知名公有雲的 IaaS、PaaS、SaaS 都有整合，因此這幾年來，Terraform 在 DevOps 社群相當火紅，大受開發人員的歡迎。
從架構面來看，Terraform 與 Puppet 或 Ansible 相似，它仍是一個宣示式的架構程式碼編譯工具，可以高效能地部署、更新、版本化基礎設施和雲端服務，具有多層次的資源管理功能，從上層的 SaaS 配置到底層的 IaaS 配置 ，都可以使用 Terraform 統一進行管理。
Terraform 的系統架構如圖六：
Terraform Core
Terraform 架構 非常簡單。雖然 HashiCorp 沒有公開 TF core 的 詳細內容，我們知道，TF core 負責把 TF-config 讀入，與 project 的現狀（state）比較，然後查詢 Terraform 平台上 provider 的 plugin，以產生一個 Terraform Action Plan ，在相關 Provider 的伺服器上執行。
Terraform config file
每個專案會用 HCL (HashiCorp Configuration Language) 撰寫 一個 TF config file，來描述一個服務。Terraform 特別的地方，就是它支援很多很多不同的 Providers，包括了 IaaS、PaaS、utilities、SaaS。所以 TF config file 通常可以作為雲端服務的 藍圖（blueprint），也可以用來做版控。
Project State
Terraform 的另一個特色，是它會根據上次部署的紀錄日誌，把服務配置的狀態存在內部。
Providers
Terraform 支援非常多的私有雲與公有雲服務供應商（Providers），例如：
- IaaS: VMware, OpenStack, AWS, GCP, Azure, …
- PaaS: K8S, Lambda, …
- SaaS: RDBMS, MongoDB, Github, Datadog, …
Terraform 的部署配置架構
Terraform 之所以大受歡迎，是因為它的部署架構跟 DevOps 的生命週期緊密結合，部署可分為 4 個步驟：
Prepare Phase
專案開發人員用 HCL 寫一個 TF Config file，把雲端服務的所有元件紀錄下來。TF config file 也是用 YAML 定義的，所以相對簡單，可讀性也非常高。
Plan Phase
Plan phase 的目的就是讓 TF core 檢查 config file 裡面要求的 provider，是否已有註冊。假若 Provider 存在，TF core 就會依照相關的 HCL 來宣告環境，產出對應該 prvider 的 API，放到 TF Execution Plan（執行計劃）內。
另一方面，TF core 還可以將 TF config file 與當前環境做對比，只把新增或修改部份放到計劃內，因此這個執行計劃就只會列出為了達到配置文件定義狀態所需執行的操作，以達到期望的狀態。
Apply Phase
若 Plan phase 順利執行，Apply phase 就只是執行產出的TF執行計劃，對相關的 Providers 發出指令，將使用者 TF config file 所註明的虛擬機房與雲端服務給部署起來。此外，執行時的日誌與結果，也會存回到該專案的 TF state 內，當下一次專案更新時，TF core 就可以算出新增的服務元件以及應修改的參數。
Destroy Phase
Destroy phase 則是 DevOps 專案的最後， 它代表了雲端服務生命週期的結束。
圖七 是 Terraform 執行的雲端服務生命週期。
總結
本文介紹了三種基礎架構即程式碼的部署模式：
- Puppet 代表比較傳統的 master/slave 模式。所有部署的體現方式 (manifest) 與catalog 都存在 master node 上。在節點上的 agent 會向 master 要求 catalog 去部署節點伺服器。這個叫做 Pull Model（拉取模式）。
- Ansible 代表了不需要 agent 的 push model（推播模式）。部署的劇本 (Playbook) 可以存在任何地方，Ansible 會根據 Inventory 把 playbook 裡面指定的 module 推到部署節點上。
- 比較新穎的 Terraform 是利用服務供應商在 Terraform 上註冊的 API，去動態產出執行計劃；它的另一特點，是 Terraform 會把每次部署的狀態記錄下來，所以下次更新就可以做漸進式部署。
這三種架構都可以用宣示式或指令式去編譯程式碼。除了Puppet外，另外兩個工具都可以同時做虛擬機房的服務開通（Provisioning）與雲端服務的調度（Orchestration）。我預期這種模式會變成主流。
雖然 Terraform 成為最近的主流，但是 Ansible 跟 Puppet 已在業界行之有年，因此還是會看到很多企業會同時使用多種工具，例如 Terraform ＋Puppet、 Terraform + Ansible 等等。
