即將發布的紅帽 Ansible Engine 2.9 帶來了令人興奮的改進，本文將介紹其中一些改進。 像往常一樣，我們一直在社區的支持下公開開發 Ansible 網路改進。 加入我們——看看 並研究發展規劃 在 wiki 頁面上 .
正如我們最近宣布的那樣， 現在包括 Ansible Tower、Ansible 引擎和所有 Ansible 網路內容。 如今，最受歡迎的網路平台都是透過 Ansible 模組實現的。 例如：
- 阿里斯塔EOS
- 思科IOS
- 思科 IOS XR
- 思科 NX-OS
- 杜松子朱諾斯
- 操作系統
紅帽透過 Ansible Automation 訂閱完全支援的平台的完整列表， .
我們學到了什麼
在過去的四年裡，我們學到了很多關於開發網路自動化平台的知識。 我們也了解到 作為 最終使用者在 Ansible 劇本和角色中使用平台工件。 這是我們發現的：
- 組織不僅對來自一家供應商的設備進行自動化，而且還對來自許多供應商的設備進行自動化。
- 自動化不僅是一種技術現象，也是一種文化現象。
- 由於自動化設計的基本架構原則，大規模網路自動化比看起來更困難。
當我們一年多前討論我們的長期成長計畫時，我們的企業客戶提出了以下要求：
- 事實收集需要更好地標準化並與所有設備上的自動化工作流程保持一致。
- 更新設備上的配置也需要標準化和一致，以便 Ansible 模組在收集事實後處理週期的後半部分。
- 我們需要嚴格且受支援的方法來將設備配置轉換為結構化資料。 在此基礎上，可以將真相來源從網路設備移走。
事實改進
使用 Ansible 從網路設備收集事實通常是隨機發生的。 基於 Web 的平台具有不同程度的事實收集功能，但它們幾乎沒有或沒有解析和標準化鍵值對中資料表示的功能。 讀 Ken Celenza 講述了分析和標準化事實數據是多麼困難和痛苦。
您可能已經注意到我們致力於 Ansible 網路引擎角色。 自然，在下載量達到 24K 後，網路引擎角色迅速成為 Ansible Galaxy 中網路自動化場景中最受歡迎的 Ansible 角色之一。 在我們將其中的大部分內容轉移到 Ansible 2.8 中以準備 Ansible 2.9 中的需求之前，這個 Ansible 角色提供了第一組工具來幫助解析命令、管理命令和收集網路設備的資料。
如果您知道如何使用 Network Engine，那麼這是收集、解析和標準化事實資料以供 Ansible 使用的非常有效的方法。 該角色的缺點是您需要為每個平台和所有網路活動創建一大堆解析器。 要了解建立、發布和維護解析器有多困難，請查看 來自思科的人。
簡而言之，從設備獲取事實並將其標準化為鍵值對對於大規模自動化至關重要，但當您擁有許多供應商和網路平台時，要實現這一點很困難。
Ansible 2.9 中的每個網路事實模組現在都可以分析網路設備的配置並返回結構化資料 - 無需額外的庫、Ansible 角色或自訂解析器。
從 Ansible 2.9 開始，每次發布更新的網路模組時，事實模組都會得到改進，以提供有關這部分配置的資料。 也就是說，事實和模組的開發現在以相同的速度進行，並且它們將始終具有共同的資料結構。
網路設備上的資源配置可以透過兩種方式檢索並轉換為結構化資料。 透過這兩種方式，您都可以使用新關鍵字收集和轉換特定的資源列表 gather_network_resources。 資源名稱與模組名稱相匹配，非常方便。
在收集事實時：
使用關鍵字 gather_facts 您可以在 playbook 的開頭檢索目前的裝置配置，然後在整個 playbook 中使用它。 指定要從設備檢索的各個資源。
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: True您可能已經注意到這些範例中的一些新內容，即 - gather_facts: true 現在可用於網路設備的本機事實收集。
直接使用網路事實模組：
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces該劇本返回有關介面的以下事實：
ansible_facts:
ansible_network_resources:
interfaces:
- enabled: true
name: Ethernet1
mtu: '1476'
- enabled: true
name: Loopback0
- enabled: true
name: Loopback1
- enabled: true
mtu: '1476'
name: Tunnel0
- enabled: true
name: Ethernet1
- enabled: true
name: Tunnel1
- enabled: true
name: Ethernet1請注意 Ansible 如何從 Arista 設備檢索本機配置並將其轉換為結構化數據，以用作下游任務和操作的標準鍵值對。
介面事實可以加入到 Ansible 儲存變數中，並立即或稍後用作資源模組的輸入 eos_interfaces 無需額外的處理或轉換。
資源模組
因此，我們提取事實，標準化數據，將它們擬合到標準化的內部數據結構圖中，並獲得現成的事實來源。 萬歲！ 當然，這很棒，但我們仍然需要以某種方式將鍵值對轉換回特定裝置平台期望的特定配置。 我們現在需要特定於平台的模組來滿足這些新的事實收集和標準化要求。
什麼是資源模組？ 您可以將設備的配置部分視為該設備提供的資源。 網路資源模組有意限制為單一資源，並且可以像建構塊一樣堆疊以配置複雜的網路服務。 結果，資源模組的要求和規格自然就被簡化了，因為資源模組可以讀取 и 在網路設備上設定特定的網路服務。
為了解釋資源模組的作用，讓我們來看一個範例劇本，它顯示了使用新網路資源事實和模組的冪等操作 eos_l3_interface.
- name: example of facts being pushed right back to device.
hosts: arista
gather_facts: false
tasks:
- name: grab arista eos facts
eos_facts:
gather_subset: min
gather_network_resources: l3_interfaces
- name: ensure that the IP address information is accurate
eos_l3_interfaces:
config: "{{ ansible_network_resources['l3_interfaces'] }}"
register: result
- name: ensure config did not change
assert:
that: not result.changed可以看到，從設備採集的資料直接傳輸到對應的資源模組，沒有進行任何轉換。 啟動後，劇本會從裝置檢索值並與預期值進行比較。 在此範例中，傳回的值符合預期（即，它檢查配置偏差）並報告配置是否已變更。
檢測配置偏差的理想方法是將事實儲存在 Ansible 儲存變數中，並在檢查模式下定期將它們與資源模組一起使用。 這是查看是否有人手動更改值的簡單方法。 在大多數情況下，組織允許手動變更和配置，儘管許多操作是透過 Ansible Automation 執行的。
新的資源模組與先前的資源模組有何不同？
對於網路自動化工程師來說，Ansible 3 和先前版本的資源模組主要有 2.9 個差異。
1) 對於給定的網路資源（也可以被認為是配置部分），模組和事實將在所有支援的網路作業系統上同時發展。 我們認為，如果 Ansible 支援在一個網路平台上進行資源配置，那麼我們應該在所有地方都支援它。 這簡化了資源模組的使用，因為網路自動化工程師現在可以使用本機和受支援的模組在所有網路作業系統上配置資源（例如 LLDP）。
2) 資源模組現在包含狀態值。
merged：配置與提供的配置合併（預設）；replaced：資源配置將替換為提供的配置；overridden：資源配置將替換為提供的配置； 不必要的資源實例將被刪除；deleted：資源配置將被刪除/恢復為預設值。
3) 資源模組現在包含穩定的回傳值。 當網路資源模組對網路設備做出（或建議）必要的更改時，它會將相同的鍵值對返回到劇本中。
before：任務前以結構化資料的形式在設備上進行配置；after：如果設備已更改（或如果使用測試模式則可能會更改），則結果配置將作為結構化資料傳回；commands：在設備上執行任何配置命令以使其進入所需狀態。
這一切意味著什麼？ 為什麼它如此重要？
這篇文章涵蓋了許多複雜的概念，但我們希望最終您能更好地理解企業客戶對自動化平台的事實收集、資料標準化和循環配置的要求。 但為什麼他們需要這些改進呢？ 許多組織現在正在尋求數位轉型，使其 IT 環境更加敏捷和更具競爭力。 無論好壞，許多網路工程師要麼出於自身利益，要麼應管理層的要求而成為網路開發人員。
組織正在意識到，自動化單一網路模板並不能解決孤島問題，只能在一定程度上提高效率。 紅帽 Ansible 自動化平台提供嚴格且規範的資源資料模型，以程式設計方式管理網路設備上的底層資料。 也就是說，使用者逐漸放棄單獨的配置方法，轉而採用更現代的方法，專注於技術（例如 IP 位址、VLAN、LLDP 等），而不是特定供應商的實現。
這是否意味著可靠且經過驗證的命令模組和配置的日子已經屈指可數了？ 不可能。 預期的網路資源模組並不適用於所有情況或每個供應商，因此網路工程師對於某些實作仍然需要命令和設定模組。 資源模組的目的是簡化大型 Jinja 模板並將非結構化設備配置規範為結構化 JSON 格式。 透過資源模組，現有網路可以更輕鬆地將其配置轉換為結構化的鍵值對，這些鍵值對代表易於閱讀的事實來源。 透過使用結構化鍵值對，您可以從在每個裝置上運行配置轉向處理獨立的結構化數據，並將網路帶到基礎設施即程式碼方法的最前沿。
Ansible Engine 2.9 中將包含哪些資源模組？
在我們詳細告訴您 Ansible 2.9 中會發生什麼之前，讓我們記住我們是如何劃分整個工作範圍的。
我們確定了 7 個類別，並為每個類別分配了特定的網路資源：
註：粗體資源是在 Ansible 2.9 中規劃和實施的。
根據企業客戶和社群的回饋，首先處理與網路拓撲協定、虛擬化和介面相關的模組是合乎邏輯的。
以下資源模組由 Ansible Network 團隊開發，對應 Red Hat 支援的平台：
以下模組由 Ansible 社群開發：
exos_lldp_global- 來自極進網路。nxos_bfd_interfaces- 來自思科nxos_telemetry- 來自思科
正如您所看到的，資源模組的概念符合我們以平台為中心的策略。 也就是說，我們在 Ansible 本身中包含了必要的能力和功能，以支援網路模組開發的標準化，並在 Ansible 角色和劇本層級簡化使用者的工作。 為了擴展資源模組的開發，Ansible 團隊發布了 Module Builder 工具。
Ansible 2.10 及更高版本的計劃
Ansible 2.9 發布後，我們將致力於 Ansible 2.10 的下一組資源模組，這些模組可用於進一步配置網路拓撲和策略，例如 。 開發計劃仍可調整，如有意見請回饋至 .
資源和入門
來源： www.habr.com