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

(※開発環境改め)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

•導入手順がバラバラ•バージョン揃ってない•それぞれ設定が違う•そして…•ローカルでは（略


Vagrantのアプローチ

24

App Code

バーチャルマシンローカルマシン


24

App Code



24

App Code App Code共有



24


Infra Code



24


構成Infra Code



24


構成Infra Code

変更も反映

hubを通して配布•アプリケーションコードと、動作するプラットフォームを同じように扱う

• Dev <=> Dev うれしい

25

App Code

Infra Code

App Code

Infra Code

OpsなVagrant

アプリを支えるにはプラットホームが重要

27

検証用サーバ

アプリを支えるにはプラットホームが重要•OSインストール

27

検証用サーバ

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

27

検証用サーバ

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

27

検証用サーバ


•結局最初に本番環境

27

検証用サーバ



27

検証用サーバ

App Code ?



27

検証用サーバ

App Code ?

•クリーンな状態からまた構築できるの？


28


28

バーチャルマシン


28

バーチャルマシンInfra Code v0.1


28

バーチャルマシン構築Infra Code v0.1


28


破棄


28


バーチャルマシンInfra Code v0.x 構築 App

破棄


28



破棄

破棄


28


Infra Code v1.0


破棄

破棄


28


Infra Code v1.0


バーチャルマシン構築 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 = マシンイメージ•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機能のまとめ•いろんな環境に対応可 •複数のバーチャルネットワーク •複数のバーチャルマシン •環境の共有は２通り • Vagrantfileでプロビジョニングコードとまとめて • Packerでboxに

•プレビューしてもらうならShareも

43

これらをまず確認してから使いましょう

44

(※)書籍の方は書式が古い箇所も

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

１つ…

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 :removeend

先程のレシピをChef-Applyでとりあえず実行

50

$ echo "package 'nano'" | sudo chef-apply -sRecipe: (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 -sRecipe: (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 -sRecipe: (chef-apply cookbook)::(chef-apply recipe) * apt_package[nano] action remove - remove package nano# ↑ 入っているのでアンインストール

$ echo "package 'nano' do action :remove end" | sudo chef-apply -sRecipe: (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)




55

Cookbook

レシピ (x n)



Cookbook

レシピ (x n)




55

Cookbook

レシピ (x n)



Cookbook

レシピ (x n)



Cookbook

レシピ (x n)




55

Cookbook

レシピ (x n)



Cookbook

レシピ (x n)



Cookbook

レシピ (x n)



Roleなど役割記述のファイル (option)


55

Cookbook

レシピ (x n)



Cookbook

レシピ (x n)



Cookbook

レシピ (x n)




収集した各種状態のファイル (option)


55

Chef-RepoCookbook

レシピ (x n)



Cookbook

レシピ (x n)



Cookbook

レシピ (x n)






55

Chef-RepoCookbook

+さらにその他色々 => インフラコード一式

レシピ (x n)



Cookbook

レシピ (x n)



Cookbook

レシピ (x n)






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

管理用なにか



why-run(dry-run)で確認しつつ実行(特に何も変わらない)


64

既存サーバ

App Code

管理用なにか



why-run(dry-run)で確認しつつ実行(特に何も変わらない)

※繰り返し

Cookbook完成、リポジトリへ

65

既存サーバ

App Code

管理用なにか Cookbook

レシピテンプレート

レシピ

じわじわレシピの要約

66

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

66

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

66


• VagrantのProvisioningもこの手法で色々つくれる

66


• VagrantのProvisioningもこの手法で色々つくれる•欠点 •さすがにまあまあ事故りやすい •見落としもありがち (cron等単品ファイルとか)

66

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

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等はどちらの立場でもつかえる •設定ファイルやインフラコードの相互乗り入れ

76App 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


•シェアする仕組み、範囲を絞ろう

80


•シェアする仕組み、範囲を絞ろう•デプロイメントが楽になる仕掛けやサービスを色々使おう • Opsに要望しよう (そうしないとNoOpsに走る)

80

例：VCCW•WordPress環境をチームで共有

• gitで交換 • Chef, Vagrantfileで環境別カスタマイズ

•作成者はphp中心のWordpressなDev

81

Opsは

82

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

82


•VMやクラウドを活かして、開発初期からインフラを詰めてく、アプリも開発中からとにかくデプロイしていく

82



•ツールのエラーは読もう

82



•ツールのエラーは読もう•XaaSは商売敵、使って手法を学ぼう (※そのまま利用も可)

82



•ツールのエラーは読もう•XaaSは商売敵、使って手法を学ぼう (※そのまま利用も可)

• Devはユーザと捉えよう82

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

83

Dev&Opsで

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

85

Provisionig(ほか)ツール選定•Devのアプリと同じ言語のツールをまず触るとよいです (※かなり個人的な見解です) •ツールチェーン •アプリのコードも読める(ようになる)

•基本どれも汎用的に使えるので応用がききます

86

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

おわりに．．．

(※開発環境改め)DevOpsのアプローチとクラウド/バーチャル環境/構成管理ツール

のお話

終オープンセミナー2015@広島

『クラウド時代の構成管理入門』

Feb. 14. 2015

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

Technology

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