serverspec at hbstudy #45
DESCRIPTION
TRANSCRIPT
serverspechbstudy #452013/06/21
Gosuke Miyashita
自己紹介
宮下 剛輔mizzy.org
@gosukenator
paperboy&co.テクニカル
マネージャー
理学部情報工学科の三年生
学割でGitHub Micro Plan
無料です
Amazon Student入ってます
hbstudy #8Puppet のススメ
サーバプロビジョニン
グ
Cloud or VMImage Launch
OSInstall
SystemConfiguration
Provisioning Toolchain by Lee Thompson at Velocity 2010
Application ServiceOrchestration
Bootstrapping
Configuration
OrchestrationCapistranoFabric
PuppetChef
EC2OpenStack
サーバプロビジョニン
グと
テスト
監視とは継続的なテストである
by @kazuho
Cloud or VMImage Launch
OSInstall
SystemConfiguration
Application ServiceOrchestration
Bootstrapping
Configuration
Orchestration NagiosZabbix
serverspec
???
Zabbix/Nagios による Apache のテスト(監視)
httpd プロセスが動いているか80 番ポートに外からアクセスできるか80 番ポートが正しいレスポンスを
返すか
serverspec による Apache のテスト
httpd プロセスが動いているか80 番ポートを Listen しているかhttpd パッケージが入っているか自動起動するようになっているか設定ファイルが存在するか正しい設定がされているか
Orchestration 領域のテストZabbixNagiosConfiguration 領域のテストserverspec
Configurationと
テスト
みなさんどうやってますか?
シェルコマンド叩く?
シェルスクリプト?実際にサービスに
アクセスする?
ConfigurationManagementFramework
ConfigurationManagement Framework
とテスト
これはテストどうやってますか?
シェルコマンド叩く?
シェルスクリプト?実際にサービスに
アクセスする?
この界隈は様々なテストツールが存在
シンタックスチェックFoodcriticknife cookbook testpuppet-lint
ユニットテストChefspecrspec-puppet
結合テストMinitest Chef HandlerCucumber ChefTest Kitchenrspec-systemserverspec
Infrastructure as Codeからの自然な流れ
これだけテストツールが存在するのにな
ぜわざわざserverspec をつくっ
たのか?
既存ツールは機能が多すぎたり、特定のツールに依存してた
りするのがイヤ
Puppet や Chef使っていてそもそも
serverspec って必要?
そもそもPuppet や Chef に
テストって必要?
一度書いたマニフェストやレシピを更新しないのであればたぶん不
要
マニフェストやレシピを継続的に更新す
るなら必要
プログラムのリファクタリングと一緒
継続的に更新するならテストも継続的に実行する必要がある
なのでテストを自動化することが必要
テストコード自体もメンテナンスが必要
なのでテストコードの読みやすさや
書きやすさも重要
テストツール自体のシンプルさも重要
severspec
サーバのテストを簡潔に書くための仕組
み
サーバのテストをRSpec で記述
RSpec?
Ruby のテストフレームワーク
describe Array, "when 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 == 0 endend
@empty_array.should be_empty@empty_array.should_not
be_empty
serverspec によるテスト
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
最近推奨の書き方expect(file ‘/etc/passwd’).to be_file
非推奨な書き方file(‘/etc/passwd’).should be_file
テストコードが簡単に書けて結果がわかり
やすくても内部が複雑なら意味がない
serverspec は基本的に
シェルコマンド叩いて
チェックしてるだけ
テスト対象のサーバに SSH で接続して
コマンドを叩く
シェルコマンド実行によるサーバのテストをスマートにやれるようにしたのが
serverspec
serverspec の始め方
# yum install rubygems# gem install serverspec rake# serverspec-init# rake spec
デモ
serverspecが産まれた経緯
2007 年
Puppet を導入することにした
Puppet でサーバ構築は自動化できた
じゃあテストはどうしよう?
Assurer という Perl 製のツールを書いた
Assurer は面倒すぎて実用には
耐えなかった
テスト駆動サーバ構築のことは
しばらく忘れた
2013 年
Puppet マニフェストの
リファクタリングをやろうと思った
コードをリファクタリングするならテス
ト必要だろ
rspec-pupet はモジュールのテスト
にしか使えない
Puppet 適用後の実際のサーバの
状態をテストしたい
@hiboma が何かやってたそういえば
http://d.hatena.ne.jp/hiboma/20130513/1368411746
それパクろうそして gem にしよう
serverspec誕生
もう少し詳しいserverspec の話
リソースタイプ
command cron default_gateway file group host ipfilter ipnat
iptables kernel_module linux_kernel_parrameter package
port routing_table selinuxservice user zfs
http://serverspec.org/resource_types.html
複数 OS サポート
DebianGentooRed HatSolarisDarwin
root ユーザじゃない場合は sudo つけて
コマンド実行( SSH の場合のみ
Exec ではつけない)
PATH の追加設定できます
spec/spec_helper.rb で
RSpec.configure do |c| c.path = ‘/sbin:/usr/sbin:$PATH’ …end
describe package(‘serverspec') do let(:path){ ‘/usr/local/rbenv/shims:$PATH’ }
it { should be_installed.by(‘gem’) }end
pre_command
describe package(‘serverspec') do let(:path){ ‘/usr/local/rbenv/shims:$PATH’ } let(:pre_command) { ‘eval “$(rbenv init -)”’ } it { should be_installed.by(‘gem’) }end
サーバ単位じゃなくロール単位でのテス
ト
サーバ固有属性を扱う
詳しくはウェブでhttp://mizzy.org/
http://serverspec.org/
インフラの継続的インテグレーション
プログラム内部の話
describe file(‘/etc/passwd’) do it { should be_file }end
が実行されるとどうなるか( Exec Backend の場合)
この辺が主に呼ばれる
serverspec/type/file.rbserverspec/backend/exec.rbserverspec/commands/redhat.rb
実際にコードを見てみましょう
SSH の場合は?
Backend::Exec の代わりに Backend::Ssh
が呼ばれる
chain する場合は?
describe package('serverspec') do it { should be_installed.by('gem') }end
matchers/be_installed.rb が呼ばれる
serverspec 自身のテスト
テストコードは 2 パターン
コマンドのテストリソースマッチャのテスト
コマンドのテスト
serverspec がテストのために実行するシェルコマンドが正しく生成されるかどうかをチェック
リソースマッチャのテスト
テスト用シェルコマンドが実行されたという「仮定」の元で、リソースのテストが想定通りの結果を返すかどうかをチェック
GitHub でのコントリビュート
1. フォークする2. ブランチをつくる
git checkout –b my-new-feature3. コード書いてコミットしてプッ
シュgit push origin my-new-feature
4. プルリクエストを送る
プルリクエストは日本語で OK途中状態でいったんプルリクしてくれ
ても OKあとからまた push すればいいその場合は頭に [WIP] とつけてくださ
い動作確認は自分が使ってる OS だけで
OK完璧に実装しなくて大丈夫です
テストコードも書いてもらえるとうれしいです書き方わからなければお気軽に相談
を
プルリクエストはお気軽に
まとめ
serverspec は読みやすい書きやすい
わかりやすい
要するに簡潔
簡潔さ超重要
ビジネス要件は絶えず変化する
それに伴いシステムも変化し複雑に
複雑さと変化に対応するためには継続的
なテスト重要
テストコード自体もシステムに伴い変化し複雑になる
なのでできるだけ簡潔に記述できる
ことが重要
serverspec とは
現実のシステムの複雑さと変化に対応するために
システムのあるべき状態を簡潔に記述し継続的にテストする
ためのもの
おまけ
おしまい