hbstudy#45-serverspecが開いたServerテストの世界-
2013年6月21日(金) 19:00 - 21:30
株式会社ハートビーツ
ハロー会議室 新宿 C+D(東京都新宿区西新宿1丁目5-11 新宿三葉ビル6F)
http://connpass.com/event/2580/
http://www.slideshare.net/mizzy/serverspec-hbstudy45
昨今のベンチャー企業やクラウドサービス利用者の中では、 "Infrastructure as code"や"DevOps"などと呼ばれる、 下回りの構築・設定・テスト自動化やオペレーションと開発の融合が注目されている。
serverspecはサーバの設定・状態を確認（テスト）するための自動試験ツールとして、 Twitterをはじめ、Webの世界で最近話題に上がっている新しいツールである。
serverspecはRubyで実装され、Rubyのテストフレームワークを用いて、 "パッケージがインストールされているか"、"ポートが開いているか"など、 サーバの各種設定の確認を自動的に行う。
serverspecを用いた設定確認が自動化されることで、 構築や設定変更に対しての確認のコストが低くなるために、 継続的なインフラの構築や・設定変更が可能になるとされていた。
紹介やデモを見る限り使いやすいツールになっていると感じたため、 大量のサーバを抱え構築・確認を継続的に行っていく会社では、 こうした自動試験ツールを用いることで確認漏れの解消や、 確認にかかる人員削減によるコストカットができる有用なツールであると感じた。
氏名：宮下剛介
所属：株式会社paperboy&co.（レンタルサーバ「ロリポップ！」の会社）
備考：serverspecの開発者(過去にhbstudy#8 「Puppetのススメ」でも講演)
Velocity 2010で語られたProvisioning Toolchainの資料を見ると、プロビジョニングの領域は以下の3つに分けられる 資料：http://www.slideshare.net/dev2ops/velocity-online-provisioningtoolchainkey
領域 - Provisioning Tool
- Orchestration（AP層） - Capistrano/Fabric
- Configuration (システムの設定) - Puppet/Chef
- Bootstrapping (OSインストール/VM操作) - EC2/OpenStack
「監視とは継続的なテストである」 by @kazuho
領域 - Provisioning Test Tool
-
Orchestration（AP層） - Nagios/Zabbix
-
Configuration (システムの設定) - Serverspec
-
Bootstrapping (OSインストール/VM操作) - ???
-
Zabbix/NagiosによるApacheのテスト
- httpdプロセスが動いているか
- 80番ポートで動いているか
- 80番ポートが正しいレスポンスを返すか
-
ServerspecによるApacheのテスト
- httpdプロセスが動いているか
- 80番ポートがListenしているか
- httpdパッケージが入っているか
-
以下Nagios/Zabbixでやらないテスト
- 自動起動するようになっているか
- 設定ファイルが存在するか
- 正しい設定がされているか
Nagios/ZabbixがあればServerspecはいらないのではとよく言われるが、テスト対象が違っているので不要とは言い切れない。 また、設定を確認するためだけにZabbixやNagiosを構築するのは大げさで大変。
以前まではシェルスクリプトやコンソールを叩いたり実際にアクセスして確認？
- Configuration Management Framework
- Puppet/Chefの登場
PuppetやChefをProvisioning Toolという人も多いが、Provisioningという意味は先のProvisioning Toolchainの図を見てもわかるように範囲が広い。 PuppetやChefはConfiguration Management Frameworkと名乗っている
Puppetを使っているのであれば、マニフェスト（自動化手順）を作って1回確認出来ればあとはPuppet任せでも可能
- シンタックスチェック
- Foodcritic
- knife cookbook test
- puppet-lint
- ユニットテスト
- Chefspec
- rspec-puppet
ChefやPuppetのテストが必要かといわれると疑問
-
× 単純な自動化手順の場合設定と確認内容が変わらないので手間になる
-
○ 複雑な設定をされたOSが複数あったりパラメータが違う場合は効果的
-
結合テスト
- Minitest Chef Handler
- Cucumber Chef
- Test Kitchen
- rspec-system
- serverspec
テストツールが多く出回っているのはInfrastructure as codeからの自然な流れ。
- 既存のツールは機能が多すぎる
- ツールの問題かテストの問題かがわからなくなるのを避けるためにもツール(serverspec)事体は簡単なものにした
- ツール(Puppet/Chef)に依存しないほうがいい
- ツールを変更することは稀かもしれないが、特定のツールに依存するのは避けたかった
- 一度書いた自動化手順を更新しないのであれば多分不要でツールに任せる
- マニフェストやレシピを継続的に更新するなら必要
- プログラムのリファクタリングと同様にテストを自動化することが必要
-
- 継続的に更新するのであればテストも継続的に実行する必要がある
-
- 自動化されていないものを継続的に実行するのは難しい * テストコードもメンテナンスが必要なのでテストコードの読み/書きやすさも重要 * テストツール自体のシンプルさも重要
serverのテストを簡潔書くための仕組み
-> サーバのテストをRSpecで書く
Rubyのテストフレームワーク
describe Array, "wehn empty" do
before do
@empty_array = []
end
it "should be empty" do
@empty_array.should be_empty
end
it "should size 0" do
@empty_array.size.should eq 0
end
end
describe package('httpd') do
it { should be_installed }
end
describe service('httpd') do
it { should be_enabled }
it { should be_running }
end
describe port("80") do
it { should be_listening }
end
- serverspecは裏側でシェルコマンドを叩いてチェックしているだけ
- やり方は2種類->ローカルとリモート
- リモートはテスト対象のサーバにSSHで接続してコマンドを叩く
- リモート先にRubyが入ってなくても動く
シェルコマンドを叩くテストをもう少しスマートにしたのがserverspec
2007年
- Puppetを導入
- テストのためにAssurerというツールを開発
- Assurerは面倒すぎて実用に耐えなかった
2013年
- Puppetのマニフェストのリファクタリングをしよう
- リファクタリングにテストが必要
- rspec-puppetに機能が足りない
- Puppet適用後のサーバの状態をテストしたい
- serverspec開発
対応するリソース(http://serverspec.org/resource_types.html)
- command
- cron
- default_gateway
- file
- port
- routing
- ...etc
複数のOSサポート
- Debian
- Gentoo
- Red Hat
- Solaris
- Darwin
その他の機能
- rootユーザでない場合はsudoをつけてコマンド実行
- PATHの追加設定可能
- コマンド実行前の設定も可能
- サーバ単位ではなくロール単位でのテスト
- サーバ固有の属性を扱うことが可能
serverspecを用いることでインフラの継続的インテグレーションが可能になる
デモと実装解説については割愛（詳細は資料で）