網管人雜誌
本文刊載於
網管人雜誌第 173 期 - 2020 年 6 月 1 日出刊，
NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。
文章目錄
前言基礎架構即程式碼 Ansible 簡介實戰 Ansible on Azure 部署內建 Ansible 的 CentOS 範本 手動為 CentOS 安裝 Ansible 執行環境 建立 Azure Credentials 透過 Ansible 部署 Azure 資源群組 透過 Ansible 部署 Azure VM 虛擬主機 透過 Ansible 部署 SQL Server 執行個體 透過 Ansible 部署 AKS（Azure Kubernetes Service）結語前言
在商業數位化的浪潮下，企業和組織如何更快速的交付產品給消費者，並且交付的產品無論在品質上或使用者體驗方面，都能有效命中消費者對於產品的想像和需求，然而這個理想目標一直以來都是個難題，而
「DevOps」這個議題，應該是目前許多企業和組織用來克服這個難題的方法了。
「DevOps」其實是個組合詞，拆分後就是指開發團隊「Dev」以及維運團隊「Ops」的組合。簡單來說，DevOps 就是整合
「人員、流程、產品」（People，Process，and Products），並且透過這樣的整合方式，持續不斷的為使用者交付有效的產品價值。
雖然，業界有許多不同的供應商提供各種工具，幫助企業和組織加速前往 DevOps 的目標，然而這也造成許多企業和組織在前往 DevOps 的道路上，變成是瞎子摸象的情況，舉例來說，有人可能認為 DevOps 就是「自動化」（Automation），或者 DevOps 就是「小型部署」（Small Deployments）……等（如圖 1 所示）。
圖 1、探索 DevOps 示意圖
事實上，DevOps 的核心精神在於
「文化」（Culture）而非各項工具鏈的整合，舉例來說，DevOps 團隊採用
「敏捷」（Agile）的方式，讓團隊採用小型批量的方式作業，專注於改善客戶端價值的端到端交付，並且努力消除開發過程中的浪費和所遭遇的障礙，團隊裡不應該有資源孤島也沒有任何互相責備，因為團隊是互相幫忙彼此負責的，即便沒有各項工具仍然能夠達成 DevOps 的目標。
基礎架構即程式碼
那麼如何讓 DevOps 團隊，能夠更專注在開發使用者需求、解決使用者遭遇的問題、交付有價值的產品給使用者，當然需要兼顧到的層面非常廣泛。在本文中，我們將會討論和實作演練，在企業和組織的基礎架構中，如何透過
「基礎架構即程式碼」（Infrastructure as Code，IaC）的方式（如圖 2 所示），加速資料中心的各項資源管理和部署作業。
圖 2、基礎架構即程式碼運作架構示意圖
過去，團隊管理人員必須維護每個不同部署環境的組態設定，一開始每個環境的差異可能非常微小，然而隨著專案時間拉長以及不同管理人員的維護方式，將會讓一開始原本相同的運作環境漸漸不同，產生環境漂移導致部署時出現各種不同的問題，影響產品交付的時間。
現在，企業和組織透過建構基礎架構即程式碼環境，將能有效管理每個部署於基礎架構上的運作環境，確保每次組態設定的步驟和執行結果都一樣，不會因為人為操作失誤導致組態設定結果不同，同時也可以克服大量部署運作環境時的困擾。
舉例來說，倘若管理人員採用傳統管理方式，組態設定「1 台」Linux 主機 DNS 名稱解析的動作，雖然可能只需要花費 10 秒鐘的時間，然而若必須組態設定「100 台」Linux 主機 DNS 名稱解析時，除了必須花費 16.67 小時的時間之外，在操作過程中很難保證不會因為人為操作失誤，導致 Linux 主機 DNS 名稱解析錯誤，進而影響後續部署服務時，因為無法正確進行 DNS 名稱解析而讓服務運作失敗的情況。此外，倘若日後必須變更 DNS 名稱解析內容時，除了必須再度花費 16.67 小時的工作時間之外，勢必過程中又有非常高的機率發生人為錯誤，導致服務無法正常運作。
當企業和組織改為採用基礎架構即程式碼的方式時，透過像程式碼的方式來管理和部署基礎架構相關資源時，再次面對上述組態設定 100 台 Linux 主機 DNS 名稱解析作業時，除了無須擔心人為操作導致錯誤之外，整個組態設定作業的工作時間也將大幅縮短。
在筆者的測試環境中，透過基礎架構即程式碼方式組態設定「100 台」Linux 主機 DNS 名稱解析作業，僅花費「80 秒」時間便完成組態設定作業。
Ansible 簡介
那麼，企業和組織應該挑選哪個工具，才能夠加速前往基礎架構即程式碼的目標 ？管理人員可以參考，由
CNCF 組織在 Cloud Native Interactive Landscape中，於
「Automation & Configuration」項目內的各項專案（如圖 3 所示），在本文中我們將採用
「Ansible」進行基礎架構即程式碼的實作演練。
圖 3、Cloud Native Interactive Landscape 中 Automation & Configuration 專案項目示意圖
實戰 Ansible on Azure
事實上，企業和組織透過 Ansible 進行基礎架構的管理和部署作業時，無論運作環境在地端資料中心或是公有雲上，都可以透過 Ansible 進行管理和部署作業。在本文實戰演練的部份，將會以 Ansible 管理 Microsoft Azure 公有雲環境上的工作負載為例。
值得注意的是，建議採用新版的
「Ansible 2.9.x」版本，目前最新釋出版本為 2020 年 4 月份的 Ansible 2.9.7 版本，才支援所有 Ansible Azure 模組功能（如圖 4 所示），舉例來說，採用
Ansible 2.8舊版本便不支援
azure_rm_batchaccount 模組，倘若使用更舊的
Ansible 2.4版本時，則連基本的
azure_rm_image模組也不支援。
有關 Ansible 各版本發行資訊，請參考 Ansible Documentation - Release and maintenance頁面資訊。
圖 4、不同 Ansible 版本針對 Microsoft Azure 公有雲環境支援程度的 Ansible Azure 模組清單
部署內建 Ansible 的 CentOS 範本
當管理人員的需求為建立「全新」的 Ansible 運作環境時，可以採用 Azure Marketplace 中由微軟官方打包，已經將 Ansible 執行環境預載完成的 CentOS 虛擬主機範本。在這個 CentOS 虛擬主機範本中，已經安裝好最新版本 Ansible 以及 Azure CLI 2.0 執行環境。
請登入 Azure Portal 管理介面，點選
「Create a resource」項目之後，在關鍵字欄位鍵入
「Ansible」即可看到 Azure Marketplace 中的 CentOS 範本，確認採用的是微軟官方打包的 CentOS 範本後，請按下
「Create」鈕準備進行部署作業（如圖 5 所示）。
圖 5、確認採用微軟官方打包的 CentOS 範本進行部署作業
在 Basic 部署頁面中，依序填入部署 CentOS 範本的 VM 虛擬主機名稱、屆時登入的管理者帳號和密碼、採用的 Azure 訂閱、部署的資源群組名稱、部署的 Azure 資料中心……等資訊。在 Additional Settings 部署頁面中，倘若管理人員希望採用特定的 Ansible 版本時，請於 Ansible version 欄位鍵入 Ansilbe 版本號碼，例如，2.9.4，或採用預設的
「latest」最新釋出版本即可（如圖 6 所示）。
圖 6、設定採用特定的 Ansible 版本或最新釋出版本
最後，在 Summary 部署頁面中，再次確認組態設定的部署資訊正確無誤後，按下 OK 鈕立即進行部署作業。當預載 Ansible 執行環境的 CentOS 虛擬主機部署完成後，即可 SSH 連線登入 CentOS 虛擬主機，並執行
「ansible --version」指令確認 Ansible 執行環境的版本資訊（如圖 7 所示）。
圖 7、確認 Ansible 執行環境的版本資訊
手動為 CentOS 安裝 Ansible 執行環境
當管理人員的需求為現有 CentOS 運作環境中，「手動」安裝 Ansible 執行環境也非常容易。首先，請確認採用的 CentOS 版本為 CentOS 7.x 或後續版本，接著在 CentOS 主機上鍵入下列 YUM 指令，執行安裝 Azure Python SDK 模組的動作。
sudo yum check-update ; sudo yum install -y gcc libffi-devel python-devel openssl-devel epel-release
sudo yum install -y python-pip python-wheel安裝完成後，可以執行
「python --version」指令確認採用的 Python 版本，在本文執行環境中可以看到 Python 版本為
2.7.5 。接著，請執行下列 pip install 指令，先將 pip 套件版本進行升級後，安裝 Ansible 套件以及 Ansible Azure 模組。
sudo pip install --upgrade pip
sudo pip install ansible[azure]當 Ansible 套件和 Ansible Azure 模組安裝完畢後，請執行
「ansible --version」指令確認 Ansible 版本，可以看到本文實作環境採用最新
Ansible 2.9.7版本（如圖 8 所示）。此外，管理人員可以執行
「pip list」指令，查看已經安裝的 Ansible 模組清單和版本資訊。
圖 8、確認在 CentOS 7 主機中安裝的 Ansible 版本資訊
建立 Azure Credentials
無論採用 Azure Marketplace 的 CentOS 範本，或者手動在 CentOS 虛擬主機中安裝 Ansible 執行環境，在管理 Microsoft Azure 公有雲環境之前，必須先組態設定
「Azure Credentials」憑證資訊，以便管理該 Azure 訂閱帳戶的公有雲基礎架構。
在組態設定 Azure Credentials 憑證資訊之前，管理人員必須準備四項
「Azure Service Principal」驗證資訊，分別是
Azure Subscription ID、Tenant ID、Client ID、Secret等資訊。
請注意，採用 Azure Service Principal 驗證資訊的主要原因，在於不應該讓屆時的 Ansible 自動化管理工具，採用「完全特權使用者」（Fully Privileged User）的身份登入，而是採用 RBAC 受限制的方式登入和管理 Azure 基礎架構和資源。
首先，請在 Azure Portal 中依序點選
「All Services > Subscriptions」，便會列出此 Azure 管理帳號所擁有的 Azure 訂閱清單，請確認要採用的
「Subscriptions ID」（如圖 9 所示）。
圖 9、查詢欲採用 Ansible 管理的 Azure Subscriptions ID
請在 Azure Portal 中，依序點選
「Azure Active Directory > Overview」，便會列出此 AAD（Azure Active Directory）環境中
「Tenant ID」資訊（如圖 10 所示）。
圖 10、查詢欲採用 Ansible 管理的 Azure Tenant ID
最後，還需要在 AAD 當中建立應用程式 ID 和產生應用程式使用的密碼，也就是 Azure Credentials 當中
Client ID和
Secret 的部份。請在 Azure Active Directory 中，依序點選
「App Registrations > Register an application」鍵入應用程式 ID 的名稱，本文實作採用的名稱為「Ansible App」並按下 Register 鈕之後，便可以看到建立 Ansible App 和「Client ID」（如圖 11 所示）。
圖 11、註冊 Ansible 應用程式並取得 Client ID
點選剛才註冊的 Ansible App 項目，然後點選 Certificates & Secrets 項目，在 Client Secrets 區塊中按下
「New Client Secret」，系統將會彈出新增 Client Secret 的描述和應用程式密碼過期時間，本文實作採用預設值
「一年」後應用程式密碼過期，然後按下 Add 鈕，系統便會自動生成 Ansible App 應用程式的
「密碼」（Secret）（如圖 12 所示）。
圖 12、產生 Ansible App 應用程式使用的密碼
倘若，管理人員覺得上述採用 Azure Portal 的方式，取得 Azure Service Principal 的方法太慢，管理人員可以採用 Azure Cloud Shell 或 Azure CLI，使用
「az account list --output table」指令，列出管理帳戶所擁有的 Azure 訂閱帳戶 ID，使用
「az ad sp create-for-rbac --name AnsibleApp」指令的方式，快速建立 Azure Service Principal（如圖 13 所示）。
建立 Azure Service Principal 結果中，「appId」欄位便是 Client IS、「password」欄位為 Secret、「tenant」欄位為 Tenant ID，並且自動採用預設一年後應用程式密碼過期。
圖 13、取得管理帳戶所擁有的 Azure 訂閱帳戶 ID 並快速建立 Azure Service Principal
準備好 Azure Credentials 的四項資訊後，便可以在 CentOS 主機上執行
「export」指令（如圖 14 所示），搭配 Azure Credentials 的四項機敏資訊，組態設定至 CentOS 主機的環境變數當中，然後透過
「env」指令再次確認是否組態設定 Azure Credentials 成功。
請注意，組態設定至 CentOS 主機環境變數中的 Azure Credentials，僅有效於該 SSH Session 。倘若，需要將 Azure Credentials 永久儲存，請建立「~/.azure/credentials」檔案，並在檔案中貼上 Azure Credentials 的四項機敏資訊。
圖 14、組態設定 Azure Credentials 的四項機敏資訊至 CentOS 主機環境變數中
透過 Ansible 部署 Azure 資源群組
現在，管理人員已經可以透過 Ansible 管理 Azure 公有雲環境，舉例來說，管理人員可以在 CentOS 主機上，建立名稱為
「create_resourcegroup.yaml」的 YAML 檔案（如圖 15 所示），內容為透過
「azure_rm_resourcegroup」這個 Ansible Azure 模組，在 Azure US East 資料中心內建立名稱為
「RG-USEast」的資源群組，並且將建立資源群組的執行結果註冊為 result 變數，然後透過 debug 模組將執行結果列印出來。
圖 15、在 Azure US East 資料中心內建立資源群組的 Playbook 檔案內容
在 CentOS 主機鍵入
「ansible-playbook create_resourcegroup.yaml」指令，透過 ansible-playbook 指令搭配撰寫好的 YAML 檔案，執行建立名稱為
「RG-USEast」的資源群組（如圖 16 所示）。
圖 16、順利透過 Ansible Playbook 執行建立資源群組的動作
透過 Ansible 部署 Azure VM 虛擬主機
順利透過 Ansible Playbook 部署資源群組後，我們可以執行部署 VM 虛擬主機的動作。首先，建立名稱為「create_vm.yaml」的 YAML 檔案，並且透過「vars」宣告後續工作任務中，經常會使用到的名稱為變數，例如，宣告「resource_group」變數名稱的值為
「RG-USEast77」，因此後續工作任務中只要使用
「"{{ resource_group }}"」，便能呼叫 resource_group 變數名稱的值帶入其中。
如圖 17 所示，在這個 Playbook 當中總共有 7 個工作任務（Tasks），並且搭配下列 7 個 Ansible Azure 模組，完成部署 VM 虛擬主機的動作。
- azure_rm_resourcegroup ：建立「Azure 資源群組」（Azure Resource Group），本文實作名稱為「RG-USEast77」。
- azure_rm_virtualnetwork ：建立「Azure 虛擬網路」（Azure Virtual Network），本文實作虛擬網路為「10.0.0.0/16」。
- azure_rm_subnet ：建立「Azure 虛擬子網路」（Azure Virtual Subnet），本文實作虛擬子網路為「10.0.1.0/24」。
- azure_rm_publicipaddress ：建立固定制「Azure 公有 IP 位址」（Azure Public IP Address），以便稍後指派給 VM 虛擬主機。
- azure_rm_securitygroup ：建立「Azure 網路安全群組」（Azure Network Security Group），允許 SSH（Port 22）網路流量通過防火牆。
- azure_rm_networkinterface ：建立 Azure 虛擬網路介面卡，以便稍後部署 VM 虛擬主機時指派給 VM 虛擬主機使用。
- azure_rm_virtualmachine ：建立 VM 虛擬主機並設定規模大小、管理者帳號和密碼、並採用 CentOS 7.7 映像檔，最後部署作業完成後啟動 VM 虛擬主機。
圖 17、查看 create_vm.yaml 的 YAML 檔案內容
YAML 檔案編寫完畢後，鍵入
「ansible-playbook create_vm.yaml」指令（如圖 18 所示），部署名稱為
「RG-USEast77」的資源群組在
「Azure East US」資料中心內，VM 虛擬主機名稱為
「ansiblevm77」並且規模大小為
「Standard_DS1_v2」。
圖 18、透過 Ansible Playbook 部署 Azure VM 虛擬主機
透過 Ansible 部署 SQL Server 執行個體
接著，實作透過 Ansible Playbook 部署 SQL Server 執行個體並建立資料庫。首先，建立名稱為
「create_sql_server.yaml」的 YAML 檔案，並且透過「vars」宣告後續工作任務中，經常會使用到的名稱為變數，例如，宣告「sqlserver_name」變數名稱的值為
「ansiblesql12」，因此後續工作任務中只要使用
「"{{ sqlserver_name }}"」，便能呼叫 sqlserver_name 變數名稱，將 SQL Server 名稱帶入其中。
如圖 19 所示，在這個 Playbook 當中總共有 3 個工作任務（Tasks），並且搭配下列 3 個 Ansible Azure 模組，完成部署 SQL Server 執行個體的動作。
- azure_rm_resourcegroup ：建立 Azure 資源群組，本文實作名稱為「RG-USEast12」。
- azure_rm_sqlserver ：建立 Azure SQL Server 執行個體，本文實作名稱為「ansiblesql12」。
- azure_rm_sqldatabase ：在 Azure SQL Server 執行個體中建立 SQL 資料庫，本文實作名稱為「sqldb」。
圖 19、查看 create_sql_server.yaml 的 YAML 檔案內容
YAML 檔案編寫完畢後，鍵入
「ansible-playbook create_sql_server.yaml」指令（如圖 20 所示），部署名稱為
「RG-USEast12」的資源群組在
「Azure East US」資料中心內，SQL Server 執行個體名稱為
「ansiblesql12」採用的版本為
「12.0」，並在 SQL Server 執行個體中建立名稱為
「sqldb」的資料庫。
預設情況下，部署的 SQL Server 執行個體規模為「General Purpose : Gen5」等級，並採用「2 vCores」和「32 GB」資料庫空間的初始預設值，但是管理人員後續可以依據工作負載需求，調整規模大小為最大 vCores「80」、最大 Memory 為「408 GB」、最大化資料庫空間「4 TB」。
圖 20、透過 Ansible Playbook 部署 SQL Server 執行個體
當然，部署 SQL Server 執行個體的工作任務完成，管理人員也可以登入 Azure Portal 管理介面，依序點選
「RG-USEast12 > ansiblesql12 > Properties」項目，查看 SQL Server 執行個體的運作環境資訊（如圖 21 所示）。
圖 21、查看 SQL Server 執行個體的運作環境資訊
透過 Ansible 部署 AKS（Azure Kubernetes Service）
實作演練透過 Ansible Playbook 機制，部署
AKS（Azure Kubernetes Service）容器管理平台。值得注意的是，在部署 AKS 容器管理平台之前，應該先確認部署的 Azure 資料中心，支援運作哪些 Kubernetes 版本，避免稍後部署作業因指定錯誤的版本導致不可預期的錯誤。管理人員可以在 Cloud Shell 或 Azure CLI 中，鍵入
「az aks get-versions --location eastus --output table」指令（如圖 22 所示），查詢 Azure East US 資料中心，支援運作哪些 Kubernetes 版本。
圖 22、查詢 Azure East US 資料中心支援運作哪些 Kubernetes 版本
建立名稱為
「create_aks_cluster.yaml」的 YAML 檔案，並且透過「vars」宣告後續工作任務中，經常會使用到的名稱為變數，例如，宣告「aks_version」變數名稱的值為
「1.16.7」，因此後續工作任務中只要使用
「"{{ aks_version }}"」，便能呼叫 aks_version 變數名稱，將指定採用的 Kubernetes 版本號碼帶入其中。
如圖 23 所示，在這個 Playbook 當中總共有 2 個工作任務（Tasks），並且搭配下列 2 個 Ansible Azure 模組，完成部署 AKS 容器管理平台的動作。
- azure_rm_resourcegroup ：建立 Azure 資源群組，本文實作名稱為「RG-USEast-AKS1167」。
- azure_rm_aks ：部署 AKS 容器管理平台，本文實作名稱為「ansibleaks1167」，並且建立初始運作 AKS 容器管理平台的成員節點主機共「2 台」。
當後續需要「擴充」AKS 容器管理平台成員節點主機的數量時，只需要將 Playbook 當中建立 Azure 資源群組的工作任務移除，並且調整「count :」參數值即可，例如，「count :5」即表示總共會有「5 台」成員節點主機，負載承載 AKS 容器管理平台的工作任務。
圖 23、查看 create_aks_cluster.yaml 的 YAML 檔案內容
YAML 檔案編寫完畢後，鍵入
「ansible-playbook create_aks_cluster.yaml」指令，透過 Ansible Playbook 機制部署 AKS 容器管理平台（如圖 24 所示），部署名稱為
「RG-USEast-AKS1167」的資源群組在
「Azure East US」資料中心內，AKS 容器管理平台名稱為
「ansibleaks1167」，採用的 Kubernetes 版本為
「1.16.7」，並且建立
「2 台」成員節點主機運作 AKS 容器管理平台。
圖 24、透過 Ansible Playbook 部署 AKS 容器管理平台
當部署 AKS 容器管理平台的工作任務完成後，管理人員可以在 Cloud Shell 或 Azure CLI 當中，透過建立 AKS 容器管理平台的驗證資訊，然後執行
「kubectl get nodes」指令，列出目前 AKS 容器管理平台的成員節點主機資訊。如圖 25 所示，可以看到共有 2 台成員節點主機，採用的 Kubernetes 版本為指定的 1.16.7 。
圖 25、透過指令查詢 AKS 容器管理平台的成員節點主機資訊
當然，管理人員也可以登入 Azure Portal，依序點選
「RG-USEast-AKS1167 > ansibleaks1167 > Node pools」項目，AKS 容器管理平台的成員節點主機的運作環境資訊（如圖 26 所示）。
圖 26、查看 AKS 容器管理平台的成員節點主機的運作環境資訊
結語
透過本文的深入剖析和實戰演練，相信讀者已經了解 DevOps 和 IaC 基礎架構即程式碼的基本概念，同時我們可以透過 Ansible 這個簡單易懂卻又強大的工具，幫助企業和組織的 IT 管理人員，有效管理地端資料中心或者公有雲基礎架構。
此外，本文實戰演練的每個 Playbook（YAML 檔案），都公開存放在筆者的
GitHub Ansible Repo當中，有興趣的讀者可以隨時下載進行測試，體驗 Ansible Playbook 如何簡化部署和組態設定作業。
