Sean Cavanaugh がすでに Infoblox に関するブログ投稿で紹介したように、Ansible 2.5 のリリースでは、Infoblox の自動化を可能にする lookup プラグイン、動的インベントリースクリプト、および 5 つのモジュールが導入されました。Role でこのモジュールと lookup プラグインを使用すれば、強力な DNS 自動化フレームワークを構成できます。

概要

今回は、Ansible を使用して Infoblox コアネットワークサービスを自動化して、IP アドレスの管理と、ネットワーク上のトラフィックのルーティングを簡単に、迅速に、そして確実に行う方法を説明します。仮想化環境とクラウド環境のネットワークシステムでは、プロビジョニングのライフサイクルを短くする必要があります。Ansible で Infoblox を管理すれば、この作業を自動化できます。Ansible と Infoblox のインテグレーションは、柔軟かつ強力です。モジュール、または Infoblox WAPI REST API への直接コールを使用して Infoblox タスクを自動化できるようになりました。

ここでは、Ansible と Infoblox でネットワークタスクを簡素化できる、実際の環境で使用される 6 つのシナリオを紹介します。

1. 複数の Role で再利用可能なプロバイダーを 1 つ作成する。
2. 正引き DNS ゾーンで新しいサブネットを作成し、ネットワークを拡張する。Infoblox 用の Ansible モジュールを使用すれば、この一般的な 2 つのタスクを簡単に行うことができます。
3. 逆引き DNS ゾーンを作成する。たとえば、関連アドレス名を持たない IP アドレスからのメールにフラグを付けるのに使用します。以前のバージョンの Ansible でこのタスクを行うには、Infoblox API へのコールを使用する必要がありましたが、Ansible v2.7 以降では、nios_zone モジュールでサポートされるようになりました。
4. Ansible の強力な Jinja2 テンプレートを使用して、新しいサブネットのゲートウェイアドレス用にホストレコードを予約する。
5. loop と host_count を使用して、サブネットに追加のホストを作成する。
6. 1 つの Infoblox アプライアンスでは足りない場合に、Infoblox Grid を管理してネットワークの規模拡大を自動化する。Grid は、管理しているネットワークを物理的に分散させ、単一障害点を取り除きます。

ここで紹介する例を実際に Infoblox デバイスで使用するには、dynamic-infoblox Role をインストールして、Infoblox 認証情報をプロバイダーとして設定する必要があります。

Infoblox 認証情報および nios_provider

Ansible で Infoblox を管理するために Infoblox lookup プラグインまたはモジュールを呼び出した場合は、Infoblox の IP、ユーザー名、パスワードを指定する必要があります。こちらの Role では、この認証情報が全て設定されている nios_provider を呼び出します。nios_provider ディクショナリーをグループ変数として作成したら、playbook や role にその認証情報を参照する一行を追加することで、設定されている値を常に適用できるようになります。

group_vars/all/main.yml
nios_provider:
   #Infoblox out-of-the-box defaults specified here
    host: 192.168.1.2
	username: admin
	password: infoblox
wapi_version: “v2.7”

モジュールを使用して、サブネットおよび正引き DNS ゾーンを設定

認証情報が準備できたら、Infoblox の動的な Role を使用する playbook を実行して、サブネットと正引き DNS ゾーンを作成できます。これは、Ansible モジュールを使用すれば簡単にできます。サブネットの作成は一般的なネットワークプロジェクトです。管理者は、サブネットを使用して、会社の新しい支社、オフィス、または事業部門に合わせて、ネットワークを拡張できます。正引き DNS ゾーンは、アドレス名から IP アドレスへの一方向マッピングを確立します。(イギリスなど) 別の国に事業進出したり、合併した場合など、新たな DNS ゾーンが必要になる場合があります。以下のタスクでは、ansible_subnet と ansible_zone を変数として定義しているため、新しいサブネットを作成するたびに上書きできます。

- name: Create a test network subnet
  nios_network: 
 	network: "{{ ansible_subnet }}"
 	comment: Test network subnet to add host records to
 	state: present
 	provider: "{{ nios_provider }}"

- name: "Create a forward DNS zone called {{ ansible_zone }}"
  nios_zone: 
 	name: "{{ ansible_zone }}"
 	comment: local DNS zone
 	state: present
 	provider: "{{ nios_provider }}"

この例では、デフォルトの Infoblox View を使用しています。Infoblox では、1 つの DNS ゾーンに複数の View を設定できます。たとえば、内部トラフィックをオンプレミスサーバーに送り、外部トラフィックをパブリックのクラウドサーバーに送る場合は、DNS の View を 2 つ使用する DNS ゾーンを設計します。このように設定すれば、社員用のイントラネットが、顧客が使用するサーバーの負荷にならないため、地理的範囲が広がり、レベルの高いサービスを24時間提供できるようになります。ただし、上述の簡単な例 (および後続の例) では、デフォルトの View を使用しています。

Infoblox API を使用して逆引き DNS ゾーンを設定

ここまでのセクションで、Ansible モジュールを使用して Infoblox への変更を自動化する方法を説明しました。次の例では、Infoblox の WAPI REST API を使用して、現行バージョンの Ansible では使用できないタスクを自動化する方法を説明します。逆引き DNS ゾーンを使用すると、相当する IP アドレスが分かっている場合に、クライアントがアドレス名を調べることができます。逆引きゾーンの重要性に関する簡単な例としては、たとえばメールサーバーでは、多くの場合、逆引き DNS を介した関連アドレス名を持たない IP アドレスからの入力トラフィックに、スパムフラグを付けることができます。ほかにも、会社の web サイトに訪れる企業に関する確実なデータを集めることができます。

以前のバージョンの Ansible の nios_zone モジュールでは正引き DNS ゾーンが作成できましたが、最新バージョンでは逆引きゾーンだけが作成できます。ただし、以前のバージョンの Ansible でも、このタスクを自動化することはできます。Ansible を、WAPI API へのコール作成にのみ使用するのです。このコールの作成には、uri モジュールまたは shell モジュールから実行するシェルスクリプトを使用できますが、uri モジュールを使用することをお勧めします。インテグレーションをより記述的にとらえ、標準の REST 戻りコードを活用する冪等性が保証された API コールを利用できるためです。ここで uri モジュールは、Ansible モジュールエコシステムの中で簡潔に WAPI コールを 1 つを呼び出すラッパーモジュールとして機能します。WAPI API は、Ansible モジュールにおける JSON データの入出力のように機能します。この API コールの本文を yaml で表現する場合は、Jinja2 フィルター (後で詳しく説明します) を使用して、ランタイム時に JSON に変換すると簡単にできます。

- name: Create a reverse DNS zone to complement forward zone
  uri: 
	url: https://{{ nios_provider.host }}/wapi/{{ wapi_version }}/zone_auth
	method: POST
	user: "{{ nios_provider.username }}"
	password: "{{ nios_provider.password }}"
	body: "{{ reverse_zone_yml | to_json }}"
	#201 signifies successful creation
	#400 signifies existing entry
	#both signify a successful WAPI call
	status_code: 201,400
	headers: 
    	Content-Type: "application/json"
	validate_certs: no
  register: reverse_dns_create
  changed_when: reverse_dns_create.status == 201
  vars: 
	reverse_zone_yml: 
  	fqdn: "{{ ansible_subnet }}"
  	zone_format: "IPV4"

ホストレコードを作成する前にサブネット、正引きゾーン、および逆引きゾーンを作成し、正引きゾーンにホストレコードを作成すると、対応する逆引きゾーンエントリーが自動的に作成されます。ここまでで、ネットワーク、正引きゾーン、逆引きゾーンを定義できたので、次に新しいサブネットのホストレコードを作成します。

Jinja2 テンプレートを使用してゲートウェイアドレスを予約

ホストレコードを作成する際、ゾーンの最初 (または最後) のホストレコードをゲートウェイアドレス (周辺ネットワークの外にある IP アドレスに向かうデータのパケットを転送するアドレス) として予約します。上述したように、そこで簡単な python 関数を呼び出し、Jinja2 フィルターを使用してデータを扱います。Jinja2 フィルター構文では、linux のパイプが効果的に使用されます。Jinja2 フィルターを使用すればデータを迅速に扱えるようになりますが、ここでは 2 つのフィルターを使用して、Infoblox ゲートウェイアドレス命名規則を順守します (以下の例を参照)。通常、各サブネットにはゲートウェイアドレスが指定されているため、ゲートウェイアドレス名が重複するのを防ぐために、サブネットに対してゲートウェイアドレス名を定義します。

- name: Create a host record for the gateway address
  nios_host_record: 
 	name: “gateway{{ ansible_subnet | ipaddr(‘first_usable’) |
  replace(".","_") }}.{{ ansible_zone }}”
 	ipv4: 
    	- address: "{{ gateway_address }}"
 	state: present
 	provider: "{{ nios_provider }}"

このタスクでは、複雑な Jinja2 表現を使用して、ゲートウェイのホスト名をステップバイステップで構築できます。Ansible のパッケージに含まれる jinja フィルターの ipaddr では、ルーチンの IP アドレスに関する操作が多数含まれているため、さまざまな用途に使用できますが、たとえば、IP の範囲が 192.168.1.0/24 で、ansible_zone が ansible.local の場合に上記のタスクのフィルターを使用すると、名前が 1 行で作成されます。

1. 表現は “gateway” から開始。
2. セクションで、
   • a. テンプレート化された ansible_subnet 値を取得
     

     ansible_subnet => 198.168.1.0/24

   • b. 取得した ansible_subnet 値を、フィルタープラグイン ipaddr(‘first_usable’) に渡し、最初に利用できる IP を取得
     

     192.168.1.0/24 | ipaddr(‘first_usable’) => 192.168.1.1

   • c. 取得した IP のドットを、アンダースコアに変更
     

     192.168.1.1 | replace(‘.’, ‘_’) => 192_168_1_1

   • d. サブネット値の前に区切り文字 . を追加
   • e. テンプレート化された ansible_zone の値を取得
     

     ansible_zone => ansible.local

サンプルのテンプレートから、上述にリストされる値をゲートウェイホスト名は、以下のようになります。

gateway192_168_1_1.ansible.local

Jinja2 フィルターは、Ansible のトピックの中でも複雑なものなので、自分で Jinja2 フィルターを構築する場合は Ansible の基本知識をきちんと押さえておく必要があります。フィルターを作成する場合は、playbook や role で実際に使用する前に、ローカルで期待値をテストできます。もしくは、Sivel’s Ansible Template Tester でもフィルターの結果を確認できます。

loop と host_count を使用してホストレコードを生成

ゲートウェイアドレスが予約できたら、loop を使用して、ホストレコードを指定した数だけ生成します。実際の環境では、サブネットには 1 台のサーバーではなく、サーバーグループ (データベースサーバー、アプリケーションサーバーなど) を作成するケースがほとんどでしょう。ここでは、ユーザーが入力したhost_count 値に基づいて一般的なホストレコードを動的に生成する loop を定義します。このデモでは、lookup プラグインの nios_next_ip を使用します。このプラグインは、次に利用可能な IP を 1 つ、または次に利用可能な IP の範囲を取得して割り当てます。この両方のタスク (ゲートウェイアドレスにホストレコードを作成する上述のタスクと、ホストを生成する以下のタスク) を使用した Playbook では、host_count を定義しないとホストレコードは作成されず、ゲートウェイアドレスだけが作成されます。

#Generating records this way should be for demo purposes
#Normal scenario would be to iterate over a dictionary/list of hosts or populate via a static csv file
- name: “Dynamically generate {{ host_count }} host records at next available ip in {{ ansible_subnet }}”
  include_tasks: host_record_generation.yml
  loop_control:
 	loop_var: count
  with_sequence: start=1 end={{ host_count }}
  when: host_count is defined

Ansible を使用し、ユーザーが入力したホスト数に合わせてホストレコードを生成すると、ホスト数に基づいて loop が発生するため、2 回目の実行時にインデックスの問題が発生する可能性はありますが、この問題は、ホストの生成数を保存することで解決できます。たとえば、コントロールノードに、ホストの合計数を静的ファイルとして保持する方法があります。Ansible の lookup プラグイン機能を利用してそのコンテンツを取得すると、ホストが生成されるたびに、このファイルの数値が増えるため、それにより発生するルール実行 (特に別のサブネットで自動化されている実行) により、互いのレコードを上書きすることがなくなります。

このようにホストレコードを生成することは、多くの企業で行われている、命名規則を使用してホストレコードを生成する方法とは異なりますが、lookup プラグインの nios_next_ip を使用して別のゾーンやサブネットにレコードを作成するのは簡単で、追加設定も必要ありません。Infoblox では、静的な csv レコードのインポート機能もサポートされます。

Ansible で Infoblox Grid を事前定義

上の 4 つのシナリオでは、ホストおよびサブネットの段階で Ansible がどのように Infoblox と連携するかを説明しました。規模を拡大するために、Ansible では Infoblox をどのように管理できるのでしょうか？ Infoblox インスタンスを 1 つ自動化すると値が提供されますが、プロダクション環境の Infoblox システムを Grid で設定することもしばしばあります。Infoblox Grid テクノロジーについては、Infoblox の web サイトで詳しく説明されています。Infoblox Grid は、個々またはペアになったアプライアンス間で分散関係を確立し、従来の DNS、DHCP、および IP アドレス管理インフラストラクチャーに存在する単一障害点などの運用上のリスクを取り除きます。各 Grid に含まれる Grid Master の数は 1 つですが、Grid Member または Grid Master Candidate は複数使用できます。Grid Member には、Infoblox データベースの中にある、このジョブを行うのに必要な部分だけが含まれますが、Grid Master Candidate には、Grid Master のデータベースがリアルタイムでフルコピーされるため、災害復旧機能として利用できます。Ansible の Role を使用すれば、以下のように、新しい Grid Master Candidate および Grid Member を事前に定義できます。

- name: Predefine a new Grid Master Candidate
  hosts: localhost
  connection: local
  roles:
	-  role: predefineGridmasterCandidate
   	master_candidate_name: gmc.ansible.local
   	master_candidate_address: 192.168.2.2
   	master_candidate_gateway: 192.168.2.254
   	master_candidate_subnet_mask: 255.255.255.0

- name: Predefine a new Grid Member
  hosts: localhost
  connection: local
  roles:
	-  role: predefineGridMember
   	member_name: m3.ansible.local
   	member_address: 192.168.2.3
   	member_gateway: 192.168.2.254
   	member_subnet_mask: 255.255.255.0

これまでの 5 つの例が示すように、Ansible と Infoblox は連携してネットワークインフラストラクチャーを管理し、トラフィックを迅速に、簡単に、確実に進めます。Ansible を使用して、Infoblox WAPI API の強固な機能を構築できます。Ansible モジュールと、WAPI API への直接コールを使用し、異なるネットワークを処理することを迅速に適用できるように、再利用可能な Ansible Role および Playbook を記述できます。ご興味を持った方は、ansible-networking repository で Role をカスタマイズできます。このリポジトリーには、ここで説明した Ansible の概念がすべて含まれています。

参考資料

Ansible ネットワーキングの詳細は Why Ansible Networking のページを参照してください。

Infoblox NIOS では、Cisco IOS、NX-OS、IOS-XR、Juniper JunOS、Arista EOS などがすでに設定されている Ansible Playbook を使用できます。詳細は Network modules を参照してください。

GitHub の Network Automation コミュニティーにご参加ください。こちらの宛先に GitHub ID をご連絡ください。

Red Hat Ansible Automation ポートフォリオについては、Red Ha Ansible Automation: Engine, Tower or Both のブログを参照してください。

ネットワークの自動化ついては、Ansible ドキュメントページを参照してください。