Help us understand the problem. What is going on with this article?

Serverspec本読書メモ 3.5章〜3.12章まで

More than 3 years have passed since last update.


オライリーのServerspec本のどくしょかんそうぶんです

3.5 動作のカスタマイズ

  • Specinfra.configration を利用して、serverspecの動作をカスタマイズできる
  • set メソッドは、Specinfra.configration のシンタックスシュガー

渡せるコマンド

使えるコマンドを解説した公式のドキュメントが見つからない...

  • ssh_options: Net::SSH.start に渡すオプション
  • pre_command: テスト実行前に引数のコマンドを実行
  • env: 環境変数。hash で複数渡せる

    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する時のオプション

    set :sudo_options, '-u foo'
    

3.6 一時的な動作の変更

let: 一時的なset

describe command('whoami') do
  let(:disable_sudo){ true }
  its(:stdout){ should match /foo/ }
end

Rspec の around を使う

spec_helper.rb
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: ハッシュを引数として受け取る

    setproperty { key1: 'value1', key2: 'value2' }
    
  • property: setproperty にて設定した値を受け取る

    property[:key1] # 'value1'
    

サーバ毎の固有の設定を json 書く

spec_helper.rb で読み込ませる技

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のアップデートで想定しない状態になるかどうかを確認する
    • そのために必要なことは何か?
kasei-san
小林の中の人 長文はblogに。QiitaにはちょっとしたTIPSを
http://kasei-san.hatenablog.com/
lclco
業界最大手高速バス料金比較サイト「バス比較なび」やLCCなど飛行機との比較ができる「格安移動」を運営
https://www.lclco.com/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away