Configurazione di un bilanciatore del carico HTTP(S) esterno globale con Cloud Run, App Engine o Cloud Functions

Questa pagina mostra come creare un bilanciatore del carico HTTP(S) esterno per il routing delle richieste ai backend serverless. Il termine serverless si riferisce ai seguenti prodotti di serverless computing:

  • Ambiente standard,
  • Cloud Functions
  • Cloud Run

L'integrazione del bilanciamento del carico HTTP(S) con il gateway API consente ai tuoi backend serverless di sfruttare tutte le funzionalità disponibili da Cloud Load Balancing. Per saperne di più, vedi Bilanciamento del carico HTTP(S) per il gateway API. Per configurare il bilanciamento del carico HTTP(S) per il routing del traffico a un gateway API, consulta la guida introduttiva al bilanciamento del carico HTTP(S) per il gateway API. Questa funzionalità è in anteprima.

NEG Serverless consente di utilizzare app serverless Google Cloud con bilanciamento del carico HTTP(S). Dopo aver configurato un bilanciatore del carico con il backend NEG serverless, le richieste al bilanciatore del carico vengono instradate al backend dell'app serverless.

Per ulteriori informazioni sui NEG serverless, leggi la panoramica dei NEG serverless.

Prima di iniziare

  1. Esegui il deployment di un servizio App Engine, Cloud Functions o Cloud Run.
  2. Se non l'hai ancora fatto, installa l'interfaccia a riga di comando di Google Cloud.
  3. Configura le autorizzazioni.
  4. Aggiungi una risorsa di certificato SSL.

Eseguire il deployment di un servizio App Engine, Cloud Functions o Cloud Run

Le istruzioni riportate in questa pagina presuppongono che il servizio Cloud Run, Cloud Functions o App Engine siano già in esecuzione.

Per l'esempio in questa pagina, abbiamo utilizzato la guida rapida di Cloud Run Python per eseguire il deployment di un servizio Cloud Run nell'area geografica us-central1. Il resto della pagina mostra come configurare un bilanciatore del carico HTTP(S) esterno che utilizza un backend NEG serverless per instradare le richieste a questo servizio.

Se non hai già eseguito il deployment di un'app serverless o se vuoi provare un NEG serverless con un'app di esempio, utilizza una delle seguenti guide rapide. Puoi creare un'app serverless in qualsiasi area geografica, ma in un secondo momento dovrai utilizzare la stessa area geografica per creare il NEG serverless e il bilanciatore del carico.

Cloud Run

Per creare una semplice applicazione Hello World, pacchettizzala in un'immagine container, quindi esegui il deployment dell'immagine container in Cloud Run, vedi Quickstart: build ed deployment.

Se hai già caricato un container di esempio in Container Registry, consulta Guida rapida: deployment di un container predefinito di esempio.

Cloud Functions

Consulta la guida rapida di Cloud Functions: Python.

App Engine

Consulta le seguenti guide rapide di App Engine per Python 3:

Installa l'interfaccia a riga di comando di Google Cloud

Installa l'interfaccia a riga di comando di Google Cloud. Consulta la sezione Panoramica di gcloud per informazioni sul concetto e sull'installazione dello strumento.

Se non hai mai eseguito l'interfaccia a riga di comando gcloud, esegui gcloud init per inizializzare la directory gcloud.

Configura autorizzazioni

Per seguire questa guida, devi creare un NEG serverless e creare un bilanciatore del carico HTTP(S) esterno in un progetto. Devi essere un proprietario o un editor del progetto oppure disporre dei seguenti ruoli IAM di Compute Engine:

Attività Ruolo obbligatorio
Crea bilanciatore del carico e componenti di networking Amministratore di rete
Creare e modificare i NEG Amministratore istanze Compute
Creare e modificare certificati SSL Amministratore sicurezza

Prenota un indirizzo IP esterno

Ora che i tuoi servizi sono in esecuzione, configura un indirizzo IP esterno statico globale che i clienti utilizzano per raggiungere il bilanciatore del carico.

console

  1. Vai alla pagina Indirizzi IP esterni in Google Cloud Console.
    Vai agli indirizzi IP esterni
  2. Fai clic su Prenota indirizzo statico per prenotare un indirizzo IPv4.
  3. Assegna un Nome a example-ip.
  4. Imposta il livello di rete su Premium.
  5. Imposta la versione IP su IPv4.
  6. Imposta il Tipo su Globale.
  7. Fai clic su Prenota.

gcloud 

gcloud compute addresses create example-ip \
    --network-tier=PREMIUM \
    --ip-version=IPV4 \
    --global

Prendi nota dell'indirizzo IPv4 riservato:

gcloud compute addresses describe example-ip \
    --format="get(address)" \
    --global

Creazione di una risorsa del certificato SSL

Per creare un bilanciatore del carico HTTPS, devi aggiungere una risorsa certificato SSL al front-end del bilanciatore del carico. Crea una risorsa certificato SSL utilizzando un certificato SSL gestito da Google o un certificato SSL autogestito.

  • Certificati gestiti da Google. L'utilizzo di certificati gestiti da Google è consigliato perché Google Cloud ottiene, gestisce e rinnova automaticamente tali certificati. Per creare un certificato gestito da Google, devi disporre di un dominio e dei record DNS per quel dominio affinché sia eseguito il provisioning del certificato. Se non hai ancora un dominio, puoi riceverne uno da Google Domains. Per ulteriori informazioni, consulta la Guida introduttiva all'utilizzo di Google Domains. Inoltre, devi aggiornare il record DNS A del dominio in modo che punti all'indirizzo IP del bilanciatore del carico creato nel passaggio precedente (example-ip). Per istruzioni dettagliate, consulta l'articolo Utilizzo dei certificati gestiti da Google.

  • Certificati autofirmati. Se al momento non vuoi configurare un dominio, puoi utilizzare un certificato SSL autofirmato per i test.

Questo esempio presuppone che tu abbia già creato una risorsa certificato SSL.

Se vuoi testare questo processo senza creare una risorsa di certificato SSL (o un dominio come richiesto dai certificati gestiti da Google), puoi comunque seguire le istruzioni riportate in questa pagina per configurare un bilanciatore del carico HTTP.

Crea il bilanciatore del carico

Nel diagramma seguente, il bilanciatore del carico utilizza un backend NEG serverless per indirizzare le richieste a un servizio Cloud Run serverless. Per questo esempio, abbiamo utilizzato la guida rapida di Python Cloud Run per eseguire il deployment di un servizio Cloud Run.

Architettura di bilanciamento del carico HTTPS esterno per un'applicazione Cloud Run.
Architettura del bilanciamento del carico HTTPS esterno per un'applicazione Cloud Run (fai clic per ingrandire)

Poiché i controlli di integrità non sono supportati per i servizi di backend con backend NEG serverless, non è necessario creare una regola firewall che consenta i controlli di integrità se il bilanciatore del carico ha solo backend NEG serverless.

console

Avvia la configurazione

  1. In Google Cloud Console, vai alla pagina Bilanciamento del carico.

    Vai al bilanciamento del carico

  2. In Bilanciamento del carico HTTP(S), fai clic su Avvia configurazione.
  3. Nella sezione Solo per Internet o interno, seleziona Da Internet alle mie VM.
  4. In Globale o a livello di area geografica, seleziona Bilanciatore del carico HTTP(S) globale.
  5. Fai clic su Continua.
  6. In Nome del bilanciatore del carico, inserisci serverless-lb.
  7. Per continuare, tieni aperta la finestra.

Configurazione dei servizi di backend

  1. Fai clic su Configurazione backend.
  2. Nel menu a discesa Crea o seleziona un servizio di backend, tieni premuto il puntatore del mouse su Servizi di backend, quindi seleziona Crea un servizio di backend.
  3. Inserisci un nome.
  4. In Tipo di backend, seleziona Gruppo di endpoint di rete serverless.
  5. Non modificare il protocollo. Questo parametro viene ignorato.
  6. In Backend, nella finestra New backend, seleziona Create Serverless network endpoint group (Crea gruppo di endpoint di rete serverless).
  7. Inserisci un nome.
  8. In Area geografica, seleziona us-central1. Seleziona Cloud Run.
  9. Seleziona Seleziona il nome del servizio.
  10. Dal menu a discesa Servizio, seleziona il servizio Cloud Run per cui vuoi creare un bilanciatore del carico.
  11. Fai clic su Crea.
  12. Nella finestra Nuovo backend, fai clic su Fine.
  13. Fai clic su Crea.

Configurazione delle regole di hosting e della corrispondenza di percorso

Le regole di hosting e le corrispondenze di percorso sono componenti di configurazione di una mappa URL di un bilanciatore del carico HTTP(S) esterno.

  1. Fai clic su Regole host e percorso.
  2. Mantieni gli host e i percorsi predefiniti. Per questo esempio, tutte le richieste vengono indirizzate al servizio di backend creato nel passaggio precedente.

Configurazione del frontend

  1. Fai clic su Configurazione frontend.
  2. Inserisci un nome.
  3. Per creare un bilanciatore del carico HTTPS, devi disporre di un certificato SSL (gcloud compute ssl-certificates list).

    Ti consigliamo di utilizzare un certificato gestito da Google come descritto in precedenza.

    4. Per configurare un bilanciatore del carico HTTP(S) esterno, compila i campi come segue.

    Verifica che le seguenti opzioni siano configurate con questi valori:

    Proprietà Valore (digita un valore o seleziona un'opzione come specificato)
    Protocollo HTTPS
    Livello di servizio di rete Premium
    Versione IP IPv4
    Indirizzo IP example-ip
    Porta 443
    Certificato Seleziona un certificato SSL esistente o creane uno nuovo.

    Per creare un bilanciatore del carico HTTPS, devi disporre di una risorsa certificato SSL da utilizzare nel proxy HTTPS. Puoi creare una risorsa certificato SSL utilizzando un certificato SSL gestito da Google o un certificato SSL autogestito.
    Per creare un certificato gestito da Google devi avere un dominio. Il record A del dominio deve risolversi nell'indirizzo IP del bilanciatore del carico (in questo esempio, example-ip). L'utilizzo dei certificati gestiti da Google è consigliato perché Google Cloud li riceve, li gestisce e li rinnova automaticamente. Se non hai un dominio, puoi utilizzare un certificato SSL autofirmato per i test.
    (Facoltativo) Attivare il reindirizzamento da HTTP a HTTPS Utilizza questa casella di controllo per attivare i reindirizzamenti dalla porta 80 alla porta 443.

    L'attivazione di questa casella di controllo crea un bilanciatore del carico HTTP parziale aggiuntivo che utilizza lo stesso indirizzo IP del bilanciatore del carico HTTPS e reindirizza le richieste HTTP al frontend HTTPS del bilanciatore del carico.

    Questa casella di controllo può essere selezionata soltanto quando è selezionato il protocollo HTTPS e viene utilizzato un indirizzo IP riservato.

    Se vuoi testare questo processo senza configurare una risorsa di certificato SSL (o un dominio come richiesto dai certificati gestiti da Google), puoi configurare un bilanciatore del carico HTTP.

    Per creare un bilanciatore del carico HTTP, verifica che siano configurate le seguenti opzioni con i seguenti valori:

    Proprietà Valore (digita un valore o seleziona un'opzione come specificato)
    Protocollo HTTP
    Livello di servizio di rete Premium
    Versione IP IPv4
    Indirizzo IP example-ip
    Porta 80
  4. Fai clic su Fine.

Rivedi la configurazione

  1. Fai clic su Esamina e finalizza.
  2. Esamina le regole di backend, host e percorso e frontend.
  3. Fai clic su Crea.
  4. Attendi che la creazione del bilanciatore del carico sia completa.
  5. Fai clic sul nome del bilanciatore del carico (serverless-lb).
  6. Prendi nota dell'indirizzo IP del bilanciatore del carico, che utilizzerai nella prossima attività. È noto come IP_ADDRESS.

gcloud

  1. Crea un NEG serverless per la tua app serverless.

    Per creare un NEG serverless con un servizio Cloud Run: 

       gcloud compute network-endpoint-groups create SERVERLESS_NEG_NAME \
       --region=us-central1 \
       --network-endpoint-type=serverless  \
       --cloud-run-service=CLOUD_RUN_SERVICE_NAME
    Per ulteriori opzioni, consulta la guida di riferimento gcloud per gcloud compute network-endpoint-groups create.
  2. Crea un servizio di backend. 

       gcloud compute backend-services create BACKEND_SERVICE_NAME \
       --load-balancing-scheme=EXTERNAL_MANAGED \
       --global
  3. Aggiungi il NEG serverless come backend al servizio di backend: 

       gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
       --global \
       --network-endpoint-group=SERVERLESS_NEG_NAME \
       --network-endpoint-group-region=us-central1
  4. Crea una mappa URL per instradare le richieste in entrata al servizio di backend: 

       gcloud compute url-maps create URL_MAP_NAME \
       --default-service BACKEND_SERVICE_NAME

    Questa mappa URL di esempio ha come target un solo servizio di backend che rappresenta una singola app serverless, quindi non è necessario configurare regole host o corrispondenze del percorso. Se hai più di un servizio di backend, puoi utilizzare le regole dell'host per indirizzare le richieste a servizi diversi in base al nome host e configurare i matcher percorso per indirizzare le richieste a servizi diversi in base al percorso della richiesta.

  5. Per creare un bilanciatore del carico HTTPS, devi avere una risorsa certificato SSL da utilizzare nel proxy di destinazione HTTPS. Puoi creare una risorsa certificato SSL utilizzando un certificato SSL gestito da Google o un certificato SSL autogestito. L'utilizzo di certificati gestiti da Google è consigliato perché Google Cloud ottiene, gestisce e rinnova automaticamente tali certificati.

    Per creare un certificato gestito da Google, devi avere un dominio. Se non hai un dominio, puoi utilizzare un certificato SSL autofirmato per i test.

    Per creare una risorsa di certificato SSL gestita da Google: 
       gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
       --domains DOMAIN
    Per creare una risorsa di certificato SSL autogestita: 
       gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
       --certificate CRT_FILE_PATH \
       --private-key KEY_FILE_PATH

  6. Crea un proxy HTTP(S) di destinazione per instradare le richieste alla tua mappa URL.

    Per un bilanciatore del carico HTTP, crea un proxy di destinazione HTTP:

       gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \
      --url-map=URL_MAP_NAME

    Per un bilanciatore del carico HTTPS, crea un proxy di destinazione HTTPS. Il proxy è la parte del bilanciatore del carico che contiene il certificato SSL per il bilanciamento del carico HTTPS, quindi puoi anche caricare il certificato in questo passaggio.

       gcloud compute target-https-proxies create TARGET_HTTPS_PROXY_NAME \
       --ssl-certificates=SSL_CERTIFICATE_NAME \
       --url-map=URL_MAP_NAME
  7. Crea una regola di forwarding per instradare le richieste in entrata al proxy.

    Per un bilanciatore del carico HTTP:

       gcloud compute forwarding-rules create HTTP_FORWARDING_RULE_NAME \
   --load-balancing-scheme=EXTERNAL_MANAGED \
   --network-tier=PREMIUM \
   --address=example-ip \
   --target-http-proxy=TARGET_HTTP_PROXY_NAME \
   --global \
   --ports=80

    Per un bilanciatore del carico HTTPS:

       gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \
       --load-balancing-scheme=EXTERNAL_MANAGED \
       --network-tier=PREMIUM \
       --address=example-ip \
       --target-https-proxy=TARGET_HTTPS_PROXY_NAME \
       --global \
       --ports=443

Connetti il dominio al bilanciatore del carico

Dopo aver creato il bilanciatore del carico, prendi nota dell'indirizzo IP associato al bilanciatore del carico, ad esempio 30.90.80.100. Per indirizzare il tuo dominio al bilanciatore del carico, crea un record A utilizzando il tuo servizio di registrazione del dominio. Se hai aggiunto più domini al tuo certificato SSL, devi aggiungere un record A per ognuno di essi, ognuno dei quali punta all'indirizzo IP del bilanciatore del carico. Ad esempio, per creare record A per www.example.com e example.com:

NAME                  TYPE     DATA
www                   A        30.90.80.100
@                     A        30.90.80.100

Se utilizzi Google Domains, consulta la pagina di assistenza di Google Domains per ulteriori informazioni.

Testa il bilanciatore del carico

Ora che hai configurato il bilanciatore del carico, puoi iniziare a inviare traffico all'indirizzo IP del bilanciatore del carico. Se hai configurato un dominio, puoi inviare traffico anche al nome del dominio. Tuttavia, la propagazione del DNS può richiedere del tempo, quindi puoi iniziare a utilizzare l'indirizzo IP per i test.

  1. Vai alla pagina Bilanciamento del carico in Google Cloud Console.
    Vai al bilanciamento del carico
  2. Fai clic sul bilanciatore del carico che hai appena creato.
  3. Prendi nota dell'indirizzo IP del bilanciatore del carico.
  4. Per un bilanciatore del carico HTTP, puoi testare il tuo bilanciatore del carico utilizzando un browser web visitando http://IP_ADDRESS. Sostituisci IP_ADDRESS con l'indirizzo IP del bilanciatore del carico. Dovresti essere reindirizzato alla home page del servizio helloworld.
  5. Per un bilanciatore del carico HTTPS, puoi testare il tuo bilanciatore del carico utilizzando un browser web visitando https://IP_ADDRESS. Sostituisci IP_ADDRESS con l'indirizzo IP del bilanciatore del carico. Dovresti essere reindirizzato alla home page del servizio helloworld.
    Se non funziona e utilizzi un certificato gestito da Google, verifica che lo stato della risorsa del certificato sia ATTIVO. Per ulteriori informazioni, consulta lo stato delle risorse dei certificati SSL gestiti da Google.
    Se hai utilizzato un certificato autofirmato per i test, il browser mostra un avviso. Devi indicare esplicitamente al browser di accettare un certificato autofirmato. Fai clic nell'avviso per visualizzare la pagina effettiva.

Opzioni di configurazione aggiuntive

Questa sezione espande l'esempio di configurazione per fornire opzioni di configurazione alternative e aggiuntive. Tutte le attività sono facoltative. in qualsiasi ordine.

Configura il bilanciamento del carico in più aree geografiche

Nell'esempio sopra riportato abbiamo un solo servizio Cloud Run che funge da backend. Poiché il NEG serverless può puntare a un solo endpoint alla volta, il bilanciamento del carico non viene effettivamente eseguito. Il bilanciatore del carico HTTP(S) esterno funge solo da frontend e invia il traffico all'endpoint dell'app helloworld specificato. Tuttavia, potresti voler pubblicare la tua app Cloud Run da più di un'area geografica per migliorare la disponibilità del tuo servizio e la latenza per gli utenti.

Se un servizio di backend contiene diversi NEG, il bilanciatore del carico bilancia il traffico inoltrando le richieste al NEG serverless nell'area geografica più vicina disponibile. Tuttavia, i servizi di backend possono contenere solo un NEG serverless per area geografica. Per rendere disponibile il tuo servizio Cloud Run in più aree geografiche, devi configurare il routing tra aree geografiche. Dovresti essere in grado di utilizzare uno schema di URL unico che funziona in qualsiasi parte del mondo, ma gestisce le richieste degli utenti dall'area geografica più vicina a quest'ultimo. Se l'area geografica più vicina non è disponibile o ha una capacità insufficiente, la richiesta verrà instradata a un'altra area geografica.

Per configurare la pubblicazione in più aree geografiche, devi utilizzare il livello di rete Premium per assicurarti che tutti i deployment Cloud Run a livello di area geografica siano compatibili e pronti per gestire il traffico da qualsiasi area geografica.

Per configurare un bilanciatore del carico a più aree geografiche:

  1. Configura due servizi Cloud Run in aree geografiche diverse. Supponiamo di aver eseguito il deployment di due servizi Cloud Run, uno in un'area geografica in Europa e un altro in un'area geografica negli Stati Uniti.
  2. Crea un bilanciatore del carico HTTP(S) esterno con la configurazione seguente:
    1. Configura un servizio di backend globale con due NEG serverless.
      1. Crea il primo NEG nella stessa area geografica del servizio Cloud Run di cui è stato eseguito il deployment in Europa.
      2. Crea il secondo NEG nella stessa area geografica del servizio Cloud Run di cui hai eseguito il deployment negli Stati Uniti.
    2. Imposta la configurazione del frontend con il livello di rete Premium.

Il resto della configurazione può essere la stessa descritta in precedenza. La configurazione risultante dovrebbe essere simile a questa:

Routing a più aree geografiche per applicazioni serverless con failover.
Routing multiregionale per applicazioni serverless con failover

Usa una sottoscrizione push Pub/Sub autenticata con un deployment Cloud Run in più aree geografiche

Per impostazione predefinita, un servizio Pub/Sub recapita solo i messaggi per il push di endpoint nella stessa area geografica Google Cloud in cui il servizio Pub/Sub archivia i messaggi. Per le richieste push autenticate, il bilanciatore del carico HTTP(S) esterno prevede un campo del pubblico specifico per l'area geografica in JWT della richiesta di push. Nel caso di un deployment a più aree geografiche, se la richiesta push viene instradata a un servizio Cloud Run in un'area geografica diversa, il token di pubblico JWT non viene autenticato e la richiesta push non riesce.

Per ovviare a questa limitazione specifica per area geografica:

  1. Crea un ID client OAuth per l'app.
  2. Esegui nuovamente il deployment dei servizi Cloud Run in tutte le aree geografiche in modo che utilizzino il nuovo ID client OAuth.
  3. Configura i messaggi push di Cloud Pub/Sub in modo che utilizzino l'ID client OAuth come pubblico nel token JWT.

Configurare il routing a livello di area geografica

Un motivo comune per pubblicare applicazioni da più aree geografiche è soddisfare i requisiti di località dei dati. Ad esempio, potresti assicurarti che le richieste effettuate dagli utenti europei vengano sempre gestite da un'area geografica situata in Europa. Per impostare questa funzionalità, devi avere uno schema di URL con URL distinti per gli utenti UE e non UE e indirizzare gli utenti UE agli URL UE.

In questo caso, dovresti utilizzare la mappa URL per instradare le richieste da URL specifici alle corrispondenti aree geografiche. Con una configurazione di questo tipo, le richieste destinate a un'area geografica non vengono mai recapitate a un'altra area geografica. In questo modo si ottiene l'isolamento tra le aree geografiche. Se, invece, un'area geografica non riesce, le richieste non vengono instradate a un'altra area geografica. Quindi questa configurazione non aumenta la disponibilità del tuo servizio.

Per configurare il routing a livello di area geografica, devi utilizzare il livello di rete Premium per poter combinare aree geografiche diverse in una singola regola di forwarding.

Per configurare un bilanciatore del carico con routing a livello di area geografica:

  1. Configura due servizi Cloud Run in aree geografiche diverse. Supponiamo di aver eseguito il deployment di due servizi Cloud Run: hello-world-eu in un'area geografica in Europa e hello-world-us in un'area geografica negli Stati Uniti.
  2. Crea un bilanciatore del carico HTTP(S) esterno con la configurazione seguente:
    1. Configura un servizio di backend con un NEG serverless in Europa. Il NEG serverless deve essere creato nella stessa area geografica del servizio Cloud Run di cui è stato eseguito il deployment in Europa.
    2. Configura un secondo servizio di backend con un altro NEG serverless negli Stati Uniti. Questo NEG serverless deve essere creato nella stessa area geografica del servizio Cloud Run di cui è stato eseguito il deployment negli Stati Uniti.
    3. Configura la mappa URL con le regole host e percorso appropriate in modo che un insieme di URL indirizzi al servizio di backend europeo mentre tutte le richieste vengono indirizzate al servizio di backend statunitense.
    4. Imposta la configurazione del frontend con il livello di rete Premium.

Il resto della configurazione può essere la stessa descritta in precedenza. La configurazione risultante dovrebbe essere simile a questa:

Routing a livello di area geografica per applicazioni serverless senza failover.
Routing a livello di area geografica per le applicazioni serverless senza failover

Utilizzare una maschera URL

Quando crei un NEG serverless, invece di selezionare un servizio Cloud Run specifico, puoi utilizzare una maschera URL per indirizzare a più servizi nello stesso dominio. Una maschera URL è un modello dello schema URL. Il NEG serverless utilizzerà questo modello per estrarre il nome del servizio dall'URL della richiesta in entrata e mappare la richiesta al servizio appropriato.

Le maschere URL sono particolarmente utili se il servizio è mappato a un dominio personalizzato anziché all'indirizzo predefinito fornito da Google Cloud per il servizio di cui è stato eseguito il deployment. Una maschera URL ti consente di scegliere come target più servizi e versioni con una singola regola anche quando la tua applicazione utilizza un pattern URL personalizzato.

Se non l'hai già fatto, leggi la Panoramica del NEGS serverless: Maschere URL.

Crea una maschera URL

Per creare una maschera URL per il bilanciatore del carico, inizia con l'URL del servizio. Per questo esempio useremo un'app serverless di esempio in esecuzione all'indirizzo https://example.com/login. Questo è l'URL in cui verrà pubblicato il servizio login dell'app.

  1. Rimuovi http o https dall'URL. Ancora example.com/login.
  2. Sostituisci il nome del servizio con un segnaposto per la maschera URL.
    1. Cloud Run: sostituisci il nome del servizio Cloud Run con il segnaposto <service>. Se al servizio Cloud Run è associato un tag, sostituisci il nome del tag con il segnaposto <tag>. In questo esempio, la maschera URL che ti rimane è: example.com/<service>.
    2. Cloud Functions: sostituisci il nome della funzione con il segnaposto <function>. In questo esempio, la maschera URL che ti rimane è: <function>.example.com.
    3. App Engine: sostituisci il nome del servizio con il segnaposto <service>. Se al servizio è associata una versione, sostituiscila con il segnaposto <version>. In questo esempio, la maschera URL che ti rimane è: example.com/<service>.
    4. Gateway API: sostituisci il nome del servizio con il segnaposto <service>. Se al servizio è associata una versione, sostituiscila con il segnaposto <version>. In questo esempio, la maschera URL che ti rimane è: example.com/<service>.

  3. (Facoltativo) Se il nome del servizio (o la funzione, la versione o il tag) può essere estratto dalla parte del percorso dell'URL, il dominio può essere omesso. Il percorso della maschera dell'URL è distinto dal primo carattere /. Se / non è presente nella maschera dell'URL, la maschera è interpretata in modo da rappresentare solo l'host. Di conseguenza, in questo esempio, la maschera URL può essere ridotta a /<service> o /<function>.

    Allo stesso modo, se il nome del servizio può essere estratto dalla parte host dell'URL, puoi omettere del tutto il percorso dalla maschera URL.

    Puoi anche omettere tutti i componenti host o sottodomini inseriti prima del primo segnaposto e i componenti percorso che seguono l'ultimo segnaposto. In questi casi, il segnaposto acquisisce le informazioni richieste per il componente.

Ecco alcuni altri esempi che dimostrano queste regole:

Cloud Run

Questa tabella presuppone che tu abbia un dominio personalizzato denominato example.com e che tutti i tuoi servizi Cloud Run siano mappati a questo dominio.

Servizio, nome tag URL del dominio personalizzato Cloud Run Maschera URL
servizio: accesso https://login-home.example.com/web <servizio>-home.example.com
servizio: accesso https://example.com/login/web example.com/<service> o /<servizio>
servizio: accesso, tag: prova https://test.login.example.com/web <tag>.<servizio>.example.com
servizio: accesso, tag: prova https://example.com/home/login/test example.com/home/<service>/<tag> o /home/<servizio>/<tag>
servizio: accesso, tag: prova https://test.example.com/home/login/web <tag>.example.com/home/<servizio>

Cloud Functions

Questa tabella presuppone che tu abbia un dominio personalizzato denominato example.com e che tutti i tuoi servizi Cloud Functions siano mappati a questo dominio.

Nome funzione URL del dominio personalizzato Cloud Functions Maschera URL
login https://example.com/login /<funzione>
login https://example.com/home/login /home/<funzione>
login https://login.example.com <funzione>.example.com
login https://login.home.example.com <funzione>.home.example.com

App Engine

Questa tabella presuppone che tu abbia un dominio personalizzato denominato example.com e che tutti i servizi App Engine siano mappati a questo dominio.

Nome del servizio, versione URL del dominio personalizzato App Engine Maschera URL
servizio: accesso https://login.example.com/web <servizio>.example.com
servizio: accesso https://example.com/home/login/web example.com/home/<servizio> o /home/<servizio>
servizio: accesso, versione: prova https://test.example.com/login/web <versione>.example.com/<servizio>
servizio: accesso, versione: prova https://example.com/login/test example.com/<service>/<versione>

API Gateway

Questa tabella presuppone che tu abbia un dominio personalizzato denominato example.com e che tutti i servizi API Gateway siano mappati a questo dominio.

Nome del servizio, versione URL del dominio personalizzato API Gateway(Preview) Maschera URL
servizio: accesso https://login.example.com/web <servizio>.example.com
servizio: accesso https://example.com/home/login/web example.com/home/<servizio> o /home/<servizio>
servizio: accesso, versione: prova https://test.example.com/login/web <versione>.example.com/<servizio>
servizio: accesso, versione: prova https://example.com/login/test example.com/<service>/<versione>

Creare un NEG serverless con una maschera URL

console

Per un nuovo bilanciatore del carico, puoi utilizzare la stessa procedura end-to-end descritta in precedenza in questo argomento. Quando configuri il servizio di backend, invece di selezionare un servizio specifico, inserisci una maschera URL.

Se hai un bilanciatore del carico esistente, puoi modificare la configurazione del backend e fare in modo che il punto di NEG serverless sia associato a una maschera URL anziché a un servizio specifico.

Per aggiungere un NEG serverless basato su maschera URL a un servizio di backend esistente:

  1. Vai alla pagina Bilanciamento del carico in Google Cloud Console.
    Vai alla pagina Bilanciamento del carico
  2. Fai clic sul nome del bilanciatore del carico di cui modificare il servizio di backend.
  3. Nella pagina Dettagli bilanciatore del carico, fai clic su Modifica. .
  4. Nella pagina Modifica bilanciatore del carico HTTP(S), fai clic su Configurazione backend.
  5. Nella pagina Configurazione backend, fai clic su Modifica in corrispondenza del servizio di backend che vuoi modificare.
  6. Fai clic su Aggiungi backend.
  7. Seleziona Crea gruppo di endpoint di rete serverless.
    1. In Nome, inserisci helloworld-serverless-neg.
    2. In Area geografica, seleziona us-central1.
    3. In Tipo di gruppo di endpoint di rete serverless, seleziona la piattaforma in cui sono state create le tue app (o i servizi o le funzioni serverless).
      1. Seleziona Use URL Mask (Utilizza maschera URL).
      2. Inserisci una maschera URL. Per istruzioni su come creare una maschera URL, consulta Creazione di una maschera URL.
      3. Fai clic su Crea.
  8. Nella finestra Nuovo backend, fai clic su Fine.
  9. Fai clic su Aggiorna.

gcloud: Cloud Run

Per creare un NEG serverless con una maschera URL di esempio di example.com/<service>:

gcloud compute network-endpoint-groups create helloworld-neg-mask \
  --region=us-central1 \
  --network-endpoint-type=serverless \
  --cloud-run-url-mask="example.com/<service>"

gcloud: Cloud Functions

Per creare un NEG serverless con una maschera URL di esempio di example.com/<service>:

gcloud compute network-endpoint-groups create helloworld-neg-mask \
 --region=us-central1 \
 --network-endpoint-type=serverless \
 --cloud-function-url-mask="example.com/<service>"

gcloud: App Engine

Per creare un NEG serverless con una maschera URL di esempio di example.com/<service>:

gcloud compute network-endpoint-groups create helloworld-neg-mask \
    --region=us-central1 \
    --network-endpoint-type=serverless \
    --app-engine-url-mask="example.com/<service>"

gcloud: gateway API

Per creare un NEG serverless con una maschera URL di esempio di example.com/<service>:

gcloud beta compute network-endpoint-groups create helloworld-neg-mask \
  --region=us-central1 \
  --network-endpoint-type=serverless \
  --serverless-deployment-platform=apigateway.googleapis.com \
  --serverless-deployment-resource=my-gateway \
  --serverless-deployment-url-mask="example.com/<service>"

Per scoprire come il bilanciatore del carico gestisce i problemi relativi alle mancate corrispondenze delle maschere degli URL, consulta Risoluzione dei problemi con i NEG serverless.

Sposta il tuo dominio personalizzato per la gestione da parte del bilanciatore del carico HTTP(S) esterno

Se le app di serverless computing vengono mappate a domini personalizzati, potresti voler aggiornare i record DNS in modo che il traffico inviato agli URL di dominio personalizzati Cloud Run, Cloud Functions, API Gateway o App Engine venga indirizzato attraverso il bilanciatore del carico.

Ad esempio, se hai un dominio personalizzato denominato example.com e tutti i servizi Cloud Run sono mappati a questo dominio, devi aggiornare il record DNS in modo che example.com faccia riferimento all'indirizzo IP del bilanciatore del carico.

Prima di aggiornare i record DNS, puoi testare la configurazione localmente forzando la risoluzione DNS locale del dominio personalizzato all'indirizzo IP del bilanciatore del carico. Per eseguire il test in locale, modifica il file /etc/hosts/ sulla tua macchina locale in modo che punti example.com all'indirizzo IP del bilanciatore del carico oppure usa il flag curl --resolve per forzare curl a utilizzare l'indirizzo IP del bilanciatore del carico per la richiesta.

Quando il record DNS per example.com si risolve nell'indirizzo IP del bilanciatore del carico HTTP(S), le richieste inviate a example.com iniziano a essere indirizzate tramite il bilanciatore del carico. Il bilanciatore del carico li invia al servizio di backend pertinente in base alla sua mappa URL. Inoltre, se il servizio di backend è configurato con una maschera URL, il NEG serverless utilizza la maschera per instradare la richiesta al servizio Cloud Run, Cloud Functions, API Gateway o App Engine appropriato.

Abilita Cloud CDN

Se abiliti Cloud CDN per il tuo servizio Cloud Run, puoi ottimizzare la distribuzione dei contenuti memorizzando nella cache i contenuti vicini agli utenti.

Puoi abilitare Cloud CDN nei servizi di backend utilizzati dai bilanciatori del carico HTTP(S) esterni globali utilizzando il comando gcloud compute backend-services update.

gcloud compute backend-services update helloworld-backend-service \
    --enable-cdn \
    --global

Cloud CDN è supportato per i servizi di backend con Cloud Run, Cloud Functions, Gateway API e backend di App Engine.

Abilita IAP nel bilanciatore del carico HTTP(S) esterno

Puoi configurare IAP in modo che venga attivato o disattivato (impostazione predefinita). Se attivata, devi fornire valori per oauth2-client-id e oauth2-client-secret.

Per abilitare IAP, aggiorna il servizio di backend in modo che includa il flag --iap=enabled con oauth2-client-id e oauth2-client-secret.

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --iap=enabled,oauth2-client-id=ID,oauth2-client-secret=SECRET \
    --global

Abilita Google Cloud Armor

Google Cloud Armor è un prodotto per la sicurezza che fornisce protezione dagli attacchi DDoS (Distributed Denial of Service) a tutti i bilanciatori del carico del proxy GCLB. Google Cloud Armor fornisce inoltre criteri di sicurezza configurabili ai servizi a cui si accede tramite un bilanciatore del carico HTTP(S) esterno. Per informazioni sui criteri di sicurezza di Google Cloud Armor per il bilanciamento del carico HTTP(S), vedi Panoramica dei criteri di sicurezza di Google Cloud Armor.

Se utilizzi Cloud Functions, puoi assicurarti che le richieste inviate agli URL predefiniti vengano bloccate utilizzando l'impostazione internal-and-gclbin entrata .

Se utilizzi Cloud Run, puoi assicurarti che le richieste inviate agli URL predefiniti o qualsiasi altro dominio personalizzato configurato tramite Cloud Run vengano bloccate limitando il traffico in entrata al livello di bilanciamento del carico interno e cloud.

Se usi App Engine, puoi ricorrere ai controlli in entrata, in modo che la tua app riceva solo le richieste inviate dal bilanciatore del carico (e il VPC, se lo utilizzi).

Senza le impostazioni di traffico in entrata adeguate, gli utenti possono utilizzare l'URL predefinito dell'applicazione serverless per ignorare il bilanciatore del carico, criteri di sicurezza Google Cloud Armor, certificati SSL e chiavi private trasmesse attraverso il bilanciatore del carico.

Abilita logging e monitoraggio

Puoi abilitare, disabilitare e visualizzare i log per un servizio di backend con bilanciamento del carico HTTP(S). Quando utilizzi Google Cloud Console, il logging è abilitato per impostazione predefinita per i servizi di backend con backend NEG serverless. Puoi utilizzare gcloud per disabilitare il logging per ogni servizio di backend in base alle tue esigenze. Per le istruzioni, consulta la sezione Logging.

Il bilanciamento del carico HTTP(S) esporta anche i dati di monitoraggio in Cloud Monitoring. Le metriche di monitoraggio possono essere utilizzate per valutare la configurazione, l'utilizzo e le prestazioni di un bilanciatore del carico. Le metriche possono essere utilizzate anche per risolvere i problemi e migliorare l'utilizzo delle risorse e l'esperienza utente. Per le istruzioni, consulta la sezione Monitoraggio.

Elimina un NEG serverless

Non è possibile eliminare un gruppo di endpoint di rete se è collegato a un servizio di backend. Prima di eliminare un NEG, assicurati che sia scollegato dal servizio di backend.

console

  1. Per assicurarti che il NEG serverless che vuoi eliminare non sia attualmente utilizzato da alcun servizio di backend, vai alla scheda Servizi di backend nel menu avanzato del bilanciamento del carico.
    Vai alla scheda Servizi di backend
  2. Se il NEG serverless è attualmente in uso:
    1. Fai clic sul nome del servizio di backend utilizzando il NEG serverless.
    2. Fai clic su Modifica .
    3. Nell'elenco Backend, fai clic su per rimuovere il backend NEG serverless dal servizio di backend.
    4. Fai clic su Salva.
  3. Vai alla pagina Gruppo di endpoint di rete in Google Cloud Console.
    Vai alla pagina Gruppo di endpoint di rete
  4. Seleziona la casella di controllo per il NEG serverless da eliminare.
  5. Fai clic su Elimina.
  6. Fai di nuovo clic su Elimina per confermare.

gcloud

Per rimuovere un NEG serverless da un servizio di backend, devi specificare l'area geografica in cui è stato creato il NEG. Devi anche specificare il flag --global perché helloworld-backend-service è una risorsa globale.

gcloud compute backend-services remove-backend helloworld-backend-service \
    --network-endpoint-group=helloworld-serverless-neg \
    --network-endpoint-group-region=us-central1 \
    --global

Per eliminare il NEG serverless:

gcloud compute network-endpoint-groups delete helloworld-serverless-neg \
    --region=us-central1

Passaggi successivi