■ はじめに
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
のように、コンフィグをそのまま指定するタイプのモジュールではなく、コンフィグのオプションがオプションとして抽象化されたモジュールが対象のようです。
- ios の例
- junos の例
- eos の例
■ ちなみに・・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
オプションを利用したほうが良いと思いました。