ID regione
REGION_ID
è un codice abbreviato che Google assegna
in base alla regione selezionata al momento della creazione dell'app. Il codice non
corrisponde a un paese o a una provincia, anche se alcuni ID regione possono sembrare
simili ai codici paese e provincia di uso comune. Per le app create dopo
febbraio 2020, REGION_ID.r
è incluso
negli 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 in che modo le richieste HTTP degli utenti raggiungono la versione appropriata di un servizio. Le richieste possono essere indirizzate nei seguenti modi:
Se testi l'app utilizzando il server di sviluppo locale, le funzionalità di routing e di invio disponibili sono leggermente diverse. Per creare in modo programmatico URL compatibili con i server di produzione e di sviluppo, utilizza il metodo get_hostname.
Per ulteriori informazioni, consulta la sezione Routing nel server di sviluppo.
Routing con gli URL
Quando 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 hai configurato per ricevere il 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 testare una nuova versione 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 una
versione specifica.
Per recuperare gli ID dei servizi e delle versioni della tua app, puoi utilizzare uno dei seguenti strumenti:
Console
Nella console Google Cloud, puoi visualizzare le pagine Istanze, Servizi e Versioni corrispondenti.
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 metodi list
nell'API Admin.
URL di esempio
Ecco alcuni esempi di URL per App Engine, che mostrano sia il dominio appspot.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 nel 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 che hai scelto come target non esiste, la richiesta viene instradata 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 viene scelto come target, le richieste vengono inviate al servizio
default
.
Routing flessibile
Se una richiesta corrisponde alla porzione PROJECT_ID.REGION_ID.r.appspot.com
del nome host, ma include un nome di servizio, versione o istanza che non esiste, viene instradata al servizio default
. Il routing flessibile non si applica ai domini personalizzati; le richieste loro restituiranno un codice di stato HTTP 404
se il nome host non è valido.
Routing target
È garantito che i seguenti pattern URL raggiungano il loro target, se presenti. Queste richieste non vengono mai intercettate e reindirizzate dai pattern che hai definito nel file dispatch:
- 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 servizi con scalabilità manuale, 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 dispatch 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 arrivo a un servizio specifico in base al percorso o al nome host nell'URL della richiesta.
Creazione di un file dispatch
Per creare un file dispatch:
Crea un file denominato
dispatch.yaml
nella directory radice della directory del progetto o nella directory principale del serviziodefault
.Definisci le regole di routing nel file come descritto. Consulta la documentazione di riferimento di
dispatch.yaml
.
Tieni presente quanto segue in merito alle 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 includano 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 nel tuo file cron.
Ad esempio, puoi creare un file dispatch per instradare le richieste mobile come
https://simple-sample.uc.r.appspot.com/mobile/
a un frontend mobile e le richieste
dei worker 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
Deployment del file dispatch
Per eseguire il deployment del file dispatch, esegui questo comando:
gcloud app deploy dispatch.yaml
Routing con Cloud Load Balancing
Cloud Load Balancing è un prodotto separato che consente configurazioni di rete avanzate per tutte le applicazioni in esecuzione su Google Cloud.
Quando il bilanciamento del carico HTTP(S) è abilitato per le app serverless, puoi:
Configura l'app serverless in modo che venga pubblicata da un indirizzo IP IPv4 e/o IPv6 dedicato non condiviso con altri servizi.
Riutilizza gli stessi certificati SSL e chiavi private che utilizzi per Compute Engine, Google Kubernetes Engine e Cloud Storage. In questo modo non è più necessario gestire certificati separati per le app serverless.
Il bilanciatore del carico non interferisce né interagisce con le regole di routing nel file dispatch.yaml
. Le regole dispatch.yaml
non vengono valutate finché un NEG serverless indirizza il traffico ad App Engine.
Tieni presente quanto segue:
- Ti consigliamo di 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). In caso contrario, gli utenti possono utilizzare l'URL di App Engine dell'app per bypassare il bilanciatore del carico, i criteri di sicurezza di Google Cloud Armor, i certificati SSL e le chiavi private che vengono trasmesse tramite il bilanciatore del carico.
Routing nel server di sviluppo
Rilevamento degli indirizzi delle istanze
Il server di sviluppo locale crea tutte le istanze di scalabilità manuale all'avvio. Le istanze per i servizi di scalabilità automatica e di base sono gestite in modo dinamico. Il server assegna una porta a ciascun servizio e i client possono dipendere dal server per bilanciare il carico e selezionare automaticamente un'istanza. Le assegnazioni delle porte per l'indirizzamento di ciascun servizio vengono visualizzate nel flusso di messaggi di log del server. Di seguito sono riportate le porte per un'app che definisce tre servizi (il tipo di scalabilità di ciascun servizio non è pertinente):
INFO Starting module "default" running at: http://localhost:8084
INFO Starting module "service1" running at: http://localhost:8082
INFO Starting module "service2" running at: http://localhost:8083
Quando utilizzi l'indirizzo di un servizio (ad esempio http://localhost:8082/
), il server seleziona (o crea) un'istanza del servizio e invia la richiesta a questa istanza.
Il server assegna porte univoche a ciascuna istanza di un servizio. Per scoprire queste porte, devi utilizzare il server di amministrazione. Esiste una porta univoca per il server di amministrazione, che viene visualizzata nel log dei messaggi:
INFO Starting admin server at: http://localhost:8000
Questo indirizzo reindirizza alla console del server di amministrazione. Da qui puoi fare clic su Istanze per visualizzare lo stato dinamico delle istanze della tua app:
Verrà visualizzata una voce separata per ogni istanza manuale e di base. I numeri delle istanze sono link con indirizzi di porta univoci per ogni istanza. Puoi passare il mouse sopra un link per visualizzare la porta assegnata all'istanza oppure fare clic sul link per inviare una richiesta direttamente all'istanza.
File di invio
Se la tua app include un filedispatch.yaml
, lo stream dei messaggi di log
includerà una porta del supervisore:
INFO Starting dispatcher running at: http://localhost:8080
Le richieste a questa porta vengono instradate in base alle regole del file di invio. Il server non supporta le regole per i file dispatch.yaml
che includono
i nomi host (ad esempio, url: "customer1.myapp.com/*"
). Le regole con
pattern di percorso relativi (url: "*/fun"
) funzioneranno, pertanto puoi utilizzare
URL come http://localhost/fun/mobile
per raggiungere le istanze. Il server segnalerà un errore nel flusso di log se tenti di avviare un'applicazione con un file dispatch.yaml
che contiene regole basate su host.
Limitazione dell'accesso a un servizio
Per impostazione predefinita, tutti i servizi sono pubblici. Se vuoi limitare l'accesso a un servizio, aggiungi l'elemento login: admin
ai relativi gestori.
Ulteriori dettagli sugli URL di App Engine
Informazioni sull'ID regione negli URL
REGION_ID
è un codice abbreviato che Google assegna
in base alla regione selezionata al momento della creazione dell'app. Il codice non
corrisponde a un paese o a una provincia, anche se alcuni ID regione possono sembrare
simili ai codici paese e provincia di uso comune. Per le app create dopo
febbraio 2020, REGION_ID.r
è incluso
negli URL di App Engine. Per le app esistenti create prima di questa data, l'ID regione è facoltativo nell'URL.
Per vedere l'ID regione della tua app, puoi usare i seguenti strumenti:
Console
Nella console Google Cloud puoi visualizzare gli URL per istanze, servizi e versioni dell'app.
Tutti questi URL includono l'ID regione.
gcloud
Quando esegui il deployment di un'app o di un servizio, il comando gcloud app deploy
mostra l'URL dopo la riuscita 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 dell'app. 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 usato per la richiesta è incluso nei dati della richiesta
passati alla tua app. Di conseguenza, puoi usare i dati della richiesta per controllare il modo in cui
l'app risponde in base al nome di dominio nella richiesta. Ad esempio, se vuoi
reindirizzamento a un dominio ufficiale, puoi programmare la tua app in modo che controlli l'intestazione della richiesta
Host
e poi rispondere di conseguenza in base al nome di dominio.