對於基礎架構管理不熟悉非IT領域的相關人員來說，若能夠找到更方便的方式讓他們操作Ansible，將可以降低IT管理人員的負擔，而解決方案便是本文所要談論及實作演練的Ansible AWX，本文將以Ansible AWX管理Microsoft Azure公有雲環境工作負載為例進行操作示範。
在網管人第173期的「化解敏捷開發難題，Ansible輕鬆管理雲負載」技術專欄中，已經從DevOps文化和IaC基礎架構即程式碼的角度，討論企業和組織在商業數位化的浪潮下，如何更快速地交付產品給消費者，同時交付後的產品在品質或使用者體驗方面，都能命中消費者對於產品的想像和需求。
事實上，對於IT管理人員來說，透過Ansible Engine指令模式來管理資料中心的資源可能駕輕就熟。然而，對於基礎架構管理不熟悉的非IT領域相關人員來說，是否有更方便的方式讓他們操作Ansible，以降低IT管理人員的負擔。
舉例來說，負責韌體開發的人員雖然使用Linux作業系統作為研發測試環境，然而並不熟悉Linux作業系統方面的管理事務，因此發生任何狀況時，例如DNS伺服器組態設定錯誤，便需要請求IT管理人員的支援。
雖然IT管理人員可以透過撰寫好的Ansible Playbook快速協助韌體開發人員排除問題，但這也會中斷IT管理人員原本正在執行的工作任務。那麼是否有更簡便的方式，可讓韌體開發人員透過已經撰寫好的Ansible Playbook自行修正這種小型且常見的問題嗎？解決方案便是本文所要談論和實作演練的Ansible AWX。
Ansible AWX簡介
事實上，Ansible AWX是源自於Red Hat Ansible Tower商業產品的「上游項目」（Upstream Project），如圖1所示。簡而之，對於熟悉Red Hat產品的IT管理人員來說，Ansible Tower和Ansible AWX之間的關係，就如同商業產品的Red Hat Enterprise Linux和開放源始碼Fedora的關係一樣。
圖1 Ansible Tower運作架構示意圖。（圖片來源：Red Hat Sysadmin Blog - An introduction to Ansible Tower）
企業在建立Ansible AWX之後，可以直接參考Red Hat Ansible Tower技術文件。舉例來說，Ansible AWX支援RESTful API，那麼管理人員便可以直接參考Ansible Tower的API Reference Guide文件內容。
實戰Ansible AWX on Azure
在本文實戰演練部分，將以Ansible AWX管理Microsoft Azure公有雲環境工作負載為例。建議管理人員採用2019年10月份釋出的Ansible 2.9或後續版本，以確保Ansible當中的Azure模組支援性最佳。
此外，有關Ansible各版本發行資訊，可參考Ansible Documentation - Release and maintenance頁面資訊。
部署內含Ansible Tower的RHEL虛擬主機
在Azure Marketplace中，當管理人員嘗試採用「Ansible AWX」關鍵字搜尋時，將發現僅有TechLatest和Websoft9這兩家廠商提供內建Ansible AWX的CentOS或Ubuntu虛擬主機範本，而Red Hat官方則僅提供商用授權版本的Ansible Tower。
然而，TechLatest和Websoft9這兩家廠商所提供的Ansible AWX範本，除了並非由微軟官方或Red Hat官方打包之外，建立後的Ansible AWX其運行版本也是老舊的「9.x」版本，而非目前最新釋出的「Ansible AWX 12.0.0」版本。因此，在Azure Marketplace實作上將以部署Red Hat官方打包的Ansible Tower為例。
登入Azure Portal管理介面後，點選「Create a resource」項目，在關鍵字欄位鍵入「Ansible Tower」，就會看到由Red Hat官方打包的Ansible Tower範本，按下〔Create〕按鈕準備進行部署作業，如圖2所示。
圖2 確認採用Red Hat官方打包的Ansible Tower範本進行部署作業。
在Basic部署頁面中，依序填入部署Ansible Tower範本的VM虛擬主機管理者帳號、SSH加密公開金鑰、用於此次部署作業的Azure訂閱帳戶、部署的資源群組名稱、部署的Azure資料中心等等資訊，如圖3所示。預設Ansible Tower範本的VM虛擬主機管理者帳號為「toweradmin」。
圖3 填入部署Ansible Tower範本的基本資訊。
在Infrastructure Settings部署頁面中，為組態設定Ansible Tower範本的VM虛擬主機名稱，並選擇運行Ansible Tower範本VM虛擬主機的規模大小，本文實作採用「Standard DS3 v2」運作規模，屆時部署的Ansible Tower範本VM虛擬主機，將具備4 vCPU和14GB記憶體的運算資源，如圖4所示。
圖4 組態設定Ansible Tower範本VM虛擬主機名稱和規模大小。
接著，在Ansible Tower Settings部署頁面中，組態設定屆時登入Ansible Tower圖形管理介面的密碼，以及用於管理Ansible Tower資料庫的密碼，如圖5所示。
圖5 組態設定Ansible Tower圖形管理介面和資料庫管理密碼。
最後，在Summary部署頁面中，再次確認組態設定Ansible Tower的部署資訊，若正確無誤，則按下〔OK〕按鈕和〔Create〕按鈕，之後系統會立即進行部署作業。
在Ansible Tower部署任務完成後，即可搭配SSH私密金鑰登入Ansible Tower範本主機，將會看到Ansible Tower範本採用RHEL Server 7.8作業系統版本，搭配最新Ansible 2.9.9和Python 2.7.5版本的運作環境，如圖6所示。本次部署Ansible Tower範本的工作任務執行時間為16分鐘。
圖6 確認Ansible Tower範本運作環境的相關版本資訊。
接著，登入Ansible Tower圖形管理介面，如圖7所示，預設的管理帳號為「admin」，而管理者密碼則是剛才部署時於Ansible Tower Settings部署頁面所設定的管理者密碼。在順利登入Ansible Tower圖形管理介面後，即可變更「admin」預設管理者帳號名稱。
圖7 登入Ansible Tower圖形管理介面。
值得注意的是，雖然順利部署Ansible Tower範本主機，企業組織必須取得Red Hat官方提供的Ansible Tower商業授權後才能夠順利使用，當然Red Hat官方也提供「60天」管理「100台主機」的試用金鑰，以便企業和組織評估建構Ansible Tower的可行性。
在Tower License頁面中，管理人員可以按下〔REQUEST LICENSE〕按鈕取得Ansible Tower試用金鑰，倘若是已經具備Red Hat訂閱帳戶的管理人員，則鍵入Red Hat帳號和密碼並按下〔GET LICENSES〕按鈕即可，如圖8所示。
圖8 取得Ansible Tower試用金鑰。
順利取得Ansible Tower試用金鑰後，預設便會進入Ansible Tower Dashboard儀表板頁面，如圖9所示。此時，管理人員便可點選左側的「Access > Users」項目，將預設的「admin」管理帳號名稱修改為企業慣用的系統管理帳號。後續倘若需要新增或變更Ansible Tower管理帳號和密碼，也是採用相同的組態設定程序。
圖9 Ansible Tower圖形管理介面儀表板。
手動為CentOS安裝Ansible AWX執行環境
由於Python官方已經正式宣佈，舊版的Python 2.x將於2020年1月停止支援，所以本文實作環境採用新版CentOS 8.1作業系統版本，搭配預設採用的Python 3.x版本，來建構Ansible AWX運作環境。
事實上，Python 2.0早在2000年時就發佈，並且在2008年時Python官方便正式宣佈將於2015年停止支援和更新Python 2，然而許多人並未升級至新版Python 3.0，所以Python官方針對Python 2.0版本的最後延長期限，便是2020年1月正式停止支援和更新Python 2.x版本。
由於本次採用新版CentOS 8作業系統，因此安裝套件的管理指令從過去的YUM改為新推出的DNF指令，來執行安裝相關套件和Azure Python SDK模組的動作：
sudo dnf -y update sudo dnf -y install -y gcc gcc- c++ python3 python3-pip python3- devel epel-release ansible sudo alternatives --set python / usr/bin/python3
安裝完成後，執行「python --version」指令確認採用的Python版本，在本文執行環境中可以看到為Python 3.6.8版本。 接著執行「ansible --version」指令確認Ansible Engine版本，將會看到最新的Ansible 2.9.9版本，如圖10所示。
圖10 確認在CentOS 8主機中安裝完成的Python和Ansible版本資訊。
由於Ansible AWX已經將整體運作環境容器化，為CentOS 8主機安裝Docker-CE和Docker-Compose容器執行環境。值得注意的是，針對最後一版的Docker-CE 19.03.9-3版本，管理人員必須先幫CentOS 8主機安裝Containerd，否則會因為套件相依性的關係導致Docker-CE 19.03.9-3安裝失敗。
當容器執行環境安裝完成之後，再鍵入「docker-compose version」指令，將可確認採用的Docker-Compose和docker-py版本，如圖11所示。
圖11 確認採用的Docker-Compose和docker-py版本。
現在可以執行「git clone --depth 50 https://github.com/ansible/awx.git」指令，從Github下載Ansible AWX專案。完成下載作業之後，查看「awx/VERSION」檔案內容，就會看到稍後部署的Ansible AWX版本是2020年6月最新釋出的「12.0.0」版本，如圖12所示。
圖12 下載Ansible AWX專案並確認採用版本。
管理人員只要修改「awx/installer/inventory」檔案內容，將要部署的Ansible AWX預設組態設定值，調整為適合企業和組織的運作環境即可。舉例來說，預設Ansible AWX的管理帳號名稱為「admin」，倘若需要修改，則調整「admin_user」欄位值，而管理者密碼預設值為「password」，也只需要調整「admin_password」欄位值即可。修改完成後，便可執行「ansible-playbook -i inventory install.yml -vvv」指令，進行部署Ansible AWX的工作任務。
在部署Ansible AWX工作階段中，管理人員會發現「Task – local_docker : Start the containers」停留較長時間，原因在於系統必須下載Ansible AWX相關容器映像檔並啟動容器所致。
順利部署Ansible AWX之後，透過「docker-compose ps」指令查看運作Ansible AWX的主要運作元件，可以看到總共透過Docker-Compose啟動「4個容器」和容器版本，如圖13所示。
圖13 順利部署Ansible AWX並查看主要運作元件。
現在，管理人員可以開啟瀏覽器鍵入Ansible AWX網址，本文實作環境網址為「awx.lab.weithenn.org」，可以看到Ansible AWX圖形管理介面的登入畫面，如圖14所示，與剛才Ansible Tower圖形管理介面非常相似。管理人員只要鍵入方才在「inventory」檔案內指定的Ansible AWX管理者帳號和密碼即可登入。
圖14 Ansible AWX圖形管理介面登入畫面。
順利通過Ansible AWX使用者身分驗證機制後，預設會進入Ansible AWX Dashboard儀表板頁面，如圖15所示，可以看到與剛才Ansible Tower圖形管理介面非常相似。同樣地，管理人員可以點選左側的「Access > Users」項目，新增、修改或刪除在Ansible AWX系統中使用者帳號和密碼資訊。
圖15 Ansible AWX圖形管理介面儀表板。
建立Azure Credentials
無論採用Azure Marketplace的Ansible Tower範本，或者手動在地端資料中心CentOS 8主機內建構Ansible AWX運作環境，在管理Microsoft Azure公有雲環境之前，都必須先組態設定「Azure Credentials」憑證資訊，以便管理Microsoft Azure訂閱帳戶的公有雲基礎架構和相關資源。
組態設定Azure Credentials憑證資訊之前，必須準備「Azure Service Principal」驗證資訊，分別是Azure Subscription ID、Tenant ID、Client ID、Secret等四項驗證資訊。
採用Azure Service Principal驗證資訊的主要原因，在於不應讓屆時的Ansible AWX自動化管理工具，採用「完全特權使用者」（Fully Privileged User）的身分登入，而是改採RBAC受限制方式登入和管理Azure基礎架構及資源。
原則上，管理人員可以透過Azure Portal逐一查詢四項Azure Service Principal資訊。在本文實作中，則採用Azure Cloud Shell環境並執行「az account list --output table」指令，先列出企業組織擁有的Azure訂閱帳戶ID，接著使用「az ad sp create-for-rbac --name AnsibleAWXapp」指令，快速建立Azure Service Principal驗證資訊，如圖16所示。
圖16 透過Azure Cloud Shell快速建立Azure Service Principal驗證資訊。
準備好Azure Credentials驗證資訊後，登入Ansible AWX管理介面，依序點選「Resources > Credentials > Create a new credential」項目，再選擇Credential Type為「Microsoft Azure Resource Manager」，然後依序填入Azure訂閱帳戶ID和四項Azure Credentials驗證資訊，如圖17所示。當管理人員按下〔SAVE〕按鈕後，可以看到Ansible AWX自動將機敏資訊，包括Azure訂閱帳戶的密碼和Client Secret欄位，在儲存至Ansible AWX資料庫時進行額外的加密處理。
圖17 組態設定Azure Credentials驗證資訊至Ansible AWX自動化管理平台。
啟動Ansible AWX同步GitHub Repository
在開始執行部署作業之前，必須讓Ansible AWX自動化管理平台知道Playbook的存放路徑在哪裡。在本文實作環境中，已經將相關Playbook存放於GitHub內，只要開啟Ansible AWX透過Git與指定的GitHub進行同步即可。
先登入Ansible AWX管理介面，再依序點選「Resources > Projects > Create a new project」項目，接著選擇SCM Type為「Git」，並在SCM URL填入GitHub Repository URL位址，本文實作為「https://github.com/Weithenn/ansible.git」，如圖18所示。
圖18 啟動Ansible AWX同步指定的GitHub Repository。
當管理人員按下〔SAVE〕按鈕後，Ansible AWX將會自動透過Git與剛才所指定的GitHub Repository進行溝通，確保Ansible AWX能夠順利同步指定的GitHub Repository。
部署Azure VM虛擬主機（IaaS）
現在管理人員可以透過Ansible AWX自動化管理平台，搭配剛才透過Git同步的GitHub Repository並選擇採用的Playbook，即可執行部署作業。首先，將在Azure公有雲環境中，部署VM虛擬主機達到管理「基礎設施即服務」（Infrastructure as a Service，IaaS）的目的。
本文實作環境採用「create_vm_with_password.yaml」的YAML檔案，並透過「vars」宣告後續工作任務中經常會使用到的名稱為變數。舉例來說，宣告「resource_group」變數名稱的值為「RG-USEast77」，後續在Playbook工作任務中只要使用「"{{ resource_group }}"」，便能呼叫resource_group變數名稱的值帶入其中。
在這個Playbook內共有七個工作任務（Tasks），同時搭配下列不同用途的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虛擬主機使用。
‧azure_rm_virtualmachine：部署VM虛擬主機並指定運作規模大小、管理者帳號和密碼、採用CentOS 7.7映像檔，並在部署作業完成後啟動VM虛擬主機。
登入Ansible AWX管理介面後，依序點選「Resources > Templates > Create a new Job Template」項目，然後在Playbook欄位選擇「Azure/create_vm_with_password.yaml」，而Credentials欄位選擇剛才組態設定的「Azure Credentials」，如圖19所示。
圖19 在Ansible AWX中建立部署Azure VM虛擬主機的工作任務。
在Ansible AWX自動化管理平台中，執行Playbook非常容易，只要在Templates頁面點選欲執行的Playbook旁的「火箭」圖示，Ansible AWX便立即執行部署Azure VM虛擬主機的動作，如圖20所示。經過幾分鐘後，順利地在Azure公有雲環境中部署名稱為「RG-USEast77」的資源群組於「Azure East US」資料中心內，部署的VM虛擬主機名稱是「ansiblevm77」且規模大小為「Standard_DS1_v2」。
圖20 透過Ansible AWX部署Azure VM虛擬主機。
動手部署SQL Server執行個體（PaaS）
接著，實作演練透過Ansible AWX在Azure公有雲環境中，部署SQL Server執行個體並建立資料庫，以達到「平台即服務」（Platform as a Service，PaaS）的目的。
本次採用「create_sql_server_instance.yaml」的YAML檔案，並透過「vars」宣告後續工作任務中經常會使用到的名稱為變數。例如，宣告「sqlserver_name」變數名稱的值為「ansiblesql12」，後續工作任務中只要使用「"{{ sqlserver_name }}"」，便會呼叫sqlserver_name變數名稱，並將指定的SQL Server名稱帶入其中。
在這個Playbook當中總共有三個工作任務（Tasks），並且搭配下列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」。
在Ansible AWX管理介面中，點選「Create a new Job Template」項目，於Playbook欄位選擇「Azure/create_sql_server_instance.yaml」，而Credentials欄位選擇先前組態設定的「Azure Credentials」，如圖21所示。
圖21 在Ansible AWX中建立部署SQL Server執行個體的工作任務。
接著，在Ansible AWX自動化管理平台中，於Templates頁面點選「Deploy Azure SQL Server Instance（PaaS）」工作任務旁的「火箭」圖示，Ansible AWX便立即執行部署SQL Server執行個體的動作，如圖22所示。經過幾分鐘後，將在Azure公有雲環境中，部署名稱為「RG-USEast12」資源群組於「Azure East US」資料中心內，SQL Server執行個體名稱為「ansiblesql12」採用的版本是「12.0」，並在SQL Server執行個體中建立名稱為「sqldb」的資料庫。
圖22 透過Ansible AWX部署SQL Server執行個體。
部署Kubernetes Cluster（CaaS）
實作演練透過Ansible AWX在Azure公有雲環境中，部署AKS（Azure Kubernetes Service）容器管理平台，達到「容器即服務」（Containers as a Service，CaaS）的目的。值得注意的是，在部署AKS容器平台之前，必須先確認欲部署的Azure資料中心支援運作哪些Kubernetes版本，避免因指定錯誤的Kubernetes版本導致不可預期的錯誤。
管理人員可以透過Azure Cloud Shell鍵入「az aks get-versions --location eastus --output table」指令，來快速查詢Azure East US資料中心，支援運作哪些Kubernetes版本，如圖23所示。稍後，將部署最新穩定版本「1.16.9」。
圖23 查詢Azure East US資料中心支援運作哪些Kubernetes版本。
然後，採用「create_aks_cluster.yaml」的YAML檔案，並透過「vars」宣告後續工作任務中，經常會使用到的名稱為變數，舉例來說，宣告「aks_version」變數名稱的值為「1.16.9」，後續工作任務中只要使用「"{{ aks_version }}"」，便能呼叫aks_version變數名稱，採用指定的Kubernetes版本號碼。
這個Playbook當中共有兩個工作任務（Tasks），並且搭配下列Ansible Azure模組，完成部署AKS容器管理平台的動作：
‧azure_rm_resourcegroup：部署Azure資源群組，本文實作名稱為「RG-USEast-AKS1169」。
‧azure_rm_aks：部署AKS容器管理平台，本文實作名稱為「ansibleaks1169」，並且建立初始運作AKS容器管理平台的成員節點主機共「2台」。
在Ansible AWX管理介面中，點選「Create a new Job Template」項目，於Playbook欄位選擇「Azure/create_aks_cluster.yaml」，而Credentials欄位選擇先前組態設定的「Azure Credentials」，如圖24所示。
圖24 在Ansible AWX中建立部署Azure AKS容器服務的工作任務。
隨後，在Ansible AWX自動化管理平台中，於Templates頁面點選「Deploy Azure AKS（CaaS）」工作任務旁的「火箭」圖示，Ansible AWX便立即執行部署Azure AKS容器服務的動作，如圖25所示。經過幾分鐘後，順利在Azure公有雲環境中，部署名稱為「RG-USEast-AKS1169」資源群組到「Azure East US」資料中心內，AKS容器管理平台名稱為「ansibleaks1169」，採用的Kubernetes版本為「1.16.9」，並建立「2台」成員節點主機運作AKS容器管理平台。
圖25 透過Ansible AWX部署AKS容器管理平台。
完成部署AKS容器管理平台的工作任務後，可以透過Azure Cloud Shell來建立AKS容器管理平台驗證資訊，然後執行「kubectl get nodes」指令，列出目前AKS容器管理平台的成員節點主機資訊。如圖26所示，會發現共有2台成員節點主機，採用的Kubernetes版本為最新穩定的「1.16.9」。
圖26 透過指令查詢AKS容器管理平台的成員節點主機資訊。
結語
本文實戰演練中的Playbook（YAML檔案），都公開存放在筆者的GitHub Ansible Repo當中（https://github.com/Weithenn/ansible）。透過本文的深入剖析和實戰演練，企業組織的IT管理人員都可以透過Ansible AWX自動化管理平台，讓Ansible Playbook自動化機制更容易使用更強大，幫助企業的IT管理人員有效管理地端資料中心和公有雲運作環境。
＜本文作者：王偉任，Microsoft MVP及VMware vExpert。早期主要研究Linux/FreeBSD各項整合應用，目前則專注於Microsoft及VMware虛擬化技術及混合雲運作架構，部落格weithenn.org。＞