NetOpsCoding #4 参加メモ

memo

NetOpsCoding #4 に参加してきたのでいつものメモです。公開資料などについては atnd のページを参照してください。

ネットワーク機器運用自動化の傾向と対策, Fixpoint/服部さん

Kompila

  • 定型的な処理を「ジョブフロー」として登録しておくことで自動実行でいる
    • bash, ruby, python, なども
    • パラメータをWebから入力してフローをキックとかもできる。

今回手伝ったNW運用自動化(運用チーム)のしごと

  • 日々いろんな作業依頼がある

現状の運用

  • いわゆる「ガチガチ」な運用
  • アプリ開発者 → NW運用チームに作業依頼(メール)
  • NW作業担当者は依頼内容に基づいたExcelで作業手順書作成 → 責任者レビュー・承認リレー
  • 承認が下りたら作業実施 → 作業担当者へ手順書を渡して実行

毎回同じような手順書書かないといけない。実際の作業は手作業なので入力ミスや誤設定とかのリスクがある。

スクリプト実行で自動化だ!

  • 作業担当とかみんなノンプログラマ
  • 簡単なスクリプトと行ってもプログラム書くハードルが高い。
  • 責任者もノンプログラマなので、プログラム見ても判断が難しい。

ノンプログラマがやりやすい手順書みたいなのってないか?

  • YAML手順書へ
  • 日本語キーワードで可読性をあげる
  • キーワードの表記揺れに対応する

Kompiraによる自動運用

  • Excelのかわりに YAML 手順書
  • 承認リレーとかは従来通りにしてある
  • 作業実施は Kompila がYAML手順書を自動実施する。

実行の流れ

  • parse
  • パラメータのチェックとか手順書の内容が意味的に合っているかどうかをいまの設定情報を元にチェック。
    • 今のコンフィグ情報を取ってきて、YAML手順書のパラメータの整合性チェック。存在しないオブジェクトの参照や二重登録など。

自動化システム実現の際にあたった壁

  • CLIの壁
  • Telnetの壁
    • Telnetでしかアクセスできない機械がある
    • expect script
    • 踏み台の処理
  • 冗長構成の壁
    • 機械によっては active 側にだけコマンド入れるモノがある。どっちがActiveなのかを判断して動かないといけない。
  • 設定リカバリの壁
    • 間違えたときに切り替えたい、というのが発生する。
    • リブートさせたくない
    • コマンドを取り消すコマンドを入力する…

CLIの壁

  • SSG: get config → shlex で字句解析
  • コマンド生成: YAML を解析して構文木 → トラバースしてコマンドを生成

Telnetの壁

  • 実行したコマンドの結果とプロンプトの区別がない。
    • コマンドが終わってプロンプトが出てからコマンド入れないといけない。
    • コマンドによってはプロンプトが変わる
    • プロンプトが出る前にエラーメッセージが出ることがある。
    • エラーメッセージハンドリングは地道にやるしかない。
      • expect script が秘伝のタレ化…

冗長構成の壁

  • Activeにだけコマンドを来る。ログインした上で状態チェックをする。

設定リカバリの壁

  • 誤投入に対して元に戻したいけど、リブートするのはいやだ
  • 逆コマンド実行をする。
    • 投入したコマンドから逆コマンドが特定できるとは限らない
    • 設定差分(diff)から逆コマンドを生成する。
  • 単純に diff とれれば良いわけではない…

まとめ

  • Kompila でNW運用自動化システムを
  • 実際に現場で使うには、細かい処理を入れ込まないと行けなくて非常に面倒くさい。
  • 今のところ銀の弾丸はない
    • 地道にやるしかない
  • 自動化することで、手作業より確実にオペレータ工数削減はできる。

QA

  • 構成管理
  • YAMLのモデル、スキーマ?
    • つくってない。入れられるパラメタは決めてあるけど。
  • 機械のバージョンによって文字列パースが違ったりする。DB内とつらいんじゃない?
    • たぶんきつくなる。いまのところ、新しい機器に対してやるときは事前に動作チェックを屋って、処理追加を入れていって対応させる、という方向。

構成管理DBをGitで管理したいネットワーク管理者の憂鬱, internet Multifeed/川上さん

Internet Exchange とは?

  • 平たく言うとL2スイッチがある。
  • 各社がBGPルータをつないで、経路交換をして、トラフィックを交換する。
  • 100くらいの顧客(AS)がつながってる

NagiosやMRTGの設定を自動生成

  • 設定作業
    • プロビジョニング、開通作業、バックボーン作業(影響がある・ない)
  • いままで手作業
    • コンフィグファイルが非常にわかりにくい。不幸な人為ミスのオンパレード, 開通作業に5時間かかる…とか。
    • DBから自動生成したい。

どういうデータベースを?

  • RDB, Text, NoSQL, Other(Excel?)
  • 自分たちの運用方法や文化にあった技術を選ばないと、現場が崩壊してしまう。
    • 運用を無視したツールファーストはNG

例: スイッチのファームウェアアップデート

  • 設定変更手順
  • オペレーション
    • 作業者+確認者の2名体制
    • サーバ系設定
      • 各ステップのコンフィグは前日までに確認・承認しておきたい
      • 全体の作業内容は変化があるので、コンフリクトが起こる可能性がある。衝突が起きたら回避できるような仕組みじゃないといけない。

DBがRDBだったとすると…

  • コンフリクトに気づけないといけないし、気づいたら担当者が変えられないといけない。
    • SQLとかまでやるのはハードルが高い。生SQLとかやらないでしょう。モデルやインタフェースのオブジェクトをどう考えるか?
  • WebUI?
    • WebUIの手順書は書くのが大変。その通りに行われる保証がない。
    • 実装コストが高い…
  • rails console?
    • つらい

Gitならなんとかなるんじゃない?

  • 運用者が読み書きしやすい・機械処理ができる・バージョン管理できる。
    • ファイルなので誰でもいじれる。(中身はYAML)
    • 意味のあるコミット単位
    • ブランチを切ってコンフィグを作れる
    • ssh + git pull でデプロイできる

ワークフローの変化

  • 作業用ブランチ → テキストでコンフィグ → レビュー
    • 差分確認、コマンドの確認を担当者がやれる。入力するコマンドのチェック。
  • メンテナンス前に担当者が rebase して変更停止(master freeze)
  • 作業実施後に branch 削除

2年半くらい運用している

  • YAML, git にカンするトラブルは特になし。
    • どっちかというと人為ミス。typoとか。
  • Good
    • ブランチ斬る運用
    • 意味のある単位でのコミット、差分によるダブルチェック
  • Bad
    • オブジェクト管理レーションが相互参照
      • pry debug がつらい
      • stack trace がおもい
    • git pull デプロイに時間がかかる
      • gitlab のパフォーマンス
    • プログラムからDB変更する

運用自動化の段階

  • phase.1, スクリプトにパラメタ渡して人が実行
  • phase.2, DBから全部コンフィグ作って機器にデプロイ
    • 機器側にコンフィグリロードの仕組みがないといけない
  • phase.3, イベントドリブンで必要なコンフィグ差分を機器に投入
  • YAML をもとにしているとつらみ
    • コメントは消える
    • 人が書いたモノと出力されるモノに違いがある
    • 人の編集とシステムによる編集のコンフリクト…

phase2→3

  • イベントごとにコンフィグ全生成というのはつらい
  • DBが半端に更新されているタイミングでコンフィグ生成しているとNG
    • branch 切れるDBというのもあるらしいけど (noms)

phase.3

規模

自動化実行に当たっての壁

  • 自動化のための整理

QA

  • デプロイを早くすることはやらない?
    • いまのところやってない。早くしても timing issue, デーモンリロードとかを伴うというのもある。早くはしたいけど。いま時間がかかる理由→ MRTGが5分間隔で動く。バックアップ側デプロイ→確認→メイン側デプロイ。過去、MRTGデプロイでバグを踏んでCPU食って死ぬ、というのがあって、サーバ側正常性の確認を入れている。そこの運用をあきらめられるのであれば2秒デプロイみたいなのも検討したいが。

LT

例によってLTについてはメモを取っていません。いくつか思うところや感想などを。

  • スマホのセンサーでネットワークを操る
    • スマホを振ったら Ansible Tower をたたいて経路変更 → 振った方向へ経路を切り替える。
    • LTでは残念ながらでも環境への接続が上手くいかず…
    • 懇親会で動くところを見せてもらえました!
    • デモ動画ができてた!

  • NetTesterで物理ネットワークのテストをプログラム!
    • あとで fixpoint の方とちょっと話をしたんだけど、感じている課題感や直面している課題はもうそのままですね。いろんなアプローチでどうにかできないかを試していけると良いと思います。
  • イベント紹介: TremaDayってどんなイベント?

感想

どれも何かしらの実装やコーディングの話が出てきて、具体的な話に突っ込んできているのが良かったなあと。まあその分泥臭い話も多めではありました…。最初の、fixpoint さんの取り組みとか、LTの "そろそろSSH/Telnetを離れて" の話ともそうなんだけど、このCLIベース自動化の話の泥沼からどうにか抜けたいところだなあ、と。あのへんの自動化実装の泥沼加減がわかりすぎるので


というツイートをしてしまいました。Ansible とか、いろんなツールややり方がいろいろ試してみるのはイイと思うんだけど、ちょっと気になるのは、こういうのをやるための地道な作り込みをどうもみんな何かしら再発明しているような気がするところかな…。いや、自分も最近ちょっとやってたというのもあるからなんだけど。APIで操作可能なガワを用意しても結局中身のCLI処理回すところの仕掛けやナレッジは自分で頑張らないといけないのがつらいなあ……とかね。プロンプトの正規表現作るとか、エラーメッセージ調べるとかのあれこれが超しんどい。何かこの辺をもうちょっと共有する・共通化するようなものがあればなあ、と思いました。