Ansible 演進史（下）：Terraform 分工、Collections 拆分與 AI 時代

⭐️精選
Aa

上篇停在一個略顯尷尬的歷史節點：Ansible 憑藉 agentless 與極簡 YAML 贏下了傳統組態管理之戰，但維運的主戰場正悄悄搬離單純的「伺服器設定」。

NOTE

延伸閱讀：Ansible 演進史（上）：Agentless、YAML 與 Red Hat 收購

從 2014 年起，幾個轉折重塑了 Ansible 的形貌：

 2014 --- Terraform 登場
      -> 佈建（Day 0）與組態（Day 1）分工固化十年
 2019 --- IBM 收購 Red Hat
      -> 進入大型企業平台生態
 2020 --- Collections 拆分
      -> 單體解耦，維護責任推回社群與硬體廠商
 2020-25- 競爭對手出清
      -> Chef、Puppet、SaltStack 凋零並爆發分叉潮
 2026 --- 容器與 AI 浪潮
      -> 守住網路設備，探索 AI 生成與執行治理

這十年裡，Ansible 經歷了工具邊界的退讓、社群治理的重劃，並在不可變基礎設施與生成式 AI 的夾擊下，重新找到了自己的立足點。

⭐️為什麼 Terraform 沒吃掉 Ansible，Ansible 也沒吃掉 Terraform

2014 年 Terraform 問世時，Ansible 早已內建了雲端模組——建立 EC2、設定 VPC、掛載雲端硬碟，在 playbook 裡都能直接呼叫。從功能清單上看，Terraform 沒有做任何 Ansible 做不到的事。

然而十年過去，業界幾乎沒有人用 Ansible 管理雲端資源的生命週期，也很少有人用 Terraform 深入伺服器內部設定。雙方沒有互相吞併，關鍵在於狀態（State）。

狀態檔帶來的分水嶺

Terraform 仰賴一份 state 檔記錄所佈建的每個資源。有了 state，它才能實現三項核心能力：

Ansible 則堅持不保存 state 檔。它的運作模型是每次執行時直接連上目標檢視實際狀態，靠模組的冪等性（Idempotence）將系統推向期望值。這在管理單台伺服器時極其輕巧，但在面對雲端 API 時卻會遭遇結構性限制：

反過來，Terraform 的局限同樣清晰：它專注於資源的存在與屬性，伺服器開機後的作業系統內部組態並非其擅長領域。Terraform 雖提供 provisioner 在建立後執行指令，但官方文件直接將其列為「最後手段」（last resort），因為它會破壞宣告式狀態模型的純粹性。

Ansible 不做 state，和它不裝 agent 是同一個設計哲學的兩面：降低管理端與受控端需要維護的額外負擔。 它不需要 Terraform 式的資源 state 檔，但 inventory、憑證與企業平台的工作紀錄仍須管理。

十年分工的整合收尾

最終，業界固化出一條明確的產業分工：Terraform 負責 Day 0 的基礎設施佈建，Ansible 接手 Day 1 的系統組態。 雙方官方甚至多次撰文強調彼此互補而非競爭。

這項分工讓 Ansible 失去了成長最迅猛的雲端原生市場——那裡的資源透過 API 隨建隨刪、用完即棄；卻也替它守住了長期運作的實體機器與伺服器維運版圖。

這場長達十年的技術分工在 2025 年 2 月 27 日迎來了歷史性的收尾：IBM 以 $64 億美元完成收購 HashiCorp，Terraform 與 Ansible 這對老對手與老搭檔，最終在同一家母公司旗下相聚。

Collections 大拆分：工程解耦的表面，責任重劃的實質

2019 年 10 月 31 日發布的 v2.9.0，是 Ansible 歷史上最後一個單體（Monolith）儲存庫。

當時的 ansible/ansible 倉庫同時容納了核心引擎與三千多個模組。2020 年 8 月 13 日發布的 v2.10.0，正式將專案切為兩層：

 [ Ansible 2.9 單體 ]
   ansible/ansible (引擎 + 3,000+ 模組)
         |
         v
 [ Ansible 2.10+ 拆分 ]
   +-- ansible-core
   |    核心引擎 + 最小模組集 (file, copy, apt...)
   +-- Ansible 社群套件
        ansible-core + 100+ Collections

工程上的官方理由非常充分：單體倉庫維護負擔過重，大量模組長期處於低度維護甚至損壞狀態。拆分後，各 collection 可擁有獨立的版本發布節奏，硬體與雲端廠商也能自由更新自家模組，不必等待 Ansible 核心發布。

維護責任的外推與淘汰機制

然而在開源治理層面，這次拆分意味著維護責任正式從 Red Hat 的單一儲存庫移出，推回給各 collection 的維護者與社群。

官方訂立了嚴格的移除流程：當某個 collection 長期缺乏維護且問題未修，便會被標記為 unmaintained，並在下一個大版本中自社群套件剔除。

這套機制最標誌性的案例發生在 2024 年底。

community.network 遭投票移除。 2024 年 10 月 7 日，社群投票決定將 community.network移出 Ansible 社群套件，原因在於其最後一次功能發布停留在 2022 年，隨後十二個月僅有零星錯誤修正。自 Ansible 12 起，需要該套件的使用者必須自行透過 ansible-galaxy 安裝。

這個案例暴露了拆分後的代價：核心引擎持續發布，不代表每個 collection 都有人維護。 對企業使用者而言，廠商維護與認證支援因此成為選型的重要條件；後面的 Uber 案例便採用了這條路徑。

為什麼 Ansible 從未發生分叉？

將 Ansible 的歷程與 Terraform 2023 年改採 BSL 授權後引發的 OpenTofu 分叉對照，Ansible 歷經 2.10 大拆分、AWX 安裝路徑收窄等多次社群摩擦，卻從未出現有威脅性的社群分叉（Fork）。

箇中原因主要有三：

  1. 授權底線從未動搖：ansible/ansible 始終維持 GPLv3 授權，使用者擁有的既有軟體權利十四年間從未被收回。
  2. 商業化邊界提早鎖定：AnsibleWorks 早期即確立「引擎開源、UI 與企業治理閉源」的策略。Red Hat 不需要像 HashiCorp 一樣回頭收回已開源的底層資產。
  3. 上游雖然提高門檻，但未關閉大門：AWX 官方安裝方式雖限縮為 Kubernetes/OpenShift 上的 AWX Operator，淘汰了輕量 Docker 與 RPM 方案，造成自架難度上升，但並未將功能鎖死在商業授權後。

增加使用麻煩只會引來抱怨，剝奪既有權利才會逼出分叉。

NOTE

延伸閱讀：IaC 與 Terraform 三十年興衰史

競品易主與分叉潮：Ansible 的平台整合優勢

2020 至 2022 年間，第一代組態管理工具接連被收購。這段時期前後，授權與分發政策也陸續改變，但兩者並非都有直接因果關係：Chef 的分發政策變更，就早於 Progress 的收購。

工具併購事件商業化政策變更社群回應
Chef2020 年被 Progress 收購2019 年起官方建置版本的商業使用須有商業授權，原始碼仍開源社群發起 Cinc，自建純開源編譯發行版
SaltStack2020 年被 VMware 收購併入 VMware 專有架構，社群重心淡化社群活躍度持續流失
Puppet2022 年被 Perforce 收購2025 年官方套件轉入私有倉庫，限 25 節點Vox Pupuli 於 2025 年發起 OpenVox 分叉

Chef 的 Cinc 提供社群建置的自由發行版，Puppet 的 OpenVox 與 Terraform 的 OpenTofu 則以分叉延續專案。這些回應共同說明：原始碼授權與取得官方可執行版本的條件，是兩條不同的界線。

「不是我們在分叉 Puppet，是 Perforce 在分叉 Puppet。Perforce 現在在做的事，是拿著我們共同使用、除錯、編寫、協作、盯著、部署在數千台機器上的開源程式碼，把存取權關起來，只留給付費客戶。」

—— Antoine Beaupré，Puppet 社群成員

唯獨 Ansible 的 pip install ansible 在十四年後依然保持原始承諾。

平台效應的保護傘

與這些競品對照，Ansible 的一項重要優勢，是它被整合進了 Red Hat 的企業作業系統版圖。

Red Hat 的核心業務是 RHEL，其企業客戶也有修補、組態與合規稽核需求。Ansible 可以沿著既有客戶與支援體系發展，並與 RHEL、OpenShift 的管理工作整合。從這個角度看，平台整合是 Ansible 持續發展的一項優勢，但不足以單獨解釋各家工具的命運。

IBM 時代：從單機自動化轉向企業控制平面

在收購 Red Hat 後，IBM 與 Red Hat 推動 Ansible 展開平台化升級：從單純「在終端機跑 playbook 的 CLI 工具」，演進為「企業自動化控制平面（Ansible Automation Platform, AAP）」。

 [ Enterprise Systems ]
        |
        | (Events/Webhooks)
        v
 [ Event-Driven Ansible (EDA) ]
        |
        | (Rulebook Match)
        v
 [ Automation Hub / Execution ]
        ^
        | (Certified Roles)
        |
 [ AAP Control Plane  ]

三項關鍵技術布局

  1. Event-Driven Ansible（EDA，2023）： 上篇提過，Ansible 早期曾兩度嘗試在受控端安裝常駐程式，最終皆退回純 SSH。EDA 採取了另一種路徑：將常駐監聽邏輯置於控制端而非受控端。透過 rulebook 監聽監控系統的警報、Webhook 或 Kafka 訊息，在無人介入下自動觸發相應的 playbook。這在不破壞 agentless 承諾的前提下，補齊了過去只有常駐 agent 才能具備的「即時反應」能力。

  2. 認證內容體系（Certified Collections）： Red Hat 在商業版 Automation Hub 中推行認證內容機制：由 Cisco、Juniper、Arista、AWS 等硬體與雲端廠商負責編寫模組，Red Hat 進行品質檢驗與企業支援背書。此舉正式將模組生態的維護重擔轉化為廠商的商業誘因。

  3. 執行環境（Execution Environments）： 將 ansible-core、Python、collections 與系統依賴封裝成容器映像檔，可透過 ansible-builder 建置並存放於 registry。同一份 playbook 從開發機移到 CI 或平台執行時，能沿用相同的依賴環境，降低「本機能跑，換台機器就失敗」的落差。

這三項布局分別處理何時觸發、誰維護內容，以及用什麼環境執行。平台化的重點，是把個人的自動化工作變成團隊能重複使用與管理的流程。

2026 現狀：守住實體硬體戰場

當雲原生應用全面轉向容器與 Kubernetes 不可變架構時，Ansible 的真正價值退守至容器技術無法覆蓋的領域：實體網路設備、硬體儲存與合規稽核。

Uber 的 5,000 台網路設備管理實例

2026 年 4 月，Uber 工程團隊公開了他們如何利用 Ansible 管理遍布全球 6 大洲、5 個區域的 5,000 台企業網路設備：

「Ansible 是 agentless 的：它不需要在受控端常駐 daemon 即可直接管理設備。」

—— Uber 工程部落格

 [ Uber 網路維運 CI/CD ]
          | (每夜執行 24 小時)
          v
 [ Jinja2 設定引擎 ] -- (渲染範本)
          |
          v
 [ 認證 Collections ] -- (SSH 推送)
          |
          v
 5,000 台網路設備
      +-- Cisco 交換器
      +-- Juniper 路由器
      +-- Arista 閘道器

這項實例印證了 Ansible 在 2026 年的定位：不可變基礎設施能吃掉應用伺服器，但吃不掉實體網路設備與地端機房。

AI 時代：Playbook 的價值會歸零嗎？

長年以來，工程師對 Ansible 最常見的抱怨集中在 YAML 語法的瑣碎——記住艱深的模組參數、檢查縮排錯誤，以及撰寫難以除錯的 Jinja2 過濾器。

隨著大型語言模型（LLM）普及，Red Hat 於 2023 年底推出整合 watsonx 的 Ansible Lightspeed，後續也支援 OpenAI、Gemini 及企業自帶模型（BYOM），讓維運人員能用自然語言提示直接生成 playbook 任務。

這常讓人產生疑問：既然 AI 連 Shell 和 Python 腳本都能一鍵產出，維運團隊為什麼還需要 Ansible？

語法負擔降低，執行價值凸顯

AI 降低了查模組參數、處理 YAML 縮排與撰寫 Jinja2 表達式的成本，卻沒有替團隊決定正確的目標狀態。當產出 playbook 變容易，Ansible 生態的價值更可能集中在三個地方：

  1. 冪等模組與變更預覽：宣告式模組讓重複執行更容易控制，check mode 則協助預覽支援模組的變更。但冪等不代表設定正確，乾跑也不是安全保證；例如 shell 模組只能透過 creates、removes 等條件提供有限的預測。
  2. 參數明確的操作介面：模組提供既有參數、操作語意與結構化結果。相較於每次生成一套自由形式腳本，團隊更容易限制與檢查模型提出的操作，但仍須核對模組能力與輸入值。
  3. 平台層的授權與稽核：AAP 的 Automation Controller 提供 RBAC、憑證管理與集中工作紀錄。這些能力來自平台層，而非單靠 ansible-playbook；模型加入工作流程後，仍須明確界定誰能啟動工作、能操作哪些目標。

生成新工作，還是觸發已核准工作？

模型參與自動化，可以有兩種不同的方式。第一種是生成新的 playbook，再由人審查與測試；Lightspeed 的程式碼生成便屬於這類。第二種是透過平台 API，觸發事先審查過的工作模板，並限制可用參數與目標範圍。

第二種方式較容易控制風險：模型選擇要跑哪項工作，操作內容與權限則事先界定。不過選錯工作、參數或目標仍會造成事故。執行層的價值，在於讓變更有可檢查的內容、明確授權與可追查的結果。 這是對 AI 自動化架構的判斷，並不代表模型觸發工作已成為所有團隊的標準做法。

NOTE

延伸閱讀：Vibe Coding 演進史（下篇）：生產事故、長期代價與軟體工程的底線

一個歷史的意外紅利

十四年前，Ansible 為了降低開發門檻而選擇不發明專用 DSL、採用現成 YAML；這項決定曾為它帶來表現力不足的批評。

到了 LLM 時代，這項選擇有了另一層優勢：YAML 廣泛用於組態檔與自動化流程，Ansible 也累積了公開的 playbook 範例與模組文件。相較於另創一套使用範圍狹窄的 DSL，採用通用格式更容易沿用既有工具與範例，讓模型生成、讓人檢查。

因此可以合理推論，YAML 讓 Ansible 更容易接入 AI 工具。 這項優勢來自通用格式與公開生態的累積；實際生成品質仍取決於模型是否熟悉 Ansible 的模組、版本與任務語意。十四年前避免自訂語法的選擇，意外降低了今天導入 AI 的門檻。

結語：成熟工具的下一個位置

從 Terraform 分工、collections 拆分到 Uber 的網路管理，Ansible 持續調整自己承擔的責任。AI 可能改變 playbook 的寫法，而成熟模組、一致的執行環境，以及平台的授權與稽核，仍是團隊管理變更的理由。這些能力能否持續被需要，將決定它下一階段的位置。

  1. Ansible 演進史（上）：Agentless、YAML 與 Red Hat 收購
  2. IaC 與 Terraform 三十年興衰史
  3. Vibe Coding 演進史（下篇）：生產事故、長期代價與軟體工程的底線