2014年9月29日月曜日

vagrant-proxyconf(1.4.0) supports docker (en)

Hello, proxy fans in the world,

Finally,vagrant-proxyconfdocker has been released!(version 1.4.0).So, you can run docker easily behind a corporate proxy.

docker

You can use vagrant-proxy docker support for docker hosts on ubuntu, RHEL(6,7), CoreOS, boot2docker and so on.

It is easy to use. Install vagrant-proxyconf, then add your proxy configuration to Vagrantfile. If you already use vagrant-proxyconf, you don't need extra configuration for vagrant-proxy docker support.

vagrant-proxyconf installation

Install vagrant-proxyconf

$ vagrant plugin install vagrant-proxyconf
Installing the 'vagrant-proxyconf' plugin. This can take a few minutes...
Installed the plugin 'vagrant-proxyconf (1.4.0)'!
$ 

If you can't install vagrant plugin because of proxy server. Try the followings.

$ http_proxy=http://myproxy:3128/ vagrant plugin install vagrant-proxyconf
Installing the 'vagrant-proxyconf' plugin. This can take a few minutes...
Installed the plugin 'vagrant-proxyconf (1.4.0)'!
$ 

Vagrantfile

Add configuration.

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  if Vagrant.has_plugin?("vagrant-proxyconf")
    config.proxy.http     = "http://myproxy:3128/"
    config.proxy.no_proxy = "localhost,127.0.0.1,.example.com"
  end
  # ... other stuff
end

Running docker

After vagrant up, try to run docker.

vagrant@vagrant-ubuntu-trusty-64:~$ sudo docker.io pull -t 14.04 ubuntu 
Pulling repository ubuntu
ad892dd21d60: Download complete 
vagrant@vagrant-ubuntu-trusty-64:~$ 

If you set http_proxy, it will affect for https communication for docker. You can use private repositories in your intranet, because you can set no_proxy.
docker/registry/registry.go
docker/registry/auth.go
The Go Programming Language Source file src/pkg/net/http/transport.go

Happy proxy life!!

Docker logo and marks usage

vagrant-proxyconf(1.4.0) supports docker

全国のproxy愛好家みなさん、こんにちは。

ついに、vagrantを使う上で欠かすことのできないvagrant-proxyconfdockerサポートが加わりました(version 1.4.0)。これでproxyの内側でも気軽にvagrant上でdockerが使えるようになりました。

docker

対応している主なゲスト(dockerのホスト)としては、ubuntu, RHEL(6,7), CoreOS, boot2dockerなどです。

使い方は簡単です。vagrant-proxyconfをインストールし、Vagrantfileに以下のようにproxyの設定をして起動するだけです。(いまvagrant-proxyconfを利用しているひとはpluginをupdateすればそのまま使えます。)

vagrant-proxyconf のinstall

vagrant-proxyconfをインストールします。

$ vagrant plugin install vagrant-proxyconf
Installing the 'vagrant-proxyconf' plugin. This can take a few minutes...
Installed the plugin 'vagrant-proxyconf (1.4.0)'!
$ 

ここでproxyが理由でインストールできない場合は。。こんな感じですね。

$ http_proxy=http://myproxy:3128/ vagrant plugin install vagrant-proxyconf
Installing the 'vagrant-proxyconf' plugin. This can take a few minutes...
Installed the plugin 'vagrant-proxyconf (1.4.0)'!
$ 

Vagrantfile

こんな感じでproxyの設定を書いてください。

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  if Vagrant.has_plugin?("vagrant-proxyconf")
    config.proxy.http     = "http://myproxy:3128/"
    config.proxy.no_proxy = "localhost,127.0.0.1,.example.com"
  end
  # ... other stuff
end

dockerを使う

vagrant upでVagrantを起動したら、dockerを使ってみてください。

vagrant@vagrant-ubuntu-trusty-64:~$ sudo docker.io pull -t 14.04 ubuntu 
Pulling repository ubuntu
ad892dd21d60: Download complete 
vagrant@vagrant-ubuntu-trusty-64:~$ 

http_proxyを設定すればhttpsの通信もそれを使うようです。また、no_proxyも使えると思いますので、プライベートのレポジトリがあっても大丈夫ですね。
docker/registry/registry.go
docker/registry/auth.go
The Go Programming Language Source file src/pkg/net/http/transport.go

Happy proxy life!!

Docker logo and marks usage

2014年9月22日月曜日

Ruby Hiroba 2014に参加してきた

概要

  • 日時: 2014/9/21(日) 09:15~17:00
  • 会場: CyberAgent, Inc. SHIBUYA MARK CITY WEST 13th floor
  • ホームページ: rubyhiroba.org/2014/

全体感想

今回、初めて、Ruby関連のイベントに参加しました。 RubyKaigi2014の一連の会議ということで、Rubyコミッタのかたもいらっしゃって、 Ruby愛を感じました。(RubyKaigiでそうとうお疲れだったのだと思いますが。)

友人から地域コミュニティいったらというおすすめもらったので、 その視点でもいろいろ見ていました。 さすがに遠くて難しいですが、toRuby, guRubyの出張版でなんとなく感じがつかめました。 地域的にはtokyu.rbが家から近くて、良さそうだと思いました。 (ということで、時間があえば次回とかに参加しようかと思っています。ML登録しました)

自分の発表

他のかたのLT見てたら、自分もしてみたくなり、急遽スライド作りました。 内容がうすいものでしたが、興味をもっていただければ幸いです。 このLTのgemはgithub/otahi/pacproxyにあります。

他の発表?などの感想など

あんまりメモできていないのと、そろそろ朝ご飯作らないといけない時間なので、 すみません。。

guRuby

メタプログラミングRubyの読書会ということで、本を持っていなかったので、 電子書籍でMetaprogramming Ruby 2: Program Like the Ruby Prosを購入して臨みました。

`method_missing` のところを呼んで、irbでうってという形式で、 わからないところを共有して、という感じで一歩一歩やっていきました。

method_missingはRubyを始めた当初に出会って、混乱の窮地に陥ったことがあったので、 感慨深かったです。(rspec-dnsというgemのコードで)

toRuby

こちらはなるほどUnixプロセス ― Rubyで学ぶUnixの基礎の読書会ということで、 こちらも電子書籍で早速購入しました。

ここでは、シグナルハンドリングのところを読みながら、理解を深めていきました。

LTで話したpacproxyというのを作っているので、とても参考になるところでした。 ちゃんとしたUNIXのサービスを作るのには、きっても切れないところですね。

LTthon

多くありすぎて、ぜんぜんかけません。。

多様性のあるすばらしいLTthonだったと思います。 LTthonということで、長時間お疲れ様でした。

2014年6月29日日曜日

hbstudy #55 「Docker勉強会」リターンズ に参加してきた

概要

  • 日時: 2014/6/27(金) 19:00~21:30
  • 会場: ハロー会議室 新宿 C+D
  • スピーカー: 中井悦司さん @enakai00

他のかたのまとめなど

感想

最近は、Dockerについて、多く情報をInputして、自分の中でイメージを構築しようとしています。(英語とかの多聴に近いかも。) そのなかで、今回の勉強会での気づきは、DockerがLXCなどの他のシステムと違うのは さまざまな既存の技術を「一連の仕組み」としているところだな ということです。

これまでのLinux上の技術を組み合わせて、 CPU、メモリ、ネットワーク、ストレージなど一括して切り出せるようにしているので、 人によって、かゆいところが違ってくるのだと思います。

また、サーバの種類によって、Dockerを使ったほうがよいか、否かがかわってくると思います。 Dockerの技術はデバイスを隠蔽しているので、直接ハードを扱いたい場合などには利用できないのと、 DBもやり方によっては、実現できるのかもしれませんが、あまりメリットが多くないのかな と思います。 なので、実際にはアプリケーションサーバなどの状態を持たないサーバをDockerで 構築するのが最初になるのかな と思いました。

ただ、自分の興味のあるネットワーク周辺については、Dockerの思想からはずれるとことがあるかもしれませんが、 いろいろ小細工していきたいな と思いました。 (今回、@enakai00 さんがネットワーク周りの操作をデモでやっていただいて、なんとなくイメージが持てました。)

内容メモ

ちょこっとしたまとめです。スライド見るとだいたい書いてあるので。。

Docker入門(Docker クイックツアー)

  • コンテナの仕組み
    • Linux上でのコンテナは、昔(といっても、そんなに昔ではない)からある技術を組み合わせ
    • ホスト側から、ひとまとまりにして、切り離せる
  • Dockerの仕組み
    • これまで実現するためには、一生懸命組み合わせないといけなかったものを簡単にできるようにしたもの
    • インターネット上のレポジトリにコンテナをイメージを置き、利用できるようにしている
    • ホスト側の環境がある程度そろっていると、コンテナの動きもかわらないようにできる
  • Docekrを動かしてみる
    • デモでいろいろ見せていただきました
      • ちゃんとFedoraの上で、CentOSのtracerouteも動きました

Docker を支える技術

  • Linuxコンテナの実態
    • namespaceを使っていろいろなリソースを分離している
    • コンテナ内部からは見えないが、ホスト側からは見える(操作できる)
    • コンテナではpid 1のプロセスが落ちると、コンテナとして落ちる
    • ネットワークのnamespeceCentOS 6.4とかだと使えない-> 6.5では入っている)
    • これまでaufs依存だったが、Device Mapper Thin-Provisioningという仕組みが入って、aufs依存しなくなった
      • Red Hatさんが作り込んだようです
    • ホスト側からは、いろいろ設定が変更できる
      • Docekrでは固定でも、そとから変更すれば変更できる
        • ただし、Dockerの思想とは反するのと、ホストによって振る舞いが違ってくることもある

2014年6月23日月曜日

JTF2014に参加してきた

JTF2014に参加してきたので、メモを残します。 もうご飯作る時間になってしまったので、ここまでです。。

概要

感想

Serverspec のような「成功」を成し遂げるには他者を巻き込む

Serverspecのmizzyさんの話でしたが、とても楽しく、また、参考になりました。 (というか、参考にしてがんばります!!) 構成管理+仮想化+テスト+CIやGithubなどの環境の変化があったところに、 Serverspecがぴったりとはまったということでした。 (あと、@naoyaito さんに広めてもらうことが、日本での普及の鍵だったそうです。。) その土台には、プロダクトを「KISS」にする、他者を巻き込みやすいようにする というようなことを やり続ける ということがある。と。 たしかに、自分がコミットしたOSSは愛着がわきますね。

Serverspecrspec-dnsにインスパイアされてLbspecというものを作っているので、 今回の話を参考にして、がんばっていきたいと思います。

docker関連

  • dockerがいま暑い

    JTF2014の中心はdockerだったように思います。 docker関連のセッションの数も多く、また、セッションには立ち見がでるほど人がきていました。 ただ、会場では「本番運用」までを期待していたものの、docker入門の部分が大きく、 ちょっと物足りなかったかかな と思います。 入門も必要なところなので、セッションごとの役割分担ができていたらよかったですね。 そもそも、本番運用までやっているところもほとんどないと思うので、自分で開拓するしかないですね。きっと。

  • dockerは「秘伝のたれ」を取り除く銀の弾丸ではない
    これまでのサーバ構築が職人の「秘伝のたれ」で構成されていることに対するカウンターとして、 dockerでコンテナ作って、CI回して・・・というのをやっているのだと思うのですが、 dockerコンテナに「秘伝のたれ」が入り込む余地はあって、 結局、ある「ゴールデンコンテナ」からの子孫を大事に守り続けることになるかもしれない という風に思いました。 ただ、hyper visor上のVMに比べたら、生成、消滅を繰り返してやれる分、 CIを速く回していけるので、思いました。

DMM.comさんはお客様にコンテンツを速く提供するためには、「なんでもする」

DMM ツチノコブログで最近情報発信を活発にされているDMM.comさんのインフラ(ネットワーク周り)の 話をお聞きすることできました。(このようにDMM.comさんが話をするのは10年ぶりだそうです。) お客様にコンテンツを速く提供するためには、「なんでもする」という話がとても印象に残りました。 「稟議も即決」「自分たちの責任でそのときのベストと思うシステムで構成する」というところが とてもかっこよかったです。 これからの情報発信にも期待です。

フロントエンドでビルドツール特にgulpが活躍

自分とはあまり関係ないところも聴いてみようと思って、このセッションを聴いたのですが、 デザインのところでもだいぶ自動化で環境が変わってきているな と思いました。

デザイナーがやるべきところに注力できるようにする ツールが進化しているというのがとてもおもしろかったです。 あとでもう一度、調べてみようと思います。

主催者、スポンサーに感謝

とても濃いセッションが多くあり、とても楽しく1日すごせました。 懇親会はでられなかったのですが、事前に申し込むと1000円以下で、 おいしい昼食と飲み物とお菓子がいただけるという。。 それだけで1000円の価値があります。。 ありがとうございました。

2014年3月17日月曜日

LoadBalancerもRSpecで定義: Lbspec

LoadBalancerのspecは、あるリクエストに対して、期待するレスポンスを返すか という表現では不十分である。実際にnodeにリクエストが到達するか ということを表現しなければいけない。そこで、LbspecというRSpecのMatcherを作った。これを使うと、LoadBalancerがnodeにリクエストを転送することをRSpecの書式で表現できる。

これでLoadBalancerもRSpecで定義できるはず。。

リンク

Installation

Gemfileに書く:

gem 'lbspec'

bundlerを実行する:

$ bundle

もしくはgem installする:

$ gem install lbspec

Requires

  • nodeにsshで入れる(~/.ssh/configなどで定義されている)

Usage

こんな感じで spec_helper.rbで require lbspec する:

# spec/spec_helper.rb
require 'rspec'
require 'lbspec'

あとはSpecを記述する:

require_relative 'spec_helper'

describe 'vhost_a' do
  it { should transfer('node_a') }
end

describe 'vhost_b' do
  it { should transfer(['node_b','node_c']) }
end

describe 'vhost_c:80' do
  it { should transfer(['node_b','node_c']).port(80) }
end

describe 'vhost_c:80' do
  it { should transfer(['node_b','node_c']).port(53).udp }
end

describe 'vhost_c:80' do
  it { should transfer('node_c').http.path('/test/') }
end

describe 'vhost_c:443' do
  it { should transfer(['node_b','node_c']).port(80).https.path('/test/') }
end

How it works

#transfer

  1. nodeにsshでログインする
  2. nodeでprobeをキャプチャーする
  3. probeを使ってリクエストを投げる(or パケットを投げる)
  4. nodeにprobeが来ているかで判定する

ここで、nodeではコマンドを実行しているだけなので、nodeに特別なプログラムを入れる必要はない。(ngrepとかtcpdumpが簡単かもしれないが、access.logをgrepするのほうが簡単かもしれない。)

#tranfer works

Configuration

#transfer

キャプチャとリクエストを投げる方法はカスタマイズできる。なので、キャプチャ方法を定義して、自分で投げたいリクエストを生成できる。

RSpec.configuration.lbspec_capture_command =
  lambda do |port, prove|
  port_str = port > 0 ? "port #{port}" : ''
  "sudo ngrep #{prove} #{port_str} | grep -v \"match:\""
end

RSpec.configuration.lbspec_https_request_command =
  lambda do |addr, port, path, prove|
  uri = 'https://' + "#{addr}:#{port}#{path}?#{prove}"
  system("curl -o /dev/null -sk #{uri}")
end

カスタマイズできるのは次のコマンド。

  • lbspec_capture_command with |port, prove|
  • lbspec_udp_request_command with |addr, port, prove|
  • lbspec_tcp_request_command with |addr, port, prove|
  • lbspec_http_request_command with |addr, port, path, prove|
  • lbspec_https_request_command with |addr, port, path, prove|

2014年2月23日日曜日

Trema Day #5 に参加してきた

Trema Day #5に参加してきたので、メモしておく。

感想

TremaはOSSでがんばっている。 小さいところでも貢献したいと思う。(まずはVagrant周りとかでも)

今回は懇親会にも参加できて、楽しかった。 ネットワーク屋が多いが、いろんな分野にまたがっているので、幅があって楽しい。

概要

  • 2014/02/22 (土) 13:00-17:00
  • KDDIウェブコミュニケーションズ CloudCoreセミナールーム
  • atnd
  • ust

他のかたのまとめなど


■意外に違う Trema と Trema-Edge

  • 大芝さん
  • Trema-Edge使ってみてTremaと違うところ
    • Pio, Sinatra が手強い
    • 不具合系の回避策とか(2014/02/22時点)
  • Trema Edgeとは
    • OpenFlow1.3
      • OpenFlow1.3の違いは扱わない
  • 変わっていないところ
    • 起動
      • 違いなし
    • ハンドラ定義
      • 違いなし
        • ポート情報の一覧の取得のところFeaturesRequest/Replyでとれなくなっている
    • タイマー定義とかメッセージ創始とか
      • 違いなし
        • フロー追加はoptionに変更あり(OpenFlow1.3関連?)
  • 変わっているところ
    • パケットインのときのパケット情報取得
      • マッチ条件の名前が変わっている
    • PortStatusのポート情報受け取り
      • PortStatusがPortクラスを継承している
    • PacketOutでデータのみのパケット出力
      • PacketInに指定していないとエラーになる
    • Sinatraとの連携しようとしたときの振る舞い
      • TremaのLoggerがSinatraのモジュールのLoggerとバッティングしている
      • エラーがでない
    • Trema::Pioと連携
      • Trema-EdgeがObjectクラスのところで修正している
      • array?がtrueとかになってしまう
      • ワークアラウンドするとarpとかだせることまで確認
    • 便利メソッドの有無
      • send_flow_mod_add など基本的なところくらいしかない
      • port.up?とかport.down?とかできない
    • Statsメッセージについて
      • マルチパートメッセージになった
    • OpenFlow1.3関連でいろいろ変わっている
      • 割愛

質疑応答

  • Q. Trema-Edgeのテスト用のスイッチとか、ダンプフローとかどうなっている?
  • A. 会社ではOpenFlowスイッチがあるので、あまり使っていない
  • C. sugyoさんがやりかたがあるらしいという情報がある
  • C. なんかやったらできる記憶がある
  • Q. グループテーブルっていまも使える?
  • A. あとで調べる(大山さんがあとでまとめていただける とのこと)

of_protocol で遊んでみた

  • 近藤さん(@Eishun_Kondoh)
  • 資料
  • of-protocolとは?
    • Erlangで実装
    • flowforwading.orgのなかのerlangな人たちが作ったLINCというスイッチのパーサ
    • 使えるバージョンは1.2、1.3のようだ
    • モジュール
      • ofprotocol
        • ofpv4utilsとか使うとなんかできる感じ
  • 使いかた(こんな感じ)
    • of_protocol:encode(#ofp_message)
    • of_protocol:decode(BinaryData)
  • Flower?ベースで作ってみた
    • 3.5klocくらい
    • Tremaにコネクトできた
  • 遊ぶのにはよいと思う。

質疑応答

  • Q. どこら辺を参考にしている?
  • A. LINC-Switchを参考にした
  • A. FlowERを参考にした
  • C. 半年コードを読んで、3ヶ月かけて実装したような感じ
  • C. Erlangの本(飛行機本)にはいろいろ書かれている
  • C. ElixirだとErlangのVMでRubyっぽい
  • C. ElixirだとRubyとかのように文法定義できるかんじ
  • Q. Erlangのメリットは?
  • A. VMの上で動いていて、他のマシンの上にあるVMに移せたりする
  • A. 小さいスレッドが作れる
  • A. 横方法にスケールアウトすることができる
  • Q. 構成図の四角はプロセス?
  • A. 違う。もっとごちゃごちゃしている

■Tremaをもっと手軽で簡単に。

  • 大山さん(@userlocalhost)
  • 素人がTremaを使うにあたって
    • 一般の声
      • Trema 覚えるの大変そう
      • やりたいことは簡単なのにやることが多い
    • 呪文が多い
    • そこで
      • Observed
        • 他のシステムと連携するシステム
      • Observedが仕組み
        • 外部システム連携は各プラグインが肩代わり
    • Trema−Gmail連携
      • Tremaから情報をとって、Gmailに送る
        • observe(見るところ).then(やること) という感じでかくと
    • HTTP-Trema連携
      • 監視しておいて落ちたら、他のサーバに振るテーブルにする
    • Pluginはいくつかある

質疑応答

  • Q. 他のフレームワークは?それとの優位性は?
  • A. JavaでCamelがある。連携作業を並列にやれたり とか効率的にできるように。まだpluginが充実していない。
  • Q. メッセージングで使えるやつのメッセージングツールとの差は?
  • A. fluentdはログに特化している
  • A. Observedはなんでも対応できるフレームワーク
  • Q. Observedは社内でやっているの?
  • A. 完全に個人のレベルでやっている
  • C. 呪文が多すぎる?について、視点が複数ある。サンプルコードが恣意的。
  • C. 共通化できると連携処理はかける
  • C. フレームワークを1つ覚えればいろいろできる
  • Q. 取りこぼしが起こるのか?syslogのように取りこぼしがあるのか?
  • A. 他のシステムに依存するところ。
  • Q. どれくらいTremaに対応しているか?
  • Q. なにができているか?
  • A. statをとる、flowを変更する というレベルはある。
  • C. Trema本体からそとに提供する仕組みがあるといいが、hookしてレポートする仕組みがあれば十分

■Go Deep

  • 千葉さん(@chibacchie)
    • 最近Rubyを勉強し始めた
  • 資料
  • Tremaでコントローラを作るときの課題
    • 受信したところからパケットパースするとるのは面倒だ
    • Rubyでパケットパーサが欲しい
    • libwireshark を使って、rubyに返す
    • ruby-wiresharkを作った
    • wiresharkの対応している分だけメソッドができる
    • まだ公開できるレベルではないが、公開できるようになったら公開する

質疑応答

  • Q. wiresharkのバージョンが変わると変わる?
  • A. 変わる
  • Q. Packetはリアルタイムで見える?
  • A. 見える。pcapの機能である。
  • C. parserの仕事。パースする。treeを表示する。意味がわかる。の両方の機能
  • C. wiresharkが意味づけしてくれる
  • Q. IPアドレスとかはRubyのクラスにマッピングできる?
  • A. できる
  • C. wiresharkのラッピングがgemでなはないのであるとうれしい

■[LT]エクルとリームなネットワーク機器テスト環境の実現

  • 空閑さん
  • ネットワークテスタHWが持つ高精度な試験をSWツールに適用したい
  • チャレンジ
    • アプローチ1: Userspace Dataplane
      • ハードのDataplaneをソフトに持って行く
    • アプローチ2: Timing API
      • パケット送受信のタイミングをNICにオフロード
      • Userspaceからパケットごとに送信タイミングを指定
        • NICにその送信タイミングにしたがって送出する実装を追加する
      • 8nsの精度
    • 2つの時間の指定方法
      • Global(絶対的な指定)
      • Local(相対的な指定)
    • アプローチ3: Programmable Interface
      • Ethernet Character device
        • echo "0000 FFFF"> /dev/ethpipe/0 などのようにする
        • リプレイできる
  • shell scriptで実装してみる
    • shell scriptで書いて8nsの精度でやる
  • アプリケーションとしては
    • latency emuration
    • "Extreme" network testing
    • Generic purpose network IO
  • オープンソースなので使える

質疑応答

  • Q. ppsとかをはかるとかそういうことにも使えるのか?
  • A. 使える。jitterとかを作れる。1GのNICで500Mbpsとかもきれいにだせる。
  • C. 10Gも目指す。
  • Q. bash押しな理由は?
  • A. シンプル化という視点でいうと、cat コマンドというイメージだったから。
  • A. sedとかして、プロセスが重くなる。gnu grepだと6Gbpsくらいはできる
  • A. 高速化を考えるんらASCIIにせずに、binaryで扱うとよいと思う。
  • Q. NICからデータをユーザープログラムが受け取るのは割り込みベース?
  • A. データの割り込みは間引きする
  • Q. いろいろDPDKとかに? ポーリング vs 割り込み
  • A. 割り込みだからできない という話ではない。(バウンダリ周り)

■[LT]VagrantとかTrema-edge switchとかデバッグツール

質疑応答

  • Q. Vagrantまわりで他になにか情報あるか?
  • A. あまりない
  • C. 作ってくれる人がいればぜひ

■[LT]Tremaの作り直し

  • 高宮さん(@yasuhito)
  • Tremaの現状
    • C
      • 37000行
      • test 30000行
    • Ruby
      • 8500行
      • test 7000行
    • 合計
      • 80000行
  • 目標
    • できるところはRubyにしたい(メンテナンスのため)
  • Cの部分の分類
    • switch manager
      • 試しに実装した
        • C: 3000行
        • Ruby : 200行
        • 期間1週間
    • switch daemon
    • openflow ライブラリ
    • main loop
    • messanger
    • packet in filter
  • 試しに実装してみた
    • switch manager
      • C: 3000行
      • Ruby : 200行
      • 期間1週間かかった
  • やることがたくさんある
  • 方針?
    • アプリからやる
    • Trema-Edgeから?
    • TremaでもRuby2.0以上にする予定
    • Tremaでも1.3をサポートする方向で。
    • がちでできるように性能は気にしてほしい
    • 必要なスパイスは消さないように