serverspecの勉強会にいってきた（#hbstudy)
こんばんわ。smallpalaceです。
タイトルどおりいってきたのでメモります。
serverspecの勉強会の記録
#hbstudy 45
発表：mizzyさん（serverspecの作者）
スライド:
http://www.slideshare.net/mizzy/serverspec-hbstudy45
zabbix,nagiosがあればserverspecいらないのでは？という疑問に対して
serverspecによるテストのほうが細かい
zabbix、nagiosは代替にならない。
Orchestation領域のテストがzabbixとか
configuration領域のテストがserverspec
provisioningのなかのconfigutation領域のテスト
みなさんテストどうやってますか？
serverspec登場以前のテストは？－＞シェルスクリプトやブラウザでのサービス確認など
configuration management frameworkとテスト
について
provisioningだとデプロイも含めた広いいみでconfiguration managementより広い
シンタックスチェック
foodcritic
knife cookbook test
puppet-list
chefspec
rspec-puppet
適用するまえの段階までのテスト
複雑なものであれば結構有効
Minitest chef handler ＋定番といわれてる
Cucumber chef
test ketchen Opscodeがつくったやつ ＋定番といわれてる
rspec-system パペットラボ製
テストのコード化は
Infrastructure as Code
からの自然な流れ
なぜわざわざserverspecをつくったのか
既存のツールは機能が多すぎる、特定のツールに依存してたりするのが嫌
VMをつくるのはテストの本質ではない
puppetやchefつかっていてそもそもserverspecって必要なのか
→一度書いたマニフェストやレシピを更新しないのであればたぶん不要
マニフェストやレシピを継続的に更新するなら必要
プログラムのリファクタリングと一緒
継続的に更新してくならテストも継続的に
なのでテストを自動化することが必要
テストコード自体もメンテナンスが必要
テストコードの読みやすさ必要
テストツール自体のシンプルさも重要
それらを意識して作ったのがserverspec
ここから本題
serverspecとは
サーバのテストを簡潔に書くしくみ
サーバのテストをRSpecで記述
こんなかんじ
descrive package service('httpd') do
it {should be_installed }
end
最近推奨のかきかた
expect(file '/etc/passwd').to be_file
expectのときはshouldつけないのが推奨らしい
テストコードが簡単にかけて確認できることが重要
裏側ではシェルスクリプトたたいてチェックしてるだけ
テスト対象のサーバにsshしてコマンドたたくかローカルでテストする
テスト対象サーバにはrubyはいってなくても大丈夫。
シェルコマンドでのテストをもう少しスマートにやれるようにしたのがserverspec
入れ方
yum install rubygems
gem install serverspec rake
serverspec-init
sshでテストするかローカルか選ぶ
vagrantのインスタンスかどうか鍵を読み込める
ホスト名をしていする
OS自動はんべつ
.ssh_configをよんでユーザ判別なければカレントユーザ
必要に応じ書き換えることが可能
spec_helper.rbというファイルで設定を指定する
.rspecというファイルで設定を指定できる、文字に色をつけたりなど
コマンドが出したしゅつりょくも出すのでこけてる理由がわかりやすい
rake spec
成功してると緑もじ、失敗してると赤い文字
テストかいてテストをとおるようにコードをかいてく
テスト駆動開発というやつとおなじ
serverspecが生まれた経緯
Assurerのコンセプトはいいけど面倒すぎて実用には耐えなかった
rspec-puppetはモジュールのテストにしか使えない
モジュール化されていないとだめ
リファクタリングするまえにテストかかないといけないけどそれでは目的がはたせない
Puppet適用後の実際のサーバの状態をテストしたい
@hibomaが何かやってたそういえば（linuxコンテナでのテストのはなし）
それをパクろうそしてgemにしよう
ということで生まれたのがserverspec
シンプルなのですぐできたが最初はsshしないしredhatだけだた
もう少し詳しい中身の話
リソースタイプ
commandとかcronとかdefaultgatewayとか
マニュアルにてせつめい
matcherがないのでも任意にコマンドたたいて戻り地をみたりもできる
ssh越しだとstdoutとstderrがまざったりしてしまうのが悩みどころ
http://serverspec.org/resource_types.html
対応してるのは
Debian、Gentoo、Redhat、Solaris、Darwin
sshでrootでないときはsudoつけてコマンド実行してる
sshの設定
opensshのControlMasterオプションとControlPersistなどがいいらしい
（何回もつなぎに行くコスト削減）ただsercerspecはつなぎっぱなしらしいので必要なさそう
同じコマンド名であってもディストリビューションによってパスが違うとかあるので、
ヘルパーのなかで指定できるようにしている
テストのなかにもパスをかくことが可能
pre_commandを渡せるようにしてる
&&でつなげてからcommandを実行するようにしてる
将来かわるかも
サーバごとにディレクトリをほってテスト書いてくみたいな。
ほんとうはロール単位がいいな
サーバ固有属性を扱う
詳しくはウェブで、
http://mizzy.orgとか公式でものせてます
早速並列処理のことが書かれてました。
http://mizzy.org/blog/2013/06/22/1/
インフラの継続的インテグレーション
CIはjenkinsがメジャーだけどukigumoつかってる
自分がいじったものが全体からみたときに壊してないか確認するために
CIテストしてる
プログラム内部の突っ込んだ話
serverspecのコントリビューターを増やしたいそうです
書いたテスト実際なにが実行されるかの解説
実際よばれるファイルtype/file.rb,backend/exec.rb,command/redhat.rb
baseクラスはLinuxだったらだいたい動くコマンド
たどるところがおおい
sshの場合はBackend::ExecのかわりにBackend::Sshがよばれる。Execを継承しててruncommandのとこだけｓｓｈする処理
chainする場合には？
ちょっとややこしいテストをしたい場合はメソッドを定義するテストがある
コマンドの戻り値が0であるのを確認するような場合は大丈夫
コマンド一発ですまない場合は書いてあげるひつようがある
テストコードは2つのパターンがある
コマンドのテスト
リソースマッチャのテスト
GitHub上でコントリビュート
１．フォークする
２．ブランチつくる
３．コード書いて
４．プルリクエストする
プルリクは日本語で大丈夫。
気になることはご相談を
動作確認は自分のつかってるOSだけで大丈夫
テストコードも書いてくれるとうれしいな
まとめ
serverspecとは
よみやすい、かきやすい、わかりやすい、
かんけつさ超重要
ビジネスの変化にともない
システムも変化して複雑になってくる
そのために継続的にテストしてくのが大切
なのでなるべく簡潔に記述できるのが重要
システムのあるべき状態を継続的にテストするために簡潔に記述できるもの
podcastもやるよ
http://podcast.bulknews.net/post/53587224871/ep14-docker-naoya-mizzy
WEB+DBの75にserverspecのことでてくるっす（予約済みです）
Test-DrivenInfrastructure
以上。
はやくつかいこなしたいです。
みていただいてどうもありがとうございました。
よい週末を。
