Panoramica delle mappe URL

I bilanciatori del carico delle applicazioni Google Cloud e Traffic Director utilizzano una risorsa di configurazione Google Cloud denominata mappa URL per instradare le richieste HTTP(S) ai servizi di backend o 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:

Sono disponibili due tipi di risorse delle mappe degli 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, esterno Servizi di backend, bucket di backend
Bilanciatore del carico delle applicazioni classico EXTERNAL Globale, esterno 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, interno 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, interno Servizi di backend

Non tutte le funzionalità della mappa URL sono disponibili per tutti i prodotti. Le mappe degli 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 ulteriori informazioni su queste differenze, consulta il documento Confronto tra le funzionalità del bilanciatore 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 instrada 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 un microservizio. Un bucket di backend è un bucket Cloud Storage, comunemente utilizzato per ospitare contenuti statici, come le immagini.

Per gli Application Load Balancer esterni regionali, gli Application Load Balancer interni e per Traffic Director, le possibili destinazioni sono le seguenti:

Inoltre, gli Application Load Balancer esterni globali supportano quanto segue:

Ad esempio, supponiamo che tu abbia 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 gruppi di server:
    • Uno ospita il sito web della tua organizzazione (servizio di backend: org-site).
    • Uno ospita l'intero sito web di 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).

Vuoi che si verifichi quanto segue:

  • Richieste a example.org (o a qualsiasi dominio diverso da example.net) per accedere al servizio di backend org-site.
  • Le richieste a example.net che non corrispondono a percorsi più specifici passano al servizio di backend video-site.
  • Richieste a example.net/video/hd/* per accedere al servizio di backend video-hd.
  • Richieste a example.net/video/sd/* per accedere al servizio di backend video-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 del 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 consente di configurare questo tipo di routing basato su host e percorso.

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

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. 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 URL.

Componenti della mappa URL

Una mappa URL è un insieme di risorse di configurazione di Google Cloud che indirizzano le richieste degli URL ai servizi di backendo ai bucket di backend. Per farlo, la mappa URL utilizza le sezioni 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 porzione 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.
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 in relazione tra loro.

Puoi controllare quali servizi di backend o bucket di backend ricevono 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 o il bucket di backend a cui Google Cloud indirizza le richieste di URL con qualsiasi nome host, a meno che non sia presente 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 percorso (pathMatchers). La porzione del nome host di un URL corrisponde esattamente al set 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 per http://example.net/video/hd a un matcher percorso, è necessaria una singola regola host che includa almeno il nome host example.net. La stessa regola dell'host potrebbe anche gestire le richieste per altri nomi host, ma li indirizzerà allo stesso matcher 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 corrispondenze di 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 con un nome host parziale specificando il carattere jolly *. Ad esempio, una regola host *.example.net viene confrontata con i nomi host news.example.net e finance.example.net.

    • Numero porta. Bilanciatori del carico delle applicazioni diversi gestiscono i numeri di porta in modo diverso. Nel caso dell'Application Load Balancer 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 dell'Application Load Balancer classico, viene considerato solo il nome host nell'URL quando viene trovata una corrispondenza con una regola dell'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 o bucket di backend che deve gestire la richiesta. Un matcher percorso è costituito 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 Cloud indirizza le richieste per gli URL i cui nomi host corrispondono a una regola dell'host associata al matcher percorso e i cui percorsi URL non corrispondono a nessuna regola di percorso nel matcher percorso.

    • Regole del percorso. Per ogni matcher percorso, puoi specificare una o più regole di percorso, ovvero coppie chiave-valore che mappano un percorso dell'URL a un singolo servizio di backend o bucket di backend. La prossima sezione contiene ulteriori informazioni sul funzionamento delle regole 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 backendo 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 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 matcher del percorso a cui fa riferimento tale regola host:

    • Se il matcher 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 matcher 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 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 di matcher percorso /video/hd/movie1 e /video/hd/*, se l'URL contiene il percorso esatto /video/hd/movie1, viene confrontata con questa regola del percorso.

    • Se nessuna delle condizioni precedenti è vera, Google Cloud indirizza le richieste al servizio di backend predefinito del matcher percorso o al bucket di backend predefinito, a seconda di quale hai definito.

Vincoli del matcher percorso

Nomi host, matcher percorso e regole percorso hanno vincoli.

Caratteri jolly, espressioni regolari e URL dinamici nelle regole del percorso

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

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

  • I matcher percorso (e le mappe URL in generale) non offrono funzionalità che funzionano come le istruzioni LocationMatch di Apache. Se hai un'applicazione che genera percorsi degli URL dinamici con un prefisso comune, come /videos/hd-abcd e /videos/hd-pqrs, e devi inviare le richieste effettuate a questi percorsi a servizi di backend diversi, potresti non riuscire a farlo con una mappa URL. Per i casi in cui vengono visualizzati solo pochi URL dinamici possibili, potrebbe essere possibile creare un matcher percorso con un insieme limitato di regole per il percorso. Per i casi più complessi, devi eseguire la corrispondenza di espressioni regolari basate su percorso nei tuoi backend.

Operatori di corrispondenza di pattern e caratteri jolly nei modelli di percorso per le regole di route

Gli operatori di corrispondenza flessibili dei pattern consentono di associare più parti di un percorso dell'URL, compresi URL parziali e suffissi (estensioni dei file), utilizzando la sintassi con caratteri jolly. Questi operatori possono essere utili quando devi instradare il traffico ed eseguire riscritture basate su percorsi di URL complessi. Puoi anche associare uno o più componenti del percorso a variabili con nome e fare riferimento a queste variabili quando riscrivi l'URL. Con le variabili denominate, puoi riordinare e rimuovere i componenti dell'URL prima che la richiesta venga inviata alla tua 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 indirizza il traffico per un'applicazione di e-commerce con servizi separati per le informazioni del carrello e quelle degli utenti. Puoi configurare routeRules con operatori di corrispondenza di 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 la riscrittura dell'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 sull'utente sia informazioni del carrello:

  1. Il percorso della richiesta corrisponde al pathTemplateMatch all'interno del pathMatcher cart-matcher. La variabile {username=*} corrisponde a abc@xyz.com 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 in pathTemplateRewrite.
  3. 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 contiene solo i dati dell'utente e dell'account:

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

La seguente tabella descrive la sintassi per i pattern dei modelli di percorso.

Operatore Corrisponde a
* Un singolo segmento di percorso, esclusi i caratteri / del separatore di percorso circostante.
** Corrisponde a zero o più caratteri, inclusi eventuali caratteri / separatori di percorso tra più segmenti di percorso. Se sono inclusi altri operatori, l'operatore ** deve essere l'ultimo.
{name} o {name=*} Una variabile con nome corrispondente a un segmento del 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 del percorso: news e un segmento con caratteri jolly *.
{name=*/news/*} Una variabile con nome corrispondente a tre segmenti del 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 flessibile dei pattern, tieni a mente questi aspetti:

  • È 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 una barra con codifica percentuale (%2F) non viene decodificato nella forma non codificata.
  • Ogni nome di variabile, ad esempio {segment} o {region}, può apparire una sola 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 il nome di una 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 definite per acquisire un percorso. Ad esempio, puoi fare riferimento, riordinare oppure omettere variabili nel campo pathTemplateRewrite durante la definizione di urlRewrite.

Quando utilizzi variabili e operatori per la corrispondenza flessibile di pattern per le riscritture di URL, tieni a mente questi aspetti:

  • Quando riscrivi un URL, puoi omettere le variabili se non sono obbligatorie nell'ambito dell'URL riscritto.
  • Prima di qualsiasi riscrittura, puoi identificare l'URL inviato dal client nella tua origine ispezionando le intestazioni delle risposte. L'URL 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 solo a una singola regola host.

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

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

Relazione del matcher regola host e percorso

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

  • Una regola host può fare riferimento a un solo matcher percorso.

Il seguente diagramma illustra questi punti.

Relazione tra regole host e matcher percorso.
Relazione tra le regole host e i matcher percorso (fai clic per ingrandire).

Relazione tra URL e backend

Ogni URL univoco è indirizzato a un solo servizio di backend 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 matcher del percorso di riferimento.

  • 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 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 diverseed è possibile creare bucket di backend che utilizzano classi di archiviazione multiregionale.

    Per indirizzare il traffico di un URL univoco a più servizi, puoi utilizzare le regole di route anziché le regole per il percorso. Se configuri il matcher 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 bucket, in base ai contenuti delle intestazioni o parametri di ricerca nell'URL.

    Analogamente per gli Application Load Balancer 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 percorsi per elaborare le richieste HTTP e 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 matcher percorso. Tutti gli URL richiesti vengono gestiti dal servizio di backend predefinito o dal bucket di backend predefinito (quello che hai definito).

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.

Mappa URL senza regole, tranne quella predefinita.
Mappa degli URL senza regole eccetto 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 URL. Questo esempio configura solo la mappa URL per un bilanciatore del carico delle applicazioni classico esistente. Per semplicità concettuale, utilizza solo 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 i matcher percorso 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. In questo esempio viene creata 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 matcher 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 denominato video-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 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 faccia 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 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.

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

La tabella seguente illustra l'elaborazione delle richieste nel diagramma precedente.

Nome host Percorsi 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 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 viene inviata al servizio di backend predefinito perché non esiste una regola percorso per /video/ o /video/*. La regola host per example.net fa riferimento a un matcher percorso, ma quest'ultimo non ha regole applicabili 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 percorso indirizzano le richieste di percorsi 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 percorso le cui regole percorso indirizzano le richieste di percorsi 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 URL predefinito non è vincolato alla corrispondenza con un pattern particolare nella richiesta in entrata. Ad esempio, puoi utilizzare un reindirizzamento di URL predefinito per reindirizzare qualsiasi nome host a un nome host a tua scelta.

Esistono diversi modi per creare un reindirizzamento URL, come descritto nella seguente tabella.

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

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

  • L'intero percorso di richiesta viene sostituito con il percorso specificato.

All'interno di defaultUrlRedirect o urlRedirect, il funzionamento di prefixRedirect dipende dall'utilizzo:

  • Se utilizzi defaultUrlRedirect, prefixRedirect è di fatto un prefisso perché il percorso corrispondente è sempre /.
  • Se utilizzi un urlRedirect all'interno di una regola di route o di un matcher percorso, prefixRedirect è una sostituzione del prefisso basata sulla corrispondenza del percorso richiesto come definito nella regola del percorso o nella regola di route.

Esempi di reindirizzamento

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

Che vuoi Eseguito con 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
Da HTTP a HTTPS + reindirizzamento host

Reindirizzamento
http://nome-host-qualsiasi/percorso
a
https://www.example.com/path 
            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-qualsiasi/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 dell'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