(※開発環境改め)DevOpsのアプローチと
クラウド/バーチャル環境/構成管理ツール
のお話
オープンセミナー2015@広島
『クラウド時代の構成管理入門』
Feb. 14. 2015
@sawanoboly(HiganWorks LLC, Opsrock LLC)
本日の内容…の前に 1/2
•基本的なところからのんびり話していきます
•広島のボルテージをよう知らん
•時間もたっぷりあるので
•各思想・ツールに対して個人の解釈も多めです
•あまり他人の話を聞かないのです
2
本日の内容…の前に 2/2
•たまに話題のスコープが妙に拡大します
•DevOpsが絡むと少々仕方ないです
•細かい話には戻ります
•セッション中のインフラについて
•(ほぼ)物理より上、アプリより下を指します
3
本日の内容
•DevOpsのこと
•を踏まえてからの
•ツールによる効率化
•Vagrantのこと
•Chefのこと
•身の回りのDevOpsをすすめる
4
まずはDevOpsのことを
大本は2009年のFlickr発表
•対立やめて協力しよう
6
http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
なぜ協力するのか ?
何のために してるか
開発
構築運用
(そもそも)
DevOpsの目的まで広げてみる
9
DevOpsの目的まで広げてみる
•個人の役割がDev/Opsだから?
9
DevOpsの目的まで広げてみる
•個人の役割がDev/Opsだから?
•開発部門/運用部門に所属しているから?
9
DevOpsの目的まで広げてみる
•個人の役割がDev/Opsだから?
•開発部門/運用部門に所属しているから?
•IT関連の会社(or 会社のIT部門)にいるから ※おつ
きあい含む

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

=> 大抵がこの部分にあたる
•じゃあ会社の目的は?
9
会社はビジネスで利益をあげたい
•そのなかで…
•Devは価値(サービス)をつくる
•Opsは価値(サービス)を届ける・維持する
•DevもOpsも目標は同じ、だから協力できるはず
10
と、いってもですね。。
ウォーターフォール
この辺開発
この辺構築
Dev
Ops
ウォーターフォール
この辺開発
この辺構築
Dev
Ops
DevやOpsが
ビジネスゴールを縮めるとか…
ウォーターフォール
この辺開発
この辺構築
Dev
Ops
DevやOpsが
ビジネスゴールを縮めるとか…
本当は端から端まで縮めたい
手を出しづらかったりとか
この辺開発
この辺構築
Dev
Ops
手を出しづらかったりとか
この辺開発
この辺構築
Dev
Ops
このへん
SIer
手を出しづらかったりとか
この辺開発
この辺構築
Dev
Ops
このへん
SIer
実は自分が
SIer
と言って
何もしないという選択は無い
とりあえず(大半の人が)
手を出せる範囲で
この辺開発
この辺構築
Dev
Ops
このへんを縮めたり、繰り返したり
できるようになっておきましょうという
ちいさめのDevOps
身の回りの効率化をしておこう
•ビジネスの変化に対応できる(かもしれない)
•ほかでもつぶしが効くように
•あわよくば会社全体のフローに影響を
•継続的なデリバリーとか
•コストの削減とか
•真にDevOpsするには経営陣の理解が必要
•せめて普段からやってないと説得力もない
16
ということを踏まえて(とりあえず)
小さなDevOpsゴールへむけて
ツールによる効率化の
話に進むことにします
Vagrantで環境の共有
使っている方も多いと思います
20
Vagrant概要
•読み:べーぐらんと
•バーチャル環境のフロントエンド
•Dev的には
•アプリケーション環境をローカル依存なしで作成
•Ops的には
•インフラ構築の使い捨てお試し環境
21
DevなVagrant
ローカルマシン
アプリを動かすには環境が必要
23
App Code
ローカルマシン
アプリを動かすには環境が必要
23
App Code
ローカルマシン
アプリを動かすには環境が必要
23
App Code
ローカルマシン
アプリを動かすには環境が必要
23
App Code
•導入手順がバラバラ
ローカルマシン
アプリを動かすには環境が必要
23
App Code
•導入手順がバラバラ
•バージョン ってない
ローカルマシン
アプリを動かすには環境が必要
23
App Code
•導入手順がバラバラ
•バージョン ってない
•それぞれ設定が違う
ローカルマシン
アプリを動かすには環境が必要
23
App Code
•導入手順がバラバラ
•バージョン ってない
•それぞれ設定が違う
•そして…
ローカルマシン
アプリを動かすには環境が必要
23
App Code
•導入手順がバラバラ
•バージョン ってない
•それぞれ設定が違う
•そして…
•ローカルでは(略
ローカルマシン
Vagrantのアプローチ
24
App Code
バーチャルマシンローカルマシン
Vagrantのアプローチ
24
App Code
バーチャルマシンローカルマシン
Vagrantのアプローチ
24
App Code App Code共有
バーチャルマシンローカルマシン
Vagrantのアプローチ
24
App Code App Code共有
Infra Code
バーチャルマシンローカルマシン
Vagrantのアプローチ
24
App Code App Code共有
構成Infra Code
バーチャルマシンローカルマシン
Vagrantのアプローチ
24
App Code App Code共有
構成Infra Code
変更も反映
hubを通して配布
•アプリケーションコードと、動作するプラット
フォームを同じように扱う
•Dev <=> Dev うれしい
25
App Code
Infra Code
App Code
Infra Code
OpsなVagrant
アプリを支えるにはプラットホームが重要
27
検証用サーバ
アプリを支えるにはプラットホームが重要
27
検証用サーバ
アプリを支えるにはプラットホームが重要
27
検証用サーバ
アプリを支えるにはプラットホームが重要
•OSインストール
27
検証用サーバ
アプリを支えるにはプラットホームが重要
•OSインストール
•手作業で試行錯誤
27
検証用サーバ
アプリを支えるにはプラットホームが重要
•OSインストール
•手作業で試行錯誤
•アプリコードを置くのは
ギリギリ
27
検証用サーバ
アプリを支えるにはプラットホームが重要
•OSインストール
•手作業で試行錯誤
•アプリコードを置くのは
ギリギリ
•結局最初に本番環境
27
検証用サーバ
アプリを支えるにはプラットホームが重要
•OSインストール
•手作業で試行錯誤
•アプリコードを置くのは
ギリギリ
•結局最初に本番環境
27
検証用サーバ
App Code ?
アプリを支えるにはプラットホームが重要
•OSインストール
•手作業で試行錯誤
•アプリコードを置くのは
ギリギリ
•結局最初に本番環境
27
検証用サーバ
App Code ?
•クリーンな状態からまた
構築できるの?
Vagrantのアプローチ
28
Vagrantのアプローチ
28
バーチャルマシン
Vagrantのアプローチ
28
バーチャルマシン
Infra Code v0.1
Vagrantのアプローチ
28
バーチャルマシン
構築Infra Code v0.1
Vagrantのアプローチ
28
バーチャルマシン
構築Infra Code v0.1
破棄
Vagrantのアプローチ
28
バーチャルマシン
構築Infra Code v0.1
バーチャルマシン
Infra Code v0.x 構築 App
破棄
Vagrantのアプローチ
28
バーチャルマシン
構築Infra Code v0.1
バーチャルマシン
Infra Code v0.x 構築 App
破棄
破棄
Vagrantのアプローチ
28
バーチャルマシン
構築Infra Code v0.1
Infra Code v1.0
バーチャルマシン
Infra Code v0.x 構築 App
破棄
破棄
Vagrantのアプローチ
28
バーチャルマシン
構築Infra Code v0.1
Infra Code v1.0
バーチャルマシン
Infra Code v0.x 構築 App
バーチャルマシン
構築 App
破棄
破棄
復数の環境に同じコードを適用
•バージョン管理ツールに乗せて、履歴も把握
•いつでもゼロから試せて修正もしやすい
•時間のかかる構築は、スナップショットも使える
29
検証用サーバ
Infra Code v1.0
本番用サーバ
Infra Code v1.0
Dev/Opsで結構類似点が・・
は一旦おいといて
Vagrantの機能
Providers: バーチャル環境を作る先
•お手元系
•Virtualbox、VMWare、Hyper-Vなど
•IaaS系
•OpenStack、Cloudstackなどプライベート
•AWS(EC2)、DigitalOceanなどパブリック
•コンテナ
•Dockerなど
32
※3rdのプラグインを含みます
複数VM、複数NWの構成もOK
33
Public Net
複数VM、複数NWの構成もOK
33
Public Net Public Net
Private Net
Provisioner: VM内の構築
•有名所のプロビジョニング
ツールを実行できる
•説明での『Infra Code』に
あたる部分
34
Provisionerは組み合わせ自由
•まずはShellからはじめるのがオススメ
•複数定義してもOK
•shell-1つめ => chef => shell-2つめ など
•shellから少しづつ他のツールにうつすとか
35
ここまで基本 <=
=> ここから応用
Box
Box = マシンイメージ
•OSをインストールして幾らかVagrant用の設定を
足したもの
• で配布されているのは、ほぼ素のOSインストー
ル直後が多い
•毎回一から作るのは時間かかるというときは、Box
をつくってもよい
38
PackerとBento(Chef)で楽につくれます
39
Share (connect)
ちょっとプレビューして欲しい時
•Vagrantfileのやりとりで済むとはいえ、アプリま
で上げてもらうのはそこそこコストがかかります
41
App Code
Infra Code
App Code
Infra Code
インターネット越しに公開
42
バーチャルマシン
App Code
atlas (旧VagrantCloud)
ブラウザで見た目チェック
SSHで環境チェック
Vagnant機能のまとめ
•いろんな環境に対応可
•複数のバーチャルネットワーク
•複数のバーチャルマシン
•環境の共有は2通り
•Vagrantfileでプロビジョニングコードとまとめて
•Packerでboxに
•プレビューしてもらうならShareも
43
これらをまず確認してから使いましょう
44
(※)書籍の方は書式が古い箇所も
ではVagrantも対応している
プロビジョニングツールから
1つ…
Chef
Chefの概要
•米Chef Software(旧Opscode)の製品
•構成管理(Configration Management)
•インフラの情報を収集・集約

Chef-Server(Zero)/Chef-Repo
•リソース定義の記述から、そのとおりに収束

Chef-Client

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

(※Chef-Provisioning)
48
リソース記述 = レシピ
•リソースの状態を記述(レシピ)して実行すると ?
•対象のリソースが記述と違えば修正
•リソースが記述どおりの状態なら何もしない
49
## nanoがインストールされた状態
package ‘nano’
## nanoがアンインストールされた状態
package ‘nano’ do
action :remove
end
先程のレシピを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)
# ↑ 入ってるのでなにもしない
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)
# ↑ 入っていないのでなにもしない
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)
テンプレートの置換例
53
$ cat sample.erb
hoge is <%= @hoge %>.
template 'sample.txt' do
source 'sample.erb'
local true
variables({ hoge: 'piyo' })
end
ERBテンプレート
テンプレートリソース
テンプレートで文字列を置換
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 %>.
#=>
55
リソースからの階層構造
55
リソース
リソース
リソースからの階層構造
55
レシピ
(x n)
リソース
リソース
リソースからの階層構造
55
レシピ
(x n)
リソース
リソース
その他色々
(x n)
リソースからの階層構造
55
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
リソースからの階層構造
55
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
リソースからの階層構造
55
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
リソースからの階層構造
55
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Roleなど役割記述の
ファイル (option)
リソースからの階層構造
55
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Roleなど役割記述の
ファイル (option)
収集した各種状態の
ファイル (option)
リソースからの階層構造
55
Chef-Repo
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Roleなど役割記述の
ファイル (option)
収集した各種状態の
ファイル (option)
リソースからの階層構造
55
Chef-Repo
Cookbook
+さらにその他色々 => インフラコード一式
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Roleなど役割記述の
ファイル (option)
収集した各種状態の
ファイル (option)
リソースからの階層構造
55
Chef-Repo
Cookbook
+さらにその他色々 => インフラコード一式
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Cookbook
レシピ
(x n)
リソース
リソース
その他色々
(x n)
Roleなど役割記述の
ファイル (option)
収集した各種状態の
ファイル (option)
リソースからの階層構造
Shellとプロビジョニングツールを比べる
56
Shellとプロビジョニングツールを比べる
•OS(ディストリビューション)の違いを結構吸収
56
Shellとプロビジョニングツールを比べる
•OS(ディストリビューション)の違いを結構吸収
•リソースに対する状態がひとまとまりで見やすい
56
Shellとプロビジョニングツールを比べる
•OS(ディストリビューション)の違いを結構吸収
•リソースに対する状態がひとまとまりで見やすい
•違いだけ適用、状況依存の分岐処理記述が少ない
56
Shellとプロビジョニングツールを比べる
•OS(ディストリビューション)の違いを結構吸収
•リソースに対する状態がひとまとまりで見やすい
•違いだけ適用、状況依存の分岐処理記述が少ない
•レシピは間違ってても悪影響が少ない
•Syntaxエラーならそもそも走らない
•ツールがこけても、サーバの状態に変更はない
56
Shellとプロビジョニングツールを比べる
•OS(ディストリビューション)の違いを結構吸収
•リソースに対する状態がひとまとまりで見やすい
•違いだけ適用、状況依存の分岐処理記述が少ない
•レシピは間違ってても悪影響が少ない
•Syntaxエラーならそもそも走らない
•ツールがこけても、サーバの状態に変更はない
•リソース同士の依存が書きやすい => 次へ
56
リソース依存の例
•httpd.conf
•変更したらhttpdをリロードしたい
•変更しなかったら特に何もしない
•レシピでは2通り
•file(template)リソースからserviceリソースに通知
•serviceリソースがfile(template)リソースを監視
57
リソース依存のサンプル
•書きっぱなしで何度実行してもよいのが楽
•事前に変更点のある/なしを折り込まなくてよい
58
service ‘httpd’ do
subscribes :relaod, file[httpd.conf]
end # service => fileを見張る例
file ‘httpd.conf’ do
notifies :relaod, service[httpd]
end # file => serviceに通知の例
(Chef等の)
プロビジョニングツールを
導入するには?
おすすめは2通り
1. 既存のサーバを 変更せず
じわじわレシピにする
例:構築済みのサーバ
•手作業で作成
•たまにコンフィグの修正
62
既存サーバ
App Code
管理用なにか
Chefをいれちゃう
•配布パッケージなら基本
的に影響はない
•`/opt/chef`以下にRuby
含めすべて格納
63
既存サーバ
App Code
管理用なにか
現状リソースをレシピに書き出す
64
既存サーバ
App Code
管理用なにか
現状リソースをレシピに書き出す
64
既存サーバ
App Code
管理用なにか
サービス状態
設定ファイル
ファイルもコピーでOK
現状リソースをレシピに書き出す
64
既存サーバ
App Code
管理用なにか
サービス状態
設定ファイル
ファイルもコピーでOK
why-run(dry-run)で確認しつつ
実行(特に何も変わらない)
現状リソースをレシピに書き出す
64
既存サーバ
App Code
管理用なにか
サービス状態
設定ファイル
ファイルもコピーでOK
why-run(dry-run)で確認しつつ
実行(特に何も変わらない)
※繰り返し
Cookbook完成、リポジトリへ
65
既存サーバ
App Code
管理用なにか
Cookbook
レシピ
テンプレート
レシピ
じわじわレシピの要約
66
じわじわレシピの要約
•サーバにあるリソースをレシピに書いて実行する
66
じわじわレシピの要約
•サーバにあるリソースをレシピに書いて実行する
•Chefは未定義の属性を変更しないので雑でもOK
•ファイルならownerとか、permission
66
じわじわレシピの要約
•サーバにあるリソースをレシピに書いて実行する
•Chefは未定義の属性を変更しないので雑でもOK
•ファイルならownerとか、permission
•VagrantのProvisioningもこの手法で色々つくれる
66
じわじわレシピの要約
•サーバにあるリソースをレシピに書いて実行する
•Chefは未定義の属性を変更しないので雑でもOK
•ファイルならownerとか、permission
•VagrantのProvisioningもこの手法で色々つくれる
•欠点
•さすがにまあまあ事故りやすい
•見落としもありがち (cron等単品ファイルとか)
66
2. 状態テストを活用する
68
Serverspec?
•サーバの状態をテストするツール
•元々はプロビジョニングツール用コードのリファ
クタリングのために開発
•(手作業を含む)プロビジョニング手順の最適化とし
て利用する
69
例:構築済みのサーバ
•手作業で作成
•たまにコンフィグの修正
•※ここまでは同じ
70
既存サーバ
App Code
管理用なにか
まずServerspecのテストを作る
•SSH越しでテスト
•サーバ側に一切変更不要
71
既存サーバ
App Code
管理用なにか
現状確認なのでオールグリーン
テストしながら空のサーバでレシピを作成
72
バーチャルマシン
テストしながら空のサーバでレシピを作成
72
バーチャルマシン
レシピ
テンプレート
レシピ
※レシピ書いて実行の繰り返し
テストしながら空のサーバでレシピを作成
72
バーチャルマシン
レシピ
テンプレート
レシピ
※レシピ書いて実行の繰り返し
※オールグリーンまで繰り返し
状態テストからレシピの要約
73
状態テストからレシピの要約
•先にテストを書く
73
状態テストからレシピの要約
•先にテストを書く
•テストが通る = サーバの状態が再現できている
73
状態テストからレシピの要約
•先にテストを書く
•テストが通る = サーバの状態が再現できている
•テストはプロビジョニングツールに依存しない
•使いまわせる
•構成管理ツールの導入をあきらめてもテストは
残る
73
状態テストからレシピの要約
•先にテストを書く
•テストが通る = サーバの状態が再現できている
•テストはプロビジョニングツールに依存しない
•使いまわせる
•構成管理ツールの導入をあきらめてもテストは
残る
•Opsは特にこちらの手法がよい
73
レシピの保守はTest-Kitchen
•任意のProvisioner、任意のテストスイート
•テストに向いたライフサイクル
•なにかのビルドにも応用
74
いろいろ踏まえて、
改めてDevOpsの話
DevとOpsで同じツール
•Vagrant, Chef等はどちらの立場でもつかえる
•設定ファイルやインフラコードの相互乗り入れ
76
App Code
Infra Code
クラウドリソースはAPI
77
クラウドリソースはAPI
•調達&廃棄が容易なので
77
クラウドリソースはAPI
•調達&廃棄が容易なので
•開発初期から並行環境で稼働できる
77
クラウドリソースはAPI
•調達&廃棄が容易なので
•開発初期から並行環境で稼働できる
•環境構築をコードにして、素早く何度も作れる
ようにする
77
クラウドリソースはAPI
•調達&廃棄が容易なので
•開発初期から並行環境で稼働できる
•環境構築をコードにして、素早く何度も作れる
ようにする
•あとからコードにする事もなんとかなる
77
例:クックパッドのCodenize.tools
•既存AWS(ほか)リソースを

コード運用に転換する
•ツール開発でDevとOpsを

半ば強引に結合
78
例:クックパッドのCodenize.tools
•既存AWS(ほか)リソースを

コード運用に転換する
•ツール開発でDevとOpsを

半ば強引に結合
78
2/24発売
ウォーターフォール(再)
この辺開発
この辺構築
Dev
Ops
ウォーターフォール(再)
この辺開発
この辺構築
Dev
Ops
Dev&Ops
ここを回す
ウォーターフォール(再)
この辺開発
この辺構築
Dev
Ops
ここの時間は縮まらないかも・・
けど質はあがる
Dev&Ops
ここを回す
Devは
80
Devは
•開発以降の環境に興味をもとう
•Vagrantで共有し、ローカル番長をやめよう
•インフラの知識も少し探ろう
80
Devは
•開発以降の環境に興味をもとう
•Vagrantで共有し、ローカル番長をやめよう
•インフラの知識も少し探ろう
•シェアする仕組み、範囲を絞ろう
80
Devは
•開発以降の環境に興味をもとう
•Vagrantで共有し、ローカル番長をやめよう
•インフラの知識も少し探ろう
•シェアする仕組み、範囲を絞ろう
•デプロイメントが楽になる仕掛けやサービスを色々
使おう
•Opsに要望しよう (そうしないとNoOpsに走る)
80
例:VCCW
•WordPress環境を

チームで共有
•gitで交換
•Chef, Vagrantfileで

環境別カスタマイズ
•作成者はphp中心の

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

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

(※そのまま利用も可)
•Devはユーザと捉えよう
82
例:Dokku
•Dockerを使ったミニheroku
•Devのコードを好きなだけすぐ動かせる
83
Dev&Opsで
CIツールを一緒に使おう
•テスト
•コードレビュー
•デプロイメント
85
Provisionig(ほか)ツール選定
•Devのアプリと同じ言語のツールをまず触るとよ
いです (※かなり個人的な見解です)
•ツールチェーン
•アプリのコードも読める(ようになる)
•基本どれも汎用的に使えるので応用がききます
86
迷ったら(一応)
DevOpsのゴールを思い出して
おわりに...
(※開発環境改め)DevOpsのアプローチと
クラウド/バーチャル環境/構成管理ツール
のお話
終
オープンセミナー2015@広島
『クラウド時代の構成管理入門』
Feb. 14. 2015

DevOpsのアプローチと クラウド/バーチャル環境/構成管理ツール のお話