いうあたりがきっかけ。みたいな話もいろんなところで聞かれるようになった気がしますが、そもそもこういう話が出る以前って、ネットワークの管理や自動化というと何をどうしてたんだっけ......という話を振り返ってみてもいいんじゃないかなと思ってきました。いう記事が回ってきたり、いくつかフラグが重なった感*1があるので、勢いでまとめてみます。複数ベンダ・複数製品が混在するヘテロな環境で運用管理・オペレーション・自動化......を考えるときに、機器ごとに異なる処理を吸収・隠蔽して、統一的な操作ができる抽象化レイヤを作ってやろうよ、というのは割とみんな前からやってるはず。頼らざるを得ないという話があると思います。やれるわけでもない)。ベースオペレーションというのになってしまう、という話もあるかな。操作の自動化ってなにをどうするのか、というと、対話処理の自動化をやるツールを使って、人の代わりにプログラム(プロセス)が応答する処理を記述することになります。いうよりはそれと同等の実装を使うことになるでしょう。個人的には過去こういうのを書いています。ルータ操作まあほかにもツール探すといろいろ出てくるんですが。探すと、こういう素の操作をやると言うよりは、もうちょっと特定の製品とか向けに(それこそCisco機器向けに、とか)機能を追加したライブラリとかがいろいろ見つかると思います。CLI自動化の落とし穴この手の処理を作ったことのあるほとんどの人が、これから列挙していくようなところではまったことがあると思います*2。いうバッドノウハウ系の話をいつまでもみんなで繰り返すのって不毛だよね。ベース自動化に頼らざるを得ないところはあるだろうけど、これからやる人のために、こういうところがつらいから気をつけてね、というのをまとめます。いう処理をやったことがない人は、これを見て、「あ、これだめなやつや」と思ってもらえればいいです。関連の話題でマネジメントプレーンのプロトコルや新しい標準、それを使った自動化、という話がなぜいろいろ出ているのか、理解の助けになればいいなあと思います。会話対象のプロセス(NW機器)が返してくる文字列を比較(正規表現マッチ)して、応答を返すべきかどうかを判断します。人間側が入力を入れるべきところがどこなのか、をあらかじめ知っておく必要があります。通常は何かしらの「プロンプト」です。プロンプトの種類が多い上にデバイスやOSバージョンや特定のコマンドごとにまちまち。するので、その辺考慮しつつプロンプトマッチ正規表現を組み立てる必要があったり。手順ベースなので順序を知っておかなければいけない。出るのかでないのかで処理実装を変えないといけない。その前の操作履歴で保存していなければ出るし、保存済みなら出ないし、とか、機材によってはそもそも聞かないものがいたりする。みたいに複数のプロンプトを順に出してくるようなものは、特定コマンドに対するサブプロンプトマッチ、しかも多段のものが処理できないといけない。mscore#エラーの把握、エラーメッセージ処理コマンドを入力したらエラーが返ることがあるわけですが、そのエラーすらもコマンド実行時の出力を見て正規表現マッチかけて把握する必要があります。機器やOSバージョンごとにエラーメッセージやフォーマットが違う。実際同じ製品ラインでもバージョン違うとエラーメッセージやメッセージフォーマットが変わってるとかあるからねえ...。やったら、コンフィグ中の特定の文字列がプロンプト正規表現にマッチしてしまって、プロンプトが出ていないところで次のコマンドを送ってしまう。プロンプト固有の文字を使っていて予期せぬプロンプトマッチおきるとか...処理シーケンスがずれてしまう...問題はコンフィグ中に直接プロンプト文字列が指定されている(正規のプロンプト文字列が、コマンドの出力に含まれる)ような例や、特定のログ中にコマンドプロンプト相当の文字列が含まれているようなケース。みたいなコマンドでログを表示させたりしたときに、過去ログの中に怪しい文字列が含まれていて止まる...とかは、なかなかテストでも見つからないです...。みたいに、どういう出力が返るか読めないコマンドの処理は非常に難しいです。系プロセスが拾った文字列に(人間可読な文字としては見えない)エスケープシーケンスが挟まっており、正規表現マッチにひっかからないことがあります。自動化すると、パラメータだけ別に(人が)入力するようなことがあるわけですが、まあ中には全角文字列とかいれるひともいてですね...処理の成否判定の難しさ・順序依存性とエラー対応の難しさまず、通信自体の正常性の判断ですよ。リモートログインした上でコマンドを送って応答をもらって、というのをやっているのだけど、どこで何が起きているのかが非常につかみにくい。プロセスの中では判断しにくい。自動化だと実装者側で頑張らないといけない。コマンドを実行して、望んだ状態になっているかどうかの確認、というのをワンセットで入れていかなければいけない。上の正規表現処理の煩雑さ、という話ともかぶるんですが...。コマンド系とか状態確認しようとした場合とか、コマンドに対して出力された文字列*3をどうにかする処理なんですよね。それでこれ、すべては文字列なんですよ。したがって、得られた情報(=文字列)に対する意味づけを、実装者側が正規表現マッチですべてパースすることになる。コマンドの出力自体はもうフリーフォーマットなので、ベンダやOSやバージョンによる違いがいろいろある。入れておくと、コマンド入力に対して常に時刻表示してくれるという機能があるんですが、そういう機能の有無が不統一だったりすると、予期せぬ文字列マッチを招いて処理がうまくいかなくなったりする。返ってきた「文字列」をみて、状態が正しいのか、エラーが起きてるのか、必要な値はどの行のどのフィールドなのか、そもそもフィールド区切りはどう判断するのか......を、自力でどうにかしないといけない。機器の設定って依存関係があるので、決まった順序が必要になったりします。一連のコマンドシーケンスを入力する間でエラーが出た・何かしらの失敗やトラブルが発生したとしたらどうすべき?処理を取り消そうにも、そこまで入力したコマンドはすでに反映されちゃってる。できるとこうしたエラー処理は非常に楽になるんだけどね。)データベースみたいにトランザクション処理みたいなことがやれるかというとそんなことないわけで、しかも周辺の状況に応じて動的に状態が変化していくし...。イベントに対応して何かをやる、というのも、実際どういう情報を集めてどう判断するのかとか考え始めるとすごく難しい。タイムアウト処理の難しさ期待している応答を拾えなかった、何かしらの形で処理が中断してしまった、等の場合に、リモートセッション張りっぱなしになってしまうと困るので、タイムアウト処理を入れます。これも往々にして機材や処理個別のチューニングが必要になり、非常に煩雑です。制御をオフにするのを忘れていて中断してはまる、とか。ターミナル横幅を超えた出力を削るか改行して送ってくるような機材もあった気がする。系はセッション開始時に全部オフにしておく等の処理が必要。したら出力まだ終わってないのにタイムアウトしちゃった...とか。結局これも、コマンドごとにタイムアウト設定ができるように実装する必要が出たりする。CLIベース自動化のつらさ結局、各機器に対するオペレーションすべてについて、全部(に近いほとんど)の入出力とその応答がどういう「文字列」として返ってくるかがわかってないと、自動化しにくいんですよね。ベンダ、機器、OS、バージョンによっても違いがある。自動化処理として実装するもの(コード)の量は、そうした構成要素のパターン数と、各機器に対してやりたい操作とのかけ算で増えていくので、もう事前情報調査もテストも膨大なパターン必要になる。全部が全部ばらばらなわけじゃないし、共通する操作はある程度作っておいて...というのができないわけじゃないのだけど、傾向としては圧倒的にパターンが多く再利用性が低いんだよね。これ、「特定のデバイスに対して、デバイスが返す応答に従って特定のコマンドを送る」を自動化する...という基本的なレベルのオペレーションに対してこういう問題が出てくるんですよ。複数の製品が連動するオーケストレーションになるとどうなるの、という話ですね。なるとつぎは、排他制御ってどうする...とかそういう話が出てくるんですよね。特定の機器の設定をいじっている間は、ほかのプロセスからの処理を受けてほしくないのです。NW機器側でそうした機能を持ってくれているかというと一般的にはないので、オーケストレータ側がどうにかしなければいけない。仕掛けが標準の中に含まれているはず。)やったことがある人だと多分感じたことがあると思うんですが、やればやるほど「俺がやりたかったことってコレジャナイ」感がすごいです。本題と関係ないところで行き詰まっちゃうし時間食いつぶしちゃうし。やりたかったのは「オペレーションを自動化すること」であって謎の正規表現チューニングやらなんやらは本題ではないわけです。おわりにまだほかにも聞いたような気がするけど思い出せない...。やっかいである、という話でした。ベースの話をせざるを得ないところもあると思うのですが、そういう方にはこういうノウハウを共通しつつ、無駄な時間をつぶすリスクを下げてもらえるとよいかな...と。界隈でインタフェースの統一やマネジメントプロトコルの提案などが行われているのか、という理由の一端を垣間見てもらえるとよいかなと思います。運用自動化関連の話がある。読んでみてくださいせっかく書いたので。参加してきたのでいつものメモです。参加してきたのでいつものメモです。理解する(3)月別アーカイブはてなブログをはじめよう!stereocatさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。