Blog
Ansible 2.4 でネットワークプログラマビリティな運用を考える
こんにちは。アドテクスタジオでネットワークエンジニアをしている山本 孔明です。
サイバーエージェントのアドベントカレンダー 2017 の3日目を担当しています。kubernetesの話が続きましたが、少しニッチなところでAnsible 2.4 でネットワークプログラマビリティな運用についての記事を書いてみます。
はじめに
以前に私がネットワーク周りで触っていた時は、row コマンドで任意のコマンドを流すくらいしかできなかったのですが、ansible も2.0以降になってネットワーク機器の操作がだいぶ使いやすくなってきました。ネットワークはいまだこういった自動化の絡みで遅れを取っており、サーバの世界で当たり前のことがなかなか進んでないのが現状かなと思っていましたが、最近はできることが増えてきたという印象です。
アドテクスタジオの環境ですが、パブリッククラウドとプライベートクラウドを適材適所で利用しております。プライベートクラウドを利用する場合にデータセンターのネットワークを運用していくわけですが、SNMP や Syslog を使った単純な監視だけですと監視には不十分なことが多々あります。ちなみにデータセンターネットワークの監視については以下の記事もありますので、気になった方は覗いてみてください。
実際のコマンドを叩いてその出力を定期的に取得したいという時に、定期ジョブの中で Ansible を使って運用を回しています。SNMP や Syslog では不十分な場合はレアケースかと思いますが、レアケースの監視が必要な時というのは Bug や原因が特定できない状態を監視しないといけない時だと思いますので、非常に重要なことかと思います。
row コマンドを使って取得してもメーカーごとに違う形式でベタ書きの情報が出力されますし、不要な情報も入ってきます。データが扱いやすい形で取得する方が監視においても良いと思いますので、今回はネットワーク機器の出力をいい感じに parse してくれる ntc-templates を紹介したいと思います。
参考までに、Cisco（Catalyst） と Brocade（VDX）の出力のサンプルを貼っておきます。メーカーにより情報も違いますし、欲しい情報を探すのも面倒ですね。
- Cisco（Catalyst） の show version の出力
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 |
Cisco IOS Software, C3750E Software (C3750E-UNIVERSALK9-M), Version 15.0(1)SE2, RELEASE SOFTWARE (fc3) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2011 by Cisco Systems, Inc. Compiled Thu 22-Dec-11 00:05 by prod_rel_team ROM: Bootstrap program is C3750E boot loader BOOTLDR: C3750E Boot Loader (C3750X-HBOOT-M) Version 12.2(58r)SE1, RELEASE SOFTWARE (fc1) sv1idc1sw19 uptime is 28 weeks, 2 days, 6 hours, 39 minutes System returned to ROM by power-on System restarted at 18:12:44 JST Thu May 18 2099 System image file is "flash:/c3750e-universalk9-mz.150-1.SE2/c3750e-universalk9-mz.150-1.SE2.bin" This product contains cryptographic features and is subject to United States and local country laws governing import, export, transfer and use. Delivery of Cisco cryptographic products does not imply third-party authority to import, export, distribute or use encryption. Importers, exporters, distributors and users are responsible for compliance with U.S. and local country laws. By using this product you agree to comply with applicable laws and regulations. If you are unable to comply with U.S. and local laws, return this product immediately. A summary of U.S. laws governing Cisco cryptographic products may be found at: http://www.cisco.com/wwl/export/crypto/tool/stqrg.html If you require further assistance please contact us by sending email to export@cisco.com. License Level: ipbase License Type: Permanent Next reload license Level: ipbase cisco WS-C3750X-48 (PowerPC405) processor (revision A0) with 262144K bytes of memory. Processor board ID AAAAAAA Last reset from power-on 1 Virtual Ethernet interface 1 FastEthernet interface 104 Gigabit Ethernet interfaces 4 Ten Gigabit Ethernet interfaces The password-recovery mechanism is enabled. 512K bytes of flash-simulated non-volatile configuration memory. Base ethernet MAC Address : AA:AA:AA:AA:AA:AA Motherboard assembly number : 11-11111-11 Motherboard serial number : AAAAAAA Model revision number : A0 Motherboard revision number : C0 Model number : WS-C3750X-48T-S Daughterboard assembly number : 111-11111-11 Daughterboard serial number : AAAAAAA System serial number : AA Top Assembly Part Number : 111-11111-11 Top Assembly Revision Number : AA Version ID : AAA CLEI Code Number : AAAAAAA Hardware Board Revision Number : 0x05 Switch Ports Model SW Version SW Image ------ ----- ----- ---------- ---------- * 1 54 WS-C3750X-48 15.0(1)SE2 C3750E-UNIVERSALK9-M Configuration register is 0xF |
- Brocade（VDX）の show version の出力
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
Network Operating System Software Network Operating System Version: 4.0.1 Copyright (c) 1995-2012 Brocade Communications Systems, Inc. Firmware name: 4.0.1b Build Time: 22:48:47 Feb 13, 2099 Install Time: 15:19:03 May 8, 2099 Kernel: 2.6.34.6 BootProm: 2.2.0 Control Processor: e500v2 with 2048 MB of memory Appl Primary/Secondary Versions ------------------------------------------ NOS 4.0.1b 4.0.1b |
手順
ここからは具体的な説明です。機能としては ansible 2.4 から追加された parse_cli_textfsm を使います。手順は以下の通りです。
- virtualenv などの環境を用意して、ansible 2.4 をインストールしてください
- ntc-templates を clone します
- ansible の ios_command モジュールを使ってデータを取得
- 3 のデータを parse_cli_textfsm + ntc-templates で整形
ntc-templates ですが、templates/cisco_asa_show_version.template を見るとわかるのですが、正規表現を使ってバージョン情報だったり OS のイメージ名など必要となる情報を変数として取得しています。
3 の ansible のタスクに記載する内容はとてもシンプルです。ざっと記載すると、show version して register で result に出力結果を保存しているだけです。cisco 機器の場合、 ansible 2.1 から追加された ios_command で任意のコマンドの出力を取得可能です。今回は、その出力結果を ntc-templates で parse します。ios_command って中で何やっているのか気になった場合は、こちらを確認してみてください。他には module_utils の ios.py や機器との接続の部分は connection.py あたりを見ておくとより良いかと思います。
|
1 2 3 4 5 |
- name: "show ver" ios_command: commands: ['show version'] provider: "{{ cli }}" register: result |
その結果を parse します。
|
1 2 3 |
- name: "stdout_command" debug: msg="{{ result.stdout[0] | parse_cli_textfsm('./ntc-templates/templates/cisco_ios_show_version.template')}}" |
出力イメージは以下のとおりです。ベタな出力を json 形式で出力してくれます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
{ "192.168.1.1": { "_ansible_no_log": false, "_ansible_verbose_always": true, "changed": false, "failed": false, "msg": [ { "CONFIG_REGISTER": "0xF", "HARDWARE": [ "WS-C3750X-48", "WS-C3750X-48T-S" ], "HOSTNAME": "switch", "ROMMON": "Bootstrap", "RUNNING_IMAGE": "/c3750e-universalk9-mz.150-1.SE2/c3750e-universalk9-mz.150-1.SE2.bin", "SERIAL": [ "AAAAAAA" ], "UPTIME": "1 year, 33 weeks, 10 hours, 30 minutes", "VERSION": "15.0(1)SE2" } ] } |
json 形式で取れるのでとにかくデータが扱いやすいです。ここから必要データを取得するのも容易です。何より ntc-templates には arista, brocade, dell, cisco, juniper, hp, paloalto などのメーカーのテンプレートが割と充実しているので、一から自分で作らなくて良いです。ただ、メーカーによって対応しているコマンドの量には偏りもあるので、私は一部自作でテンプレートを作成して運用しております。
活用事例
例えば、 DELL Force 10 のVLT (Virtual Link Trunking) 機能の出力などを定期的に取得し、サーバとの接続が片系になったことを監視したりしています。サーバ側のリロードなどある際に、syslog や SNMP では即時飛んできます。サーバのメンテナンスする際の監視を止めるのは手間で、サーバ向けのインタフェースは SNMP Trap の通知をしない運用をしていました。
ただ、気付いたら3ヶ月くらい 片側のNIC が DOWN してたよねという状態に陥るリスクもあるので、1日に一回 jenkins で ansible を叩いて監視をしています。おかしなステータスになっていた場合、Slack の webhook でアラートチャンネルで通知をしています。元々のスイッチからの出力は以下の通りです。
|
1 2 3 4 5 6 7 |
Local LAG Id Peer LAG Id Local Status Peer Status Active VLANs ------------ ----------- ------------ ----------- ------------- 4 4 UP UP 10 8 8 UP UP 10 12 12 UP UP 10 16 16 UP UP 10 20 20 UP DOWN 10 |
V1日に一回 SNMP のポーリングでいいのではと思う方もいるかと思いますが、筐体跨ぎのLAGで片方だけが DOWN している時にだけ通知するのは SNMP のポーリングでも単純には検知ができないので、こういった監視方法がマッチしているかと思います。
他にも、過去の障害として、MAC アドレステーブルの学習ポートがおかしくなるという恐ろしい Bug に遭遇したことがあり、その Bug 対応のため一時的に MAC アドレステーブルで Gateway の MAC アドレステーブルが正しくが学習されているか確認しています。こちらは通知だけでなく、運用として MAC アドレステーブルのクリア job に繋げる準備もしていました（再発する前に Version UP で対処できたので発動はせずでしたが）
まとめ
元のテンプレートがある程度あるので、欲しいものがないなという物だけこちらで自作すればいいので断然楽です。作成したテンプレートについては綺麗にして PR あげておこうかと考えています。
こちらへ記載した内容は、監視だけでなくホスト表やポート表などの作成も面倒だったりするので GAS を使ってスプレッドシートにデータを入れるなど更なる活用方法は多々あるかと思います。他にも LLDP から情報を引っ張り、サーバとネットワーク機器のインタフェースのマッピングを MySQL などに入れておけば、何個か活用できることが思いつきますね。こういった仕組みを一から作る場合は、頻度との兼ね合いではこれらを自動化するより手で記載していった方が良いかという結論にもなりやすいですが、ある程度テンプレートがあるので工数はかなり減らせます。
冒頭に記載したのですが、ネットワークの世界ではメーカーやソフトウェアに依存しない技術での自動化が進んでいない印象が強く、こういった活用事例が増えてくると良いかなと思っています
Author
