ti consigliamo
di utilizzare il protocollo HTTPS per inviare richieste alla tua app. Le richieste HTTPS inviate al
REGION_ID .r.appspot.com
devono utilizzare la stringa "-dot-
" per separare i sottodomini
anziché ".
".
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 configurare quella versione per ricevere il traffico.
Gli URL di servizi e versioni specifici sono nel 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:
URL di esempio
Di seguito sono riportati alcuni esempi di URL per App Engine, che mostrano sia il dominio appspot.com
che App Engine assegna 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 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 target. Se il servizio scelto come target non esiste, la richiesta viene instradata temporaneamente .
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 soft
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 inesistente, la richiesta viene instradata al servizio default
. Il routing soft non si applica ai domini personalizzati; le richieste inviate a questi utenti restituiscono un codice di stato HTTP 404
se il nome host non è valido.
Routing target
I seguenti pattern URL sono garantiti per raggiungere il target, se esistono . Queste richieste non vengono mai intercettate e reindirizzate dai pattern definiti nel file di invio:
Nota: nell'ambiente flessibile, il targeting di un'istanza non è supportato. Non è possibile inviare richieste direttamente a un'istanza specifica.
Routing con un file di invio
Puoi creare un file di invio per sostituire le regole di routing basate su URL di App Engine e definire le tue regole di routing personalizzate. Con un file di invio, puoi inviare le richieste in arrivo a un servizio specifico in base al percorso o al nome host nell'URL della richiesta.
Creazione di un file di invio
Per creare un file di spedizione:
Crea un file denominato dispatch.yaml
nella directory principale della directory del progetto o nella directory
principale del servizio default
.
Definisci le regole di routing nel file come descritto nel 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
e service
.
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 definiti nel file cron .
Ad esempio, puoi creare un file di invio per indirizzare le richieste da dispositivi mobili come https://simple-sample.uc.r.appspot.com/mobile/
a un frontend per dispositivi mobili e indirizzare 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 di invio
Per eseguire il deployment del file di invio, 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 la tua app serverless per la pubblicazione 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. Ciò elimina la necessità di gestire certificati separati per le app serverless.
Il bilanciatore del carico non interferisce con le regole di routing nel file dispatch.yaml
né vi interagisce. 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 traffico in entrata
in modo che la tua app riceva solo le richieste inviate dal bilanciatore del carico
(e il VPC se lo utilizzi). In caso contrario, gli utenti possono utilizzare l'URL di App Engine della tua app 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.
Ulteriori dettagli sugli URL di App Engine
Informazioni sull'ID regione negli URL
REGION_ID
è un codice abbreviato assegnato da Google in base all'area geografica selezionata quando crei l'app. Il codice non corrisponde a un paese o a una provincia, anche se alcuni ID area geografica potrebbero sembrare simili ai codici paese e provincia più utilizzati. 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 visualizzare l'ID regione della tua app, puoi utilizzare i seguenti strumenti:
console Nella console Google Cloud, puoi visualizzare gli URL delle istanze , dei servizi e delle versioni della tua 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
visualizza l'URL al termine del deployment. Questo URL include l'ID della regione.
Per visualizzare l'URL per un servizio già sottoposto a 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, inserisci gcloud app versions list --service=default
.
Inserisci il comando gcloud app versions describe
. L'output di tale comando include l'URL della versione con l'ID regione dell'app. Ad esempio, per descrivere la versione 20191023t101741 del servizio predefinito, inserisci gcloud 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 trasmessi alla tua app. Pertanto, puoi utilizzare i dati della richiesta per controllare in che modo l'app risponde in base al nome di dominio nella richiesta. Ad esempio, se vuoi reindirizzare a un dominio ufficiale, puoi programmare la tua app per controllare l'intestazione della richiesta Host
e poi rispondere di conseguenza in base al nome di dominio.