同じWAR（複数の異なるコンテキスト、同じコンテナ）の複数のインスタンスを効率的にデプロイ

Question

私は1つのWAR（app.war）と1つのコンテナ（Tomcat、Jetty、Glassfishな​​ど）を持っています。 私の目標は、オンデマンドで、この同じWebアプリケーションのインスタンスをコンテナにデプロイすることです。これを達成する

http://foo/app1 --> app.war 
http://foo/app2 --> app.war 
http://foo/app3 --> app.war 
... 
http://foo/appN --> app.war 

いくつかの明白な方法：Tomcatので

• 、すべて同じWARを指し、（appN.xml命名）各アプリケーションのための1つのcontext.xmlファイルを作成します。他の容器は、このアプローチと同様の方法
  • 問題を持っている：それは、Webアプリケーション/ {APP1、APP2、APPN}フォルダを作成する
• 使用シンボリックリンクをディスクスペースの多くを取って、WAR N回爆発しますapp.warの展開バージョンを指しています。これにより、ディスクスペースの爆発を防ぎますが、JVMはまだ多くの重複JARをメモリにロードしています。
• ほとんどのjar（および上記2つのオプションの組み合わせ）を含む共有libフォルダをいくつか使用します。

もっと良い方法があるのだろうかと思います。理想的には、新しいインスタンスを作成すると、余分なディスクスペース（余分な構成ファイル以外）を占めてはならず、スレッド実行スタックやその他の実行時割り当てに関連するメモリのみを使用してください。

アイデア？

Answer 1

桟橋は、オーバーレイと呼ばれるものを使って、あなたが探しているもののサポートを追加しました。 wikiページからのビットのコピー

http://wiki.eclipse.org/Jetty/Tutorial/Configuring_the_Jetty_Overlay_Deployer

：あなたが展開されているバージョンは明らかであるように

• あなたは不変WARファイルを保つことができますが、でも、署名しました。
• ウェブアプリケーションをカスタマイズ/設定するためのすべての変更は、別々のWARであるため、レビューや新しいバージョンへの移行のために簡単に識別できます。
• Webアプリケーションの多くのインスタンスに適用される一般的なカスタマイズや設定が含まれているパラメータ化されたテンプレートオーバーレイを作成できます（たとえば、マルチテナント展開の場合）。
• Jettyでは、階層化されたデプロイメントによって共通コンポーネントとインスタンス固有のコンポーネントが明確に識別されるため、テンプレートのクラスローダーと静的リソースキャッシュを共有できるため、複数のインスタンスのメモリフットプリントが大幅に削減されます。

Answer 2

フロントエンド（mod_proxy/mod_proxy_ajp）にApacheを設定して、名前付き仮想ホストをTomcatにデプロイされた単一のWARにポイントすることができます。アプリケーションは、すべてのリクエストを処理する方法で設計/記述されている必要があります - ウェブサイト名ごとの特定の設定をデータベースに保存するか、アプリケーション内の設定ファイルとして保存することができます。正しい設定が適用されていることを確認してください（セッションごとに1回）。一般的に言えば、1つのアプリケーションでこれを解決できるはずです。素晴らしい開発者はLAZYです。

Answer 3

これは実験用の場合は、リストされた方法のいずれかがうまくいく可能性があります。

これが製造用の場合は、これをお勧めします。私はすべてのコンテナをテストしていませんが、私が使用しているコンテナは、ヘッドレスVMにコンテナを単に準備するだけではるかに弾力性があると信じています。 Linux VMは非常に小さくすることができ、VMテクノロジーを使用すると、必要な数のインスタンスを追加または削除できます。

もしあなたが本当に動的に成長しているソリューションを望むなら、単一の障害点を排除して、全世界を1つに集約しようとするべきです。

"最大2番目の"負荷の拡張/縮小が本当に必要な場合は、AWSまたはCloundFoundryを参照する必要があります。

Answer 4

Jettyを使用している場合は、プログラムでコンテキストを追加できます。

WebAppContext webapp = new WebAppContext(); 
webapp.setBaseResource(myBaseDirectory); 
webapp.setContextPath(myContextPath); 

すべてのコンテキストでこれをループで実行します。ディスクスペースのオーバーヘッドがゼロに近くなければなりません。

おそらくTomcatでこれを行うのと同じ方法があります。

Answer 5

少し話題になっていて申し訳ありませんが、あなたのシナリオでは「マルチテナント」アプリケーションを叫んでいるので、複数の「テナント」（顧客）にサービスを提供する単一のアプリケーションがあります。マルチテナントのセットアップに関しては

、次の考慮事項を考慮しなければならないだろう。彼らは、データが、同じデータベースに保存されている同じスキーマと使用している場合

• お客様が「（お互いのデータにアクセスすることはできませんデータを分離するための「弁別子」フィールド）。これは、SpringセキュリティをAccess Control Lists
• と一緒に使用することで実現できます。Hibernateには、バージョン4.0のsupport for multitenancy appsが組み込まれています。
• これら二つのSOの質問は同様に有用であり得る
  • Multiple Entity Manager issue in Spring when using more than one datasource（顧客ごとに同じデータベース）上の異なるデータソース（異なるデータベースまたは単に異なるスキーマを使用する。
  • Multi tenancy support in Java EE 6

マルチテナントの利点：

• 共有コードとは、ある顧客に対して固定されたバグがすべての顧客に対して固定されていることを意味します（異なる顧客がバグの構成と機能の構成について異なる見解を示す場合、
• クラスタ化されたデプロイメントでは、顧客間の負荷を共有できます（ただし、ピーク時のキャパシティをすべての顧客に提供できるようにする必要があります）。

欠点が：クエリは、顧客との「差別」はaccidentiallyお互いのデータに顧客をさらすことなく動作することを確認する必要がありますよう

• コードは少し複雑になるだろう。