■ 1. 開催概要
2017/08/18 に 「ネットワークの自動化、何つかう?~自動化ツール紹介~(2回目)」という発表をしました。 取り扱ったツールは以下の通りです。
- 1.構成管理ツール
- その1:Ansible
- その2:SaltStack
- 2.Pythonライブラリ
- その1:Netmiko
- その2:NAPALM
7/21に実施した勉強会の追加開催というかたちです。
■ 2. 資料
発表に使用した資料はこちらです。1回目の資料より少しだけ追記しています。
www.slideshare.net■ 3. Q&A
当日頂いた質問とその回答です。
- 【Q1】dry-run (check mode) や diff 表示などはどうなっていますか?変更点を事前に確認できることは重要だと思います
- 【A1】dry-run についてはAnsibleやSaltは対応していますが、netmikoやNAPALMは自前で実装する必要があります。diffについてはAnsible、Salt、NAPALMは対応していますが、netmikoは自前で実装する必要があります。
- 【Q2】webサーバなどに比べNW機器の設定変更頻度は普通、非常に低いものと思います。生configではなくツールを使い、ツールの定義ファイルで設定を変更/管理するメリットはどのような点にあるとお考えでしょうか。
- 【A2】 定義ファイルであればフォーマットが決まっているので、プログラムからのエクスポートやインポートがしやすいメリットがあります。一方で、構文を覚える必要があるというデメリットもあります。
- 【Q3】デバイスタイプやログイン先のコードの部分は外部参照(Excelから取得)できるものでしょうか。
- 【A3】標準ではなさそうなので、自前で実装が必要になると思います。
- 【Q4】JANOGでも思ったのですが、「作業」の自動化でもやはり「commit」を自動化するのは非常に恐ろしいと思ってます(BGP shutやVLAN ADD等)。その点についてどう思われますか?
- 【A4】確かに恐ろしいと思います。そのため、事前や事後の確認でリスクを少なくする工夫をセットでしていく必要があると思います。
- 【Q5】設定の抽象化は捨ててもいいが、showやget系等の表示コマンドに対しての抽象化は全ベンダーに対しては到底ムリに近いと思っているが、表示コマンドの抽象化は必要だと思いますか? (個人的にはせっかく間にAnsible等の豊富なAPI持ってるソフトを使っているのだから、取得した情報を共通フォーマットでjsonなりでパースしたほうが連携したほうがいいと思っています)
- 【A5】表示コマンドの抽象化はできると便利だと思います。自力でパースするのは大変ですので。
- 【Q6】NW機器単独であればTeratermマクロやVBAによる自動化は独自でやっている事が多いので、構成管理ツールでサーバとNWの一括管理がメリットなきがしました。
- 【A6】 私もそう思います。「Ansibleは様々なエンジニアにとっての共通言語である」という言葉をどこかで聞いて印象的でした。
- 【Q7】機器が対応していない場合のアプローチは?paramiko使って自作?Ansibleモジュール自作?
- 【A7】はい。paramikoで自作か、Ansibleのモジュールを自作するなどの対応になります。
- 【Q8】すでに使っている機器の管理に Ansible などを導入する場合はどんな感じでやっていますか?
- 【A8】インベントリファイルをどう作るかが課題になると思います。スクリプトで生成するなど、導入時は少々泥臭い対応が必要になると思います。
- 【Q9】失敗時のロールバックに対応したものはありますか
- 【A9】JunosのようなOSであれば、OSの機能としてロールバックされます。
■ 4. 感じたこと
ネットワーク自動化について自分なりに考えて、利用できるツールを調べて試して、ということをおこなってきましたが、今までは設定の自動化に偏りがちでした。 様々な方の意見をお伺いして、「設定の自動化」と「安全性」はセットであるべきだという感がに至るようになりました。そのため、これからは状態確認やテスト、そもそもテストとは何か、のようなことも考えていきたいと思うようになりました。
お忙しい中お集りいただき、誠にありがとうございました。