前言

今天要聊的是一個常常跟 OpenShift Container Platform（OCP） 綁在一起出現的工具：
Ansible Automation Platform（AAP）。
很多剛接觸 OCP 的人都會問：

• 「我已經有 oc 指令、Operator、GitOps，為什麼還要 Ansible？」
• 「不是只要安裝叢集就好，幹嘛拉一個平台進來？」

Ansible 與 OCP 的淵源

OpenShift 一開始的安裝工具就是 openshift-ansible。
雖然現在有了 openshift-install + IPI/UPI，但底層還是離不開 Ansible：

• 前期：建 VM、設 VLAN、防火牆規則
• 中期：安裝 OCP 元件（API Server、etcd、Machine Config Operator）
• 後期：Day-2 操作（加節點、憑證更新、調整 StorageClass）

基於上述特性， Red Hat 官方會把 Ansible Automation Platform 當成 OCP 自動化的好朋友

為什麼要用「平台」而不是純 Ansible？

純的 ansible-playbook 在小規模實驗環境沒問題，但進到企業場景會遇到瓶頸：

• 誰能跑？誰不行？（RBAC 問題）
• 怎麼管版本？（Playbook 改壞怎麼辦？）
• 誰跑過？什麼時候跑的？（Audit Log）
• 能不能給非工程人員一鍵操作？

這些需求，靠 CLI 很難搞定。 而 AAP 提供了 GUI、API、集中控管、審計紀錄、整合 Red Hat Insights，讓自動化升級成「企業級」。

AAP 在 OCP 生態系的位置

如果把 OCP 的自動化拼圖比喻成一場球賽：

• Operator → 自動管理單一產品（像是 DB Operator 自顧自）
• GitOps (ArgoCD) → 保證「叢集內的狀態」跟 Git repo 一致
• oc/kubectl → 工程師的萬能小刀
• Ansible Automation Platform → 跨叢集、跨平台、跨層級的大總管

舉建一個新環境為例：

1. AAP 幫你拉 VM、設 VLAN、防火牆（Infra）
2. AAP 跑 OCP 安裝 Playbook（Cluster）
3. 裝完叢集再用 ArgoCD 佈署應用（App）

如此就是全自動 CI/CD pipeline from Infra to App。

實戰案例：OCP 憑證輪替

配合我們前面做過的更換憑證為例，OCP 的 ingress、API Server 憑證過期是大家的痛點。
你可以用 oc get secret 手動更新，但要跑很多步。

如果用 AAP：

• 寫一個 Playbook 把到期憑證偵測、自動替換、更新 IngressOperator 全包
• 設排程，憑證快過期就自動跑
• RBAC 控制只有 SRE team 能改
• Audit Log 留下紀錄，稽核人員也滿意

這就是「平台化」的威力。

結論

• 為什麼 Red Hat 硬推 AAP？
  • 生態系整合：跟 Satellite、Insights、OCP Operators 全部接起來
  • 商業價值：有訂閱、有支援，企業客戶買得安心
  • 治理需求：Audit / Compliance / RBAC / API 全都有
  • 跨平台：不只 OCP，還能控 AWS、VMware、F5、防火牆、儲存設備
• 但只要一進企業場景，多叢集、多雲、多團隊，有合規需求，要跨 infra + OCP 管理，那就幾乎是非用不可了！