marketplaceのamiをpackerで作る時、 chefは3度配膳する

MarketPlaceのAMIをPackerで作る時、 Chefは3度配膳する

!

(※公開版スライド) Chef Casual Talks Kansai vol.3

Jun 11 2014 with Tokyo,Sapporo

本スライド案内• 6/11に行ったChef Casual Talks Kansai

vol3の資料から、Chef書籍のくだりをカットした本編のみ版

2

3

AWS Marketplace• なにかしらアプリ入りのAMIを販売

• 通常のEC2従量課金に＋(細々とした)ライセンス料

• ぽちっと押したらEC2でアプリ入りサーバ

• それなりのセキュリティ要件がある

• ※だいたいこれのせいで面倒=> 今日の話に

4

Packer

5

Packer?• VagrantのHashCorp製

• イメージ作成自動化ツール

• 作成できるイメージの対象プロバイダは様々

6

Packerの構築パート• Provisioners

• まあVagrantと同じっす

• 複数回指定OK

• 『Shell => Shell => Chef => Shell』のようなことも。

7

Marketplace用AMI• インスタンスオーナーは不特定多数

• 構築時の情報を残しちゃ駄目

• ログ、History、公開鍵

• アプリは、共通デフォルトパスワード駄目

• 起動時に自動生成せよ(例：インスタンスID)

• 大体のアプリは、初回起動時に色々初期化しないとイカン

• 特にこれが面倒

8

で、都合三回Chef実行 にしたことがある

Provision by chef 1/3• Packerからprovisioner[chef-solo]

• パッケージやらの下地・ミドルウェアの設定など

• 後で必要ならOhaiのプラグインとか

• リソース間の依存関係が面倒なものは…

• テンプレートから、次のレシピを出力

• 継続実行・運用するもんでは無いので、割り切る

• AMI起動時の初期化に対応するため。。

• テンプレートから、初回起動時のレシピを出力

• ↑cron @rebootに仕込む

10

Provision by chef 2/3• 2パターン

• 事前に用意してあるレシピから、別のランリストでchef-solo

• 1/3が出力したレシピをchef-applyで実行

• 依存関係が面倒な例

• 展開したtarの中にインストーラがあるとか

• Ohaiのプラグインを置いてリロード必須のリソースとか

• 最後にHistoryの掃除等、shell provisionerで仕上げ

11

Provision by chef 3/3• 1/3で設置したレシピが対象

• cron @reboot で chef-apply

• ミドルウェア調整(※必要な場合)

• template の`local true`がラク

• アプリの初期化

• アプリデフォルトパスワードをインスタンスidとしてセット

• Seppuku (しない場合もある)

12

図解

13

!

時系列

下ごしらえ chef-solo

AMIのオーナーは他者AMIのオーナーは自分

前提が面倒な chef-solo

/ chef-apply

起動時に決定される 情報を元に chef-apply

アプリ提供！!AMI

Packer時代 放逐時代

最後に補足• インフラコードのIdempotence(冪等性)

• 何度実行してもOKってのもあるけど。。

• 言い出しっぺの主張は『必要な時に一度だけ実行』が主

14

おわり