light log

学んだこととか

Railsのproduction環境のDB周りの謎が解決?した

昨日の問題が解決?した。

はてなを付けてるのは、一応の対策はわかったけど理由がよくわからんから。

昨日↓の記事

yamacent.hatenablog.com

対策

昨日以下のようにしてたところを、

$ bin/rake db:migrate RAILS_ENV=production

このように変えれば動いた。

$ rake db:migrate RAILS_ENV=production

要はbin/rake -> rake

疑問

springについて知ってから、

yamacent.hatenablog.com

rake, railsの実行にはbin/を付けてたんだけど、今回の場合これが問題だったようだ。なぜなのかは分からない。挙動を見る限りはbin以下のbinstub実行時には環境変数がうまく読み込まれていないように見えるけれど。

それから、rails cしたときにも、実行の仕方によってDBのコネクション成否が異なるようなんだけど、これがrake db:migrateのときと方則性が違ってもはや何が何だかさっぱりわからない。

昨日bin/rake db:createは成功してた理由もよくわからない。

とりあえず、rails crake db:migrateを実行したときの成否パターンを以下にまとめてみた。

これら2つに対して、

  • bin/を付ける
  • bundle execを付ける
  • 何も付けない

のそれぞれに

  • RAILS_ENV=productionを前に付ける
  • RAILS_ENV=productionを後ろに付ける

というパターンを試した。

環境は昨日と同じ。

rails console

失敗するケース

$ rails c RAILS_ENV=production
$ bin/rails c RAILS_ENV=production
$ bundle exec rails c RAILS_ENV=production

成功するケース

$ RAILS_ENV=production rails c
$ RAILS_ENV=production bin/rails c
$ RAILS_ENV=production bundle exec rails c

まとめると、RAILS_ENV=productionが前にあると成功、後ろにあると失敗する。rails, bin/rails, bundle exec railsは関係なし。

あと、ここでの「成功」はエラーが出ずにコンソールが起動することを言ってる。そこでDBにアクセスしようとするとエラーになったケースもあったような気がする。。

rake db:migrate

失敗するケース

$ bin/rake db:migrate RAILS_ENV=production
$ RAILS_ENV=production bin/rake db:migrate

成功するケース

$ rake db:migrate RAILS_ENV=production
$ RAILS_ENV=production rake db:migrate
$ bundle exec rake db:migrate RAILS_ENV=production
$ RAILS_ENV=production bundle exec rake db:migrate

まとめると、rake, bundle exec rakeは成功、bin/rakeは失敗する。RAILS_ENV=productionの前後は関係なし。

まとめ

こういう結果になる理由が全然わからなくてものすごく気持ち悪いんだけど、今はこれ以上深堀りせず先に進むことにする。

これは後でレベルが上がってから振り返ったらなんてことなく理解できるパターンのような気がする。

疲れた。