■ はじめに
現在開発中の Ansible 2.7 (develブランチ) で、ネットワーク機器への 参照系コマンドを実行するモジュール cli_command が登場したことを知りました。
Ansible 2.7 の ROADMAP を眺めていたときにモジュール名だけは見たことがあったのですが、実際に devel にマージされたようなので、Junos と IOS で試した結果を記載します。
なお、同じく Ansible 2.7 で開発中の 設定系 コマンドを投入するモジュール cli_config については「Ansible 2.7 で導入予定のネットワークモジュール cli_configを試す」をご参照ください。
基本情報
cli_command モジュール 公式ドキュメント
cli_command - Run a cli command on cli-based network devices — Ansible Documentation
対応プルリク
github.com
コード (cli_command.py)
ansible/cli_command.py at devel · ansible/ansible · GitHub
※現在(2018/8/7)開発中のため、仕様が変わる可能性があります。後日確認時点で、リストで指定する commands オプションから、文字列で指定する command オプションに変更されています。詳細は、公式ドキュメントをご参照ください。
■ 準備（開発版 Ansible のインストール）
pip install git+https://github.com/ansible/ansible.git@devel
現在、これで開発中の Ansible 2.7 がインストールされます。
■ Juniper Junos で試す
インベントリファイル
以下のインベントリファイルを用意します。今回は各変数は Playbook 内で定義することにします。
[junos]
172.16.0.1
Playbook
今回は、show version コマンドの結果を画面に表示するだけの、以下の Playbook を用意します。
ポイントは、コネクションタイプに network_cli を指定するところです。通常の、Junos に対しては、netconf を指定して、NETCONF で接続することが多いかと思いますが、 cli_command モジュールは netconf には対応していません。
他、ansible_network_os 変数も（私が）忘れがちですが、指定します。
- hosts: junos
gather_facts: no
tasks:
- name: command test
cli_command:
commands:
- show version
register: result
- name: debug
debug:
msg: "{{ result.stdout_lines[0] }}"
vars:
ansible_connection: network_cli
ansible_network_os: junos
ansible_user: testuser
ansible_ssh_pass: testuserpsss
実行
無事に実行され、 show version の結果が表示されました。
(ansible27) [vagrant@centos7 vagrant]$ ansible-playbook -i inventory junos_27.yml
PLAY [junos] ***************************************************************************
TASK [command test] ********************************************************************
ok: [172.16.0.1]
TASK [debug] ***************************************************************************
ok: [172.16.0.1] => {
"msg": [
"Hostname: vsrx1",
"Model: firefly-perimeter",
"JUNOS Software Release [12.1X47-D15.4]"
]
}
PLAY RECAP *****************************************************************************
172.16.0.1 : ok=2 changed=0 unreachable=0 failed=0
なお、ansible_connection: netconf を指定した場合は、以下のエラーになります。
connection type netconf is not valid forthis module
インベントリファイル
Junosのときと同様、変数は Playbook 内で定義することにします。
[ios]
172.16.0.2
Playbook
- hosts: ios
gather_facts: no
tasks:
- name: command test
cli_command:
commands:
- show version
register: result
- name: debug
debug:
msg: "{{ result.stdout_lines[0] }}"
vars:
ansible_connection: network_cli
ansible_network_os: ios
ansible_user: testuser
ansible_ssh_pass: testuserpass
実行
無事に実行され、 show version の結果が表示されました。
(ansible27) [vagrant@centos7 vagrant]$ ansible-playbook -i inventory ios_27.yml
PLAY [ios] *******************************************************************************************************************
TASK [command test] **********************************************************************************************************
ok: [172.16.0.2]
TASK [debug] *****************************************************************************************************************
ok: [172.16.0.2] => {
"msg": [
"Cisco IOS XE Software, Version 16.08.01a",
"Cisco IOS Software [Fuji], Virtual XE Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 16.8.1a, RELEASE SOFTWARE (fc1)",
"Technical Support: http://www.cisco.com/techsupport",
"Copyright (c) 1986-2018 by Cisco Systems, Inc.",
"Compiled Tue 03-Apr-18 18:43 by mcpre",
(...略...)
]
}
PLAY RECAP *******************************************************************************************************************
172.16.0.2 : ok=2 changed=0 unreachable=0 failed=0
■ Junos も IOS もまとめて試す
お気づきかもしれませんが、前述の Junos 向け Playbook と、IOS 向け Playbook の差分は、 hosts と ansible_network_os しかありません。そのため、変数定義の方法を工夫することで、Playbook は1つにまとめる事ができます。
準備するファイルは、インベントリファイル、変数ファイル、Playbook です。
イベントリファイル
[junos]
172.16.0.1
[ios]
172.16.0.2
変数ファイル
ansible_connection: network_cli
ansible_network_os: junos
ansible_user: testuser
ansible_ssh_pass: testuserpass
ansible_connection: network_cli
ansible_network_os: ios
ansible_user: testuser
ansible_ssh_pass: testuserpass
もっと工夫の余地がありますが、あまりファイル数が増えてもサンプルとして見通しが悪くなるため、この辺にしておきます。
Playboook
前述のプラットフォーム別の Playbook との違いは hosts: all にしたことと、変数定義をしなくなったことです。
これでプラットフォーム固有の記述はなくなりました。
- hosts: all
gather_facts: no
tasks:
- name: command test
cli_command:
commands:
- show version
register: result
- name: debug
debug:
msg: "{{ result.stdout_lines[0] }}"
実行
1つの Playbook で Junos、IOS の両方の show version コマンドの結果を表示することができました。
(ansible27) [vagrant@centos7 vagrant]$ ansible-playbook -i inventory all_27.yml
PLAY [all] ************************************************************************************
TASK [command test] ***************************************************************************
ok: [172.16.0.1]
ok: [172.16.0.2]
TASK [debug] **********************************************************************************
ok: [172.16.0.2] => {
"msg": [
"Cisco IOS XE Software, Version 16.08.01a",
"Cisco IOS Software [Fuji], Virtual XE Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 16.8.1a, RELEASE SOFTWARE (fc1)",
"Technical Support: http://www.cisco.com/techsupport",
"Copyright (c) 1986-2018 by Cisco Systems, Inc.",
"Compiled Tue 03-Apr-18 18:43 by mcpre",
(...略...)
]
}
ok: [172.16.0.1] => {
"msg": [
"Hostname: vsrx1",
"Model: firefly-perimeter",
"JUNOS Software Release [12.1X47-D15.4]"
]
}
PLAY RECAP *********************************************************************************
172.16.0.1 : ok=2 changed=0 unreachable=0 failed=0
172.16.0.2 : ok=2 changed=0 unreachable=0 failed=0
■ まとめ
簡単ですが、 cli_command モジュールの動作を確認しました。
最近のネットワークモジュールは、プラットフォームに依存しないタイプ（内部で ansible_network_os変数を見てプラットフォーム固有モジュールを呼ぶ？）も増えてきており、 cli_command モジュールもその流れだと思います。
