Cisco ACI のインベントリープラグイン

このような状況においてインベントリープラグインを自分で開発できる方法の一例として、Cisco ACI (Application Centric Infrastructure) 実装の問題を解決する、Ansible インベントリープラグインについての記事を執筆しました。このプラグインは、物理インベントリー要素 (スパインスイッチ、リーフスイッチ、APIC コントローラー) にクエリを実行し、これらに関する基本データを Ansible ホスト変数として保存します。

Ansible Tower でプラグインを使用する

これを Ansible Tower で使用するには複数のプロセスがあり、Collections を使用するステップが含まれます。ここでは例として、Cisco DevNet ACI Sandbox を使用してセットアップします。Ansible Tower 環境で Ansible Galaxy にアクセスできる必要があります。また、DevNet にログインしてサンドボックスの [Topology] ページにアクセスし、アクセス認証情報を取得する必要もあります。

プロジェクトの準備

以下のような requirements ファイルを collections/requirements.yml に作成します。

---
collections:
  - zjpeterson.aci

次に YAML インベントリーとして、以下のような aci.yml を作成します。

---
plugin: zjpeterson.aci.aci_inventory
host: sandboxapicdc.cisco.com
validate_certs: no

お好みの SCM を使用してこれらの 2 つのファイルをプロジェクトにコミットして、Project として Ansible Tower に追加します。

認証情報の準備

まず、ACI_USERNAME と ACI_PASSWORD 環境変数を出力してプラグインで使用できるようにする、認証情報タイプを設定する必要があります。 コレクションにはこの処理を実行するロールが含まれていますが、以下の最小設定を手動で実行できます。

• [Administration] > [Credential Types] > [New Credential Type] の順に選択します。
• 新しいタイプに「Cisco ACI」(または類似した名前) と名前を付けます。
• [Input Configuration (JSON)] に以下の内容を入力します。

{
 "fields": [
  {
   "id": "username",
   "type": "string",
   "label": "APIC Username",
   "secret": false
  },
  {
   "id": "password",
   "type": "string",
   "label": "APIC Password",
   "secret": true
  }
 ],
 "required": [
  "username",
  "password"
 ]
}

• [Injector Configuration (JSON)] に以下の内容を入力します。

{
 "env": {
  "ACI_PASSWORD": "{{ password }}",
  "ACI_USERNAME": "{{ username }}"
 }
}

• 保存します。

これで認証情報タイプが設定されたので、[Resources] > [Credentials] に移動して新しい認証情報を作成できます。結果は以下のようになります。

Ansible Tower インベントリーの準備

[Resources] > [Inventories] で新しい Ansible Tower インベントリーを作成します。インベントリーに名前と組織を指定し、[Save] をクリックします。[Sources] タブに移動して、新しいソースを作成します。

以下のすべての処理を実行します。

• ソースに名前を付けます。
• [Source] ドロップダウンで、[Sourced from a Project] を選択します。
• [Project] ドロップダウンで、先ほど追加したプロジェクトを選択します。
• [Inventory File] に aci.yml を入力します。このファイルはドロップダウンに表示されていない場合があります。その場合は、入力してください。
• [Overwrite] と [Overwrite Variables] ボックスをオンにして、同期したときに変更または廃棄されるものがあればその内容を上書きします。
• 保存します。

結果は以下のようになります。

このソースを同期すると、プラグインで処理を実行できるようになります。同期が成功すると、以下のようなインベントリーが作成されます。

各ホストには、以下のような hostvars が設定されます。

まとめ

すべてのセットアップが完了すると、指定された APIC の内側にある物理スイッチの完全なインベントリーが Ansible Tower で作成され、一部の基本情報がホスト変数として保存されます。

これだけの処理で、上記の最初の問題は解決されます。Ansible Tower でノードを追加すると、[Settings] > [License] 画面に表示されるノード数がそれに合わせて増加します。

2 番目の問題については、hostvars データを使用して Ansible Tower REST API を介したクエリを実行できます。Collection には、Python で作成された、この実行方法の例が含まれています。どのテクノロジーを選択しても、Ansible Tower に対して以下のアプローチで API を呼び出すことをお勧めします。

• GET api/v2/inventories/<inventory id>/hosts/
  1 回、インベントリー内のすべてのホストを取得するため
• GET api/v2/hosts/<host id>/variable_data/
  上記の呼び出しで見つかったホストごとに 1 回

このプロジェクトは、私の ACI Ansible Collection の一部として Ansible Galaxy で公開されています。または、アップストリーム GitHub ソースリポジトリを参照してください。免責事項として、これはコミュニティコンテンツであり、Ansible 認定コンテンツ FAQ に従い、Ansible Galaxy に公開された Collections は Ansible コミュニティによって公開された最新コンテンツであり、共同サポートの主張は一切伴わないことに留意してください。

これを使用してみたい方は、プラグインに関するマニュアルの全文をご覧になり、使用に関するその他の詳細をご確認ください。

インベントリープラグインの開発について詳細情報を知りたい場合は、Ansible 開発者ガイドをご確認ください。「Managing Meaningful Inventories」という AnsibleFest 2019 のプレゼンテーション資料も、概念を大局的に理解するためにお勧めします。

最後に、最近の Cisco のブログ記事「What's New and Exciting on Cisco ACI with Red Hat Ansible」に目を通しておくこともお勧めします。