ねえ、私は Grails に不慣れで、展開について疑問に思っています。.war が本番環境にデプロイされたら、ダウンタイムなしでアプリケーションを更新するにはどうすればよいですか?
5 に答える
こちら でmod_proxy_balancer
説明されているように、前にApache を配置して 2 つの tomcat インスタンスをセットアップできます。アプリケーションの再デプロイには、「ローリング アップグレード」戦略が適用される場合があります (app1 と app2 が 2 つの tomcat インスタンスであると仮定します)。
- Apache のバランサーマネージャーで tomcat@app1 を無効にします
- アプリケーションを tomcat@app1 に再デプロイする
- app1 でいくつかのテストを行い、すべてが機能するかどうかを確認します
- balancer-manager で tomcat@app1 を有効にする
- balancer-manager で tomcat@app2 を無効にする
- アプリケーションを tomcat@app2 に再デプロイする
- balancer-manager で tomcat@app2 を有効にする
これで完了です。そのために複数の物理マシンまたは仮想マシンは必要ありません。単一のボックスでも可能です。アプリケーションのアップグレードがデータベースの変更を意味する場合は、注意してください。上記はガントスクリプトなどにカプセル化されている可能性があるため、単純な「grails cluster-redeploy」で必要なすべてが実行されます。そのようなスクリプトは現在私のリストにありますが、これがいつ完成するかはわかりません。
Tomcat を使用している場合は、並列配置と呼ばれるものを使用して可能です。
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Parallel_deployment
ドキュメントで説明されているように、バージョン番号を使用して war ファイルに名前を付けるだけです。
- foo##42.war
- foo##43.war
(サーバーを再起動せずに) WAR ファイルをホットデプロイした場合でも、コンテキストのリロード中にダウンタイムが発生します。これは、Grails そのものではなく、J2EE/サーブレットに関するものです。
dogbert が言ったように、メンテナンス ページを作成し (Tomcat の前に Apache を使用することをお勧めします)、アプリ サーバーをシャットダウンし、新しい WAR をアップロードしてからサーバーを再起動するのが最善です。
アプリが WAR としてパッケージ化されると、run-app を使用する場合のように、ソース ファイルへの変更が自動的に反映されることはありません。一般に、特にコードがコンパイルされ、コードが実質的に常にライブである場合、ライブ更新を実行するのは少し危険だと思います。開発中の奇妙な展開の不具合に対処することはできますが、本番環境では安全にプレイし、少しのダウンタイムで生活したいと考えています.
私が知っているのは、groovy ファイルまたは .gsp ファイルを変更して、変更を保存した後、ブラウザで利用できるということだけですが、他の種類のファイルがある場合、この機能について正確にはわかりません。