Modalità di instradamento delle richieste

ID regione

Il REGION_ID è un codice abbreviato che Google assegna in base alla regione selezionata durante la creazione dell'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 febbraio 2020, REGION_ID.r è incluso negli URL 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 corretta di un servizio. Le richieste possono essere indirizzate nei seguenti modi:

Se testi la tua app utilizzando il server di sviluppo locale, le funzionalità di routing e distribuzione disponibili sono leggermente diverse. Per creare programmaticamente URL che funzionino sia con i server di produzione che con quelli di sviluppo, utilizza il metodo ModulesService.getVersionHostname.

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

Routing con 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 Google Cloud progetto che contiene l'app.

Questo URL invia richieste al servizio predefinito della tua app nella versione che hai configurato 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 un proprio URL, quindi puoi eseguire il deployment e testare una nuova versione prima di configurarla per ricevere 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 dei servizi e delle versioni della tua app, puoi utilizzare uno dei seguenti strumenti:

Console

Nella console Google Cloud , puoi visualizzare le pagine corrispondenti Istanze, Servizi e Versioni.

gcloud

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

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 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 di destinazione. Se il servizio di destinazione non esiste, la richiesta viene instradata in modo soft.

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

Soft routing

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 indirizzata al servizio default. Il soft routing non si applica ai domini personalizzati; le richieste a questi domini restituiranno un codice di stato HTTP 404 se il nome host non è valido.

Routing mirato

I seguenti pattern URL raggiungono sicuramente la destinazione, se esistenti. Queste richieste non vengono mai intercettate e reindirizzate dai pattern che hai definito nelfile dispatche:

  • Invia la richiesta a un'istanza disponibile di un servizio e 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 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 nel seguente modo:

    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 regole di routing personalizzate. Con un file dispatch, puoi inviare richieste in entrata 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:

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

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

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 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 dispatch per indirizzare le richieste mobile come https://simple-sample.uc.r.appspot.com/mobile/ a un frontend mobile e indirizzare le richieste dei lavoratori 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 dispatch senza modificare la versione attualmente in servizio, 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 implementare 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 applicazioni in esecuzione su Google Cloud.

Quando il bilanciamento del carico HTTP(S) è abilitato per le app serverless, puoi:

  • Configura la tua 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 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 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 di ingresso in modo che la tua app riceva solo le richieste inviate dal bilanciamento del carico (e dal VPC, se lo 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 Cloud Armor, i certificati SSL e le chiavi private che vengono passati tramite il bilanciatore del carico.

Routing nel server di sviluppo

Individuare gli indirizzi delle istanze

Il server di sviluppo locale crea tutte le istanze all'avvio. Tieni presente che al momento le istanze di scalabilità di base non sono supportate sul server di sviluppo locale. A ogni istanza creata viene assegnata una porta. Le assegnazioni delle porte vengono visualizzate nel flusso di messaggi di log del server. I client web possono comunicare con una determinata istanza scegliendo la porta di destinazione. Per i servizi con scalabilità automatica viene creata una sola istanza (e porta). Nel log del server ha il seguente aspetto (tieni presente che i servizi erano precedentemente 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. Le richieste a questa porta vengono indirizzate automaticamente a una delle istanze configurate:

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

La seguente tabella mostra come è possibile chiamare questi servizi nel server di sviluppo 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 dispatch

Tutti i file di distribuzione vengono ignorati quando viene eseguito il server di sviluppo locale. L'unico modo per scegliere come target le istanze è tramite le loro 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 relativo vincolo di sicurezza.

Ulteriori dettagli sugli URL di App Engine

Informazioni sull'ID regione negli URL

Il REGION_ID è un codice abbreviato che Google assegna in base alla regione selezionata durante la creazione dell'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 febbraio 2020, REGION_ID.r è incluso negli URL 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 le istanze, i servizi e le 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 dopo il deployment. Questo URL include l'ID regione.

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

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

  2. 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, 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 alla tua app. Pertanto, puoi utilizzare i dati della richiesta per controllare il modo in cui la tua app risponde in base al nome di dominio nella richiesta. Ad esempio, se vuoi reindirizzare a un dominio ufficiale, puoi codificare la tua app per controllare l'intestazione della richiesta Host e quindi rispondere di conseguenza in base al nome di dominio.