ChefとCapistranoの境界線 (Chef Casual Talks Vol.1) #eytokyo #opschef_ja

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

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

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

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

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

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

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

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