Modalità di routing delle richieste

ID regione

REGION_ID è un codice abbreviato assegnato da Google in base alla regione selezionata quando crei l'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 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

Go Java Node.js PHP Python Ruby .NET Personalizzato

Questa pagina descrive in che modo 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

Queste opzioni si applicano solo alle app di cui è stato eseguito il deployment. Quando esegui test locali, il comportamento di routing dipende dal particolare ambiente di runtime e di sviluppo che utilizzi.

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 nella versione che hai configurato per ricevere il traffico.

Nota: 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é ".". Puoi utilizzare la semplice notazione URL "." con i tuoi domini personalizzati e con le 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 prima di configurarla per ricevere 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 query istanze, Servizi, e Versioni pagine.

gcloud

Esegui l' gcloud app instances list per elencare gli ID risorsa di uno specifico progetto Google Cloud.

API

Per recuperare in modo programmatico gli ID risorsa, consulta i list metodi nella l'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 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 in servizio target. Se il servizio scelto come target non esiste, il parametro viene instradata in modalità temporanea.

• 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 non flessibile

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 che non esiste, la richiesta viene indirizzata 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 target

È garantito che i seguenti pattern URL raggiungano il loro target, se presenti. 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 specifico e Versione:

  
  https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
  https://VERSION_ID.SERVICE_ID.PROJECT_ID.CUSTOM_DOMAIN

Nota: nell'ambiente flessibile, il targeting di un'istanza non è supportato. Non è possibile inviare richieste direttamente a un'istanza specifica.

Instradamento con un file di invio

Puoi creare un file dispatch per eseguire l'override di App Engine regole di routing e definisci regole personalizzate. Con un file di invio, puoi inviare le richieste in entrata a un servizio specifico in base al percorso o al nome dell'host nell'URL della richiesta.

Creazione di un file di invio

Per creare un file dispatch:

1. Crea un file denominato dispatch.yaml nella radice del progetto o nella directory root del tuo servizio default.

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 gli elementi url e service.
• Le regole devono utilizzare pattern URL HTTP che includono la notazione "." per separare i sottodomini. URL definita con il protocollo HTTPS "-dot-" non sono supportate.
• Le regole si applicano anche agli URL definiti nel file cron.yaml.

Ad esempio, puoi creare un file dispatch per instradare richieste mobile come https://simple-sample.uc.r.appspot.com/mobile/ a un frontend mobile e indirizza il worker richieste 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 invio utilizzando gcloud, esegui il seguente 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 tue applicazioni in esecuzione su Google Cloud.

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

• Configura l'app serverless per la pubblicazione da un 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. 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 nel tuo 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 app riceva solo le richieste inviate dal bilanciatore del carico. (e il VPC, se lo usi). 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.

Metriche incoerenti quando l'ambiente flessibile di App Engine utilizza Cloud Load Balancing

La dashboard dell'ambiente flessibile di App Engine mostra tutte le metriche solo per le richieste instradate attraverso un backend gestito da un ambiente flessibile. Se utilizzi l'ambiente flessibile di App Engine con alcune metriche in App Engine tabella delle metriche sono riportate come metriche da loadbalancing . Per ulteriori informazioni, consulta Logging e monitoraggio del bilanciamento del carico HTTP(S).

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

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 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. 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 per reindirizzare a un dominio ufficiale, puoi programmare la tua app in modo che controlli Host richiesta e quindi rispondere di conseguenza in base al nome di dominio.