Serverspec

サーバ設定のテストを Rspec で書く Serverspec を勉強する。

===

参考

• 「Serverspec」を使ってサーバー環境を自動テストしよう: さくらのナレッジに綺麗にまとまっている
• serverspecのリソースタイプ・マッチャー: メモ的に色々なテストを書いてくれている
• Serverspec書き方メモ: 超短文
• Serverspecの判定にサーバ内のコマンドの実行結果を使いたい: コマンド実行結果を判定に使うことだけをメモしている

メモ

わかったこと

わかった事的な

• spec file の中身

describe <resource_type>(<target>) do
  <test_condition>
  ...
  ...
end

• resource_typeの例: parckage, service, port
• test_condition の書き方
  • it { should <condition> }
  • its(<target>) { should <condition> <value> }

疑問

まずは触る前に

なんとなくわかったけど動作確認必要

• 遠隔のサーバに対してもテストできるか？遠隔サーバ側に必要なものは？
  • linuxならssh出来ること, sudo権限があること, で十分らしい. windowsならRMほげほげというのがあってログインできること. 要はserverspecを遠隔に入れておく必要が無いということらしい. -> コード読んで確認したい

わかっていないこと

• 「ポートが空いていること」って誰からどのinterface,ipaddrを見るかで変わってくるけどそこまで細かく (統一的に簡単に) 出来るか？
  • Infrataster というのではできそう。 (参考)
• 監視ツールとどう違う？どう使い分ける？
  • Serverspec 良いこと
    • ruby アプリケーションと同様にサーバ構成管理を行える
    • agent-less
    • 深いテストができる: portやprocessが上がっているかとかだけじゃなく, インストールされているパッケージやプログラム, cronのエントリ, コマンド実行結果, などが簡単にテストできる
    • Pythonの類似インフラ環境のテストツール: Testinfra
  • 監視ツール(Icinga,Nagiosなど) 良いこと
    • NW疎通性がなくなったら, 要はHOST監視が落ちたら Service,Process 監視も落としてくれる
    • 通知が充実: mail, slack, etc.
    • statusが充実: up, down, flap, acknowledged up, acknowledged down
• そもそもテストツールは監視ツールとして使ってはいけないのかなぁ？ この辺は使ってみないとなんともかなぁ。開発後にリリースに当たってのチェック, Quality Assuarance として使うような感じ？