Questa pagina è stata tradotta dall'API Cloud Translation.

Modalità di routing delle richieste

ID regione

REGION_ID è un codice abbreviato assegnato da Google in base all'area geografica selezionata al momento della creazione dell'app. Il codice non corrisponde a un paese o a una provincia, anche se alcuni ID di area geografica potrebbero essere simili ai codici di 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 area geografica è facoltativo nell'URL.

Scopri di più sugli ID dell'area geografica.

In questa pagina viene descritto in che modo le richieste HTTP degli utenti raggiungono la versione appropriata di un servizio. Le richieste possono essere instradate nei seguenti modi:

Routing con URL
Routing con un file di invio
Routing con Cloud Load Balancing

Queste opzioni si applicano solo alle app di cui è stato eseguito il deployment. Quando esegui il test in locale, il comportamento di routing dipende dal runtime e dall'ambiente di sviluppo specifici utilizzati.

Routing con URL

Quando la tua 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 le 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 un proprio URL, in modo da poter eseguire il deployment e testare una nuova versione prima di configurarla per ricevere il traffico.

Gli URL per servizi e versioni 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 delle versioni e dei servizi dell'app, puoi utilizzare uno dei seguenti strumenti:

Console

In Cloud Console, puoi visualizzare le pagine relative a istanze, servizi e versioni.

gcloud

Esegui il comando gcloud app instances list per elencare gli ID risorsa all'interno di uno specifico progetto Cloud.

API

Per recuperare gli ID risorsa in modo programmatico, consulta i metodi list nell'API Admin.

URL di esempio

Di seguito sono riportati 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 una richiesta a un'istanza 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 scelto come 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 di 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 soft

Se una richiesta corrisponde alla parte PROJECT_ID.REGION_ID.r.appspot.com del nome host, ma include un servizio, una versione o un nome di istanza inesistente, la richiesta viene instradata al servizio default. Il routing soft non si applica ai domini personalizzati; le richieste che li restituiscono 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 in base ai pattern definiti 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 i servizi a scalabilità manuale, puoi scegliere come target 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 in 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
```
Nota: il targeting di un'istanza non è supportato nei servizi configurati per la scalabilità automatica o la scalabilità di base. L'ID istanza deve essere un numero intero nell'intervallo compreso tra 0 e il numero totale di istanze in esecuzione. Indipendentemente dal tipo di scalabilità o dalla classe di istanza, non è possibile inviare una richiesta a un'istanza specifica senza scegliere come target una versione o un servizio al suo interno.

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 regole di routing personalizzate. Con un file di invio, è possibile inviare 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 invio:

Crea un file denominato dispatch.yaml nella stessa directory utilizzata per gli altri file di configurazione, ad esempio app.yaml.
Definisci le regole di routing nel file come descritto e fai riferimento al riferimento di dispatch.yaml.

Tieni presenti le seguenti informazioni 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 includano la notazione"."per separare i sottodomini. Gli URL definiti con la notazione HTTPS"-dot-"non sono supportati.
Le regole vengono applicate anche agli URL definiti nel file cron.

Ad esempio, puoi creare un file di invio per instradare le richieste per dispositivi mobili come https://simple-sample.uc.r.appspot.com/mobile/ a un frontend per dispositivi mobili e instradare 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 di configurazione di dispatch senza alterare la versione di pubblicazione attuale, utilizza uno dei seguenti comandi nella directory che contiene il file di dispatch, a seconda del tuo ambiente:

gcloud

gcloud app deploy dispatch.yaml

Maven

mvn appengine:deployDispatch dispatch.yaml

Gradle

gradle appengineDeployDispatch dispatch.yaml

IDE

Se utilizzi IntelliJ o Eclipse, puoi selezionare i singoli file di configurazione di cui eseguire il deployment utilizzando il modulo di deployment.

Routing con Cloud Load Balancing

Cloud Load Balancing è un prodotto separato che consente configurazioni di rete avanzate per tutte le tue 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 sia 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 o interagisce con le regole di routing nel 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 in entrata in modo che la tua applicazione 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 aggirare 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

Per visualizzare l'ID area geografica della tua app, puoi utilizzare i seguenti strumenti:

Console

In Cloud Console puoi visualizzare gli URL delle istanze, servizi e versioni delle tue app.

Tutti questi URL includono l'ID regione.

gcloud

Quando esegui il deployment di un'applicazione o un servizio, il comando gcloud app deploy visualizza l'URL al termine del deployment. Questo URL include l'ID area geografica.

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, inserisci gcloud 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 dell'area geografica dell'app. Ad esempio, per descrivere la versione 20191023t101741 per il 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 passati alla tua app. Pertanto, puoi utilizzare i dati della richiesta per controllare la modalità di risposta dell'app in base al nome di dominio nella richiesta. Ad esempio, se vuoi reindirizzare a un dominio ufficiale, puoi programmare la tua app in modo che controlli l'intestazione della richiesta Host, quindi risponda di conseguenza in base al nome del dominio.