File di configurazione dispatch.yaml

ID regione

L'REGION_ID è un codice abbreviato che Google assegna 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.

Scopri di più sugli ID regione.

Il file dispatch.yaml consente di eseguire l'override delle regole di routing rules. Puoi utilizzare dispatch.yaml per inviare le richieste in entrata a un servizio specifico (in precedenza noto come moduli) in base al percorso o al nome host nell'URL.

Per saperne di più, consulta Come vengono indirizzate le richieste.

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

Eseguire il deployment del file dispatch

Prima di eseguire il deployment del file dispatch, devi assicurarti che tutti i servizi definiti in questo file siano già stati sottoposti a deployment in App Engine. Per eseguire il deployment del dispatch.yaml file, esegui il gcloud app deploy comando dalla directory che contiene il dispatch.yaml:

gcloud app deploy dispatch.yaml

Per saperne di più sui comandi di deployment, consulta Eseguire il deployment di un'app.

Sintassi

L'elemento root nel file dispatch.yaml è dispatch: e contiene un elenco di definizioni di routing specificate dai seguenti sottoelementi.

Le regole definite nel file dispatch 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 di dispatch dipendono dall'ordine e verrà applicata solo la prima regola che corrisponde a un URL.

Elemento Descrizione
service

Specifica il nome del servizio che gestirà le richieste che corrispondono 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 .url

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

I percorsi URL che iniziano con /_ah/ non vengono indirizzati dal file dispatch.

Esempio

Di seguito è riportato un file dispatch di esempio che indirizza le richieste a https://simple-sample.uc.r.appspot.com e richieste come https://simple-sample.uc.r.appspot.com/favicon.ico al servizio default. Tutti i contenuti statici vengono pubblicati dal default servizio. Le richieste da dispositivi mobili come https://simple-sample.uc.r.appspot.com/mobile/ vengono indirizzate a un frontend mobile, mentre le richieste dei worker come https://simple-sample.uc.r.appspot.com/work/ vengono indirizzate a un backend 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 possibili richieste, 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ù restrittive.

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 indirizzano le richieste in entrata da "customer1.myapp.com" al servizio predefinito e le richieste in entrata dai sottodomini a un servizio di backend statico.

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 dell'URL, né il nome host né il percorso possono contenere più di 100 caratteri.

Eliminare tutte le regole di dispatch

Per eliminare tutte le regole di dispatch:

  1. Modifica i contenuti del file dispatch.yaml in modo che siano:

    dispatch: []

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