参加してきたのでいつものメモ書き起こしです。Togetterまとめすごく盛りだくさんな勉強会でした。最初にこういうのもあるよね、というバリエーションを出してみるという意味では、良かったんじゃないでしょうか。個々のネタについてもうちょっと掘り下げて話を聞きたいなあ、と思うものが結構あったので、今後はもうちょっとテーマ絞ってやっていけると面白そうだなあ。NetOpsCodingNetOpsCodingとは?ネットワークインフラにおける自動化事例、システム開発の知見、有用なツールの共有をやっていく勉強会に。プログラマハードル高い勉強会にしない。自動化初めてみたい、プログラム初めてみたい、みたいな人歓迎。自動化難しいところも多いけど、手順書作成とか、わりと手をつけやすいところもある。雑務に近いところもある。楽したいミスをなくしたいもっと楽しいことをしたいとはいえ開発始めてみると壁が多いな...システム開発、NW運用のスキルだけじゃなくてもっといろんなことを大量に覚えないといけない。NW装置、業界標準の制御方法が定まっていない。作ってみたけどみんなが使ってくれない...(運用ツールあるある)開発業務に時間を取りにくいなど。SIer...NW運用者に伝えたい自分たちで使いたいものを作るのが自動化の一番の近道では覚えることが多くてハードル高いけど、自分たちの仕事を再定義できるチャンス。10年後どういう仕事していたいかを考えよう。最初からすごいものはできないけど、やれるところからやってみよう。ソフトウェア開発者に伝えたいNW運用の人、現場はすごくたくさん課題を抱えている。NW運用の実情を知ってもらって、改善のヒントをくださいNW運用とソフトウェア開発の人が一緒に仕事できるといいなNW装置メーカーの人に伝えたいいいAPIがあればおしえてください。何がベストか、というのはなかなか難しい標準化動向も教えてほしいです!NetOpsCodingでやってみたいこと自動化事例、有用なツール、チュートリアル・ハンズオン、OSS開発やろうぜって言ってくれる人是非声をかけてください。運営は4名でやってます。自動化をやりたい、運用本気で困ってる、みんなを助けるヒーローになりたい前のめりに参加してください。やり始めないと何も変わらないので。NW/インフラ周りRubyをこの半年くらいで。プログラミング経験は浅いです。最近いろいろ自動化を図るためにやってます。Janog36で発表。勉強会で知恵を共有できるといいな。API/Web化によるネットワーク自動化30分でAPI作ってルータに設定を入れるよdescriptionの設定をします。APIのテストDBに設定とかを登録。MariaDBSRXのセットアップとかは割愛。vSRXJuniperからOVA配布。新しいの使ったけどすごく重い。必要なリソース要件はちゃんと見ておいた方がいい。IDCFクラウドでテンプレ展開。古いfireflyだとトラブル会ったから注意。今回使ったのは問題なかった。ハマりポイント2vCPU以上にすること。1vCPUだと一応起動するけど、設定はいらない、NIC認識しない、という状態になる。デフォルトがFWなので、今回オフにしちゃってます。expectREST開発しやすいけど、サポートされてるNW機器があんまりない。プロトコル自体は結構前からあるんだけどあまりライブラリがない。Juniperはライブラリ出してくれてる。アップデートもなくメンテナンスもされていない雰囲気。例外処理とかは甘い感じ。その辺いったん出した上で、編集したいところをいじる。設定確認^xmlで設定取ってくる。するときえてるのがわかる。必要setコマンドの形式でかける。DB名ルールが決まってるので注意。APIを用意して仮想ルータに設定を入れる。サーバ側が忙しい場合、ルータ側がコンフィグ変更中で衝突する場合。ロールバックして終わってくれればいいけど、たまにロック解除されずに操作できなくなることが。プログラムの方でアンロックかけて抜けないといけない。商用の時とかは例外処理とカチャンと入れないとつらい。lock/unlockでやっぱりトラブルがありましたMicrosoftにおけるネットワーク自動化とそれを支えるソフトウェア群についてマイクロソフト北島さん自己紹介NWEとしてMSのインフラをつくってきたコアネットワークの担当。その中でも実践的で応用が利きそうな内容を。スクリプターとデベロッパーがあって、スクリプターをしている。動けばいいって言う方。デベロッパーとはまたちょっと別。今日のは、両方のチームの力を合わせて作ったもの。MSのネットワーク世界中に。どれだけ少ない人数でオペレートするか。ソフトウェア・自動化が大事。自動化がないと人が追いつかない。Group標準化されていないと自動化しようがない。デザイン標準、テンプレ標準もあるんだけど、デバイスのコンフィグは別物になってる...という問題。SESというフレームワークを作った。シンプルなルールとアイディアで動くフレームワーク。configletごとに標準手プレトマッチングマッチしてなかったら直す。failだったらどうするのか、というのを判断。setdependenciesSESライブラリを読んで、テンプレとして何と待ちするかをNWEが定義する。repairもまとめてやれる。上手くいった理由NWE同士のコーディング、コラボレーションを促進したこと。デプロイレビューでリスクレベルの判断、誰が承認したか、とかが全部残ってる。あらゆるcoreに対する変更はこれでやれってことになってて多数のスクリプトがある。今後のSESどれくらい非標準コンフィグがあったのかのグラフ。Adaptiveなアプローチを取ったのが上手くいった。driven)実際のコンフィグを見てどれがおかしいのかを直すというアプローチメンテナンスや設計変更に使える。OSPFをIS-ISにかえようとか、既存のポリシの書き換えとか。Adaptiveだとマイグレーションがやりやすい。drivenでやってる。コンフィグの抽象化をやりたい。XRのコンフィグをYANGモデルで書き換えてる。YANGはスーパーセットではない。ベンダ独自のモデルというのがある。接ぎ木しないといけない。validationshowコマンドうってるけどNWE見てねえってときがある。メンテ前にprecheckコマンドコマンド発行して結果を取っておく。メンテ終わったらpostcheckコマンド同じコマンド流してまた状態取得。tableとかでかいのでインメモリDBとか使ってる)取ってきて比較。pass/failを出す→メンテ前後の状態で何が変わったのかを出す。変化外としたものかどうかを見ていく。機械的にチェックもできるし証拠も残る。Bandwidth実トラフィックに応じてLSPの予約帯域を動的に変更する、ルータの仕組み。最大予約帯域をセットしてある。回線利用効率)DC間の実トラフィックレプリケーションでいきなりトラフィック出たりする。LSP予約帯域を実トラフィックが越える。config足さないといけない。