プラットフォームで管理されるスケーラブルで高可用性のアプリケーション配信コントローラーをサービスとして提供する Azure サービス。
こんにちは 拓也 小川,
英語から日本語に翻訳したので、文法的な誤りがあるかもしれませんがご容赦ください。
Microsoft Q&A フォーラムにお問い合わせいただきありがとうございます。
Azure Application Gateway のパスベースのルールが期待どおりに動作しない場合があります。これは、リダイレクト ルールではなく単純なルーティング ルールとして設定されている、パス パターンが不完全 (* が欠落している)、ルールの優先順位が間違っている、またはオーバーライド バックエンド パスが正しく構成されていないことが原因です。/scdl/ へのアクセスを /sc/ のように動作させるという特定の目的を達成するには、明示的な URL パス ベースのリダイレクト (ブラウザの URL が /sc/ に変更されるように) または、オーバーライド バックエンド パスを慎重に設定 (クライアントが /scdl/ を要求した場合でも、バックエンドが /sc/ を認識するように) する必要があります。
パスベースのルールが「デフォルトでは機能しない」理由
- PathBasedRouting ルールではなく基本ルーティングルールを使用すると、パスは無視され、バックエンドは 1 つしか使用されません。ルールタイプを PathBasedRouting に設定し、URL パス マップを添付してルールを作成する必要があります。
- パス パターンを /scdl/* ではなく /scdl と記述すると、正確なパス /scdl のみが一致します。/scdl/foo のようなリクエストはデフォルトのバックエンドにフォールバックし、エラーとして表示されます。ワイルドカードを使用する場合は、必ず /scdl/* を使用してください。
- ルールの優先順位が正しく設定されていない場合、より一般的なルールが先に一致するため、/scdl/* は評価されません。/scdl/* には、一般的なルールよりも高い優先順位(小さい数値)を設定してください。
- リダイレクトなしでバックエンドルーティングのみを設定した場合、トラフィックは正しいバックエンドにルーティングされるものの、URLは/scdl/のままとなり、アプリケーションが/sc/を期待している場合、ルールが「機能していない」ように見えることがあります。
- オーバーライドバックエンドパスが設定されていない、または誤って設定されている場合、バックエンドは/sc/...ではなく/scdl/...を受け取るため、アプリケーションは意図したとおりに動作しません。
/scdl/ へのアクセスを /sc/ に転送する方法
ブラウザの URL を変更するかどうかによって、2 つの明確な方法があります。
オプション A: URL をリダイレクトする(ユーザーに /sc/ を表示させる場合に推奨)
これにより、302 (Found) または 301 (Permanent) リダイレクトが作成され、ブラウザで /scdl/* が /sc/* に変わります。
手順:
- リダイレクト設定を作成します。
- タイプ: 一時的なリダイレクトの場合は Found (302)、永続的なリダイレクトの場合は Permanent (301) を指定します。
- パスを含める: true
- クエリ文字列を含める: true これにより、/scdl/foo?x=1 が /sc/foo?x=1 にリダイレクトされます。
- パスベースのルール用の URL パス マップを作成します。
- パス: /scdl/*
- このパスにリダイレクト設定を関連付けます。
- パスベースルーティングルールを作成します。
- リスナーとURLパスマップを関連付け、/scdl/* がより一般的なルールよりも先に評価されるように適切な優先順位を設定します。
この設定により、/scdl/... へのリクエストはすべて /sc/... にリダイレクトされ、ユーザーのブラウザには新しいURLが表示されます。
オプションB:内部的にパスを書き換える(URLは/scdl/のまま、バックエンドでは/sc/として認識される)
パスベースルーティングとバックエンドパスのオーバーライドを使用する:
- URLパスマップを使用してパスベースルールを作成する:
- パス:/scdl/*
- バックエンドプール:/sc/で使用されているプールと同じ
- バックエンドHTTP設定:バックエンドパスのオーバーライドを有効にする。
- バックエンドHTTP設定で:
- バックエンドパスのオーバーライドを設定し、/scdl/...が/sc/...に書き換えられるようにする。
- 例えば、一致するパスを/sc/でオーバーライドすると、/scdl/fooはバックエンドに転送される際に/sc/fooとなる。
この方法では、クライアントのブラウザには/scdl/...が表示されますが、バックエンドでは/sc/...が受信され、正しいコンテンツが配信されます。
「時々うまくいく」理由は、多くの場合、以下の通りです。
- 複数のルールが設定されており、一部のリクエストは正しいルールに一致するものの、他のリクエストは設定ミスのあるルールに一致している。
- パスパターンに「*」が欠落しているため、/scdl は完全に一致するものの、/scdl/foo は一致しない。
- バックエンドアプリケーション自体が、場合によっては /scdl から /sc へ内部リダイレクトを行うが、常に一貫して行われるわけではない。
/scdl/ → /sc/ を確実に動作させるための最小限のチェックリスト
- ルールタイプとして基本ルールではなく、PathBasedRouting を使用してください。
- パスパターンをワイルドカード付きの /scdl/* に設定してください。
- /scdl/* に、より一般的なパスよりも高い優先度(低い数値)を設定してください。
- 以下のいずれかの操作を行ってください。
- include-path = true を指定したリダイレクト設定を追加し、/scdl/* → /sc/* にリダイレクトする、または
- バックエンドの HTTP 設定でバックエンドパスのオーバーライドを設定し、バックエンドが /scdl/... ではなく /sc/... を受け取るようにしてください。
- バックエンドアプリケーションが実際に /sc/ でコンテンツを提供していることを確認してください。
Microsoft の公式ドキュメント
- Azure Application Gateway URL ベースのコンテンツ ルーティングの概要 | Microsoft Learn
- チュートリアル:CLI を使用した URL パスベースのリダイレクト - Azure Application Gateway | Microsoft Learn
上記の情報がお役に立てば幸いです。また、この件に関してさらにサポートが必要な場合はお知らせください。
提供された情報がお役に立った場合は、「賛成」をお願いいたします。これは他のコミュニティメンバーにも役立ちます。