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

6章 : トラブルシューティングとデバッグ

6.1 Pryによるトラブルシューティングとデバッグ

pryでテスト対象サーバ上でserverspecのメソッドを実行する方法

$ TARGET_HOST=#{ホスト名} pry

require 'rspec'
require './spec/spec_helper'

os # => {:family=>"ubuntu...}

6.2 テストが失敗した場合

• エラーメッセージに表示されているコマンドを実行してみる
• 標準出力/標準エラー出力を確認

6.3 例外が発生した場合

• エラーメッセージを見ようね
• テスト対象を絞り込む
• 途中に binding.pry を入れて変数の中身とかを確認する
• SSH実行時のトラブルは、 spec_helper.rb の設定を確認してね
• sudo実行時のトラブル
  • PTY割当を確認する → PTYってなんぞ?
  • serverspec側で、 set :request_pry とエラーメッセージを出してくれるのでそれに従う
  • ただし、上記のエラーは、 you must have a tty to run sudo という標準エラー出力を match して引っ掛けているらしいので、メッセージが日本語だとうまくいかなかったりするので注意
• 環境変数でハマることも多いので、pryで同じ環境変数を用意したりして、確認してみてね!

7章 : Serverspecの今後

• 今後大きく変えることは考えていない
• PowerAssertに一部対応中
  • 単純なアサーション(マッチャ)でも、テスト失敗時の情報がしっかり出力されれば十分という思想
  • Rspecみたいな、本来やりたいことに対して記法のバリエーションが多すぎることに対してのアンチテーゼ
• Dockerがあれば構成管理ツールは不要? という考え
  • Dockerfileでイメージを管理
  • 単機能コンテナならばテストは不要?
  • Dockerfileはシンプルだけど、その分抽象度が低く複雑
  • まだテストは必要と思っている

付録A: Resourcesリファレンス

• command

  • stdout, stderr, exit_status

    describe command('ls /foo') do
      its(:stderr) { should match /No such file or directory/ }
    end
    

• cron

  describe cron do
    it{ should have_entry '* * * * * /user/local/bin/foo' }
  end
  

• default_gateway

  describe default_gateway do
    its(:ipadress) { should eq '192.168.0.1' }
    its(:interface) { should eq 'br0' }
  end
  

• file

  • content
    • ファイルに含まれている文字列を確認

• host

  • be_resolvable : 名前解決できるか?
  • be_reachable : 対象のホストに ICMP, TCP, UDP で到達できるか?

• interface

  • speed, have_ipv4_address

• iptables

  • have_rule

• package

  • be_installed

• port

  • be_listening

• selinux

  • be_disabled,be_enforceing,be_permissive

• service

  • be_enabled,be_installed,be_running,be_monited_by,have_start_mode

• yumrepo

  • exist, be_enabled