テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-

1. テスト駆動インフラ構築～Chefとserverspecを使ったインフラ構築自動化のすすめ～ TIS株式会社戦略技術センター秋穂賢 2014/7/15(Tue) @ 西新宿Tech-Circle#2 「DevOps勉強会」

2. TIS株式会社戦略技術センター所属自己紹介秋穂賢（あきほすぐる）名前 Zabbix, OTRS, JobScheduler, Chefなど仕事 http://www.atmarkit.co.jp/ait/articles/1310/17/news006.html http://codezine.jp/article/detail/7767

3. ちょっと宣伝　TIS OSSサポートサービス対象OSS インフラ基盤運用基盤アプリケーション稼働基盤

4. ちょっと宣伝　TIS OSSサポートサービス問い合わせ先 TIS株式会社 OSSサポートサービス担当窓口 oss-sales@ml.tis.co.jp

5. テスト駆動インフラ DevOps と本編に入る前に

6. 開発スピードの向上 ≒ ビジネススピードの向上開発スピードを向上させてもリリースや運用に手間取っては意味がない Devの開発スピードにOpsも追従する必要がある => DevOpsを実践してビジネススピードを加速しよう本編に入る前に

7. 「アジャイル型開発におけるプラクティス活用事例調査」の報告書とリファレンスガイドを公開http://www.ipa.go. jp/sec/softwareengineering/reports/20130319.html　IPA資料より抜粋本編に入る前にアジャイル開発のプラクティスの一部ご紹介 ● ユニットテストの自動化 ● 継続的インテグレーション ● リファクタリング ● テスト駆動開発開発スピードを早めた

8. 本編に入る前にちょっと待って、これって開発者の話し？いいえ、そんなことありませんテスト駆動インフラの実践 => スピード感を持ってインフラ環境を提供出来る！（とぼくは思う）

9. Culture Tools 尊重・尊敬し合う信頼し合う失敗に対して寛大に責任を押し付けないインフラ自動化バージョン管理ワンステップビルド/デプロイメトリクスの共有チャットの活用

10. Culture Tools 尊重・尊敬し合う信頼し合う失敗に対して寛大に責任を押し付けないインフラ自動化バージョン管理ワンステップビルド/デプロイメトリクスの共有チャットの活用

11. インフラ自動化を実現するために Provisioning Toolchain Introduction for Velocity Online Conference (March 2010) ここの話し

12. 今日話そうと思っていること Step1: インフラ構築自動化ツールの導入 Step2: インフラテスト自動化ツールの導入 Step3: テスト駆動インフラの実践 Step4: インフラの継続的インテグレーション Step5: インフラの継続的デリバリー

13. What is Chef ? ● インフラ環境の構築や構成管理の自動化ツール ○ OS環境の設定・パッケージインストール・ミドルウェア設定 ● Rubyの拡張なので、Rubyがそのまま使える ● 何度実行しても同じ状態に収束する（冪等性） ● インフラの定義がコード化（形式知化）される Infrastructure as Code step 1 構築自動化昨日（7/14）Chefが1000万ダウンロードを達成したようです！

14. Chef 3分クッキング～Apache編～ CentOS6にApache2をインストール # curl -L https://www.opscode.com/chef/install.sh | bash # knife cookbook create apache -o /var/chef/cookbooks # vim /var/chef/cookbooks/apache/recipes/default.rb package 'httpd' # chef-solo -o apache 〜 chefのログ〜 # rpm -qa | grep httpd httpd-tools-2.2.15-30.el6.centos.x86_64 httpd-2.2.15-30.el6.centos.x86_64 step 1 構築自動化

15. 何がいいの？インフラをコードで定義出来る Githubなどを使ってバージョン管理出来る！ step 1 構築自動化

16. 何がいいの？ Githubなどを使ってバージョン管理出来る！　　「誰が」「いつ」「何を」変更したか一目瞭然エクセルで作った手順書の場合 ● 変更履歴の管理は履歴表シートで過去のファイルは共有フォルダ ● メールで更新ファイルを上司に送ってレビュー依頼。レビュー結果はメールに残っている状態 ● 変更実施者を書き換え忘れて上司に差し戻される ● ファイルの更新を他の人と同時にしないように注意する必要がある Infrastructure as Codeを実践したら ● バージョン管理システムで履歴と差分を一括管理 ● プルリクエストでのレビュー依頼。レビュー結果はレビュー依頼と紐付いて残る ● 変更実施者は自動で登録されるので、書き換え忘れが発生しない ● 変更が衝突してもバージョン管理システムがうまくやってくれる step 1 構築自動化

17. Githubは会社じゃ使いづらいな.... 大丈夫！今日はこんなLTがあるらしいですよ。「チケット駆動でテスト駆動なアプリケーション開発」 --- STC 冨永善視きっとGitLabとか出てくるはず step 1 構築自動化 https://about.gitlab.com/

18. 構築は自動化したけど... # curl -L https://www.opscode.com/chef/install.sh | bash # knife cookbook create apache -o /var/chef/cookbooks # vim /var/chef/cookbooks/apache/recipes/default.rb package 'httpd' # chef-solo -o apache 〜 chefのログ〜 # rpm -qa | grep httpd httpd-tools-2.2.15-30.el6.centos.x86_64 httpd-2.2.15-30.el6.centos.x86_64 テストは手動... step 2 テスト自動化

19. インフラテストの自動化ツール ● ChefSpec ○ RSpecを拡張した、Chef専用のテスティングフレームワーク。ノードにrecipeを適用せずにテストを実行可能 ● serverspec ○ RSpecを拡張したサーバテストのフレームワーク。テスト対象サーバにsshでログインしてサーバの状態を確認する。単体テスト（サーバ内部からみてどういう状態か）が主な用途 ● infrataster ○ RSpecを拡張したサーバテストのフレームワーク。対象サーバの外からサーバの状態を確認する。結合テストが主な用途 step 2 テスト自動化

20. What is serverspec ? ● 2013年3月末にリリース ● RSpecでサーバの状態をテスト ● 本質はサーバの状態を記述したコードをテスト ○ PuppetマニフェストやChefレシピなど ● インフラコードの開発やリファクタリングを効率よく行うためのツール step 2 テスト自動化 https://speakerdeck.com/mizzy/serverspec-at-jtf2014　より抜粋

21. serverspecの例 Apacheがインストールされてて、80番でリッスンしてるか describe package('httpd') do it { should be_installed } end describe port(80) do it { should be_listening } end 起動はserverspec-init と rake spec 内部的には、sshで対象サーバにログインして rpm -q httpd を打ってパッケージがインストールされているか内部的には、sshで対象サーバにログインして netstat -tunl | grep -- :80 を打って80ポートがリッスンしているか step 2 テスト自動化 http://tech-sketch.jp/2014/04/serverspec.html

22. What is serverspec ? ● 2013年3月末にリリース ● RSpecでサーバの状態をテスト ● 本質はサーバの状態を記述したコードをテスト ○ PuppetマニフェストやChefレシピなど ● インフラコードの開発やリファクタリングを効率よく行うためのツール step 2 テスト自動化 https://speakerdeck.com/mizzy/serverspec-at-jtf2014　より抜粋

23. ● 本質はサーバの状態を記述したコードをテスト

24. ● 本質はサーバの状態を記述したコードをテストアジャイル開発のプラクティスの一つにこんなのありました ● テスト駆動開発 ● リファクタリング

25. テスト駆動インフラに向けて TDDの利点 ● 安心出来る ○ テストコードを先に書いて、プロダクトコードを書くので、プロダクトコードが確実にテストを満たせる ● 自ずとテスト自動化が出来る ○ テストコード有りきなので、テスト自動化を推進出来る ● リファクタリング！ ○ テストコードがあるので、変更に強くなり、品質の高いコードを保てる step 3 インフラTDD RED → GREEN REFACTOR

26. インフラTDDの支援ツール Chefとserverspecを使えばインフラTDDは出来そう serverspec実行→Red確認→Chef実行→serverspec実行→Green確認でも... ● Chefを使うとクリーンなOS環境からやり直したくなる ● 都度OS入れてChef入れてserverspec入れて...を繰り返すと嫌になる ○ テンポ悪いし、TDDやりたくなくなる step 3 インフラTDD

27. インフラTDDの支援ツール Test-Kitchenっていう便利なツールがあります ● Heavy Water Operations LLC.が提供しているテストツールセット ○ 元は旧OpsCode社（現Chef社）で開発されてた ● プラグインによって様々な環境に対して使える ○ Vagrant, EC2, Docker | serverspec, ChefSpec ● Chefだけでなく、PuppetやAnsibleにも対応している（っぽい） ● 個別のツールを使うよりテンポよくTDD出来る step 3 インフラTDD

28. Test-Kitchenの使い方 ● gem install test-kitchen (※事前にRubyをインストール) ● kitchen init で初期化(※chef-repo内で実行) ○ .kitchen.ymlとtestディレクトリが生成される ● .kitchen.ymlの中身 ○ driver: dockerやvagrant, ec2など ○ provisioner: chef-solo, chef-zeroなど ○ platforms: centos, ubuntuなど ○ suites: chef実行時のパラメータ(run_listやattributeなど)を設定 ● test/integration/serverspec/にテストコードを記述 step 3 インフラTDD

29. Test-Kitchenの使い方 ● kitchen create name でdriverで指定した先にインスタンスを生成 ● kitchen converge name でchef-soloなどを実行 ● kitchen verify name でserverspecを実行 ● kitchen destroy name でインスタンスを破棄 ● kitchen test name でインスタンスの生成〜プロビジョニング・テスト実行、インスタンスの破棄までひと通り実行 ● kitchen login name で困った時にはログイン可能 step 3 インフラTDD

30. 何が嬉しい？ ● Chefやserverspec個々に実行するよりテンポよくインフラTDDが出来る ○ 特にkitchen-dockerを使うとインスタンスの生成が一瞬 ● インスタンスの生成や破棄が簡単に出来る ● driverを変更することでdockerやec2などを柔軟に変更できる ○ dockerでテストが通ったらec2にインスタンス生成して動作確認なども簡単に出来る ● インフラTDDが楽しくなる step 3 インフラTDD

31. インフラコードのCI TDDと来たら次はCI（継続的インテグレーション）ですね！ Test-Kitchenを使ってインフラTDDを実践していればすでにChefのコードとテストのコードはある step 4 インフラCI CIツールとgitを連携させて kitchen test を実行するのみ！

32. インフラCI実践方法の一例 step 4 インフラCI ①git push ②post notifyCommit ③git pull ④kitchen test kitchen- docker

33. Jenkinsよくわからないな.... 大丈夫！今日はこんなLTがあるらし(ry 「チケット駆動でテスト駆動なアプリケーション開発」 --- STC 冨永善視きっとJenkinsとか出てくるはず step 4 インフラCI

34. インフラのCD（ここからは妄想） CIと来たら次はCD（継続的デリバリー）ですね！ Test-Kitchenには様々なドライバーがあるので、開発環境のCDは簡単にできそうですね本番環境はCultureとToolsをうまく共存させて各々の環境で最適な方法を模索 step 5 インフラCD

35. インフラCD実践方法の一例① step 5 インフラCD CIで無事にテスト通ったら kitchen create kitchen converge kitchen verify kitchen-vagrant

36. インフラCD実践方法の一例② step 5 インフラCD CIで無事にテスト通ったら kitchen- docker kitchen create kitchen converge kitchen verify docker commit ～ docker push docker-hub docker pull docker run ～

37. まとめ「Infrastructure as Code」が世の中で浸透してきて「インフラエンジニアだからコードは書かない」が通じなくなってきている

38. まとめだからこそ、小さなところから「Infrastructure as Code」や「テスト駆動インフラ」を初めて、 TISなりのDevOpsを模索してみませんか？

39. Thank you for your attention!!

https://twitter.com	92
http://s.deeeki.com	33
https://cybozulive.com	7
http://www.slideee.com	6
http://geechscamp.lovepop.jp	1
http://webcache.googleusercontent.com	1

SlideShare for iOS

Views

Actions

Embeds 140

Report content

Transcript