cli_command でできること

cli_command を使用して、ネットワークデバイスで任意のコマンドを実行できます。こちらは、Arista vEOS デバイスに対して cli_command を使用する簡単な例です。

---
- name: RUN COMMAND AND PRINT TO TERMINAL WINDOW
  hosts: arista
  gather_facts: false

  tasks:

    - name: RUN ARISTA COMMAND
      cli_command:
        command: show ip interface brief
      register: command_output

    - name: PRINT TO TERMINAL WINDOW
      debug:
        msg: "{{command_output.stdout}}"

以前は eos_command モジュールを使用しなくてはならなかったため、次のようにする必要がありました。

---
- name: RUN COMMAND AND PRINT TO TERMINAL WINDOW
  hosts: arista
  gather_facts: false

  tasks:

    - name: RUN ARISTA COMMAND
      eos_command:
        commands: show ip interface brief
      register: command_output

    - name: PRINT TO TERMINAL WINDOW
      debug:
        msg: "{{command_output.stdout}}"

どちらの Ansible Playbook もシンプルで、アウトプットは同じになります。例えば次のようなものになります。

この時点では、これら 2 つの Playbook の外観にさほど違いはありません。しかし複数ベンダーの機器を操作する場合、新しい非依存型ネットワークモジュールを使用しないと、Playbook はあっという間に複雑なものになってしまいます。複数ベンダー混在環境を扱う Playbook は、以前は以下の 2 つのルートのいずれかをたどって複雑化していきました。1 つは、次のように多数の条件分岐 (when ステートメント) を連ねる方法。

- name: RUN ARISTA COMMAND
  eos_command:
    commands: show ip int br
  when: ansible_network_os == 'eos'

- name: RUN CISCO NXOS COMMAND
  nxos_command:
    commands: show ip int br
  when: ansible_network_os == 'nxos'

- name: RUN JUNOS COMMAND
  junos_command:
    commands: show interface terse
  when: ansible_network_os == 'junos'

もう 1 つの多少ましな方法を採った場合のネットワーク自動化 Playbook は次のようになります。

- name: RUN JUNOS COMMAND
  include_tasks: “{{ansible_network_os}}”

この 2 番目の方法は最初のものよりはるかにシンプルです。include_tasks が eos.yml、ios.yml、nxos.yml などの Ansible Playbook を呼び出し、対応するコマンドやタスクを実行します。対象ネットワーク・プラットフォームごとに別の Ansible Playbook を作成できることから、こちらの方が優れていると言えますが、非依存型モジュールを使った場合ほど簡潔でも簡単でもありません。非依存型モジュールを使うと、基本的な機能性はそのままに、Ansible Playbook がはるかにシンプルになります。

この include_tasks メソッドを取り上げたのは、非依存型モジュールを使用したとしても、Playbook ロジックの分離が必要になる場面は必ず出てくるからです。たとえば、上記の Juniper のコマンド (show interface terse) は、Arista や Cisco (show ip interface brief) とは異なります。

Cisco、Juniper、Arista を扱う上記の Playbook が、非依存型の cli_command を使うとどれだけシンプルになるかを見てみましょう。

---
- name: RUN COMMAND AND PRINT TO TERMINAL WINDOW
  hosts: routers
  gather_facts: false

  tasks:
    - name: RUN SHOW COMMAND
      cli_command:
        command: "{{show_interfaces}}"
      register: command_output

    - name: PRINT TO TERMINAL WINDOW
      debug:
        msg: "{{command_output.stdout}}"

最初の Playbook には 3 つの *os_command タスクがありましたが、それが 1 つのタスクにまとまりました。show_interfaces 変数は、プラットフォームごとにグループ変数として保存されています。完全版のサンプルは、こちらの GitHub リポジトリをご覧ください。

バックアップの例

cli_command モジュールのユースケースをもう 1 つ見てみましょう。ネットワーク運用で一般的に実施するタスクの 1 つに、ネットワーク構成のバックアップがあります。Ansible Network Automation モジュールには、このごくありふれた、しかし重要なタスクを自動化するのに役立つ backup パラメーターがあります。たとえば、Arista EOS では次のようにできます。

---
- name: BACKUP NETWORK CONFIGURATIONS
  hosts: arista
  gather_facts: false

  tasks:

    - name: BACKUP CONFIG
      eos_config:
        backup: yes

cli_command モジュールには backup パラメーターがありません。その理由は、backup パラメーターは時にきわめて柔軟性に乏しく、処理が難しいからです。Ansible への機能リクエストの中でも特に多く寄せられるものの 1 つが、すべての config モジュールでバックアップ先を設定できるようにすることです。しかし、各 config モジュールでとてつもない量のロジックやコードを再作成する代わりに、既存のモジュールを再利用することを考えてみましょう。この場合、すでに広く利用されている copy モジュールを活用できます。

---
- name: RUN COMMAND AND PRINT TO TERMINAL WINDOW
  hosts: arista
  gather_facts: false

  tasks:

    - name: RUN ARISTA COMMAND
      cli_command:
        command: show run
      register: backup

    - name: PRINT TO TERMINAL WINDOW
      copy:
        content: "{{backup.stdout}}"
        dest: "{{inventory_hostname}}.backup"

これにより、コマンド出力をより簡単に処理して保存できるようになります。ここでは running-config を対象としましたが、この方法なら startup-config に切り替えることも簡単にできます。また、この方法ならバックアップ先のディレクトリとファイル名も指定できます。Arista EOS、Juniper Junos、Cisco IOS のバックアップのための非依存型 Playbook の例は、https://github.com/network-automation/agnostic_example をご覧ください。

Ansible Network Automation Playbook をはるかに簡潔かつシンプルにする、非依存型モジュールの優れた活用法はまだまだたくさんあります。cli_comand および cli_config モジュールは、2018 年 10 月以降の Ansible プロジェクトに含まれています。まだの場合はアップグレードをご検討ください。すでに cli_command および cli_config モジュールを使用している場合は、ぜひ共有してください。今後のブログ記事では、非依存型モジュールを使用した例をさらに取り上げていきますので、お楽しみに。