IISでは、複数のアプリケーションを独立したWebサイトとしてホストするか、デフォルトサイトの仮想ディレクトリとしてホストする方がよいでしょうか。
バックグラウンド
私は最近、クライアント用のMVCアプリケーションを開発しました。彼らは、同じサーバー上の他のいくつかのアプリと一緒に、それをホストしたいと考えています。
私はサーバー管理者というよりも開発者ですが、私の本能は、独自のサブドメインバインディングを使用してIISに新しいサイトをセットアップすることでした。
ただし、クライアントは、代わりに、アプリケーションを指すデフォルトサイトに仮想ディレクトリを作成したいと考えています。したがって、たとえば、次のようになります。
COMPANY.COM/APP1およびCOMPANY.COM/APP2
のではなく：
APP1.COMPANY.COMおよびAPP2.COMPANY.COM
これしました動作します;ただし、標準のHTTPマークアップの相対URLと競合し、問題はすぐに解決されました。
質問
同じサーバー上で複数のWebアプリを別々のサイトとしてホストするか、デフォルトのWebサイト内の仮想ディレクトリとしてホストする方がよいでしょうか。仮想ディレクトリアプローチに落とし穴はありますか？
私は仮想ディレクトリのアプローチを判断していません。それは私にとって新しいものであり、現在または将来問題が発生しないことを確認したいと思います。
私は常にアプリケーションのために個々のサイトに固執しようとしました。すべてをより細かく制御でき、ASP.NETを実行している場合は、簡単に発生するweb.configカスケードの問題に遭遇することはありません。さらに、アプリケーションプールをよりきめ細かく制御でき、実際に個々のアプリケーションのパフォーマンスを監視できます。これはすべて好みです。
とにかく、おそらく最良の答えは、アプリケーションレベルではなく、Webサイトレベルでバインディングを適用することです。したがって、各アプリが非SSLではなく独自のURLまたはSSLを必要とする場合は、実際には個々のサイトを調べる必要があります。
さらに、おっしゃるように、展開メカニズムを念頭に置いてプログラミングする必要があります。相対URLを使用すると、多くの問題が発生します。
最後に：なぜ彼らはサブドメインを使いたくないのですか？あなたが私に尋ねれば、それはリソースの素晴らしいクリーンなRESTfulish分離を提供します。
状況によって異なります...アプリケーションは、単一のアプリの機能に影響を与えない各仮想ディレクトリにカスケードする、より高いレベルで単一の変更を快適に行うことができるという点で、互いに非常に似ていますか？アプリごとに個別のサイトがある場合は、各サイトの設定（証明書、IP、ポートなど）を個別に管理する必要があります。これは、サイトが多数ある場合は頭痛の種になる可能性がありますが、完全に独立したサイトであるため、設定は別のアプリには影響しません。実際の作業はワーカープロセス/アプリプールによって行われるため、どちらの設定でも、複数のアプリで同じアプリプールを共有することも、アプリごとに別々のアプリプールを使用することもできます。
- 別々のサイトのアプリケーション =アプリをよりきめ細かく制御し、各サイトのメンテナンスを増やすことでアプリに接続する方法
- 同じサイト上のアプリケーション =すべてが非常に類似している場合は管理が容易ですが、アプリの要件が競合している場合は構成の問題が発生する可能性があります