Panoramica #

Questo articolo spiega come migrare un iRule F5 BIG-IP che instrada più URI di applicazioni allo stesso pool di backend in RELIANOID Utilizzo della corrispondenza nativa del servizio farm HTTP/S e dei modelli URI basati su espressioni regolari (regex).

L'iRule originale valuta l'URI in entrata e invia il traffico corrispondente a diversi percorsi applicativi allo stesso pool di backend.

iRule F5 originale #

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

Obiettivo migratorio #

Lo scopo di questa configurazione è:

• Corrispondenza di più percorsi applicativi
• Instradare tutto il traffico corrispondente allo stesso pool di backend.
• Semplificare la logica di instradamento dell'applicazione.

RELIANOID Approccio alla migrazione #

In RELIANOID, questo può essere ottenuto senza scripting utilizzando:

• Un unico servizio HTTP/S
• corrispondenza del modello URI
• Espressioni regolari (regex)
• Configurazione backend condivisa

Questo approccio è più semplice, più pulito e più facile da gestire rispetto a molteplici iRules condizionali.

RELIANOID Configurazione #

Accedere a Farm > Farm HTTP/S > Servizi and Crea un nuovo servizio.

Configurazione di corrispondenza URI #

Nel pattern URL utilizzare l'espressione regolare:

^/(primaapp|secondaapp|terzaapp)

Configurazione dei backend #

Aggiungi la configurazione dell'elenco backend nel servizio.

Perché questo approccio è consigliato #

L'utilizzo di un singolo servizio basato su espressioni regolari offre:

• Configurazione più pulita
• Manutenzione più semplice
• Numero ridotto di servizi
• Migliore scalabilità
• Risoluzione dei problemi semplificata

Anziché gestire più condizioni iRule, la logica URI è centralizzata in un'unica regola di corrispondenza.

Convalida #

Test con CURL. Esempio:

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

Oppure:

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

Risultato atteso:

• La richiesta viene inoltrata al pool di backend configurato.
• L'applicazione risponde normalmente

Troubleshooting #

Richieste non corrispondenti #

Verificare:

• La modalità Regex è abilitata
• Il modello URI è corretto
• Nessuno spazio nascosto o sintassi regex non valida

Solo alcune applicazioni funzionano #

Dai un'occhiata:

• Regex include tutti i nomi delle applicazioni richiesti
• comportamento di capitalizzazione dell'URI

RELIANOID La corrispondenza delle espressioni regolari è sensibile alle maiuscole e minuscole, a meno che non sia configurata diversamente.

Se è necessaria la corrispondenza senza distinzione tra maiuscole e minuscole, utilizzare:

(?i)^/(primaapp|secondaapp|terzaapp)

Traffico inviato al servizio predefinito. #

Di solito questo indica:

• Errore di corrispondenza nell'espressione regolare
• Problema relativo all'ordinazione del servizio
• differenze di normalizzazione URI

Approccio alternativo #

Sebbene sia possibile creare anche più servizi, questa pratica non è generalmente consigliata quando:

• Tutte le applicazioni condividono lo stesso pool di backend
• La logica di routing è identica

Un singolo servizio basato su espressioni regolari è più efficiente.

Best Practices #

• Quando possibile, raggruppa le applicazioni simili in servizi condivisi.
• Utilizza le espressioni regolari con cautela per evitare corrispondenze indesiderate.
• Mantenere centralizzata la logica di corrispondenza degli URI.
• Documentare le regole regex per la visibilità operativa

Sintesi #

Le iRules F5 che eseguono la selezione del pool basata su URI possono essere migrate in RELIANOID Utilizzo della corrispondenza dei servizi HTTP/S nativi con modelli di espressioni regolari.

Questo approccio semplifica la configurazione mantenendo un comportamento di routing dell'applicazione equivalente.