この翻訳記事は Ansible 公式ブログである THE INSIDE PLAYBOOK の記事、RED HAT ANSIBLE NETWORK AUTOMATION UPDATESを、筆者であるSean Cavanaughさん及びRed Hat の許可を得て翻訳したものです。
先日、今まで最大の AnsibleFest は成功を収めました。Ansible Engine 2.6、Ansible Tower 3.3、そして直近の Ansible Engine 2.7 のリリースで Red Hat の エンジニアリングチームが行った大きな機能拡張について、ネットワーク自動化の観点で振り返ってみたいと思います。すべての Ansible を愛するすべての人のためのリマインダーとして、アップグレードをなるべく簡単に行うためのポーティングガイドがあります！
このブログ記事では、以下の内容を説明します。
- HTTPAPI コネクションプラグイン
- 新しいネットワーク自動化モジュール
- 改善された Ansible Tower のユーザーエクスペリエンス
- ネットワーク機器のための認証情報の管理
- Ansible Tower のための カスタム Ansible 環境のサポート
HTTPAPI コネクションプラグイン
コネクションプラグインは、Ansible がターゲットホストに接続して、タスクを実行できるようにします。
Ansible 2.5 のリリースでは、netwrok_cli コネクションプラグインが導入されました。これにより、provider パラメーターが不要になり、ネットワークモジュールの標準化によって Linux ホストと同じように Playbook を作成し、操作できるようになりました。また、Red Hat Ansible Tower では、ネットワーク機器でも他の機器と同じように「machine credentials」を扱えるようになりました。もう「network credentials」は不要です。以前のブログ記事でも説明されていましたが、Linuxサーバー、Arista EOS スイッチ、Cisco ルーターでも、同じようにユーザー名やパスワードなどの認証情報を使用、保存できます。
しかし、eAPI や NX-API 経由の接続方法は、これまで従来の provider 方式の接続方法しかサポートされていませんでした。Ansible 2.6 ではこの制限がなくなり、代わりにトップレベル（訳注: conneciton: httpapi や ansible_connection: httpapi のような指定） の httapi 接続が利用できるようになりました。
どのようになるか見てみましょう。
まず、httpapi 接続を利用するために、ネットワーク機器側で eAPI や NX-API を有効にする必要があります。 幸い、これは Asnible でとても簡単にできてしまいます！ ad-hoc コマンドは素早く Arosta EOS スイッチの eAPI を有効にできます。
[user@rhel7]$ ansible -m eos_eapi -c network_cli leaf01
leaf01 | SUCCESS => {
"ansible_facts": {
"eos_eapi_urls": {
"Ethernet1": [
"https://192.168.0.14:443"
],
"Management1": [
"https://10.0.2.15:443"
]
}
},
"changed": false,
"commands": []
}
Arista EOS スイッチに実際に接続すると、show management api http-commands コマンドで API が有効になっていることがわかります。
leaf01# show management api http-commands Enabled: Yes HTTPS server: running, set to use port 443 <<< ...略...>>>
以下の Playbook は単純な show version コマンドを実行し、デバッグ文ではコマンドタスクから与えられた JSON 出力の中からバージョンだけを返します。
--- - hosts: leaf01 connection: httpapi gather_facts: false tasks: - name: type a simple arista command eos_command: commands: - show version | json register: command_output - name: print command output to terminal window debug: var: command_output.stdout[0]["version"]
Playbook を実行すると、以下のような結果になります。
[user@rhel7]$ ansible-playbook playbook.yml
PLAY [leaf01]********************************************************
TASK [type a simple arista command] *********************************
ok: [leaf01]
TASK [print command output to terminal window] **********************
ok: [leaf01] => {
"command_output.stdout[0][\"version\"]": "4.20.1F"
}
PLAY RECAP***********************************************************
leaf01 : ok=2 changed=0 unreachable=0 failed=0
補足ですが、短縮コマンド（例:「show version」に対する「show ver」）は Arista eAPI では実行できません。完全なコマンドを使用する必要があります。httapi コネクションプラグインの詳細については関連ドキュメントを参照してください。
新しいネットワーク自動化モジュール
Ansible 2.6 と今後リリースされる 2.7（訳注: 2018/10/4リリース済み）には、7 つの新しいモジュールがあります。
net_get と net_put
- net_get - ネットワーク機器から Ansible コントローラーにファイルをコピーする
- net_put - Ansible コントローラーからネットワーク機器にファイルをコピーする
- netconf_get - NETCONF が有効なネットワーク機器から設定や状態を取得する
- netconf_rpc - NETCONF が有効なネットワーク機器上で操作を実行する
- netconf_config - NETCONF が有効なネットワーク機器に設定XMLファイルを送信して設定し、変更を検出する。
- cli_command - CLI ベースのネットワーク機器上で CLI コマンドを実行する
- cli_config - テキストベースのコンフィグを network_cli 経由で ネットワーク機器に送る
net_get と net_put モジュールは、標準的な SCP や SFTP 転送プロトコル（protocol パラメーターで指定）を使用して、ネットワーク機器との間でファイルをコピーする、ベンダー非依存型のモジュールです。
どちらのモジュールも、 network_cli 接続方法を使用する必要があります。また、Ansible コントローラー上で scp がインストール(pip install scp)され、ネットワーク機器上で SCP（または SFTP）が有効になっている必要があります。
この Playbook を動作させるために、 あらかじめ Leaf01 で以下のことを実行したと仮定します。
leaf01#copy running-config flash:running_cfg_eos1.txt Copy completed successfully.
ここでは、2つのタスクからなる Playbook を見ていきます。最初のタスクは、 Leaf01 からファイルをコピーし、2つ目のタスクは Leaf01 へファイルをコピーします。
--- - hosts: leaf01 connection: network_cli gather_facts: false tasks: - name: COPY FILE FROM THE NETWORK DEVICE TO ANSIBLE CONTROLLER net_get: src: running_cfg_eos1.txt - name: COPY FILE FROM THE ANSIBLE CONTROLLER TO THE NETWORK DEVICE net_put: src: temp.txt
netconf_get、netconf_rpc、netconf_config
- netconf_get - NETCONF が有効なネットワーク機器から設定や状態を取得する
- netconf_rpc - NETCONF が有効なネットワーク機器上で操作を実行する
- netconf_config - NETCONF が有効なネットワーク機器に設定XMLファイルを送信して設定し、変更を検出する。
Network Configuration Protocol (NETCONF) は、IETF によって開発、標準化されたネットワーク管理プロトコルです。RFC 6241 として定義されているように、NETCONF はネットワーク機器の設定をインストール、操作、削除を行うことができます。NETCONF は SSH 接続によるコマンドライン (netowrk_cli)や、Cisco NX-API と Arista eAPI (httpapi)のような機器の API の代わりになるものです。
新しい netconf モジュールを紹介するために、まず junos_netconf モジュールを利用して、Juniper ルーターの netconf を有効にします。すべてのネットワーク機器が netconf をサポートするわけではありませんので、対象のプラットフォームをサポートしているベンダーのドキュメントを確認してください。
[user@rhel7 ~]$ ansible -m junos_netconf juniper -c network_cli
rtr4 | CHANGED => {
"changed": true,
"commands": [
"set system services netconf ssh port 830"
]
}
rtr3 | CHANGED => {
"changed": true,
"commands": [
"set system services netconf ssh port 830"
]
}
Juniper Networks は Operational Tags や、Configuration Tags を確認するために Junos XML API Explorer を提供しています。Juniper Network のドキュメントに例示されている、特定のインターフェースへの RPC リクエストの操作例を見てみましょう。
<rpc> <get-interface-information> <interface-name>ge-2/3/0</interface-name> <detail/> </get-interface-information> </rpc> ]]>]]>
これは、とてもきれいに Playbook に変換できます。get-interface-informatio は RPC 呼び出しで、content パラメーターの配下には、キーと値のペアからなる追加パラメーターを定義します。この場合、interface-name という1つのオプションがあり、インターフェース em1.0 だけを見ます。debug モジュールを利用してターミナル上に結果を出力するために、register というタスクレベルのパラメーターを使用して結果を保存します。netconf_rpc モジュールは、XML の戻り値を直接 JSON に変換することもできます。
--- - name: RUN A NETCONF COMMAND hosts: juniper gather_facts: no connection: netconf tasks: - name: GET INTERFACE INFO netconf_rpc: display: json rpc: get-interface-information content: interface-name: "em1.0" register: netconf_info - name: PRINT OUTPUT TO TERMINAL WINDOW debug: var: netconf_info
Playbook を実行すると、以下のように返されます。
--- - name: RUN A NETCONF COMMAND hosts: juniper gather_facts: no connection: netconf tasks: - name: GET INTERFACE INFO netconf_rpc: display: json rpc: get-interface-information content: interface-name: "em1.0" register: netconf_info - name: PRINT OUTPUT TO TERMINAL WINDOW debug: var: netconf_info <<< ...略...>>>
Juniper プラットフォームについての詳細は、 Juniper Platform Guide を参照してください。 netconf コネクションプラグインについての詳細は、 NETCONF documentation を参照してください。
cli_command と cli_config
- cli_command - CLI ベースのネットワーク機器上で CLI コマンドを実行する
- cli_config - テキストベースのコンフィグを network_cli 経由で ネットワーク機器に送る
Aniable Engine 2.7 リリースで利用可能な cli_commandとcli_config モジュールは、ネットワークプラットフォームを自動化するベンダー非依存型のモジュールです。これらのモジュールは、適切な cliconf プラグインを使用するために、 ansible_network_os 変数（インベントリファイルや group_vars ディレクトリ内で定義）を使用します。これにより、ネットワーク自動化のプレイブックのベンダー中立性が向上します。すべての ansible_network_os の値のリストは、ドキュメントを参照してください。このリリースではプラットフォーム固有のモジュールは廃止されないため、既存の Playbook を更新するために急ぐことはありません！詳細については、公式のポーティングガイドを参照してください。
Playbook がどのようになるか見てみましょう。
この Playbook は IOS-XE が動作している Cisco Cloud Services Routers (CSR) に対して実行します。
ansible_network_os 変数は、インベントリーファイルの中で ios に設定します。
<インベントリーファイル抜粋> [cisco] rtr1 ansible_host=34.203.197.120 rtr2 ansible_host=34.224.60.230 [cisco:vars] ansible_ssh_user=ec2-user ansible_network_os=ios
こちらが cli_config と cli_command モジュールを利用した Playbook です。
--- - name: AGNOSTIC PLAYBOOK hosts: cisco gather_facts: no connection: network_cli tasks: - name: CONFIGURE DNS cli_config: config: ip name-server 8.8.8.8 - name: CHECK CONFIGURATION cli_command: command: show run | i ip name-server register: cisco_output - name: PRINT OUTPUT TO SCREEN debug: var: cisco_output.stdout
最後に、Playbook の実行結果はこのようになります。
[user@rhel7 ~]$ ansible-playbook cli.yml
PLAY [AGNOSTIC PLAYBOOK] *********************************************
TASK [CONFIGURE DNS] *************************************************
ok: [rtr1]
ok: [rtr2]
TASK [CHECK CONFIGURATION] *******************************************
ok: [rtr1]
ok: [rtr2]
TASK [PRINT OUTPUT TO SCREEN] ****************************************
ok: [rtr1] => {
"cisco_output.stdout": "ip name-server 8.8.8.8"
}
ok:
[rtr2] => {
"cisco_output.stdout": "ip name-server 8.8.8.8"
}
PLAY RECAP **********************************************************
rtr1 : ok=3 changed=0 unreachable=0 failed=0
rtr2 : ok=3 changed=0 unreachable=0 failed=0
上記の出力を見ると、適切なネットワーク機器に対応するコマンド構文を使用している限り、モジュールが冪統( idempotent/idempotency) であることにお気づきでしょう。
改善された Ansible Tower のユーザーエクスペリエンス
Red Hat Ansible Tower 3.3 のリリースでは、Web ユーザー・インタフェースがより機能的に改善され、少ないクリック数で多くの作業を完了できるようになりました。アップグレードされた Ansible Tower 3.3 にログインすると、刷新された UXが現れます。
認証情報の管理、ジョブスケジューリング、インベントリースクリプト、ロールベースのアクセス制御 (RBAC) 、通知などは、左メニューからワンクリックで行えるようになりました。ジョブビューでは、開始時間、ジョブを開始したユーザー、ジョブが実行されたインベントリー、Playbook が取得されたプロジェクトなどの詳細情報が最上位に表示されます。
ネットワーク機器のための認証情報の管理
Red Hat Ansible Tower 3.3 では、ネットワーク機器のための認証情報の管理が以前より簡単になりました。 新しい Web UIでは、 Credentials メニューを1クリックするだけでアクセスできます。左メニューの Resources の下の Credentials を選択してください。
以前までは Network と呼ばれる認証情報タイプがありました。これは、従来の provider 方式で利用する環境変数 ANSIBLE_NET_USERNAME と ANSIBLE_NET_USERNAME を設定するものです。Ansible Tower の Credentials の章に記載されているとおり、既存の Playbook のためにまだ完全にサポートされています。しかし、新しい httpapi と network_cli 接続方法ではNetwork という認証情報タイプはもう必要ありません。ユーザー名とパスワードは、 Ansible が標準の Linux ホストに接続するのと同じように利用されます。そのため、Machine 認証情報タイプはネットワーク機器にも利用できるようになりました。Machine 認証情報 を選択し、ユーザー名とパスワード（または SSH 鍵）を入力するだけです。
注意: 認証情報に一度保存すると、Ansible Tower はパスワードを暗号化します。
暗号化によって、平文パスワードを見られることなく、個人またはグループに認証情報を利用してもらうことができます。認証情報の仕組みや、使用されている暗号化、その他の認証情報タイプ（Amazon AWS、Microsoft Azure、Google GCEなど）についての詳細は、関連のAnsible Tower のドキュメントを参照してください。
新しい Red Hat Ansible Tower 3.3 についての詳細な説明についてはChris Short によるこちらのブログ記事を参照してください。
Ansible Tower のためのカスタム Ansible 環境のサポート
もし、いくつかの Playbook は Ansible Engine 2.4.2 で、また別の Playbook はAnsible Engine 2.6.4 で実行したい場合は、どうしたらよいでしょうか？このようなユースケースのために、 Ansible Tower は virtualenv を利用します。Virtualenv は、依存関係やバージョンの違いよる問題を避けるために、隔離された Python環境を作るツールです。Ansible Tower 3.3 のリリースでは、Organization、Project、Job Template のレベルで、virtualenv を設定できるようになりました。Ansible Tower でネットワーク機器のバックアップを行う Job Template を見てみましょう。
Ansible Tower に複数の virtualenv による仮想環境が設定されると、Web UI に Ansible Environment のドロップダウンメニューが表示されます。これにより、特定のジョブをどのバージョンの Ansible で実行するかを簡単に選べるようになります。
もし、provider 方式による Playbook（Ansible 2.4 以前）と、httpapi や network_cli といったコネクションプラグインによる新しい Playbook（Ansible 2.5 以降）が混合しているネットワーク自動化の Playbook 群がある場合、各ジョブに異なるバージョンの Ansible を簡単に割り当てることができます。また、他のユースケースとしては、開発環境とプロダクション環境との間で Ansible のバージョンが異なる場合が考えられます。
別の考え方をすると、Ansible Tower をアップグレードしても、利用できる Ansible Engine のバージョンが1つに固定されるわけではない、ということです。
これにより、さまざまな種類のネットワーク機器、環境、ユースケースを自動化するための柔軟性がより向上します。
Ansible Tower で virtualenv を使用する方法の詳細については 関連ドキュメントを参照してください。
お礼
Ansible Networking チームは、今後リリース予定（訳注: 2018/10/04リリース 済み）の Ansible 2.7 に興奮しています。また、これを支えてきた全てのネットワーキングパートナーとコミュニティメンバーに温かい感謝の気持ち伝えたいです。 あなたのフィードバックやご意見、アイディアをお待ちしています。そして、Ansible networking community への参加を歓迎します。
翻訳者コメント
Ansible は、2016年リリースの Ansible 2.1 でネットワーク機器に標準対応しました。最近は、単にモジュールや対応プラットフォームの追加だけでなく、ベンダー非依存型のモジュールの登場や、ネットワークモジュール固有の Playbook の書き方（provider オプションによる接続情報の指定）の排除など、全体的な機能の底上げが図られてきているように感じています。
本記事では、このような最近の動向がまとめられていて有益な記事だと感じ、日本語でも共有したく翻訳を申し出しました。許可をいただきありがとうございました。
Mr. Sean Cavanaugh, Thank you for a wonderful blog post.
私も独自に Ansible 2.7 でのネットワークモジュールのアップデート情報をまとめた記事がありますので、あわせてご参照ください。 tekunabe.hatenablog.jp
なお、Red Hat Ansible Engine の参考価格や総合的な日本語情報はこちらです。 www.redhat.com
