Panoramica delle mappe URL

Google Cloud Application Load Balancers e Cloud Service Mesh utilizzano una risorsa di configurazione Google Cloud chiamata mappa URL per instradare le richieste HTTP(S) ai servizi di backend 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 (modi globale, regionale e classico)
• Bilanciatore del carico delle applicazioni interno (modalità tra regioni e regionale)
• Cloud Service Mesh, se Cloud Service Mesh viene disegnato con le API di bilanciamento del carico

Sono disponibili due tipi di risorse mappa URL: globali e regionali.

• I valori urlMaps globali vengono utilizzati da bilanciatori del carico delle applicazioni esterni globali, bilanciatori del carico delle applicazioni classici, bilanciatori del carico delle applicazioni interni tra regioni e Cloud Service Mesh.

• regionUrlMaps vengono utilizzati dai bilanciatori del carico delle applicazioni esterni regionali e dai bilanciatori del carico delle applicazioni interni regionali.

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	Servizi di backend, bucket di backend
Bilanciatore del carico delle applicazioni classico	EXTERNAL	Globale	Servizi di backend, bucket di backend
Bilanciatore del carico delle applicazioni esterno regionale	EXTERNAL_MANAGED	Regionale	Servizi di backend
Bilanciatore del carico delle applicazioni interno tra regioni	INTERNAL_MANAGED	Globale	Servizi di backend
Bilanciatore del carico delle applicazioni interno regionale	INTERNAL_MANAGED	Regionale	Servizi di backend
Cloud Service Mesh	INTERNAL_SELF_MANAGED	Globale	Servizi di backend

Non tutte le funzionalità della mappa degli URL sono disponibili per tutti i prodotti. Le mappe URL utilizzate con bilanciatori del carico delle applicazioni esterni globali, bilanciatori del carico delle applicazioni esterni regionali, bilanciatori del carico delle applicazioni interni e Cloud Service Mesh supportano anche diverse funzionalità avanzate di gestione del traffico. Per ulteriori 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 la inoltra a un determinato servizio di backendo 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, che viene comunemente 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 Cloud Service Mesh, 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 che tu abbia la seguente configurazione:

• Un indirizzo IP:
  • Tutte le richieste alla tua organizzazione vengono inviate allo stesso indirizzo IP e allo stesso bilanciatore del carico.
  • Il traffico viene indirizzato a diversi servizi di backend 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 dei video di formazione complessivi (servizio di backend: video-site).
  • Uno ospita video di formazione in alta definizione (HD) (servizio di backend: video-hd).
  • Uno ospita video di formazione in definizione standard (SD) (servizio di backend: video-sd).

Vuoi che si verifichi quanto segue:

• Le richieste a example.org (o a qualsiasi dominio diverso da example.net) devono essere indirizzate al servizio di backend org-site.
• Le richieste a example.net che non corrispondono a percorsi più specifici vanno al servizio di backend video-site.
• Le richieste a example.net/video/hd/* devono essere indirizzate al servizio di backend video-hd.
• Le richieste a example.net/video/sd/* devono essere indirizzate al servizio di backend video-sd.

Un --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, lo trasforma rimuovendo il segmento di percorso precedente a /../ e risponde con l'URL trasformato... Ad esempio, quando viene inviata una richiesta perhttp://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 percorso.

Esempio di configurazione del servizio di backend (fai clic per ingrandire).

Denominazione

Ogni mappa di 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. Questo nome corrisponde al 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 di URL.

Componenti della mappa degli URL

Una mappa URL è un insieme di risorse di configurazione Google Cloud che indirizzano le richieste per gli URL ai servizi di backendo ai bucket di backend. La mappa URL lo fa utilizzando le parti nome host e percorso per ogni 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.

Configurazione del bilanciatore del carico con mappa URL di base (fai clic per ingrandire).

Questo diagramma mostra la struttura degli oggetti di configurazione del bilanciamento del carico tra loro.

Nota: il diagramma non ha lo scopo di mostrare il flusso di elaborazione delle richieste.

Puoi controllare quali servizi di backend 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. Questo valore predefinito 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.

Nota: i bucket di backend non sono supportati con i bilanciatori del carico delle applicazioni interni e Cloud Service Mesh.

• Regola host (hostRules). Una regola host indirizza le richieste inviate a uno o più nomi host associati a un singolo matcher percorso (pathMatchers). La parte del nome host di un URL viene associata esattamente all'insieme dei 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'espressione di corrispondenza dei percorsi, è necessaria una singola regola di example.net che includa almeno il nome host example.net. La stessa regola di impostazione dell'host potrebbe gestire anche le richieste per altri nomi host, ma le indirizzerebbe allo stesso associatore di percorsi.

  Se devi indirizzare le richieste a diversi corrispondenti dei percorsi, devi utilizzare regole host diverse. Due regole host in una mappa URL non possono includere lo stesso nome host.

  È possibile trovare una corrispondenza per tutti i nomi host specificando il carattere jolly* nella regola host. Ad esempio, per gli URL http://example.org, http://example.net/video/hd e http://example.com/audio, tutti e tre i nomi host example.org, example.net e example.com possono essere abbinati specificando * nella regola host. È anche possibile trovare una corrispondenza per un nome di host parziale specificando il carattere jolly *. Ad esempio, una regola host *.example.net viene associata sia ai nomi host news.example.net che finance.example.net.

  • Numero porta. I bilanciatori del carico delle applicazioni gestiscono i numeri di porta in modo diverso. 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 su example.net:8080. Nel caso del bilanciatore del carico delle applicazioni classico, viene considerato solo il nome host nell'URL durante la corrispondenza di una regola host. Ad esempio, le richieste example.net per la porta 8080 e la porta 80 corrispondono alla regola host example.net.

• 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'associazione di percorsi è costituita da due elementi:

  • Servizio di backend predefinito del matcher percorso o bucket di backend predefinito del matcher percorso. Per ogni matcher percorso, devi specificare almeno un servizio di backend predefinito o un bucket di backend predefinito, ma non entrambi. Questo valore predefinito rappresenta il servizio di backend o il bucket di backend a cui Google Cloudindirizza le richieste per gli URL i cui nomi host corrispondono a una regola host associata al correlatore di percorsi e i cui percorsi URL non corrispondono a nessuna regola di percorso nel correlatore di percorsi.

  • Regole percorso. Per ogni matcher percorso, puoi specificare una o più regole percorso, ovvero coppie chiave-valore che mappano un percorso dell'URL a un singolo servizio di backend o a un bucket di backend. La sezione successiva contiene ulteriori informazioni su come funzionano le regole dei percorsi.

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 correttoo al bucket di backend, 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 della mappa URLo al bucket di backend predefinito, a seconda di quale hai definito.

• Se la mappa URL contiene una regola host che include il nome host dell'URL, viene consultato il corrispettivo per il percorso a cui fa riferimento la regola host:

  • Se il corrispettivo del percorso contiene una regola del 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 del percorso.

  • Se il corrispettivo per il percorso non contiene una regola del percorso che corrisponde esattamente al percorso dell'URL, ma contiene una regola del percorso che termina con /* il cui prefisso corrisponde alla sezione più lunga del percorso dell'URL, Google Cloudindirizza 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 di corrispondenza del percorso/video/hd/movie1 e /video/hd/*, se l'URL contiene il percorso esatto/video/hd/movie1, viene abbinato a questa 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 corrispettivo della strada, a seconda di quale hai definito.

Vincoli del matcher percorso

I nomi host, i matcher dei percorsi e le regole dei percorsi hanno vincoli.

Segnaposto, espressioni regolari e URL dinamici nelle regole del percorso

• Una regola del percorso può includere un carattere jolly (*) solo dopo un carattere barra (/). Ad esempio, /videos/* e /videos/hd/* sono validi per le regole del percorso, ma /videos* e /videos/hd* no.

• Le regole dei percorsi non utilizzano espressioni regolari o corrispondenze di sottostringhe. PathTemplateMatch può utilizzare operatori di corrispondenza del percorso semplificati. Ad esempio, le regole del percorso per /videos/hd o /videos/hd/* non si applicano a un URL con il percorso /video/hd-abcd. Tuttavia, a questo percorso si applica una regola del percorso per /video/*.

• I corrispondenti di percorso (e le mappe di URL in generale) non offrono funzionalità che funzionano come le direttive LocationMatch di Apache. Se hai un'applicazione che genera percorsi URL dinamici con un prefisso comune, ad esempio /videos/hd-abcd e /videos/hd-pqrs, e devi inviare le richieste effettuate a questi percorsi a diversi servizi di backend, potresti non essere in grado di farlo con una mappa URL. Per i casi che contengono solo alcuni possibili URL dinamici, potresti essere in grado di creare un corrispettivo del percorso con un insieme limitato di regole del percorso. Per i casi più complessi, devi eseguire la corrispondenza con espressioni regolari basate sul percorso sui tuoi backend.

Caratteri jolly e operatori di corrispondenza di 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 dell'URL, inclusi URL parziali e suffissi (estensioni file), utilizzando la sintassi dei caratteri jolly. Questi operatori possono essere utili quando devi indirizzare il traffico ed eseguire riscritture in base a percorsi degli URL complessi. Puoi anche associare uno o più componenti del percorso a variabili denominate e poi fare riferimento a queste variabili durante la riscrittura dell'URL. Con le variabili denominate, 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
• Cloud Service Mesh

Il seguente esempio instrada il traffico per un'applicazione di e-commerce che ha servizi distinti per le informazioni sul carrello e per le informazioni sull'utente. Puoi configurare routeRules con operatori di corrispondenza di pattern flessibili e variabili denominate per inviare l'ID univoco dell'utente a una pagina dei dettagli dell'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 cliente richiede/xyzwebservices/v2/xyz/users/[e-mail]/carts/FL0001090004/entries/SJFI38u3401nms?fields=FULL&client_type=WEB, che contiene sia le informazioni dell'utente sia quelle del carrello:

1. Il percorso della richiesta corrisponde a pathTemplateMatch all'interno di cart-matcher pathMatcher. La variabile {username=*} corrisponde a [e-mail] e la variabile {cartid=**} corrisponde a FL0001090004/entries/SJFI38u3401nms.
2. I parametri di ricerca vengono separati dal percorso, il percorso viene riscritto in base a pathTemplateRewrite e i parametri di ricerca vengono aggiunti al percorso riscritto. Dobbiamo utilizzare solo le stesse variabili che abbiamo utilizzato per definire pathTemplateMatch nel nostro pathTemplateRewrite.
3. La richiesta riscritta viene inviata a cart-backend con il percorso dell'URL riscritto: /[e-mail]-FL0001090004/entries/SJFI38u3401nms?fields=FULL&client_type=WEB.

Quando un cliente richiede invece /xyzwebservices/v2/xyz/users/abc%40xyz.com/accountinfo/abc-1234, che contiene solo i dati dell'utente e dell'account:

1. Il percorso della richiesta corrisponde a pathTemplateMatch all'interno di user-matcher pathMatcher. Il primo * corrisponde a abc%40xyz.com e il secondo * corrisponde a abc-1234.
2. La richiesta viene inviata a user-backend.

La tabella seguente illustra la sintassi dei pattern dei modelli di percorso.

Operatore	Corrisponde a
*	Un singolo segmento di percorso, esclusi i caratteri / di separazione del percorso circostante.
**	Corrisponde a zero o più caratteri, inclusi eventuali caratteri / di separatore di percorso tra più segmenti di percorso. Se sono inclusi altri operatori, l'operatore ** deve essere l'ultimo.
{name} o {name=*}	Una variabile denominata corrispondente a un segmento di percorso. Corrisponde a un singolo segmento di percorso, esclusi i caratteri / del separatore di percorso circostante.
{name=news/*}	Una variabile denominata che corrisponde esplicitamente a due segmenti di percorso: news e un segmento di carattere jolly *.
{name=*/news/*}	Una variabile denominata corrispondente a tre segmenti di percorso.
{name=**}	Una variabile denominata che corrisponde a zero o più caratteri. Se presente, deve essere l'ultimo operatore.

Quando utilizzi questi operatori per la corrispondenza di pattern flessibile, tieni presente queste considerazioni:

• È possibile combinare più operatori in un unico pattern.
• I parametri di query vengono separati dal percorso, il percorso viene riscritto in base a pathTemplateRewrite e i parametri di ricerca vengono aggiunti al percorso riscritto.
• Le richieste non sono normalizzate con codifica percentuale. Ad esempio, un URL con un carattere barra codificato in percentuale (%2F) non viene decodificato nella forma non codificata.
• 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.
• Esiste 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 a variabili, riordinarle o ometterle nel pathTemplateRewrite campo quando definisci urlRewrite.

Quando utilizzi variabili e operatori per la corrispondenza di pattern flessibile per le riscritture di URL, tieni presente queste considerazioni:

• Quando riscrivi un URL, puoi omettere le variabili se non sono necessarie nell'URL riscritto.
• Prima di qualsiasi riscrittura, puoi identificare l'URL inviato dal client nella tua origine controllando le intestazioni di risposta. L'URL del client originale viene compilato con l'intestazione x-client-request-url e l'intestazione x-envoy-original-path.

Relazione tra nome host e regola host

• Un nome host può fare riferimento a una sola regola host.

• Una singola regola host può elaborare più nomi host.

La relazione tra i nomi host e le regole host (fai clic per ingrandire).

Relazione tra regola host e matcher percorso

• Più regole host possono fare riferimento a un singolo matcher percorso.

• Una regola host può fare riferimento a un solo corrispondenze dei percorsi.

Il seguente diagramma illustra questi punti.

La relazione tra le regole host e i corrispondenti dei percorsi (fai clic per ingrandire).

Relazione tra URL e backend

Ogni URL univoco viene indirizzato a un solo servizio di backend o a un 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 corrispettivo associato al percorso.

• Quando utilizzi le regole percorso in un matcher percorso, non puoi creare più di una regola percorso per lo stesso percorso. Ad esempio, le richieste per /videos/hd non possono essere indirizzate a più di un servizio di backend o a un bucket di backend. I servizi di backend possono avere gruppi di istanze di backend o gruppi di endpoint di rete di backend (NEG) in zone e regioni diversee puoi creare bucket di backend che utilizzano le classi di archiviazione multiregionali.

  Per indirizzare il traffico per un URL univoco a più servizi, puoi utilizzare le regole di route anziché le regole di percorso. Se configuri il corrispettivo del percorso con le regole di routing per le corrispondenze di intestazioni o parametri, un URL univoco può essere indirizzato a più di un servizio di backend o a un bucket, in base ai contenuti delle intestazioni o dei parametri di ricerca nell'URL.

  Analogamente, per i bilanciatori del carico delle applicazioni esterni regionali e Cloud Service Mesh, i servizi di backend ponderati nelle azioni di route possono indirizzare lo stesso URL a più servizi di backend o bucket, a seconda dei pesi impostati sul servizio di backend ponderato.

Mappe URL e protocolli

Puoi utilizzare la stessa mappa URL, le stesse regole host e gli stessi corrispondenti dei percorsi per elaborare sia le richieste HTTP sia quelle HTTPS inviate dai client, a condizione che sia un proxy HTTP di destinazione sia un proxy HTTPS di destinazione facciano riferimento alla mappa 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 e non contiene matcher di percorso. Il servizio di backend o il bucket di backend predefinito (a seconda di quello che hai definito) gestisce tutti gli URL richiesti.

Se definisci un servizio di backend predefinito, Google Cloud indirizza le richieste ai suoi gruppi di istanza di backend o ai suoi NEG di backend in base alla configurazione del servizio di backend.

Mappa URL senza regole, ad eccezione di quella predefinita (fai clic per ingrandire).

Esempio di flusso di lavoro della mappa URL con un bilanciatore del carico delle applicazioni esterno

L'esempio seguente illustra l'ordine delle operazioni per una mappa di 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. Tuttavia, puoi sostituirli con 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 scoprire di più sulla creazione e sulla configurazione delle mappe URL con i corrispondenti dei percorsi e le regole host, consulta la documentazione di gcloud compute url-maps create.

1. 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 denominato org-site.

   gcloud compute url-maps create video-org-url-map \
       --default-service=org-site
   

2. Crea un'associazione di percorsi denominata video-matcher con le seguenti caratteristiche:

   • Il servizio di backend predefinito è video-site, un servizio di backend esistente.
   • Aggiungi regole di percorso che indirizzino le richieste per il percorso dell'URL esatto /video/hd o per il prefisso del percorso dell'URL /video/hd/* a un servizio di backend esistente denominato video-hd.
   • Aggiungi regole di percorso che indirizzino le richieste per il percorso dell'URL esatto /video/sd o per il prefisso del percorso dell'URL /video/sd/* a un servizio di backend esistente denominato video-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
   

3. Crea una regola host per il nome host example.net che fa riferimento al matcher percorso video-matcher.

   gcloud compute url-maps add-host-rule video-org-url-map \
       --hosts=example.net \
       --path-matcher-name=video-matcher
   

La mappa degli URL di 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.

Mappa di URL con una regola del percorso, corrispondenze del percorso e una regola dell'host (fai clic per ingrandire).

La tabella seguente spiega l'elaborazione della richiesta mostrata nel diagramma precedente.

Nome host	Percorsi dell'URL	Servizio di backend selezionato	Motivo della selezione
Nome host: example.org e tutti gli altri nomi host diversi da example.net	tutti i percorsi	org-site	Il nome host non è presente in nessuna regola host della mappa URL, pertanto la richiesta viene indirizzata al servizio di backend predefinito della mappa URL.
Nome host: example.net	/video /video/examples	video-site	La richiesta viene inviata 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 percorso, ma questo matcher percorso non ha regole percorso che si applichino 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 percorso le cui regole di percorso indirizzano le richieste per i percorsi URL che corrispondono esattamente /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 percorso le cui regole di percorso indirizzano le richieste per i percorsi URL che corrispondono esattamente /video/sd o che iniziano con /video/sd/* al servizio di backend video-sd.

Reindirizzamenti degli URL

Un reindirizzamento URL reindirizza i visitatori del tuo dominio da un URL a un altro.

Un reindirizzamento URL predefinito non è condizionato alla corrispondenza di un determinato pattern nella richiesta in entrata. Ad esempio, potresti voler utilizzare un URL di reindirizzamento predefinito per reindirizzare qualsiasi nome host a un nome host di tua scelta.

Esistono diversi modi per creare un reindirizzamento dell'URL, come indicato nella tabella seguente.

Metodo	Configurazione
Reindirizzamento URL predefinito della mappa URL	defaultUrlRedirect di primo livello
Il reindirizzamento URL predefinito di un matcher percorso	pathMatchers[].defaultUrlRedirect[]
Il reindirizzamento URL della regola percorso di un matcher percorso	pathMatchers[].pathRules[].urlRedirect
Il reindirizzamento URL della regola di route di un matcher percorso	pathMatchers[].routeRules[].urlRedirect

All'interno di un defaultUrlRedirect o urlRedirect, pathRedirect funziona sempre come segue:

• L'intero percorso della richiesta viene sostituito con quello specificato.

All'interno di un defaultUrlRedirect o urlRedirect, il funzionamento del prefixRedirect dipende da come lo utilizzi:

• Se utilizzi un defaultUrlRedirect, prefixRedirect è in pratica un prefisso iniziale perché il percorso corrispondente è sempre /.
• Se utilizzi un urlRedirect all'interno della regola percorso o della regola percorso di un'espressione di corrispondenza dei percorsi, prefixRedirect è una sostituzione del prefisso in base alla modalità di corrispondenza del percorso richiesto come definito nella regola percorso o nella regola percorso.

Esempi di reindirizzamento

La tabella seguente fornisce alcuni esempi di configurazioni di reindirizzamento. La colonna a destra mostra la configurazione dell'API per un reindirizzamento dell'URL predefinito.

Vuoi	Realizzato utilizzando un reindirizzamento URL predefinito
Reindirizzamento da HTTP a HTTPS Reindirizza http://host.name/path a https://host.name/path	kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True
HTTP a HTTPS + reindirizzamento dell'host Reindirizza 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"
HTTP a HTTPS + reindirizzamento dell'host + reindirizzamento del percorso completo Reindirizza http://nome-host-qualsiasi/percorso a https://www.example.com/newPath	kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True hostRedirect: "www.example.com" pathRedirect: "/newPath"
HTTP a HTTPS + reindirizzamento dell'host + reindirizzamento del prefisso Reindirizza http://nome-host-qualsiasi/percorso-originale a https://www.example.com/newPrefix/percorso-originale	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 di URL, consulta Utilizzare le mappe di URL.

• Per informazioni sulle mappe di regole di routing con Cloud Service Mesh, consulta la panoramica delle mappe di regole di routing di Cloud Service Mesh.