ラベル 勉強会 の投稿を表示しています。 すべての投稿を表示
ラベル 勉強会 の投稿を表示しています。 すべての投稿を表示

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 さん

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