ChefとCapistranoの境界線 @ Chef Casual Talks Vol.1

1. ChefとCapistranoの境界線
Chef
Casual
Talks
Vol.1
Aki
/
@nekoruri

2. あらすじ
• ウェブサイトリニューアル
– Ruby
on
Rails
– 一部Movable
Type
+
PHP動的生成
– 2台でホットスタンバイ
• エンジニア的裏テーマ
– Chefでやる
– chef-­‐soloでやる

3. 基本ポリシー
1. 原則サーバ上で作業しない
2. 公開されたcookbooksを再利用する
– opscode-­‐cookbooksにあればそれを探す
– communityやgithubにあるcookbookを使う
3. あきらめの心を持つ
– 変更ならば公開cookbooksにも手を入れる
– 半日調べて難しそうなことはあきらめて手作業

4. 結果
• そんなに難しくない
– パッケージ入れたい？→recipeに書く
– 動作を少し変えたい？→aHributesを探す
– 設定ファイルを編集したい？→templatesに書く
• chef-­‐soloでの問題もあまり無い
– chef-­‐soloのdata_bags対応
– edelight/chef-­‐solo-­‐search

5. 本題
• プログラム本体のデプロイ
– 元々はCapistranoで普通にデプロイ
– 自前で用意したinit.d
scriptを手で設置
– Chefでどこまでやれるか/やるべきか
• 「サーバ構築」と「デプロイ」の境界線
– Unicornプロセスの管理
– レポジトリからのソースコード取得

6. 試行錯誤の歴史
1. opscode-­‐cookbooks/applicaKon_ruby
– レポジトリは社内からしかアクセス出来ない
– database.ymlが自動生成になる→嫌
2. runit_serviceだけ使う
– CapistranoのrootまでをChefで生成
– Unicornの自動起動をrunit管理
– Unicornのgraceful
restartで問題あり（未調査）
3. Chefではなにもしない ←イマココ

7. 補足
• 最終的に、Chefでは以下を管理
– Capistrano
rootディレクトリの作成
– 各種ログディレクトリの作成
– ログファイルlogrotateの設定ファイル
– 昔ながらのinit.d
script配布
– MySQLのデータベース/ユーザ作成
• 鶏と卵問題
– Unicornがデプロイ時のbundle
installで入る
→ 一度デプロイされないとUnicornが存在しない
– 空のRailsプロジェクトをgithubに用意してダミーデプロイ
– Unicorn管理を諦めたので最終的には未使用

8. 質問
• Chefでどこまでやっていますか？
– アプリケーションの初回デプロイ
– APサーバ(Unicorn等)のプロセス管理
• ハッシュタグ等でご意見ください
– #opschef_ja
とか