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

開催概要

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

感想

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

全体まとめ

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

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

• @gosukenator さんがいっていたPodcastがでてた
  • ep14: Test Driving DevOps with Docker, chef and serverspec (naoya, mizzy) - Tatsuhiko Miyagawa's Podcast
• 「hbstudy#44 「serverspecが拓いたサーバテストの世界」 #hbstudy」をトゥギャりました。 by @sechiro さん

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

発表資料:serverspec by 宮下さん

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で
  • システムが違うとだめだから
• 一部パスを追加することもできる
• pre_{commandでテストコマンドの前に実行して&};&で実行できる
  • 今後サポートするかは不明
• サーバーごとにディレクトリを掘る
• ロール単位とかもできるserverspec.orgのadvanced tipsにある
• テストを常に実行する環境を作りたかった
  • Ukigomo
    • IRCでもできる
• 一部を変更したときに全体を壊していないことを確認できる
  • CIできる

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

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

まとめ

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

質問

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

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

• 立て続きにあるので、各自確認を
  • インフラエンジニア勉強会hbstudy
• 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茂岩さん がいろいろとお話を。