4

将来、アプリケーションを透過的にアップグレードするために、同じ Play アプリケーションの 2 つのインスタンスを実行しようとしています。

最初のインスタンスを起動すると、明らかにすべてがうまくいきます。ポート 9525 でアプリケーションの 2 番目のインスタンスを起動するstart 9525コマンドを起動すると、次のエラーが発生します。

Play server process ID is 8909
This application is already running (Or delete .../RUNNING_PID file)

これを回避する方法はありますか？

4

1 に答える 1

6

この Play のドキュメントでは、「透過的なアップグレード」のための Apache の使用について既に説明しています。一般に、2 つの別々のフォルダーで 2 つのインスタンスを開始する必要があります

はじめに:

  1. distアプリのソースを使用して、フォルダー内にパッケージを作成します
  2. それをいくつかのサブフォルダーに解凍します。instance1
  3. instance1例として、目的のポートで開始し9998ます。これは毎日のインスタンスになります

変更後、透過的にアプリを再デプロイする場合:

  1. 変更をサーバーにプッシュします (バージョン管理システム、つまり git を使用していると仮定します)。
  2. それを作成して他のフォルダーdistに解凍します。instance2
  3. 他のポートで起動します。9999
  4. フォルダ内のアプリケーションを停止instance1
  5. 解凍したディストリビューションをコピーinstance2するinstance1
  6. でアプリケーションを開始し、でアプリケーションinstance1を停止しますinstance2
  7. 新しい変更を加えて再デプロイする必要があるたびに、この手順を繰り返します。

もちろん、すべてのステップを一度に実行する単純なシェル スクリプトを作成することは、非常に役立ちます。

ヒント：

特にCSS や画像などの一部の公開コンテンツ や静的コンテンツを置換/変更する必要がある場合は特に、頻繁な再展開を避けるために、vhostこれらのリソースの処理に Apache common を使用することもできます。vhost一部のフォルダーをサブドメインとして作成するだけです。http://static.domain.tldまたは別のドメインでより良い：http://my-cdn.tldしたがって、次のようなパスを使用できます：

<img src="http://static.domain.tld/images/photo.png" alt="" />

それ以外の

<img src="/public/images/photo.png" alt="" />

メリット：

  • これらのファイルを変更するためにアプリを再デプロイする必要はありません。
  • Cookie は送信しません。これは、パブリック アセットにとってほとんど冗長です (vhost のドメインがメイン プロジェクト以外の場合)。
  • キャッシュタグを設定するためにHTTPサーバーの構成を使用できます（パフォーマンス！）
  • すべてのインスタンス間で自動的に統計を共有しています。
  • 画像を提供するために JVM リソースを浪費することはありません :) Play のデフォルト サーバーは非常に高速ですが、単純な HTTP サーバーで静的コンテンツを提供する方がおそらく高速であることに気付きました...

最後に、私の経験から、nginx は Apache よりも高速です。そのため、HTTP サーバーのタスクのみが Play のアプリの負荷分散である場合は、軽量な nginx の使用を検討してください。

于 2013-04-01T17:59:56.617 に答える