ネットワークの自動化、何つかう？ 〜自動化ツール紹介〜 #APC勉強会 #30(2回目) 参加メモ

memo

ネットワークの自動化、何つかう？〜自動化ツール紹介〜　APC勉強会＃30(2回目) - connpass に参加してきたのでいつものメモ。1回目のときはぼんやりしていたらあっという間に満席になってしまったので2回目で滑り込みです。

資料は1回目の時に公開されているのでそちらを参照してください。

ネットワークの自動化、何つかう？〜自動化ツール紹介〜

はじめに
  • NW機器もAPIに対応して、自動化フレンドリーなものが増えてきた
  • そういう機械でなくても自動化できるツールやライブラリを紹介
    • netmiko
    • napalm
    • ansible
    • salt
全体像
  • 業務フロー : 作業, 実際に config 流し込むところの自動化
  • ツール依存イメージ
    • 構成管理ツール : ansible, salt
    • python ライブラリ : napalm, netmiko
  • 機能概要
    • netmiko, napalm : ライブラリ。抽象化の仕方が違う。
      • netmiko...直接コマンドを指定, napalm...ひとつのメソッドで複数のベンダのコマンドに相当
    • ansible, salt : ツール。抽象化の仕方が違う。
      • saltはnapalmの中で使っているのでベンダをお意識しなくても使えるようになっている
      • ansibleはモジュールによるけど、コマンドを直接呼ぶタイプのモジュールが多い
netmiko

netmiko

  • シンプルで薄い抽象化ライブラリ。
  • login, モード移行, commit などを共通メソッドとして抽象化。
    • "conf term" とかは抽象化されてる
    • 表示・設定コマンドはコマンドを直接指定する
  • netmiko 対応機種
    • けっこうある

コード例

  • 状態表示
    • enable メソッドで抽象化されてる
    • send_command で直接コマンドを送る
      • コマンド実行結果がそのままとれる (特に parse とかしない)
  • 設定変更
    • 設定コマンドも直接指定
    • send_config_set でコマンド文字列(リスト)を渡して実行

まとめ

  • シンプルで薄い
  • teraterm マクロよりは楽かな
    • waitとかプロンプトとか気にしなくていいので設定に注力
    • 対応機種は限られるので注意
napalm

napalm

  • 多機能で厚い抽象化ライブラリ
    • 一部だけど表示コマンド・設定コマンドまで抽象化
  • 対応機種
    • netmikoよりはすくない
  • 対応メソッド
    • サイトにある…使いたい嬉々とやりたい操作の対応をチェックすべし。

コード例

  • 状態表示
    • get_interfaces メソッド→IOSの場合は"show interface" : 抽象化されてる
    • コマンド実行結果も parse されて構造化されたデータとして取得
    • 違うOSでも共通のデータ構造で取得できる
  • 設定変更
    • load_template メソッド。テンプレートを呼び出して、パラメータを渡して、設定実行。

まとめ

  • 多機能で厚い
    • 一部設定と表示に関しても抽象化…対応していないものについては直接コマンド指定して実行することもできる。
Ansible

ansible

  • シンプルな構成管理ツール
  • 抽象化というアプローチは特にとっていない。
    • ベンダごとにモジュールがあるのでそれを使い分ける
    • netconf 対応などは今後注目
  • 特徴
    • agentless
    • yaml で構成定義 (playbook)...なってほしい状態を定義する
      • プログラムを書くわけではない
  • 対応機種
    • v2.3, napalm よりちょっと多い

playbook例(cisco ios module)

  • 状態表示
    • コマンドを直接指定して実行
    • 特に parse されるわけじゃない
  • 設定変更
    • コマンドを直接指定して実行
    • "changed=1", 既に設定が入っていれば "changed=0"

まとめ

  • シンプル
    • インストールも pip で一発。必要なファイルも最低二つ。
salt

salt

  • 多機能な構成管理ツール
    • 中で napalm を使っている……抽象化するアプローチ
    • ベンダごとのモジュールも出てきているけど主要なのは napalm を使う方法
  • 概要
    • master/agent 型
    • yaml で構成定義
    • 高機能 : イベントドリブン, スケジューラ, WebAPI
    • v2016.11.0 で napalm 統合 (NW機器対応)

Saltの主な用語

  • Master : 指示を出す
  • Minion : いわゆる Agent, master の指示を受ける
    • Master-Minion 間は MQ
    • NW機器対応をどうするか…Proxy Minion
    • Master → Proxy Minion → NW機器 (ssh等)
  • Grains : ホスト名、シリアル番号、バージョン番号などの基本的な情報を保存
  • Pillars : 任意のデータを保存できる

対応機種

  • 基本的には napalm と同じ

設定がちょっとややこしい

  • デバイスID → IPや認証情報は別ファイルで管理(proxy minion)

状態表示例

  • Grains から情報を引っ張ってくる
    • 内部で napalm キックして情報をとってくる
    • 構造化された情報がとれる

設定変更例

  • 定義ファイル実行
    • "changed=1"

デモ

  • 定義ファイルが更新されたら自動的に設定投入 : イベントドリブン
    • daemon で動いているのでファイル監視とかができる

まとめ

  • 多機能な構成管理ツール
各ツールの比較
  • ライブラリか、構成管理ツールか
  • 抽象化のアプローチ
  • メリット・デメリット
    • netmiko: 対応機種が多い。その分抽象化レベルは低い。
    • napalm: マルチベンダ環境の情報取得に強い…parseしてくれる。一方、設定系のメソッドがまだ少ない。足りないところは直接コマンド入力
    • ansible: シンプル! アプローチが違うので機種ごとにモジュールを使い分け。情報量が多い。開発が盛ん。
    • Salt: 高機能…イベントドリブンとかWebAPIとか。内部では napalm を使っているので、マルチベンダ情報取得に強いという特徴を。日本語情報は少ない。調べるときは公式ドキュメント頼み。

ツールつかいどころ選択

  • 管理したい危機に対応しているかどうか
  • コードを書くかどうか
    • コードにすると運用城南があるのであれば構成管理ツール系へ
  • シンプル or 高機能
    • 高機能 → 学習コストが高い
  • どの程度抽象化したいか
    • ターゲットが一つ二つであればそんなに抽象化気にしないのでは
  • 管理対象機器の種類・ベンダ数
    • 種類が多いほど、抽象化レベルが低いとベンダごとのコマンド使い分け・パターンが増える。
  • 既存で導入している構成管理ツールがあるならあわせる

まとめ

  • 特徴を把握して適材適所で
これから
  • 自動化を進めるにあたって: ツール・人・仕様
    • 人: 自動化するための設計・実装スキル、文化
    • ツール: 今回の話はここ
    • 仕様: api拡充、標準化
QA
  • dry-run/diff 表示
    • ansible, salt は dry-run できる。netmiko, napalm は自前で dry-run 動作を実装しないといけない。
  • ツールによる設定変更・管理のメリット
    • 設定要件→定義ファイルのexportなど、中間加工のしやすさ。デメリットとしてはyaml知らないといけないというのはある
  • excelからデータとれる?
    • 標準ではなさそう。やろうとおもえばやれる
  • commit の自動化って大丈夫?
    • 変なことすると途中で止まるとかはある。検証・dry-runしてチェックしたうえで実行とか、そのあとのテストなどでリスクヘッジしていく。アプリ開発の自動化とはこういった点で性質が異なる。
  • 表示コマンドの抽象化は必要か?
    • ケースバイケースではあるが、あると便利だと思う。自前で parse するのは大変。
  • 既存の自動化スクリプト+構成管理ツールでサーバとNWの一括管理というのがメリットがあるのでは
    • サーバ側を含めて、というのはメリットがあるだろう
  • 機器が対応していない場合のアプローチ?
    • paramiko (netmiko内部のssh module) ベースで自作, ansible module 自作、あたりか。
  • Ansible導入どうやってる?
    • 最初のハードル。インベントリファイルどう作るかとか。別なスクリプトかませないといけないかもしれない。最初の対応はちょっと泥臭い対応が必要になりそう。
  • 失敗時ロールバック?
    • 実装すれば全部可能。モジュールについては試していないが、junosのケースでは失敗時commitしないようになっているのでは?

所感

懇親会でも他の方と話をしたんですが、この辺のツールで気になるところはある程度共通だなあと。

  • エラー処理・例外処理
  • dry-run など実行前のチェックの可否

何かしらのカタチでコマンドを投げる、というところだけだとやっぱり実際動かしていシステムで使うのはちょっとねー、という話になる。あと、エラー処理とか例外処理とか、運用している側からすると、やりたいことそのものではないというのもあるかな。エラー処理とか対応手順とかはあるんだけど、CLIベースの機材に対してそれを自動化するための仕掛けそのものを作るのってハードル(手間的な)が高いんだよね…。ツールにあるエラーハンドリングの仕掛けの上でやりたいこと(やりたいエラー処理)に集中できるようにならないかな、と言う話とかね。