LT駆動開発１４でServerSpecを軽く紹介しました。

1. ServerSpecの
ご紹介
LT駆動勉強会14

2. お約束
・本スライドで出てくる事象はフィクションです。
所属組織その他特定の事象に言及しているわけ
ではないですし、実際にあったわけではないかもし
れません。

3. ServerSpecとは？
ServerSpecとは、サーバの状態をテストするため
のフレームワークです。
ServerSpecは、テスト対象のサーバに対してSSH
ログインしてテストするので、
ServerSpec用に何か特別なエージェントをインス
トールする必要がありません。

4. サーバのテストって？？？
そもそもサーバ構築時、テストしてますか？
・phpinfoが出ればOK？
・DBがつながればOK?
・WordPressが動けばOK?
・プロセスが起動していればOK?

5. そもそもサーバ構築ってどうやってますか？
・コピペ駆動
・手順書（エクセルやWikiとか紙とかテキストとか）
・ChefやAnsibleなど構成管理
・シェルスクリプト（！）
そもそもサーバの要件って決まってます？？
（WordPressが動くサーバ用意して。など）

6. ありがちなミス
● いままで問題なく動いていたのに、再起動したら
SSHもWebもつながらなくなった！！
○ iptablesの保存し忘れ
○ Apacheの自動起動設定もれ

7. ありがちなミス
● 気がついたらDBサーバの時計がズレている。
○ NTPサービス起動忘れ。
手順書に漏れていたり、どこかのサイトをコピペするとやり
がち。
ちなみに、DBサーバの時刻がずれている時、急に時刻を
合わせると、
酷い目に合う可能性があります。
メールサーバも同様。

8. つまり
● サーバの構築は構成管理などで（ある程度）自動
化できるけど、構築したサーバのテストも必要。
● 設定や構成管理のミスはそれ単体のテストでは検
証できない。（ChefSpecをパスしたからと言って
サーバが要求通りの動作をしている訳ではない。）
○ サーバもテスト駆動でやろう。

9. ServerSpecインストール
１：Rubyをインストール
2:gem install serverspec
3:ServerSpecのテストコードを出力したいディレク
トリでserverspec-initを実行。
4:質問に答えると、ひな形が生成される。
Winな人はCygWinでもOK。
サーバ側はSSHさえつながればOK.

10. ServerSpecインストール
５：~/.ssh/configにssh接続情報をセット
Host test.org
HostName example.com
IdentityFile ~/.ssh/example.com.
id_rsa
User webmaster

11. テストコードの例
require 'spec_helper'
describe package('httpd'), :if => os[:family] == 'redhat' do
it { should be_installed }
end
describe port(80) do
it { should be_listening }
end
割と簡潔でわかりやすくかける。
OSの差異はある程度吸収してくれる。

12. テストって言われても・・・
何をテストしていいのか分からない。という場合は、
ServerSpecのサイトにあるリソースを眺めてみて、
何がテストできるのか？から追いかけるのも手で
す。
ServerSpecは既存のサーバに影響を与えないの
で、気になるところや今動いているものが動いている
テストを書いてみる。等から始めると良い。

13. テストすると何がいいの？
・テストコード自体が生きた資料（チェックリスト）に
なる。
・プログラムと違い、サーバのテスト項目はある程
度決まっているので、作ってしまえば、他のサーバ
に流用が効く。
・不具合が起こった時何が問題なのかが分かる。

14. ServerSpecでテストできる範囲
・ServerSpecはSSHでつないで各種コマンドの実行
結果よりチェックを行う。
→サーバ内部からのチェック。
・複数台のサーバと連携しているか？外部からつな
がるか？等外部からのチェックはZabbixなどを使
う。

15. ServerSpecのちょっと残念なところ
・デフォルトではサーバごとにテストを書かないといけ
ない。
→本当は機能や役割ごとにテストを書いて、インストー
ルされた機能毎にテストを組み合わせて適用したい。
→設定いじれば結構柔軟にカスタム出来そうだけど、
rakeやRubyの知識が必要（本家にカスタム例あり）

16. まとめ
・構築手順書やマニュアルの類は所詮メンテされないし、読み
手を選ぶ。
（サーバ建てる毎に手順書やマニュアル作りますか？？）
・構成管理やテストコードなど、インフラをコードで記述すること
により、生きた手順書、チェックリストを作成することができる。
・バージョン管理ができるし、差分チェックもできる。
・自動化できる。他サーバに流用できる。
・テストをすることによりある程度の安心感を得る。

17. 参考サイト
・serverspecを使ってサーバの状態をテストしてみよう
・ServerSpec
・serverspec の論文公開します