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

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questa pagina mostra come creare un bilanciatore del carico HTTP(S) esterno per indirizzare le richieste ai backend serverless. In questo caso il termine serverless si riferisce ai seguenti prodotti di serverless computing:

  • App Engine
  • Cloud Functions
  • Cloud Run

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

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

Per scoprire di più sui NEG serverless, leggi la panoramica dei NEG serverless.

Se sei un utente esistente del bilanciatore del carico HTTP(S) esterno globale (classico), assicurati di leggere Pianifica la migrazione al bilanciatore del carico HTTP(S) esterno globale quando pianifichi un nuovo deployment con il bilanciatore del carico HTTP(S) esterno globale.

Prima di iniziare

  1. Esegui il deployment di un servizio App Engine, Cloud Functions o Cloud Run.
  2. Se non lo hai già fatto, installa Google Cloud CLI.
  3. Configura le autorizzazioni.
  4. Aggiungi una risorsa del certificato SSL.

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

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

Per l'esempio su questa pagina, abbiamo utilizzato la guida rapida di Cloud Run Python per eseguire il deployment di un servizio Cloud Run nella regione 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 ancora 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 devi utilizzare la stessa regione in un secondo momento 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, consulta Quickstart: Build and Deploy.

Se hai già caricato un container di esempio in Container Registry, consulta la 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 Google Cloud CLI

Installa Google Cloud CLI. Consulta la panoramica gcloud per informazioni concettuali e di installazione sullo strumento.

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

Configura le autorizzazioni

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

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

Prenotare un indirizzo IP esterno

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

Console

  1. Vai alla pagina Indirizzi IP esterni in Google Cloud Console.
    Vai a 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 del certificato SSL al front-end del bilanciatore del carico. Crea una risorsa del certificato SSL utilizzando un certificato SSL gestito da Google o un certificato SSL autogestito.

  • Certificati gestiti da Google. Consigliamo di utilizzare i certificati gestiti da Google perché Google Cloud ottiene, gestisce e rinnova automaticamente tali certificati. Per creare un certificato gestito da Google, devi avere un dominio e i record DNS per quel dominio affinché venga eseguito il provisioning del certificato. Se non hai ancora un dominio, puoi riceverne uno da Google Domains. Per ulteriori informazioni, consulta la guida introduttiva a 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 la sezione 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 del certificato SSL.

Se vuoi testare questo processo senza creare una risorsa del certificato SSL (o un dominio come richiesto dai certificati gestiti da Google), puoi comunque utilizzare le istruzioni 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 Cloud Run Python per eseguire il deployment di un servizio Cloud Run.

Architettura esterna di bilanciamento del carico HTTPS per un'applicazione Cloud Run.
Architettura di 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 a Bilanciamento del carico

  2. In Bilanciamento del carico HTTP(S), fai clic su Avvia configurazione.
  3. In Per Internet o solo 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 Name (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 Nuovo backend, seleziona Crea gruppo di endpoint di rete serverless.
  7. Inserisci un nome.
  8. In Area geografica, seleziona us-central1. Seleziona quindi 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 Create (Crea).
  12. Nella finestra Nuovo backend, fai clic su Fine.
  13. Fai clic su Create (Crea).

Configurazione di regole host e matcher percorso

Le regole host e i matcher 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 inviate 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 avere 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 avere una risorsa certificato SSL da utilizzare nel proxy HTTPS. Puoi creare una risorsa del 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). Si consiglia di utilizzare i certificati gestiti da Google perché Google Cloud ottiene, gestisce e rinnova automaticamente questi certificati. Se non hai un dominio, puoi utilizzare un certificato SSL autofirmato per i test.
    (Facoltativo) Abilita il reindirizzamento da HTTP a HTTPS Utilizza questa casella di controllo per attivare i reindirizzamenti dalla porta 80 alla porta 443.

    L'abilitazione 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 del 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 le seguenti opzioni siano configurate con questi 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 Backend, Host e percorso e Frontend.
  3. Fai clic su Create (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à. È denominato 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 altre opzioni, consulta la gcloud guida di riferimento 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 matcher 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 del certificato SSL utilizzando un certificato SSL gestito da Google o un certificato SSL autogestito. È consigliabile utilizzare certificati gestiti da Google perché Google Cloud ottiene, gestisce e rinnova automaticamente questi 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 del certificato SSL gestita da Google: 
       gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
       --domains DOMAIN
    Per creare una risorsa del 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 carichi anche il tuo 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 arrivo 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

Collegare il dominio al bilanciatore del carico

Dopo aver creato il bilanciatore del carico, annota l'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 servizio di registrazione del dominio. Se hai aggiunto più domini al certificato SSL, devi aggiungere un record A per ciascuno, il tutto puntando 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, visita la pagina della guida 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 il traffico anche al nome di 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 a Bilanciamento del carico
  2. Fai clic sul bilanciatore del carico appena creato.
  3. Prendi nota dell'indirizzo IP del bilanciatore del carico.
  4. Per un bilanciatore del carico HTTP, puoi testarlo utilizzando un browser web tramite http://IP_ADDRESS. Sostituisci IP_ADDRESS con l'indirizzo IP del bilanciatore del carico. Dovrebbe aprirsi la home page del servizio helloworld.
  5. Per un bilanciatore del carico HTTPS, puoi testare il tuo bilanciatore del carico utilizzando un browser web visitando la pagina https://IP_ADDRESS. Sostituisci IP_ADDRESS con l'indirizzo IP del bilanciatore del carico. Dovrebbe aprirsi la 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 scoprire di più, consulta lo stato delle risorse del certificato SSL gestito da Google.
    Se hai utilizzato un certificato autofirmato per il test, nel browser viene visualizzato un avviso. Devi indicare esplicitamente al browser di accettare un certificato autofirmato. Fai clic sull'avviso per visualizzare la pagina effettiva.

Opzioni di configurazione aggiuntive

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

Configura il bilanciamento del carico su più aree geografiche

Nell'esempio sopra riportato viene utilizzato un solo servizio Cloud Run come 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 trasmette il traffico all'endpoint dell'app helloworld specificato. Tuttavia, potresti voler pubblicare la tua app Cloud Run da più di una regione per migliorare la disponibilità del servizio e migliorare la latenza per gli utenti.

Se un servizio di backend contiene più NEG, il bilanciatore del carico bilancia il traffico inoltrando le richieste al NEG serverless nella regione disponibile più vicina. Tuttavia, i servizi di backend possono contenere un solo NEG serverless per area geografica. Per rendere disponibile il servizio Cloud Run in più aree geografiche, devi configurare il routing tra aree geografiche diverse. Dovresti poter utilizzare un unico schema URL che funzioni in qualsiasi parte del mondo, ma soddisfi le richieste degli utenti nell'area geografica più vicina all'utente.

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

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

  1. Configura due servizi Cloud Run in diverse regioni. Supponiamo che tu abbia 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 regione del servizio Cloud Run di cui è stato eseguito il deployment in Europa.
      2. Crea il secondo NEG nella stessa regione del servizio Cloud Run di cui è stato 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 avere l'aspetto seguente:

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

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

Per impostazione predefinita, un servizio Pub/Sub recapita i messaggi solo agli endpoint di push nella stessa regione di Google Cloud in cui il servizio Pub/Sub archivia i messaggi. Per le richieste di push autenticate, il bilanciatore del carico HTTP(S) esterno prevede un campo di pubblico specifico per l'area geografica nel 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 del pubblico JWT non viene autenticato e la richiesta push non riesce.

Per aggirare 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 regioni in modo che ricevano 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.

Configura il routing a livello di regione

Un motivo comune per la distribuzione di 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 in Europa. Per farlo, devi avere uno schema dell'URL con URL distinti per gli utenti dell'UE e del resto del mondo e indirizzare gli utenti dell'UE agli URL dell'UE.

In uno scenario di questo tipo, devi utilizzare la mappa URL per instradare le richieste da URL specifici alle regioni corrispondenti. Con questa configurazione, le richieste destinate a un'area geografica non vengono mai recapitate a un'altra area geografica. Questo fornisce l'isolamento tra aree geografiche. Se invece un'area geografica smette di funzionare, 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 regione, devi utilizzare il livello di rete Premium in modo da poter combinare diverse regioni in un'unica regola di forwarding.

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

  1. Configura due servizi Cloud Run in diverse regioni. Supponiamo che tu abbia eseguito il deployment di due servizi Cloud Run: hello-world-eu in una regione 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. Configurare un servizio di backend con un NEG serverless in Europa. Il NEG serverless deve essere creato nella stessa regione 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 regione 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 portano al servizio di backend USA.
    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 avere l'aspetto seguente:

Routing a livello di regione per applicazioni serverless senza failover.
Routing a livello di regione per applicazioni serverless senza failover

Usa una maschera URL

Quando crei un NEG serverless, invece di selezionare un servizio Cloud Run specifico, puoi utilizzare una maschera URL per puntare a più servizi in esecuzione sullo stesso dominio. Una maschera URL è un modello dello schema dell'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 dell'URL sono particolarmente utili se il servizio è associato 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 dei NEG serverless: Maschere URL.

Crea una maschera URL

Per creare una maschera URL per il bilanciatore del carico, inizia con l'URL del tuo servizio. Per questo esempio, utilizzeremo 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 dell'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 rimane è example.com/<service>.
    2. Cloud Functions: sostituisci il nome della funzione con il segnaposto <function>. In questo esempio, la maschera URL che rimane è example.com/<function>.
    3. App Engine: sostituisci il nome del servizio con il segnaposto <service>. Se al servizio è associata una versione, sostituisci la versione con il segnaposto <version>. In questo esempio, la maschera URL che rimane è example.com/<service>.
    4. Gateway API: sostituisci il nome del gateway con il segnaposto <gateway>. In questo esempio, la maschera URL che rimane è example.com/<gateway>.

  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. La parte del percorso della maschera dell'URL si distingue per il primo carattere /. Se / non è presente nella maschera URL, la maschera viene considerata solo per rappresentare l'host. Pertanto, per questo esempio, la maschera URL può essere ridotta a /<service>, /<gateway> o /<function>.

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

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

Ecco alcuni altri esempi che mostrano 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 associati a questo dominio.

Servizio, nome tag URL di 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 /<service>
servizio: accesso, tag: test https://test.login.example.com/web <tag>.<servizio>.example.com
servizio: accesso, tag: test https://example.com/home/login/test example.com/home/<service>/<tag> o /home/<service>/<tag>
servizio: accesso, tag: test 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 servizi Cloud Functions siano mappati a questo dominio.

Nome funzione URL del dominio personalizzato di Cloud Functions Maschera URL
accedi https://example.com/login /<funzione>
accedi https://example.com/home/login /home/<funzione>
accedi https://login.example.com <funzione>.example.com
accedi 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 tuoi servizi App Engine siano associati a questo dominio.

Nome del servizio, versione URL 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/<service> o /home/<service>
servizio: accesso, versione: test https://test.example.com/login/web <versione>.example.com/<servizio>
servizio: accesso, versione: test 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 vengano associati a questo dominio.

Nome gateway URL di dominio personalizzato del gateway API(anteprima) Maschera URL
accedi https://example.com/login /<gateway>
accedi https://example.com/home/login /home/<gateway>
accedi https://login.example.com <gateway>.example.com
accedi https://login.home.example.com <gateway>.home.example.com

Crea un NEG serverless con una maschera URL

Console

Per un nuovo bilanciatore del carico, puoi utilizzare lo stesso processo end-to-end descritto 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 accesso NEG serverless sia a una maschera URL invece che a un servizio specifico.

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

  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 vuoi modificare il servizio di backend.
  3. Nella pagina Dettagli del 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 per il servizio di backend da 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 app (o i servizi o le funzioni serverless).
      1. Seleziona Use URL Mask (Usa maschera URL).
      2. Inserisci una maschera URL. Per istruzioni su come creare una maschera URL, consulta la pagina Creazione di una maschera URL.
      3. Fai clic su Create (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/<gateway>:

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/<gateway>"

Per scoprire come il bilanciatore del carico gestisce i problemi con le corrispondenze errate delle maschere degli URL, consulta la pagina Risoluzione dei problemi con i NEG serverless.

Sposta il tuo dominio personalizzato per essere gestito dal bilanciatore del carico HTTP(S) esterno

Se le tue app di computing serverless vengono mappate a domini personalizzati, ti consigliamo di aggiornare i record DNS in modo che il traffico inviato agli URL di dominio personalizzati Cloud Run, Cloud Functions, API Gateway o App Engine personalizzati venga instradato tramite 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 per example.com in modo che punti all'indirizzo IP del bilanciatore del carico.

Prima di aggiornare i record DNS, puoi testare la tua configurazione localmente forzando la risoluzione DNS locale del dominio personalizzato sull'indirizzo IP del bilanciatore del carico. Per eseguire il test in locale, modifica il file /etc/hosts/ sulla macchina locale in modo che reindirizzi 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 instradate 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, API Gateway e backend di App Engine.

Abilita IAP sul bilanciatore del carico HTTP(S) esterno

Puoi configurare IAP in modo che sia abilitato o disabilitato (predefinito). Se l'opzione è abilitata, devi fornire i valori per oauth2-client-id e oauth2-client-secret.

Per abilitare IAP, aggiorna il servizio di backend in modo da includere 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 Distributed Denial of Service (DDoS) a tutti i bilanciatori del carico del proxy GCLB. Google Cloud Armor fornisce anche criteri di sicurezza configurabili ai servizi a cui si accede tramite un bilanciatore del carico HTTP(S) esterno. Per saperne di più sui criteri di sicurezza di Google Cloud Armor per il bilanciamento del carico HTTP(S), consulta la 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 Ingress internal-and-gclb.

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 bilanciamento del carico interno e nel cloud.

Se utilizzi App Engine, puoi utilizzare i controlli in entrata in modo che la tua app riceva solo le richieste inviate dal bilanciatore del carico e dal VPC se lo utilizzi.

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

(Facoltativo) Configura un criterio di sicurezza di backend predefinito. Il criterio di sicurezza predefinito limita il traffico oltre una soglia configurata dall'utente. Per ulteriori informazioni sui criteri di sicurezza predefiniti, consulta la Panoramica sulla limitazione di frequenza.

  1. Per disattivare il criterio di sicurezza predefinito di Google Cloud Armor, seleziona None nel menu dell'elenco dei criteri di sicurezza del backend.
  2. Nella sezione Sicurezza, seleziona Criterio di sicurezza predefinito.
  3. Nel campo Nome criterio, accetta il nome generato automaticamente o inserisci un nome per il tuo criterio di sicurezza.
  4. Nel campo Conteggio richieste, accetta il conteggio delle richieste predefinito o inserisci un numero intero compreso tra 1 e 10,000.
  5. Nel campo Intervallo, seleziona un intervallo.
  6. Nel campo Enforce on key (Applica alla chiave), scegli uno dei seguenti valori: All (Tutti), IP address (Indirizzo IP) o X-Forwarded-For IP address. Per ulteriori informazioni su queste opzioni, consulta Identificazione dei client per la limitazione di frequenza.

Abilita logging e monitoraggio

Puoi abilitare, disabilitare e visualizzare i log per un servizio di bilanciamento del carico HTTP(S) Quando si utilizza Google Cloud Console, il logging è abilitato per impostazione predefinita nei servizi di backend con backend serverless NEG. 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 Monitoraggio.

Elimina un NEG serverless

Impossibile 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 dei 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 relativa al NEG serverless che vuoi 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 specificare anche 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