2013年12月19日木曜日

Vagrant 1.4.1でCentOS上でdockerを走らせてみる

Vagrantが1.4.1になって、Redhat、CentOSでもdockerのproviderが動くようになったということで、試してみた。

結果

とりあえず動かしてみることは簡単にできた。

Vagrantfileを作る

実行

vagrant up

こんな感じでdockerのコンテナができていることを確認

[otahi@otahiair test-docker-vagrant]$ vagrant up       
Bringing machine 'default' up with 'virtualbox' provider...
[default] Box 'centos65' was not found. Fetching box from specified URL for
the provider 'virtualbox'. Note that if the URL does not have
a box for this provider, you should interrupt Vagrant now and add
the box yourself. Otherwise Vagrant will attempt to download the
full box prior to discovering this error.
Downloading box from URL: https://github.com/2creatives/vagrant-centos/releases/download/v6.5.1/centos65-x86_64-20131205.box
Extracting box...te: 660k/s, Estimated time remaining: --:--:--)
Successfully added box 'centos65' with provider 'virtualbox'!
[default] Importing base box 'centos65'...
[default] Matching MAC address for NAT networking...
[default] Setting the name of the VM...
[default] Clearing any previously set forwarded ports...
[default] Fixed port collision for 22 => 2222. Now on port 2200.
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2200 (adapter 1)
[default] Booting VM...
[default] Waiting for machine to boot. This may take a few minutes...
[default] Machine booted and ready!
[default] The guest additions on this VM do not match the installed version of
VirtualBox! In most cases this is fine, but in rare cases it can
cause things such as shared folders to not work properly. If you see
shared folder errors, please make sure the guest additions within the
virtual machine match the version of VirtualBox you have installed on
your host and reload your VM.

Guest Additions Version: 4.3.4
VirtualBox Version: 4.2
[default] Mounting shared folders...
[default] -- /vagrant
[default] Running provisioner: docker...
[default] Installing Docker (latest) onto machine...
[default] Pulling Docker images...
[default] -- Image: centos
[otahi@otahiair test-docker-vagrant]$ vagrant ssh
[vagrant@vagrant-centos65 ~]$ sudo docker images        
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
centos              6.4                 539c0211cd76        8 months ago        300.6 MB (virtual 300.6 MB)
centos              latest              539c0211cd76        8 months ago        300.6 MB (virtual 300.6 MB)
[vagrant@vagrant-centos65 ~]$ sudo docker run centos echo hello
hello
[vagrant@vagrant-centos65 ~]$ 

2013年8月24日土曜日

RSpecを使ってDNSのテストを自動で実施する方法

DNSのテストを素早く回すことができるrspec-dnsというのがあるので紹介する。 これを使えば、DNSを変更するときにだいぶ安心できるはず。

使うもの

どのように書くのか?

次のように update_config でDNSを指定する。(config/dns.ymlというのを更新するので、なにもやらなければ、config/dns.ymlに記載されているまま) レコードごとにspecを記載していく。 複数のDNSをテストしたい場合は、 update_config でDNSを指定していく。

実行のやり方

  • git clone
    • % git clone -b example https://github.com/otahi/rspec-dns.git
  • move into example directory and run
    • % cd rspec-dns/example
    • % rvm use 1.9.3
    • % bundle install --path=vendor/bundle --binstubs=vendor/
    • % bundle exec rspec -c -f doc

どのような出力になるか?

% bundle exec rspec -c -f doc 

github.com
  should have the correct dns entries with {:type=>"A", :address=>"192.30.252.128"}
  should have the correct dns entries with {:type=>"A", :address=>"192.30.252.129"}
  should have the correct dns entries with {:type=>"A", :address=>"192.30.252.130"}
  should have the correct dns entries with {:type=>"A", :address=>"192.30.252.131"}
  should have the correct dns entries with {:type=>"A", :address=>"204.232.175.90"}
  should have the correct dns entries with {:type=>"A", :address=>"207.97.227.239"}
  should have the correct dns entries with {:type=>"MX", :exchange=>"ASPMX.L.GOOGLE.com", :preference=>10}
  should have the correct dns entries with {:type=>"MX", :exchange=>"ALT1.ASPMX.L.GOOGLE.com", :preference=>20}
  should have the correct dns entries with {:type=>"MX", :exchange=>"ALT2.ASPMX.L.GOOGLE.com", :preference=>20}
  should have the correct dns entries with {:type=>"MX", :exchange=>"ASPMX2.GOOGLEMAIL.com", :preference=>30}
  should have the correct dns entries with {:type=>"MX", :exchange=>"ASPMX3.GOOGLEMAIL.com", :preference=>30}
  should have the correct dns entries with {:type=>"NS", :name=>"ns1.p16.dynect.net"}
  should have the correct dns entries with {:type=>"NS", :name=>"ns2.p16.dynect.net"}
  should have the correct dns entries with {:type=>"NS", :name=>"ns3.p16.dynect.net"}
  should have the correct dns entries with {:type=>"NS", :name=>"ns4.p16.dynect.net"}
  should have the correct dns entries with {:type=>"TXT", :data=>"v=spf1 include:_spf.google.com include:_netblocks.zdsys.com include:sendgrid.net include:mailgun.org include:smtp.github.com ~all"}
  should have the correct dns entries with {:type=>"SOA", :mname=>"ns1.p16.dynect.net", :rname=>"hostmaster.github.com", :refresh=>3600, :retry=>600, :expire=>604800, :minimum=>60}

Finished in 2.4 seconds
17 examples, 0 failures
% 

Reference

2013年8月4日日曜日

Linux Container (lxc) on Cent OS 6.4 on Vagrant VM

Linux Container(lxc) on Cent OS 6.4 on Vagrant VM

vagrant で作ったCent OS 6.4 のVMの上に、Linux Containerを複数起動できる環境を作る方法をまとめる。 中身はgithubを参照のこと。

背景

  • MacやWindowsをホストとして利用するときに、Linux由来のツールをそのまま利用することが難しい場合がある。
    • たとえば、iptables, openvswitch など
  • lxcの情報はUbuntuの情報が多く、いつも使っているCent OSの情報が少なかったので、ちょっと試した。
  • ちょっとした複数マシン連携のテストなんかに使えるかな?と思う。
  • Tremaの環境を作って遊びたいときに使えるのではないか?とか。

構成

lxcのVM2つをvagrant で作ったCent OS のVMの上に作る。

layout.

事前条件

  • VirtualBox installed(upper 4.2.16)
  • vagrant installed(uppper 1.2.0)
  • vagrant box has been set as "centos64-base"
    • %vagrant box add centos64-base http://developer.nrel.gov/downloads/vagrant-boxes/CentOS-6.4-x86_64-v20130427.box
      • ここのURLはそのうちなくなるかもしれない

動かし方

  • git リポジトリをとってくる
    • %git clone https://github.com/otahi/vagrant-centos-lxc.git
  • vagrant up
    • %vagrant up
  • しばし待つ
  • vagrant VMにログイン
    • %vagrant ssh
  • lxc VMs にログイン
    • %sudo lxc-console -n vm1
    • %sudo lxc-console -n vm2
  • これで構成図のとおりのVMが動いているはず。

2013年7月28日日曜日

Trema Day #3 に参加してきた(一部)

Trema Day #3に参加してきたので、まとめる。 ぜんぜんまとまっていないが、とりあえず出す。ということで。。

全体(といっても前半)

4歳の息子が一緒にいきたがったので、連れて行ったが、 結果としては最初に少し間に合わず、途中で帰ることに。。

ustに録画がでたので、あとでこちらを参考に、あとで書き直す予定。

Wakame-VDCの話はとても興味深かった。 TremaをHiper Visorごとにいれてあり、それを集中管理するという方法が、 「そういう使い方もあるのか」と思った。 Wakame-VDC自身も興味深かった。lxcとかも使えるということで、 Macの上にVMを立てて、いろいろ遊べる気がした。 ちょっといろいろ調べてみようと思う。

RubyでPacketParserの話も興味深かった。 今回はLLDPの話だったが、もっとレイヤが上位のパケットを考えると、 tcpdumpレベルでは難しいパケットの抽出もでき、 解析もけっこうやりやすくなるのかもしれないと思った。

概要

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

他のかたのまとめ

Wakame-VDCの仮想ネットワーク

  • あくしゅ 山崎泰宏( @sparklegate )さん
  • Virtual Networking
    • 構造
      • Agent Network
    • VM同士のネットワーク
    • eth0とeth1でeth1をマネジメントにしてhva(Hyper Visor Agent)を接続
    • 分離
      • 物理NW
      • 論理NW
      • VM
    • WakameではHVに1つのovs、1つのhva(Tremaコントローラ含む)
    • dhcp、dnsなどはTremaコントローラで折り返す
    • トンネリング
      • MAC2MAC(と呼んでいる方法を使っている)
        • ARPのブロードキャストドメインをコントロール
        • ARPブロードキャストをユニキャストに変換する(これでスイッチは学習できる)
          • L3は超えられない
      • DBで管理できているので、それを使ってやる
    • WakameではTremaとovsの間はUnixSocket通信している
    • Wakame-vnetというのを切り出そうとしている
  • Q&A
    • RabbitMQからZeroMQにした理由は?
      • セルロイドというライブラリがzeroMQだった
      • 小さいパケットの処理が早い
    • ブロードキャストをユニキャストに変換するのはarp以外にも制御できる?
      • 明らかに対向がわかるものしかできない
  • 資料
    • 見つけられていないが、OPEN CARFの資料を参考にするとちょっとわかりやすいかも。

OpenFlowでSDN作りました

  • 中程さん@UEC
  • ospf -> sospf関連のとOpenFlowの話
  • ospfだと経路が重なり輻輳の問題がある
    • それを解決したい
  • 今回はPOXで書いたので長くなってしまった

Rubyでパケットパーサ

  • @yasuhito さん
    • trema #3の話
      • Lineを貼ってみた
      • フィールドオブドリームズのように人が来る
    • 今回はコンビニの大木さんが発表。
  • LLDPを使ったトポロジ探索サンプルプログラム
    • 短く、読みやすく、改造しやすく
    • LLDPジェネレータとパーサ
    • PacketFu
      • ちょっと流儀が。。
    • Racket
      • おしい
    • BinData
      • けっこう使われている
      • バイナリをパースするライブラリ
      • DSL的
  • BinData
    • プリミティブ型があり、それを組み合わせて定義できる
  • Trema::Packetとして共通部を切り出してやっていければなと思う
  • 資料

OpenFlowの可視化ツール

  • 大山裕泰さん
  • ***ここで帰ることになってしまった。。***

LT 安くOFS&冗長化

  • あとで

LT OpenStackでのトラフィックフロー制御

Virtual Network Platform の紹介

2013年6月28日金曜日

Vagrantでパケアナ #pakeana 16

第16回「ネットワークパケットを読む会(仮)」で話した。

PC上のVMで他人に迷惑をかけずに実験をするための方法を考えたので、突っ込みをください。


Vagrant packana16-otahi from Hiroshi Ota


※init.shの最終行は2013/06/29追加。これがないと、HostOnlyNetwork以外はIPパケットがでない。

@twovs さんの「how to GET GET」はあとで役に立つと思うので、メモしておく。

2013年6月26日水曜日

Private Proxy Settings

Background

いくつかの企業ではproxyサーバ経由でhttp(s)クライアントが 企業の外にあるサーバにアクセスする必要がある。 場合によっては、proxyサーバはusername/passwordの認証を要求する。 http(s)クライアントによっては、認証ありのproxyサーバを使えない場合もある。

Purpose

ここでは複数のhttp(s)クライアントのproxy設定を削減するためのproxy設定を提供する。

layout. proxy can use upstrem proxy

Note

  • 権限に従って設定してください

Specs

  • proxyサーバはlocalhost/hostonlynetworkにのみサービスを提供する
  • proxyサーバは上流proxyサーバのusername/passwordのペアを保持する
  • proxyサーバはインターネットへのアクセスに上流proxyサーバを使う

How-to run

  • Git clone
    • %git clone https://github.com/otahi/private_proxy_settings.git
  • Modify squid.conf for your own environment
    • %vi squid.conf
  • Install squid
    • eg[mac].
      • %brew install squid
    • eg[cygwin].
      • %apt-cyg install squid
  • Put squid.conf to right place
    • eg[mac].
      • %cp squid.conf /usr/local/etc/
    • eg[cygwin].
      • %cp squid.conf /etc/
  • Create a directory
    • %sudo mkdir -p /var/cache/squid/
  • Change owner a directory and a file for nobody
    • %sudo chwon nobody:nobody /var/cache/squid
    • %sudo chwon nobody:nobody /var/log/squid.log
  • Create cache directory
    • eg[mac].
      • %sudo /usr/local/sbin/squid -z
    • eg[cygwin].
      • %/usr/bin/squid -z
  • Run squid
    • eg[mac].
      • %sudo /usr/local/sbin/squid
    • eg[cygwin].
      • %/usr/bin/squid
  • Run squid as a daemon
    • eg[mac].
      • %sudo /usr/local/sbin/squid -k shutdown
      • %sudo install -oroot -gwheel squid.plist /Library/LaunchDaemons/
      • %sudo launchctl load /Library/LaunchDaemons/squid.plist
    • eg[cygwin].
      • TODO check cygserver

How-to use a proxy server

Set envirionment variables or browser settings

set environment variables for the proxy(for local application)

eg.

export HTTP_PROXY=localhost:3128
export HTTPS_PROXY=$HTTP_PROXY
export FTP_PROXY=$HTTP_PROXY
export http_proxy=$HTTP_PROXY
export https_proxy=$HTTP_PROXY
export ftp_proxy=$HTTP_PROXY

set environment variables for the proxy(for VMs)

eg[192.168.100.1 is a proxy server in a hostonlynetwork].

export HTTP_PROXY=192.168.100.1:3128
export HTTPS_PROXY=$HTTP_PROXY
export FTP_PROXY=$HTTP_PROXY
export http_proxy=$HTTP_PROXY
export https_proxy=$HTTP_PROXY
export ftp_proxy=$HTTP_PROXY

2013年6月22日土曜日

hbstudy#45「serverspecが拓いたサーバテストの世界」に参加してきた

開催概要

  • hbstudy#45
  • 2013/06/21(金) 19:00〜
  • ハロー会議室新宿
  • 第45回: serverspecが拓いたサーバテストの世界

感想

  • 宮下さんを見習って、子供と一緒にがんばろうと思う。
  • まずは自分の担当するところでまずは試してみよう。
  • 最後にテストを回すというスタイルから、できあがったときにはテストは終わっているという状態にしていきたい。

全体まとめ

  • serverspecは
    • 機能が欲しい人が実装するという基本
    • puppet, chefとかの仕組みと疎結合
      • できあがったserver自体をテストするので
    • 「読みやすい、書きやすい、わかりやすい」を大切にしている
    • spechelperを書き換えればいろいろできる
  • 気軽にpull requestしてほしい
  • やりたいことがあれば各自実装を!

追加情報(2013/06/23追加)

paperboy&co. Technical Manager 宮下 剛輔さん [twitter: @gosukenator]

serverspecの位置づけ、serverspecとは、使い方

  • 宮下さん @gosukenator
    • paperboy&co
      • ロリポップなどのレンタルサーバなどで有名
  • サーバプロビジョニングとは
    • いろいろな領域が含まれる(大きくは3つ)
      • Application Service - Orchestration
        • 方法
          • Capistrano
          • Fabric
        • テスト
          • 外から見る
            • zabbix
            • Nagios
      • System config - Configration(きょうはここが中心)
        • 方法
          • puppet
          • chef
        • テスト
          • serverspec
            • サーバ自身を見る
            • パッケージとかもみる
      • os, vm - BootStrapping
        • EC2
        • OpenStack
    • 監視とは継続的なテストである @kazuho
    • Zabbixとかあれば、serverspecいらない ともいえなくはない
      • Zabbixで継続して監視ししながら実装できるのであれば
  • System configとテスト
    • これまでは?
      • shell script?
      • 実際のサービスの確認だった?
  • Configuration Management Framework(CMF)
    • puppet
    • chef
    • ansible
      • orchestrationも含んでいるツール
  • CMFとテスト
    • これまでは?
      • shell script?
    • 界隈のツール
      • シンタックスチェック
        • foodcritic
        • knife cookbook test
      • ユニットテスト
        • chefspec
          • 実際のサーバでやるのではない
          • chefの正当性を確認するためのツール
        • rspec-puppet
      • 結合テスト
        • Minitest Chef Handler
        • Cucumber Chef
        • Test Kitchen
        • rspec-system
          • puppet用
        • serverspec
          • puppetでもchefでも
    • なぜ serverspecを作ったの?
      • 余計な機能が多い
      • chef,puppetなどのツールに依存している
    • TestKitchenと合わせると良さそう
    • そもそもserverspecが必要なの?
      • 一度だけ書いて、修正しないなら不要
      • マニフェスト、レシピを継続的に更新するなら必要
        • これの自動化のために必要
      • テストコードの書きやすさ、読みやすさも重要
      • テストツールのシンプルさが重要
        • なので、serverspec
  • serverspecについて
    • サーバのテストを「簡潔に」書くための仕組み
      • RSpecで書く
        • 読みやすい
          • 最近expectで書くのがよいとされている→少し読みにくい
      • しかし、shouldのほうが見やすい
        • serverspecではshould全部のオブジェクトにshouldメソッドをつける必要がないのでよい
    • serverspecはshellからコマンドたたいているだけ
    • コマンドのパターン
      • ローカル
      • ssh接続
        • エージェントをいる必要はない
        • コマンドを実行するだけなのでテスト対象にはrubyすらいらない
  • severspecのはじめかた
    • # yum install rubygems
    • # gem install serverspec rake
    • # serverspec-init
      • ssh or local?
      • ファイル、ディレクトリができる
    • # rake spec
      • .rspec で–colour で色つく
      • –format S で文字列で表示
      • まさにテスト駆動でできる

serverspecについて

  • serverspecが生まれた経緯
    • 2007年 puppetを使い始めた
    • puppetで構築は自動化できた
    • テストをどうするか?
    • テスト報告を簡単に作りたい
    • Assurerというperlツール作った
      • テスト駆動サーバ構築! 2007年
      • 面倒。。
        • レポーティング機能をつけたので重くなった
      • 実用にいたらなかった
    • puppetのマニフェストのリファクタリングをしようと思った
    • テストが必要だろう
    • rspec-testはモジュール型になっているマニフェストのテストにしか使えない。。
      • モジュールかされていないものにはテストがかけない
    • マニフェストをテストではなくて、実際のサーバの状態をテストすればよい
    • @hibomaがやっていたこと をパクッてgem化した
    • sshでできるように、rubyなくていいようにした
    • local実行、OS判別などを追加してもらった
  • なにができる?
    • いろいろマッチャがある
    • 任意のコマンドがたたける
    • sshのときはstderrとstdoutが混ざる
  • serverspec.orgをみて
  • サポートOS
    • サポートしている
      • Redhat系
      • Debian
      • Gentoo
      • Solaris
      • Darwin
    • サポートしていない
      • BSD
        • 利用者がいないから??
      • Windows
        • 以前移植しようとしている人がいたがまだpull requestがきていない。。
  • serverspecはsudoしてrootで実行している
    • sshのみ
    • Localではsudoはしない(たたくときにできるから)
  • パスの追加設定もできる
    • spec helperで
    • システムが違うとだめだから
  • 一部パスを追加することもできる
  • precommandでテストコマンドの前に実行して&;&で実行できる
    • 今後サポートするかは不明
  • サーバーごとにディレクトリを掘る
  • ロール単位とかもできるserverspec.orgのadvanced tipsにある
  • テストを常に実行する環境を作りたかった
    • Ukigomo
      • IRCでもできる
  • 一部を変更したときに全体を壊していないことを確認できる
    • CIできる

serverspecのコントリビュータを増やすための話(メモれていない。。)

  • プログラムの内部の話 github-mizzy/serverspec
    • fileの例(コードを読むと結構わかりやすい気がした。)
    • beinstalledの例
  • serverspecのテストの話(十分理解はできなかった。。)
  • 全部実装していなくてもpull requestしてほしい
    • 作業中の場合はWIP(work in progress)とつけておく
    • 自分のOSで動けばOK(他のOSを気にしているときつくなるので)
    • お気軽にpull requestしてください

まとめ

  • 読みやすい、書きやすい、わかりやすい
    • 簡潔
      • 簡潔さ重要
  • 要件が変わる
    • 継続的なテストが必要
    • テストも複雑になる
      • 簡潔にし続ける

質問

  • Q. ユーザーはサーバに対して固定?
    • spechelperが固定になっているが、対応付けすればOK
  • Q. このユーザーはこれができて、このユーザーはこれができない というのはできない?
    • 基本はやりたい人が実装してもらえれば。。
    • コマンドをかけるので、sudoを使ってコマンドで書いてもよいかも
  • Q. paperboyも実運用で使っている?
    • まだあまりない
  • Q. 量が多くなると、時間かかる?
    • RSpecの並列化ができるのではないか?

イベント告知(馬場さんより)

  • 立て続きにあるので、各自確認を
  • hbstudy#46 トラブル☆しゅーたーず#06 ~chain reaction~
    • 日時: 2013/6/29(土) 13:30~20:00
    • 会場: ニフティ株式会社 ラウンジ&会議室
  • hbstudy#47 July Tech Festa 2013 コードの中のインフラ(Infrastructure as Programming)
    • 日時: 2013/7/14(日) 10:00~21:00
    • 会場: 産業技術大学院大学(AIIT)
  • hbstudy#48 インフラ+セキュリティ=楽しい? 他2本
    • 日時: 2013/7/19(金) 19:00~21:30
    • 会場: ハロー会議室 新宿 B+C (東京都新宿区西新宿1丁目5-11 新宿三葉ビル6F)
    • DeNA茂岩さん がいろいろとお話を。

2013年4月21日日曜日

Trema Day #2 に参加してきた

1.1 概要

1.2 全体

OpenFlow/SDN周辺を勉強しないとなと思いながら、 ずっと手をつけられていなかったが、 Tremaでいい加減OpenFlowを体験してみようと思い、 Trema day #2に参加した。

会場はネットワーク系のエンジニア7割、サーバ・アプリよりのエンジニア3割という 感じの参加者だった。

OpenFlow関連の技術はまだユースケースが多くなく(データセンターなどでは一部確立できている部分はあるが)、 どのようにOpenFlowをやっていくか というところの議論が多く、ためになった。 IPv6と同じ(?)で、なかなか、キラーアプリがない状態で、 エンジニアがこれは大事だとは思いながらも、実際にどのように いまの環境、会社に適用していくか というところのイメージがあまりない状態だと思う。

手段の目的化もときにはあってよいと思うので、 エンジニアは、この技術を心に秘めて、いろんな困りごとを見て、 OpenFlowを使うと、その困りごとがどのように解決できるか というのを探し続けるのかな と思う。 (アプリ開発者と机を隣にするという議論もあったが、そういうことだと思う。)

Tremaをまだほとんど触れていないので、 どこら辺に困難があるかわかっていないため、 理解ができていないところが多いと思うが、メモしてみる。

次回のTrama Dayには違う視点で話を理解できるように、 まずは、ソースコード読んだり、実装してみたりしよう。 テストフレームワークも。。

参考:nanapi社長日記 - 「目的があっての手段だ」なんて考え、つまらなくないですか?

1.3 OpenFlow 1.2で、トラフィックエンジニアリングを試してみた by @ttsubo さん

OpenFlow 1以降で追加された機能のひとつである、マルチフローテーブルを使って、 通信種別によってパスを使い分けて、経路に問題が発生したら、 瞬時に切り替えるということをやっていた。

通信種別はTOS(Type of Serive)を使って分けていて、 普段は別の経路を指定して、いざというときには、 同じパスを通るようにする という手段だと思う。

この手法であれば、コントローラに負荷をかけずに マルチパス、と問題発生時の切り替えができる と理解した。

ちなみに、説明の中にでてきたOAMはOperations Administration and Maintenanceの略のようだOAMの説明を読むとそうかなと思う。

資料リンク

1.4 Tremaで作る実用OpenFlowコントローラ by @chibacchie さん

いろいろな事情があって、いろいろ話せないことがあった模様。 前半はOpenFlowを(TremaのC言語ライブラリで)実装するときの注意点。

  1. TremaはOFCではない
    • Tremaはフレームワーク
    • 他のライブラリを使えばよい
  2. OFSはデータベースではない
    • Flow modは確実にすぐに実行されるわけではない
    • Barrier Requestをすると実行される
      • apps/transaction manager
  3. 非同期でイベントが発生する feathres request/replyよりも前に
    • そういうことも考慮する
    • 無視するための処理が必要
  4. send_openflow_messageはqueueに追加するだけ
    • 順序の保証もない
  5. libtramaはthread safeではない関数がある
    • thread safe化プロジェクトをこじんまりとしている
  6. send queueは固定長
  7. flush_messenger()を読んではいけない
    • Handlerが再帰的に呼ばれる可能性がある
  8. start_tremaはfork(2)を呼ぶ可能性がるので注意

後半は、大量のネットワークスライスを制御するために、 OpenFlowController(Work)を配置して、REST APIで制御する システムの説明だった。

WorkerとDBを使って負荷分散するとスケールアウトで対応できそうだな と思う一方、勉強しないと大変そうなところがわからないな と思った。

資料リンク

1.5 SDN人生相談

みなさん、エンジニアとして悩んでいるなと。 (全体のところで省略。)

1.6 会社をOpenFlowにしちゃおう by 大山さん

会社に入ると説明責任がある。 ただ自分がやりたいからやるではできない。 なので、GUIで可視化して、OpenFlowとかをやっていきたい という趣旨と思う。

利用者(一般社員、アプリ開発者、サーバ管理者、インフラ運用者)によって、 いろいろみたいビューが違うので、それを表現できるようにしたらよいのでは?という コメントがあったが、 そうだなぁ と思った。

インフラのエンジニアとしては、数あるネットワーク機器で 問題が発生していたらすぐにわかるように、とか、 いつもと違うことがすぐにわかる(感覚的に)といいなぁ と思った。

1.7 Tremaで構築中小企業の社内LAN by 近藤さん

中小企業で実際にOpenFlowで社内ネットワークを構築した という話。

これこそ、手段の目的化だが、 実際にやってみないと、なにが問題なのか どうなのかがわからない というところから出発していて、 自分もこういうアプローチでいくのかな と漠然と思った。

社内LAN環境だと、場合によってはセキュリティを絡めて、 Radiusとかの認証と組み合わせてもよいかな と思った。

1.8 LT - 手半田でつくるEthernetスイッチ箱 by @SRCHACK さん

自作でEthernetスイッチ箱を作るという話。 詳しくはInteropのORCを参照のことということで、 Interopで時間をとって見に行こうと思う。

2013年4月20日土曜日

ネットワークパケットを読む会(仮) 14回に参加してきた

1.1 概要

  • ネットワークパケットを読む会(仮) 14回

1.2 全体

初めてネットワークパケットを読む会(仮)にパケット解析経験者として参加した。 今回はフレッシャーズ向けということで、パケット解析のいろは、 パケット解析の心得、パケット解析の黒い部分?について、 振り返ることができて、とてもよかった。

月曜日からは心得にしたがって、正常系のパケットをいっぱい見るようにしようと思う。

次回は2013/05/24(金)を予定しているとのことなので、こちらも参加したいと思う。

1.3 フレッシャーのためのパケット解析入門 by @hebikuzure さん

パケットの解析とはなにか、パケットを採る場所、方法、ツールなどの紹介だった。

パケットツールの紹介では、Wireshark、tcpdump を中心にいろいろなツールの紹介があった。 その中で、NetworkMinerというツールの紹介があった。 このツールは、キャプチャした通信から、ファイル、画像などが見やすい形で 表示することができるツールで、アプリケーションの通信でどのような 通信がされているかを見ることができ、Wiresharkとは違った用途で使えそうだ。

また、Windowsの場合は、MicrosoftのNetwork Monitorがパケットとプロセスの情報とを 結びつけられるということで、これも使えそうだ。

資料リンク

1.4 tcpdumpから始まるネットワークエンジニアの朝 by @twovs さん

ネットワークエンジニアとしての心得を紹介だった。 経験に基づき、どのようなところに着目するか、どのように 異常に気づくかを簡潔にまとめてあった。

その中で、一番こころに残ったのは、 「正常系のパケットをいっぱい見よう」「パケットは読むんじゃない感じるんだ」というところ。

日頃から正常系のパケットを見ていると、 異常が起こったときに、パケットの感じが違う ということに気づくことができる。 tcpdumpで多くのパケットを見ることで、正常系を意識に残す。 もし、tcpdumpでなにか違う と思ったら、Wiresharkでじっくり現象を見ていく と いうように、tcpdumpでパケットを感じるということが大切だということだった。 (だいぶ意訳がはいっているが。。)

資料リンク

1.5 とある環境(3G回線)であるアプリのパケットを見てみた by @totoromasaki さん

ちょっとここではかけない。。 とても黒い感じがした。