読者です 読者をやめる 読者になる 読者になる

プログラミング 美徳の不幸

Ruby, Rails, JavaScriptなどのプログラミングまとめ、解説、備忘録。

Railsのステージング環境を構築③(関連プロセスのリスタート)

前回までで、Capistrano側からunicornの再起動ができるところまで行きました。

Railsアプリは他にも、各種のプロセスを同時に立ち上げることが多いです。当たり前ですがnginxの再起動は不要です。APサーバ上で動くもので必要なものをリスタートさせると良いです。

特に、私はdelayed_jobという遅延処理のgemを使っているのですが、これは別プロセスをたちあげてそちらに処理を委譲する構造なのでデプロイ時にリスタートさせないといけません。

あと、wheneverというgemは、rails側でcronの登録をするもので、これもデプロイ時にcronの再設定をかけてくれると助かります。

それらの設定を書くと、こういうふうになります。
◯config/deploy.rb

set :whenever_command, "bundle exec whenever"
require 'whenever/capistrano'

#==========
#delayed_job
#cap (staging|production) delayed_job (restart|start|stop)
#==========
namespace :delayed_job do
  desc "Restart the delayed_job process"
  [:restart,:start,:stop].each do |cmd|
    task cmd, :roles => :app do
      run "cd #{current_path}; RAILS_ENV=#{rails_env} script/delayed_job #{cmd.to_s}"
    end
  end
end


after "deploy:update_code" ,"delayed_job:restart"


require 'capistrano-unicorn'

ポイントとして、delayed_jobのほうはタスクとして独自定義しています。
一方で、wheneverのほうはwhenever自身でcapistranoに対応するライブラリを持っているようで、これをrequireすればとくに意識することなく使用できます。



ここまで設定すると、初回デプロイから定期的デプロイまでスムーズに行くはずなんですが、一箇所確認している問題があります。
手順としては
cap staging deploy:setup
=>これでデプロイ先にディレクトリを作ってくれる
このときにreleaseやshareが入っているアプリのディレクトリをls -lで見ると所有者がrootになっている。
しかし私はすべてadminで作業したいので、これはいちいち
sudo chown -R admin.admin <アプリ名>
のようなことをしないとならない。

ま、おそらくさくっと解決するし、しないなら無理やりタスクとして定義しちゃえばいいんですが、問題意識としてはちょっと運用がわからないのであれだけど、このsetupているの?という点。
実はEC2のAMIを作成したときにAPサーバにすでに上のアプリディレクトリをもたせているので、APサーバを増やすときにはすでにsetupされている状態・・・。


だから、今これでいいのかと思っているのはcapistranoの設定とかよりは、AMIの作成ですでに含ませる情報/含ませない情報の境界、という感じですか。。。