ホストコンテナ
目次
はじめに
Host 要素は、サーバーのネットワーク名（例：「www.mycompany.com」）とTomcatが実行されている特定のサーバーとの関連付けである仮想ホストを表します。クライアントがTomcatサーバーにネットワーク名を使用して接続できるようにするには、この名前を所属するインターネットドメインを管理するドメインネームサービス（DNS）サーバーに登録する必要があります。詳細については、ネットワーク管理者にお問い合わせください。
多くの場合、システム管理者は、複数のネットワーク名（www.mycompany.com や company.com など）を同じ仮想ホストおよびアプリケーションに関連付けたいと考えています。これは、後述のホスト名エイリアス機能を使用して実現できます。
1つ以上の Host 要素は、Engine 要素内にネストされます。Host要素内には、この仮想ホストに関連付けられたWebアプリケーションのContext要素をネストできます。各Engineに関連付けられたHostのうち、正確に1つがそのEngineの defaultHost 属性と一致する名前を持つ必要があります。
クライアントは通常、接続先のサーバーを識別するためにホスト名を使用します。このホスト名はHTTPリクエストヘッダーにも含まれています。TomcatはHTTPヘッダーからホスト名を抽出し、一致する名前を持つ Host を探します。一致するものが見つからない場合、リクエストはデフォルトのホストにルーティングされます。デフォルトのホストの名前はDNS名と一致する必要はありません（一致することもできます）。DNS名が Host 要素の名前と一致しないリクエストはすべてデフォルトのホストにルーティングされるからです。
以下の説明では、ほとんどの相対パスが解決される基準となるベースディレクトリを参照するために、変数名 $CATALINA_BASE を使用します。CATALINA_BASE ディレクトリを設定して複数のインスタンス用にTomcatを設定していない場合、$CATALINA_BASE はTomcatをインストールしたディレクトリである $CATALINA_HOME の値に設定されます。
属性
共通属性
Host のすべての実装は、次の属性をサポートします。
| 属性 | 説明 |
|---|---|
appBase |
この仮想ホストのアプリケーションベースディレクトリ。これは、この仮想ホストにデプロイされるWebアプリケーションが含まれる可能性のあるディレクトリのパス名です。絶対パス名、または |
xmlBase |
この仮想ホストのXMLベースディレクトリ。これは、この仮想ホストにデプロイされるコンテキストXML記述子が含まれる可能性のあるディレクトリのパス名です。このディレクトリには絶対パス名、または |
createDirs |
|
autoDeploy |
このフラグ値は、Tomcatの実行中にTomcatが新しいまたは更新されたWebアプリケーションを定期的にチェックする必要があるかどうかを示します。 |
backgroundProcessorDelay |
この値は、このホストとその子コンテナ（すべてのコンテキストを含む）で backgroundProcess メソッドの呼び出し間隔を秒単位で表します。子コンテナの遅延値が負でない場合（つまり、独自の処理スレッドを使用している場合）、子コンテナは呼び出されません。これを正の値に設定すると、スレッドが生成されます。指定された時間が経過すると、スレッドはこのホストとそのすべての子コンテナで backgroundProcess メソッドを呼び出します。ホストは、ライブWebアプリケーションのデプロイメント関連タスクを実行するためにバックグラウンド処理を使用します。指定しない場合、この属性のデフォルト値は -1 です。これは、ホストが親エンジンのバックグラウンド処理設定に依存することを意味します。 |
className |
使用する実装のJavaクラス名。このクラスは |
deployIgnore |
この正規表現は、 詳細については、自動アプリケーションデプロイメントを参照してください。 |
deployOnStartup |
このフラグ値は、Tomcatの起動時にこのホストからのWebアプリケーションを自動的にデプロイする必要があるかどうかを示します。デフォルトは |
failCtxIfServletStartFails |
ロード時起動 >= 0 のサーブレットの起動が失敗した場合、各子コンテキストが起動に失敗するようにするには、 各子コンテキストはこの属性をオーバーライドできます。 指定しない場合、デフォルト値の |
legacyAppBase |
この仮想ホストのレガシーアプリケーションベースディレクトリ。これは、デプロイ前にJakarta EEに変換されるJava EE Webアプリケーションが含まれる可能性のあるディレクトリのパス名です。このディレクトリに配置されたWARファイルまたはディレクトリとしてパッケージ化されたJava EEアプリケーションは、Apache Tomcat Migration Tool for Jakarta EEを使用してJakarta EEに変換されます。変換は、デフォルト設定を使用して実行されます。結果のWARまたはディレクトリは、この仮想ホストに設定された デフォルト設定がアプリケーションの移行に適していない場合は、移行を手動で実行することにより、移行オプションの全範囲にアクセスできます。 絶対パス名、または |
name |
通常、ドメインネームサービスサーバーに登録されているこの仮想ホストのネットワーク名。ホスト名を指定するために使用される大文字と小文字に関係なく、Tomcatは内部的に小文字に変換します。Engine 内にネストされたHostの1つは、そのEngineの |
startStopThreads |
この Host が子Context要素を並行して起動するために使用するスレッドの数。同じスレッドプールは、自動デプロイメントが使用されている場合、新しいContextをデプロイするためにも使用されます。スレッドプールはサーバーレベルで共有されるため、複数のHostがこの設定を指定した場合、最大値のみが適用され、特別な値1を除いてすべてに使用されます。指定しない場合、デフォルト値の1が使用されます。1つのスレッドを使用する場合、 |
undeployOldVersions |
このフラグは、Tomcatが自動デプロイメントプロセスの一部として、並行デプロイメントを使用してデプロイされた古い未使用のバージョンのWebアプリケーションをチェックし、見つかった場合は削除するかどうかを決定します。このフラグは、 |
標準実装
Host の標準実装は、org.apache.catalina.core.StandardHost です。これは、次の追加属性をサポートします（上記の共通属性に加えて）。
| 属性 | 説明 |
|---|---|
copyXML |
アプリケーション内に埋め込まれているコンテキストXML記述子（ |
deployXML |
アプリケーション内に埋め込まれているコンテキストXML記述子（ |
errorReportValveClass |
このHostで使用されるエラー報告バルブのJavaクラス名です。このバルブの役割は、エラーレポートを出力することです。このプロパティを設定することで、Tomcatによって生成されるエラーページの見た目をカスタマイズできます。このクラスは |
unpackWARs |
注: TomcatがWARファイルを展開する場合、Tomcatが実行されていない間にWARファイルの変更を検出するために使用するファイル（ 注: このオプションを |
workDir |
このHostのアプリケーションで使用されるスクラッチディレクトリへのパス名です。各アプリケーションは、一時的な読み書き用に使用される独自のサブディレクトリを持ちます。ContextのworkDirを構成すると、HostのworkDir構成の使用がオーバーライドされます。このディレクトリは、Servlet仕様に記述されているように、 |
ネストされたコンポーネント
このHost要素内には、1つ以上のContext要素をネストでき、それぞれがこの仮想ホストに関連付けられた異なるWebアプリケーションを表します。
次のユーティリティコンポーネントのインスタンスを最大1つまで、Host要素内に対応する要素をネストすることでネストできます。
特別な機能
ログ
ホストは、org.apache.catalina.core.ContainerBase.[engine_name].[host_name]ログカテゴリに関連付けられています。角括弧は名前の一部であり、省略しないことに注意してください。
アクセスログ
Webサーバーを実行すると、通常生成される出力ファイルの1つがアクセスログであり、サーバーによって処理された各リクエストに対して、標準形式で1行の情報が生成されます。Catalinaには、Webサーバーによって作成されたものと同じ標準形式、または任意の数のカスタム形式でアクセスログを作成できるオプションのValve実装が含まれています。
次のようなValve要素をネストすることで、Engine、Host、またはContextによって処理されたすべてのリクエストのアクセスログを作成するようにCatalinaに指示できます。
<Host name="localhost" ...>
...
<Valve className="org.apache.catalina.valves.AccessLogValve"
prefix="localhost_access_log" suffix=".txt"
pattern="common"/>
...
</Host>サポートされている構成属性の詳細については、アクセスログバルブを参照してください。
自動アプリケーションデプロイメント
デフォルト設定の標準のHost実装を使用している場合、appBase内のアプリケーション、またはconfigBase内のコンテキストファイルは、Tomcatの起動時に自動的にデプロイされ（deployOnStartupプロパティのデフォルトはtrue）、Tomcatの実行中に変更が検出されると（必要に応じて）再ロードまたは再デプロイされます（autoDeploy属性のデフォルトもtrueです）。
deployOnStartupとautoDeployは、まったく同じコードの実行をトリガーするため、動作は非常に似ています。ただし、1つの重要な違いがあります。Tomcatが起動するとき、どのファイルが同じで、どれが変更され、どれが新しいかを知りません。したがって、すべてのファイルを新しいものとして扱います。Tomcatの実行中は、変更されていないファイル、変更されたファイル、新しいファイルを区別できます。これにより、Tomcatの実行中に変更されたファイルと、Tomcatが停止している間に変更されたファイルの間で、動作にいくつかの違いが生じます。
自動デプロイメントを使用する場合、HostのappBaseおよび/またはconfigBaseに存在する関連ファイル（Webアプリケーションには、context.xmlファイル、WAR、およびディレクトリがある場合があります）は、予期される命名規則に準拠する必要があります。簡単に言えば、これは同じWebアプリケーションのファイルが同じベース名を共有する必要があることを意味します。
自動デプロイメントプロセスは、次の検索順序を使用して、新規および/または変更されたWebアプリケーションを識別します。
- HostのconfigBaseにあるcontext.xmlファイルを持つWebアプリケーション。
- context.xmlファイルの検索中にまだ識別されていない、HostのappBaseにあるWARファイルを持つWebアプリケーション。
- context.xmlファイルおよび/またはWARファイルの検索中にまだ識別されていない、HostのappBaseにあるディレクトリを持つWebアプリケーション。
autoDeployがtrueの場合、自動デプロイメントプロセスは、デプロイされたWebアプリケーションの変更を監視します。変更内容に応じて、Webアプリケーションは再デプロイまたは再ロードされます。再デプロイメントには、新しいWebアプリケーションの作成が含まれ、標準セッションマネージャーを使用している場合は、ユーザーセッションは保持されません。再ロードは既存のWebアプリケーションを使用しますが、web.xmlを再解析し、クラスを再ロードします。標準セッションマネージャーを使用している場合、ユーザーセッションは保持されます。
ユーザーは、context.xmlファイルにWatchedResources要素を追加することにより、自動デプロイメントプロセスが再ロードのために監視するファイルを追加できます（つまり、これらのファイルのいずれかへの変更は、Webアプリケーションの再ロードをトリガーします）。詳細については、Contextドキュメントを参照してください。
自動デプロイメントを使用する場合、XML Contextファイルで定義されたdocBaseは、appBaseディレクトリの外にある必要があります。そうでない場合、Webアプリケーションのデプロイに問題が発生したり、アプリケーションが2回デプロイされたりする可能性があります。この状況を回避するために、deployIgnore属性を使用できます。
server.xmlでコンテキストを明示的に定義している場合は、自動アプリケーションデプロイメントをオフにするか、deployIgnoreを注意深く指定する必要があります。そうしないと、Webアプリケーションはそれぞれ2回デプロイされ、アプリケーションに問題が発生する可能性があります。
設定、新しいファイル、変更されたファイル、および削除されたファイルの組み合わせはたくさんあります。別のページでは、これらのシナリオの多くで自動デプロイメントプロセスの予期される動作について説明しています。
ホスト名エイリアス
多くのサーバー環境では、ネットワーク管理者が、同じサーバーのIPアドレスに解決される複数のネットワーク名（ドメインネームサービス（DNS）サーバー内）を構成しています。通常、このような各ネットワーク名は、conf/server.xml内の個別のHost要素として構成され、それぞれに独自のWebアプリケーションのセットが用意されます。
ただし、状況によっては、2つ以上のネットワーク名が同じ仮想ホストに解決され、同じアプリケーションのセットを実行することが望ましい場合があります。このシナリオの一般的なユースケースは、企業Webサイトであり、ユーザーがwww.mycompany.comまたはcompany.comのいずれかを使用して、まったく同じコンテンツとアプリケーションにアクセスできることが望ましい場合です。
これは、Host要素内にネストされた1つ以上のAlias要素を利用することによって実現されます。例:
<Host name="www.mycompany.com" ...>
...
<Alias>mycompany.com</Alias>
...
</Host>この戦略を有効にするためには、関係するすべてのネットワーク名が、このCatalinaインスタンスを実行している同じコンピューターに解決されるようにDNSサーバーに登録されている必要があります。
エイリアスでは、Hostのname属性とは異なり、ワイルドカード形式（*.domainname）を使用することもできます。
ライフサイクルリスナー
このHostの起動時または停止時に知る必要のあるJavaオブジェクトを実装している場合は、この要素内にListener要素をネストすることで宣言できます。指定するクラス名はorg.apache.catalina.LifecycleListenerインターフェースを実装する必要があり、対応するライフサイクルイベントの発生について通知されます。このようなリスナーの構成は次のようになります
<Host name="localhost" ...>
...
<Listener className="com.mycompany.mypackage.MyListener" ... >
...
</Host>リスナーには、この要素から構成できる追加のプロパティを任意に含めることができることに注意してください。属性名は、標準のプロパティメソッド命名パターンを使用して、対応するJavaBeanプロパティ名に一致します。
リクエストフィルター
周囲のEngine、Host、またはContext要素に向けられたすべての着信リクエストのIPアドレスまたはホスト名を確認するようにCatalinaに指示できます。リモートアドレスまたは名前は、java.util.regex正規表現構文を使用して定義された構成済みの「accept」および/または「deny」フィルターに対してチェックされます。受け入れられない場所からのリクエストは、HTTP「Forbidden」エラーで拒否されます。フィルター宣言の例
<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アプリケーションに対して1回だけ認証を要求することが望ましい場合があります。これは、この仮想ホストのHost要素内に次のような要素をネストすることで実現できます。
<Host name="localhost" ...>
...
<Valve className="org.apache.catalina.authenticator.SingleSignOn"/>
...
</Host>シングルサインオン機能は、次のルールに従って動作します。
- この仮想ホスト用に構成されたすべてのWebアプリケーションは、同じRealmを共有する必要があります。実際には、Realm要素をこのHost要素（または周囲のEngine要素）の中にネストできますが、関係するWebアプリケーションの1つのContext要素の中にはネストできません。
- ユーザーがこの仮想ホスト上のWebアプリケーションの保護されていないリソースのみにアクセスする場合、ユーザーは認証を要求されません。
- ユーザーがこの仮想ホストに関連付けられたいずれかのWebアプリケーションで保護されたリソースにアクセスするとすぐに、ユーザーは現在アクセスしているWebアプリケーションに定義されているログイン方法を使用して、本人認証を要求されます。
- 認証されると、このユーザーに関連付けられた役割は、ユーザーに各アプリケーションに個別に認証を要求することなく、関連付けられたすべてのWebアプリケーションでのアクセス制御の決定に使用されます。
- ユーザーが1つのWebアプリケーションからログアウトすると（例えば、フォームベースのログインを使用している場合は対応するセッションを無効化するなど）、すべてのWebアプリケーションにおけるユーザーのセッションが無効になります。その後、いずれかのアプリケーションで保護されたリソースにアクセスしようとすると、ユーザーは再び認証を行う必要があります。
- シングルサインオン機能は、各リクエストを保存されたユーザーIDに関連付けるトークンをHTTP Cookieを使用して送信するため、Cookieをサポートするクライアント環境でのみ利用できます。
ユーザーウェブアプリケーション
多くのWebサーバーは、チルダ文字（"~"）とユーザー名で始まるリクエストURIを、サーバー上のそのユーザーのホームディレクトリ（一般的にはpublic_htmlという名前）に自動的にマッピングできます。Catalinaで同じことを実現するには、次のような特別なListener要素を使用します（有効なユーザーを識別するために/etc/passwdファイルを使用するUnixシステムの場合）。
<Host name="localhost" ...>
...
<Listener className="org.apache.catalina.startup.UserConfig"
directoryName="public_html"
userClass="org.apache.catalina.startup.PasswdUserDatabase"/>
...
</Host>/etc/passwdが使用されていないサーバーでは、Catalinaに対して、指定されたベースディレクトリ（この例ではc:\Homesなど）にあるすべてのディレクトリを、このディレクティブの目的のために「ユーザーホーム」ディレクトリとみなすように要求できます。
<Host name="localhost" ...>
...
<Listener className="org.apache.catalina.startup.UserConfig"
directoryName="public_html"
homeBase="c:\Homes"
userClass="org.apache.catalina.startup.HomesUserDatabase"/>
...
</Host>craigmccという名前のユーザーに対してユーザーホームディレクトリが設定されている場合、クライアントブラウザから次のようなURLにリクエストを送信することで、その内容が表示されます。
http://www.mycompany.com:8080/~craigmccこの機能を正常に使用するには、次の考慮事項を認識する必要があります。
- 各ユーザーWebアプリケーションは、グローバルおよびホストレベルのデフォルトコンテキスト設定によって確立された特性とともにデプロイされます。
- このListener要素の複数のインスタンスを含めることは合法です。ただし、これは、複数の「homeBase」ディレクトリを設定したい場合にのみ役立ちます。
- Catalinaが実行されているオペレーティングシステムのユーザー名は、各ユーザーのWebアプリケーションディレクトリとそのすべての内容に対する読み取りアクセス権を持っている必要があります。
カスタム context.xml と web.xml
各仮想ホストについて、$CATALINA_BASEからconf/context.xmlファイルおよびconf/web.xmlファイルにあるデフォルト値を上書きできます。Tomcatは、xmlBaseで指定されたディレクトリにcontext.xml.defaultおよびweb.xml.defaultという名前のファイルを探し、それらのファイルをデフォルトのファイルにマージします。