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 |
Nell'elemento
Per l'elemento
Suggerimento: puoi includere pattern glob come il carattere jolly
I percorsi degli URL che iniziano con |
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:
Modifica i contenuti del file
dispatch.yaml
in:dispatch: []
Esegui il deployment del file
dispatch.yaml
in App Engine.