透過「基礎架構即程式碼」可加速資料中心的各項資源管理和部署作業，本文以「Ansible」工具進行實作。無論運作環境在地端資料中心或是公有雲上，都可以透過Ansible進行管理與部署。本次實戰演練將以Ansible來管理Microsoft Azure公有雲環境上的工作負載。
在商業數位化的浪潮下，企業組織如何更快速地交付產品給消費者，並且交付的產品無論在品質上或使用者體驗方面，都能有效命中消費者對於產品的想像和需求，然而這個理想目標一直以來都是個難題，而「DevOps」這個議題，應該是目前許多企業組織用來克服這個難題的方法了。
「DevOps」其實是個組合詞，拆分後就是指開發團隊「Dev」以及維運團隊「Ops」的組合。簡單來說，DevOps就是整合「人員」（People）、「流程」（Process）以及「產品」（Products），並且透過這樣的整合方式，持續不斷地為使用者交付有效的產品價值。
雖然業界有許多不同的供應商提供各種工具，幫助企業加速前往DevOps的目標，然而這也造成許多企業組織在前往DevOps的道路上，變成是瞎子摸象的情況，舉例來說，有人可能認為DevOps就是「自動化」（Automation），或者DevOps就是「小型部署」（Small Deployments）等等，如圖1所示。
圖1 探索DevOps示意圖。 （圖片來源：Microsoft Channel 9 - DevOps Fundamentals - Introduction to DevOps）
事實上，DevOps的核心精神在於「文化」（Culture）而非各項工具鏈的整合。舉例來說，DevOps團隊採用「敏捷」（Agile）的方式，讓團隊採用小型批量的方式作業，專注於改善客戶端價值的端到端交付，並且努力消除開發過程中的浪費和所遭遇的障礙，團隊裡不應該有資源孤島，也沒有任何互相責備，因為團隊是互相幫忙彼此負責的，即便沒有各項工具，仍然能夠達成DevOps的目標。
認識基礎架構即程式碼
那麼如何讓DevOps團隊能夠更專注在開發使用者需求、解決使用者遭遇的問題、交付有價值的產品給使用者，當然需要兼顧到的層面非常廣泛。本文將會討論和實作演練，在企業組織的基礎架構中，如何透過「基礎架構即程式碼」（Infrastructure as Code，IaC）的方式，加速資料中心的各項資源管理和部署作業，如圖2所示。
圖2 基礎架構即程式碼運作架構示意圖。 （圖片來源：Cisco Blogs - Tune in: "Demystifying Cisco Orchestration for Infrastructure as Code"）
過去，團隊管理人員必須維護每個不同部署環境的組態設定，一開始，每個環境的差異可能非常微小，然而隨著專案時間拉長以及不同管理人員的維護方式，將會讓原先相同的運作環境漸漸不同，而產生環境漂移，導致部署時出現各種不同的問題，影響產品交付的時間。
現在，企業透過建構基礎架構即程式碼環境，將能有效地管理每個部署於基礎架構上的運作環境，確保每次組態設定的步驟和執行結果都一樣，不會因為人為操作失誤而導致組態設定結果不同，同時也可以克服大量部署運作環境時的困擾。
舉例而言，倘若管理人員採用傳統管理方式，組態設定「1台」Linux主機DNS名稱解析的動作，雖然可能只需要花費10秒鐘的時間，然而若必須組態設定「100台」Linux主機DNS名稱解析時，除了必須花費16.67小時的時間之外，在操作過程中很難保證不會因為人為操作失誤，導致Linux主機DNS名稱解析錯誤，進而影響後續部署服務時，因為無法正確進行DNS名稱解析而讓服務運作失敗的情況。此外，如果日後必須變更DNS名稱解析內容，除了必須再度花費16.67小時的工作時間外，勢必過程中又有非常高的機率發生人為錯誤，導致服務無法正常運作。
當企業改為採用基礎架構即程式碼的方式，透過程式碼的方式來管理及部署基礎架構相關資源，再次面對上述組態設定100台Linux主機DNS名稱解析作業時，除了無須擔心人為操作導致錯誤外，整個組態設定作業的工作時間也將大幅縮短。
那麼企業應該挑選哪一個工具才能夠加速前往基礎架構即程式碼的目標？管理人員可以參考由CNCF組織在Cloud Native Interactive Landscape中，於「Automation & Configuration」項目內的各項專案，如圖3所示，在本文中將採用「Ansible」進行基礎架構即程式碼的實作演練。
圖3 Cloud Native Interactive Landscape中Automation & Configuration專案項目示意圖。 （圖片來源：CNCF Cloud Native Interactive Landscape）
實戰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模組也不支援。
圖4 不同Ansible版本針對Microsoft Azure公有雲環境支援程度的Ansible Azure模組清單。 （圖片來源：Microsoft Docs - Ansible module and version matrix for 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 pyt hon-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 Portal中依序點選「All Services > Subscriptions」，便會列出此Azure管理帳號所擁有的Azure訂閱清單，確認所要採用的「Subscriptions ID」，如圖9所示。然後，在Azure Portal中依序點選「Azure Active Directory > Overview」，便會列出此AAD（Azure Active Directory）環境中的「Tenant ID」資訊，如圖10所示。
圖9 查詢欲採用Ansible管理的Azure Subscriptions ID。
圖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所示。
圖13 取得管理帳戶所擁有的Azure訂閱帳戶ID，並快速建立Azure Service Principal。
準備好Azure Credentials的四項資訊之後，便可以在CentOS主機上執行「export」指令，如圖14所示，搭配Azure Credentials的四項機敏資訊，組態設定至CentOS主機的環境變數內，然後透過「env」指令再次確認是否組態成功設定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虛擬主機的動作：
圖17 查看create_vm.yaml的YAML檔案內容。
‧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虛擬主機。
YAML檔案編寫完成後，執行「ansible-playbook create_vm.yaml」指令，如圖18所示，在「Azure East US」資料中心內部署名稱為「RG-USEast77」的資源群組，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執行個體的動作。
圖19 查看create_sql_server.yaml的YAML檔案內容。
‧azure_rm_resourcegroup：建立Azure資源群組，本文實作名稱為「RG-USEast12」
‧azure_rm_sqlserver：建立Azure SQL Server執行個體，本文實作名稱為「ansiblesql12」。
‧azure_rm_sqldatabase：在Azure SQL Server執行個體中建立SQL資料庫，本文實作名稱為「sqldb」。
YAML檔案編寫完成後，鍵入「ansible-playbook create_sql_server.yaml」指令，如圖20所示，部署名稱為「RG-USEast12」的資源群組到「Azure East US」資料中心內，SQL Server執行個體名稱是「ansiblesql12」，採用的版本為「12.0」，並在SQL Server執行個體中建立名稱為「sqldb」的資料庫。
圖20 透過Ansible Playbook部署SQL Server執行個體。
當然，部署SQL Server執行個體的工作任務完成，管理人員也可以登入Azure Portal管理介面，依序點選「RG-USEast12 > ansiblesql12 > Properties」項目，查看SQL Server執行個體的運作環境資訊，如圖21所示。
圖21 查看SQL Server執行個體的運作環境資訊。
透過Ansible部署AKS容器管理平台
接下來，實作演練透過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版本。隨後，建立名稱為「create_aks_cluster.yaml」的YAML檔案，並且透過「vars」宣告後續工作任務中經常會使用到的名稱為變數，例如宣告「aks_version」變數名稱的值為「1.16.7」，因此後續工作任務中只要使用「"{{ aks_version }}"」，便能呼叫aks_version變數名稱，將指定採用的Kubernetes版本號碼帶入其中。如圖23所示，在這個Playbook當中總共有2個工作任務（Tasks），並且搭配下列2個Ansible Azure模組，完成部署AKS容器管理平台的動作。
圖22 查詢Azure East US資料中心支援運作哪些Kubernetes版本。
圖23 查看create_aks_cluster.yaml的YAML檔案內容。
‧azure_rm_resourcegroup：建立Azure資源群組，實作名稱為「RG-USEast-AKS1167」
‧azure_rm_aks：部署AKS容器管理平台，本文實作名稱為「ansibleaks1167」，並且建立初始運作AKS容器管理平台的成員節點主機共「2台」。
待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（https://github.com/Weithenn/ansible），有興趣的讀者可以隨時下載進行測試，體驗Ansible Playbook如何簡化部署和組態設定作業。
＜本文作者：王偉任，Microsoft MVP及VMware vExpert。早期主要研究Linux/FreeBSD各項整合應用，目前則專注於Microsoft及VMware虛擬化技術及混合雲運作架構，部落格weithenn.org。＞