NetOpsCoding #2 #netopscoding 参加メモ

memo

NetOpsCoding#2 に参加してきました。毎度のメモです。資料とかは atnd からたどれます。

みんないろいろやってるなあ。こういうプラクティカルな話を自分でも出せるようにしたいものだ…。と思うんだけどね。今年はもうちょっとそういう活動をやりたいなあ。

Introduction to NetOpsCoding / Biglobe土屋さん

  • ネットワークにおける運用自動化ツール、事例などを共有する勉強会
  • サーバインフラとかは割と情報が多い
    • ネットワークの自動化、いろいろハードル高いところがあるよね。そういうの勉強会でノウハウ共有したいよね、というのがきっかけ。
  • あまりハードル高い勉強会にしない
    • NW運用やってる人、がりがりプログラム書いてるって人あまりいないのでは。そういう人でも気軽に入ってこれるような勉強会に。

NW運用業務の一例

  • 装置の設定・監視
  • リソース情報の管理
  • 手順書

運用業務大変だよね。

  • 仕事は増えるけど人は増えない
  • 楽をしたい! ミスをなくしたい! 楽しいことに時間を使いたい!

開発始めてみると壁が

  • システム開発が専門じゃないので覚えることが多い
    • Programming, DB, Web Application,...
  • NW装置の業界標準な制御方法が決まってない
    • APIとかは最近そろい始めているものの…
    • ひとつの会社の製品だけならできるけど、マルチベンダ環境だと苦労
  • 作ったものがみんなに使ってもらえない
    • 作ったとしても、その先がまだある。運用ツールは使う人からフィードバックもらって作り続けないと行けない。
  • 十分な開発時間を確保できない。
    • 自分の時間を確保するために自動化をするけど、自動化するのも時間がかかる。バランスをどう取るか。

成功例もある

  • ベストプラクティス
  • 開発の進め方
  • NWやる人、あまり多くない。みんなで壁を乗り越えよう!

NW運用の人へ

  • 自分たちで作っていくことが、運用業務を減らす近道。
  • 自分たちの仕事のやり方を再定義するチャンス。
    • もっとスマートに仕事をできるかも
  • ハードル高いけど、まずはできるところから。小さく始めてみよう

ソフトウェア開発の人へ

  • NW運用、課題がたくさんある。
    • 無駄なところがいっぱいある
  • もっと楽にできるよとか、改善できるよとか、ヒントがほしい。
    • 理想としては、一緒にものを作れること

メーカーの方へ

  • 良いAPIとかツールとかがあったら教えてください
  • 最新動向(標準化動向)とかも

勉強会でやりたいこと

  • 事例の紹介、ツールの紹介
  • チュートリアル/ハンズオン
    • やってみたいネタがあったら主催へフィードバックを
  • atnd の下にアンケートとかコメントかけるようになってrのでフィードバックしてください!

(会場) Backtround?

  • NW運用 50-60%
  • 開発者 20-30%
  • メーカー 10%?

さくらインターネットのベアメタル自動化への挑戦/さくらインターネット伊藤さん

自己紹介

  • さくらVPS開発担当
    • 物理〜ミドルウェア周りまでの検証・開発
    • ベアメタルプランのメイン開発担当

ベアメタルプラン

  • VPS?
    • 物理サーバを借りられる。
    • VPSコントロールパネルから、VPSと同じように使えるとか、料金体系がおなじだとか。

自動プロビジョニングシステムの独自開発

  • kickstart/preseedを動的に生成, PXE config と紐付け
  • ユーザ設定・最低限のパッケージのインストール
  • 独自OUI MACアドレスの割り当てとか、グローバルIPの割り当てとか、契約があった段階で払い出して設定。

NW構成

  • 集約スイッチ→アクセススイッチ→ベアメタルスイッチ
  • アクセススイッチにホワイトボックススイッチを利用
    • 作り込みしてる。

ホワイトボックススイッチ(WBS)使ってる?

  • 国内で使ってる事業者ってどれくらいある?
    • 会場→検証やってるところはあるけど、サービス利用はほぼナシ
  • 事例がない。サービスできるところまでやってみたので自分たちでやって発信してみよう。

WBSカスタマイズ

構成

REST API でやってること

  • スイッチの状態の変更や取得をGET/POSTでやる
    • リンクアップダウン、ポートカウント、VLAN ID、帯域制御設定、spoofing 対策用ホワイトリスト、通信断制御(on/off)

REST API でうれしいこと

  • 制御が楽になった
    • jsonベースで全部やれる。シンプルで見やすい。
  • チームごとのフロントエンド作るのが楽。
    • チームごとにに見たいものが違う。チームごとの作り替えが簡単。
    • 自製なので、endpoint 足りないとかあれば、自前でいじれる。かゆいところに手が届く。

ハマリどころ

  • サーバと同じ感覚で扱うとリソース枯渇が発生。
  • WBS, わりと安いのを買った。ディスクが1GBくらいしかない。すぐディスク埋まる。
    • 検証機では virtualenv で環境構築
    • 本番に対しては flask lib, python source code だけを取り出して ansible で配布
      • 本番機にはなるべくものをおかない
  • リクエストの取りこぼしの危険性
    • flask, 軽量 → キューの管理とか特にやってくれない。たくさんリクエストが来ると取りこぼしのリスク。
    • Gunicornみたいなリッチなものをいれるりソースもない
    • 真ん中に RabbitMQ を入れて解決。クライアントが多数になっても中間の RabbitMQ でキューイング。本番機はホスト名ごとのキューから取りに行く
  • Jenkins + Serverspec
    • セットアップスクリプトのテスト。
    • Github Enterprise から Jenkins をフック→ Serverspec でスイッチをチェック。
    • 今までサーバで普通にやってたことがスイッチに対しても違和感なくできる。スイッチだから・サーバだから、という話じゃなくて、どっちも同じようにテストが回せる。

WBSとうまくつきあう

  • できること・できないことを理解すること。

QA

  • REST APIの認証、アクセス制御
    • 社内アクセスのみの管理NWのみ利用。まずはやってみようという段階。将来的には認証とかもいると思う。
  • REST Server の OSS化?
    • 今のところ計画はないけど、上司が許せば…。見せられないビジネスロジックとかそういうのがあるわけじゃなくて、割と一般的なことしかしてない。
  • 一番大変だったこと?
    • 覚えることだらけ。資料がない。バグは踏むわドキュメントはないわ。
  • 機材、OS、使ったものとかの情報出せる?
    • NG
  • フロントエンドがたたきに行ってるもの、いまはWBSだけ? WBSとそうじゃないものの混在とかどう考える?
    • いまはWBSに対して、だけ。本当は社内もいろいろメーカー混在。なかなか難しい。ほかのメーカーの機材でもMQ対応してくれるとかがあれば、ある程度吸収できたりするんじゃないか…と思ってるけど。
    • 環境が増えるごとに階乗できつくなっていくので

ネットワーク試験自動化 GoBGPのシナリオテストを例に/NTT石田さん

自己紹介

  • Net/CodingをやってるけどOpsはやってません
  • LinuxでLDPサポートはいったので、GoLDPはじめました

Trusting the network automation

  • けがを防ぐための自動化の事例

GoBGPの試験自動化

  • Go75%, Python25%... pythonが何をしているか、というところの紹介。

GoBGP?

  • 既存BGP実装への(主にJPNAPさんの)不満が動機
    • 今時の技術でその辺の不満を解決しよう
    • API: gRPC で API First
    • マルチコア対応: Golang
    • OpenConfig(Ops主導のYANG Model)

API First?

  • CLIもgRPCを使うように実装。
    • No More Expect

自動化によるけがを防ぐ

  • (ソフトウェア)試験
    • ユニットテスト
    • シナリオテスト ← 今日はこれ。人力でやってるとスケールしない。

GoBGPのシナリオテスト

  • Github PR → Jenkins → Docker でテスト実行 → 結果を確認してマージするかどうか判断

どんな試験があるか?

  • gobgp/test/scenariotest

demo

  • 4 containers (docker), 3 quagga + 1 gobgp
    • テストによっては exabgp も使う
  • 相互に peer 張って、established 担ったり経路情報もらえたりするのをチェック

docker

  • 開発ツールとしては超優秀
    • 依存関係ではまることが激減
    • 複数のBGPデーモンそれぞれ起動して、テストごとに仮想ネットワーク分けて同時実行とかもできる。

python test code

  • gobgp/test/lib
    • 各gobgp/quagga/exabgp contaienrを同じ操作で扱うためのライブラリ

応用

  • BGP実装の性能測定: BGPerf
    • exabgp instance をコンテナの中で100個作ってたくさん経路突っ込む
    • 使用したメモリ量、時間
  • 既存のルータ? 仮想アプライアンス版をつかえばソフトウェア試験はできるかな
  • 物理ルータも、Dockerに物理インタフェースつないでやれば試験できる
  • アイディア次第

運用自動化試験の自動化も

QA

  • ルータの評価、結構時間かかる。ひとつの機械に対して半月とか一月とか。ルータの自動テストツールとかもいける?
    • 作れるようになる、とは思っている。今できるかどうかはわからないけど。OpenConfigとかは最近実装も出てきてるし、ライブラリ作って同じように制御できるようになるのでは。
    • expect使えば(すごく)大変だけどできるよね。
  • テストコードを書く時間の比較?
    • 時間はそうでもないけど、精神の濁り具合が違う

ネットワーク運用におけるgithubの活用と今後の展望/Mixi吉野さん

  • NW機器のコンフィグ管理、githubつかうとどれだけうれしいんだ?
  • 仮想ルータで作ったラボみたいな話の紹介

前提

  • 運用者は同じ場所にいない。DC,家,オフィス
    • 口頭で話せない
  • chat, github の内容がメイン

アドベントカレンダーに書いた内容

例

  • FX1の検証
    • 遠くのクラウドとIPsecトンネル, 自社網とトンネルでつなぐ。
    • githubでやりたいこととかどういうことやるかとかやりとり。
    • 目元かやってる最中のアレコレを書いてもらう
    • アドバイスとかもかく

例

  • 通常の運用の中で疑問点を質問
  • リファレンスをつけて意図を回答

github活用のメリット

  • 過去の経緯とかが全部残ってる。歴史的な闇として残ることがない、あるいは、誰かが掘り起こして光を当ててくれる。
  • slackとかに連携していて、slack/githubをいったりきたりすると仕事ができる
  • upper layer からの話とかも残ってる

ラボ

  • 仮想環境でのラボ

これからやること

QA

  • githubつかうモチベーション
    • 今風なものに変えてみようかな。
  • 口頭でやった方が早いんじゃない、とか言うひともいるんじゃない?
    • みんなオフィスにいるんならいいけど。あと転職とかもあるし過去のドキュメントひっくり返してフォローアップとかしんどい。リポジトリ検索する方が早い。
  • github, プログラム書いている人には親和性が高いと思うけど、officerな人たちにとっては? そういうひとにtaskをチケットで降るとか。そういう人たちを巻き込むことはできてる?
    • 総合職・企画・マーケもgithub account持ってる。サービスに関わって、システムとちょっとでもやりとりするところがあれば、githubを使う。ラッパーがあったとしても大本はgithubにしてある。
  • そうするためのコツ?
    • これが当たり前みたいな空気を作る!
  • githubが死んでる間はどうする?
    • ローカルにリポジトリはあるので、ネットワーク的な問題はない。サービス側…リポジトリとしては一部ミラーがある。issue/PRは見えない。そのときは頑張る。メンテの時には、事前にPDFにしておくとか、そういう対策はしている。
  • ラボ, 自分の会社の環境と全く同じ構成を仮想で作って、実網とおなじものを仮想でシミュレーションとか、できる?
    • 越えないといけない壁がある。ルータのバージョン、仮想の方が高いので、自社網をそこまで追いつかせないと行けない。しんどい。下のバージョンのやつをどうしていくか。というのが一番やばい。
    • トラフィック流さない前提なら動くのでは。

LT

ネットワーク機器のAPIあれこれ入門/テラセンス ebikenさん

ネットワークの機器のAPIで何かいろいろやりたい。

  • いろいろ調べてみたけど、全体像をつかむのに時間が…。
  • 調べて勉強してきた内容をまとめて共有して、一緒にやれる人を増やそうと思ってます。

APIを利用してできること

  • 設定投入、情報取得…
  • API: プログラムからそれを連携してたたけるようになることがメリット。
    • NW屋さんが考えつかないこともできるかもね

メジャーなインタフェース

  • CLI
  • NETCONF/YANG
  • REST

CLI

  • 難しいと言うより面倒くさい
  • 現状、CLIでしかできないこともある。

NETCONF/YANG

  • 構造化されたデータでやりとり。IETFで標準化
    • データモデル、ベンダによりけりなので、そこの統一について議論。
    • データモデル感の変換は大変なので。
  • SDK/lib の利用を (MTUとかワンアクションでどこまでとか)

REST

  • http method で操作, URIで捜査対象リソース
  • シンプル
  • 標準化がされてない。NW機器でRESTそのもので実装しているのはほぼない、という状況。
    • REST(like), いろいろ違いがある。
    • RESTはプログラムが書きやすいので、各機器でどういう仕様なのかを調べて、それぞれ自分が使いたい機器を中心に手を染めていく、というのがよいのだろう。
    • "REST" と書いてあるからといって RESTful だと簡単に信用しないように!!

できれば作りましょう!

  • 使ってくれそうと思わないと、メーカーは作らない。ほしいこと、やりたいことは表に出しましょう!
老害のためのネットワーク自動化入門 閉域網の自動制御システムを作ってみた/さくらインターネット 大久保さん

ハイブリッド接続: L2でローカルネットワーク接続できるサービス

  • 先月追加リリース
  • トンネルとかVLAN ID変換を使った相互接続、
    • 申し込みによって各機器を自動的に設定してパスをつなぐ

システムの裏側

皆さんも是非オレオレSDNに挑戦してみては!!

みんな大好きNet::Telnet

Firewall Test Automation , NeedleWork(FWポリシーテスト自動化ツール)/APC鈴木さん

FWの構築の流れ (通常パターン)

  • 設計, permit/denyの設計
  • 設定
  • テスト
  • 納品

FWの構築の流れ(炎上パターン )

  • 設計が遅延。決まらない。
  • コンフィグ投入はすごく後ろ倒し
  • 大量のテストを短時間で
    • ポリシ漏れもたくさん
  • 納品日は変わらない。

テストで犠牲者多数

  • 1400ポリシのテストを手作業で → 150時間、人をたくさん入れて3日で終わらせるという事例が。
  • FWのポリシテストと言うより人間への負荷テスト。つらい

楽になるツールを作ってみた

  • needle work = 刺繍: FWに針を刺しまくる
  • テスト内容を書いたCSVをインポート
    • netnsで送受信するノードを作る
    • netcatを起動
    • FW経由でコネクションを張る
      • 1ポリシ1秒くらいで自動テスト
    • ポリシ修正したらリトライ
    • テスト結果もexport可能

150時間→18分!!

これから

  • netcat, L4のみ
    • アプリケーションの通信も
  • 稼働中のFWテストもどうにかしたい

NICたくさんあるサーバで使う感じで

OSS化は相談します

検証環境をgobgpで"極力"仮想化してみた/Biglobe馬淵さん

評価環境の整備ってどうしよう?

  • 環境作って、明日やろうかな、と思ったら、翌日BGP落ちてる…

Why?

  • 昔の検証の傷跡…
    • クリーニングする機構がちゃんと整えられていない!

標準構成に手早く戻せて、コンフィグなるべくいじりたくない
検証自体を楽にできるようにしたい

  • 経路の生成とか手軽に
    • Attribute, AS-Pathとか

GoBGPで作ってみました

  • 検証で必要な機材以外は全部 GoBGPで
    • GoBGP ModPathすごい便利。コンフィグで経路作らなくて良い
  • 機器自体のクリーニング: Ansible/2.1, IOS-XR/Junos対応

次のステップ

  • GoBGP/ModPath + BMP + jenkins, ベストパス移り変わりとかをチェックするとかで自動化できるんじゃないか。