概要 #
この記事では、複数のアプリケーションURIを同じバックエンドプールにルーティングするF5 BIG-IP iRuleを移行する方法について説明します。 RELIANOID ネイティブHTTP/Sファームサービスのマッチングと正規表現（regex）URIパターンを使用します。
元のiRuleは、受信したURIを評価し、複数のアプリケーションパスに一致するトラフィックを同じバックエンドプールに送信します。
オリジナルF5 iRule #
when HTTP_REQUEST { switch -glob [string tolower [HTTP::uri]] { "/firstapp*" { pool "MY_POOL" } "/secondapp*" { pool "MY_POOL" } "/thirdapp" { pool "MY_POOL" } } }
移住目標 #
この構成の目的は以下のとおりです。
- 複数のアプリケーションパスを一致させる
- 一致するすべてのトラフィックを同じバックエンドプールにルーティングする
- アプリケーションのルーティングロジックを簡素化する
RELIANOID 移行アプローチ #
In RELIANOIDこれは、スクリプトを使用せずに以下の方法で実現できます。
- 単一のHTTP/Sサービス
- URIパターンマッチング
- 正規表現 (正規表現)
- 共有バックエンド構成
この方法は、複数の条件付きiRuleを使用するよりも、シンプルで分かりやすく、メンテナンスも容易です。
RELIANOID #
MFAデバイスに移動する ファーム > HTTP/Sファーム > サービス (NAIST) と 創造する 新しいサービス。
URIマッチング設定 #
URLパターンでは、以下の正規表現を使用します。
^/(最初のアプリ | 2 番目のアプリ | 3 番目のアプリ)
バックエンドの設定 #
サービスにバックエンドリストの設定を追加します。
このアプローチが推奨される理由 #
単一の正規表現ベースのサービスを使用することで、以下のことが可能になります。
- よりクリーンな構成
- メンテナンスが容易
- サービス数の削減
- スケーラビリティの向上
- トラブルシューティングの簡素化
複数のiRule条件を管理する代わりに、URIロジックは1つのマッチングルールに集約されます。
検証 #
CURLでテストします。例：
カール -k https://example.com/firstapp -v
または：
カール -k https://example.com/secondapp/api/test -v
期待される結果：
- リクエストは設定済みのバックエンドプールに転送されます。
- アプリケーションは正常に応答します
トラブルシューティング #
リクエストが一致しません #
確認してください：
- 正規表現モードが有効になっています
- URIパターンは正しい
- 隠しスペースや無効な正規表現構文は使用しないでください。
一部のアプリケーションのみが動作します #
チェック：
- 正規表現には必要なアプリケーション名がすべて含まれています
- URIの大文字化動作
RELIANOID 正規表現によるマッチングは、特に設定がない限り、大文字と小文字を区別します。
大文字小文字を区別しないマッチングが必要な場合は、以下を使用してください。
(?i)^/(最初のアプリ | 2 番目のアプリ | 3 番目のアプリ)
デフォルトサービスに送信されるトラフィック #
これは通常、次のことを示します。
- 正規表現の不一致
- サービス注文に関する問題
- URI正規化の違い
代替アプローチ #
複数のサービスを作成することも可能ですが、一般的には以下のような場合には推奨されません。
- すべてのアプリケーションは同じバックエンドプールを共有します
- ルーティングロジックは同じです
正規表現に基づく単一のサービスの方が効率的です。
ベストプラクティス #
- 類似のアプリケーションは可能な限り共有サービスにまとめる。
- 意図しない一致を避けるため、正規表現は慎重に使用してください。
- URIマッチングロジックは一元管理する
- 運用上の可視性を確保するための正規表現ルールを文書化する
製品概要 #
URIベースのプール選択を実行するF5 iRulesは、 RELIANOID ネイティブHTTP/Sサービスと正規表現パターンを照合して使用します。
このアプローチにより、同等のアプリケーションルーティング動作を維持しながら、設定が簡素化されます。
