Marché #
Cet article explique comment migrer une iRule F5 BIG-IP qui achemine plusieurs URI d'application vers le même pool backend. RELIANOID utilisation de la correspondance de services HTTP/S natifs et des modèles d'URI d'expressions régulières (regex).
La règle iRule d'origine évalue l'URI entrante et envoie le trafic correspondant à plusieurs chemins d'application vers le même pool backend.
iRule F5 d'origine #
when HTTP_REQUEST { switch -glob [string tolower [HTTP::uri]] { "/firstapp*" { pool "MY_POOL" } "/secondapp*" { pool "MY_POOL" } "/thirdapp" { pool "MY_POOL" } } }
Objectif de migration #
L'objectif de cette configuration est :
- Correspondance de plusieurs chemins d'application
- Acheminer tout le trafic correspondant vers le même pool backend
- Simplifier la logique de routage des applications
RELIANOID Approche migratoire #
In RELIANOID, cela peut être réalisé sans script en utilisant :
- Un seul service HTTP/S
- correspondance de modèles d'URI
- Expressions régulières (regex)
- Configuration du backend partagé
Cette approche est plus simple, plus propre et plus facile à maintenir que plusieurs iRules conditionnelles.
RELIANOID Configuration #
Accédez à Fermes > Ferme HTTP/S > Services et Créer un nouveau service.
Configuration de correspondance des URI #
Dans le modèle d'URL, utilisez l'expression régulière :
^/(première application | deuxième application | troisième application)
Configuration des backends #
Ajoutez la configuration de la liste backend au service.
Pourquoi cette approche est recommandée #
L'utilisation d'un service unique basé sur les expressions régulières offre les avantages suivants :
- Configuration plus propre
- Maintenance simplifiée
- Nombre de services réduit
- Meilleure évolutivité
- Dépannage simplifié
Au lieu de gérer plusieurs conditions iRule, la logique URI est centralisée dans une seule règle de correspondance.
Validation #
Test avec CURL. Exemple :
curl -k https://example.com/firstapp -v
Ou:
curl -k https://example.com/secondapp/api/test -v
Résultat attendu:
- La requête est transmise au pool backend configuré.
- L'application répond normalement
Dépannage #
Requêtes ne correspondant pas #
Vérifier:
- Le mode Regex est activé
- Le modèle d'URI est correct.
- Aucun espace caché ni syntaxe d'expression régulière invalide
Seules certaines applications fonctionnent #
Vérifier:
- L'expression régulière inclut tous les noms d'application requis.
- Comportement de mise en majuscules des URI
RELIANOID La correspondance des expressions régulières est sensible à la casse, sauf configuration contraire.
Si une correspondance insensible à la casse est nécessaire, utilisez :
(?i)^/(première application | deuxième application | troisième application)
Trafic envoyé au service par défaut #
Cela indique généralement :
- Incompatibilité d'expression régulière
- Problème de commande de service
- Différences de normalisation de l'URI
Approche alternative #
Bien que la création de plusieurs services soit également possible, cette solution est généralement déconseillée lorsque :
- Toutes les applications partagent le même pool de backend
- La logique de routage est identique
Un service unique basé sur les expressions régulières est plus efficace.
Pratiques d'excellence #
- Regroupez les applications similaires en services partagés lorsque cela est possible.
- Utilisez les expressions régulières avec précaution pour éviter les correspondances non intentionnelles.
- Centralisez la logique de correspondance des URI
- Règles d'expression régulière du document pour la visibilité opérationnelle
Résumé #
Les iRules F5 effectuant une sélection de pool basée sur les URI peuvent être migrées vers RELIANOID Utilisation d'un service HTTP/S natif correspondant à des modèles d'expressions régulières.
Cette approche simplifie la configuration tout en conservant un comportement de routage applicatif équivalent.
