Modalità di routing delle richieste

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

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

Tieni presente che se utilizzi i servizi in bundle precedenti per testare la tua 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 la funzione Metodo get_hostname. Per scoprire di più, consulta la sezione sul 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 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.

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 una versione specifica.

Per recuperare gli ID dei servizi e delle versioni della tua app, puoi utilizzare uno dei seguenti strumenti:

URL di esempio

Di seguito sono riportati alcuni esempi di URL per App Engine, che mostrano sia il appspot.com dominio 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 serviziodefault.

• 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 scelto come target 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 flessibile

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 istanza che non esiste, la richiesta viene indirizzata al servizio default. Il routing graduale 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.

Percorso mirato

I seguenti pattern URL raggiungono sicuramente il target, se esistenti. Queste richieste non vengono mai intercettate e reindirizzate dagli schemi 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 servizi con scalabilità manuale, puoi scegliere come target e inviare una richiesta a un'istanza includendone l'ID. 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

Instradamento 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 le tue regole di routing personalizzate. Con un file dispatch, 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 dispatch

Per creare un file dispatch:

1. Crea un file denominato dispatch.yaml nella directory principale del progetto o nella directory principale del servizio default.

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

Tieni presente quanto segue 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 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.yaml.

Ad esempio, puoi creare un file dispatch per inoltrare le richieste mobile comehttps://simple-sample.uc.r.appspot.com/mobile/ a un frontend mobile e le richieste di 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

Eseguire il deployment del file dispatch

Per eseguire il deployment del file dispatch 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 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, non è necessario gestire certificati separati per le app serverless.

Il bilanciatore del carico non interferisce o 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 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 l'URL App Engine della tua app per bypassare il bilanciatore del carico, i criteri di sicurezza di Google Cloud Armor, i certificati SSL e le chiavi private trasmessi tramite il bilanciatore del carico.

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

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.