Chef Casual Talks Kansai vol.3で話した時の資料

1. MarketPlaceのAMIを
Packerで作る時、
Chefは3度配膳する
!
(※公開版スライド)
Chef Casual Talks Kansai vol.3
Jun 11 2014
with Tokyo,Sapporo

2. 本スライド案内
• 6/11に行ったChef Casual Talks Kansai
vol3の資料から、Chef書籍のくだりをカッ
トした本編のみ版
2

3. 3

4. AWS Marketplace
• なにかしらアプリ入りのAMIを販売
• 通常のEC2従量課金に＋(細々とした)ライ
センス料
• ぽちっと押したらEC2でアプリ入りサーバ
• それなりのセキュリティ要件がある
• ※だいたいこれのせいで面倒
=> 今日の話に
4

5. Packer
5

6. Packer?
• VagrantのHashCorp製
• イメージ作成自動化ツール
• 作成できるイメージの対象プロバイダは様々
6

7. Packerの構築パート
• Provisioners
• まあVagrantと同じっす
• 複数回指定OK
• 『Shell => Shell => Chef => Shell』
のようなことも。
7

8. Marketplace用AMI
• インスタンスオーナーは不特定多数
• 構築時の情報を残しちゃ駄目
• ログ、History、公開
• アプリは、共通デフォルトパスワード駄目
• 起動時に自動生成せよ(例：インスタンスID)
• 大体のアプリは、初回起動時に色々初期化しな
いとイカン
• 特にこれが面倒
8

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

10. Provision by chef 1/3
• Packerからprovisioner[chef-solo]
• パッケージやらの下地・ミドルウェアの設定など
• 後で必要ならOhaiのプラグインとか
• リソース間の依存関係が面倒なものは…
• テンプレートから、次のレシピを出力
• 継続実行・運用するもんでは無いので、割り切る
• AMI起動時の初期化に対応するため。。
• テンプレートから、初回起動時のレシピを出力
• ↑cron @rebootに仕込む
10

11. Provision by chef 2/3
• 2パターン
• 事前に用意してあるレシピから、別のランリスト
でchef-solo
• 1/3が出力したレシピをchef-applyで実行
• 依存関係が面倒な例
• 展開したtarの中にインストーラがあるとか
• Ohaiのプラグインを置いてリロード必須のリソー
スとか
• 最後にHistoryの掃除等、shell provisionerで仕上げ
11

12. Provision by chef 3/3
• 1/3で設置したレシピが対象
• cron @reboot で chef-apply
• ミドルウェア調整(※必要な場合)
• template の`local true`がラク
• アプリの初期化
• アプリデフォルトパスワードをインスタン
スidとしてセット
• Seppuku (しない場合もある)
12

13. 図解
13
!
時系列
下ごしらえ
chef-solo
AMIのオーナーは他者AMIのオーナーは自分
前提が面倒な
chef-solo
/ chef-apply
起動時に決定される
情報を元に
chef-apply
アプリ提供！
!AMI
Packer時代 放逐時代

14. 最後に補足
• インフラコードのIdempotence(冪等性)
• 何度実行してもOKってのもあるけど。。
• 言い出しっぺの主張は
『必要な時に一度だけ実行』が主
14

15. おわり