オライリーのServerspec本のどくしょかんそうぶんです
1章 Serverspecの紹介
- Serverspec : サーバの状態をRspec記法のコードにより自動的にテストするためのツール
- 利用目的
- TDDによるインフラコード開発
- サーバ構築後の確認作業の自動化
- サーバ監視に使う人も居る → そんな人もいるのか
- サーバのあるべき状態の抽象化
- 本質 : テスト駆動によりインフラコードの開発やリファクタリングを促進する
- 必要性
- TDDで、infrastructure as code を進めるため
- サーバの状態をServerspecが保証することで、リファクタリングがやりやすくなる
- 開発の哲学
- 導入の敷居を下げる
- Ruby1.8.7をサポート → RHEL6系でデフォルトのRubyであるため
- 特定のサーバ管理ツールに依存しない
- 構成管理ツールのライフサイクルより、テストコードのライフサイクルの方が長いであろうという哲学
- 1つのことを上手くやる
- サーバのテストをやるだけ → 複雑で多機能なツールは使われづらい
- 並列実行はRakeに任せている
- 導入の敷居を下げる
- 究極の目標
- システムの継続的改善に寄与すること
2章 はじめてのServerspec
-
serverspec-init
はサンプルコードを生成するだけで、実践向きではない- あくまでサンプル
- Rakefile
- テストの実行に必須ではない
- ただし、Serverspecは1つのプロセスで複数のホストを扱うことを考慮していない
- Rakeを利用してホスト毎にタスクを分ける
- spec_helper.rb
- Rspecと同様に、serverspecの挙動を制御する
3章 Serverspecの本格利用
- あえて
expext
ではなく ワンライナーshould
記法を推奨している- 最も直感的にかけるため
- テストが通ったか、通らなかったか? だけを求めているので自然言語風に記述にこだわりがない
-
should
だけ覚えていれば使えるようにしたい - Rspecの記法のバリエーションの隆盛に振り回されたくない
- わかる
- ちなみにRspec3で非推奨になるのは
Object#should
でワンライナーshould
記法は残る
.rb
describe packege('nginx') do
it { should be_installed }
end
3.2 リソースとリソースタイプ
.rb
describe packege('nginx') do
it { should be_installed }
end
リソース : 具体的な個別テストの対象
- 上記の場合
packege('nginx')
がテスト対象となるリソース
リソースタイプ : リソースの種類
- 上記の場合
packege('nginx')
リソースのリソースタイプは、packege
ServerspecではSSH経由でテストを実行する場合、デフォルトで sudo をつけている
3.4 テスト対象ホストの追加
serverspec-init で生成される Rakefile では以下のように設定している
.rb
namespace :spec do
targets = []
Dir.glob('./spec/*').each do |dir|
next unless File.directory?(dir)
target = File.basename(dir)
target = "_#{target}" if target == "default"
targets << target
end
spec以下のディレクトリ構成はこんな感じ
$tree
.
├── spec_helper.rb
└── #{サーバ名}
└── sample_spec.rb
- なので、テスト対象のホストを増やしたい時は、spec 以下にサーバ名のディレクトリを増やせば良い
- また、Rakefileの当該部分を書き換えることで、別の方法でテスト対象を増やすことも可能
- 例えば AWS の API を叩くとか、consulを使うとか