オライリーの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 記法は残る

describe packege('nginx') do
  it { should be_installed }
end

3.2 リソースとリソースタイプ

describe packege('nginx') do
  it { should be_installed }
end

リソース : 具体的な個別テストの対象

• 上記の場合 packege('nginx') がテスト対象となるリソース

リソースタイプ : リソースの種類

• 上記の場合 packege('nginx') リソースのリソースタイプは、 packege

ServerspecではSSH経由でテストを実行する場合、デフォルトで sudo をつけている

3.4 テスト対象ホストの追加

serverspec-init で生成される Rakefile では以下のように設定している

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を使うとか