Server specのご紹介

Transcript

• 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 exsample.com IdentityFile ~/.ssh/exsample.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 の論文公開します