I bilanciatori del carico delle applicazioni Google Cloud e Traffic Director utilizzano una risorsa di configurazione di Google Cloud denominata mappa URL per instradare le richieste HTTP(S) ai servizi o ai bucket di backend.
Ad esempio, con un bilanciatore del carico delle applicazioni esterno, puoi utilizzare una singola mappa URL per instradare le richieste a destinazioni diverse in base alle regole configurate nella mappa URL:
- Le richieste per
https://example.com/video
vanno a un servizio di backend. - Le richieste per
https://example.com/audio
vanno a un altro servizio di backend.
- Le richieste per
https://example.com/images
vanno a un bucket di backend Cloud Storage.
- Le richieste per qualsiasi altra combinazione di host e percorso vanno a un servizio di backend predefinito.
Le mappe URL vengono utilizzate con i seguenti prodotti Google Cloud:
- Bilanciatore del carico delle applicazioni esterno (modalità globale, regionale e classica)
- Bilanciatore del carico delle applicazioni interno (modalità tra regioni e regioni)
- Traffic Director, quando viene eseguito il deployment di Traffic Director con le API di bilanciamento del carico
Sono disponibili due tipi di risorse di mappe URL: globali e a livello di regione. Il tipo di risorsa che utilizzi dipende dallo schema di bilanciamento del carico del prodotto.
Prodotto | Schema di bilanciamento del carico | Tipo di risorsa mappa URL | Destinazioni supportate |
---|---|---|---|
Bilanciatore del carico delle applicazioni esterno globale | EXTERNAL_MANAGED |
Globale, esterna | Servizi di backend, bucket di backend |
Bilanciatore del carico delle applicazioni classico | EXTERNAL |
Globale, esterna | Servizi di backend, bucket di backend |
Bilanciatore del carico delle applicazioni esterno regionale | EXTERNAL_MANAGED |
A livello di regione, esterno | Servizi di backend |
Bilanciatore del carico delle applicazioni interno tra regioni | INTERNAL_MANAGED |
Globale, interna | Servizi di backend |
Bilanciatore del carico delle applicazioni interno regionale | INTERNAL_MANAGED |
A livello di regione, interno | Servizi di backend |
Traffic Director | INTERNAL_SELF_MANAGED |
Globale, interna | Servizi di backend |
Non tutte le funzionalità delle mappe URL sono disponibili per tutti i prodotti. Le mappe URL utilizzate con bilanciatori del carico delle applicazioni esterni globali, Application Load Balancer esterni regionali, Application Load Balancer interni e Traffic Director supportano anche diverse funzionalità avanzate di gestione del traffico. Per maggiori informazioni su queste differenze, consulta Confronto delle funzionalità dei bilanciatori del carico: routing e gestione del traffico. Inoltre, le mappe URL a livello di regione possono essere una risorsa designata come servizio in App Hub, che è in anteprima.
Come funzionano le mappe URL
Quando una richiesta arriva al bilanciatore del carico, quest'ultimo instrada la richiesta a un determinato servizio di backend o a un bucket di backend in base alle regole definite nella mappa URL.
Un servizio di backend rappresenta una raccolta di backend, ovvero istanze di un'applicazione o di un microservizio.Un bucket di backend è un bucket Cloud Storage, solitamente utilizzato per ospitare contenuti statici, come le immagini.
Per i bilanciatori del carico delle applicazioni esterni regionali, i bilanciatori del carico delle applicazioni interni e Traffic Director, le possibili destinazioni sono le seguenti:
- Servizio di backend predefinito
- Servizio di backend non predefinito
Inoltre, i bilanciatori del carico delle applicazioni esterni globali supportano quanto segue:
- Bucket di backend predefinito
- Bucket di backend non predefinito
Ad esempio, supponiamo di avere la seguente configurazione:
- Un indirizzo IP:
- Tutte le richieste alla tua organizzazione vanno allo stesso indirizzo IP e allo stesso bilanciatore del carico.
- Il traffico viene indirizzato a servizi di backend diversi in base all'URL della richiesta.
- Due domini:
example.net
ospita video di formazione.example.org
ospita il sito web della tua organizzazione.
- Quattro insiemi di server:
- Uno ospita il sito web della tua organizzazione (servizio di backend:
org-site
). - Uno ospita il sito web complessivo del video di formazione (servizio di backend:
video-site
). - Uno ospita video di addestramento in alta definizione (HD) (servizio di backend:
video-hd
). - Uno ospita video di addestramento in definizione standard (SD) (servizio di backend:
video-sd
).
- Uno ospita il sito web della tua organizzazione (servizio di backend:
Vuoi che si verifichi quanto segue:
- Richieste a
example.org
(o a qualsiasi dominio diverso daexample.net
) per passare al servizio di backendorg-site
. - Richieste a
example.net
che non corrispondono a percorsi più specifici per accedere al servizio di backendvideo-site
. - Richieste a
example.net/video/hd/*
di andare al servizio di backendvideo-hd
. - Richieste a
example.net/video/sd/*
di andare al servizio di backendvideo-sd
.
Un valore --path-rule
per /video/*
corrisponde a URI come /video/test1
e /video/test2
. Tuttavia, questa regola del percorso non corrisponde al percorso
/video
.
Se il bilanciatore del carico riceve una richiesta con /../
nell'URL, il bilanciatore del carico trasforma l'URL rimuovendo il segmento di percorso prima di ..
e risponde con l'URL trasformato. Ad esempio, quando viene inviata una richiesta per http://example.net/video/../abc
, il bilanciatore del carico risponde con un reindirizzamento 302 a http://example.net/abc
. La maggior parte dei client reagisce inviando una
richiesta all'URL restituito dal bilanciatore del carico (in questo caso,
http://example.net/abc
). Questo reindirizzamento 302 non viene registrato in
Cloud Logging.
La mappa URL ti consente di configurare questo tipo di routing basato su host e percorsi.
Denominazione
Ogni mappa URL ha un nome. Quando crei un bilanciatore del carico basato su HTTP(S) utilizzando la console Google Cloud, alla mappa URL viene assegnato un nome. È lo stesso nome del bilanciatore del carico nella console Google Cloud. Se utilizzi Google Cloud CLI o l'API, puoi definire un nome personalizzato per la mappa URL.
Componenti della mappa URL
Una mappa URL è un insieme di risorse di configurazione di Google Cloud che indirizza le richieste degli URL ai servizi di backendo ai bucket di backend. A tale scopo, la mappa URL utilizza le porzioni nome host e percorso per ciascun URL elaborato:
- Un nome host è la parte del nome di dominio di un URL; ad esempio, la parte del nome host dell'URL
http://example.net/video/hd
èexample.net
. - Un percorso è la parte di un URL che segue il nome host e il numero di porta facoltativo; ad esempio, la parte del percorso dell'URL
http://example.net/video/hd
è/video/hd
.
Questo diagramma mostra la struttura degli oggetti di configurazione per il bilanciamento del carico in relazione tra loro.
Puoi controllare quali servizi o bucket di backend ricevono le richieste in entrata utilizzando i seguenti parametri di configurazione della mappa URL:
- Servizio di backend predefinito o bucket di backend predefinito. Quando crei una mappa URL, devi specificare un servizio di backend predefinito o un bucket di backend predefinito, ma non entrambi. Questa impostazione predefinita rappresenta il servizio di backend o il bucket di backend a cui Google Cloud indirizza le richieste per gli URL con qualsiasi nome host, a meno che non esista una regola host applicabile.
Regola host (
hostRules
). Una regola host indirizza le richieste inviate a uno o più nomi host associati a un singolo matcher di percorso (pathMatchers
). La porzione del nome host di un URL corrisponde esattamente all'insieme di nomi host configurati della regola host. In una regola host e percorso della mappa URL, se ometti l'host, la regola corrisponde a qualsiasi host richiesto. Per indirizzare le richieste perhttp://example.net/video/hd
a un matcher di percorso, è necessaria una singola regola host che includa almeno il nome hostexample.net
. La stessa regola host potrebbe gestire anche le richieste per altri nomi host, ma le indirizzerebbe allo stesso matcher di percorso.Se devi indirizzare le richieste a matcher di percorso diversi, devi utilizzare regole host diverse. Due regole host in una mappa URL non possono includere lo stesso nome host.
È possibile trovare una corrispondenza con tutti i nomi host specificando il carattere jolly
*
nella regola host. Ad esempio, per gli URLhttp://example.org
,http://example.net/video/hd
ehttp://example.com/audio
, tutti e tre i nomi hostexample.org
,example.net
eexample.com
possono essere abbinati specificando*
nella regola host. È anche possibile trovare una corrispondenza con un nome host parziale specificando il carattere jolly*
. Ad esempio, una regola host*.example.net
viene confrontata con entrambi i nomi hostnews.example.net
efinance.example.net
.- Numero di porta. I bilanciatori del carico delle applicazioni
gestiscono i numeri di porta in modo differente. Nel caso del bilanciatore del carico delle applicazioni interno, puoi utilizzare il parametro Regola host per specificare un numero di porta. Ad esempio, per
indirizzare le richieste
example.net
per la porta 8080, imposta la regola host suexample.net:8080
. Nel caso del bilanciatore del carico delle applicazioni classico, viene considerato solo il nome host nell'URL per la corrispondenza di una regola host. Ad esempio, le richiesteexample.net
per la porta 8080 e la porta 80 corrispondono alla regola hostexample.net
.
- Numero di porta. I bilanciatori del carico delle applicazioni
gestiscono i numeri di porta in modo differente. Nel caso del bilanciatore del carico delle applicazioni interno, puoi utilizzare il parametro Regola host per specificare un numero di porta. Ad esempio, per
indirizzare le richieste
Matcher percorso (
pathMatchers
). Un matcher percorso è il parametro di configurazione a cui fa riferimento una regola host. Definisce la relazione tra la parte del percorso di un URL e il servizio di backend o il bucket di backend che deve gestire la richiesta. Un matcher di percorso è composto da due elementi:Servizio di backend predefinito dello strumento di abbinamento del percorso o bucket di backend predefinito dello strumento di abbinamento del percorso. Per ogni matcher di percorso, devi almeno specificare un servizio di backend o un bucket di backend predefinito, ma non entrambi. Questa impostazione predefinita rappresenta il servizio di backend o il bucket di backend a cui Google Cloud indirizza le richieste per gli URL i cui nomi host corrispondono a una regola host associata al matcher del percorso e i cui percorsi degli URL non corrispondono a nessuna regola del percorso nel matcher del percorso.
Regole percorso. Per ogni matcher di percorso, puoi specificare una o più regole di percorso, ovvero coppie chiave-valore che mappano un percorso URL a un singolo servizio di backend o bucket di backend. La prossima sezione contiene ulteriori informazioni sul funzionamento delle regole del percorso.
Ordine delle operazioni
Per un determinato nome host e percorso in un URL richiesto, Google Cloud utilizza la seguente procedura per indirizzare la richiesta al servizio di backend o al bucket di backendcorretto, come configurato nella mappa URL:
Se la mappa URL non contiene una regola host per il nome host dell'URL, Google Cloud indirizza le richieste al servizio di backend predefinito o al bucket di backend predefinitodella mappa URL, a seconda di quale hai definito.
Se la mappa URL contiene una regola host che include il nome host dell'URL, viene consultato il matcher del percorso a cui fa riferimento la regola host:
Se il matcher di percorso contiene una regola di percorso che corrisponde esattamente al percorso dell'URL, Google Cloud indirizza le richieste al servizio di backend o al bucket di backend per quella regola di percorso.
Se il matcher di percorso non contiene una regola di percorso che corrisponde esattamente al percorso dell'URL, ma contiene una regola di percorso che termina con
/*
il cui prefisso corrisponde alla sezione più lunga del percorso dell'URL, Google Cloud indirizza le richieste al servizio di backend o al bucket di backend per quella regola del percorso. Ad esempio, per la mappa URL contenente due regole dello strumento di abbinamento del percorso/video/hd/movie1
e/video/hd/*
, se l'URL contiene il percorso esatto/video/hd/movie1
, viene abbinata alla regola del percorso.Se nessuna delle condizioni precedenti è vera, Google Cloud indirizza le richieste al servizio di backend predefinito o al bucket di backend predefinitodel matcher di percorso, a seconda di quale hai definito.
Vincoli dello strumento di abbinamento del percorso
I nomi host, i matcher di percorso e le regole per il percorso hanno dei vincoli.
Caratteri jolly, espressioni regolari e URL dinamici nelle regole per il percorso
Una regola di percorso può includere solo un carattere jolly (
*
) dopo una barra (/
). Ad esempio,/videos/*
e/videos/hd/*
sono validi per le regole di percorso, mentre/videos*
e/videos/hd*
non lo sono.Le regole percorso non utilizzano espressioni regolari o corrispondenze di sottostringhe. PathTemplateMatch può utilizzare operatori di corrispondenza dei percorsi semplificati. Ad esempio, le regole percorso per
/videos/hd
o/videos/hd/*
non si applicano a un URL con percorso/video/hd-abcd
. ma una regola percorso per/video/*
si applica a questo percorso.I matcher di percorso (e le mappe URL in generale) non offrono funzionalità che funzionano come le istruzioni
LocationMatch
Apache. Se hai un'applicazione che genera percorsi di URL dinamici con un prefisso comune, come/videos/hd-abcd
e/videos/hd-pqrs
, e hai bisogno di inviare richieste effettuate a questi percorsi a diversi servizi di backend, potresti non riuscire a farlo con una mappa URL. Per i casi contenenti solo pochi possibili URL dinamici, potresti creare un matcher di percorso con un insieme limitato di regole di percorso. Per casi più complessi, devi eseguire nei backend la corrispondenza tramite espressioni regolari basata su percorsi.
Caratteri jolly e operatori di corrispondenza dei pattern nei modelli di percorso per le regole di route
Gli operatori di corrispondenza dei pattern flessibili ti consentono di abbinare più parti di un percorso URL, inclusi URL parziali e suffissi (estensioni file), utilizzando la sintassi con caratteri jolly. Questi operatori possono essere utili quando devi instradare il traffico ed eseguire riscritture in base a percorsi di URL complessi. Puoi anche associare uno o più componenti del percorso a variabili con nome per poi fare riferimento a queste variabili quando riscrivi l'URL. Con le variabili con nome, puoi riordinare e rimuovere i componenti dell'URL prima che la richiesta venga inviata all'origine.
La corrispondenza di pattern con caratteri jolly è supportata solo per i seguenti prodotti:
- Bilanciatore del carico delle applicazioni esterno globale
- Bilanciatore del carico delle applicazioni esterno regionale
- Bilanciatore del carico delle applicazioni interno regionale
- Bilanciatore del carico delle applicazioni interno tra regioni
- Traffic Director
L'esempio seguente instrada il traffico per un'applicazione di e-commerce che offre servizi separati per le informazioni del carrello e le informazioni degli utenti.
Puoi configurare routeRules
con operatori di corrispondenza dei pattern flessibili e variabili con nome per inviare l'ID univoco dell'utente alla pagina dei dettagli di un account utente e le informazioni del carrello dell'utente a un servizio di elaborazione del carrello dopo aver riscritto l'URL.
pathMatchers:
- name: cart-matcher
routeRules:
- description: CartService
matchRules:
- pathTemplateMatch: '/xyzwebservices/v2/xyz/users/{username=*}/carts/{cartid=**}'
service: cart-backend
priority: 1
routeAction:
urlRewrite:
pathTemplateRewrite: '/{username}-{cartid}/'
- name: user-matcher
routeRules:
- description: UserService
matchRules:
- pathTemplateMatch: '/xyzwebservices/v2/xyz/users/*/accountinfo/*'
service: user-backend
priority: 1
Ecco cosa succede quando un client richiede /xyzwebservices/v2/xyz/users/abc@xyz.com/carts/FL0001090004/entries/SJFI38u3401nms?fields=FULL&client_type=WEB
, che contiene sia informazioni dell'utente che del carrello:
- Il percorso della richiesta corrisponde a
pathTemplateMatch
in pathMatchercart-matcher
. La variabile{username=*}
corrisponde aabc@xyz.com
e la variabile{cartid=**}
corrisponde aFL0001090004/entries/SJFI38u3401nms
. - I parametri di ricerca vengono separati dal percorso, il percorso viene riscritto
in base al valore
pathTemplateRewrite
e iparametri di ricercay vengono aggiunti al percorso riscritto. Dobbiamo utilizzare esclusivamente le stesse variabili che abbiamo utilizzato per definirepathTemplateMatch
nel nostropathTemplateRewrite
. - La richiesta riscritta viene inviata a
cart-backend
con il percorso dell'URL riscritto:/abc@xyz.com-FL0001090004/entries/SJFI38u3401nms?fields=FULL&client_type=WEB
.
Quando un client richiede invece /xyzwebservices/v2/xyz/users/abc%40xyz.com/accountinfo/abc-1234
, che dispone solo dei dati dell'utente e dell'account:
- Il percorso della richiesta corrisponde a
pathTemplateMatch
in pathMatcheruser-matcher
. Il primo*
corrisponde aabc%40xyz.com
e il secondo*
corrisponde aabc-1234
. - La richiesta viene inviata a
user-backend
.
La seguente tabella illustra la sintassi per i pattern del modello di percorso.
Operatore | Corrisponde a |
---|---|
* |
Un singolo segmento di percorso, escluso i caratteri / separatori del percorso circostanti. |
** |
Corrisponde a zero o più caratteri, inclusi eventuali separatori di percorso / tra più segmenti del percorso. Se sono inclusi altri operatori, l'operatore ** deve essere l'ultimo. |
{name} oppure {name=*} |
Una variabile denominata corrispondente a un segmento del percorso. Corrisponde a un singolo segmento di percorso, esclusi i / caratteri separatori del percorso circostanti. |
{name=news/*} |
Una variabile con nome che corrisponde esplicitamente a due segmenti di percorso:
news e un segmento con caratteri jolly * . |
{name=*/news/*} |
Una variabile denominata che corrisponde a tre segmenti di percorso. |
{name=**} |
Una variabile con nome che corrisponde a zero o più caratteri. Se presente, deve essere l'ultimo operatore. |
Quando utilizzi questi operatori per la corrispondenza flessibile con pattern, tieni presente le seguenti considerazioni:
- È possibile combinare più operatori in un unico pattern.
- I parametri di query vengono separati dal percorso, il percorso viene riscritto
in base al valore
pathTemplateRewrite
e iparametri di ricercay vengono aggiunti al percorso riscritto. - Le richieste non sono con codifica percentuale normalizzata. Ad esempio, un URL con un carattere barra con codifica percentuale (%2F) non viene decodificato nel formato non codificato.
- Ogni nome di variabile, ad esempio
{segment}
o{region}
, può apparire solo una volta nello stesso pattern. Più variabili con lo stesso nome non sono valide e vengono rifiutate. - I nomi delle variabili sono sensibili alle maiuscole e devono essere identificatori validi. Per verificare se un nome di variabile è valido, assicurati che corrisponda all'espressione regolare
^[a-zA-Z][a-zA-Z0-9_]*$
.{API}
,{api}
e{api_v1}
sono tutti identificatori validi. Identificano tre variabili distinte.{1}
,{_api}
e{10alpha}
non sono identificatori validi.
- È previsto un limite di cinque operatori per pattern di modello.
Per eseguire una riscrittura facoltativa dell'URL prima che la richiesta venga inviata all'origine,
puoi utilizzare le stesse variabili che hai definito per acquisire un percorso.
Ad esempio, puoi fare riferimento, riordinare oppure omettere le variabili nel campo pathTemplateRewrite
quando definisci urlRewrite
.
Quando utilizzi variabili e operatori per la corrispondenza flessibile con pattern per le riscritture degli URL, tieni presente quanto segue:
- Quando riscrivi un URL, puoi omettere le variabili se non sono richieste come parte dell'URL riscritto.
- Prima di qualsiasi riscrittura, puoi identificare l'URL inviato dal client alla tua origine controllando le intestazioni delle risposte. L'URL del client originale viene compilato con le intestazioni
x-client-request-url
ex-envoy-original-path
.
Nome host e relazione regola host
Un nome host può fare riferimento solo a una singola regola host.
Una singola regola host può elaborare più nomi host.
Relazione del matcher tra regola host e percorso
Più regole host possono fare riferimento a un singolo matcher percorso.
Una regola host può fare riferimento a un solo matcher di percorso.
Il seguente diagramma illustra questi punti.
URL e relazione backend
Ogni URL univoco è indirizzato a un solo servizio o bucket di backend. Di conseguenza:
Google Cloud utilizza la parte del nome host di un URL per selezionare una singola regola host e il relativo matcher del percorso di riferimento.
Quando utilizzi le regole del percorso in un matcher percorso, non puoi creare più di una regola del percorso per lo stesso percorso. Ad esempio, le richieste per
/videos/hd
non possono essere indirizzate a più di un servizio di backend o di un bucket di backend. I servizi di backend possono avere gruppi di istanze di backend o gruppi di endpoint di rete (NEG) di backend in zone e regioni diverse; puoi creare bucket di backend che utilizzano classi di archiviazione su più regioni.Per indirizzare il traffico per un URL univoco a più servizi, puoi utilizzare regole di route anziché regole di percorso. Se configuri il matcher di percorso con regole di route per le corrispondenze di intestazione o parametri, un URL univoco può essere indirizzato a più di un servizio di backend o di un bucket, in base ai contenuti delle intestazioni o dei parametri di ricerca dell'URL.
Allo stesso modo, per i bilanciatori del carico delle applicazioni esterni regionali e Traffic Director, i servizi di backend ponderati sulle azioni di route possono indirizzare lo stesso URL a più servizi di backend o bucket, a seconda delle ponderazioni impostate sul servizio di backend ponderato.
Mappe e protocolli URL
Puoi utilizzare la stessa mappa URL, le stesse regole host e gli stessi matcher di percorso per elaborare le richieste HTTP e HTTPS inviate dai client, a condizione che un proxy HTTP di destinazione e un proxy HTTPS di destinazione facciano riferimento alla mappa degli URL.
Mappa URL più semplice
La mappa URL più semplice ha solo un servizio di backend predefinito o un bucket di backend predefinito. Non contiene regole host né matcher di percorso. Il servizio di backend predefinito o il bucket di backend predefinito (a seconda di quale hai definito) gestisce tutti gli URL richiesti.
Se definisci un servizio di backend predefinito, Google Cloud indirizza le richieste ai gruppi di istanza di backend o ai NEG di backend in base alla configurazione del servizio di backend.
Esempio di flusso di lavoro della mappa di URL con un bilanciatore del carico delle applicazioni esterno
L'esempio seguente illustra l'ordine delle operazioni per una mappa URL. Questo esempio configura solo la mappa URL per un bilanciatore del carico delle applicazioni classico esistente. Per semplicità concettuale, utilizza solo i servizi di backend, ma puoi sostituire i bucket di backend. Per scoprire come creare gli altri componenti del bilanciatore del carico, consulta Creare un bilanciatore del carico delle applicazioni classico.
Per saperne di più sulla creazione e sulla configurazione delle mappe URL con matcher di percorso e regole host, consulta la documentazione di gcloud compute url-maps create
.
Crea una mappa URL per il bilanciatore del carico e specifica un servizio di backend predefinito. Questo esempio crea una mappa URL denominata
video-org-url-map
che fa riferimento a un servizio di backend esistente denominatoorg-site
.gcloud compute url-maps create video-org-url-map \ --default-service=org-site
Crea un matcher di percorso denominato
video-matcher
con le seguenti caratteristiche:- Il servizio di backend predefinito è
video-site
, un servizio di backend esistente. - Aggiungi regole di percorso che indirizzano le richieste per il percorso esatto dell'URL
/video/hd
o il prefisso del percorso dell'URL/video/hd/*
a un servizio di backend esistente denominatovideo-hd
. - Aggiungi regole di percorso che indirizzano le richieste per il percorso esatto dell'URL
/video/sd
o il prefisso del percorso dell'URL/video/sd/*
a un servizio di backend esistente denominatovideo-sd
.
gcloud compute url-maps add-path-matcher video-org-url-map \ --path-matcher-name=video-matcher \ --default-service=video-site \ --path-rules=/video/hd=video-hd,/video/hd/*=video-hd,/video/sd=video-sd,/video/sd/*=video-sd
- Il servizio di backend predefinito è
Crea una regola host per il nome host
example.net
che fa riferimento al matcher di percorsovideo-matcher
.gcloud compute url-maps add-host-rule video-org-url-map \ --hosts=example.net \ --path-matcher-name=video-matcher
La mappa URL video-org-url-map
dovrebbe avere il seguente aspetto:
gcloud compute url-maps describe video-org-url-map
creationTimestamp: '2021-03-05T13:34:15.833-08:00' defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/org-site fingerprint: mfyJIT7Zurs= hostRules: - hosts: - '*' pathMatcher: video-matcher - hosts: - example.net pathMatcher: video-matcher id: '8886405179645041976' kind: compute#urlMap name: video-org-url-map pathMatchers: - defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-site name: video-matcher pathRules: - paths: - /video/hd - /video/hd/* service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-hd - paths: - /video/sd - /video/sd/* service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-sd selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/urlMaps/video-org-url-map
La mappa URL video-org-url-map
indirizza gli URL richiesti ai backend nel seguente modo.
La tabella seguente spiega l'elaborazione delle richieste mostrata nel diagramma precedente.
Nome host | Percorsi degli URL | Servizio di backend selezionato | Motivo della selezione |
---|---|---|---|
Nome host:example.org e tutti gli altri nomi host
diversi daexample.net |
tutti i percorsi | org-site |
Il nome host non è presente in alcuna regola host della mappa URL, quindi la richiesta viene indirizzata al servizio di backend predefinito della mappa URL. |
Nome host:example.net |
/video /video/examples |
video-site |
La richiesta va al servizio di backend predefinito perché non esiste una regola di percorso per /video/ o /video/* . La regola host per example.net fa riferimento a un matcher di percorso, ma quel matcher di percorso non ha regole di percorso che si applicherebbero a questi percorsi.
|
Nome host:example.net |
/video/hd /video/hd/movie1 /video/hd/movies/movie2 Altri URL che iniziano con /video/hd/* |
video-hd |
Una regola host per example.net fa riferimento a un matcher di percorso le cui regole di percorso indirizzano le richieste per i percorsi dell'URL che corrispondono esattamente a /video/hd o che iniziano con /video/hd/* al servizio di backend video-hd . |
Nome host:example.net |
/video/sd /video/sd/show1 /video/sd/shows/show2 Altri URL che iniziano con /video/sd/* |
video-sd |
Una regola host per example.net fa riferimento a un matcher di percorso le cui regole di percorso indirizzano le richieste per i percorsi dell'URL che corrispondono esattamente a /video/sd o che iniziano con /video/sd/* al servizio di backend video-sd . |
Reindirizzamenti URL
Un reindirizzamento di URL reindirizza i visitatori del tuo dominio da un URL a un altro.
Un reindirizzamento di URL predefinito non è condizionato dalla corrispondenza di un pattern particolare nella richiesta in entrata. Ad esempio, potresti voler utilizzare un reindirizzamento URL predefinito per reindirizzare qualsiasi nome host a un nome host di tua scelta.
Esistono diversi modi per creare un reindirizzamento URL, come illustrato nella tabella seguente.
Metodo | Configurazione |
---|---|
Reindirizzamento URL predefinito della mappa URL | defaultUrlRedirect di primo livello |
Il reindirizzamento dell'URL predefinito di un matcher di percorso | pathMatchers[].defaultUrlRedirect[] |
Reindirizzamento URL della regola di percorso di un matcher di percorso | pathMatchers[].pathRules[].urlRedirect |
Reindirizzamento URL della regola di route di un matcher di percorso | pathMatchers[].routeRules[].urlRedirect |
All'interno di un elemento defaultUrlRedirect
o urlRedirect
, pathRedirect
funziona sempre come segue:
- L'intero percorso di richiesta viene sostituito con il percorso specificato.
All'interno di un defaultUrlRedirect
o urlRedirect
, il funzionamento di prefixRedirect
dipende da come lo utilizzi:
- Se utilizzi
defaultUrlRedirect
,prefixRedirect
è in realtà un'anteposizione del prefisso perché il percorso corrispondente è sempre/
. - Se utilizzi un
urlRedirect
all'interno di una regola di route o di una regola di percorso di un matcher di percorso,prefixRedirect
è un prefisso di sostituzione in base alla corrispondenza del percorso richiesto come definito nella regola del percorso o nella regola di route.
Esempi di reindirizzamento
La seguente tabella fornisce alcuni esempi di configurazioni di reindirizzamento. La colonna di destra mostra la configurazione API per un reindirizzamento URL predefinito.
Cosa vuoi | Eseguito utilizzando un reindirizzamento URL predefinito |
---|---|
Reindirizzamento da HTTP a HTTPS Reindirizzamento http://host.name/path a https://host.name/path |
kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True |
Da HTTP a HTTPS + Reindirizzamento host Reindirizzamento http://nome-host-qualsiasi/percorso a https://www.example.com/percorso |
kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True hostRedirect: "www.example.com" |
da HTTP a HTTPS + reindirizzamento host + reindirizzamento percorso completo Reindirizzamento http://nome-host/percorso a https://www.example.com/newPath |
kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True hostRedirect: "www.example.com" pathRedirect: "/newPath" |
Da HTTP a HTTPS + Reindirizzamento host + Reindirizzamento prefisso Reindirizzamento http://any-host-name/originalPath a https://www.example.com/newPrefix/originalPath |
kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True hostRedirect: "www.example.com" prefixRedirect: "/newPrefix" |
Il seguente snippet parziale annota ogni risorsa API:
defaultUrlRedirect: redirectResponseCode: MOVED_PERMANENTLY_DEFAULT httpsRedirect: True # True if you want https://, false if you want http:// hostRedirect: "new-host-name.com" # Omit to keep the requested host pathRedirect: "/new-path" # Omit to keep the requested path; mutually exclusive to prefixRedirect prefixRedirect: "/newPrefix" # Omit to keep the requested path; mutually exclusive to pathRedirect stripQuery: False # True to omit everything in the URL after ? ...
Passaggi successivi
Per aggiungere, convalidare, testare, elencare o eliminare una mappa URL, consulta la sezione Utilizzare le mappe URL.
Per informazioni sulle mappe di regole di routing con Traffic Director, consulta Panoramica delle mappe di regole di routing di Traffic Director.