File di configurazione dispatch.yaml

ID regione

REGION_ID è un codice abbreviato assegnato da Google in base all'area geografica selezionata al momento della creazione dell'app. Il codice non corrisponde a un paese o a una provincia, anche se alcuni ID regione possono sembrare simili ai codici paese e provincia 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.

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

Per saperne di più, vedi Come vengono instradate le richieste.

Un'app può avere un solo file dispatch.yaml e le regole di routing in quel file si applicano a tutti i servizi e a tutte le versioni dell'app.

Deployment del file dispatch

Per eseguire il deployment e applicare le impostazioni di configurazione dal file dispatch'ambiente App Engine:

gcloud app deploy dispatch.yaml

Sintassi

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

Le regole che definisci nel file dispatch devono utilizzare pattern URL HTTP che includano la notazione "." per separare i sottodomini. Gli URL definiti con la notazione HTTPS "-dot-" non sono supportati.

Le regole di invio 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 in precedenza erano denominati moduli.

url

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

Per l'elemento service, devi specificare il nome del servizio che deve gestire le richieste in entrata corrispondenti al pattern URL dell'elemento url.

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 instradati dal file dispatch.

Esempio

Di seguito è riportato un esempio di file dispatch che instrada le richieste a https://simple-sample.uc.r.appspot.com e quelle come https://simple-sample.uc.r.appspot.com/favicon.ico al servizio default. Tutti i contenuti statici vengono pubblicati dal servizio default. Le richieste mobile come https://simple-sample.uc.r.appspot.com/mobile/ vengono instradate a un frontend mobile, mentre le richieste dei worker come https://simple-sample.uc.r.appspot.com/work/ vengono instradate 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 soddisfano 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 del dominio in entrata a un servizio. Le seguenti regole instradano 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 URL, né il nome host né il percorso possono superare i 100 caratteri.

Eliminazione di tutte le regole di invio

Per eliminare tutte le regole di invio:

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

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