serverspec at hbstudy #45

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 とは

現実のシステムの複雑さと変化に対応するために

システムのあるべき状態を簡潔に記述し継続的にテストする

ためのもの

おまけ

おしまい