Übersicht #

Dieser Artikel erklärt, wie eine F5 BIG-IP iRule, die mehrere Anwendungs-URIs an denselben Backend-Pool weiterleitet, migriert wird nach RELIANOID unter Verwendung nativer HTTP/S-Farmdienste und regulärer Ausdrücke (Regex) für URI-Muster.

Die ursprüngliche iRule wertet die eingehende URI aus und leitet Datenverkehr, der zu mehreren Anwendungspfaden passt, an denselben Backend-Pool weiter.

Original F5 iRule #

when HTTP_REQUEST { switch -glob [string tolower [HTTP::uri]] { "/firstapp*" { pool "MY_POOL" } "/secondapp*" { pool "MY_POOL" } "/thirdapp" { pool "MY_POOL" } } }

Migrationsziel #

Der Zweck dieser Konfiguration ist:

• Mehrere Anwendungspfade abgleichen
• Leiten Sie den gesamten übereinstimmenden Datenverkehr an denselben Backend-Pool weiter.
• Anwendungsroutinglogik vereinfachen

RELIANOID Migrationsansatz #

In RELIANOIDDies kann ohne Skripte durch folgende Verwendung erreicht werden:

• Ein einziger HTTP/S-Dienst
• URI-Mustervergleich
• Reguläre Ausdrücke (regex)
• Gemeinsame Backend-Konfiguration

Dieser Ansatz ist einfacher, übersichtlicher und leichter zu pflegen als mehrere bedingte iRules.

RELIANOID Konfiguration #

Navigieren Sie zu Farms > HTTP/S Farm > Services und erstellen Sie einen neuen Dienst.

URI-Übereinstimmungskonfiguration #

Verwenden Sie im URL-Muster den regulären Ausdruck:

^/(erste App|zweite App|dritte App)

Backend-Konfiguration #

Fügen Sie die Backend-Listenkonfiguration im Dienst hinzu.

Warum diese Vorgehensweise empfohlen wird #

Die Verwendung eines einzigen auf regulären Ausdrücken basierenden Dienstes bietet folgende Vorteile:

• Sauberere Konfiguration
• Einfachere Wartung
• Reduzierte Serviceanzahl
• Bessere Skalierbarkeit
• Vereinfachte Fehlerbehebung

Anstatt mehrere iRule-Bedingungen zu verwalten, ist die URI-Logik in einer einzigen übereinstimmenden Regel zentralisiert.

Validierung #

Testen Sie mit CURL. Beispiel:

curl -k https://example.com/firstapp -v

Oder:

curl -k https://example.com/secondapp/api/test -v

Erwartetes Ergebnis:

• Die Anfrage wird an den konfigurierten Backend-Pool weitergeleitet.
• Die Anwendung reagiert normal

Problemlösung #

Anfragen stimmen nicht überein #

Überprüfen:

• Der Regex-Modus ist aktiviert.
• Das URI-Muster ist korrekt.
• Keine versteckten Leerzeichen oder ungültige Regex-Syntax

Nur einige Anwendungen funktionieren #

Prüfen:

• Der reguläre Ausdruck enthält alle erforderlichen Anwendungsnamen
• URI-Großschreibungsverhalten

RELIANOID Bei der Regex-Übereinstimmung wird zwischen Groß- und Kleinschreibung unterschieden, sofern nichts anderes konfiguriert ist.

Falls eine Suche ohne Berücksichtigung der Groß-/Kleinschreibung erforderlich ist, verwenden Sie Folgendes:

(?i)^/(firstapp|secondapp|thirdapp)

Datenverkehr an Standarddienst gesendet #

Dies weist normalerweise auf Folgendes hin:

• Regex-Fehler
• Servicebestellungsproblem
• URI-Normalisierungsunterschiede

Alternativer Ansatz #

Obwohl auch mehrere Dienste erstellt werden können, ist dies im Allgemeinen nicht empfehlenswert, wenn:

• Alle Anwendungen nutzen denselben Backend-Pool.
• Die Routing-Logik ist identisch

Ein einziger Dienst, der auf regulären Ausdrücken basiert, ist effizienter.

Praxisbeispiele #

• Ähnliche Anwendungen können nach Möglichkeit in gemeinsamen Diensten zusammengefasst werden.
• Reguläre Ausdrücke sollten mit Bedacht eingesetzt werden, um unbeabsichtigte Übereinstimmungen zu vermeiden.
• URI-Matching-Logik zentralisieren
• Dokumentieren Sie Regex-Regeln für die operative Transparenz

Zusammenfassung #

F5 iRules, die eine URI-basierte Poolauswahl durchführen, können migriert werden nach RELIANOID Verwendung nativer HTTP/S-Dienste zum Abgleich mit regulären Ausdrücken.

Dieser Ansatz vereinfacht die Konfiguration und erhält gleichzeitig das gleiche Routing-Verhalten der Anwendung bei.