Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Serverspec at Testing Framework Meeting

5,422 views

Published on

Serverspec at Testing Framework Meeting

Published in: Technology
  • Be the first to comment

Serverspec at Testing Framework Meeting

  1. 1. Serverspec
  2. 2. 自己紹介 • 宮下 剛輔 • mizzy, @gosukenator • フリーランスのソフトウェアエンジニア
  3. 3. Serverspec とは何か • RSpec でサーバのテストを行うためのツール
  4. 4. Serverspec のコード例 describe package('serverspec') do it { should be_installed.by('gem').with_version('2.24.1') } end
  5. 5. Serverspec のコード例 power-assert 版 assert { package('serverspec').installed?('gem', '2.24.1') }
  6. 6. 生み出された経緯
  7. 7. 2006年 • 当時の職場では Word で書かれた手順書に基づいて手動でサ ーバ構築してた • Puppet を導入した • 構築は自動化されたけど、構築後のテストはExcelのチェック シートに目視確認した結果を記述 • 結果をプリントアウトして上長に提出、印鑑を押してもらう
  8. 8. 2007年 • Assurer というツールをつくりはじめた • Perl製 • TAP (Test Anything Protocol) で結果出力
  9. 9. Assurer • Plagger っぽさ(プラグイン、YAMLで設定) • Serverspecとは違い外部から振舞をテスト • テスト駆動サーバ構築
  10. 10. Assurerの失敗 • 悪い意味で Plagger の影響を引きずっている • テストしたい内容は YAML で記述 • プラグインも種類が無駄にある • Filter, Format, Notify, Publish, Test • 無駄に高機能 • ジョブキューを利用した分散実行とかも実装してた
  11. 11. Assurerの失敗(つづき) • TAP で出力すること以外は Perl プログラムのテストの書き方 とは異なる • 振舞のテストは状態のテストより面倒 • 作者本人が使うのめんどくさくなった • そのうち忘れ去られた
  12. 12. 2013年 • 自分が書いたPuppetマニフェストをリファクタリングしたく なった • リファクタと言えばテストが必要 • rspec-puppet は用途に合わない
  13. 13. 2013年(つづき) • そう言えば hiboma が Sqale のコンテナ構築のテストを RSpec でやってた • それを真似してもう少し汎用的なサーバテストフレームワー クつくったら良さそう • Serverspec 誕生
  14. 14. Assurer と Serverspec の思想の違い • Assurer はサーバのテストを自動化したいからつくった • Serverspec はインフラコードのリファクタリングをしたいか らつくった
  15. 15. Serverspec の位置づけ • Infrastructure as Code を実現するための一ツール • Infrastructure as Code とは「ソースコードリポジトリ・アプ リケーションデータのバックアップ・サーバリソースからビ ジネスを復旧できるようにすること」
  16. 16. RSpec について
  17. 17. なぜ RSpec なのか • 社内では Ruby のテストは RSpec が標準だった • その流れで hiboma が RSpec ベースでコンテナのテストをや ってた • その hiboma のやつをベースにつくったので RSpec になった • なので、特に強いこだわりがあったわけではない
  18. 18. RSpec について思うところ • One-liner syntax の should を好んで使っている • Object#should は deprecated だけど、One-liner should はまだ deprecated ではないはず • serverspec.org での説明もすべて One-liner should を使って いる • とは言え、RSpec をそのまま使っているので、Serverspec は RSpec で使える記法はすべて使える
  19. 19. RSpec について思うところ(つづき) • One-liner should が deprecated になったら RSpec は捨てる かも • 記法が変わる、という非本質的なことには振り回されたく ない • その場合は実験的に一部 power-assert 対応しているのを 本格対応
  20. 20. 実装方針
  21. 21. 実装方針 • 導入の敷居を下げる • ひとつのことをうまくやる • 他人のために開発しない • 開放/閉鎖原則
  22. 22. 導入の敷居を下げる • Assurer が使うハードル高すぎて自分ですら使わなくなった という反省から • 余計なものをできる限りインストールしない • Ruby 1.8.7 サポート • エージェントレス • serverspec-init コマンド
  23. 23. 1つのことをうまくやる • UNIX 哲学 • サーバのテストのみをやる • 状態のテストのみで振舞のテストはやらない • テスト対象ホストの管理、テスト用VM操作、サーバ構成管理 ツールとの連携等はやらない • 他のツールで補えるのであればそちらに任せる
  24. 24. 他人のために開発しない • 自分が使う機能しか実装しない • 最初のリリースは、SSH 経由での実行、RedHat 系のみサ ポート • Exec など他のバックエンドを選べる仕組みや、他の OS に対応する仕組みは、他の人が実装してくれた
  25. 25. 他人のために開発しない(つづき) • GitHub の issue 機能は disable にしている • 必要な機能は、それを必要とする人が実装すべき • バグも、そのバグで困っている人が直すべき • 基本的には、自分が使うために開発している、というスタン スを崩さない • 燃え尽き防止
  26. 26. 開放/閉鎖原則 • 1つのことをうまくやるだけだと機能不足 • Rakefile と spec_helper.rb のカスタマイズで対応 • 既存のコードの修正なしに、追加だけで機能拡張できる • 「他人のために開発しない」ためにも必要
  27. 27. Specinfra
  28. 28. Specinfra • Serverspec から分離した、汎用コマンド実行フレームワーク • 実行形式(Exec, SSH, WinRM, Docker など)や、OS 毎のコ マンドの違いを吸収するフレームワーク • Serverspec 以外のテストフレームワークや、サーバ構成管理 ツールのベースになることを狙って分離 • Itamae や Serverkit のベースにもなっている
  29. 29. power-assert 対応
  30. 30. 今後やりたいこと
  31. 31. 今後やりたいこと • 実はあまりない • どう実際の運用に活かしていくか、の方が興味ある • @sora_h くんが実装中 の infra_operator という ベター Specinfra への乗り換え
  32. 32. 参考文献
  33. 33. 参考文献 • O'Reilly Japan - Serverspec • http://www.oreilly.co.jp/books/9784873117096/ • 論文「serverspec: 宣言的記述でサーバの状態をテスト可能な 汎用性の高いテストフレームワーク」 • https://github.com/mizzy/serverspec-thesis

×