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
- Esegui il deployment di un servizio App Engine, Cloud Functions o Cloud Run.
- Se non l'hai ancora fatto, installa l'interfaccia a riga di comando di Google Cloud.
- Configura le autorizzazioni.
- 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
- Vai alla pagina Indirizzi IP esterni in Google Cloud Console.
Vai agli indirizzi IP esterni - Fai clic su Prenota indirizzo statico per prenotare un indirizzo IPv4.
- Assegna un Nome a
example-ip
. - Imposta il livello di rete su Premium.
- Imposta la versione IP su IPv4.
- Imposta il Tipo su Globale.
- 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.
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
- In Google Cloud Console, vai alla pagina Bilanciamento del carico.
- In Bilanciamento del carico HTTP(S), fai clic su Avvia configurazione.
- Nella sezione Solo per Internet o interno, seleziona Da Internet alle mie VM.
- In Globale o a livello di area geografica, seleziona Bilanciatore del carico HTTP(S) globale.
- Fai clic su Continua.
- In Nome del bilanciatore del carico, inserisci
serverless-lb
. - Per continuare, tieni aperta la finestra.
Configurazione dei servizi di backend
- Fai clic su Configurazione backend.
- 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.
- Inserisci un nome.
- In Tipo di backend, seleziona Gruppo di endpoint di rete serverless.
- Non modificare il protocollo. Questo parametro viene ignorato.
- In Backend, nella finestra New backend, seleziona Create Serverless network endpoint group (Crea gruppo di endpoint di rete serverless).
- Inserisci un nome.
- In Area geografica, seleziona us-central1. Seleziona Cloud Run.
- Seleziona Seleziona il nome del servizio.
- Dal menu a discesa Servizio, seleziona il servizio Cloud Run per cui vuoi creare un bilanciatore del carico.
- Fai clic su Crea.
- Nella finestra Nuovo backend, fai clic su Fine.
- 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.
- Fai clic su Regole host e percorso.
- 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
- Fai clic su Configurazione frontend.
- Inserisci un nome.
-
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.
- Fai clic su Fine.
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 |
Rivedi la configurazione
- Fai clic su Esamina e finalizza.
- Esamina le regole di backend, host e percorso e frontend.
- Fai clic su Crea.
- Attendi che la creazione del bilanciatore del carico sia completa.
- Fai clic sul nome del bilanciatore del carico (serverless-lb).
- Prendi nota dell'indirizzo IP del bilanciatore del carico, che utilizzerai nella prossima attività. È noto come
IP_ADDRESS
.
gcloud
- 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 riferimentogcloud
pergcloud compute network-endpoint-groups create
. - Crea un servizio di backend.
gcloud compute backend-services create BACKEND_SERVICE_NAME \ --load-balancing-scheme=EXTERNAL_MANAGED \ --global
- 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
- 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.
-
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
-
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
- 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.
- Vai alla pagina Bilanciamento del carico in Google Cloud Console.
Vai al bilanciamento del carico - Fai clic sul bilanciatore del carico che hai appena creato.
- Prendi nota dell'indirizzo IP del bilanciatore del carico.
- Per un bilanciatore del carico HTTP, puoi testare il tuo bilanciatore del carico
utilizzando un browser web visitando
http://IP_ADDRESS
. SostituisciIP_ADDRESS
con l'indirizzo IP del bilanciatore del carico. Dovresti essere reindirizzato alla home page del serviziohelloworld
.
- Per un bilanciatore del carico HTTPS, puoi testare il tuo bilanciatore del carico
utilizzando un browser web visitando
https://IP_ADDRESS
. SostituisciIP_ADDRESS
con l'indirizzo IP del bilanciatore del carico. Dovresti essere reindirizzato alla home page del serviziohelloworld
.
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:
- 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.
- Crea un bilanciatore del carico HTTP(S) esterno con la configurazione seguente:
- Configura un servizio di backend globale con due NEG serverless.
- Crea il primo NEG nella stessa area geografica del servizio Cloud Run di cui è stato eseguito il deployment in Europa.
- Crea il secondo NEG nella stessa area geografica del servizio Cloud Run di cui hai eseguito il deployment negli Stati Uniti.
- Imposta la configurazione del frontend con il livello di rete Premium.
- Configura un servizio di backend globale con due NEG serverless.
Il resto della configurazione può essere la stessa descritta in precedenza. La configurazione risultante dovrebbe essere simile a questa:
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:
- Crea un ID client OAuth per l'app.
- Esegui nuovamente il deployment dei servizi Cloud Run in tutte le aree geografiche in modo che utilizzino il nuovo ID client OAuth.
- 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:
- 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.
- Crea un bilanciatore del carico HTTP(S) esterno con la configurazione seguente:
- 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.
- 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.
- 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.
- 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:
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.
- Rimuovi
http
ohttps
dall'URL. Ancoraexample.com/login
. - Sostituisci il nome del servizio con un segnaposto per la maschera URL.
- 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>
. - Cloud Functions: sostituisci il nome della funzione con il segnaposto
<function>
. In questo esempio, la maschera URL che ti rimane è:<function>.example.com
. - 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>
. - 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>
.
- Cloud Run: sostituisci il nome del servizio Cloud Run con il segnaposto
(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:
- Vai alla pagina Bilanciamento del carico in Google Cloud Console.
Vai alla pagina Bilanciamento del carico - Fai clic sul nome del bilanciatore del carico di cui modificare il servizio di backend.
- Nella pagina Dettagli bilanciatore del carico, fai clic su Modifica. .
- Nella pagina Modifica bilanciatore del carico HTTP(S), fai clic su Configurazione backend.
- Nella pagina Configurazione backend, fai clic su Modifica in corrispondenza del servizio di backend che vuoi modificare.
- Fai clic su Aggiungi backend.
- Seleziona Crea gruppo di endpoint di rete serverless.
- In Nome, inserisci
helloworld-serverless-neg
. - In Area geografica, seleziona us-central1.
- 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).
- Seleziona Use URL Mask (Utilizza maschera URL).
- Inserisci una maschera URL. Per istruzioni su come creare una maschera URL, consulta Creazione di una maschera URL.
- Fai clic su Crea.
- In Nome, inserisci
- Nella finestra Nuovo backend, fai clic su Fine.
- 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-gclb
in 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
- 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 - Se il NEG serverless è attualmente in uso:
- Fai clic sul nome del servizio di backend utilizzando il NEG serverless.
- Fai clic su Modifica .
- Nell'elenco Backend, fai clic su per rimuovere il backend NEG serverless dal servizio di backend.
- Fai clic su Salva.
- Vai alla pagina Gruppo di endpoint di rete in Google Cloud Console.
Vai alla pagina Gruppo di endpoint di rete - Seleziona la casella di controllo per il NEG serverless da eliminare.
- Fai clic su Elimina.
- 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
- Utilizzo di logging e monitoraggio
- Risoluzione dei problemi relativi ai NEG serverless
- Pulizia della configurazione del bilanciatore del carico
- Utilizzo di un modulo Terraform per un bilanciatore del carico HTTPS esterno con un backend Cloud Run