Panoramica delle mappe URL

Bilanciatori del carico delle applicazioni Google Cloud e Cloud Service Mesh usano una configurazione Google Cloud risorsa 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 indirizzare 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 di https://example.com/images vanno a Cloud Storage di backend.

• Le richieste per qualsiasi altra combinazione di host e percorso vanno a un backend predefinito completamente gestito di Google Cloud.

Le mappe URL vengono utilizzate con i seguenti prodotti Google Cloud:

• Bilanciatore del carico delle applicazioni esterno (globale, regionale e classico modalità)
• Bilanciatore del carico delle applicazioni interno (tra regioni e regionali)
• Cloud Service Mesh, quando Il deployment di Cloud Service Mesh viene eseguito con le API di bilanciamento del carico

Sono disponibili due tipi di risorse di mappe URL: globali e a livello di regione. La il tipo di risorsa che utilizzi dipende dallo schema di bilanciamento del carico del prodotto.

Non tutte le funzionalità delle mappe URL sono disponibili per tutti i prodotti. 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 soluzioni avanzate funzionalità di gestione del traffico. Per ulteriori informazioni su queste differenze, consulta Confronto delle funzionalità del bilanciatore del carico: routing e traffico dei modelli. Nel Inoltre, le mappe URL a livello di regione possono essere una risorsa designata come servizio in App Hub, che si trova in l'anteprima.

Come funzionano le mappe URL

Quando una richiesta arriva al bilanciatore del carico, quest'ultimo instrada richiesta a un particolare servizio di backend o 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 un'applicazione o un microservizio. Un bucket di backend è un servizio Cloud Storage di archiviazione principale, di solito utilizzato per ospitare contenuti statici, come immagini.

Per i bilanciatori del carico delle applicazioni esterni regionali, i bilanciatori del carico delle applicazioni interni e Cloud Service Mesh è possibile le 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 vengono inviate allo stesso indirizzo IP e allo stesso con il bilanciatore del carico di rete passthrough esterno regionale.
  • 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 generale del video di formazione (servizio di backend: video-site).
  • Uno ospita video di addestramento in alta definizione (HD) (servizio di backend: video-hd).
  • Uno contiene video di addestramento in definizione standard (SD) (servizio di backend: video-sd).

Vuoi che si verifichi quanto segue:

• Richieste di accesso a example.org (o a qualsiasi dominio diverso da example.net) il servizio di backend org-site.
• Richieste a example.net che non corrispondono a percorsi più specifici che rimandano a video-site servizio di backend.
• Richieste a example.net/video/hd/* di andare al servizio di backend video-hd.
• Richieste a example.net/video/sd/* di andare 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 carico il bilanciatore trasforma l'URL rimuovendo il segmento di percorso prima di .. e risponde con l'URL trasformato. Ad esempio, quando viene inviata una richiesta http://example.net/video/../abc, il bilanciatore del carico risponde con un errore 302 reindirizza a http://example.net/abc. La maggior parte dei clienti reagisce poi inviando all'URL restituito dal bilanciatore del carico (in questo caso, http://example.net/abc). Reindirizzamento 302 non connesso 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 nella console Google Cloud, alla mappa URL viene assegnato un nome. È lo stesso di il 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 configurazioni di Google Cloud che indirizzano le richieste per gli URL ai servizi di backend di backend o di backend. La mappa URL lo fa utilizzando la proprietà le parti nome host e percorso per ogni URL elaborato:

• Un nome host è la parte del nome di dominio di un URL. della Ad esempio, la porzione 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 la porta facoltativa numero; ad esempio, la porzione 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 l'uno con l'altro.

Sei tu a controllare quali servizi di backend o bucket di backend ricevono le richieste in entrata seguenti parametri di configurazione della mappa URL:

• Servizio di backend predefinito o bucket di backend predefinito. Quando crei un Mappa URL, devi specificare un servizio di backend predefinito o un backend predefinito ma non entrambi. Questa impostazione predefinita rappresenta il servizio di backend o il backend bucket a cui Google Cloud indirizza le richieste di 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 una o più nomi host associati a un singolo matcher del percorso (pathMatchers). Il nome host di un URL corrisponde esattamente alla serie di parametri della regola host e nomi host configurati. In una regola host e percorso di una 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, è necessario un singolo host che includa almeno il nome host example.net. Lo stesso host in grado di gestire le richieste per altri nomi host, ma e li colleghi 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 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 corrispondere che specifica * nella regola host. È anche possibile far corrispondere specificando il carattere jolly *. Ad esempio, una regola host *.example.net viene confrontato con i nomi host news.example.net e finance.example.net.

  • Numero di porta. I bilanciatori del carico delle applicazioni diversi gestiscono le porte numeri 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 richieste example.net dirette per la porta 8080, imposta la regola host su example.net:8080. Nel caso del bilanciatore del carico delle applicazioni classico, solo il nome host nell'URL viene preso in considerazione per la corrispondenza di un host personalizzata. Ad esempio, le richieste example.net per la porta 8080 e la porta 80 corrispondono la regola host example.net.

• Corrispondenza del percorso (pathMatchers). Un matcher del percorso è la 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 soddisfare la richiesta. Un matcher di percorso è composto da due elementi:

  • Servizio di backend predefinito dello strumento di abbinamento del percorso o Backend predefinito dello strumento di abbinamento del percorso bucket. Per ogni matcher del percorso, devi almeno specificare un valore predefinito servizio di backend o 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 URL i cui nomi host corrispondono a una regola host associata con il matcher di percorso e i cui percorsi dell'URL non corrispondono ad alcun percorso nel matcher percorso.

  • Regole percorso. Per ogni matcher di percorso, puoi specificare uno o più di regole, che sono coppie chiave/valore che mappano un percorso dell'URL a un singolo backend servizio o bucket di backend. La prossima sezione contiene ulteriori informazioni come funzionano le 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 backend corretto o il 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 URL o un 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 di percorso a cui fa riferimento quella regola host:

  • Se il matcher di percorso contiene una regola del percorso che corrisponde esattamente al percorso dell'URL, Google Cloud indirizza le richieste al backend servizio o bucket di backend per quella regola percorso.

  • Se il matcher del percorso non contiene una regola del percorso che corrisponde esattamente il percorso dell'URL, ma contiene una regola 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 quel percorso personalizzata. 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 a quella regola percorso.

  • Se nessuna delle condizioni precedenti è vera, Google Cloud indirizza le richieste al servizio di backend predefinito o al servizio di backend predefinito del matcher di percorso bucket di backend, 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 percorso può includere solo un carattere jolly (*) dopo un barra (/). Ad esempio, /videos/* e /videos/hd/* sono valide 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 un percorso semplificato operatori corrispondenti. Ad esempio, regole percorso per /videos/hd o /videos/hd/* non si applicano a un URL con il 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 Apache LocationMatch. Se hai un'applicazione genera percorsi degli URL dinamici con un prefisso comune, ad esempio /videos/hd-abcd e /videos/hd-pqrs e devi inviare le richieste inviate a questi percorsi per servizi di backend diversi, potresti non riuscire a farlo Mappa URL. Nei casi che contengono solo pochi possibili URL dinamici, potrebbe essere in grado di creare un matcher di percorso con un insieme limitato di regole per il percorso. Per casi più complessi, devi eseguire espressioni regolari basate sul percorso la corrispondenza nei backend.

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 dell'URL, inclusi 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 URL complessi. Puoi anche associare uno o più percorsi componenti con variabili con nome, quindi fai riferimento a queste variabili durante la riscrittura l'URL. Con le variabili con nome, puoi riordinare e rimuovere i componenti dell'URL prima la richiesta viene 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
• Cloud Service Mesh

L'esempio seguente instrada il traffico per un'applicazione di e-commerce che ha distinti per le informazioni del carrello e le informazioni degli utenti. Puoi configurare routeRules con operatori flessibili di corrispondenza dei pattern 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 di riscrivere 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 dati dell'utente sia informazioni del carrello:

1. Il percorso di richiesta corrisponde a pathTemplateMatch all'interno di cart-matcher pathMatcher. La variabile {username=*} corrisponde a abc@xyz.com e alla 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 il percorso riscritto. Dobbiamo usare solo le stesse variabili che abbiamo usato per definisci pathTemplateMatch nel nostro 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, si verifica quanto segue. /xyzwebservices/v2/xyz/users/abc%40xyz.com/accountinfo/abc-1234 invece, che contiene solo i dati dell'utente e dell'account:

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

La seguente tabella illustra la sintassi per i pattern del modello di percorso.

Quando utilizzi questi operatori per la corrispondenza flessibile con pattern, mantienili considerazioni in merito:

• È possibile combinare più operatori in un unico pattern.
• I parametri di query vengono separati dal percorso e il percorso viene riscritto in base a pathTemplateRewrite e i parametri di ricerca vengono aggiunti il percorso riscritto.
• Le richieste non sono con codifica percentuale normalizzata. Ad esempio, un URL con un Il 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 in lo stesso pattern. Più variabili con lo stesso nome non sono valide e lo sono rifiutato.
• I nomi delle variabili sono sensibili alle maiuscole e devono essere identificatori validi. Per verificare se un nome di variabile sia valido, accertati 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 usare le stesse variabili che hai definito per acquisire un percorso. Ad esempio, puoi fare riferimento, riordinare oppure omettere variabili nella Campo pathTemplateRewrite durante la definizione di urlRewrite.

Quando utilizzi variabili e operatori per la corrispondenza flessibile con pattern degli URL riscritture, tieni a mente queste considerazioni:

• 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 cliente alla tua origine esaminando le intestazioni delle risposte. L'URL client originale è stato compilato con le intestazioni x-client-request-url e x-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 e il matcher percorso di riferimento.

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

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

  Allo stesso modo, per i bilanciatori del carico delle applicazioni esterni regionali e Cloud Service Mesh, da servizi di backend sulle azioni di route possono indirizzare lo stesso URL a più di backend o bucket, a seconda delle ponderazioni impostate di servizio di backend.

Mappe e protocolli URL

Puoi utilizzare la stessa mappa URL, le stesse regole host e gli stessi matcher di percorso per elaborare sia i messaggi HTTP e HTTPS inviate dai client, purché sia un proxy HTTP di destinazione un proxy HTTPS di destinazione fa riferimento alla mappa URL.

Mappa URL più semplice

La mappa URL più semplice ha solo un servizio di backend predefinito o un backend predefinito bucket. Non contiene regole host né matcher di percorso. Il valore predefinito servizio di backend o il bucket di backend predefinito (a seconda del servizio che hai definito) gestisce tutti gli URL richiesti.

Se definisci un servizio di backend predefinito, Google Cloud indirizza le richieste alla i relativi gruppi di istanza di backend o NEG di backend in base al configurazione.

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 un URL mappa. Questo esempio configura solo la mappa URL per una il bilanciatore del carico delle applicazioni classico. Per semplicità concettuale, utilizza solo il backend servizi; ma puoi sostituirli. Per scoprire come per creare gli altri componenti del bilanciatore del carico, consulta Creare un il bilanciatore del carico delle applicazioni classico.

Per saperne di più sulla creazione e sulla configurazione delle mappe URL con matcher del percorso e le regole dell'host, consulta la sezione gcloud compute url-maps create documentazione.

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 matcher di percorso denominato video-matcher con quanto segue 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 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 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 in seguendo la strada giusta.

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

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 URL predefinito reindirizzamento per reindirizzare qualsiasi nome host a un nome host di tua scelta.

Esistono diversi modi per creare un reindirizzamento URL, come illustrato di seguito .

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

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

All'interno di una defaultUrlRedirect o urlRedirect, come funziona prefixRedirect dipende da come lo utilizzi:

• Se usi un defaultUrlRedirect, prefixRedirect è a tutti gli effetti una anteporre il prefisso perché il percorso corrispondente è sempre /.
• Se utilizzi un urlRedirect all'interno della regola di route o del percorso di un matcher di percorso , prefixRedirect è un prefisso di sostituzione in base a come il percorso corrisponde a 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 a destra indica la configurazione API per un reindirizzamento URL predefinito.

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
           

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
          

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
              pathRedirect: "/newPath"
           

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

• Per informazioni sulle mappe di regole di routing con Cloud Service Mesh, consulta Mappe di regole di routing di Cloud Service Mesh Panoramica.