ID regione
REGION_ID
è un codice abbreviato assegnato da Google in base alla regione selezionata quando crei l'app. Il codice non corrisponde a un paese o a una provincia, anche se alcuni ID regione possono sembrare simili ai codici di paesi e province di uso comune. Per le app create dopo il giorno
Febbraio 2020, REGION_ID.r
è incluso in
URL di App Engine. Per le app esistenti create prima di questa data,
l'ID regione è facoltativo nell'URL.
Scopri di più sugli ID regione.
Questa pagina descrive come le richieste HTTP degli utenti raggiungono la versione appropriata di un servizio. Le richieste possono essere indirizzate nei seguenti modi:
Queste opzioni si applicano solo alle app di cui è stato eseguito il deployment. Quando esegui test locali, il comportamento di routing dipende dal particolare ambiente di runtime e di sviluppo che utilizzi.
Routing con gli URL
Una volta che l'app è in esecuzione in App Engine, puoi utilizzare il seguente URL per inviare richieste HTTP all'app:
https://PROJECT_ID.REGION_ID.r.appspot.com
dove
PROJECT_ID
è l'ID del progetto Google Cloud
che contiene l'app.
Questo URL invia richieste al servizio predefinito della tua app alla versione che configurate per ricevere traffico.
URL per servizi e versioni
Se crei più di un servizio nella tua app, ogni servizio ha il proprio URL. Ogni versione di un servizio ha anche il proprio URL, quindi puoi eseguire il deployment e prima di configurarla per ricevere traffico.
Gli URL di versioni e servizi specifici hanno il seguente formato:
VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
Puoi omettere VERSION-dot-
se non devi scegliere come target un
una specifica versione.
Per recuperare gli ID dei servizi e delle versioni della tua app, puoi usare uno qualsiasi dei seguenti strumenti:
Console
Nella console Google Cloud puoi visualizzare le query istanze, Servizi, e Versioni pagine.
gcloud
Esegui il comando
gcloud app instances list
per elencare gli ID risorsa all'interno di un progetto Google Cloud specifico.
API
Per recuperare in modo programmatico gli ID risorsa, consulta i list
metodi nella
l'API Admin.
URL di esempio
Di seguito sono riportati alcuni esempi di URL per App Engine, che mostrano sia il dominioappspot.com
assegnato da App Engine alla tua app sia un dominio personalizzato che puoi configurare per la tua app.
- Invia la richiesta a un'istanza disponibile del servizio
default
: https://PROJECT_ID.REGION_ID.r.appspot.com
https://CUSTOM_DOMAIN
Le richieste vengono ricevute da qualsiasi versione configurata per il traffico in Servizio
default
.- Invia la richiesta a un'istanza disponibile del servizio
- Invia una richiesta a un'istanza disponibile di un servizio specifico:
https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
https://SERVICE_ID.CUSTOM_DOMAIN
Le richieste vengono ricevute da qualsiasi versione configurata per il traffico nel servizio di destinazione. Se il servizio di destinazione non esiste, la richiesta viene indirizzata in modo flessibile.
- Invia una richiesta a un'istanza disponibile di una versione specifica nella
- Servizio
default
: https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com
https://VERSION_ID.CUSTOM_DOMAIN
Quando un servizio non è scelto come target, le richieste vengono inviate al servizio
default
.
Routing non flessibile
Se una richiesta corrisponde alla parte PROJECT_ID.REGION_ID.r.appspot.com
del nome host, ma include un nome di servizio, versione o istanza che non esiste, la richiesta viene indirizzata al servizio default
. Il routing flessibile
non si applicano ai domini personalizzati; per le tue richieste restituiranno uno stato HTTP 404
se il nome host non è valido.
Routing target
I seguenti pattern URL raggiungono sicuramente il target, se esistenti. Queste richieste non vengono mai intercettate e reindirizzate dagli schemi che hai definito nel file di invio:
- Invia la richiesta a un'istanza disponibile di un servizio e di una versione specifici:
https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
https://VERSION_ID.SERVICE_ID.PROJECT_ID.CUSTOM_DOMAIN
Se utilizzi la scalabilità manuale servizi, puoi indirizzare e inviare una richiesta a un'istanza includendo l'ID istanza. L'ID istanza è un numero intero compreso tra
0
e il numero totale di istanze in esecuzione e può essere specificato come segue:Invia una richiesta a un servizio e a una versione specifici all'interno di un'istanza specifica:
https://INSTANCE_ID-dot-VERSION_ID-dot-SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com https://INSTANCE_ID.VERSION_ID.SERVICE_ID.CUSTOM_DOMAIN
Routing con un file dispatch
Puoi creare un file di invio per eseguire l'override delle regole di routing basate su URL di App Engine e definire le tue regole di routing personalizzate. Con un file dispatch, puoi inviare richieste in entrata a un servizio specifico in base al percorso o all'host nome nell'URL della richiesta.
Creazione di un file di invio
Per creare un file dispatch:
Crea un file denominato
dispatch.yaml
nella radice della directory del progetto o nella directory del tuo serviziodefault
.Definisci le regole di routing nel file come descritto nella documentazione di riferimento
dispatch.yaml
.
Tieni presente quanto segue sulle regole di routing:
- Puoi definire fino a 20 regole di routing. Ogni regola deve contenere gli elementi
url
eservice
. - Le regole devono utilizzare pattern URL HTTP che includono la notazione "
.
" per separare i sottodomini. Gli URL definiti con la notazione HTTPS "-dot-
" non sono supportati. - Le regole si applicano anche agli URL che definisci nei file cron.
Ad esempio, puoi creare un file dispatch per instradare richieste mobile come
https://simple-sample.uc.r.appspot.com/mobile/
a un frontend mobile e indirizza il worker
richieste come https://simple-sample.uc.r.appspot.com/work/
a un backend statico:
dispatch:
# Send all mobile traffic to the mobile frontend.
- url: "*/mobile/*"
service: mobile-frontend
# Send all work to the one static backend.
- url: "*/work/*"
service: static-backend
Eseguire il deployment del file di invio
Per eseguire il deployment del file di invio, esegui il seguente comando:
gcloud app deploy dispatch.yaml
Routing con Cloud Load Balancing
Cloud Load Balancing è un prodotto separato che consente funzionalità configurazioni per tutte le applicazioni in esecuzione su Google Cloud.
Quando il bilanciamento del carico HTTP(S) è abilitato per serverless, puoi:
Configura l'app serverless in modo che venga pubblicata da un indirizzo IP IPv4 e/o IPv6 dedicato che non è condiviso con altri servizi.
Riutilizza gli stessi certificati SSL e le stesse chiavi private che utilizzi per Compute Engine, Google Kubernetes Engine e Cloud Storage. In questo modo, non è necessario gestire certificati separati per le app serverless.
Il bilanciatore del carico non interferisce né interagisce con le regole di routing in
il tuo file dispatch.yaml
. Le regole dispatch.yaml
non vengono valutate finché un NEG serverless non indirizza il traffico ad App Engine.
Tieni presente quanto segue:
- Ti consigliamo di utilizzare i controlli di immissione in modo che la tua app riceva solo le richieste inviate dal bilanciatore del carico (e dalla VPC, se la utilizzi). In caso contrario, gli utenti possono utilizzare l'URL App Engine della tua app per bypassare il bilanciatore del carico, i criteri di sicurezza di Google Cloud Armor, i certificati SSL e le chiavi private trasmessi tramite il bilanciatore del carico.
Ulteriori dettagli sugli URL di App Engine
Informazioni sull'ID regione negli URL
REGION_ID
è un codice abbreviato assegnato da Google
in base alla regione selezionata al momento della creazione dell'app. Il codice non
corrispondono a un paese o a una provincia, anche se potrebbero essere visualizzati alcuni ID regione
in modo simile ai codici paese e provincia di uso comune. Per le app create dopo il giorno
Febbraio 2020, REGION_ID.r
è incluso in
URL di App Engine. Per le app esistenti create prima di questa data,
l'ID regione è facoltativo nell'URL.
Per visualizzare l'ID regione della tua app, puoi utilizzare i seguenti strumenti:
Console
Nella console Google Cloud puoi visualizzare gli URL per istanze, Servizi, e Versions.
Tutti questi URL includono l'ID regione.
gcloud
Quando esegui il deployment di un'app o di un servizio, il comando gcloud app deploy
visualizza l'URL al termine del deployment. Questo URL include
l'ID regione.
Per visualizzare l'URL di un servizio di cui è già stato eseguito il deployment:
Inserisci il comando
gcloud app versions list
per elencare le versioni di un servizio specifico. Ad esempio, per elencare le versioni del servizio predefinito, inseriscigcloud app versions list --service=default
.Inserisci il comando
gcloud app versions describe
. L'output di questo comando include l'URL della versione con l'ID regione. Ad esempio, per descrivere la versione 20191023t101741 per il servizio predefinito, inseriscigcloud app versions describe 20191023t101741 --service=default
Il nome di dominio è incluso nei dati della richiesta
Il nome di dominio utilizzato per la richiesta è incluso nei dati della richiesta,
passati alla tua app. Pertanto, puoi utilizzare i dati delle richieste per controllare il modo in cui
l'app risponde in base al nome di dominio nella richiesta. Ad esempio, se vuoi
per reindirizzare a un dominio ufficiale, puoi programmare la tua app in modo che controlli Host
richiesta e quindi rispondere di conseguenza in base al nome di dominio.