uriworkermap.properties の設定

はじめに

WebサーバーからTomcatへのリクエストの転送は、マッピングルールを定義することで設定されます。このようなルールは、リクエストをワーカーにマッピングします。マップのリクエスト部分はURIパターンで記述され、ワーカーはそのワーカー名で記述されます。

いわゆるuriworkermapファイルは、すべてのWebサーバーで機能するルール定義のメカニズムです。ルールを定義するためのWebサーバー固有の他の設定オプションも存在し、それらは個々のWebサーバー向けTomcatコネクタ設定のリファレンスページで主に議論されます。

このファイルの名前は通常 uriworkermap.properties ですが、これはWebサーバーで設定可能です。uriworkermapファイルを有効にする方法については、Webサーバー固有のドキュメントページを参照してください。

uriworkermapファイルでサポートされる主な機能は次のとおりです

  • ルールファイル内でのコメントのサポート。
  • 厳密な一致とワイルドカード一致、ディレクトリとそのコンテンツ全体をマッピングするためのショートカット。
  • 除外ルール、ルールの無効化、およびルール優先順位。
  • ルール拡張、ルールごとのワーカーの動作変更。
  • 仮想ホストの統合: URIマッピングルールは仮想ホストごとに表現できます。ただし、詳細はWebサーバー固有です。
  • 動的リロード: ファイルは定期的に変更がチェックされます。新しいバージョンはWebサーバーの再起動なしに自動的にリロードされます。
  • ステータスワーカーとの統合。
以下のセクションでこれらの側面について詳しく説明します。

構文

行フォーマット

このファイルは行ベースのフォーマットです。継続文字はないため、各ルールは1行で定義する必要があります。各ルールはURIパターンとワーカー名のペアで構成され、等号'='で結合されます。

/myapp=myworker
URIパターンは大文字と小文字を区別します。

コメント、空白

文字'#'以降のすべてのテキストは無視され、コメントとして使用できます。URIパターンとワーカー名の前後の空白はトリムされます。以下の定義はすべて同等です

# This is a white space example
/myapp=myworker
  /myapp=myworker
/myapp  =  myworker

URIパターン

URIパターン内では、3つの特殊文字 '*', '?' および '|' を使用できます。文字 '*' は、URI内の任意の数の文字に一致するワイルドカードであり、'?' は正確に1文字に一致します。各URIパターンは文字 '/'、または '*'、または '?' で始まる必要があり、オプションで修飾子 '!' と '-' の任意の組み合わせがプレフィックスとして付与されます(次節参照)。

# Mapping the URI /myapp1 and everything under /myapp1/:
/myapp1=myworker-a
/myapp1/*=myworker-a
# Mapping all URI which end with a common suffix:
*.jsp=myworker
*.do=myworker
特定の場所とその内部のすべてをマッピングする最初のケースは非常に一般的なため、文字 '|' は便利なショートカットを提供します。
# Mapping the URI /myapp1 and everything under /myapp1/:
/myapp1|/*=myworker-a
パターン 'X|Y' は、2つのマップ 'X' と 'XY' に完全に同等です。

除外、無効化、および優先順位

除外とルールの無効化

除外ルールは、Tomcatにリクエストを転送するURIルールからの除外を定義することを可能にします。除外ルールが一致する場合、リクエストは転送されません。これは通常、Webサーバーが静的コンテンツを提供するために使用されます。ルールが除外ルールであるのは、それに '!' がサフィックスとして付加されている場合です。

# Mapping the URI /myapp and everything under /myapp/:
/myapp|/*=myworker
# Exclude the subdirectory static:
!/myapp/static|/*=myworker
# Exclude some suffixes:
!*.html=myworker
除外ルールが通常のマップルールをオーバーライドするのは、通常のルールと除外ルール内のワーカー名が同じである場合のみです。JKバージョン1.2.26以降では、除外ルールのワーカー名としてアスタリスク文字 '*' を使用することで、任意のワーカーに除外ルールを適用できます。除外ワーカー名にこれより複雑なパターンを使用することはできません。
# Mapping the webapps /myapp1 and /myapp2:
/myapp1|/*=myworker1
/myapp2|/*=myworker2
# Exclude the all subdirectories static for all workers:
!/*/static|/*=*
# Exclude some suffixes for all workers:
!*.html=*

ルールの無効化は、Webサーバーがさまざまなソースからのルールをマージし、以前に定義されたルールを無効にしたい場合に機能します。uriworkermapファイルは動的にリロードされるため、これを使用して一時的にリクエスト転送を無効にできます。ルールは、それに '-' がサフィックスとして付加されている場合に無効になります。

# We are not in maintenance.
# The maintenance rule got defined somewhere else.
-/*=maintenance
除外ルールも無効にすることができ、その場合、ルールは '-!' で始まります。

マッピングの優先順位

最も制限的なURIパターンが最初に適用されます。より正確には、URIパターンはパターン内の'/'文字の数でソートされ(最も多いものが最初)、数が同じルールは文字列の長さでソートされます(最も長いものが最初)。

両方の区別がそれでも不十分な場合、ルールの定義元が考慮されます。uriworkermap.propertiesで定義されたルールは、JkMount(Apache HTTP Serverの場合)によって定義されたルールや、workers.properties内でmount属性を使用して定義されたルールよりも優先されます。

すべての無効なルールは無視されます。除外ルールは、すべての通常のルールが適用された後に適用されます。

以下の設定競合については、定義された動作がありません: 同じ定義元で文字通り同じURIパターンを使用し、異なるワーカーターゲットを持つ場合。

ルール拡張

ルール拡張はバージョン1.2.27で追加されました。それ以前のバージョンでは利用できません。

構文

ルール拡張は、任意のルールに付加できる追加属性です。それらはルールの末尾に追加され、各拡張はセミコロンで区切られます。

# This is an extension example,
# setting a reply_timeout of 1 minute
# only for this mapping.
/myapp=myworker;reply_timeout=60000
#
# This is an example using multiple extensions
/myapp=myloadbalancer;reply_timeout=60000;stopped=member1
ルール拡張によって設定された属性は、ワーカー定義ファイル内の競合する設定を常に上書きします。

拡張 reply_timeout

拡張reply_timeoutは、単一のマッピングルールに対する応答タイムアウトを設定します。

# Setting a reply_timeout of 1 minute
# only for this mapping.
/myapp=myworker;reply_timeout=60000
これは、ワーカーに対して定義されたすべてのreply_timeoutを上書きします。この拡張機能により、ワーカーに妥当なデフォルトの応答タイムアウトを設定し、時間のかかるタスクを開始することが知られているURLには、より緩和された応答タイムアウトを設定できます。応答タイムアウトの一般的な説明については、タイムアウトのドキュメントを参照してください。

拡張 sticky_ignore

拡張sticky_ignoreは、単一のマッピングルールに対するセッションのスティッキー性を無効にします。

# Disable session stickyness
# only for this mapping.
/myapp/loginform.jsp=myworker;sticky_ignore=1
この拡張機能は、クッキーベースのセッションスティッキー性を使用する際にロードバランシングを最適化するのに役立ちます。この場合、ユーザーがセッションを開始した状態でブラウザを開いている限り、そのユーザーからのいかなるリクエストも、セッションを使用するアプリケーションの部分を離れたとしても、同じTomcatインスタンスに送信されます。例えば、ユーザーがログインフォームをリクエストした際にこの環境変数を設定することで、この初期セッションリクエストが非スティッキーにバランスされることを保証できます。

この拡張機能はバージョン1.2.33から利用可能です。

拡張 stateless

拡張statelessは、セッションベースのロードバランシングを使用している場合にのみ役立ちます。この場合、通常、セッションIDを伴わないリクエストは新しいセッションとしてカウントされます。マッピングルールにstateless拡張をマークすると、そのマッピングルールに一致するリクエストは、セッションIDを伴わない場合でも、新しいセッションとしてカウントされなくなります。

# Don't let static content trash our session balancing
/myapp/static/*=myworker;stateless=1
この拡張機能はバージョン1.2.33から利用可能です。

拡張 active/disabled/stopped

拡張activedisabled、およびstoppedは、ロードバランサーのマッピングルールで使用して、ロードバランサーの選択されたメンバーを特別な有効化状態に設定できます。

# Stop forwarding only for member1 of loadbalancer
/myapp=myloadbalancer;stopped=member1
複数のメンバーはカンマまたは空白で区切る必要があります。
# Stop forwarding for member01 and member02 of loadbalancer
# Disable forwarding for member21 and member22 of loadbalancer
/myapp=myloadbalancer;stopped=member01,member02;disabled=member21,member22
有効化状態の正確な意味については、有効化の説明を参照してください。

拡張 fail_on_status

拡張fail_on_statusは、あらゆるルールで使用できます。

# Send 503 instead of 404 and 500,
# and if we get a 503 also set the worker to error
/myapp=myworker;fail_on_status=-404,-500,503
複数のステータスコードはカンマで区切る必要があります。この属性の正確な意味については、fail_on_statusの説明を参照してください。

拡張 use_server_errors

拡張use_server_errorsは、バックエンド(例: Tomcat)のエラーページではなく、Webサーバーにエラーページを送信させることを可能にします。これは、カスタマイズされたエラーページを送信したいが、それらがすべてのWebアプリケーションの一部ではない場合に役立ちます。それらはWebサーバーに配置できます。

use_server_errorsの値は正の数です。バックエンドに送信されたリクエストがuse_server_errors以上のHTTPステータスコードを返した場合、そのステータスコードに対するWebサーバーのエラーページがクライアントに応答として送信されます。

# Use web server error page for all errors
/myapp=myworker;use_server_errors=400
# Use web server error page only for technical errors
/myotherapp=myworker;use_server_errors=500

ロードバランサーのスティッキー性を制御する拡張機能

拡張機能

  • session_cookie
  • session_path
  • set_session_cookie
  • session_cookie_path
は、マウントごとに同名のロードバランサーワーカー属性を定義することを可能にします。worker.properties設定リファレンスでそれらの説明を参照してください。

仮想ホストの統合

Microsoft IIS用ISAPIリダイレクター

Microsoft IISでISAPIリダイレクターを使用する場合、URIパターンに仮想ホスト情報をプレフィックスとして付加することで、個々のルールを特定の仮想ホストに制限できます。ルールとしては、URLがホスト名でプレフィックスされている必要があります。

# Use www.foo.org as virtual host
/www.foo.org/myapp/*=myworker
# Use www.bar.org as virtual host
/www.bar.org/myapp/*=myworker
# Normal mapping
/mysecondapp/*=myworker

/mysecondapp/* は存在するすべての仮想ホストにマッピングされることに注意してください。特定の仮想ホストへのマッピングを防ぐ必要がある場合は、除外ルールを使用する必要があります。

# Make sure the myapp is accessible by all virtual hosts
/myapp/*=myworker
# Disable mapping myapp for www.foo.org virtual host
!/www.foo.org/myapp/*=myworker

Apache HTTP Server用mod_jk

Apache HTTP Serverでは、仮想ホストごとに個別のuriworkermapファイルを定義できます。JkMountFileディレクティブは、メインサーバーおよび各仮想ホストで使用できます。仮想ホストがJkMountfileを使用せず、JkMountCopyが'On'に設定されている場合、メインサーバーからJkMountFileを継承します。すべての仮想ホストがメインサーバーからマウントを継承するようにしたい場合は、メインサーバーでJkMountCopyを'All'に設定できます。

動的リロード

リクエストが処理される際、Tomcatコネクタはuriworkermapファイルの最終更新時刻をチェックします。パフォーマンスへの影響を低く抑えるため、これは前回のチェックから少なくともn秒が経過した場合にのみ行われます。

Apache HTTP Serverでは、JkMountFileReloadディレクティブを使用して間隔「n」を設定でき、Microsoft IISではworker_mount_reload属性を使用します。デフォルト値は60秒です。「0」の値はリロードをオフにします。

ファイルが変更された場合、完全にリロードされます。uriworkermapファイル以外のソース(例:workers.propertiesのmount属性やApache HTTP ServerのJkMount)から来るルールが存在する場合、新しいuriworkermapファイルは、Webサーバーを再起動した場合とまったく同じように動的にそれらとマージされます。

バージョン1.2.19までは、リロードの動作がわずかに異なっていました。uriworkermapファイルの全内容をルールマッピングに継続的に追加していました。マージルールでは、重複が排除され、新しいファイルでルールを無効と定義することで古いルールを無効にできました。ルールが削除されることはありませんでした。

ステータスワーカーとの統合

ステータスワーカーの設定ビューには、さまざまなマッピングルールも表示されます。各ワーカーの設定の後、そのワーカーに転送されるルールがリストされます。リストには4つの列が含まれます。

  • 仮想サーバーの名前
  • URIパターン(無効なパターンには'-'が、除外パターンには'!'がプレフィックスとして付加されます)
  • ルールの種類: Exact または Wildchar
  • そしてルール定義のソース: workers.propertiesファイル(mount属性)の場合は「worker definition」、Apache HTTP ServerのJkMountとその関連の場合は「JkMount」、そしてuriworkermapファイルの場合は最後に「uriworkermap」となります。

注: 以下の制限はバージョン1.2.26から削除されました。
Apache HTTP Serverには重要なニュアンスがあります。ステータスワーカーに送られるリクエストは、特定のサーバー(メインまたは仮想)のコンテキストで実行されます。ステータスワーカーは、そのサーバー(メインまたは仮想)に対して定義されたマッピングルールのみを表示します。
バージョン1.2.25までは、リストには3つの列が含まれていました。

  • ルールの種類: Exact または Wildchar(最終的にDisabledまたはUnmount(除外ルール用)がプレフィックスとして付加されます)
  • URIパターン
  • そしてルール定義のソース: workers.propertiesファイル(mount属性)の場合は「worker definition」、Apache HTTP ServerのJkMountとその関連の場合は「JkMount」、そしてuriworkermapファイルの場合は最後に「uriworkermap」となります。