1.
(※開発環境改め)DevOpsのアプローチと
クラウド/バーチャル環境/構成管理ツール
のお話
オープンセミナー2015@広島
『クラウド時代の構成管理入門』
Feb. 14. 2015
@sawanoboly(HiganWorks LLC, Opsrock LLC)

2.
本日の内容…の前に 1/2
•基本的なところからのんびり話していきます
•広島のボルテージをよう知らん
•時間もたっぷりあるので
•各思想・ツールに対して個人の解釈も多めです
•あまり他人の話を聞かないのです
2

3.
本日の内容…の前に 2/2
•たまに話題のスコープが妙に拡大します
•DevOpsが絡むと少々仕方ないです
•細かい話には戻ります
•セッション中のインフラについて
•(ほぼ)物理より上、アプリより下を指します
3

4.
本日の内容
•DevOpsのこと
•を踏まえてからの
•ツールによる効率化
•Vagrantのこと
•Chefのこと
•身の回りのDevOpsをすすめる
4

5.
まずはDevOpsのことを

6.
大本は2009年のFlickr発表
•対立やめて協力しよう
6
http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr

7.
なぜ協力するのか ?

8.
何のために してるか
開発
構築運用
(そもそも)

9.
DevOpsの目的まで広げてみる
9

10.
DevOpsの目的まで広げてみる
•個人の役割がDev/Opsだから？
9

11.
DevOpsの目的まで広げてみる
•個人の役割がDev/Opsだから？
•開発部門/運用部門に所属しているから？
9

12.
DevOpsの目的まで広げてみる
•個人の役割がDev/Opsだから？
•開発部門/運用部門に所属しているから？
•IT関連の会社(or 会社のIT部門)にいるから ※おつ
きあい含む
=> 大抵がこの部分にあたる
9

13.
DevOpsの目的まで広げてみる
•個人の役割がDev/Opsだから？
•開発部門/運用部門に所属しているから？
•IT関連の会社(or 会社のIT部門)にいるから ※おつ
きあい含む
=> 大抵がこの部分にあたる
•じゃあ会社の目的は?
9

14.
会社はビジネスで利益をあげたい
•そのなかで…
•Devは価値(サービス)をつくる
•Opsは価値(サービス)を届ける・維持する
•DevもOpsも目標は同じ、だから協力できるはず
10

15.
と、いってもですね。。

16.
ウォーターフォール
この辺開発
この辺構築
Dev
Ops

17.
ウォーターフォール
この辺開発
この辺構築
Dev
Ops
DevやOpsが
ビジネスゴールを縮めるとか…

18.
ウォーターフォール
この辺開発
この辺構築
Dev
Ops
DevやOpsが
ビジネスゴールを縮めるとか…
本当は端から端まで縮めたい

19.
手を出しづらかったりとか
この辺開発
この辺構築
Dev
Ops

20.
手を出しづらかったりとか
この辺開発
この辺構築
Dev
Ops
このへん
SIer

21.
手を出しづらかったりとか
この辺開発
この辺構築
Dev
Ops
このへん
SIer
実は自分が
SIer

22.
と言って
何もしないという選択は無い

23.
とりあえず(大半の人が)
手を出せる範囲で
この辺開発
この辺構築
Dev
Ops
このへんを縮めたり、繰り返したり
できるようになっておきましょうという
ちいさめのDevOps

24.
身の回りの効率化をしておこう
•ビジネスの変化に対応できる(かもしれない)
•ほかでもつぶしが効くように
•あわよくば会社全体のフローに影響を
•継続的なデリバリーとか
•コストの削減とか
•真にDevOpsするには経営陣の理解が必要
•せめて普段からやってないと説得力もない
16

25.
ということを踏まえて(とりあえず)
小さなDevOpsゴールへむけて

26.
ツールによる効率化の
話に進むことにします

27.
Vagrantで環境の共有

28.
使っている方も多いと思います
20

29.
Vagrant概要
•読み：べーぐらんと
•バーチャル環境のフロントエンド
•Dev的には
•アプリケーション環境をローカル依存なしで作成
•Ops的には
•インフラ構築の使い捨てお試し環境
21

30.
DevなVagrant

31.
ローカルマシン
アプリを動かすには環境が必要
23
App Code

32.
ローカルマシン
アプリを動かすには環境が必要
23
App Code

33.
ローカルマシン
アプリを動かすには環境が必要
23
App Code

34.
ローカルマシン
アプリを動かすには環境が必要
23
App Code
•導入手順がバラバラ

35.
ローカルマシン
アプリを動かすには環境が必要
23
App Code
•導入手順がバラバラ
•バージョン ってない

36.
ローカルマシン
アプリを動かすには環境が必要
23
App Code
•導入手順がバラバラ
•バージョン ってない
•それぞれ設定が違う

37.
ローカルマシン
アプリを動かすには環境が必要
23
App Code
•導入手順がバラバラ
•バージョン ってない
•それぞれ設定が違う
•そして…

38.
ローカルマシン
アプリを動かすには環境が必要
23
App Code
•導入手順がバラバラ
•バージョン ってない
•それぞれ設定が違う
•そして…
•ローカルでは（略

39.
ローカルマシン
Vagrantのアプローチ
24
App Code

40.
バーチャルマシンローカルマシン
Vagrantのアプローチ
24
App Code

41.
バーチャルマシンローカルマシン
Vagrantのアプローチ
24
App Code App Code共有

42.
バーチャルマシンローカルマシン
Vagrantのアプローチ
24
App Code App Code共有
Infra Code

43.
バーチャルマシンローカルマシン
Vagrantのアプローチ
24
App Code App Code共有
構成Infra Code

44.
バーチャルマシンローカルマシン
Vagrantのアプローチ
24
App Code App Code共有
構成Infra Code
変更も反映

45.
hubを通して配布
•アプリケーションコードと、動作するプラット
フォームを同じように扱う
•Dev <=> Dev うれしい
25
App Code
Infra Code
App Code
Infra Code

46.
OpsなVagrant

47.
アプリを支えるにはプラットホームが重要
27
検証用サーバ

48.
アプリを支えるにはプラットホームが重要
27
検証用サーバ

49.
アプリを支えるにはプラットホームが重要
27
検証用サーバ

50.
アプリを支えるにはプラットホームが重要
•OSインストール
27
検証用サーバ

51.
アプリを支えるにはプラットホームが重要
•OSインストール
•手作業で試行錯誤
27
検証用サーバ

52.
アプリを支えるにはプラットホームが重要
•OSインストール
•手作業で試行錯誤
•アプリコードを置くのは
ギリギリ
27
検証用サーバ

53.
アプリを支えるにはプラットホームが重要
•OSインストール
•手作業で試行錯誤
•アプリコードを置くのは
ギリギリ
•結局最初に本番環境
27
検証用サーバ

54.
アプリを支えるにはプラットホームが重要
•OSインストール
•手作業で試行錯誤
•アプリコードを置くのは
ギリギリ
•結局最初に本番環境
27
検証用サーバ
App Code ?

55.
アプリを支えるにはプラットホームが重要
•OSインストール
•手作業で試行錯誤
•アプリコードを置くのは
ギリギリ
•結局最初に本番環境
27
検証用サーバ
App Code ?
•クリーンな状態からまた
構築できるの？

56.
Vagrantのアプローチ
28

57.
Vagrantのアプローチ
28
バーチャルマシン

58.
Vagrantのアプローチ
28
バーチャルマシン
Infra Code v0.1

59.
Vagrantのアプローチ
28
バーチャルマシン
構築Infra Code v0.1

60.
Vagrantのアプローチ
28
バーチャルマシン
構築Infra Code v0.1
破棄

61.
Vagrantのアプローチ
28
バーチャルマシン
構築Infra Code v0.1
バーチャルマシン
Infra Code v0.x 構築 App
破棄

62.
Vagrantのアプローチ
28
バーチャルマシン
構築Infra Code v0.1
バーチャルマシン
Infra Code v0.x 構築 App
破棄
破棄

63.
Vagrantのアプローチ
28
バーチャルマシン
構築Infra Code v0.1
Infra Code v1.0
バーチャルマシン
Infra Code v0.x 構築 App
破棄
破棄

64.
Vagrantのアプローチ
28
バーチャルマシン
構築Infra Code v0.1
Infra Code v1.0
バーチャルマシン
Infra Code v0.x 構築 App
バーチャルマシン
構築 App
破棄
破棄

65.
復数の環境に同じコードを適用
•バージョン管理ツールに乗せて、履歴も把握
•いつでもゼロから試せて修正もしやすい
•時間のかかる構築は、スナップショットも使える
29
検証用サーバ
Infra Code v1.0
本番用サーバ
Infra Code v1.0

66.
Dev/Opsで結構類似点が・・
は一旦おいといて

67.
Vagrantの機能

68.
Providers: バーチャル環境を作る先
•お手元系
•Virtualbox、VMWare、Hyper-Vなど
•IaaS系
•OpenStack、Cloudstackなどプライベート
•AWS(EC2)、DigitalOceanなどパブリック
•コンテナ
•Dockerなど
32
※3rdのプラグインを含みます

69.
複数VM、複数NWの構成もOK
33
Public Net

70.
複数VM、複数NWの構成もOK
33
Public Net Public Net
Private Net

71.
Provisioner: VM内の構築
•有名所のプロビジョニング
ツールを実行できる
•説明での『Infra Code』に
あたる部分
34

72.
Provisionerは組み合わせ自由
•まずはShellからはじめるのがオススメ
•複数定義してもOK
•shell-1つめ => chef => shell-2つめ など
•shellから少しづつ他のツールにうつすとか
35

73.
ここまで基本 <=
=> ここから応用

74.
Box

75.
Box = マシンイメージ
•OSをインストールして幾らかVagrant用の設定を
足したもの
• で配布されているのは、ほぼ素のOSインストー
ル直後が多い
•毎回一から作るのは時間かかるというときは、Box
をつくってもよい
38

76.
PackerとBento(Chef)で楽につくれます
39

77.
Share (connect)

78.
ちょっとプレビューして欲しい時
•Vagrantfileのやりとりで済むとはいえ、アプリま
で上げてもらうのはそこそこコストがかかります
41
App Code
Infra Code
App Code
Infra Code

79.
インターネット越しに公開
42
バーチャルマシン
App Code
atlas (旧VagrantCloud)
ブラウザで見た目チェック
SSHで環境チェック

80.
Vagnant機能のまとめ
•いろんな環境に対応可
•複数のバーチャルネットワーク
•複数のバーチャルマシン
•環境の共有は２通り
•Vagrantfileでプロビジョニングコードとまとめて
•Packerでboxに
•プレビューしてもらうならShareも
43

81.
これらをまず確認してから使いましょう
44
(※)書籍の方は書式が古い箇所も

82.
ではVagrantも対応している
プロビジョニングツールから
１つ…

83.
Chef

84.
Chefの概要
•米Chef Software(旧Opscode)の製品
•構成管理(Configration Management)
•インフラの情報を収集・集約
Chef-Server(Zero)/Chef-Repo
•リソース定義の記述から、そのとおりに収束
Chef-Client
今日はプロビジョニングツールの側面を
47

85.
Chef(Client)の技術要素
•インストールはRuby込みのパッケージで提供
•Ruby DSLで記述
•ERBテンプレートで環境依存のコンフィグを生成
•最小単位はリソース、それぞれ状態を定義する
•file / service / package などOS向けリソース
•クラウド上のインスタンス等、インフラリソース
(※Chef-Provisioning)
48

86.
リソース記述 = レシピ
•リソースの状態を記述(レシピ)して実行すると ?
•対象のリソースが記述と違えば修正
•リソースが記述どおりの状態なら何もしない
49
## nanoがインストールされた状態
package ‘nano’
## nanoがアンインストールされた状態
package ‘nano’ do
action :remove
end

87.
先程のレシピをChef-Applyで
とりあえず実行
50
$ echo "package 'nano'" | sudo chef-apply -s
Recipe: (chef-apply cookbook)::(chef-apply recipe)
* apt_package[nano] action install
- install version 2.2.6-1 of package nano
# ↑ 入ってないのでインストール
$ echo "package 'nano'" | sudo chef-apply -s
Recipe: (chef-apply cookbook)::(chef-apply recipe)
* apt_package[nano] action install (up to date)
# ↑ 入ってるのでなにもしない

88.
removeも試してみる
51
$ echo "package 'nano' do action :remove end" | sudo chef-apply -s
Recipe: (chef-apply cookbook)::(chef-apply recipe)
* apt_package[nano] action remove
- remove package nano
# ↑ 入っているのでアンインストール
$ echo "package 'nano' do action :remove end" | sudo chef-apply -s
Recipe: (chef-apply cookbook)::(chef-apply recipe)
* apt_package[nano] action remove (up to date)
# ↑ 入っていないのでなにもしない

89.
serviceリソースの例
52
$ cat << _EOL_ | sudo chef-apply -s
> service 'cron' do
> action [:enable, :start] # サーバ起動時に実行を有効と、今実行
> end
> _EOL_
Recipe: (chef-apply cookbook)::(chef-apply recipe)
* service[cron] action enable (up to date)
* service[cron] action start (up to date)

90.
テンプレートの置換例
53
$ cat sample.erb
hoge is <%= @hoge %>.
template 'sample.txt' do
source 'sample.erb'
local true
variables({ hoge: 'piyo' })
end
ERBテンプレート
テンプレートリソース

91.
テンプレートで文字列を置換
54
$ sudo chef-apply template.rb
Recipe: (chef-apply cookbook)::(chef-apply recipe)
* template[sample.txt] action create
- create new file sample.txt
- update content in file sample.txt from none to 141d2b
--- sample.txt 2015-02-13 02:42:55.197828606 +0000
+++ /tmp/chef-rendered-template20150213-21341-dzvsb6 2015-02-13
02:42:55.000000000 +0000
@@ -1 +1,2 @@
+hoge is piyo.
$ cat sample.txt
hoge is piyo.
=>
$ cat sample.erb
hoge is <%= @hoge %>.
#=>

92.
55
リソースからの階層構造

93.
55
リソース
リソース
リソースからの階層構造

94.
55
レシピ
(x n)
リソース
リソース
リソースからの階層構造

95.
55
レシピ
(x n)
リソース
リソース
その他色々
(x n)
リソースからの階層構造

96.
55
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
リソースからの階層構造

97.
55
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
リソースからの階層構造

98.
55
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
リソースからの階層構造

99.
55
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Roleなど役割記述の
ファイル (option)
リソースからの階層構造

100.
55
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Roleなど役割記述の
ファイル (option)
収集した各種状態の
ファイル (option)
リソースからの階層構造

101.
55
Chef-Repo
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Roleなど役割記述の
ファイル (option)
収集した各種状態の
ファイル (option)
リソースからの階層構造

102.
55
Chef-Repo
Cookbook
+さらにその他色々 => インフラコード一式
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Roleなど役割記述の
ファイル (option)
収集した各種状態の
ファイル (option)
リソースからの階層構造

103.
55
Chef-Repo
Cookbook
+さらにその他色々 => インフラコード一式
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Roleなど役割記述の
ファイル (option)
収集した各種状態の
ファイル (option)
リソースからの階層構造

104.
Shellとプロビジョニングツールを比べる
56

105.
Shellとプロビジョニングツールを比べる
•OS(ディストリビューション)の違いを結構吸収
56

106.
Shellとプロビジョニングツールを比べる
•OS(ディストリビューション)の違いを結構吸収
•リソースに対する状態がひとまとまりで見やすい
56

107.
Shellとプロビジョニングツールを比べる
•OS(ディストリビューション)の違いを結構吸収
•リソースに対する状態がひとまとまりで見やすい
•違いだけ適用、状況依存の分岐処理記述が少ない
56

108.
Shellとプロビジョニングツールを比べる
•OS(ディストリビューション)の違いを結構吸収
•リソースに対する状態がひとまとまりで見やすい
•違いだけ適用、状況依存の分岐処理記述が少ない
•レシピは間違ってても悪影響が少ない
•Syntaxエラーならそもそも走らない
•ツールがこけても、サーバの状態に変更はない
56

109.
Shellとプロビジョニングツールを比べる
•OS(ディストリビューション)の違いを結構吸収
•リソースに対する状態がひとまとまりで見やすい
•違いだけ適用、状況依存の分岐処理記述が少ない
•レシピは間違ってても悪影響が少ない
•Syntaxエラーならそもそも走らない
•ツールがこけても、サーバの状態に変更はない
•リソース同士の依存が書きやすい => 次へ
56

110.
リソース依存の例
•httpd.conf
•変更したらhttpdをリロードしたい
•変更しなかったら特に何もしない
•レシピでは2通り
•file(template)リソースからserviceリソースに通知
•serviceリソースがfile(template)リソースを監視
57

111.
リソース依存のサンプル
•書きっぱなしで何度実行してもよいのが楽
•事前に変更点のある/なしを折り込まなくてよい
58
service ‘httpd’ do
subscribes :relaod, file[httpd.conf]
end # service => fileを見張る例
file ‘httpd.conf’ do
notifies :relaod, service[httpd]
end # file => serviceに通知の例

112.
(Chef等の)
プロビジョニングツールを
導入するには？

113.
おすすめは2通り

114.
1. 既存のサーバを 変更せず
じわじわレシピにする

115.
例：構築済みのサーバ
•手作業で作成
•たまにコンフィグの修正
62
既存サーバ
App Code
管理用なにか

116.
Chefをいれちゃう
•配布パッケージなら基本
的に影響はない
•`/opt/chef`以下にRuby
含めすべて格納
63
既存サーバ
App Code
管理用なにか

117.
現状リソースをレシピに書き出す
64
既存サーバ
App Code
管理用なにか

118.
現状リソースをレシピに書き出す
64
既存サーバ
App Code
管理用なにか
サービス状態
設定ファイル
ファイルもコピーでOK

119.
現状リソースをレシピに書き出す
64
既存サーバ
App Code
管理用なにか
サービス状態
設定ファイル
ファイルもコピーでOK
why-run(dry-run)で確認しつつ
実行(特に何も変わらない)

120.
現状リソースをレシピに書き出す
64
既存サーバ
App Code
管理用なにか
サービス状態
設定ファイル
ファイルもコピーでOK
why-run(dry-run)で確認しつつ
実行(特に何も変わらない)
※繰り返し

121.
Cookbook完成、リポジトリへ
65
既存サーバ
App Code
管理用なにか
Cookbook
レシピ
テンプレート
レシピ

122.
じわじわレシピの要約
66

123.
じわじわレシピの要約
•サーバにあるリソースをレシピに書いて実行する
66

124.
じわじわレシピの要約
•サーバにあるリソースをレシピに書いて実行する
•Chefは未定義の属性を変更しないので雑でもOK
•ファイルならownerとか、permission
66

125.
じわじわレシピの要約
•サーバにあるリソースをレシピに書いて実行する
•Chefは未定義の属性を変更しないので雑でもOK
•ファイルならownerとか、permission
•VagrantのProvisioningもこの手法で色々つくれる
66

126.
じわじわレシピの要約
•サーバにあるリソースをレシピに書いて実行する
•Chefは未定義の属性を変更しないので雑でもOK
•ファイルならownerとか、permission
•VagrantのProvisioningもこの手法で色々つくれる
•欠点
•さすがにまあまあ事故りやすい
•見落としもありがち (cron等単品ファイルとか)
66

127.
2. 状態テストを活用する

128.
68

129.
Serverspec?
•サーバの状態をテストするツール
•元々はプロビジョニングツール用コードのリファ
クタリングのために開発
•(手作業を含む)プロビジョニング手順の最適化とし
て利用する
69

130.
例：構築済みのサーバ
•手作業で作成
•たまにコンフィグの修正
•※ここまでは同じ
70
既存サーバ
App Code
管理用なにか

131.
まずServerspecのテストを作る
•SSH越しでテスト
•サーバ側に一切変更不要
71
既存サーバ
App Code
管理用なにか
現状確認なのでオールグリーン

132.
テストしながら空のサーバでレシピを作成
72
バーチャルマシン

133.
テストしながら空のサーバでレシピを作成
72
バーチャルマシン
レシピ
テンプレート
レシピ
※レシピ書いて実行の繰り返し

134.
テストしながら空のサーバでレシピを作成
72
バーチャルマシン
レシピ
テンプレート
レシピ
※レシピ書いて実行の繰り返し
※オールグリーンまで繰り返し

135.
状態テストからレシピの要約
73

136.
状態テストからレシピの要約
•先にテストを書く
73

137.
状態テストからレシピの要約
•先にテストを書く
•テストが通る = サーバの状態が再現できている
73

138.
状態テストからレシピの要約
•先にテストを書く
•テストが通る = サーバの状態が再現できている
•テストはプロビジョニングツールに依存しない
•使いまわせる
•構成管理ツールの導入をあきらめてもテストは
残る
73

139.
状態テストからレシピの要約
•先にテストを書く
•テストが通る = サーバの状態が再現できている
•テストはプロビジョニングツールに依存しない
•使いまわせる
•構成管理ツールの導入をあきらめてもテストは
残る
•Opsは特にこちらの手法がよい
73

140.
レシピの保守はTest-Kitchen
•任意のProvisioner、任意のテストスイート
•テストに向いたライフサイクル
•なにかのビルドにも応用
74

141.
いろいろ踏まえて、
改めてDevOpsの話

142.
DevとOpsで同じツール
•Vagrant, Chef等はどちらの立場でもつかえる
•設定ファイルやインフラコードの相互乗り入れ
76
App Code
Infra Code

143.
クラウドリソースはAPI
77

144.
クラウドリソースはAPI
•調達＆廃棄が容易なので
77

145.
クラウドリソースはAPI
•調達＆廃棄が容易なので
•開発初期から並行環境で稼働できる
77

146.
クラウドリソースはAPI
•調達＆廃棄が容易なので
•開発初期から並行環境で稼働できる
•環境構築をコードにして、素早く何度も作れる
ようにする
77

147.
クラウドリソースはAPI
•調達＆廃棄が容易なので
•開発初期から並行環境で稼働できる
•環境構築をコードにして、素早く何度も作れる
ようにする
•あとからコードにする事もなんとかなる
77

148.
例：クックパッドのCodenize.tools
•既存AWS(ほか)リソースを
コード運用に転換する
•ツール開発でDevとOpsを
半ば強引に結合
78

149.
例：クックパッドのCodenize.tools
•既存AWS(ほか)リソースを
コード運用に転換する
•ツール開発でDevとOpsを
半ば強引に結合
78
2/24発売

150.
ウォーターフォール(再)
この辺開発
この辺構築
Dev
Ops

151.
ウォーターフォール(再)
この辺開発
この辺構築
Dev
Ops
Dev&Ops
ここを回す

152.
ウォーターフォール(再)
この辺開発
この辺構築
Dev
Ops
ここの時間は縮まらないかも・・
けど質はあがる
Dev&Ops
ここを回す

153.
Devは
80

154.
Devは
•開発以降の環境に興味をもとう
•Vagrantで共有し、ローカル番長をやめよう
•インフラの知識も少し探ろう
80

155.
Devは
•開発以降の環境に興味をもとう
•Vagrantで共有し、ローカル番長をやめよう
•インフラの知識も少し探ろう
•シェアする仕組み、範囲を絞ろう
80

156.
Devは
•開発以降の環境に興味をもとう
•Vagrantで共有し、ローカル番長をやめよう
•インフラの知識も少し探ろう
•シェアする仕組み、範囲を絞ろう
•デプロイメントが楽になる仕掛けやサービスを色々
使おう
•Opsに要望しよう (そうしないとNoOpsに走る)
80

157.
例：VCCW
•WordPress環境を
チームで共有
•gitで交換
•Chef, Vagrantfileで
環境別カスタマイズ
•作成者はphp中心の
WordpressなDev
81

158.
Opsは
82

159.
Opsは
•たいていが意識低い扱い
•『結局導入できない』の言い訳に使われる
82

160.
Opsは
•たいていが意識低い扱い
•『結局導入できない』の言い訳に使われる
•VMやクラウドを活かして、開発初期からインフラを詰め
てく、アプリも開発中からとにかくデプロイしていく
82

161.
Opsは
•たいていが意識低い扱い
•『結局導入できない』の言い訳に使われる
•VMやクラウドを活かして、開発初期からインフラを詰め
てく、アプリも開発中からとにかくデプロイしていく
•ツールのエラーは読もう
82

162.
Opsは
•たいていが意識低い扱い
•『結局導入できない』の言い訳に使われる
•VMやクラウドを活かして、開発初期からインフラを詰め
てく、アプリも開発中からとにかくデプロイしていく
•ツールのエラーは読もう
•XaaSは商売敵、使って手法を学ぼう
(※そのまま利用も可)
82

163.
Opsは
•たいていが意識低い扱い
•『結局導入できない』の言い訳に使われる
•VMやクラウドを活かして、開発初期からインフラを詰め
てく、アプリも開発中からとにかくデプロイしていく
•ツールのエラーは読もう
•XaaSは商売敵、使って手法を学ぼう
(※そのまま利用も可)
•Devはユーザと捉えよう
82

164.
例：Dokku
•Dockerを使ったミニheroku
•Devのコードを好きなだけすぐ動かせる
83

165.
Dev&Opsで

166.
CIツールを一緒に使おう
•テスト
•コードレビュー
•デプロイメント
85

167.
Provisionig(ほか)ツール選定
•Devのアプリと同じ言語のツールをまず触るとよ
いです (※かなり個人的な見解です)
•ツールチェーン
•アプリのコードも読める(ようになる)
•基本どれも汎用的に使えるので応用がききます
86

168.
迷ったら(一応)
DevOpsのゴールを思い出して

169.
おわりに．．．

170.
(※開発環境改め)DevOpsのアプローチと
クラウド/バーチャル環境/構成管理ツール
のお話
終
オープンセミナー2015@広島
『クラウド時代の構成管理入門』
Feb. 14. 2015