Serverspec at Testing Framework Meeting

1. Serverspec

2. 自己紹介
• 宮下 剛輔
• mizzy, @gosukenator
• フリーランスのソフトウェアエンジニア

3. Serverspec とは何か
• RSpec でサーバのテストを行うためのツール

4. Serverspec のコード例
describe package('serverspec') do
it { should be_installed.by('gem').with_version('2.24.1') }
end

5. Serverspec のコード例
power-assert 版
assert { package('serverspec').installed?('gem', '2.24.1') }

6. 生み出された経緯

7. 2006年
• 当時の職場では Word で書かれた手順書に基づいて手動でサ
ーバ構築してた
• Puppet を導入した
• 構築は自動化されたけど、構築後のテストはExcelのチェック
シートに目視確認した結果を記述
• 結果をプリントアウトして上長に提出、印鑑を押してもらう

8. 2007年
• Assurer というツールをつくりはじめた
• Perl製
• TAP (Test Anything Protocol) で結果出力

9. Assurer
• Plagger っぽさ（プラグイン、YAMLで設定）
• Serverspecとは違い外部から振舞をテスト
• テスト駆動サーバ構築

10. Assurerの失敗
• 悪い意味で Plagger の影響を引きずっている
• テストしたい内容は YAML で記述
• プラグインも種類が無駄にある
• Filter, Format, Notify, Publish, Test
• 無駄に高機能
• ジョブキューを利用した分散実行とかも実装してた

11. Assurerの失敗（つづき）
• TAP で出力すること以外は Perl プログラムのテストの書き方
とは異なる
• 振舞のテストは状態のテストより面倒
• 作者本人が使うのめんどくさくなった
• そのうち忘れ去られた

12. 2013年
• 自分が書いたPuppetマニフェストをリファクタリングしたく
なった
• リファクタと言えばテストが必要
• rspec-puppet は用途に合わない

13. 2013年（つづき）
• そう言えば hiboma が Sqale のコンテナ構築のテストを
RSpec でやってた
• それを真似してもう少し汎用的なサーバテストフレームワー
クつくったら良さそう
• Serverspec 誕生

14. Assurer と Serverspec の思想の違い
• Assurer はサーバのテストを自動化したいからつくった
• Serverspec はインフラコードのリファクタリングをしたいか
らつくった

15. Serverspec の位置づけ
• Infrastructure as Code を実現するための一ツール
• Infrastructure as Code とは「ソースコードリポジトリ・アプ
リケーションデータのバックアップ・サーバリソースからビ
ジネスを復旧できるようにすること」

16. RSpec について

17. なぜ RSpec なのか
• 社内では Ruby のテストは RSpec が標準だった
• その流れで hiboma が RSpec ベースでコンテナのテストをや
ってた
• その hiboma のやつをベースにつくったので RSpec になった
• なので、特に強いこだわりがあったわけではない

18. RSpec について思うところ
• One-liner syntax の should を好んで使っている
• Object#should は deprecated だけど、One-liner should
はまだ deprecated ではないはず
• serverspec.org での説明もすべて One-liner should を使って
いる
• とは言え、RSpec をそのまま使っているので、Serverspec は
RSpec で使える記法はすべて使える

19. RSpec について思うところ（つづき）
• One-liner should が deprecated になったら RSpec は捨てる
かも
• 記法が変わる、という非本質的なことには振り回されたく
ない
• その場合は実験的に一部 power-assert 対応しているのを
本格対応

20. 実装方針

21. 実装方針
• 導入の敷居を下げる
• ひとつのことをうまくやる
• 他人のために開発しない
• 開放/閉鎖原則

22. 導入の敷居を下げる
• Assurer が使うハードル高すぎて自分ですら使わなくなった
という反省から
• 余計なものをできる限りインストールしない
• Ruby 1.8.7 サポート
• エージェントレス
• serverspec-init コマンド

23. 1つのことをうまくやる
• UNIX 哲学
• サーバのテストのみをやる
• 状態のテストのみで振舞のテストはやらない
• テスト対象ホストの管理、テスト用VM操作、サーバ構成管理
ツールとの連携等はやらない
• 他のツールで補えるのであればそちらに任せる

24. 他人のために開発しない
• 自分が使う機能しか実装しない
• 最初のリリースは、SSH 経由での実行、RedHat 系のみサ
ポート
• Exec など他のバックエンドを選べる仕組みや、他の OS
に対応する仕組みは、他の人が実装してくれた

25. 他人のために開発しない（つづき）
• GitHub の issue 機能は disable にしている
• 必要な機能は、それを必要とする人が実装すべき
• バグも、そのバグで困っている人が直すべき
• 基本的には、自分が使うために開発している、というスタン
スを崩さない
• 燃え尽き防止

26. 開放/閉鎖原則
• 1つのことをうまくやるだけだと機能不足
• Rakefile と spec_helper.rb のカスタマイズで対応
• 既存のコードの修正なしに、追加だけで機能拡張できる
• 「他人のために開発しない」ためにも必要

27. Specinfra

28. Specinfra
• Serverspec から分離した、汎用コマンド実行フレームワーク
• 実行形式（Exec, SSH, WinRM, Docker など）や、OS 毎のコ
マンドの違いを吸収するフレームワーク
• Serverspec 以外のテストフレームワークや、サーバ構成管理
ツールのベースになることを狙って分離
• Itamae や Serverkit のベースにもなっている

29. power-assert 対応

31. 今後やりたいこと

32. 今後やりたいこと
• 実はあまりない
• どう実際の運用に活かしていくか、の方が興味ある
• @sora_h くんが実装中 の infra_operator という ベター
Specinfra への乗り換え

33. 参考文献

34. 参考文献
• O'Reilly Japan - Serverspec
• http://www.oreilly.co.jp/books/9784873117096/
• 論文「serverspec: 宣言的記述でサーバの状態をテスト可能な
汎用性の高いテストフレームワーク」
• https://github.com/mizzy/serverspec-thesis