heroku cedar にデプロイされた grails アプリがあり、アプリの起動に 60 秒以上かかり、herokuによると:
Web プロセスが、割り当てられた $PORT にバインドするのに 60 秒以上かかりました。これが発生すると、dyno のプロセスが強制終了され、dyno がクラッシュしたと見なされます。
可能な限り依存関係を減らしましたが、起動に 60 秒以上かかる場合があるため、アプリは heroku によって停止されます。
これを回避する方法を知っていますか？
質問する
968 次
3 に答える
4
この問題に対する優れた解決策があります。Grails ビルドパックをフォークし、Jetty を$PORTアーリーに強制的にバインドするコードを少し追加して、Grails の起動に必要な時間を常に確保できるようにしました。Grails の起動時に、リクエストは単に 404 エラーで失敗しますが、少なくともアプリは確実に起動します。
https://github.com/funfork/heroku-buildpack-grails-earlybind
使用するには:
heroku config:set BUILDPACK_URL=https://github.com/funfork/heroku-buildpack-grails-earlybind
また、スラッグの再コンパイルを強制する必要がある場合 (最初に保留中のコミットがないことを確認してください):
git commit --allow-empty -m "empty commit"
git push heroku master
そして、どうぞ！
于 2013-05-10T06:04:02.263 に答える
1
Grailのアプリでも同じことを経験しました。アプリの 1 つが正しく起動しましたが、依存関係の構成は非常に似ていましたが、別のアプリをデプロイしたところ、この問題が発生しました。
BuildConfig.groovy (jquery、jquery-ui、twitter-bootstrap、lesscss-resources) のいくつかの js プラグインを削除し、このリソースを手動で追加することで解決しました。
ローカルでは、これによりブート時間が 20 秒から 13 秒に短縮されました (常に最初のブートについて話しますが、インタラクティブ モードでは、後続のブートは非常に高速です)。テーブルの作成と削除、および一部のデータのブートストラップも行っていることを考慮してください。ただし、言及されたプラグインを削除するまで、これを回避しても問題は解決しませんでした。
すべてのプラグインを使用して、私の他のアプリが heroku で時間内に開始する方法も興味深いです。
于 2013-04-23T04:52:59.287 に答える