概要
hbstudy で serverspec の作者 @gosukenator さんが「serverspecが拓いたサーバテストの世界」と題してお話されたもののメモ。すでにこちらで資料も公開されています！
自己紹介
- mizzy さん
- 学生
- puppet のススメ
サーバープロビジョニング
Provisioning Toolchain
- Bootstrapping のテストツールは...？
- Configuration（puppet chef）の テストツールとして serverspec
- Orchestration（capistrano…）のテストツールとして Nagios とか zabbix
サーバープロビジョニングとテスト
- 監視とは継続的なテストである
- zabbix や Nagios で apache を監視する場合
- serverspec で apache を監視する場合
- httpd プロセスが動いているか？
- 自動起動するか？
- パッケージがインストールされているか？
- configuration のテスト
- Nagios とか Zabbix があれば serverspec は不要論
Configuration とテスト
serverspec 登場前？
- シェル叩く
- ブラウザでアクセスする
configuration management framework
- puppet
- chef
- ansible works（？）
- オーケストレイヤーも含む？
configuration management framework と test
- 従来はシェル
この界隈はテスト・ツールが乱立？
シンタックステスト
- foodcritic
- cookbook test
ユニットテスト
結合テスト
- serverspec
- test kitchen
- cucumber chef
Instructure as code
- Instructure as code は自然の流れ
なぜ、serverspec を作ったか？
- 既存のツールは機能が多い
- 特定の環境に依存しない
- test-kitchen と serverspec の組み合わせが良いらしい
puppet や chef を使っていて servespec が必要か？
- 一度書いたマニフェストやレシピを更新しないのであれば不要（たぶん）
- 継続的に更新するなら必要
- プログラムのリファクタリングと一緒
- テストの自動化が必要
- 自動化するならコードに落としこむ
- テストコード自体のメンテナンスも必要
- テストコードの読みやすさ、テストツール自体のシンプルさも重要
serverspec
- サーバーのテストを簡潔に書くための仕組み
- rspec で記述
- rspec は ruby のテストフレームワーク
- shoud とか should_not
- expect(file '/etc/hoge') が推奨
- オブジェクトに should を付けるのは非推奨
中身
シンプル
- chkconfig とか叩いている
テスト対象に ssh してコマンドを叩く
一言で言うと...
- シェル・コマンド実行によるサーバーのテストをスマートにやれるようにしたのが servespec
serverspec の始め方
- さくっとインストール
- さくっとデモ
- serverspec-init
spec_helper
- DetectOS で OS を自動判別する
- .ssh/config の設定を読み込む
- :user をユーザー名で書き換えても良い
その他
- local を選ぶと ssh 関連の設定は入らない
- --color オプションを付けると見やすい
- --fomat s オプションを付けると何が成功しているかがわかる
テスト駆動型
- テストしてサーバーを構築していく
serverspec が産まれた経緯
- 2007 年に puppet を導入することにした
- puppet でサーバー構築の自動化出来ました
- じゃあ、テストはどうするか？→テスト報告書
- Assurer（Perl で書いた）→多機能で実用に耐えなかった
2013 年
- puppet マニフェストのリファクタリングをやろうと思った
- puppet の最近のベストプラクティスはモジュール化
- rspec-puppet はモジュールのテストにしか使えない
- puppet 適当後の状態のサーバーをテストしたい
- @hiboma さん → LXC で構築したサーバー（コンテナ）をテストしてた
- ぱくって gem にしよう
- サクッと作って、さくっと gem にした
- localhost は考慮されず、RedHat 系のみを対象にした
もう少し詳しい serverspec の話
リソースタイプ
- サーバー上のリソース（commnad とか cron とか...）
- マッチャー
- ディレクトリもファイルの一つ
複数 OS
- BSD 系は非対応
- 使ってる人が居ない…
tips
- root 権限（sudo をつけてコマンド実行）
- path を追加することが出来る
- pre_command を実行してから...
- 将来変わるかも...
- 詳しくは web で
- Advanced Tips
インフラの継続的インテグレーション（ukigumo）
- CI 環境
- テストの結果をまとめてくれる
- IRC に飛ばしてくれる
- 全体を壊していないかを確認することが必要
プログラム内部の話
コードが書けないので 100 分 1 くらいしか理解できていない。
should be_file を参考に...
describe file ("hoge") do
it { should be_file }
end
上のようなマッチャーの場合には...
- be_file.rb → exec.rb → base.rb のような順で呼ばれる
- exec.rb の
method_missing→check_zeroからの base.rb までたどり着く
def check_file file
"test -f #{escape(file)}"
end
改めてコードを追ってみると、自分のようなド素人でも追えてしまうのは、やはりシンプルな作りに徹している mizzy さんの努力の賜物なのではと思う。
backend::ssh と backend::exec
- ret=ssh.exec!(command)
- OS ごとの切り替え
- リモートかローカルか
chain
- .by ('gem')
serverspec 自体のテスト
github でのコントリビュート
- 日本語で OK
- 途中でプルリク OK
- [Working In Progress]
- 動作確認は自分が使っている OS だけで OK
- テストも書いてね（テストも書いてくれると嬉しい）
- 書き方が解らなければご相談を
まとめ
- 簡潔さが重要
- ビジネス要件が重要で複雑
- 継続的にテスト
- テスト自体が複雑になる include Serverspec::Helper::DetectOS
serverspec とは
- システムのあるべき状態を簡潔に記述する
おまけ
- WEB+DB Press
- Test-Driven Instructure…2nd Edition
感想
- お話や実際にコードを拝見させて頂いてserverspec がシンプル且つ継続的にテストする為に作られたツールであることが強く感じられた
- ssh だけが開いていれば良いという点が個人的にはとても気に入っている
include Serverspec::Helper::DetectOSの意味が理解出来てよかった- コードが全く書けない自分でも何か書いてみたいなという気持ちにさせてもらった
- あれこれ悩むよりコードを書いてみたいと思う
質問
聞きたかったけど聞かなかった質問達。
（質）contain の返り値はどこまで見ているのか？
- 完全一致？
- 部分一致？
（質）クラスタ構成をテストするようなことを想定されているか？また、今後、サポートすることがあるか？
（質）複数台のサーバーをテストする場合の挙動
- おそらく順番にテストしていくと仮定していますが、実際は？
- パラレルでテストを行う場合、どのような手法がオススメか？
- capistrano を絡ませる
（質）spec ファイルの使い回しについて
- 共通の spec はシンボリックリンクで運用していますが、どう思われますか？
（質）ペパボで実運用してますか？
- 一部で使ってます
