File di configurazione dispatch.yaml

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.

dispatch.yaml ti consente di ignorare il routing Google Cloud. Puoi utilizzare dispatch.yaml per inviare richieste in arrivo a un servizio specifico (precedentemente noti come moduli) in base al percorso o al nome host dell'URL.

Per saperne di più, consulta Modalità di routing delle richieste.

Un'app può avere un solo file dispatch.yaml e le regole di routing nel file si applicano a tutti i servizi e alle versioni dell'app. Le regole di routing si applicano anche agli URL utilizzati in un file cron.

Deployment del file dispatch

Prima di eseguire il deployment del file dispatch, devi assicurarti che tutti i servizi definiti in questo file ne è già stato eseguito il deployment in App Engine. Per eseguire il deployment il file dispatch.yaml, esegui il comando gcloud app deploy dal che contiene dispatch.yaml:

gcloud app deploy dispatch.yaml

Per ulteriori informazioni sui comandi di deployment, consulta Deployment di un'app.

Sintassi

L'elemento principale del file dispatch.yaml è dispatch: e contiene un elenco di definizioni di routing specificate dai seguenti elementi secondari.

Le regole definite nel file dispatch devono utilizzare pattern URL HTTP che includono "." per separare i sottodomini. URL definita con il protocollo HTTPS "-dot-" non sono supportate.

Le regole di invio dipendono dall'ordine e solo la prima regola che corrisponde a un URL .

Elemento Descrizione
service

Specifica il nome del servizio che gestirà le richieste corrisponde al pattern url. Tieni presente che i servizi erano precedentemente chiamati moduli.

url

Nell'elemento url, definisci il patterntra virgolette, che può includere il nome host e il percorso dell'URL che non superano i 100 caratteri.

Per l'elemento service, specifica il nome del servizio che vuoi che gestisca le richieste in entrata che corrispondono al pattern URL dell'elemento service.

Suggerimento: puoi includere pattern glob come il carattere jolly * nell'elemento url. Tuttavia, questi pattern possono essere utilizzati solo prima del nome host e alla fine del percorso dell'URL.

I percorsi degli URL che iniziano con /_ah/ non vengono indirizzati dal file di invio.

Esempio

Di seguito è riportato un esempio di file dispatch che instrada le richieste a https://simple-sample.uc.r.appspot.com e richieste simili https://simple-sample.uc.r.appspot.com/favicon.ico al servizio default. Tutti vengono forniti contenuti statici dal servizio default. Richieste da dispositivo mobile come https://simple-sample.uc.r.appspot.com/mobile/ vengono indirizzati a un frontend mobile e richieste worker come https://simple-sample.uc.r.appspot.com/work/ vengono indirizzate a un e statico.

Esempio:

dispatch:
  # Default service serves the typical web resources and all static resources.
  - url: "*/favicon.ico"
    service: default

  # Default service serves simple hostname request.
  - url: "simple-sample.uc.r.appspot.com/"
    service: default

  # 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

Se preferisci regole di routing generali che corrispondono a molte richieste possibili, puoi definire regole con ambiti più ampi.

Esempio:

# Send any path that begins with “simple-sample.uc.r.appspot.com/mobile” to the mobile-frontend service.
- url: "simple-sample.uc.r.appspot.com/mobile*"
  service: mobile-frontend

# Send any domain/sub-domain with a path that starts with “work” to the static backend service.
- url: "*/work*"
  service: static-backend

Puoi anche scrivere espressioni più rigide.

Esempio:

# Matches the path "/fun", but not "/fun2" or "/fun/other"
- url: "*/fun"
  service: mobile-frontend

# Matches the hostname 'customer1.myapp.com', but not '1.customer1.myapp.com.
- url: "customer1.myapp.com/*"
  service: static-backend

Puoi creare regole per reindirizzare le richieste di dominio in entrata a un servizio. Le seguenti regole instradano le richieste in arrivo da "customer1.myapp.com" alle richieste in entrata e servizio predefinito dai sottodomini a un backend statico completamente gestito di Google Cloud.

Esempio:

# Matches the domain name 'customer1.myapp.com' and directs all the request to default service 
- url: "customer1.myapp.com/*"
  service: default

# Matches all the subdomains of 'customer1.myapp.com' and directs all the request to static-backend service
- url: "*.customer1.myapp.com/*"
  service: static-backend

Limiti

Il file dispatch può contenere fino a 20 regole di routing. Quando specifichi la stringa URL, né il nome host né il percorso possono essere più lunghi di 100 caratteri.

Eliminazione di tutte le regole di invio

Per eliminare tutte le regole di invio:

  1. Modifica i contenuti del file dispatch.yaml per:

    dispatch: []

  2. Esegui il deployment del file dispatch.yaml in App Engine.