インサイド・プレイブック。 新しい Ansible Engine 2.9 のネットワーク機能

Red Hat Ansible Engine 2.9 の今後のリリースでは、魅力的な改善がもたらされており、その一部についてはこの記事で説明します。 いつものように、私たちはコミュニティのサポートを受けながら、Ansible ネットワークの改善をオープンに開発してきました。 参加してみましょう - 見てみましょう GitHub の発行ボード ～の開発計画を検討します Red Hat Ansible Engine 2.9 のリリース のウィキページで Ansible ネットワーク.

最近お知らせしたように、 Red Hat Ansible 自動化プラットフォーム Ansible Tower、Ansible Engine、およびすべての Ansible Network コンテンツが含まれるようになりました。 現在、最も一般的なネットワーキング プラットフォームは Ansible モジュールを通じて実装されています。 例えば：

• アリスタEOS
• Cisco IOS
• Cisco IOS XR
• Cisco NX-OS
• ジュニパー ジュノス
• VyOS

Ansible Automation サブスクリプションを通じて Red Hat によって完全にサポートされているプラ​​ットフォームの完全なリストについては、 ここで公開されています.

私たちは何を学んだのか

過去 XNUMX 年間にわたり、私たちはネットワーク自動化プラットフォームの開発について多くのことを学びました。 私たちもそれを学びました 方法 プラットフォーム アーティファクトは、エンド ユーザーによって Ansible プレイブックとロールで使用されます。 そして、私たちが知ったことは次のとおりです。

• 組織は、XNUMX つのベンダーだけでなく、多くのベンダーのデバイスを自動化しています。
• 自動化は技術的な現象であるだけでなく、文化的な現象でもあります。
• 自動化設計の基本的なアーキテクチャ原則のため、ネットワークを大規模に自動化することは、思っているよりも困難です。

XNUMX年以上前に私たちが長期的な成長計画について話し合ったとき、私たちの法人顧客は次のことを求めました。

• ファクト収集をより標準化し、すべてのデバイスにわたる自動化ワークフローと連携させる必要があります。
• Ansible モジュールがファクト収集後のサイクルの後半を処理できるように、デバイス上の構成の更新も標準化され、一貫性がある必要があります。
• デバイス構成を構造化データに変換するには、厳密でサポートされた方法が必要です。 これに基づいて、信頼できる情報源をネットワーク デバイスから移動できます。

事実の改善

Ansible を使用してネットワーク デバイスからファクトを収集することは、多くの場合ランダムに行われます。 Web ベースのプラットフォームにはさまざまな程度の事実収集機能がありますが、キーと値のペアでのデータ表現を解析して標準化する機能はほとんど、またはまったくありません。 読む 投稿する Ken Celenza が、事実データを分析して標準化することがいかに難しく、苦痛であるかを語ります。

私たちが Ansible Network Engine の役割に取り組んでいることに気づいたかもしれません。 当然のことながら、24 回のダウンロード後、ネットワーク エンジン ロールは、ネットワーク自動化シナリオ用の Ansible Galaxy で最も人気のある Ansible ロールの 2.8 つになりました。 Ansible 2.9 で必要になるものに備えるために、この大部分を Ansible XNUMX に移行する前に、この Ansible ロールは、コマンドの解析、コマンドの管理、およびネットワーク デバイスのデータ収集を支援する最初のツール セットを提供しました。

Network Engine の使用方法を知っている場合、これは Ansible で使用するファクト データを収集、解析、標準化するための非常に効率的な方法です。 このロールの欠点は、プラットフォームごとおよびすべてのネットワーク アクティビティに対して大量のパーサーを作成する必要があることです。 パーサーの作成、配布、保守がいかに難しいかを理解するには、以下を参照してください。 1200 を超えるパーサー シスコの人たちから。

一言で言えば、デバイスからファクトを取得し、それらをキーと値のペアに正規化することは、大規模な自動化に不可欠ですが、多くのベンダーやネットワーク プラットフォームがある場合、これを達成するのは困難です。

Ansible 2.9 の各ネットワーク ファクト モジュールは、追加のライブラリ、Ansible ロール、カスタム パーサーなしで、ネットワーク デバイスの構成を分析し、構造化データを返すことができるようになりました。

Ansible 2.9 以降、更新されたネットワーク モジュールがリリースされるたびに、構成のこのセクションに関するデータを提供するようにファクト モジュールが改善されています。 つまり、ファクトとモジュールの開発は同じペースで行われ、それらは常に共通のデータ構造を持つことになります。

ネットワーク デバイス上のリソースの構成は、XNUMX つの方法で取得して構造化データに変換できます。 どちらの方法でも、新しいキーワードを使用してリソースの特定のリストを収集および変換できます。 gather_network_resources。 リソース名はモジュール名と一致するため、非常に便利です。

事実を収集しながら:

キーワードを使用する gather_facts プレイブックの先頭で現在のデバイス構成を取得し、それをプレイブック全体で使用できます。 デバイスから取得する個々のリソースを指定します。

- 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 追加の処理や変換なしで。

リソースモジュール

そこで、事実を抽出し、データを正規化し、標準化された内部データ構造図に当てはめて、既製の信頼できる情報源を受け取りました。 万歳！ もちろんこれは素晴らしいことですが、キーと値のペアを何らかの方法で特定のデバイス プラットフォームが期待する特定の構成に変換する必要があります。 これらの新しい事実収集と正規化の要件を満たすために、プラットフォーム固有のモジュールが必要になりました。

リソースモジュールとは何ですか? デバイスの構成セクションは、そのデバイスによって提供されるリソースと考えることができます。 ネットワーク リソース モジュールは意図的に XNUMX つのリソースに制限されており、ビルディング ブロックのように積み重ねて複雑なネットワーク サービスを構成できます。 その結果、リソース モジュールは次の内容を読み取ることができるため、リソース モジュールの要件と仕様は自然に簡素化されます。 и ネットワーク デバイス上で特定のネットワーク サービスを構成します。

リソース モジュールの機能を説明するために、新しいネットワーク リソース ファクトとモジュールを使用した冪等操作を示すプレイブックの例を見てみましょう。 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 が XNUMX つのネットワーク プラットフォームでリソース構成をサポートするのであれば、それをどこでもサポートする必要があると私たちは考えています。 これにより、ネットワーク オートメーション エンジニアはネイティブ モジュールとサポートされているモジュールを使用してすべてのネットワーク オペレーティング システム上でリソース (LLDP など) を構成できるため、リソース モジュールの使用が簡素化されます。

2) リソースモジュールに状態値が含まれるようになりました。

• merged: 設定は提供された設定とマージされます (デフォルト)。
• replaced: リソース構成は、提供された構成に置き換えられます。
• overridden: リソース構成は、提供された構成に置き換えられます。 不要なリソース インスタンスは削除されます。
• deleted: リソース構成は削除されるか、デフォルトに復元されます。

3) リソースモジュールには安定した戻り値が含まれるようになりました。 ネットワーク リソース モジュールがネットワーク デバイスに必要な変更を行う (または提案する) と、同じキーと値のペアがプレイブックに返されます。

• before: タスク前の構造化データの形式でのデバイス上の構成。
• after: デバイスが変更された場合 (またはテスト モードが使用されている場合は変更される可能性があります)、結果の構成は構造化データとして返されます。
• commands: デバイスを目的の状態にするために、任意の構成コマンドがデバイス上で実行されます。

これは何を意味するのでしょうか? どうしてそれが重要ですか？

この投稿では多くの複雑な概念を取り上げていますが、最終的には、企業クライアントが実際に自動化プラットフォームの収集、データ正規化、ループ構成を求めていることについてより深く理解できることを願っています。 しかし、なぜこのような改善が必要なのでしょうか? 現在、多くの組織が IT 環境の俊敏性と競争力を高めるためにデジタル変革を追求しています。 良くも悪くも、多くのネットワーク エンジニアは私利私欲のため、または経営陣の命令でネットワーク開発者になります。

組織は、個々のネットワーク テンプレートを自動化してもサイロの問題は解決せず、効率はある程度向上するだけであることに気づき始めています。 Red Hat Ansible Automation Platform は、ネットワーク デバイス上の基盤となるデータをプログラムで管理するための、厳密で規範的なリソース データ モデルを提供します。 つまり、ユーザーは個別の構成方法を徐々に放棄し、特定のベンダーの実装ではなくテクノロジー (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 の次のリソース モジュール セットに取り組む予定です。これは、ネットワーク トポロジとポリシーをさらに構成するために使用できます。 ACL、OSPF、BGP。 開発計画はまだ調整可能ですので、ご意見がございましたら、 までご報告ください。 Ansible ネットワーク コミュニティ.

リソースと開始方法

Ansible Automation Platform に関するプレスリリース
Ansible 自動化プラットフォームのブログ
Ansible におけるコンテンツ配信の未来
Ansible プロジェクト構造の変更に関する考察

出所： habr.com