仮想ホスト(Virtual host)について

バーチャルホスト(別名：仮想ホスト、英名：Virtual host)は、図のように１台の物理サーバーに対して複数のドメイン名を割り当てることで、 利用者からみるとドメイン名別にあたかも(このあたかもが仮想です。)それぞれのドメイン１つに対して物理サーバーがあるように管理する技術です。

バーチャルホストの方式は、大きく分けて２つの方法があります。

• 名前ベースバーチャルホスト
• IPベースバーチャルホスト

上記概要図の例では１つのIPアドレス(NICが1つ)に対して２つのドメイン名を割り当てているので名前ベースです。 対して、IPベースバーチャルホストは、１台の物理サーバーに複数のNICを搭載して複数のIPアドレスを割り当てます。 割り当てられたIPアドレスから個別のドメイン名を判定します。

このように高価な物理サーバーの資源を複数の仮想ホストでそれぞれ有効活用することが目的です。

Hostタグ

• Tomcat Version:8.5.23

Host要素は仮想ホストを表します。仮想ホストは、サーバー（「www.mycompany.com」など）のネットワーク名と、Tomcatが実行されている特定のサーバーとの関連付けです。
クライアントがネットワーク名を使用してTomcatサーバーに接続できるようにするには、所属するインターネットドメインを管理するドメインネームサービス（DNS）サーバーにこの名前を登録する必要があります。

多くの場合、システム管理者は、複数のネットワーク名（www.mycompany.comやcompany.comなど）を同じ仮想ホストとアプリケーションに関連付けることを望みます。
これは、以下で説明するホスト名エイリアス機能を使用して実行できます。

1つまたは複数のHost要素がEngine要素内にネストされています。 Host要素内で、この仮想ホストに関連付けられたWebアプリケーションのコンテキスト要素をネストできます。
各エンジンに関連付けられたホストの1つが、そのエンジンのdefaultHost属性に一致する名前を持っていなければなりません。

クライアントは通常、ホスト名を使用して、接続先のサーバーを識別します。このホスト名は、HTTP要求ヘッダーにも含まれています。
TomcatはHTTPヘッダーからホスト名を抽出し、一致する名前のHostを探します。一致するものが見つからない場合、要求はデフォルトのホストにルーティングされます。
DNS名がHost要素の名前と一致しない要求がデフォルトのホストにルーティングされるため、デフォルトホストの名前はDNS名と一致する必要はありません（DNS名と一致する必要はありません）。

以下の説明では、変数名$CATALINA_BASEを使用して、相対パスのほとんどが解決されているベースディレクトリを参照しています。
CATALINA_BASEディレクトリを設定して複数のインスタンスに対してTomcatを設定していない場合、
$CATALINA_BASEはTomcatをインストールしたディレクトリ$CATALINA_HOMEの値に設定されます。

Hostタグ共通属性

Hostのすべての実装では、次の属性がサポートされています。

Hostタグ標準実装

Hostの標準実装はorg.apache.catalina.core.StandardHostです。上記の共通属性に加えて、次の追加属性をサポートしています。

Hostタグの子要素

このHost要素には、この仮想ホストに関連付けられた別のWebアプリケーションを表す1つ以上のContext要素をネストすることができます。

Host要素内の対応する要素をネストすることによって、次のユーティリティコンポーネントのインスタンスを最大で1つ入れ子にすることができます。

• Realm - ユーザーのデータベースおよび関連する役割を、このホスト内にネストされたすべてのコンテキストにわたって共有できるように、レルムを構成します（下位レベルのレルム構成によって上書きされない限り）。

(筆者追記)Tomcatの古いバージョンはserver.xmlに全ての要素を定義していました。
Tomcatが普及され多くのWebアプリケーションが配備されることでserver.xmlファイルだけではファイルの肥大化と保守性が劣化する事を解消するために、 Tomcatサーバーの主たる設定を定義するserver.xmlとWebアプリケーション固有の設定ファイルであるコンテキスト.xmlに分離されました。
子要素のContext要素は、$CATALINA_BASE/conf/エンジン名/ホスト名/アプリケーション名.xmlファイル内に別ファイルに定義します。

特記事項

ログ

エンジンは、org.apache.catalina.core.ContainerBase.[enginename]ログカテゴリに関連付けられています。
角括弧は実際には名前の一部であり、省略しないことに注意してください。

アクセスログ

Webサーバーを実行すると、通常生成される出力ファイルの1つがアクセス・ログになります。
アクセス・ログは、サーバーによって処理される各要求ごとに1行の情報を標準形式で生成します。
Catalinaには、Webサーバーやカスタム形式で作成された同じ標準フォーマットでアクセスログを作成できるオプションのValve実装が含まれています。

Catalinaに、Engine、Host、Contextで処理されたすべてのリクエストに対するアクセスログを、次のようにValve要素を入れ子にして作成することができます：

server.xmlのデフォルト設定値
<Host name="localhost"  appBase="webapps" unpackWARs="true" autoDeploy="true" >

	<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
		prefix="localhost_access_log" suffix=".txt"
		pattern="%h %l %u %t "%r" %s %b" />

</Host>
      			

サポートされているコンフィグレーション属性の詳細については、「ロギング・バルブにアクセスする」を参照してください。

アプリケーションの自動デプロイメント

デフォルトの設定で標準のホスト実装を使用している場合、appBaseのアプリケーションまたはconfigBaseのコンテキストファイルを使用してTomcatを起動すると自動的にデプロイされます（deployOnStartupプロパティはデフォルトでtrue）。
変更が検出されたときに再ロードまたは再デプロイされるTomcatは実行中です（autoDeploy属性のデフォルト値はtrueです）。

deployOnStartupとautoDeployはまったく同じコードの実行をトリガーするので、動作は非常に似ています。しかし、1つの重要な違いがあります。
Tomcatが起動すると、どのファイルが同じで、どのファイルが変更されているのか、そしてどのファイルが新しいのかは分かりません。
したがって、すべてのファイルを新しいファイルとして扱います。 Tomcatは実行中ですが、変更されていないファイルと変更されたファイルと新しいファイルを区別できます。
これにより、Tomcatが実行されている間に変更されるファイルと、Tomcatが停止している間にファイルが変更されることの間に、いくつかの動作の違いが生じます。

自動デプロイメントを使用する場合、ホストのappBaseおよび/またはconfigBaseに存在する関連ファイル（Webアプリケーションにはcontext.xmlファイル、WARおよびディレクトリがある可能性があります）は、
予期された命名規則に準拠している必要があります。つまり、同じWebアプリケーションのファイルは同じベース名を共有する必要があります。

自動展開プロセスでは、次の検索順序を使用して新規および/または変更されたWebアプリケーションを識別します。

1. ホストのconfigBaseにあるcontext.xmlファイルを持つWebアプリケーション。
2. context.xmlファイルのスキャン中にまだ識別されていない、ホストのappBaseにあるWARファイルを持つWebアプリケーション。
3. context.xmlおよび/またはWARファイルのスキャン中にまだ識別されていない、ホストのappBaseにあるディレクトリを持つWebアプリケーション。

autoDeployがtrueの場合、自動デプロイメントプロセスはデプロイされたWebアプリケーションの変更を監視します。
どのような変更が行われたかによって、Webアプリケーションは再配備または再ロードされます。
再デプロイメントには新しいWebアプリケーションの作成が含まれ、標準セッションマネージャを使用する場合、
ユーザーセッションは保持されません。再読み込みは、既存のWebアプリケーションを使用しますが、web.xmlを再解析してすべてのクラスをリロードします。
標準セッションマネージャを使用している場合、ユーザーセッションは永続化されます。

ユーザーは、自動展開プロセスが再ロードを監視するファイルに追加することができます。
つまり、WatchedResources要素をcontext.xmlファイルに追加することによって、
これらのファイルのいずれかの変更によってWebアプリケーションのリロードがトリガーされます。
詳細については、コンテキストのドキュメントを参照してください。

自動デプロイメントを使用する場合、XMLコンテキストファイルで定義されたdocBaseはappBaseディレクトリの外にある必要があります。
これが当てはまらない場合は、Webアプリケーションのデプロイメントが困難な場合や、アプリケーションを2回デプロイする場合があります。
この状況を回避するには、deployIgnore属性を使用できます。

server.xmlでコンテキストを明示的に定義する場合、アプリケーションの自動デプロイメントを無効にするか、deployIgnoreを慎重に指定する必要があります。
そうしないと、Webアプリケーションがそれぞれ2回展開され、アプリケーションに問題が発生する可能性があります。

ホスト名別名(エイリアス)

多くのサーバー環境では、ネットワーク管理者は同じサーバーのIPアドレスに解決される複数のネットワーク名（ドメインネームサービス（DNS）サーバー内）を構成しています。
通常、このような各ネットワーク名はconf/server.xmlに別々のHost要素として設定され、それぞれ独自のWebアプリケーションセットが設定されます

しかし、状況によっては、2つ以上のネットワーク名を同じ仮想ホストに解決し、同じ一連のアプリケーションを実行することが望ましい場合もあります。
このシナリオの一般的な使用例は、ユーザーがwww.mycompany.comまたはcompany.comのいずれかを利用して、
まったく同じコンテンツおよびアプリケーションにアクセスできることが望ましい企業のWebサイトです。

これは、Host要素内にネストされた1つ以上のAlias要素を利用することで実現されます。例：

ドメイン名の別名をAliasタグで表現した例
<Host name="www.mycompany.com" ...>
  ...
  <Alias>mycompany.com</Alias>
  ...
</Host>
      			

この方法を有効にするには、関係するすべてのネットワーク名をDNSサーバーに登録して、
このCatalinaのインスタンスを実行しているコンピュータと同じコンピュータに解決する必要があります。

エイリアスでは、ホストのname属性に許可されているワイルドカード形式（*.domainname）も使用できます。

Lifecycle Listeners

このホストの開始または停止を知る必要があるJavaオブジェクトを実装している場合は、この要素の内部にListener要素をネストすることで宣言できます。
指定するクラス名は、org.apache.catalina.LifecycleListenerインタフェースを実装する必要があり、対応するライフサイクルイベントの発生を通知されます。
このようなリスナーの構成は次のようになります。

Listenerタグを利用した例
<Host name="localhost" ...>
  ...
  <Listener className="com.mycompany.mypackage.MyListener" ... >
  ...
</Host>
      			

リスナーは、この要素から構成できる追加のプロパティをいくつでも持つことができます。
属性名は、標準のプロパティーメソッド命名パターンを使用して、対応するJavaBeanプロパティー名と照合されます。

リクエストフィルター

Catalinaに、周囲のEngine、Host、またはContext要素に向けられたすべての着信要求に対してIPアドレスまたはホスト名を確認するように頼むことができます。
リモートアドレスまたは名前は、java.util.regex正規表現構文を使用して定義された、設定された「受け入れ」,「拒否」フィルタに対してチェックされます。
承認されていない場所からのリクエストは、HTTPの「禁止」エラーで拒否されます。フィルター宣言の例：

Listenerタグを利用した例
<Host name="localhost" ...>
  ...
  <Valve className="org.apache.catalina.valves.RemoteHostValve"
         allow=".*\.mycompany\.com|www\.yourcompany\.com"/>
  <Valve className="org.apache.catalina.valves.RemoteAddrValve"
         deny="192\.168\.1\.\d+"/>
  ...
</Host>
        			

サポートされている構成オプションの詳細については、「リモートアドレスフィルタとリモートホストフィルタ」を参照してください。

シングルサインオン

多くの環境、特にポータル環境では、特定の仮想ホストにデプロイされたWebアプリケーションのセットに対して一度だけ自分自身を認証することをユーザーに求めることが望まれます。
これは、次のような要素をこの仮想ホストのHost要素の中にネストすることで実現できます。

Listenerタグを利用した例
<Host name="localhost" ...>
  ...
  <Valve className="org.apache.catalina.authenticator.SingleSignOn"/>
  ...
</Host>
        			

シングルサインオン機能は、次のルールに従って動作します。

• この仮想ホスト用に設定されたすべてのWebアプリケーションは、同じレルムを共有する必要があります。
  実際には、このHost要素（または周囲のEngine要素）内にRealm要素をネストできますが、関連するWebアプリケーションのContext要素内には入れないことを意味します。
• ユーザーがこの仮想ホスト上のいずれかのWebアプリケーションで保護されていないリソースにのみアクセスする限り、ユーザーは自分自身を認証することに挑戦することはありません。
• ユーザーがこの仮想ホストに関連付けられたWebアプリケーションの保護されたリソースにアクセスするとすぐに、ユーザーは、現在アクセスされているWebアプリケーション用に定義されたログインメソッドを使用して自分自身を認証するように求められます。
• 一度認証されると、このユーザに関連付けられたロールは、ユーザが各アプリケーションに個別に認証することに挑戦することなく、関連するすべてのウェブアプリケーションにわたってアクセス制御の決定に利用される。
• ユーザーが1つのWebアプリケーションからログアウトすると（フォームベースのログインが使用されている場合は対応するセッションを無効にするなど）、
  すべてのWebアプリケーションのユーザーセッションは無効になります。どのアプリケーションでも保護されたリソースにアクセスしようとすると、
  ユーザーは再び自分自身を認証する必要があります。
• シングルサインオン機能は、HTTP Cookieを使用して、各要求を保存されたユーザーIDと関連付けるトークンを送信するため、Cookieをサポートするクライアント環境でのみ利用できます。

Webアプリケーション

多くのWebサーバーは、チルダ文字（ "〜"）で始まる要求URIとユーザー名を、サーバー上のそのユーザーのホームディレクトリにあるディレクトリ
（一般にpublic_htmlという名前）に自動的にマップできます。このような特殊なListener要素
（有効なユーザーを識別するために/etc/passwdファイルを使用するUnixシステム上）を使用することで、Catalinaで同じことを達成できます。

ListenerタグでUserConfigを利用した例
<Host name="localhost" ...>
  ...
  <Listener className="org.apache.catalina.startup.UserConfig"
            directoryName="public_html"
            userClass="org.apache.catalina.startup.PasswdUserDatabase"/>
  ...
</Host>
        			

/etc/passwdが使用されていないサーバでは、指定されたベースディレクトリ（この例ではc：\yen;Homesなど）
にあるすべてのディレクトリを「ユーザホーム」ディレクトリと見なすようにCatalinaに要求することができます。この例：

ListenerタグでUserConfigを利用した例
<Host name="localhost" ...>
  ...
  <Listener className="org.apache.catalina.startup.UserConfig"
            directoryName="public_html"
            homeBase="c:\yen;Homes"
            userClass="org.apache.catalina.startup.HomesUserDatabase"/>
  ...
</Host>
        			

ユーザーホームディレクトリがcraigmccという名前のユーザー用に設定されている場合、その内容は次のようなURLに要求することによってクライアントブラウザから表示されます。

この機能をうまく使用するには、次の点を考慮する必要があります。

• 各ユーザーWebアプリケーションは、グローバルおよびホストレベルのデフォルトのコンテキスト設定によって確立された特性で展開されます。
• このListener要素の複数のインスタンスを含めることは正当です。しかし、これは複数の "homeBase"ディレクトリを設定したい場合にのみ便利です。
• Catalinaが実行されるオペレーティングシステムのユーザー名は、各ユーザーのWebアプリケーションディレクトリ
  およびそのすべての内容に対する読み取りアクセス権を持っていなければなりません。