Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
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.
Puoi configurare le impostazioni dell'app App Engine nel file app.yaml.
Questo file specifica in che modo i percorsi degli URL corrispondono ai gestori di richieste e ai file statici.
Il file app.yaml contiene anche informazioni sul codice dell'app, come il runtime e l'identificatore della versione più recente.
Ogni servizio nell'app ha il proprio file app.yaml, che funge da descrittore per il relativo deployment. Devi creare il file app.yaml per il servizio default prima di poter creare ed eseguire il deployment di file app.yaml per servizi aggiuntivi all'interno dell'app.
Una direttiva script: può contenere un percorso file che termina con .py, il che significa che lo script utilizza CGI, oppure un percorso modulo Python, con i nomi dei pacchetti separati da punti, il che significa che lo script utilizza WSGI.
Il formato YAML supporta i commenti. Una riga che inizia con un carattere cancelletto (#) viene ignorata:
# This is a comment.
I pattern di URL e di percorsi dei file utilizzano la sintassi delle espressioni regolari estese di POSIX, escludendo gli elementi di confronto e le classi di confronto. Sono supportati i ritorni a ritroso alle corrispondenze raggruppate (ad es. \1), così come le seguenti estensioni Perl: \w \W \s \S \d \D.
Elementi di runtime ed app
Elemento
Descrizione
application
L'approccio consigliato consiste nel rimuovere l'elemento application dal file app.yaml e utilizzare invece un flag della riga di comando per specificare l'ID applicazione:
Per utilizzare il comando
gcloud app deploy, devi specificare il
flag --project:
gcloud app deploy --project [YOUR_PROJECT_ID]
Per maggiori informazioni sull'utilizzo di questi comandi, vedi
Deployment dell'app.
L'ID applicazione è l'ID progetto della console Google Cloud
che hai specificato al momento della creazione dell'applicazione nella
console Google Cloud.
api_version
Obbligatorio.
La versione dell'API nell'ambiente di runtime specificato che viene utilizzato dalla tua app.
Quando Google annuncia il supporto di una nuova versione dell'API di un ambiente di runtime, l'app di cui hai eseguito il deployment continuerà a utilizzare quella per cui era stata scritta. Per eseguire l'upgrade dell'app a una nuova versione dell'API, modifica questo valore ed esegui nuovamente il deployment dell'app in App Engine. Quando specifichi il valore 1, viene utilizzato l'ambiente di runtime più recente supportato ogni volta che esegui il deployment dell'app (attualmente ).
Al momento, App Engine dispone di una sola versione dell'ambiente di runtime python27: 1
Predefinita. Utilizza ID automatici sparsi, ovvero numeri interi ben distribuiti, grandi e sufficientemente piccoli da essere rappresentati da valori in virgola mobile a 64 bit.
Facoltativo.
L'SDK Python 2 include una serie di gestori integrati per le funzioni di applicazioni più comuni. L'istruzione builtins consente di includere gestori specifici in app.yaml.
Attiva il gestore differito su /_ah/queue/deferred.
Questa funzionalità integrata consente agli sviluppatori di utilizzare deferred.defer()
per semplificare la creazione di attività relative alle code di attività.
remote_api
Abilita la funzionalità integrata remote_api su
/_ah/remote_api/. Questa funzionalità integrata consente alle applicazioni remote con le credenziali corrette di accedere al datastore da remoto.
Esempio:
builtins:
- deferred: on
- appstats: on
L'istruzione builtins è un'istanza speciale dell'istruzione includes. Ogni istruzione builtin
è equivalente, in Python, a un'istruzione includes con
un percorso espanso. Ad esempio:
Quando utilizzi builtins nel file app.yaml, gli eventuali gestori definiti nel file include.yaml integrato sostituiranno gli eventuali gestori che hai definito nel file app.yaml. Tuttavia, se includi un file che poi utilizza builtins o includes, i gestori vengono aggiunti in base all'ordine della gerarchia di inclusione. In altre parole, i gestori dell'elemento "principale" vengono aggiunti prima che quelli dell'elemento "secondario" includano e così via.
Ad esempio, considera l'elemento app.yaml seguente, che utilizza
i gestori appstats integrati:
handlers:
- url: /.*
script: main.app
builtins:
- appstats: on
L'elenco di gestori risultante è:
[/_ah/stats, /.*]
Se app.yaml utilizza un'istruzione includes:
includes:
- included.yaml
E il file included.yaml utilizza builtins:
handlers:
- url: /.*
script: main.app
builtins:
- appstats: on
L'elenco di gestori risultante è ora:
[/.*, /_ah/stats]
L'ordine di posizionamento della clausola builtins in un
file .yaml non ne modifica il comportamento.
default_expiration
Facoltativo. Consente di impostare un periodo predefinito per la cache globale per tutti i gestori di file statici di un'applicazione. Puoi anche configurare una durata della cache per gestori di file
statici specifici. Il valore è una stringa di numeri e unità, separati da spazi, dove le unità possono essere d per i giorni, h per ore, m per minuti e s per secondi. Ad esempio, "4d 5h" imposta la scadenza della cache su 4 giorni e 5 ore dopo la prima richiesta del file. Se omesso, il server di produzione imposta la scadenza su 10 minuti.
Facoltativo.
Puoi definire le variabili di ambiente nel file app.yaml
per renderle disponibili nella tua app. Assicurati che la chiave nelle variabili di ambiente corrisponda all'espressione "[a-zA-Z_][a-zA-Z0-9_]*" (inizia con l'alfabeto o "_" seguito da caratteri alfanumerici o "_").
Le variabili di ambiente precedute dal prefisso GAE sono riservate all'uso da parte del sistema e non sono consentite nel file app.yaml.
Queste variabili saranno disponibili nel dizionario os.environ:
Questa notifica viene inviata se viene raggiunta una scadenza prima che venga ricevuta una risposta dalla tua app.
Il valore error_code è facoltativo; se non è specificato, il file specificato è la risposta di errore predefinita per la tua app.
file
Ogni voce di file indica un file statico che deve essere pubblicato al posto della risposta di errore generica. Se specifichi un elemento file senza un elemento error_code corrispondente, il file statico sarà la pagina di errore predefinita per la tua app.
I dati di errore personalizzati devono essere inferiori a 10 kilobyte.
Obbligatorio.
Un elenco di pattern URL e descrizioni di come devono essere gestiti.
App Engine può gestire gli URL eseguendo il codice dell'applicazione o pubblicando file statici caricati con il codice, come immagini, CSS o JavaScript.
Facoltativo.
L'istruzione includes consente di includere il file di configurazione per qualsiasi libreria o servizio all'interno dell'applicazione. Ad esempio, puoi includere una libreria di amministrazione utenti come segue:
includes:
- lib/user_admin.yaml
App Engine risolve il percorso incluso nel seguente ordine:
Percorso assoluto o relativo della directory di lavoro. Il percorso specificato viene risolto in un file.
Relativo alla directory dell'applicazione, nota anche come basepath. Il percorso base e il percorso si risolvono in un file.
Rispetto al file che includeva il file corrente. La posizione del file di riferimento e il percorso di inclusione vengono risolti nel file incluso.
Se l'istruzione include specifica una directory, App Engine cerca in quella directory il file denominato include.yaml. Se l'istruzione "include" è un file, viene incluso anche quel file specifico. L'utilizzo di includes consente di recuperare solo i seguenti tipi di istruzioni dal file di destinazione (se presente):
I pattern skip_files inclusi vengono aggiunti a quelli che
includono app.yaml o all'elenco predefinito se non è presente
alcun elenco esplicito in app.yaml. Tieni presente che skip_files confronta i percorsi assoluti.
inbound_services
Facoltativo.
Le applicazioni devono abilitare questi servizi prima che possano ricevere richieste in entrata. Puoi abilitare il servizio per un'app Python 2 includendo una sezione inbound_services nel file app.yaml.
I seguenti valori sono disponibili a seconda della
scalabilità del servizio:
Scalabilità automatica
F1, F2, F4, F4_1G
Predefinito:F1
Facoltativamente, utilizza l'elemento automatic_scaling per modificare le impostazioni predefinite per la scalabilità automatica, come il numero minimo e massimo di istanze, la latenza e le connessioni simultanee.
Nota: se instance_class è impostato su F2 o su un valore superiore, puoi ottimizzare le istanze impostando max_concurrent_requests su un valore superiore al valore predefinito di 10. Per determinare il valore ottimale, aumentalo gradualmente e monitora le prestazioni della tua applicazione.
Scalabilità di base e manuale
B1, B2, B4, B4_1G, B8
Predefinito:B2
Le classi di istanza di base e manuali richiedono di specificare
l'elemento basic_scaling o l'elemento manual_scaling.
libraries
Facoltativo.
Il runtime Python 2.7 include alcune librerie di terze parti. Alcune sono disponibili per impostazione predefinita, mentre altre sono disponibili solo se configurate. Puoi specificare la versione da utilizzare specificando i valori name e version.
Nota che quando specifichi latest, l'SDK determina
la versione più recente della libreria al momento del deployment. Una volta eseguito il deployment, la versione della libreria non cambierà. L'unico modo per ottenere una versione diversa della libreria è eseguire di nuovo il deployment.
Se stai sviluppando un'applicazione che non ha ancora utenti: non devi monitorare le nuove versioni. Tuttavia, se la tua applicazione viene usata attivamente, fai attenzione: potresti sorprenderti che la tua applicazione inizi a utilizzare una nuova versione della libreria non compatibile con le versioni precedenti.
Per gestire la tua app con gcloud CLI, utilizza invece l'elemento service.
runtime
Obbligatorio. Il nome dell'ambiente di runtime utilizzato dalla tua
app. Ad esempio, per specificare Python 2.7, utilizza:
runtime: python27
service
I servizi in precedenza erano noti come Moduli.
Supportato solo dai plug-in basati su gcloud CLI o gcloud CLI, ad esempio: gcloud app deploy.
Obbligatorio se crei un
servizio.
Facoltativo per il servizio
default. Ogni servizio e ogni versione devono avere un nome. Un nome può contenere numeri, lettere e trattini. La lunghezza combinata di
VERSION-dot-SERVICE-dot-PROJECT_ID, dove VERSION è il nome della
tua versione, SERVICE è il nome del servizio e PROJECT_ID
è l'ID progetto, non può superare i 63 caratteri e non può
iniziare o terminare con un trattino. Scegli un nome univoco per ciascun servizio e ciascuna versione. Non riutilizzare i nomi tra servizi e versioni.
Esempio:
service: service-name
Nota: il comando gcloud app
deploy è compatibile con le versioni precedenti e supporta i file app.yaml esistenti che includono i servizi dichiarati come moduli, ad esempio:
module: service-name
service_account
Facoltativo. L'elemento service_account consente di specificare un
account di servizio gestito dall'utente come identità per la versione. L'account di servizio specificato viene utilizzato per accedere ad altri servizi Google Cloud ed eseguire attività.
Facoltativo.
L'elemento skip_files specifica quali file nella directory delle applicazioni non devono essere caricati in App Engine.
Il valore è un'espressione regolare o un elenco di espressioni regolari. I nomi di file corrispondenti a una qualsiasi delle espressioni regolari vengono omessi dall'elenco dei file da caricare quando viene caricata l'applicazione. I nomi file sono relativi alla directory del progetto.
Il pattern predefinito esclude i file di backup di Emacs con nomi nei formati
#...# e ...~, .pyc e
.pyo, file in una directory di controllo delle revisioni RCS
e file nascosti Unix con nomi che iniziano con un punto
(.).
Per estendere l'elenco di espressioni regolari riportato sopra, copia e incolla l'elenco precedente in app.yaml e aggiungi le tue espressioni regolari. Ad esempio, per saltare i file i cui nomi terminano con .bak oltre ai pattern predefiniti, aggiungi una voce come la seguente per skip_files:
Per saltare una directory completa, aggiungi il nome della directory all'elenco. Ad esempio, per saltare una directory denominata logs, aggiungi la seguente riga a quelle descritte in precedenza:
skip_files:
- logs/
threadsafe
Obbligatorio.
Configura la tua applicazione per utilizzare le richieste in parallelo. Se utilizzi la
libreria di threading di Python, i dati locali del thread, restituiti da threading.local(), vengono cancellati dopo ogni richiesta.
Nota: l'istruzione threadsafe è obbligatoria per le applicazioni Python 2.7.
threadsafe: true richiede che tutti i gestori di script siano WSGI. In altre parole, ogni script deve essere specificato in un'istruzione script: utilizzando un percorso del modulo Python, con i nomi dei pacchetti separati da punti. L'ultimo componente di un'istruzione script: che utilizza un percorso modulo Python è il nome di una variabile globale nel service: tale variabile deve essere un'app WSGI e di solito viene chiamata app per convenzione.
version
L'approccio consigliato consiste nel rimuovere l'elemento version dal file app.yaml e utilizzare invece un flag della riga di comando per specificare l'ID versione:
Per utilizzare il comando
gcloud app deploy, devi specificare il
flag -v:
gcloud app deploy -v [YOUR_VERSION_ID]
Per maggiori informazioni sull'utilizzo di questo comando, vedi
Deployment dell'app.
Un identificatore della versione del codice dell'applicazione di cui esegui il deployment in App Engine.
L'ID versione può contenere lettere minuscole, cifre e trattini. Non
può iniziare con il prefisso ah- e i nomi
default e latest sono riservati e non possono
essere utilizzati.
Nota: i nomi di versione devono iniziare con una lettera per distinguerli dalle istanze numeriche sempre specificate da un numero. Ciò consente di evitare ambiguità relative a URL come 123-dot-my-service.uc.r.appspot.com, che possono essere interpretati in due modi: se esiste la versione "123", la destinazione sarà la versione "123" del servizio specificato. Se questa versione non esiste, la destinazione sarà il numero di istanza 123 della versione predefinita del servizio.
Ogni versione di un'applicazione conserva la propria copia di app.yaml. Quando viene caricata un'applicazione, la versione menzionata nel file app.yaml caricato è quella che viene creata o sostituita dal caricamento. Un amministratore può modificare la versione dell'applicazione che gestisce il traffico utilizzando la console Google Cloud e può anche testare altre versioni prima di configurarle per la ricezione del traffico.
vpc_access_connector
Facoltativo.
Configura la tua applicazione in modo che utilizzi un connettore di accesso VPC serverless, consentendo all'applicazione di inviare richieste alle risorse interne nella tua rete VPC. Per maggiori informazioni, consulta
Connessione a una rete VPC.
name
Valore letterale stringa. Specifica il nome completo del connettore di accesso VPC serverless tra virgolette:
Facoltativo. Il valore predefinito è private-ranges-only. egress_setting può essere uno dei seguenti:
private-ranges-only
Predefinita. Le richieste agli indirizzi IP interni vengono inviate tramite il connettore di accesso VPC serverless alla rete VPC connessa. Le richieste agli indirizzi IP esterni vengono inviate alla rete internet pubblica.
all-traffic
Tutte le richieste vengono inviate tramite il connettore di accesso VPC serverless alla rete VPC connessa.
L'elemento handlers è un elemento obbligatorio nel
file di configurazione app.yaml. L'elemento fornisce un elenco di pattern URL
e descrizioni di come devono essere gestiti. App Engine può gestire gli URL eseguendo il codice dell'applicazione o pubblicando file statici caricati con il codice, come immagini, CSS o JavaScript.
I pattern vengono valutati nell'ordine in cui appaiono nel file app.yaml, dall'alto verso il basso. Il primo mapping il cui pattern corrisponde all'URL è quello utilizzato per gestire la richiesta.
Nella tabella seguente sono elencati gli elementi secondari dell'elemento handlers che controllano il comportamento di script, file statici, directory statiche e altre impostazioni.
Elemento
Descrizione
application_readable
Facoltativo. Valore booleano. Per impostazione predefinita, i file dichiarati nei gestori di file statici vengono caricati come dati statici e vengono pubblicati solo per gli utenti finali. Non possono essere letti da un'applicazione. Se questo campo viene impostato su true, i file vengono caricati anche come dati di codice in modo che l'applicazione possa leggerli.
Entrambi i caricamenti vengono addebitati in base alle quote delle risorse di codice e archiviazione dei dati statici.
Facoltativo.
Il periodo di tempo in cui un file statico pubblicato da questo gestore deve essere memorizzato nella cache da proxy web e browser. Il valore è una stringa di
numeri e unità, separati da spazi, dove le unità possono essere
d per i giorni, h per ore, m per
minuti e s per i secondi. Ad esempio, "4d 5h" imposta la scadenza della cache su 4 giorni e 5 ore dopo la prima richiesta del file. Se omesso, viene utilizzato il valore default_expiration dell'applicazione. Per ulteriori dettagli, consulta Scadenza della cache.
http_headers
Facoltativo. Puoi impostare intestazioni HTTP per le risposte dei gestori di directory o di file statici. Se devi impostare le intestazioni HTTP nei gestori script, devi farlo nel codice dell'app. Per informazioni su quali intestazioni delle risposte influenzano la memorizzazione nella cache, consulta Memorizzazione nella cache dei contenuti statici.
Esempio
handlers:
- url: /images
static_dir: static/images
http_headers:
X-Foo-Header: foo
X-Bar-Header: bar value
vary: Accept-Encoding
# ...
Supporto CORS
Un utilizzo importante di questa funzionalità è il supporto della condivisione delle risorse tra origini (CORS), ad esempio l'accesso ai file ospitati da un'altra app App Engine.
Ad esempio, potresti avere un'app di gioco mygame.uc.r.appspot.com
che accede agli asset ospitati da myassets.uc.r.appspot.com.
Tuttavia, se mygame tenta di creare un codice JavaScript
XMLHttpRequest per myassets, l'operazione
non avrà esito positivo a meno che il gestore per myassets non restituisca un'intestazione della risposta Access-Control-Allow-Origin: contenente
il valore http://mygame.uc.r.appspot.com.
Ecco come fare in modo che il gestore di file statico restituisca il valore di intestazione della risposta richiesta:
Nota: se vuoi consentire a tutti di accedere ai tuoi asset, puoi
utilizzare il carattere jolly '*', anziché
https://mygame.uc.r.appspot.com.
mime_type
Facoltativo. Se specificato, tutti i file pubblicati da questo gestore verranno pubblicati utilizzando il tipo MIME specificato. Se non specificato, il tipo MIME di un file verrà derivato dall'estensione del nome file del file.
Se lo stesso file viene caricato con più estensioni, l'estensione risultante può dipendere dall'ordine in cui sono stati eseguiti i caricamenti.
Per ulteriori informazioni sui possibili tipi di contenuti multimediali MIME, visita il sito web IANA MIME Media Type
redirect_http_response_code
Facoltativo. redirect_http_response_code viene utilizzato con l'impostazione secure per impostare il codice di risposta HTTP restituito quando si esegue un reindirizzamento richiesto dal modo in cui è configurata l'impostazione secure.
L'elemento redirect_http_response_code ha i seguenti
valori possibili:
301
Codice di risposta permanente spostato.
302
Codice di risposta trovato.
303
Vedi Altro codice di risposta.
307
Codice di risposta di reindirizzamento temporaneo.
Quando la richiesta di un utente viene reindirizzata, il codice di stato HTTP viene impostato sul valore del parametro redirect_http_response_code. Se il parametro non è presente, verrà restituito il valore 302.
script
Facoltativo.
Specifica il percorso dello script dalla directory radice dell'applicazione:
handlers:
# The root URL (/) is handled by the WSGI application named
# "app" in home.py. No other URLs match this pattern.
- url: /
script: home.app
# The URL /index.html is also handled by the home.py script.
- url: /index\.html
script: home.app
# A regular expression can map parts of the URL to the
# path of the script.
- url: /browse/(books|videos|tools)
script: \1.catalog.app
# All other URLs use the WSGI application named in "app"
# in not_found.py.
- url: /.*
script: not_found.app
Un'istruzione script: deve essere un percorso di importazione Python, ad esempio package.module.app che punta a un'applicazione WSGI. L'ultimo componente di un'istruzione script: che utilizza un percorso modulo Python è il nome di una variabile globale nel modulo: questa variabile deve essere un'app WSGI e di solito viene chiamata app per convenzione.
Nota: proprio come per un'istruzione import Python, ogni
sottodirectory di un pacchetto deve contenere un file denominato __init__.py.
Facoltativo. Qualsiasi gestore di URL può utilizzare l'impostazione secure, inclusi i gestori di script e di file statici. L'elemento secure ha i seguenti
valori possibili:
optional
Sia le richieste HTTP che HTTPS con URL corrispondenti al gestore hanno esito positivo senza reindirizzamenti. L'applicazione può esaminare la richiesta per determinare quale protocollo è stato utilizzato e rispondere di conseguenza. Questa è l'impostazione predefinita quando non viene fornito secure per un gestore.
never
Le richieste di un URL corrispondente a questo gestore che utilizzano HTTPS vengono reindirizzate automaticamente all'URL HTTP equivalente. Quando la richiesta HTTPS di un utente viene reindirizzata come richiesta HTTP, i parametri di ricerca vengono rimossi dalla richiesta. Questo impedisce a un utente di inviare accidentalmente dati di query su una connessione non protetta destinata a una connessione sicura.
always
Le richieste di un URL che corrisponde a questo gestore che non utilizzano HTTPS vengono
reindirizzate automaticamente all'URL HTTPS con lo stesso percorso. I parametri di query vengono conservati per il reindirizzamento.
Il server web di sviluppo non supporta le connessioni HTTPS. Il parametro secure viene ignorato, pertanto i percorsi destinati all'utilizzo con HTTPS possono essere testati utilizzando normali connessioni HTTP al server web di sviluppo.
L'accesso e la disconnessione da un Account Google vengono sempre eseguiti utilizzando una connessione protetta, indipendentemente dalla configurazione degli URL dell'applicazione.
static_dir
Facoltativo. Il percorso della directory contenente i file statici, dalla directory principale dell'applicazione. Tutto quello che segue la fine del
pattern url corrispondente viene aggiunto a
static_dir per formare il percorso completo al file richiesto.
Ogni file nella directory statica viene pubblicato utilizzando il tipo MIME corrispondente all'estensione del nome file, a meno che non venga sostituito dall'impostazione mime_type della directory. Tutti i file nella directory specificata vengono caricati come file statici e nessuno può essere eseguito come script.
Tutti i file in questa directory vengono caricati con la tua app come file statici. App Engine archivia e pubblica i file statici separatamente dai file dell'app. I file statici non sono disponibili nel file system dell'app per impostazione predefinita. Per modificare questa impostazione, imposta l'opzione application_readable su true.
Esempio:
handlers:
# All URLs beginning with /stylesheets are treated as paths to
# static files in the stylesheets/ directory.
- url: /stylesheets
static_dir: stylesheets
# ...
static_files
Facoltativo. Un gestore di pattern di file statici associa un pattern URL ai percorsi dei file statici caricati con l'applicazione. L'espressione regolare del pattern URL può definire raggruppamenti di espressioni regolari da utilizzare nella creazione del percorso file. Puoi utilizzare questa opzione anziché static_dir per mappare file specifici in una struttura di directory senza mappare l'intera directory.
Esempio:
handlers:
# All URLs ending in .gif .png or .jpg are treated as paths to
# static files in the static/ directory. The URL pattern is a
# regular expression, with a grouping that is inserted into the
# path to the file.
- url: /(.*\.(gif|png|jpg))$
static_files: static/\1
upload: static/.*\.(gif|png|jpg)$
# ...
App Engine archivia e gestisce i file statici separatamente dai file dell'applicazione. Per impostazione predefinita, i file statici non sono disponibili nel file system dell'applicazione. Questo valore può essere modificato impostando l'opzione application_readable su true.
I file statici non possono essere uguali ai file con il codice dell'applicazione.
Se un percorso di file statico corrisponde a un percorso a uno script utilizzato in un gestore dinamico, lo script non sarà disponibile per il gestore dinamico.
upload
Facoltativo. Un'espressione regolare che corrisponde ai percorsi dei file di tutti i file a cui questo gestore farà riferimento. Questa operazione è necessaria perché il gestore non è in grado di determinare quali file nella directory dell'applicazione corrispondono ai pattern url e static_files specificati. I file statici vengono caricati e gestiti separatamente dai file dell'applicazione. L'esempio
precedente potrebbe utilizzare il seguente pattern upload:
archives/(.*)/items/(.*)
url
Elemento obbligatorio in handlers. Il pattern URL, come
espressione regolare. L'espressione può contenere raggruppamenti a cui è possibile fare riferimento nel percorso file dello script con riferimenti a ritroso tramite espressione regolare. Ad esempio, /profile/(.*)/(.*) corrisponde all'URL /profile/edit/manager e utilizza edit e manager come primo e secondo raggruppamento.
Il pattern URL presenta alcune differenze di comportamento quando viene utilizzato con i seguenti elementi:
Utilizza un prefisso URL. Il pattern express regolare non deve contenere raggruppamenti se utilizzato con l'elemento static_dir. Tutti gli URL che iniziano con questo prefisso vengono gestiti da questo gestore, utilizzando come parte del percorso del file la parte dell'URL che segue il prefisso.
Un gestore di pattern di file statici associa un pattern URL ai percorsi dei file statici caricati con l'applicazione. L'espressione regolare del pattern URL può definire raggruppamenti di espressioni regolari da utilizzare nella creazione del percorso file. Puoi utilizzare questa opzione anziché static_dir per mappare file specifici in una struttura di directory senza mappare l'intera directory.
Ridimensionare gli elementi
Gli elementi nella tabella seguente configurano la scalabilità dell'applicazione. Per scoprire di più sulla scalabilità delle app di App Engine, consulta Tipi di scalabilità.
Elemento
Descrizione
automatic_scaling
Facoltativo. Applicabile solo per le applicazioni che utilizzano una classe di istanza F1 o superiore.
Specifica questo elemento per modificare le impostazioni predefinite per la scalabilità automatica, ad esempio l'impostazione dei livelli minimo e massimo per il numero di istanze, la latenza e le connessioni simultanee per un servizio.
Questo elemento può contenere i seguenti elementi:
max_instances
Facoltativo. Specifica un valore compreso tra 0 e 2147483647, dove zero
disabilita l'impostazione.
Questo parametro specifica il numero massimo di istanze che App Engine può creare per questa versione del modulo. Questo è utile per limitare i costi di un modulo.
min_instances
Facoltativa. Il numero minimo di istanze da creare con App Engine per questa versione del modulo. Queste istanze gestiscono il traffico all'arrivo delle richieste e continuano a gestire il traffico anche quando vengono avviate altre istanze richieste per gestire il traffico.
Specifica un valore compreso tra 0 e 1000. Puoi impostare il parametro sul valore 0 per consentire la scalabilità a 0 istanze per ridurre i costi quando non vengono gestite richieste. Tieni presente che ti viene addebitato
il numero di istanze specificato, indipendentemente dal fatto che
ricevano o meno il traffico.
max_idle_instances
Facoltativo. Il numero massimo di istanze inattive che App Engine deve mantenere per questa versione. Specifica un valore compreso tra 1 e 1000. Se non specificato, il valore predefinito è automatic,
il che significa che App Engine gestirà
il numero di istanze inattive.
Tieni presente che:
Un valore massimo elevato riduce il numero di istanze inattive in modo più graduale quando i livelli di carico tornano alla normalità dopo un picco. Ciò consente all'applicazione di mantenere prestazioni stabili attraverso le fluttuazioni del carico delle richieste, ma aumenta anche il numero di istanze inattive (e i conseguenti costi di esecuzione) durante questi periodi di carico elevato.
Un valore massimo basso consente di ridurre i costi di esecuzione, ma può compromettere le prestazioni a fronte di livelli di carico volatili.
Nota: quando si torna a livelli normali dopo un picco di carico, il numero di istanze inattive può temporaneamente superare il limite massimo specificato. Tuttavia, non ti verrà addebitato un numero di istanze superiore a quello specificato.
min_idle_instances
(Facoltativo) Il numero di istanze aggiuntive da mantenere in esecuzione
e pronte a gestire il traffico per questa versione.
App Engine calcola il numero di istanze necessarie per gestire il traffico attuale dell'applicazione in base alle impostazioni di scalabilità come target_cpu_utilization e target_throughput_utilization. L'impostazione di min_idle_instances specifica il numero di istanze da eseguire oltre a questo numero calcolato. Ad esempio, se App Engine calcola che sono necessarie 5 istanze per gestire il traffico e min_idle_instances è impostato su 2, App Engine eseguirà 7 istanze (5, calcolate in base al traffico, più due aggiuntive per min_idle_instances).
Tieni presente che ti viene addebitato
il numero di istanze specificato, indipendentemente dal fatto che
ricevano o meno il traffico. Tieni presente che:
Un minimo basso aiuta a mantenere bassi i costi di esecuzione durante i periodi di inattività, ma significa che meno istanze potrebbero essere immediatamente disponibili per rispondere a un picco improvviso del carico.
Un minimo elevato consente di preparare l'applicazione per picchi rapidi nel carico delle richieste. App Engine mantiene il numero minimo di istanze in esecuzione per gestire le richieste in entrata. Ti viene addebitato il numero di istanze specificato, indipendentemente dal fatto che stiano gestendo le richieste.
Se imposti un numero minimo di istanze inattive, latenza in sospeso avrà meno effetto sulle prestazioni della tua applicazione.
target_cpu_utilization
Facoltativo. Specifica un valore compreso tra 0,5 e 0,95. Il valore predefinito è 0.6.
Questo parametro specifica la soglia di utilizzo della CPU al quale le nuove istanze inizieranno a gestire il traffico. In questo modo potrai trovare un equilibrio tra prestazioni e costi, con valori più bassi che aumentano le prestazioni e i costi e i valori più alti diminuiscono le prestazioni, ma anche i costi. Ad esempio, un valore pari a 0,7 indica che le nuove istanze verranno avviate dopo che l'utilizzo della CPU avrà raggiunto il 70%.
target_throughput_utilization
Facoltativo. Specifica un valore compreso tra 0,5 e 0,95. Il valore predefinito è 0.6.
Utilizzato con max_concurrent_requests per specificare quando viene avviata una nuova istanza a causa di richieste in parallelo. Quando il
numero di richieste in parallelo raggiunge un valore uguale a
max_concurrent_requests volte
target_throughput_utilization, lo scheduler tenta
di avviare una nuova istanza.
max_concurrent_requests
Facoltativo. Il numero di richieste in parallelo che un'istanza di scalabilità automatica può accettare prima che lo scheduler generi una nuova istanza (valore predefinito: 10, massimo: 1000).
Utilizzato con target_throughput_utilization per specificare quando viene avviata una nuova istanza a causa di richieste in parallelo.
Quando il numero di richieste in parallelo raggiunge un valore uguale a max_concurrent_requests per target_throughput_utilization, lo scheduler tenta di avviare una nuova istanza.
Ti consigliamo di non impostare max_concurrent_requests su un valore inferiore a 10, a meno che tu non abbia bisogno di un thread singolo. È probabile che un valore inferiore a 10 porti alla creazione di più istanze del necessario per un'app threadsafe, il che potrebbe portare a costi non necessari.
Se questa impostazione è troppo alta, potresti riscontrare una maggiore latenza delle API. Tieni presente che lo scheduler potrebbe generare una nuova istanza prima che venga raggiunto il numero massimo effettivo di richieste.
max_pending_latency
Il tempo massimo che App Engine deve consentire a una richiesta di attendere nella coda in attesa prima di avviare altre istanze per gestire le richieste in modo da ridurre latenza in sospeso. Quando questa soglia viene raggiunta, è un indicatore di scale up e determina un aumento del numero di istanze.
Se non specificato, il valore predefinito è automatic. Ciò significa che le richieste possono rimanere nella coda in attesa per un massimo di 10 secondi, il
limite di tempo massimo per le richieste in attesa, prima che vengano attivati i nuovi avvii di istanza.
Un valore massimo basso significa che App Engine avvia prima nuove istanze per le richieste in attesa, migliorando le prestazioni ma aumentando i costi di esecuzione.
Un numero massimo elevato significa che gli utenti potrebbero attendere più a lungo per la pubblicazione delle loro richieste (se ci sono richieste in attesa e nessuna istanza inattiva per gestirle), ma l'esecuzione dell'applicazione avrà un costo inferiore.
min_pending_latency
Un elemento facoltativo che puoi impostare per specificare il periodo di tempo minimo che App Engine deve consentire a una richiesta di attendere nella coda in attesa prima di avviare una nuova istanza per gestirla.
Specificare un valore può ridurre i costi di esecuzione, ma aumentare il tempo
di attesa degli utenti per la distribuzione delle richieste.
Per le app gratuite, il valore predefinito è 500ms. Per le app
a pagamento, il valore predefinito è 0.
Questo elemento interagisce con l'elemento max_pending_latency per determinare quando App Engine crea nuove istanze.
Se le richieste in attesa sono in coda:
Inferiore al valore min_pending_latency specificato, App Engine non creerà nuove istanze.
Più di max_pending_latency, App Engine proverà a creare una nuova istanza.
Tra il periodo di tempo specificato da min_pending_latency e max_pending_latency, App Engine proverà a riutilizzare un'istanza esistente. Se nessuna istanza è in grado di elaborare la richiesta prima del giorno max_pending_latency, App Engine creerà una nuova istanza.
Le applicazioni che utilizzano una
classe
istanza B1 o superiore devono specificare questo elemento o
manual_scaling.
Questo elemento consente la scalabilità di base delle classi di istanza B1 e successive. Può contenere i seguenti elementi:
max_instances
Obbligatorio. Il numero massimo di istanze che App Engine può creare per questa versione del servizio. Ciò è utile per limitare i costi di un servizio.
idle_timeout
Facoltativo. L'istanza verrà arrestata questo periodo di tempo dopo aver ricevuto l'ultima richiesta. Il valore predefinito è 5 minuti
(5m).
