オライリーのServerspec本のどくしょかんそうぶんです
3.5 動作のカスタマイズ
-
Specinfra.configration
を利用して、serverspecの動作をカスタマイズできる -
set
メソッドは、Specinfra.configration
のシンタックスシュガー
渡せるコマンド
使えるコマンドを解説した公式のドキュメントが見つからない...
-
ssh_options:
Net::SSH.start
に渡すオプション -
pre_command: テスト実行前に引数のコマンドを実行
-
env: 環境変数。hash で複数渡せる
.rb
set :env, :LANG => 'C', :LC_MESSAGES => 'C'
```
-
path: PATH
-
shell:テストで使用するシェル
-
sudo_path: sudo する時のpath
-
disable_sudo: テスト実行時に sudo しない
-
request_pty: PTYを常に要求
- 標準エラー出力と標準出力が一緒になるので注意
- Execバックエンドの場合も同様
- 1.8.7の互換性のため
-
sudo_options: sudoする時のオプション
.rb
set :sudo_options, '-u foo'
# 3.6 一時的な動作の変更
## **let**: 一時的な`set`
```.rb
describe command('whoami') do
let(:disable_sudo){ true }
its(:stdout){ should match /foo/ }
end
Rspec の around を使う
Rspec.configure do |c|
c.around :each, sudo: false do |example|
set :disable_sudo, true
example.run
set :disable_sudo, false
end
end
sudo: false
のあるExampleでのみ disable_sudo
が有効になる
describe command('whoami'), sudo: false do
let(:disable_sudo){ true }
its(:stdout){ should match /foo/ }
end
3.7 specファイルを複数のホストで共有
-
Rakefileで使用するspecを制御できるのでやりようは自由
-
こんなふうなやり方もあるよという提案
-
ロール毎にまとめる
- 共通のテスト、dbサーバ、appサーバ用のテストをそれぞれ用意
- Rake でサーバ名毎に、どのテストを実行するかを決める
-
モジュール毎にまとめる
- chef なら cookbook単位
- 各 cookbookにspecディレクトリを用意
- それを読む
- サーパ構成管理ツールを乗り換える時に大変
- attributeとかを多用しているとできなさそう
-
この辺はプロジェクトに応じていろいろやりようがある気がする
3.8 ホスト固有情報の利用
-
setproperty: ハッシュを引数として受け取る
.rb
setproperty { key1: 'value1', key2: 'value2' }
- **property**: `setproperty` にて設定した値を受け取る
```.rb
property[:key1] # 'value1'
サーバ毎の固有の設定を json 書く
spec_helper.rb で読み込ませる技
set_property JSON.perse(File.read('properties.json'))[ENV['TARGET_HOST']]
3.8 もそうだけれども、やりようは色々あるから、自由にやってね! というスタンスを感じる
3.9 任意コマンドの実行
テスト実行前に任意のコマンドを実行したい場合
-
Specinfra::Runner
に色々なコマンド実行用メソッドがある- Q: 使えるメソッドの一覧どこ
-
Specinfra::Runner.run_command
で任意のコマンドを実行 -
Specinfra::CommandResult
オブジェクトが返るsuccess?
failure?
stdout
stderr
exit_status
3.12 テストコード実装の指針
- 新規システム
- 最初は書かずに、ある程度固まった所で書く
- 寿命が短いシステムはわざわざテストしなくても良い
- リファクタリングのためにテストは必要
- 既存システム
- テストがない場合、今後も長く使うのであれば書く
- システムは変わるもの。変えるときにテストがあると安心
- 構成管理ツールがある場合
- そのモジュールやcookbookが何をするものかを明示するため
-
構成管理ツールは信用する。インフラコードを書く人間を信用しない
- ツールの設定をする人が間違えたり、勝手に(別の所で)バージョンが変わっていないことを保証する
- どこまでテストするか?
- サーバのとしての役割が必須な所まで
- 設定ファイルの詳細まで追うのは苦労の割に実入りが少ない
-
設定そのものよりも、設定によってもたらされる振る舞いをテストすべき
- それは serverspec 外の仕事 → 例: Infratester
- セキュリティ上重要な部分
-
インフラコードの変更、パッケージ/OSのアップデートで想定しない状態になるかどうかを確認する
- そのために必要なことは何か?