Panoramica delle mappe URL

IGoogle Cloud bilanciatori del carico delle applicazioni e Cloud Service Mesh utilizzano una Google Cloud risorsa di configurazione 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 :

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

  • 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 da bilanciatori del carico delle applicazioni esterni regionali, bilanciatori del carico delle applicazioni interni regionali e Cloud Service Mesh.

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
Cloud Service Mesh INTERNAL_SELF_MANAGED Regionale Servizi di backend

Non tutte le funzionalità della mappa degli URL sono disponibili per tutti i prodotti. Le mappe URL utilizzate con i bilanciatori del carico delle applicazioni esterni globali, i bilanciatori del carico delle applicazioni esterni regionali, i 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, vedi Confronto delle 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 nelle applicazioni App Hub.

Come funzionano le mappe URL

Quando una richiesta arriva al bilanciatore del carico, quest'ultimo la indirizza a un servizio di backend o a un bucket di backend specifico in base alle regole definite nella mappa URL.

Un servizio di backend rappresenta una raccolta di backend, che sono 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 destinazioni possibili sono le seguenti:

Inoltre, i bilanciatori del carico delle applicazioni esterni globali supportano quanto segue:

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 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 set di server:
    • Uno ospita il sito web della tua organizzazione (servizio di backend: org-site).
    • Uno ospita il sito web complessivo dei video di formazione (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) vanno 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/* vanno al servizio di backend video-hd.
  • Le richieste a example.net/video/sd/* vanno 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, 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 quindi 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.
Esempio di configurazione del servizio di backend (fai clic per ingrandire).

Denominazione del bilanciatore del carico

Per i bilanciatori del carico delle applicazioni, il nome del bilanciatore del carico è sempre uguale al nome della mappa URL. Il comportamento di ciascuna Google Cloud interfaccia è il seguente:

  • ConsoleGoogle Cloud . Se crei un bilanciatore del carico delle applicazioni utilizzando la consoleGoogle Cloud , alla mappa URL viene assegnato automaticamente lo stesso nome che hai inserito per il nome del bilanciatore del carico.
  • Google Cloud CLI o API. Se crei un bilanciatore del carico delle applicazioni utilizzando gcloud CLI o l'API, inserisci un nome a tua scelta durante la creazione della mappa URL. Il nome della mappa URL viene quindi visualizzato nella consoleGoogle Cloud come nome del bilanciatore del carico.

Per scoprire di più sul funzionamento della denominazione per i bilanciatori del carico di rete proxy e i bilanciatori del carico di rete passthrough, consulta Panoramica dei servizi di backend: denominazione del bilanciatore del carico.

Componenti della mappa URL

Una mappa URL è un insieme di risorse di configurazione che indirizzano le richieste di URL a servizi di backend o bucket di backend. Google Cloud La mappa degli URL lo fa utilizzando le parti nome host e percorso per ogni URL che elabora:

  • 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 una 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.

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

  • 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 o tramite espressioni regolari 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 matcher percorso, è necessaria una singola regola host che includa almeno il nome host example.net. La stessa regola host potrebbe gestire anche le richieste per altri nomi host, ma le indirizzerebbe allo stesso matcher percorso.

    Se devi indirizzare le richieste a espressioni di corrispondenza dei percorsi diverse, 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 essere abbinati specificando * nella regola host. È anche possibile trovare una corrispondenza parziale del nome host 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 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 quando viene abbinata 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 path matcher è 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 host associata al matcher percorso e i cui percorsi URL non corrispondono ad alcuna regola percorso nel matcher percorso.

    • Regole percorso. Per ogni matcher di percorso, puoi specificare una o più regole di percorso, che sono coppie chiave-valore che mappano un percorso URL a un singolo servizio di backend o bucket di backend.

      Gli operatori di corrispondenza dei pattern flessibili consentono di abbinare più parti di un percorso URL, inclusi URL parziali e suffissi (estensioni dei file), utilizzando la sintassi con 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. Per maggiori dettagli, vedi Caratteri jolly, espressioni regolari e URL dinamici nelle regole di percorso.

      Se hai bisogno di funzionalità di routing più avanzate, ad esempio se vuoi indirizzare il traffico per un URL univoco a più servizi, puoi utilizzare le regole di route anziché le regole di percorso.

    • Regole di route. Le regole di route possono essere utilizzate in alternativa alle regole di percorso quando hai bisogno di funzionalità di routing del traffico avanzate, ad esempio il routing del traffico in base al percorso URL, alle intestazioni HTTP e parametri di ricerca.

      Puoi configurare le regole di routing con operatori di corrispondenza dei pattern flessibili e variabili denominate. Questi operatori possono essere utili quando devi indirizzare il traffico ed eseguire riscritture in base a percorsi degli URL complessi. Per i dettagli, vedi Caratteri jolly e operatori di corrispondenza dei pattern nei modelli di percorso per le regole di route.

      Puoi anche configurare le regole di routing in modo che corrispondano alle espressioni regolari che corrispondono al percorso, parametri di ricerca o alle intestazioni nella richiesta in entrata. Per maggiori dettagli, vedi Espressioni regolari nelle regole di routing.

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.

Relazione tra regola host e matcher percorso

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

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

Relazione tra URL e backend

Ogni URL univoco viene 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 relativo matcher di percorso a cui fa riferimento.

  • Quando utilizzi le regole di percorso in un matcher di percorso, non puoi creare più di una regola di 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 istanza di backend o gruppi di endpoint di rete (NEG) di backend in zone e regioni diverse e puoi creare bucket di backend che utilizzano classi di Multi-Regional Storage.

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

    Allo stesso modo, 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 nel servizio di backend ponderato.

Mappe URL e protocolli

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 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. Il servizio di backend predefinito 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 relativi gruppi di istanza di backend o NEG di backend in base alla configurazione del servizio di backend.

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

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 backend corretto, 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 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 di percorso a cui fa riferimento la regola host:

    • Se il matcher 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 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, allora Google Cloud indirizza le richieste al servizio di backend o al bucket di backend per quella regola di 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 confrontato con 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 predefinito del matcher percorso, a seconda di quale hai definito.

Vincoli di configurazione della mappa URL

Le sezioni seguenti descrivono alcuni vincoli di configurazione per i componenti della mappa URL.

Matcher di espressioni regolari nelle regole host e route

Le regole host ti consentono di confrontare la parte del nome host di un URL con l'insieme dei nomi host configurati della regola host. Puoi scegliere di utilizzare un nome host specifico o un carattere jolly * nel campo hostRules[].hosts[] da confrontare con il nome host nella richiesta in entrata.

Le regole di route ti consentono di definire regole di corrispondenza che possono corrispondere a un'espressione regolare nel percorso, nella stringa di query o in un'intestazione della richiesta in entrata. Le regole di routing supportano l'uso di espressioni regolari per i seguenti campi della mappa URL:

  • pathMatchers[].routeRules[].matchRules[].regexMatch: un'espressione regolare utilizzata per trovare una corrispondenza con il percorso della richiesta in entrata.
  • pathMatchers[].routeRules[].matchRules[].headerMatches[].regexMatch: un'espressione regolare che contiene un predicato che corrisponde a un'intestazione della richiesta in entrata.
  • pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].regexMatch: Un'espressione regolare che contiene un predicato che corrisponde a un parametro di query della richiesta in entrata.

Una richiesta viene considerata corrispondente a una routeRule quando una qualsiasi delle matchRules è soddisfatta. Tuttavia, i predicati all'interno di una determinata matchRule hanno una semantica AND. ovvero tutti i predicati all'interno di una matchRule devono corrispondere affinché la richiesta corrisponda alla regola.

Note aggiuntive sull'utilizzo:

  • Le espressioni regolari sono supportate solo per i seguenti prodotti:

    • Bilanciatori del carico delle applicazioni interni regionali
    • Bilanciatori del carico delle applicazioni interni tra regioni
    • Bilanciatori del carico delle applicazioni esterni regionali

    I bilanciatori del carico delle applicazioni globali e classici non supportano le espressioni regolari.

  • Per creare le espressioni regolari, devi utilizzare la sintassi RE2. Per l'elenco completo delle limitazioni e degli operatori consentiti nelle mappe URL, consulta le specifiche RE2 per le mappe URL.

  • La corrispondenza mediante espressioni regolari è costosa in termini di consumo di memoria e latenze di elaborazione delle richieste. Se scegli di utilizzare la corrispondenza delle espressioni regolari, devi tenere conto del peggioramento delle prestazioni quando pianifichi l'implementazione. Ad esempio, se hai una mappa URL con una singola espressione regolare, puoi prevedere che la latenza del bilanciatore del carico aumenterà di 100 microsecondi per richiesta. Se la tua mappa URL contiene 5 espressioni regolari da corrispondere, puoi prevedere un aumento della latenza di 200 microsecondi per richiesta.

Esempio 1: utilizzare un'espressione regolare per trovare una corrispondenza con il percorso

Il percorso viene considerato una corrispondenza se corrisponde all'espressione regolare specificata da regexMatch dopo la rimozione di eventuali parametri di ricerca e ancore forniti con l'URL originale. Ad esempio, nelle seguenti mappe URL di esempio, l'espressione regolare della regola di percorso /videos/hd.* si applicherebbe a un URL con il percorso /videos/hd-abcd?key=245.

defaultService: projects/example-project/global/backendServices/org-site
name: rule-match-url-map
hostRules:
- hosts:
  - '*' # Match any host
  pathMatcher: video-matcher
- hosts:
  - example.net
  pathMatcher: video-matcher
pathMatchers:
- name: video-matcher
  # Optional: default service for this path matcher if no routeRules match
  defaultService: projects/example-project/global/backendServices/video-site
  routeRules:
  - priority: 100000
    matchRules:
    - regexMatch: /videos/hd.*
    routeAction:
      weightedBackendServices:
      - backendService: projects/example-project/global/backendServices/video-hd
        weight: 100

Di seguito è riportata una spiegazione per ogni campo della mappa degli URL di esempio:

  • defaultService: specifica il servizio di backend predefinito da utilizzare se nessun'altra regola nella mappa URL corrisponde alla richiesta in entrata.
  • name: assegna il nome rule-match-url-map a questa configurazione della mappa URL.
  • hostRules: definisce un elenco di regole per la corrispondenza dell'intestazione host delle richieste in entrata. La prima regola corrisponde a qualsiasi host (*) e indirizza il traffico al matcher percorso pathMatcher denominato video-matcher. La seconda regola corrisponde in modo specifico all'host example.net e indirizza anche il traffico al matcher percorso denominato video-matcher.
  • pathMatchers: definisce un elenco di matcher di percorso denominati.
  • name: definisce un matcher di percorso denominato video-matcher.
  • defaultService: imposta il servizio predefinito per questo matcher di percorso. Questo servizio viene utilizzato se una richiesta corrisponde alle regole host che rimandano a video-matcher, ma non corrisponde a nessuno dei routeRules al suo interno.
  • routeRules: contiene un elenco di regole per trovare una corrispondenza con il percorso dell'URL.
  • priority: imposta la priorità di questa regola su 100.000. Le regole vengono valutate in ordine dal numero di priorità più basso a quello più alto.
  • matchRules: Contiene le condizioni per la corrispondenza di questa regola di route.
  • regexMatch: questa condizione verifica se il percorso dell'URL corrisponde all'espressione regolare /videos/hd.* (ad esempio, "/videos/hd" e "/videos/hd-caching").
  • routeAction: specifica l'azione da intraprendere se tutte le condizioni in matchRules sono soddisfatte.
  • weightedBackendServices: distribuisce il traffico tra un elenco di servizi di backend in base ai pesi.
  • backendService: specifica il servizio di backend a cui indirizzare il traffico.
  • weight: assegna un peso di 100 a questo servizio di backend. Poiché è l'unico servizio nell'elenco, riceverà il 100% del traffico corrispondente a questa routeRule.

La seguente mappa degli URL mostra un esempio simile senza utilizzare un routeAction.

defaultService: projects/example-project/global/backendServices/video-site
name: path-matcher-videos
routeRules:
  matchRules:
  - regexMatch: /videos/hd.*
  priority: 100000
  service: projects/example-project/global/backendServices/video-hd

Esempio n. 2: utilizzare un'espressione regolare per trovare una corrispondenza con le intestazioni

L'intestazione viene considerata una corrispondenza se il valore dell'intestazione corrisponde all'espressione regolare specificata da regexMatch. Ad esempio, nella seguente mappa di URL di esempio, l'espressione regolare del nome dell'intestazione, .*Android.*-hd, si applicherebbe a una richiesta con l'intestazione User-Agent:123Androidabc-hd.

defaultService: projects/example-project/regions/us-central1/backendServices/default-backend-service
name: header-match-url-map
hostRules:
- hosts:
  - '*'  # Match any host
  pathMatcher: header-matcher
pathMatchers:
- name: header-matcher
  # Optional: default service for this path matcher if no routeRules match
  defaultService: projects/example-project/regions/us-central1/backendServices/default-backend-service
  routeRules:
  - priority: 1
    matchRules:
    - headerMatches:
      - headerName: User-Agent
        regexMatch: .*Android.*-hd
    # This prefix match applies to the path part of the URL
    - prefixMatch: /video/
    # service: can be used instead of routeAction if no other actions are needed
    service: projects/example-project/regions/us-central1/backendServices/video-backend-service
    # Alternatively, use routeAction to specify the service:
    # routeAction:
    #   weightedBackendServices:
    #   - backendService: projects/example-project/regions/us-central1/backendServices/video-backend-service
    #     weight: 100

Di seguito è riportata una spiegazione per ogni campo della mappa degli URL di esempio:

  • defaultService: specifica il servizio di backend predefinito da utilizzare se nessun'altra regola nella mappa URL corrisponde alla richiesta in entrata.
  • name: assegna il nome header-match-url-map a questa configurazione della mappa URL.
  • hostRules: definisce un elenco di regole per la corrispondenza dell'intestazione host delle richieste in entrata. La regola corrisponde a qualsiasi host ("*") e indirizza il traffico al matcher intestazione denominato pathMatcher.
  • pathMatchers: definisce un elenco di matcher di percorso denominati.
  • name: definisce un matcher di percorso denominato header-matcher.
  • defaultService: imposta il servizio predefinito per questo matcher di percorso. Questo servizio viene utilizzato se una richiesta corrisponde alla regola host, ma non a nessuno dei routeRules all'interno di questo matcher percorso.
  • routeRules: contiene un elenco di regole per trovare le corrispondenze delle richieste in entrata in base a intestazioni e percorsi.
  • priority: imposta la priorità di questa regola su 1. Le regole vengono valutate in ordine dal numero di priorità più basso a quello più alto.
  • matchRules: contiene un elenco di condizioni che devono essere tutte vere affinché la regola corrisponda.
  • headerMatches: specifica le condizioni in base alle intestazioni delle richieste.
  • headerName: cerca l'intestazione User-Agent.
  • regexMatch: verifica se il valore dell'intestazione User-Agent corrisponde all'espressione regolare .*Android.*-hd. Corrisponderebbe agli User-Agent che indicano un dispositivo Android, con una stringa contenente "-hd".
  • prefixMatch: se impostata su /video/, questa condizione verifica se il percorso dell'URL inizia con "/video/".
  • service: se vengono soddisfatte tutte le condizioni matchRules, il traffico viene indirizzato a questo servizio di backend.
  • La sezione routeAction commentata mostra un modo alternativo per specificare il servizio di backend, che sarebbe necessario se dovessi configurare altre azioni di route come la riscrittura degli URL, le trasformazioni delle intestazioni o i servizi di backend ponderati.

Esempio 3: utilizzare un'espressione regolare per trovare corrispondenze con parametri di ricerca

Il parametro di ricerca viene considerato una corrispondenza se il valore del percorso con i parametri di ricerca corrisponde all'espressione regolare specificata da regexMatch. Ad esempio, nella seguente mappa degli URL di esempio, l'espressione regolare del parametro di query, /im.*/.*.html, si applicherebbe a un URL con parametri di ricerca come /images/random_page.html?param1=param_value_123abc-hd.

defaultService: projects/example-project/regions/us-central1/backendServices/sample-bs
name: query-match-url-map
hostRules:
- hosts:
  - '*'  # Match any host
  pathMatcher: query-matcher
pathMatchers:
- name: query-matcher
  # Optional: default service for this path matcher if no routeRules match
  defaultService: projects/example-project/regions/us-central1/backendServices/sample-bs
  routeRules:
  - priority: 1
    matchRules:
    - queryParameterMatches:
      - name: param1   #parameter name in query
        regexMatch: param_value_.*-hd
    # This regexMatch applies to the path part of the URL
    - regexMatch: /im.*/.*.html
    # Directs traffic to this service if all conditions in matchRules are met
    service: projects/example-project/regions/us-central1/backendServices/sample-images-bs

Di seguito è riportata una spiegazione per ogni campo della mappa degli URL di esempio:

  • hostRules: aggiunge una regola per trovare corrispondenze con tutti gli host (*) e indirizza il traffico al pathMatcher denominato query-matcher.
  • pathMatchers: definisce un matcher di percorso denominato query-matcher.
  • routeRules: inserisce il blocco routeRules fornito all'interno di query-matcher.
  • priority: imposta la priorità di questa regola su 1. Le regole vengono valutate in ordine dal numero di priorità più basso a quello più alto.
  • matchRules: contiene le condizioni per routeRules.
  • queryParameterMatches: verifica se il parametro di query denominato "param1" corrisponde all'espressione regolare param_value_.*-hd.
  • regexMatch: l'espressione regolare /im.*/.*.html si applica al percorso dell'URL (ad esempio /images/random_page.html), prima della stringa di query.
  • service: specifica il servizio di backend da utilizzare se tutte le condizioni all'interno di matchRules sono vere.

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

  • Una regola di percorso (pathMatchers[].pathRules[]) può includere solo un carattere jolly (*) dopo una barra (/). Ad esempio, /videos/* e /videos/hd/* sono validi per le regole di percorso, ma /videos* e /videos/hd* non lo sono.

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

  • Una corrispondenza con prefisso (pathMatchers[].routeRules[].matchRules[].prefixMatch) non considera * come carattere jolly, ma come carattere letterale.

  • I matcher di percorso (e le mappe URL in generale) non offrono funzionalità che funzionano come la direttiva <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 servizi di backend diversi, 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 matcher di percorso con un insieme limitato di regole del percorso. Per i casi più complessi, devi eseguire la corrispondenza delle espressioni regolari basate sul percorso sui backend.

Caratteri jolly e operatori di corrispondenza di pattern nei modelli di percorso per le regole di route

Gli operatori di corrispondenza flessibile dei pattern consentono di abbinare più parti di un percorso 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 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 indirizza il traffico per un'applicazione e-commerce che dispone di servizi separati per le informazioni sul carrello e sull'utente. Puoi configurare routeRules con operatori di corrispondenza flessibili e variabili denominate per inviare l'ID univoco dell'utente a una pagina dei dettagli dell'account utente e le informazioni sul 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 sull'utente sia informazioni sul carrello:

  1. Il percorso della richiesta corrisponde a pathTemplateMatch all'interno di cart-matcher pathMatcher. 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 iparametri di ricercay 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 URL riscritto: /abc@xyz.com-FL0001090004/entries/SJFI38u3401nms?fields=FULL&client_type=WEB.

Quando un cliente richiede /xyzwebservices/v2/xyz/users/abc%40xyz.com/accountinfo/abc-1234, che contiene solo informazioni sull'utente e sull'account, si verifica quanto segue:

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

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

Operatore Corrisponde a
* Un singolo segmento di percorso, esclusi i caratteri separatori di percorso / circostanti.
** Trova corrispondenze con zero o più caratteri, inclusi i 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 denominata che corrisponde a un segmento di percorso. Trova un singolo segmento di percorso, esclusi i caratteri separatori di percorso /.
{name=news/*} Una variabile denominata che corrisponde esplicitamente a due segmenti di percorso: news e un segmento jolly *.
{name=*/news/*} Una variabile denominata che corrisponde 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 flessibile dei pattern, tieni presente quanto segue:

  • È 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 iparametri di ricercay 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 nel formato non codificato.
  • 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 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 alle variabili, riordinarle o ometterle nel campo pathTemplateRewrite quando definisci urlRewrite.

Quando utilizzi variabili e operatori per la corrispondenza flessibile dei pattern per la riscrittura degli URL, tieni presente quanto segue:

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

Flusso di lavoro di esempio della mappa URL con un bilanciatore del carico delle applicazioni esterno

L'esempio seguente illustra l'ordine delle operazioni per una mappa degli 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; tuttavia, puoi sostituirli con 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 la configurazione di mappe URL con criteri di corrispondenza del percorso e 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 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 URL esatto /video/hd o il prefisso del percorso URL /video/hd/* a un servizio di backend esistente denominato video-hd.
    • Aggiungi regole di percorso che indirizzano le richieste per il percorso URL esatto /video/sd o il prefisso del percorso 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 essere simile alla seguente:

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 percorso, matcher percorso e una regola host.
Mappa URL con una regola di percorso, corrispondenze di percorso e una regola host (fai clic per ingrandire).

La seguente tabella spiega l'elaborazione delle richieste 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 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 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 percorso indirizzano le richieste per i 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 per i percorsi URL che corrispondono esattamente a /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 con alcun pattern specifico 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 descritto nella tabella seguente.

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

All'interno di un defaultUrlRedirect o urlRedirect, pathRedirect funziona sempre nel seguente modo:

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

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

  • Se utilizzi un defaultUrlRedirect, prefixRedirect è effettivamente un prefisso anteposto perché il percorso corrispondente è sempre /.
  • Se utilizzi un urlRedirect all'interno di una regola di percorso o di una regola di route di un matcher di percorso, prefixRedirect è una sostituzione del prefisso in base alla corrispondenza del percorso richiesto come definito nella regola di 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 dell'API per un reindirizzamento URL predefinito.

Vuoi Realizzato 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
Reindirizzamento da HTTP a HTTPS + host

Reindirizzamento
http://any-host-name/path
a
https://www.example.com/path 
            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
Reindirizzamento da HTTP a HTTPS + reindirizzamento host + reindirizzamento percorso completo

Reindirizzamento
http://any-host-name/path
a
https://www.example.com/newPath 
            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
              pathRedirect: "/newPath"
Reindirizzamento 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