Serverspec at Testing Framework Meeting

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