- 更新日: 2014年10月20日
- Rails
Capistrano デプロイでエラー
運用中の Rails アプリケーションにおいて、Capistrano デプロイでエラーに遭遇しました。production 環境へのデプロイ中にエラーが発生すると、めちゃくちゃ焦りますね…。
デプロイ先のディレクトリ・ファイル構造は以下の通りです。（見やすく省略してます）
|
1 2 3 4 5 6 7 8 |
$ ls -la lrwxrwxrwx. current -> /path/to/project/releases/2014****** drwxr-xr-x. releases drwxr-xr-x. repo -rw-r--r--. revisions.log drwxr-xr-x. shared |
— 環境 —
rails 4.1
capistrano 3
画像付き英語辞書 Imagict | 英単語をイメージで暗記Capistrano でのデプロイで以下のエラーが発生
Capistrano でいつも通りデプロイを行っていたら、突然エラーが起こりまして中断。その後、ssh でサーバーにログインして調査したところ、releases/2014******/tmp/cache というフォルダが、デプロイする度に何度も自動的に作成されていました。キャッシュファイルが作られすぎ？！結局原因は不明で分かりませんでした。
おそらくこれが原因のせいで、unicorn のエラーログを見たところ「secret_key が見つかりません」のエラーメッセージが繰り返し出力されており、ちゃんと production 用の secret_key は設定してあるにもかかわらず、production 環境での Rails アプリケーションが真っ白になる現象。
参考： Rails が production 環境で真っ白、SECRET_KEY_BASE 設定忘れが原因でした | EasyRamble
解決策
最終的に以下の方法で解決させました。
1. 一旦サーバーを再起動
2. デプロイ用ディレクトリの releases/, repo/, revisions.log をバックアップ
3. その後、デプロイ用ディレクトリの shared 以外のフォルダ・ファイルを全て削除
4. デプロイを最初からやり直し
これで一応復旧して、releases/2014******/tmp/cache が自動で作成されることもなくなりました。ちょっと力技での復旧ですけど、とにかく稼働させることを優先しまして。shared ディレクトリは残しておかないと、デプロイ時に再び bundle install が走っちゃうので、復旧に時間がかかります。
キャッシュが多すぎたのが原因だろうか…。よく分かりませんのでもう少し調査してみます。一応上記手順で、力技ながら復旧できることが分かったので、経験値は上がりました（笑）。一旦キャッシュファイルも削除、Rails によるキャッシュも無効にして様子見です。
- Rails の関連記事
- RailsでMySQLパーティショニングのマイグレーション
- Rails ActiveRecordでdatetime型カラムのGROUP BY集計にタイムゾーンを考慮する
- RailsプラグインGemの作成方法、RSpecテストまで含めたrails pluginの作り方
- RailsでAMPに対応するgemをリリースしました
- Railsでrequest.urlとrequest.original_urlの違い
- Railsでwheneverによるcronバッチ処理
- Google AnalyticsのRails Turbolinks対応
- Railsアプリにソーシャル・シェアボタンを簡単設置
- Rails監視ツール用にErrbitをHerokuで運用
- Facebook APIバージョンのアップグレード手順(Rails OmniAuth)
Leave Your Message!