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 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
ti consente di eseguire l'override delle regole di routing.
Puoi utilizzare dispatch.yaml
per inviare richieste in entrata a un servizio specifico
(in precedenza noto come moduli) in base al percorso o al nome host nell'URL.
Per ulteriori informazioni, consulta la sezione Come vengono instradate le richieste.
Un'app può avere un solo file dispatch.yaml
e le regole di routing al suo interno si applicano a tutti i servizi e le versioni dell'app.
Eseguire il deployment del file dispatch
Per eseguire il deployment e applicare le impostazioni di configurazione del file dispatch'ambiente App Engine:
gcloud app deploy dispatch.yaml
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 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 corrispondenti al pattern |
url |
Nell'elemento
Per l'elemento
Suggerimento: puoi includere pattern glob come il carattere jolly
I percorsi URL che iniziano con |
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 instradate a un frontend mobile e
le richieste dei lavoratori 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 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 in entrata del dominio 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 essere più lunghi di 100 caratteri.
Eliminazione di tutte le regole di invio
Per eliminare tutte le regole di invio:
Modifica i contenuti del file
dispatch.yaml
in modo che:dispatch: []
Esegui il deployment del file
dispatch.yaml
in App Engine.