■ はじめに
Ansible 2.4 から、ネットワークモジュールの一部で、繰り返しを伴う設定を効率的に投入できる aggregate
というオプションが利用できるようになりました。 この記事では、既存の with_items
による繰り返しとの比較を通じて、動作の紹介をします。
検証環境は Ansible 2.5.2 です。
■ aggregate オプションの利用例
aggregate
オプションは以下のような利用の仕方になります。(junos_static_route
モジュールでの例)
サンプル
- name: set static route
junos_static_route:
aggregate:
- { address: 172.16.1.0/24, next_hop: 10.0.0.1 }
- { address: 172.16.2.0/24, next_hop: 10.0.0.2 }
- { address: 172.16.3.0/24, next_hop: 10.0.0.3 }
雰囲気である程度予想できるかもしれませんが、上記の場合3つのスタティックルートが追加されます。
junos_static_route
モジュールにはもともと、 address
や next_hop
などのオプションがあり、それらを繰り返し指定するために、 aggregate
オプション配下に指定する形になります。
実行結果
(ansible25) [vagrant@centos7 vagrant]$ ansible-playbook -i inventory junos_test.yml
PLAY [junos] ****************************************************************************
TASK [set static route (aggregate)] *****************************************************
changed: [172.16.0.1]
PLAY RECAP ******************************************************************************
172.16.0.1 : ok=1 changed=1 unreachable=0 failed=0
(ansible25) [vagrant@centos7 vagrant]$
ポイントは、スタティックルートを追加する処理を3回繰り返すのではなく、1回の処理で完了 している点です。
これは、繰り返し分のコンフィグを生成してから、1つのタスクとしていっぺんにコンフィグ投入するためです。
仮に、特定の1つのスタティックルートにパラメータエラーがあった場合は、3つのスタティックルートとも設定が入りません。
ネットワーク機器側の確認
念のため確認します。
root@vsrx1# show routing-options static | display set
set routing-options static route 172.16.1.0/24 next-hop 10.0.0.1
set routing-options static route 172.16.2.0/24 next-hop 10.0.0.2
set routing-options static route 172.16.3.0/24 next-hop 10.0.0.3
無事に追加されました。
■ aggregate オプションが利用できるモジュール例
一例ですが、以下のようなモジュールで aggregate
オプションが利用できます。
公式ドキュメント内に一覧は見当たりませんでしたが、*_config
や *_commmand
のように、コンフィグをそのまま指定するタイプのモジュールではなく、コンフィグのオプションがオプションとして抽象化されたモジュールが対象のようです。
■ ちなみに・・with_items の場合
繰り返し処理というと with_items
や loop
(Asnible2.5から利用可)を思い浮かべると思います。先程のサンプルを with_itmes
で記載すると以下のようになります。
サンプル
- name: set static route (with_items)
junos_static_route:
address: "{{item.address}}"
next_hop: "{{item.next_hop}}"
with_items:
- { address: 172.16.1.0/24, next_hop: 10.0.0.1 }
- { address: 172.16.2.0/24, next_hop: 10.0.0.2 }
- { address: 172.16.3.0/24, next_hop: 10.0.0.3 }
実行結果
(ansible25) [vagrant@centos7 vagrant]$ ansible-playbook -i inventory junos_test.yml
PLAY [junos] ****************************************************************************
TASK with_items) ***********************************************************************
changed: [172.16.0.1] => (item={u'next_hop': u'10.0.0.1', u'address': u'172.16.1.0/24'})
changed: [172.16.0.1] => (item={u'next_hop': u'10.0.0.2', u'address': u'172.16.2.0/24'})
changed: [172.16.0.1] => (item={u'next_hop': u'10.0.0.3', u'address': u'172.16.3.0/24'})
PLAY RECAP ******************************************************************************
172.16.0.1 : ok=1 changed=1 unreachable=0 failed=0
(ansible25) [vagrant@centos7 vagrant]$
おなじみの with_items
らしいログとなりました。
仮に、特定の1つのスタティックルートにパラメータエラーがあった場合は、そのスタティックルート以外は設定されます。
■ aggregate と with_items の比較
まとめると以下のようになります。
比較項目 |
aggregate |
with_items |
利用可能バージョン |
2.4以上 |
|
利用可能モジュール |
一部 |
すべて |
処理速度 |
早い |
遅い |
パラメータエラー時 (junos_static_route で確認) |
1つも設定されない |
エラー分のみスキップ |
■ まとめ
個人的には aggregate
オプションのほうが早いですし、よりフェールファーストらしい挙動になるので、利用できるモジュールの場合は特徴を理解した上で、 aggregate
オプションを利用したほうが良いと思いました。
参考資料(公式ブログ)
www.ansible.com