網管人雜誌
本文刊載於 網管人雜誌第 175 期 - 2020 年 8 月 1 日出刊，NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。本文目錄
前言Ansible AWX 簡介
實戰 Ansible AWX on Azure
部署內含 Ansible Tower 的 RHEL 虛擬主機
手動為 CentOS 安裝 Ansible AWX 執行環境
建立 Azure Credentials
啟動 Ansible AWX 同步 GitHub Repository
部署 Azure VM 虛擬主機（IaaS）
部署 SQL Server 執行個體（PaaS）
部署 Kubernetes Cluster（CaaS）
結語
前言
在本刊「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 AWX 和 Ansible Tower 之間的關係，就如同商業產品的 Red Hat Enterprise Linux 和開放源始碼 Fedora 的關係一樣。因此，當企業和組織建立 Ansible AWX 之後，可以直接參考 Red Hat Ansible Tower 技術文件。舉例來說，Ansible AWX 支援 RESTful API，那麼管理人員便可以直接參考 Ansible Tower 的 API Reference Guide 文件內容。
圖 1、Ansible Tower 運作架構示意圖
實戰 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 和 14 GB 記憶體的運算資源（如圖 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 模組的動作。
過去，大家所熟悉的 YUM 套件管理指令為 「YUM v3」 版本，而 CentOS 8 的 DNF 套件管理指令則是 「YUM v4」 版本。
$ 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 所示）。
管理人員可以執行「pip3 list」指令，查看已經安裝的 Ansible 模組清單和版本資訊。
圖 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 所示）。
Ansible AWX 目前支援三種部署環境，分別是 OpenShift、Kubernetes 和 Docker-Compose。
圖 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 所示）。
最新版本的 Ansible AWX 12.0.0，正式採用 Redis 取代舊版的 「RabbitMQ」 和 「MemCache」 運作元件。所以 Ansible AWX 主要運作元件從舊版的 「5 個」 降為新版的 「4 個」。
圖 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 所示）。
建立 Azure Service Principal 驗證資訊後，其中 「appId」 欄位為 Client ID、「password」 欄位為 Secret、「tenant」 欄位為 Tenant ID，並預設 「一年」 之後應用程式密碼過期。
圖 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 所示）。
當管理人員按下 Save 鈕之後，Ansible AWX 將會自動透過 Git 與剛才所指定的 GitHub Repository 進行溝通，確保 Ansible AWX 能夠順利同步指定的 GitHub Repository。
圖 18、啟動 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 變數名稱的值帶入其中。
有關 create_vm_with_password.yaml 的 YAML 檔案詳細內容，請參考 GitHub - Weithenn/Ansible/Azure/create_vm_with_password.yaml。
在這個 Playbook 內共有 7 個工作任務（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 名稱帶入其中。
有關 create_sql_server_instance.yaml 的 YAML 檔案詳細內容，請參考 GitHub - Weithenn/Ansible/Azure/create_sql_server_instance.yaml。
在這個 Playbook 當中總共有 3 個工作任務（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 版本號碼。
有關 create_aks_cluster.yaml 的 YAML 檔案詳細內容，請參考 GitHub - Weithenn/Ansible/Azure/create_aks_cluster.yaml。
這個 Playbook 當中共有 2 個工作任務（Tasks），並且搭配下列 Ansible Azure 模組，完成部署 AKS 容器管理平台的動作。
- azure_rm_resourcegroup ： 部署 Azure 資源群組，本文實作名稱為「RG-USEast-AKS1169」
- azure_rm_aks ： 部署 AKS 容器管理平台，本文實作名稱為「ansibleaks1169」，並且建立初始運作 AKS 容器管理平台的成員節點主機共「2 台」。
後續需要「擴充」AKS 容器管理平台成員節點主機的數量時，只需要調整「count :」參數值即可，例如，「count : 5」即表示總共會有「5 台」成員節點主機，有興趣的讀者請參考 GitHub - Weithenn/Ansible/Azure/scale_aks_cluster.yaml。在 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 容器管理平台的成員節點主機資訊