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!!