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.

Questa pagina descrive in che modo le richieste HTTP degli utenti raggiungono la versione appropriata di un servizio. Le richieste possono essere indirizzate nei seguenti modi:

Se testi l'app utilizzando lo sviluppo locale server, le caratteristiche di routing e di spedizione disponibili sono leggermente diverse. A creare in modo programmatico URL compatibili con le versioni di produzione e di sviluppo utilizza get_hostname .

Consulta la sezione Routing nel server di sviluppo per saperne di più.

Routing con gli URL

Quando l'app è in esecuzione in App Engine, puoi usare l'URL seguente per invia 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.

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 di versioni e servizi 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 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 nei 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 nei 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 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 applicano ai domini personalizzati; delle richieste restituiranno uno 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

  • 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 servizio : 

    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 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 radice della directory del progetto o nella directory del tuo servizio default.

  2. Per definire le regole di routing nel file come descritto, consulta le dispatch.yaml riferimento.

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 includano "." per separare i sottodomini. URL definita con il protocollo HTTPS "-dot-" non sono supportate.
  • Le regole si applicano anche agli URL che definisci nei file cron.

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 dispatch, esegui questo comando:

    gcloud app deploy dispatch.yaml

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

Routing nel server di sviluppo

Rilevamento degli indirizzi delle istanze

Il server di sviluppo locale crea tutte le istanze di scalabilità manuale all'avvio. Le istanze per i servizi di scalabilità automatica e di base sono gestite in modo dinamico. La server assegna una porta a ciascun servizio e i client possono dipendere dal server del carico e selezionare automaticamente un'istanza. Le assegnazioni delle porte per relative a ciascun servizio, vengono visualizzate nel messaggio di log del server flusso di dati. Di seguito sono riportate le porte per un'app che definisce tre servizi (la scalabilità tipo di servizio non è pertinente):

INFO Starting module "default" running at: http://localhost:8084
INFO Starting module "service1" running at: http://localhost:8082
INFO Starting module "service2" running at: http://localhost:8083

Quando utilizzi l'indirizzo di un servizio (ad esempio http://localhost:8082/), il server selezionerà (o creerà) un'istanza del servizio e invierà a quella istanza.

Il server assegna porte univoche a ciascuna istanza di un servizio. Per scoprire a queste porte devi usare il server di amministrazione. C'è una porta univoca il server di amministrazione, riportato nel log dei messaggi:

INFO Starting admin server at: http://localhost:8000

Questo indirizzo reindirizza alla console del server di amministrazione. Da qui puoi fare clic Istanze per visualizzare lo stato dinamico delle istanze della tua app:

Screenshot della console di amministrazione dev_appserver

Verrà visualizzata una voce separata per ogni istanza manuale e di base. L'istanza I numeri sono collegamenti con indirizzi di porta univoci per ciascuna istanza. Puoi passare il mouse sopra su un link per vedere la porta assegnata all'istanza oppure fai clic sul link per inviare una richiesta direttamente a quell'istanza.

File di invio

Se la tua app include un file dispatch.yaml, lo stream dei messaggi di log verrà includi una porta per il supervisore:

INFO Starting dispatcher running at: http://localhost:8080

Le richieste a questa porta vengono instradate in base alle regole della spedizione . Il server non supporta dispatch.yaml regole dei file che includono nomi host (ad esempio, url: "customer1.myapp.com/*"). Regole con pattern di percorso relativi (url: "*/fun") sono validi, quindi puoi usare URL come http://localhost/fun/mobile per raggiungere le istanze. Il server segnala un errore nel flusso di log se provi ad avviare un'applicazione con un dispatch.yaml che contiene regole basate su host.

Limitazione dell'accesso a un servizio

Per impostazione predefinita, tutti i servizi sono pubblici. Se vuoi limitare l'accesso a un servizio, aggiungi il login: admin elemento al rispettivo gestori.

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 vedere l'ID regione della tua app, puoi usare i seguenti strumenti:

Console

Nella console Google Cloud puoi visualizzare gli URL per istanze, Servizi, e Versions.

Tutti questi URL includono l'ID regione.

gcloud

Quando esegui il deployment di un'app o di un servizio, il comando gcloud app deploy e mostra l'URL dopo il completamento 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. 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 delle richieste per controllare il modo in cui l'app risponde in base al nome di dominio nella richiesta. Ad esempio, se vuoi reindirizza 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.