テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 1,434 views

TIS株式会社で行った社内勉強会(西新宿Tech-Circle)の資料です。 ...

TIS株式会社で行った社内勉強会(西新宿Tech-Circle)の資料です。
Test-Kitchenを使ってTDDを実践する方法をご紹介しています。
資料内で出てくるGitLabやJenkinsのLT資料は以下リンクより見れます。
http://www.slideshare.net/yoshimitominaga/ss-36972336

Statistics

Views

Total Views
1,434
Views on SlideShare
1,339
Embed Views
95

Actions

Likes
7
Downloads
13
Comments
0

4 Embeds 95

https://twitter.com 55
http://s.deeeki.com 33
http://www.slideee.com 6
http://geechscamp.lovepop.jp 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • テスト駆動インフラ構築 ~Chefとserverspecを使った インフラ構築自動化のすすめ~ TIS株式会社 戦略技術センター 秋穂 賢 2014/7/15(Tue) @ 西新宿Tech-Circle#2 「DevOps勉強会」
  • TIS株式会社 戦略技術センター所属 自己紹介 秋穂 賢(あきほ すぐる)名前 Zabbix, OTRS, JobScheduler, Chefなど仕事 http://www.atmarkit.co.jp/ait/articles/1310/17/news006.html http://codezine.jp/article/detail/7767
  • ちょっと宣伝 TIS OSSサポートサービス 対象OSS インフラ基盤 運用基盤 アプリケーション 稼働基盤
  • ちょっと宣伝 TIS OSSサポートサービス 問い合わせ先 TIS株式会社 OSSサポートサービス担当窓口 oss-sales@ml.tis.co.jp
  • テスト駆動インフラ DevOps と 本編に入る前に
  • 開発スピードの向上 ≒ ビジネススピードの向上 開発スピードを向上させてもリリースや運用に手間 取っては意味がない Devの開発スピードにOpsも追従する必要がある => DevOpsを実践してビジネススピードを加速しよう 本編に入る前に
  • 「アジャイル型開発におけるプラクティス活用事例調査」の報告書とリファレンスガイドを公開http://www.ipa.go. jp/sec/softwareengineering/reports/20130319.html IPA資料より抜粋 本編に入る前に アジャイル開発のプラクティスの一部ご紹介 ● ユニットテストの自動化 ● 継続的インテグレーション ● リファクタリング ● テスト駆動開発 開発スピードを早めた
  • 本編に入る前に ちょっと待って、これって開発者の話し? いいえ、そんなことありません テスト駆動インフラの実践 => スピード感を持ってインフラ環境を提供出来る! (とぼくは思う)
  • Culture Tools 尊重・尊敬し合う 信頼し合う 失敗に対して寛大に 責任を押し付けない インフラ自動化 バージョン管理 ワンステップ ビルド/デプロイ メトリクスの共有 チャットの活用
  • Culture Tools 尊重・尊敬し合う 信頼し合う 失敗に対して寛大に 責任を押し付けない インフラ自動化 バージョン管理 ワンステップ ビルド/デプロイ メトリクスの共有 チャットの活用
  • インフラ自動化を実現するために Provisioning Toolchain Introduction for Velocity Online Conference (March 2010) ここの話し
  • 今日話そうと思っていること Step1: インフラ構築自動化ツールの導入 Step2: インフラテスト自動化ツールの導入 Step3: テスト駆動インフラの実践 Step4: インフラの継続的インテグレーション Step5: インフラの継続的デリバリー
  • What is Chef ? ● インフラ環境の構築や構成管理の自動化ツール ○ OS環境の設定・パッケージインストール・ミドルウェア設定 ● Rubyの拡張なので、Rubyがそのまま使える ● 何度実行しても同じ状態に収束する(冪等性) ● インフラの定義がコード化(形式知化)される Infrastructure as Code step 1 構築自動化 昨日(7/14)Chefが1000万ダウンロード を達成したようです!
  • 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 構築自動化
  • 何がいいの? インフラをコードで定義出来る Githubなどを使ってバージョン管理出来る! step 1 構築自動化
  • 何がいいの? Githubなどを使ってバージョン管理出来る!   「誰が」「いつ」「何を」変更したか一目瞭然 エクセルで作った手順書の場合 ● 変更履歴の管理は履歴表シートで過 去のファイルは共有フォルダ ● メールで更新ファイルを上司に送って レビュー依頼。レビュー結果はメール に残っている状態 ● 変更実施者を書き換え忘れて上司に 差し戻される ● ファイルの更新を他の人と同時にしな いように注意する必要がある Infrastructure as Codeを実践したら ● バージョン管理システムで履歴と差分 を一括管理 ● プルリクエストでのレビュー依頼。レ ビュー結果はレビュー依頼と紐付い て残る ● 変更実施者は自動で登録されるの で、書き換え忘れが発生しない ● 変更が衝突してもバージョン管理シス テムがうまくやってくれる step 1 構築自動化
  • Githubは会社じゃ使いづらいな.... 大丈夫! 今日はこんなLTがあるらしいですよ。 「チケット駆動でテスト駆動なアプリケーション開 発」 --- STC 冨永善視 きっとGitLabとか出てくるはず step 1 構築自動化 https://about.gitlab.com/
  • 構築は自動化したけど... # 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 テスト自動化
  • インフラテストの自動化ツール ● ChefSpec ○ RSpecを拡張した、Chef専用のテスティングフレームワーク。 ノードにrecipeを適用せずにテストを実行可能 ● serverspec ○ RSpecを拡張したサーバテストのフレームワーク。テスト対象 サーバにsshでログインしてサーバの状態を確認する。単体テ スト(サーバ内部からみてどういう状態か)が主な用途 ● infrataster ○ RSpecを拡張したサーバテストのフレームワーク。対象サーバ の外からサーバの状態を確認する。結合テストが主な用途 step 2 テスト自動化
  • What is serverspec ? ● 2013年3月末にリリース ● RSpecでサーバの状態をテスト ● 本質はサーバの状態を記述したコードをテスト ○ PuppetマニフェストやChefレシピなど ● インフラコードの開発やリファクタリングを効率よ く行うためのツール step 2 テスト自動化 https://speakerdeck.com/mizzy/serverspec-at-jtf2014 より抜粋
  • 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
  • What is serverspec ? ● 2013年3月末にリリース ● RSpecでサーバの状態をテスト ● 本質はサーバの状態を記述したコードをテスト ○ PuppetマニフェストやChefレシピなど ● インフラコードの開発やリファクタリングを効率よ く行うためのツール step 2 テスト自動化 https://speakerdeck.com/mizzy/serverspec-at-jtf2014 より抜粋
  • ● 本質はサーバの状態を記述したコードをテスト
  • ● 本質はサーバの状態を記述したコードをテスト アジャイル開発のプラクティスの一つにこんなのありました ● テスト駆動開発 ● リファクタリング
  • テスト駆動インフラに向けて TDDの利点 ● 安心出来る ○ テストコードを先に書いて、プロダクトコードを書くので、 プロダクトコードが確実にテストを満たせる ● 自ずとテスト自動化が出来る ○ テストコード有りきなので、テスト自動化を推進出来る ● リファクタリング! ○ テストコードがあるので、変更に強くなり、品質の高い コードを保てる step 3 インフラTDD RED → GREEN REFACTOR
  • インフラTDDの支援ツール Chefとserverspecを使えばインフラTDDは出来そう serverspec実行→Red確認→Chef実行→serverspec実行→Green確認 でも... ● Chefを使うとクリーンなOS環境からやり直したくなる ● 都度OS入れてChef入れてserverspec入れて...を繰 り返すと嫌になる ○ テンポ悪いし、TDDやりたくなくなる step 3 インフラTDD
  • インフラTDDの支援ツール Test-Kitchenっていう便利なツールがあります ● Heavy Water Operations LLC.が提供している テストツールセット ○ 元は旧OpsCode社(現Chef社)で開発されてた ● プラグインによって様々な環境に対して使える ○ Vagrant, EC2, Docker | serverspec, ChefSpec ● Chefだけでなく、PuppetやAnsibleにも対応して いる(っぽい) ● 個別のツールを使うよりテンポよくTDD出来る step 3 インフラTDD
  • 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
  • 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
  • 何が嬉しい? ● Chefやserverspec個々に実行するよりテンポよ くインフラTDDが出来る ○ 特にkitchen-dockerを使うとインスタンスの生成が一瞬 ● インスタンスの生成や破棄が簡単に出来る ● driverを変更することでdockerやec2などを柔軟 に変更できる ○ dockerでテストが通ったらec2にインスタンス生成して動 作確認なども簡単に出来る ● インフラTDDが楽しくなる step 3 インフラTDD
  • インフラコードのCI TDDと来たら次はCI(継続的インテグレーション) ですね! Test-Kitchenを使ってインフラTDDを実践していれ ばすでにChefのコードとテストのコードはある step 4 インフラCI CIツールとgitを連携させて kitchen test を実行するのみ!
  • インフラCI実践方法の一例 step 4 インフラCI ①git push ②post notifyCommit ③git pull ④kitchen test kitchen- docker
  • Jenkinsよくわからないな.... 大丈夫! 今日はこんなLTがあるらし(ry 「チケット駆動でテスト駆動なアプリケーション開 発」 --- STC 冨永善視 きっとJenkinsとか出てくるはず step 4 インフラCI
  • インフラのCD(ここからは妄想) CIと来たら次はCD(継続的デリバリー)ですね! Test-Kitchenには様々なドライバーがあるので、開 発環境のCDは簡単にできそうですね 本番環境はCultureとToolsをうまく共存させて各々 の環境で最適な方法を模索 step 5 インフラCD
  • インフラCD実践方法の一例① step 5 インフラCD CIで無事にテスト通ったら kitchen create kitchen converge kitchen verify kitchen-vagrant
  • インフラCD実践方法の一例② step 5 インフラCD CIで無事にテスト通ったら kitchen- docker kitchen create kitchen converge kitchen verify docker commit ~ docker push docker-hub docker pull docker run ~
  • まとめ 「Infrastructure as Code」が世 の中で浸透してきて 「インフラエンジニアだからコー ドは書かない」が通じなくなって きている
  • まとめ だからこそ、小さなところから 「Infrastructure as Code」や 「テスト駆動インフラ」を初めて、 TISなりのDevOpsを模索して みませんか?
  • Thank you for your attention!!