Ansible Network Team によってメンテナンスされているネットワークモジュール一覧は以下のページにまとめられています。
Modules Maintained by the Ansible Network Team — Ansible Documentation
(参考リンク)
なお、サポートされないものも含めたネットワークモジュールは以下のページにまとめられています。
Ansible 2.4 から、ネットワークモジュールの一部で、繰り返しを伴う設定を効率的に投入できる aggregate というオプションが利用できるようになりました。 この記事では、既存の with_items による繰り返しとの比較を通じて、動作の紹介をします。
検証環境は Ansible 2.5.2 です。
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 オプションが利用できます。
公式ドキュメント内に一覧は見当たりませんでしたが、*_config や *_commmand のように、コンフィグをそのまま指定するタイプのモジュールではなく、コンフィグのオプションがオプションとして抽象化されたモジュールが対象のようです。
繰り返し処理というと 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 |
|---|---|---|
| 利用可能バージョン | 2.4以上 | |
| 利用可能モジュール | 一部 | すべて |
| 処理速度 | 早い | 遅い |
パラメータエラー時 (junos_static_route で確認) |
1つも設定されない | エラー分のみスキップ |
個人的には aggregate オプションのほうが早いですし、よりフェールファーストらしい挙動になるので、利用できるモジュールの場合は特徴を理解した上で、 aggregate オプションを利用したほうが良いと思いました。
2018/04/26 に開催された Ansible Night in Tokyo 2018.04 で「Junosモジュールのコネクションタイプの使い分け」という発表をさせていただきました。
Ansible 2.5 で、ネットワークモジュール向けに network_cli 、 netconf という2つのコネクションタイプが追加され、Junos モジュールではどちらも使用できます。
今回の発表ではこれらのコネクションタイプの使い分け方をご紹介しました。
この記事では私の発表資料の共有や、他の方の発表資料、ブロガー枠の方の記事の紹介などをまとめます。
私が発表に使用した資料はこちらです。
www.slideshare.net
他の方の資料は以下のページにアップされています。
www.slideshare.net
www.slideshare.net
ブロガー枠（一般参加枠より倍率が低く参加しやすい）で参加された方のレポート記事です。 smallpalace.hatenablog.com
来日されていた Red Hat の Sean Cavanaugh さんによる通常セッション「Ansible 2.5 のアップデートとネットワーク自動化」の内容と一部被ってしまうではないかと、内心ハラハラしていたのですが、 結果的には Sean さんの発表の一部を深掘りして日本語でお届けでできた、とかたちになったのでホッとしました。
そしてコメント頂き嬉しかったです。
Some great slides from @akira6592 on JunOS and @ansible pic.twitter.com/Ab7SUrBRaA
— Sean Cavanaugh (@IPvSean) 2018年4月26日
2018/04/20 に開催された JANOG41.5 Interim Meeting で「もっと気軽に始めるAnsible」という発表をさせていただきました。
Ansible はネットワーク機器にも対応しています。YAML形式の定義ファイル（Playbook）を書かずに、もっと気軽に始められる Ad-Hoc な Ansible の使い方をご紹介します。
今回は、Playbook もインベントリファイルも、設定ファイルも作らず、意地でもコマンドで済ませるというポリシーです。
この記事では、発表資料の共有とサンプルコマンドの再掲、感想をまとめます。
発表に使用した資料はこちらです。
Jストリーム様のご協力により発表の動画も公開されました。私の発表は 1:23:20 頃からです。
他の方の発表の分も JANOG41.5 connpass イベントページ に掲載されています。
資料中に掲載されているサンプルコマンドをコピペしやすいように、以下に再掲します。
# Ansible のインストール pip install ansible # Junosモジュールで必要なpythonモジュールのインストール pip install ncclient jxmlease
# 実行結果を json にする export ANSIBLE_STDOUT_CALLBACK=json # ansible コマンドでも前述の設定を有効にする export ANSIBLE_LOAD_CALLBACK_PLUGINS=True # （オプション）接続対象ホストキーがAnsibleホストに未登録の場合は、ホストキーチェックを無効化 export ANSIBLE_HOST_KEY_CHECKING=False
ansible -i 172.16.0.1, all \ -m junos_command \ -a "commands='show configuration'" \ -c netconf -u root -k \ -e ansible_network_os=junos \ | jq -r ".plays[0].tasks[0].hosts[].stdout[0]" > config.txt
# （オプション）接続対象ホストキーがAnsibleホストに未登録の場合は、ホストキーチェックを無効化 export ANSIBLE_HOST_KEY_CHECKING=False
ansible -i 172.16.0.1,172.16.0.2 all \ -m junos_config \ -a "lines='set system ntp server 172.16.0.123'" \ -c netconf -u user1 -k \ -e ansible_network_os=junos
資料中に掲載されているリンクをジャンプしやすいように、以下に再掲します。
Run Your First Command and Playbook — Ansible Documentation
仮想Junos4台とAnsibleホストをVagrantで構築するVagrantfile tekunabe.hatenablog.jp
仮想ネットワーク機器のオンラインラボサービスの使い方 tekunabe.hatenablog.jp
Ansible でNW機器を操作したい時に参考になりそうな日本語情報 tekunabe.hatenablog.jp
私の発表時のツイートは P13 の 18:23 あたりからです。
発表の反応を拝見すると「ワンライナー的な使い方もアリだな」ですとか「Cisco IOSで試してみた」という方々がいらっしゃって嬉しかったです。
@akira6592 さんの「もっと気軽に始めるAnsible」の発表に触発され、Cisco IOSでも試してみました。事前準備なくAnsibleを試せるので、楽でいいですね。 #janoghttps://t.co/1jdYHlLDPq pic.twitter.com/mMmGroj3nT
— kooshin (@kooshin) 2018年4月20日
ネットワークエンジニアが Ansible を触ってみる入り口の一つとして、今回の発表が参考になったら幸いです。
さて、JANOG は前回のJANOG 41が初参加でした。ネットワーク運用自動化BoF内で発表もさせ頂いたので、2回連続で機会をいただきました。ありがとうございました。
次回 JANOG 42 は、2018/07/11-13 に三重で開催されます。次回も参加する予定です。
Safety‐1 & Safety‐2―安全マネジメントの過去と未来
Safety-1 は、うまくいかない要因を排除しようという考え方の安全マネジメント。 Safety-2 は、うまくいく理由を理解して、うまくいくようにしようという考え方の安全マネジメント。Safety-2 の考え方に興味を持ったので読みました。
たとえば、インシデントのなぜなぜ分析は良くすると思いますが「うまくいったことのなぜなぜ分析」はしたことありますでしょうか？読みながらそんな問いかけを思い浮かべました。
うまくいったことは認識しずらく、測定もしずらい。けれど、そこと向き合うのが Safety-2。
難しく、飲み込みきれない部分も多いですが、考え方の枠が広がった気がします。 ほかの分野にも応用できる部分もありそうです。
2018/04/04、書籍「カイゼン・ジャーニー」の第1部「一人から始める」をテーマにしたイベントに参加してきました。
公式レポート kaizenjourney.jp
書籍
著者の新井剛さん、市谷聡啓さんのぞれぞれの経験をもとにした発表と、事前のアンケートで寄せられたお題をもとにした座談会（5人程度のグループディスカッション）という構成でした。
当たり前のことを当たり前にやった、ちょっと勇気を持ってやっているのかも、という点が印象的でした。 最近、当たり前のこと向き合う意味、難しさ、他の真似だけではだめ・・などなど考える事があったため、勇気をもらいました。
www.slideshare.net
「これからはソロの時代」「所属から提供へ」という言葉が印象的でした。 私自身もちょっと人と違うことをすることを好んでしている節があるので、そういう意味では自ら進んでぼっちになっているのかもしれません。 ですが、それを誰かに伝えて表現することで、ひょっこり同じことしてくれる人が出てくるということを感じているので、こういうのも悪くないなと思っています。
ぼっちからのはじめ方、巻き込み方、組織風土などをテーマにディスカッションしました。 他のグループや、著者への質疑応答含めて気になったものは以下です。
参加者含めて、非常に熱のある集まりだと感じました。 一方で、このような社外のコミュニティだけでなく、もっと身近な自社にも自分が知らないだけで、同じような思いの人がいるのではという問いかけを自分にしました。 偶然、翌日に似たようなテーマで同僚と話すこと機会があり、色々共感を得られたのがとても嬉しかったです。 今後は社内にも目を配ってみようと思いました。
Ansible には callback plugin という仕組みがあり、結果出力の形式を変更したりすることができます。
ansible-playbook コマンドでは、ansible.cfg で stdout_callback の指定を、ansible コマンドではこれに加え bin_ansible_callbacks = True という指定が必要です。
この記事では、それぞれの例をご紹介します。
例えば、 json という callback plugin を指定して ansible-playbook コマンド実行する例を見てみます。
stdout_callback で json を指定します。
stdout_callback = json
なお、環境変数として設定する場合は export ANSIBLE_STDOUT_CALLBACK=json を実行します。
念のため ansible-config コマンドで設定を確認します。
[vagrant@centos7 vagrant]$ ansible-config dump | grep CALLBACK DEFAULT_CALLBACK_PLUGIN_PATH(default) = [u'/home/vagrant/.ansible/plugins/callback', u'/usr/share/ansible/plugins/callback'] DEFAULT_CALLBACK_WHITELIST(default) = [] DEFAULT_LOAD_CALLBACK_PLUGINS(default) = False DEFAULT_STDOUT_CALLBACK(/etc/ansible/ansible.cfg) = json ← json になった
ここでは junos_command モジュールで show version を実行する Playbook を実行します。
[vagrant@centos7 vagrant]$ ansible-playbook -i inventory junos_test.yml { "plays": [ { "play": { "id": "525400da-a710-c40b-4624-000000000008", "name": "junos" }, "tasks": [ { "hosts": { "172.16.0.1": { "_ansible_no_log": false, "_ansible_parsed": true, "changed": false, "invocation": { (～略～) }, "stdout": [ "Hostname: vsrx1\nModel: firefly-perimeter\nJUNOS Software Release [12.1X47-D15.4]" ], "stdout_lines": [ [ "Hostname: vsrx1", "Model: firefly-perimeter", "JUNOS Software Release [12.1X47-D15.4]" ] ] } }, "task": { "id": "525400da-a710-c40b-4624-00000000000a", "name": "show version" } } ] } ], "stats": { "172.16.0.1": { "changed": 0, "failures": 0, "ok": 1, "skipped": 0, "unreachable": 0 } } }
このように、JSON 形式で結果が出力されます。
ansible コマンド（ad-hocコマンドとも呼ばれる） でも、callback plugin を指定する場合は、stdout_callback 以外にも bin_ansible_callbacks という設定も必要です。
stdout_callback で json を指定するのに加え、 bin_ansible_callbacks を True に指定します。
stdout_callback = json bin_ansible_callbacks = True
なお、環境変数として設定する場合は export ANSIBLE_LOAD_CALLBACK_PLUGINS=True を実行します。
念のため ansible-config コマンドで設定を確認します。
[vagrant@centos7 vagrant]$ ansible-config dump | grep CALLBACK DEFAULT_CALLBACK_PLUGIN_PATH(default) = [u'/home/vagrant/.ansible/plugins/callback', u'/usr/share/ansible/plugins/callback'] DEFAULT_CALLBACK_WHITELIST(default) = [] DEFAULT_LOAD_CALLBACK_PLUGINS(/etc/ansible/ansible.cfg) = True ← True になった DEFAULT_STDOUT_CALLBACK(/etc/ansible/ansible.cfg) = json
ここでは junos_command モジュールで show version を実行する ansible コマンド を実行します。
[vagrant@centos7 vagrant]$ ansible -i 172.16.0.1, all -m junos_command -a "commands='show version'" -c netconf -u root -k SSH password: (パスワードを入力) { "plays": [ { "play": { "id": "525400da-a710-ece8-5deb-000000000007", "name": "Ansible Ad-Hoc" }, "tasks": [ { "hosts": { "172.16.0.1": { "_ansible_no_log": false, "_ansible_parsed": true, "changed": false, "invocation": { (～略～) }, "stdout": [ "Hostname: vsrx1\nModel: firefly-perimeter\nJUNOS Software Release [12.1X47-D15.4]" ], "stdout_lines": [ [ "Hostname: vsrx1", "Model: firefly-perimeter", "JUNOS Software Release [12.1X47-D15.4]" ] ] } }, "task": { "id": "525400da-a710-ece8-5deb-000000000009", "name": "" } } ] } ], "stats": { "172.16.0.1": { "changed": 0, "failures": 0, "ok": 1, "skipped": 0, "unreachable": 0 } } } [vagrant@centos7 vagrant]$
無事に ansible コマンドでも json 形式で出力できました。
json callback plugin を利用する場合を例にまとめます。
[defaults] stdout_callback = json
export ANSIBLE_STDOUT_CALLBACK=json
[defaults] stdout_callback = json bin_ansible_callbacks = True
export ANSIBLE_STDOUT_CALLBACK=json export ANSIBLE_LOAD_CALLBACK_PLUGINS=True
