File di configurazione dispatch.yaml

ID regione

REGION_ID è un codice abbreviato che viene assegnato da Google in base alla regione selezionata al momento della creazione dell'app. Il codice non corrisponde a un paese o a una provincia, anche se alcuni ID regione possono essere simili ai codici paese e di provincia di uso comune. Per le app create dopo febbraio 2020, il campo 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 ignorare le regole di routing. Puoi utilizzare dispatch.yaml per inviare richieste in entrata a un servizio specifico (noto in precedenza come moduli) in base al percorso o al nome host nell'URL.

Per saperne di più, vedi Modalità di routing delle 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. Le regole di routing si applicano anche agli URL utilizzati in un cron file o in una configurazione della coda di attività.

Deployment del file dispatch

Il file dispatch.yaml può trovarsi ovunque nella directory del codice sorgente.

Per eseguire il deployment del file di configurazione di invio, senza modificare la versione attualmente in uso, utilizza uno dei seguenti comandi nella directory contenente il file dispatch, a seconda dell'ambiente:

gcloud

gcloud app deploy dispatch.yaml

Maven

mvn appengine:deployDispatch dispatch.yaml

Gradle

gradle appengineDeployDispatch dispatch.yaml

IDE

Se utilizzi IntelliJ o Eclipse, seleziona i singoli file di configurazione di cui eseguire il deployment utilizzando il modulo di deployment.

Per ulteriori informazioni sui comandi di deployment, consulta la pagina relativa al deployment di un'app Java 8.

Syntax

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

Le regole che definisci 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 invio dipendono dall'ordine e viene 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 in precedenza i servizi erano chiamati moduli.

url

Nell'elemento url, definisci il pattern URL, che può includere il nome host e il percorso dell'URL che non devono superare i 100 caratteri. Per l'elemento service, specifichi il nome del servizio di cui vuoi 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.

Un pattern URL che può includere il nome host e il percorso dell'URL. I caratteri globi possono essere utilizzati per la corrispondenza con i pattern. I caratteri Glob possono essere specificati solo all'inizio e alla fine del pattern. Specifica il pattern URL tra virgolette.

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

Esempio

Di seguito è riportato un file dispatch di esempio che instrada 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 servizio default. Le richieste mobile come https://simple-sample.uc.r.appspot.com/mobile/ vengono indirizzate a un frontend mobile, mentre le richieste worker come https://simple-sample.uc.r.appspot.com/work/ vengono indirizzate a un backend statico.

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. Ad 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ù rigorose:

# 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

Limiti

Il file dispatch può contenere fino a 20 regole di routing. Quando specifichi la stringa URL, il nome host o il percorso non possono contenere più 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 in:

    dispatch: []

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