serverspechbstudy #452013/06/21Gosuke Miyashita
自己紹介
宮下 剛輔mizzy.org@gosukenator
paperboy&co.テクニカルマネージャー
理学部情報工学科の三年生
学割でGitHub Micro Plan無料です
Amazon Student入ってます
hbstudy #8Puppetのススメ
サーバプロビジョニング
Cloud or VMImageLaunchOSInstallSystemConfigurationProvisioning Toolchain by Lee Thompson at Velocity 2010Application Servi...
サーバプロビジョニングとテスト
監視とは継続的なテストであるby @kazuho
Cloud or VMImageLaunchOSInstallSystemConfigurationApplication ServiceOrchestrationBootstrappingConfigurationOrchestrationN...
Zabbix/NagiosによるApacheのテスト(監視)httpdプロセスが動いているか80番ポートに外からアクセスできるか80番ポートが正しいレスポンスを返すか
serverspecによるApacheのテストhttpdプロセスが動いているか80番ポートをListenしているかhttpdパッケージが入っているか自動起動するようになっているか設定ファイルが存在するか正しい設定がされているか
Orchestration領域のテストZabbixNagiosConfiguration領域のテストserverspec
Configurationとテスト
みなさんどうやってますか?
シェルコマンド叩く?シェルスクリプト?実際にサービスにアクセスする?
ConfigurationManagementFramework
ConfigurationManagement Frameworkとテスト
これはテストどうやってますか?
シェルコマンド叩く?シェルスクリプト?実際にサービスにアクセスする?
この界隈は様々なテストツールが存在
シンタックスチェックFoodcriticknife cookbook testpuppet-lint
ユニットテストChefspecrspec-puppet
結合テストMinitest Chef HandlerCucumber ChefTest Kitchenrspec-systemserverspec
Infrastructure as Codeからの自然な流れ
これだけテストツールが存在するのになぜわざわざserverspecをつくったのか?
既存ツールは機能が多すぎたり、特定のツールに依存してたりするのがイヤ
PuppetやChef使っていてそもそもserverspecって必要?
そもそもPuppetやChefにテストって必要?
一度書いたマニフェストやレシピを更新しないのであればたぶん不要
マニフェストやレシピを継続的に更新するなら必要
プログラムのリファクタリングと一緒
継続的に更新するならテストも継続的に実行する必要がある
なのでテストを自動化することが必要
テストコード自体もメンテナンスが必要
なのでテストコードの読みやすさや書きやすさも重要
テストツール自体のシンプルさも重要
severspec
サーバのテストを簡潔に書くための仕組み
サーバのテストをRSpecで記述
RSpec?
Rubyのテストフレームワーク
describe Array, "when empty" dobefore do@empty_array = []endit "should be empty" do@empty_array.should be_emptyendit "shou...
@empty_array.should be_empty@empty_array.should_not be_empty
serverspecによるテスト
describe package(httpd) doit { should be_installed }enddescribe service(httpd) doit { should be_enabled }it { should be_ru...
最近推奨の書き方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_gatewayfile group host ipfilter ipnatiptables kernel_modulelinux_kernel_parrameter packageport routin...
複数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) dolet(:path){‘/usr/local/rbenv/shims:$PATH’}it { should be_installed.by(‘gem’) }end
pre_command
describe package(‘serverspec) dolet(:path){‘/usr/local/rbenv/shims:$PATH’}let(:pre_command) {‘eval ‚$(rbenv init -)‛’}it {...
サーバ単位じゃなくロール単位でのテスト
サーバ固有属性を扱う
詳しくはウェブでhttp://mizzy.org/http://serverspec.org/
インフラの継続的インテグレーション
プログラム内部の話
describe file(‘/etc/passwd’) doit { 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) doit { should be_installed.by(gem) }endmatchers/be_installed.rb が呼ばれる
serverspec自身のテスト
テストコードは2パターンコマンドのテストリソースマッチャのテスト
コマンドのテストserverspecがテストのために実行するシェルコマンドが正しく生成されるかどうかをチェック
リソースマッチャのテストテスト用シェルコマンドが実行されたという「仮定」の元で、リソースのテストが想定通りの結果
GitHub でのコントリビュート1. フォークする2. ブランチをつくるgit checkout –b my-new-feature3. コード書いてコミットしてプッシュgit push origin my-new-feature4. プルリ...
プルリクエストは日本語でOK途中状態でいったんプルリクしてくれてもOKあとからまたpushすればいいその場合は頭に[WIP]とつけてください動作確認は自分が使ってるOSだけでOK完璧に実装しなくて大丈夫ですテストコードも書いてもら...
プルリクエストはお気軽に
まとめ
serverspecは読みやすい書きやすいわかりやすい
要するに簡潔
簡潔さ超重要
ビジネス要件は絶えず変化する
それに伴いシステムも変化し複雑に
複雑さと変化に対応するためには継続的なテスト重要
テストコード自体もシステムに伴い変化し複雑になる
なのでできるだけ簡潔に記述できることが重要
serverspecとは
現実のシステムの複雑さと変化に対応するために
システムのあるべき状態を簡潔に記述し継続的にテストするためのもの
おまけ
おしまい
Serverspec at hbstudy #45
Serverspec at hbstudy #45
Serverspec at hbstudy #45
Serverspec at hbstudy #45
Serverspec at hbstudy #45
Serverspec at hbstudy #45
Serverspec at hbstudy #45
Serverspec at hbstudy #45
Serverspec at hbstudy #45
Serverspec at hbstudy #45
Serverspec at hbstudy #45
Serverspec at hbstudy #45
Serverspec at hbstudy #45
Serverspec at hbstudy #45
Upcoming SlideShare
Loading in...5
×

Serverspec at hbstudy #45

9,700

Published on

Published in: Technology
0 Comments
62 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
9,700
On Slideshare
0
From Embeds
0
Number of Embeds
15
Actions
Shares
0
Downloads
93
Comments
0
Likes
62
Embeds 0
No embeds

No notes for slide

Serverspec at hbstudy #45

  1. 1. serverspechbstudy #452013/06/21Gosuke Miyashita
  2. 2. 自己紹介
  3. 3. 宮下 剛輔mizzy.org@gosukenator
  4. 4. paperboy&co.テクニカルマネージャー
  5. 5. 理学部情報工学科の三年生
  6. 6. 学割でGitHub Micro Plan無料です
  7. 7. Amazon Student入ってます
  8. 8. hbstudy #8Puppetのススメ
  9. 9. サーバプロビジョニング
  10. 10. Cloud or VMImageLaunchOSInstallSystemConfigurationProvisioning Toolchain by Lee Thompson at Velocity 2010Application ServiceOrchestrationBootstrappingConfigurationOrchestrationCapistranoFabricPuppetChefEC2OpenStack
  11. 11. サーバプロビジョニングとテスト
  12. 12. 監視とは継続的なテストであるby @kazuho
  13. 13. Cloud or VMImageLaunchOSInstallSystemConfigurationApplication ServiceOrchestrationBootstrappingConfigurationOrchestrationNagiosZabbixserverspec???
  14. 14. Zabbix/NagiosによるApacheのテスト(監視)httpdプロセスが動いているか80番ポートに外からアクセスできるか80番ポートが正しいレスポンスを返すか
  15. 15. serverspecによるApacheのテストhttpdプロセスが動いているか80番ポートをListenしているかhttpdパッケージが入っているか自動起動するようになっているか設定ファイルが存在するか正しい設定がされているか
  16. 16. Orchestration領域のテストZabbixNagiosConfiguration領域のテストserverspec
  17. 17. Configurationとテスト
  18. 18. みなさんどうやってますか?
  19. 19. シェルコマンド叩く?シェルスクリプト?実際にサービスにアクセスする?
  20. 20. ConfigurationManagementFramework
  21. 21. ConfigurationManagement Frameworkとテスト
  22. 22. これはテストどうやってますか?
  23. 23. シェルコマンド叩く?シェルスクリプト?実際にサービスにアクセスする?
  24. 24. この界隈は様々なテストツールが存在
  25. 25. シンタックスチェックFoodcriticknife cookbook testpuppet-lint
  26. 26. ユニットテストChefspecrspec-puppet
  27. 27. 結合テストMinitest Chef HandlerCucumber ChefTest Kitchenrspec-systemserverspec
  28. 28. Infrastructure as Codeからの自然な流れ
  29. 29. これだけテストツールが存在するのになぜわざわざserverspecをつくったのか?
  30. 30. 既存ツールは機能が多すぎたり、特定のツールに依存してたりするのがイヤ
  31. 31. PuppetやChef使っていてそもそもserverspecって必要?
  32. 32. そもそもPuppetやChefにテストって必要?
  33. 33. 一度書いたマニフェストやレシピを更新しないのであればたぶん不要
  34. 34. マニフェストやレシピを継続的に更新するなら必要
  35. 35. プログラムのリファクタリングと一緒
  36. 36. 継続的に更新するならテストも継続的に実行する必要がある
  37. 37. なのでテストを自動化することが必要
  38. 38. テストコード自体もメンテナンスが必要
  39. 39. なのでテストコードの読みやすさや書きやすさも重要
  40. 40. テストツール自体のシンプルさも重要
  41. 41. severspec
  42. 42. サーバのテストを簡潔に書くための仕組み
  43. 43. サーバのテストをRSpecで記述
  44. 44. RSpec?
  45. 45. Rubyのテストフレームワーク
  46. 46. describe Array, "when empty" dobefore do@empty_array = []endit "should be empty" do@empty_array.should be_emptyendit "should size 0" do@empty_array.size.should == 0endend
  47. 47. @empty_array.should be_empty@empty_array.should_not be_empty
  48. 48. serverspecによるテスト
  49. 49. describe package(httpd) doit { should be_installed }enddescribe service(httpd) doit { should be_enabled }it { should be_running }enddescribe port(80) doit { should be_listening }end
  50. 50. 最近推奨の書き方expect(file ‘/etc/passwd’).to be_file非推奨な書き方file(‘/etc/passwd’).should be_file
  51. 51. テストコードが簡単に書けて結果がわかりやすくても内部が複雑なら意味がない
  52. 52. serverspecは基本的にシェルコマンド叩いてチェックしてるだけ
  53. 53. テスト対象のサーバにSSHで接続してコマンドを叩く
  54. 54. シェルコマンド実行によるサーバのテストをスマートにやれるようにしたのがserverspec
  55. 55. serverspecの始め方
  56. 56. # yum install rubygems# gem install serverspec rake# serverspec-init# rake spec
  57. 57. デモ
  58. 58. serverspecが産まれた経緯
  59. 59. 2007年
  60. 60. Puppetを導入することにした
  61. 61. Puppetでサーバ構築は自動化できた
  62. 62. じゃあテストはどうしよう?
  63. 63. AssurerというPerl製のツールを書いた
  64. 64. Assurerは面倒すぎて実用には耐えなかった
  65. 65. テスト駆動サーバ構築のことはしばらく忘れた
  66. 66. 2013年
  67. 67. Puppetマニフェストのリファクタリングをやろうと思った
  68. 68. コードをリファクタリングするならテスト必要だろ
  69. 69. rspec-pupetはモジュールのテストにしか使えない
  70. 70. Puppet適用後の実際のサーバの状態をテストしたい
  71. 71. @hibomaが何かやってたそういえばhttp://d.hatena.ne.jp/hiboma/20130513/1368411746
  72. 72. それパクろうそしてgemにしよう
  73. 73. serverspec誕生
  74. 74. もう少し詳しいserverspecの話
  75. 75. リソースタイプ
  76. 76. command cron default_gatewayfile group host ipfilter ipnatiptables kernel_modulelinux_kernel_parrameter packageport routing_table selinuxservice user zfshttp://serverspec.org/resource_types.html
  77. 77. 複数OSサポート
  78. 78. DebianGentooRed HatSolarisDarwin
  79. 79. rootユーザじゃない場合はsudoつけてコマンド実行(SSHの場合のみExec ではつけない)
  80. 80. PATHの追加設定できます
  81. 81. spec/spec_helper.rb でRSpec.configure do |c|c.path = ‘/sbin:/usr/sbin:$PATH’…end
  82. 82. describe package(‘serverspec) dolet(:path){‘/usr/local/rbenv/shims:$PATH’}it { should be_installed.by(‘gem’) }end
  83. 83. pre_command
  84. 84. describe package(‘serverspec) dolet(:path){‘/usr/local/rbenv/shims:$PATH’}let(:pre_command) {‘eval ‚$(rbenv init -)‛’}it { should be_installed.by(‘gem’) }end
  85. 85. サーバ単位じゃなくロール単位でのテスト
  86. 86. サーバ固有属性を扱う
  87. 87. 詳しくはウェブでhttp://mizzy.org/http://serverspec.org/
  88. 88. インフラの継続的インテグレーション
  89. 89. プログラム内部の話
  90. 90. describe file(‘/etc/passwd’) doit { should be_file }endが実行されるとどうなるか(Exec Backend の場合)
  91. 91. この辺が主に呼ばれるserverspec/type/file.rbserverspec/backend/exec.rbserverspec/commands/redhat.rb実際にコードを見てみましょう
  92. 92. SSH の場合は?Backend::Exec の代わりに Backend::Sshが呼ばれる
  93. 93. chain する場合は?describe package(serverspec) doit { should be_installed.by(gem) }endmatchers/be_installed.rb が呼ばれる
  94. 94. serverspec自身のテスト
  95. 95. テストコードは2パターンコマンドのテストリソースマッチャのテスト
  96. 96. コマンドのテストserverspecがテストのために実行するシェルコマンドが正しく生成されるかどうかをチェック
  97. 97. リソースマッチャのテストテスト用シェルコマンドが実行されたという「仮定」の元で、リソースのテストが想定通りの結果
  98. 98. GitHub でのコントリビュート1. フォークする2. ブランチをつくるgit checkout –b my-new-feature3. コード書いてコミットしてプッシュgit push origin my-new-feature4. プルリクエストを送る
  99. 99. プルリクエストは日本語でOK途中状態でいったんプルリクしてくれてもOKあとからまたpushすればいいその場合は頭に[WIP]とつけてください動作確認は自分が使ってるOSだけでOK完璧に実装しなくて大丈夫ですテストコードも書いてもらえるとうれしいです書き方わからなければお気軽に相談を
  100. 100. プルリクエストはお気軽に
  101. 101. まとめ
  102. 102. serverspecは読みやすい書きやすいわかりやすい
  103. 103. 要するに簡潔
  104. 104. 簡潔さ超重要
  105. 105. ビジネス要件は絶えず変化する
  106. 106. それに伴いシステムも変化し複雑に
  107. 107. 複雑さと変化に対応するためには継続的なテスト重要
  108. 108. テストコード自体もシステムに伴い変化し複雑になる
  109. 109. なのでできるだけ簡潔に記述できることが重要
  110. 110. serverspecとは
  111. 111. 現実のシステムの複雑さと変化に対応するために
  112. 112. システムのあるべき状態を簡潔に記述し継続的にテストするためのもの
  113. 113. おまけ
  114. 114. おしまい
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×