ネットワークプログラマビリティ勉強会 #1 参加メモ

ネットワークプログラマビリティ勉強会 #1 - connpass に行ってきたのでメモを残しておきます。

この勉強会の目的と方針(暫定)

  • ネットワークのプログラマビリティに関するオープンな勉強会。
  • 今のところ企画は2人。
  • あとは仕事のつながりとかで近い方に発表とかをお願いしてる。

経緯

  • SDNとかNFVはやってきてるけど、いままでクローズドな機械ベースの話してた人たちからすると、なかなかそういうオープンな話や素養を勉強していくのが難しい。
  • NWエンジニア同士でそういう勉強とか情報交換とか交流とか、なかなかチャンスがないですよね。
  • プロトコルや標準を作る…という観点ではいろいろやってるだろうけど、ソフトウェア開発とかそういう観点での勉強をやる機会はあまりなかったのではないか。

勉強会

  • NWエンジニア同士で、NWにおけるプログラマビリティ全般について情報交換をしたい
  • ほかの業界から(インフラ、ソフトウェア)からNW的なところへ関心を持ってもらって参加するのも歓迎。
    • 挙手
      • ネットワーク系; 8割くらい?
      • インフラ系: 2割くらい?
      • ソフトウェア: 数人
  • セミナーと言うよりは、有志に話題を提供してもらって、意見交換するようなスタイルを考えてる。
  • 扱ってみたいトピック
    • SDN, NFV, IoT/IoE, Orchestration/Automation, OSS, ソフトウェア開発全般

募集

  • 発表ネタ提供
  • 運営・企画ヘルプ
  • 会場提供

今回は企画者の都合で C 社の人主体でやってますが、オープンな会にしていきたいので、特定企業の色がついてしまうようなことがないようにしたい。即効性のあるネタだけでなく、基礎体力をつけるようなネタもOK。

ネットワークエンジニアのためのpuppet/chef, Tetsuhiro Sato

資料

ネットワーク機器もpuppet/chefで管理しましょうという話が各社から出てきてる

  • NWエンジニアにとってpuppet/chefとは?

自己紹介

  • SDN的な仕事
  • Rubiyst
    • OpenDaylight やルータいじる SDK 関連で Java
    • Node.js + CoffeeScript
    • Netflow collector自作してみたり
    • 科学計算系で python 使ってみたい
      • NW関連の統計計算とか。

今日のお題

  • ネットワークエンジニアによるネットワークエンジニアのための puppet/chef
  • puppet/chef 使えたらうれしいの? (ユーザ視点で)
インフラの自動化

Open Source Provisioning Toolchain

  • bootstrapping: OSセットアップするあたりまで
  • configuration: システム設定, 今日はここ
  • orchestration: アプリケーションサービス導入

Infrastructure as Code

  • 手作業でやっていた環境整備の自動化

宣言的

  • 手順ではなくて「あるべき姿」を記述する
    • 裏では同じようなことをやるけど…
    • shell script とかで書くと、途中で失敗したりした後、再度やってもうまくいかないとか。あるいは環境に変更があったときに再度動かして動くか、とかは怪しくなる。

冪等性

  • chef/puppet が手続き的なモノと違うところ: 冪等性。ある操作を何回か繰り返して実行しても同じ状態に収束する
  • chef/puppet がこうした冪等性を担保してくれる。
    • プラットフォームごとに異なるやり方の吸収
    • 不要な作業のチェックとか面倒くさいことの処理はフレームワーク側で吸収してくれる。
  • chef/puppet 的サービスを自分で作るなら、サービスプロバイダ側の実装でこうした冪等性を担保する必要がある。
    • NW機器だとコンフィグ消して上書きとかしないといけないことがある。冪等性担保してくれないOSだと泥臭いことが必要に…

インフラの自動化、なにがうれしいの?

  • 一昔前
    • インフラ構成の自動化
    • 同じ環境を再現できる。何かあったらすぐ戻せるとか。
    • 大規模化、作業の高速化・省力化・人為的ミス対策
  • 現在
    • これまでのメリット + インフラ状態のコード化、に狙いが移りつつある
    • アプリケーション開発の方法論をインフラにも適用しよう。
    • バージョン管理、変更管理、レビュー性
    • テスト駆動インフラ
      • テスト→アプリケーション実装
      • 機能がちゃんと入ったか? 自分が作った機能がほかのコンポーネントに影響することがある(デグレ)のを見つけたい。すぐわからないと、いつ、どのタイミングで何が起きたのか…を探るのに時間がかかる。
      • リファクタリング。外部仕様を買えずに中の実装を最適化して技術的な負債を減らす。過去の悪いところをなくしていく作業をやるのが、ソフトウェアの継続メンテナンスでは重要。
    • インフラCI(継続的インテグレーション)
      • システムを全部一人で作れるわけじゃない。結合テストが必要。master repos へのプッシュの段階で全体の結合テストして全体としてちゃうと動くかどうかを見る。
      • というのをインフラでもできる。ソフトウェアほどじゃないけど、頻繁な更新に対してメリットがあるだろう。
Puppetの紹介

Puppet

  • chef より先にできた。(2005-)
  • 独自言語のマニフェストでシステムリソースを管理
    • Rubyになれてるなれてないとかで好き嫌いが分かれる

利用形態

  • server/client (今日紹介するのはこれ)
    • puppet client が server にある manifest file を取ってきて動く (xmlrpc over https)
  • standalone
    • client 相当のアプリがローカルの manifest を読む。
    • お手軽だけど集中管理とかはしにくい

環境セットアップ

SSLv3認証

  • server-client間 transport は SSLv3
  • clientがmaster(server)に初回アクセスする際にCSR生成して署名してもらう。

マニフェストファイル

レシピ

テンプレート

  • erb

サービスの起動・停止

Chefの紹介

Chef

  • 実装は Ruby
  • 2009-
  • Ruby DSL
  • 最新は chef12 だけど今回は chef11 ベース

利用形態

  • server/client
    • 管理 workstation が cookbook/recipe を管理する
  • chef solo (standalone)
    • client 相当が自分で cookbook/recipe を管理
  • chef solo + knife solo
    • リモートで cookbook/recipe を管理して rsync で配る
    • シンプルである程度スケールできる
    • 今日はこれ

管理ワークステーションの環境セットアップ

  • Chef-DK (for windows)
    • knife-solo だけ gem で個別にインストールする
  • 管理とかが ruby 的な文化に染まってるので、そこになじめるかどうかがちょっとあるかもしれない。

Knife Solo

  • workstation で cookbook/recipe 管理して rsync + リモートから chef solo 動かす
  • そこそこ規模のある環境もいける
    • ほぼ管理workstationだけで作業になる

knife solo init

knife solo prepare

  • パスワードなしsshログインして sudo できるようにしておくと、リモート(knife solo)から chef-client とかをリモートから入れられる。

Berkshelf

  • Chef cookbook 依存関係の管理ユーティリティ (yumとかああいうやつに近い)

knife cookbook

テンプレート

  • erb

Nodes

  • どのノードに何を適用するかのマッピング: Node Attribute
    • run_list: 何を適用するかあ
テスト駆動インフラ/インフラCI

Serverspec

  • サーバ状態テストのフレームワーク
    • 入れた後の確認を自動化
    • 裏で rspec つかってる。宣言的にテストコードを記述。

テストコード

test kitchen

使い方

Berkshelf

  • Cookbook管理。
  • Test Kitchen 使用時は自作の cookbook も berkshelf で管理する必要がある

kitchen create
kitchen converge
kitchen setup
kitchen verify
kitchen destroy

kitchen test

  • 全部まとめてやってくれる

インフラCI

  • master repos push を元に通知してテストを動かす
ネットワークで構成管理ツールが使えたらうれしいのか?

本当にうれしいの?

  • 各社いろいろ設定管理ソリューションを謳っている。

ネットワークで chef/puppet がつかえたら?

  • 規模があればそれなりにうれしいか…
  • すでにサーバとかで使っていれば?
  • コード化
    • バージョン管理やレビューができる、変更トレースとかもできる。
    • テスト。機能単位テストできるようなツールがない。設定しても、expect + show command + regexp parse でチェックするのであればあんまりうれしくないのでは。
    • SandBox が用意できない。
      • 仮想環境で動くようなモノを用意できれば原理的にはできるだろう。
      • CML (Cisco Modeling Lab)

ネットワーク固有のうれしさ

  • ネットワーク機器の設定は重複が多い。似たような設定をいろいろ入れてる。
    • 特に chef は設定ファイル自体が ruby code なので重複は iteration して排除できる → 変更箇所がすごくわかりやすくなる。

IXIA VM on Cisco Modeling Lab (CML), Akira Iwamoto

資料

自己紹介

  • 普段は製品サポートやってます
  • という関係もあって、CML というツールを使ってる

Cisco Modeling Lab

  • 仮想ネットワークシミュレーション環境
  • vIOS, XRv, C1000v等を自由につないでテスト・シミュレーションできる。
    • x86 で動くイメージ。QEMU/KVMで動かす。中で OVS でI/F同士をつないでる。

CML - VM Maestro

  • CML Client Soft
  • このなかに IxVM いれられないか。

Third-party virtual machine

  • 中身いじって好きな VM 入れていいのかな?
    • サポートしないけどやるのはかまわないよ!
    • なかに Linux なりなんなり好きな VM 入れて使っていい。

IXIA VM (IxVM)

  • Ixia が出してるネットワークテスタの VM イメージ。OVAで提供される。

トラフィックテスタ

IXIA ハードウェア版テスタ

IXIA VM版テスタ

IxVM on CML

  • 仮想環境なので、性能と言うよりはルーティングとか機能寄りのテストとして
  • XRv だとダウンロード可能だったか。制限付きだったはず。

まとめ

  • Ciscoはこういうの出してる。他社も出すだろうし、OSSのも出てる。
  • こういうことができます、という一つの報告でした。

CDP Indicator, Toru Okatsu

資料

自己紹介

  • いつもはテクニカルサポート。ルータとかスイッチのトラブルシュートから最近は PM 的な話。
  • 今日はあまり役に立たない話かもしれないけど。
    • 社内で Ras-pi あげるから何か作れって言うコンテスト(PI-Athlon)があったので作ってみたものの紹介

CDP Indicator Features

  • 8 word x 2line のモニタに CDP 情報出す
  • Ras-piがつながったポートがどの機械の何番ポートかを出す + DHCPでもらった IP を表示する

Process Overview

  • main thread
  • cep receiver thread
  • python でがんばって書く。
    • SCAPYというライブラリがある。(tcpdumppython 向けにしたようなやつ)
    • packet の作成とかも割と楽

Cloudbit

  • littlebits という電子ブロックみたいなモノ。組み合わせると回路がくめる、みたいなやつ。
  • そのパーツの一つとして cloudbit
  • 電圧→WLAN→Cloud, Cloud→WLAN→電圧
  • cloud 側に web api があって、クラウド側に設定すると cloudbits を設定できる

-

IFTTTによるWebサービスとの連携

  • cloudbit もサポートされてる
  • cloudbit(littlebit) ; FB投稿とかメール投稿とかいろいろの連動

次回

是非次回も、12月中旬くらいに
こういった観点の話で、興味のありそうな人がいれば紹介、声がけして参加してください。

感想

個人的な感想

  • ビール&ピザ! ごちそうさまでした。
    • 金曜(平日)開催だと、開始時間が19:00-くらいになるとうれしいです…。(定時17:30だとして移動に1時間弱かかったり…。今回はフレックス制というお題目をフル活用しましたが。)
    • ビアバッシュでももうちょっと時間とって他の人と話をする機会があるとイイかなあとちょっと思いました。
    • みんなこういう技術領域って何をしたいですか? 何に困っていますか? これまでどういうことをやっていますか? という話をいろいろ聞いて回るだけでも面白いんじゃないかなあ。
  • twitter hashtag 用意してくだしあ! 事前にタグ設定があったらこういうメモじゃなくて実況にしたかもしれない。あと、記事の更新とか、こういうまとめ記事の投稿とか、落ち穂拾い的な話がやりやすくなるので…。

ここから先は勉強会とはまた別なんですが。

帰りにほかの勉強会で会ったことのある人と話をしてたんだけど、NWとかインフラ・低レイヤから入った人は上のレイヤ(アプリケーション開発)の技術の素養がなかなか身につけられないし、アプリケーション開発からこういう話に入ってくる人は、ハードウェア周りの話やネットワークの原理的な話をなかなか理解できない。技術分野を広げたいとは思いつつ、別な領域に入っていくための壁を越えるのが難しい。新しい領域の知識や技術を身につけようとすると、社内留学みたいな状態にしないと難しそうだけど……お仕事上そうしたフォローを受けるのも難しいし、教えられる人もそうそういない。ネットワーク知らない人からすると、本だけ読んでてもネットワークの技術や考え方は理解しにくい。実機触った方がいいんだろうけど機材もないし、個人でフォローしていくのは限界がある。

みたいな話をしてました。このへんどうしたものかなあ、と思いつつまあ答えはないんですけどね。