marketplaceのamiをpackerで作る時、 chefは3度配膳する
DESCRIPTION
Chef Casual Talks Kansai vol.3で話した時の資料TRANSCRIPT
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
おわり