Modalità di instradamento delle richieste

ID regione

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.

Scopri di più sugli ID regione.

Ok

Questa pagina descrive come le richieste HTTP degli utenti raggiungono la versione appropriata di un servizio. Le richieste possono essere inoltrate nei seguenti modi:

• Routing con URL

• Routing con un file di invio

• Routing con Cloud Load Balancing

Se testi l'app utilizzando il server di sviluppo locale, le funzionalità di routing e invio disponibili sono leggermente diverse. Per creare in modo programmatico URL che funzionino sia con i server di produzione sia con quelli di sviluppo, utilizza il metodo ModulesService.getVersionHostname.

Per scoprire di più, consulta la sezione Routing nel server di sviluppo.

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.

Nota: recommend utilizzando il protocollo HTTPS per inviare richieste alla tua app. Richieste HTTPS inviate a il REGION_ID.r.appspot.com deve utilizzare la stringa "-dot-" in sottodomini separati anziché ".". Puoi utilizzare il semplice "." notazione URL con la tua notazione con domini personalizzati e con richieste HTTP.

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 il traffico.

Gli URL per 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 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 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

Di seguito sono riportati alcuni esempi di URL per App Engine, che mostrano sia la classe appspot.com dominio assegnato da App Engine alla tua app e 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 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 in servizio target. 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 nel

  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 PROJECT_ID.REGION_ID.r.appspot.com porzione di il nome host, ma include un nome di servizio, versione o istanza che non esiste, la richiesta viene instradata al servizio default. Il routing flessibile non si applica ai domini personalizzati; le richieste inviate a questi domini restituiranno un codice di stato HTTP 404 se il nome host non è valido.

Routing mirato

I seguenti pattern URL raggiungono sicuramente il target, se esistenti. Queste richieste non vengono mai intercettate vengono reindirizzati in base ai 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 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

  Nota: il targeting di un'istanza non è supportato nei servizi configurati per la scalabilità automatica o di base. L'ID istanza deve essere un numero intero compreso tra 0 e il numero totale di istanze in esecuzione. Indipendentemente il tipo di scalabilità o la classe dell'istanza, non è possibile inviare una richiesta un'istanza specifica senza scegliere come target un servizio o una versione al suo interno in esecuzione.

Routing con un file dispatch

Puoi creare un file dispatch per eseguire l'override di App Engine regole di routing e definisci regole 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 dispatch

Per creare un file dispatch:

1. Crea un file denominato dispatch.yaml nella stessa directory utilizzata per gli altri file di configurazione, app.yaml.

2. Definisci le regole di routing nel file come descritto nella documentazione di riferimento dispatch.yaml.

Tieni presente quanto segue in merito alle regole di routing:

• Puoi definire fino a 20 regole di routing. Ogni regola deve contenere il parametro 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 che definisci nei file cron.

Ad esempio, puoi creare un file di invio per inoltrare le richieste mobile comehttps://simple-sample.uc.r.appspot.com/mobile/ a un frontend mobile e le richieste dei lavoratori comehttps://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 configurazione di invio senza modificare in altro modo il valore che attualmente gestisce la versione, utilizza uno dei seguenti comandi nella directory contenente il file 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, seleziona i singoli file di configurazione da eseguire il deployment utilizzando il modulo di deployment.

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 le app 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 la necessità di 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 fino a quando il NEG serverless 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 URL di App Engine per bypassare il bilanciatore del carico, Google Cloud Armor criteri di sicurezza, certificati SSL e chiavi private che vengono trasmessi tramite il bilanciatore del carico.

Routing nel server di sviluppo

Rilevamento degli indirizzi delle istanze

Il server di sviluppo locale crea tutte le istanze all'avvio. Tieni presente che al momento le istanze con scaling di base non sono supportate sul server di sviluppo locale. A ogni istanza creata viene assegnata una porta. Le assegnazioni delle porte vengono visualizzate nello stream dei messaggi di log del server. I client web possono comunicare con una determinata istanza prendendo di mira la relativa porta. Viene creata una sola istanza (e porta) per i servizi con scalabilità automatica. Nel log del server ha il seguente aspetto (tieni presente che in precedenza i servizi erano chiamati moduli):

INFO: Module instance service-auto is running at http://localhost:37251/

A ogni istanza di un servizio con scalabilità manuale viene assegnata una porta univoca:

INFO: Module instance service-manual instance 0 is running at http://localhost:43190/
INFO: Module instance service-manual instance 1 is running at http://localhost:52642/

Inoltre, a ogni servizio con scalabilità manuale viene assegnata una porta aggiuntiva in modo che i client possano accedere al servizio senza specificare un'istanza specifica. Richieste a questa porta vengono instradati automaticamente a una delle istanze configurate:

INFO: Module instance service-manual is running at http://localhost:12361/

La tabella seguente mostra come è possibile chiamare questi servizi nella fase di sviluppo server e nell'ambiente App Engine:

Servizio	Istanza	Indirizzo del server di sviluppo	Indirizzo App Engine
service-auto	(non utilizzato)	http://localhost:37251/	https://v1-dot-service-auto-dot-PROJECT_ID.REGION_ID.r.appspot.com/
service-manual	0	http://localhost:43190/	https://0-dot-v1-dot-service-manual-dot-PROJECT_ID.REGION_ID.r.appspot.com/

viene utilizzato dal server di sviluppo locale. Per maggiori dettagli, vedi Apache Maven o Gradle.

File di invio

Tutti i file di invio vengono ignorati durante l'esecuzione del server di sviluppo locale. L'unico modo per scegliere come target le istanze è tramite le relative porte.

Limitare l'accesso a un servizio

Per impostazione predefinita, tutti i servizi sono pubblici. Se vuoi limitare l'accesso a un servizio, aggiungi l'elemento <role-name>admin</role-name> al suo vincolo di sicurezza

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 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 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 regione.

Per visualizzare l'URL di un servizio di cui è già stato eseguito il deployment:

1. Inserisci il valore 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.

2. Inserisci il valore 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, 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 che vengono trasmessi all'app. Pertanto, puoi utilizzare i dati della richiesta per controllare la risposta dell'app in base al nome di dominio nella richiesta. Ad esempio, se vuoi eseguire un reindirizzamento a un dominio ufficiale, puoi programmare la tua app in modo che controlli l'intestazione della richiesta Host e poi risponda di conseguenza in base al nome di dominio.