CapistranoでVagrantにデプロイした際、なぜか設定したはずの環境変数が適用されなかった。それはserviceコマンドの挙動が原因だった。という話です。

経緯

おなじみRailscasts#335で紹介された方法で、いったんデプロイには成功した。

しかしその後、Raiscasts#337を参考にconfig/recipesにCapistranoの設定を分割してからVagrantで作った環境にデプロイしたところ、環境変数が読み込まれなかった。

大問題である。

環境変数には、他人には見られたくないAmazon S3のパスワードなどが入っている。asset_syncやfogを使っているので、アプリケーションにはどうしても環境変数の設定が必要。これらを本番環境で動くサーバにセットせねばならない。

選択肢として、application.ymlにS3のパスワードなどを書いて、本番環境に置くという方法もある。だができれば本番環境上で作業したくない。全部Capistranoですませたい。どうすればよいか？

余談

ちなみに、複数サーバにCapistranoでデプロイするのはとても簡単。GithubのCapistrano Wikiにやり方が書いてある。
https://github.com/capistrano/capistrano/wiki/2.x-Multistage-Extension
以前はプラグインとして提供されていたらしいcapistrano-extはすでにcapistrano内に入っている。 なので、

set :stages, %w(production vagrant)
set :default_stage, "vagrant"
require "capistrano/ext/multistage"

とするだけで、複数ステージにデプロイ可能。

config/deployディレクトリを作って

server "1xx.xxx.xxx.xx", :web, :app, :db, primary: true
set :user, "katryo"
set :port, 10022 #22から変更した
set :deploy_to, "/home/#{user}/apps/#{application}"

server "localhost", :web, :app, :db, primary: true
set :user, "vagrant"
set :port, 2222
set :deploy_to, "/home/#{user}/apps/#{application}"

ssh_options[:keys] = [
  "#{ENV['HOME']}/.ssh/id_rsa",
  "#{ENV['HOME']}/.vagrant.d/insecure_private_key"
]

とdeployディレクトリに各サーバの設定を別々に書けばよい。参考:
http://d.hatena.ne.jp/okinaka/20120520/1337476743

set :deploy_toが重複していて気持ち悪いけど、読み込みのタイミング上、production.rbとvagrant.rbのuserが読み込まれてからdeploy_toを設定する必要があるのでしかたなく2回同じ文を書いた。

設定したはずの環境変数がなぜ適用されない？

Capistranoでは、

ENV.update YAML.load(File.read(File.expand_path('../application.yml', __FILE__)))
set :default_environment, {
  "AWS_ACCESS_KEY_ID" => ENV["AWS_ACCESS_KEY_ID"],
  "AWS_SECRET_ACCESS_KEY" => ENV["AWS_SECRET_ACCESS_KEY"]
}

のように:default_environmentにsetすれば、シェルスクリプトを実行するrunの際に環境変数をセットできる。だから、開発環境の環境変数を引き継いで実行できる……はずだ。

この記事の環境変数の項でもそれについては説明した。 http://qiita.com/items/f410916d5314dad2de96

実際に、前回のデプロイでは環境変数の引き継ぎに成功した。なぜ今回に限って引き継ぎに失敗するのか？

前回の手法をもういちど試したところ、引き継ぎには成功。
前回と今回の違いはどこか？　recipesにCapistranoの設定を分割したことか？　色々考え、調べたところ、原因が判明した。

原因

# storyblogはアプリケーション名
$ service unicorn_storyblog start

が原因だった。

service hoge startは環境変数をほぼ引き継がない!!!

serviceで起動した場合、環境変数はLANG, PATH, TERMの3つだけを適用する、らしい。"service /etc/init.d 違い"あたりで検索したところ、情報がいろいろ出てきた。

これらの記事を参考。
http://d.hatena.ne.jp/amari3/20111223/1324656530
http://linux.just4fun.biz/?%E9%80%86%E5%BC%95%E3%81%8DUNIX%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%2F%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9(%E3%83%87%E3%83%BC%E3%83%A2%E3%83%B3)%E3%81%AE%E8%B5%B7%E5%8B%95%E3%83%BB%E5%86%8D%E8%B5%B7%E5%8B%95%E3%83%BB%E5%81%9C%E6%AD%A2%E3%83%BB%E7%8A%B6%E6%85%8B%E5%8F%96%E5%BE%97

解決方法

なので、Raiscasts#337のCapistrano設定コードを書きかえ、

run "service unicorn_#{application} #{command}"

となっている箇所を

run "/etc/init.d/unicorn_#{application} #{command}"

と書きかえ。

nginxに関しても

run "#{sudo} service nginx #{command}"

となっているところを

run "#{sudo} /etc/init.d/nginx #{command}"

と書きかえた。

$ capistrano vagrant unicorn:stop
$ capistrano vagrant unicorn:start

としたら、見事環境変数を読み込んでくれた。やった！！！！ 半日悩んだ問題が解決した。

ちなみに最後のunicorn停止と起動に関して、再起動の

$ capistrano vagrant unicorn:restart

ではダメだった。Unicornはrestartの際、環境変数を引き継いで再起動するらしいのでそれが原因……なのかも。

ちょっと違うけど、参考。/etc/init.dからの起動時に環境変数を指定する方法 http://qiita.com/items/83bb3fb5cb7f46484d4b