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 alla regione selezionata al momento della creazione dell'app. Il codice non
corrispondono a un paese o a una provincia, anche se potrebbero essere visualizzati alcuni ID regione
in modo simile 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.
Configura le impostazioni dell'app App Engine in app.yaml
.
Questo file specifica in che modo i percorsi degli URL corrispondono ai gestori di richieste e
file statici.
Il file app.yaml contiene anche informazioni sul codice della tua app, ad esempio il runtime e l'identificatore della versione più recente.
Ogni servizio
nella tua app ha il proprio file app.yaml, che funge da descrittore per il suo
implementazione. Devi prima creare il file app.yaml per il servizio default
prima di poter creare ed eseguire il deployment di file app.yaml per i servizi aggiuntivi all'interno di
la tua app.
Un'istruzione script: può contenere un percorso file che termina con .py, che
indica che lo script utilizza CGI, o un percorso del modulo Python, con i nomi dei pacchetti.
sono separati da punti, il che significa che lo script utilizza WSGI.
Il formato YAML supporta i commenti. Una riga che inizia con il carattere cancelletto (#) viene ignorata:
# This is a comment.
I pattern per URL e percorsi file utilizzano l'espressione regolare estesa POSIX
, escludendo le regole di confronto
elementi e classi di confronto. Riferimenti precedenti a corrispondenze raggruppate (ad es. \1)
così come le seguenti estensioni Perl: \w \W \s \S \d \D.
Elementi di runtime e app
Elemento
Descrizione
application
L'approccio consigliato è rimuovere l'elemento application
dal file app.yaml e utilizzare un
flag della riga di comando per specificare l'ID applicazione:
Per utilizzare il comando
gcloud app deploy, devi specificare il
Flag --project:
gcloudappdeploy--project[YOUR_PROJECT_ID]
Per ulteriori informazioni sull'uso di questi comandi, vedi
Deployment dell'app.
L'ID applicazione è l'ID progetto della console Google Cloud
specificato quando hai creato l'applicazione nella
console Google Cloud.
api_version
Obbligatorio.
La versione dell'API nell'ambiente di runtime specificato utilizzata
dalla tua app.
Quando Google annuncia il supporto di una nuova versione dell'API di un ambiente di runtime, l'app di cui è stato eseguito il deployment continuerà a utilizzare quella per cui è stata scritta. Per eseguire l'upgrade dell'app a una nuova versione
dell'API, modifica questo valore e poi 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 ha una versione dell'ambiente di runtime python27:1
Valore predefinito. Utilizza ID automatici sparsi che sono grandi e ben distribuiti
numeri interi sufficientemente piccoli da essere rappresentati da numeri in virgola mobile a 64 bit.
Facoltativo.
L'SDK Python 2 include una serie di gestori integrati per
funzioni di applicazione più comuni. L'istruzione builtins
ti consente di includere gestori specifici in app.yaml.
Attiva
Appstat di /_ah/stats/, che puoi utilizzare per
per misurare le prestazioni della tua applicazione. Per utilizzare Appstat,
devi inoltre
installa il registratore di eventi.
deferred
Attiva il gestore differito in /_ah/queue/deferred.
Questo comando integrato consente agli sviluppatori di utilizzare deferred.defer()
per semplificare la creazione delle attività della coda di lavoro.
remote_api
Consente di attivare remote_api integrata alle
/_ah/remote_api/. Questo valore predefinito consente alle applicazioni remote con le credenziali appropriate di accedere al datastore da remoto.
Esempio:
builtins:-deferred:on-appstats:on
L'istruzione builtins è un'istanza speciale del metodo
includes. Ogni istruzione builtin
è equivalente, in Python, a un'istruzione includes con
un percorso espanso. Ad esempio:
Quando utilizzi builtins nel file app.yaml,
tutti gli handler definiti nel file include.yaml predefinito sostituiranno gli eventuali handler definiti nel file app.yaml. Tuttavia, se includi una
che utilizza builtins o includes,
I gestori vengono aggiunti in base all'ordine della gerarchia di inclusione. In altre
parole, i gestori dell'include "principale" vengono aggiunti prima degli
elementi incorporati dell'include "secondario" e così via.
L'ordine di posizionamento della clausola builtins in una
.yaml non modifica il comportamento.
default_expiration
Facoltativo. Imposta un periodo di cache predefinito globale per tutti i gestori di file statici di un'applicazione. Puoi anche configurare una durata della cache per file statici specifici
e i gestori di rete. Il valore è una stringa di numeri e unità, separati da spazi, dove le unità possono essere d per giorni, h per ore, m per minuti e s per secondi. Ad esempio, "4d 5h" imposta la scadenza della cache
a 4 giorni e 5 ore dalla prima richiesta del file. Se omesso,
il server di produzione imposta la scadenza a 10 minuti.
Facoltativo.
Puoi definire le variabili di ambiente in app.yaml
per renderle disponibili per la 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 qualsiasi carattere alfanumerico o "_").
Le variabili di ambiente precedute dal prefisso
GAE sono riservate all'uso di sistema e non sono consentite nel
app.yaml file.
Queste variabili saranno disponibili in os.environ
dizionario:
Viene pubblicato se viene raggiunta una scadenza prima di ricevere una risposta da
la tua app.
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 in
della risposta di errore generico. 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, ad esempio immagini, CSS o JavaScript.
Facoltativo.
L'istruzione includes ti consente di includere
di configurazione per qualsiasi libreria o servizio nel tuo
un'applicazione. Ad esempio, puoi includere un'amministrazione utenti
libreria nel seguente modo:
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 risolve in un file.
Rispetto alla directory dell'applicazione, nota anche come
basepath. Il percorso di base e il percorso risolvono in un file.
Rispetto al file che includeva il file corrente. La posizione di
il file di riferimento e il percorso di inclusione si risolvono nel file
.
Se l'istruzione include specifica una directory, allora App
Engine cerca in quella directory un file denominato
include.yaml. Se l'istruzione di inclusione è un file,
incluso il file. Utilizzo dei recuperi di includes
solo i seguenti tipi di istruzioni dal file di destinazione (se
attuale):
skip_files pattern inclusi vengono aggiunti a quelli in
incluso app.yaml, o all'elenco predefinito se non
elenco esplicito in app.yaml. Tieni presente che
skip_files confronta i percorsi assoluti.
inbound_services
Facoltativo.
Le applicazioni devono abilitare questi servizi prima di poter ricevere messaggi in entrata
richieste. Puoi abilitare il servizio per un'app Python 2
includendo una sezione inbound_services nella
app.yaml file.
I seguenti valori sono disponibili a seconda
del servizio
scalabilità:
Scalabilità automatica
F1, F2, F4, F4_1G
Valore predefinito:F1
Se vuoi, utilizza l'elemento automatic_scaling per modificare le impostazioni predefinite per la scalabilità automatica, ad esempio 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,
aumentarlo gradualmente e monitorare il rendimento
un'applicazione.
Scalabilità di base e manuale
B1, B2, B4, B4_1G, B8
Valore predefinito:B2
Le classi di istanze di base e manuali richiedono di specificare
l'elemento basic_scaling o l'elemento manual_scaling.
libraries
Facoltativo.
Il runtime di 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: rispetto a quando specifichi latest, l'SDK determina
l'ultima versione della libreria al momento del deployment. Una volta
di cui è stato eseguito il deployment, la versione della libreria non cambierà. L'unico modo per ottenere
un'altra versione della libreria.
Se stai sviluppando un'applicazione che non ha ancora utenti,
non devi monitorare le nuove versioni. Ma se la tua applicazione viene
utilizzata attivamente, fai attenzione: potrebbe sorprenderti il fatto che la tua applicazione
inizia a utilizzare una nuova versione della libreria non compatibile con le versioni precedenti.
Per gestire la tua app con l'interfaccia a riga di comando gcloud, 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 erano precedentemente noti come Moduli.
Supportate solo da gcloud CLI o basate su gcloud CLI
plug-in, ad esempio: gcloud app deploy.
Obbligatorio se crei un
servizio.
Facoltativo per il servizio default. Ogni servizio e ogni versione deve 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
versione, SERVICE è il nome del servizio e PROJECT_ID
è l'ID progetto, non deve essere superiore a 63 caratteri e non deve
iniziare o terminare con un trattino. Scegli un nome univoco per ogni servizio
e ogni versione. Non riutilizzare i nomi tra servizi e versioni.
Esempio:
service:service-name
Nota:
Il comando gcloud app
deploy è indietro
compatibile e supporta i file app.yaml esistenti che
Includi 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 i file nella directory dell'applicazione che non devono essere caricati su App Engine.
Il valore è un'espressione regolare o un elenco di valori
le espressioni regolari. Qualsiasi nome file che corrisponde a una delle espressioni regolari
viene omesso dall'elenco dei file da caricare quando viene caricata
l'applicazione. I nomi file sono relativi alla directory del progetto.
skip_files ha le seguenti impostazioni predefinite:
Il pattern predefinito esclude i file di backup di Emacs con nomi di tipo
#...# e ...~, .pyc e
.pyo, i file in una directory di controllo revisione RCS
e i file nascosti Unix con nomi che iniziano con un punto
(.).
Per estendere l'elenco di espressioni regolari precedenti, copia e incolla quanto riportato sopra
elenco nel tuo app.yaml e aggiungi il tuo
le espressioni regolari. Ad esempio, per saltare i file i cui nomi terminano con
.bak oltre ai pattern predefiniti, aggiungi una voce
come questa per skip_files:
Per saltare una directory completa, aggiungi il nome della directory a
dall'elenco. Ad esempio, per saltare una directory denominata logs,
aggiungi la seguente riga a quelle descritte in precedenza:
skip_files:-logs/
threadsafe
Obbligatorio.
Configura l'applicazione per l'uso di richieste in parallelo. Se utilizzi
la
libreria di threading di Python, i
dati a livello di thread, come restituiti da threading.local(), vengono
cancellati dopo ogni richiesta.
Nota: la direttiva threadsafe è obbligatoria per le applicazioni Python 2.7.
threadsafe: true richiede che tutti gli script handler siano
WSGI. Ciò significa che ogni script deve essere specificato in un
script: utilizzando un modulo Python
con i nomi dei pacchetti separati da punti. L'ultimo componente di una direttiva
script: che utilizza il percorso di un modulo Python
è il nome di una variabile globale in service:. Questa variabile deve essere un'app WSGI e in genere viene chiamata app per convenzione.
version
L'approccio consigliato consiste nel rimuovere version
del file app.yaml e utilizza invece un
del flag della riga di comando per specificare l'ID versione:
Un identificatore per la 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 delle versioni devono iniziare con una lettera per distinguerli
da istanze numeriche che sono sempre specificate da un numero. Questo
evita l'ambiguità con URL come
123-dot-my-service.uc.r.appspot.com, che può essere interpretato
in due modi: se la versione "123" esiste, il target sarà la versione "123"
del servizio in questione. Se questa versione non esiste, il target sarà
l'istanza numero 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
indicata nel file app.yaml caricato è la
versione che viene creata o sostituita dal caricamento. Un amministratore
può cambiare la versione dell'applicazione che gestisce il traffico
mediante la console Google Cloud e anche
prova
altre versioni prima di configurarle per ricevere traffico.
vpc_access_connector
Facoltativo.
Configura la tua applicazione per l'uso di un accesso VPC serverless
il connettore dati, consentendo all'applicazione di inviare richieste
delle tue risorse nella tua rete VPC. Per ulteriori informazioni, vedi
Connessione a una rete VPC.
name
Valore letterale di stringa. Specifica il nome completo del tuo
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
Connettore di accesso VPC serverless
alla rete VPC connessa.
L'elemento handlers è obbligatorio nel file di configurazione app.yaml. L'elemento fornisce un elenco di URL
e descrizioni di come dovrebbero essere gestiti. App Engine può gestire gli URL eseguendo il codice dell'applicazione o pubblicando file statici caricati con il codice, ad esempio 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.
La tabella seguente elenca i sottoelementi 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 in gestori di file statici
vengono caricati come dati statici e mostrati
solo agli utenti finali. Non possono essere letti da un'applicazione. Se questo campo è 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 per il codice e i dati statici.
Facoltativo.
Il periodo di tempo in cui un file statico pubblicato da questo gestore dovrebbe essere
memorizzati nella cache da proxy web e browser. Il valore è una stringa di
numeri e unità, separati da spazi, in cui le unità possono essere
d per i giorni, h per le 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, il valore
È in uso default_expiration. Vedi Cache
data di scadenza per ulteriori dettagli.
http_headers
Facoltativo. Puoi impostare HTTP
intestazioni per le risposte del file statico o della directory
e i gestori di rete. Se devi impostare intestazioni HTTP
nei tuoi gestori script, devi invece farlo nelle
le API nel tuo codice. Per informazioni sulle intestazioni di risposta che influiscono sulla memorizzazione nella cache, consulta Memorizzazione nella cache dei contenuti statici.
Un uso importante di questa funzionalità è supportare la 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 a myassets, non
riuscito a meno che il gestore di myassets non restituisca un
L'intestazione della risposta Access-Control-Allow-Origin: contiene
il valore http://mygame.uc.r.appspot.com.
Ecco come fare in modo che il gestore dei file statici restituisca il valore obbligatorio dell'intestazione di risposta:
Nota: se vuoi consentire a tutti di accedere alle tue risorse, 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à dedotto dall'estensione del nome file.
Se lo stesso file viene caricato con più estensioni, l'estensione risultante può dipendere dall'ordine in cui sono stati eseguiti i caricamenti.
Facoltativo. redirect_http_response_code viene utilizzato con l'impostazione secure per impostare il codice di risposta HTTP restituito quando viene eseguito un reindirizzamento richiesto dalla configurazione dell'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 Codice di risposta: altro.
307
Codice di risposta del 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
directory:
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\.htmlscript: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
Una direttiva script: deve essere un percorso di importazione di Python, ad esempio package.module.app che rimanda a un'applicazione WSGI. L'ultimo componente di un'istruzione script:
utilizzando un percorso di modulo Python è il nome di un
nel modulo: quella variabile deve essere un'app WSGI ed è
di solito viene chiamato app per convenzione.
Nota: proprio come per un'istruzione import di Python, ogni
una 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
i gestori di file statici. L'elemento secure ha i seguenti
valori possibili:
optional
Richieste sia HTTP che HTTPS con URL che corrispondono al gestore
hanno esito positivo senza reindirizzamenti. L'applicazione può esaminare la richiesta per determinare quale protocollo è stato utilizzato e rispondere di conseguenza. Questo
è l'impostazione predefinita se secure non viene fornito per un
.
never
Le richieste per un URL corrispondente a questo gestore che utilizzano HTTPS vengono
vengono reindirizzati automaticamente all'URL equivalente HTTP. Quando la richiesta HTTPS di un utente viene reindirizzata a una richiesta HTTP, i parametri di query vengono rimossi dalla richiesta. In questo modo, un
utente non può inviare accidentalmente i dati delle query tramite una connessione
non sicura che era stata pensata per una connessione sicura.
always
Le richieste per un URL corrispondente a questo gestore che non utilizzano HTTPS vengono
vengono reindirizzati automaticamente all'URL HTTPS con lo stesso percorso. Termine di ricerca
vengono conservati per il reindirizzamento.
Il server web di sviluppo non supporta le connessioni HTTPS. Ignora il parametro secure, pertanto i percorsi destinati all'utilizzo con HTTPS possono essere testati utilizzando connessioni HTTP standard al server web di sviluppo.
A
scegliere come target una specifica versione dell'app utilizzando
REGION_ID.r.appspot.com
dominio, sostituisci i punti che generalmente separano
i componenti di sottodominio dell'URL con la stringa "-dot-",
ad esempio: https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com
L'accesso e la disconnessione dall'Account Google vengono sempre eseguiti utilizzando un
connessione sicura, non correlata al modo in cui gli URL dell'applicazione
configurato.
static_dir
Facoltativo. Il percorso della directory contenente i file statici, dalla directory principale dell'applicazione. Tutto ciò che segue la fine del
pattern url corrispondente viene aggiunto a
static_dir per formare il percorso completo del file richiesto.
Ogni file nella directory statica viene pubblicato utilizzando il tipo MIME che
corrisponde alla relativa estensione del nome file a meno che non venga sostituito dal
dell'impostazione mime_type della directory. Tutti i file nel
una determinata directory vengono caricati come file statici
nessuno di questi può essere eseguito come script.
Tutti i file in questa directory vengono caricati con la tua app in formato statico
. App Engine archivia e pubblica i file statici separatamente
dai file della tua app. Per impostazione predefinita, i file statici non sono disponibili nel file system dell'app. Questa opzione può essere modificata impostando il application_readable su true.
Esempio:
handlers:# All URLs beginning with /stylesheets are treated as paths to# static files in the stylesheets/ directory.-url:/stylesheetsstatic_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 costruzione del percorso del file. Puoi utilizzarlo al posto di
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/\1upload:static/.*\.(gif|png|jpg)$# ...
App Engine archivia e pubblica i file statici separatamente
dai file dell'applicazione. I file statici non sono disponibili in
del file system dell'applicazione per impostazione predefinita. Questo valore può essere modificato impostando su true l'opzione application_readable.
I file statici non possono essere gli stessi dei file di codice dell'applicazione.
Se un percorso file statico corrisponde a un percorso di 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 per tutti
file a cui fa riferimento questo gestore. Questo è necessario
perché l'handler non può determinare quali file nella directory
dell'applicazione corrispondono ai pattern url e
static_files specificati. I file statici vengono caricati
e vengono gestiti separatamente dai file dell'applicazione. L'esempio
riportato sopra potrebbe utilizzare il seguente pattern upload:
archives/(.*)/items/(.*)
url
Elemento obbligatorio in handlers. Il pattern URL, come
un'espressione regolare. L'espressione può contenere raggruppamenti a cui fare riferimento nel percorso del file dello script con i riferimenti incrociati delle espressioni regolari. Ad esempio:
/profile/(.*)/(.*) corrisponde all'URL
/profile/edit/manager e utilizza
edit e manager come primo e secondo
e i raggruppamenti.
Il pattern URL presenta alcune differenze di comportamento se utilizzato con i seguenti elementi:
Utilizza un prefisso URL. Il pattern di espressioni regolari non deve contenere agrupamenti se utilizzato con l'elemento static_dir. Tutti
Gli URL che iniziano con questo prefisso vengono gestiti da questo gestore, utilizzando
la porzione dell'URL che segue il prefisso come parte del percorso del file.
Un gestore di pattern di file statici associa un pattern URL ai percorsi dei file statici caricati con l'applicazione. Il pattern URL è regolare
può definire raggruppamenti di espressioni regolari da utilizzare nel
costruzione del percorso del file. Puoi utilizzarlo al posto di
static_dir per mappare file specifici in una directory
senza dover mappare l'intera directory.
Ridimensionare gli elementi
Gli elementi nella tabella seguente configurano la scalabilità dell'applicazione. Per saperne di più sulla scalabilità delle app App Engine, consulta Tipi di scalabilità.
Elemento
Descrizione
automatic_scaling
Facoltativo. Applicabile solo per le applicazioni che utilizzano una
classe
di istanze F1 o superiore.
Specifica questo elemento per modificare le impostazioni predefinite della scalabilità automatica.
come l'impostazione dei livelli minimo e massimo per il numero di istanze,
latenza e 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
disattiva l'impostazione.
Questo parametro specifica il numero massimo di istanze per l'applicazione
Motore da creare per questa versione del modulo. È utile per limitare
solo i costi di un modulo.
min_instances
Facoltativo. Il numero minimo di istanze da creare per App Engine per questa versione del modulo. Queste istanze pubblicano il traffico quando arrivano le richieste e continuano a farlo anche quando vengono avviate istanze aggiuntive in base alle esigenze 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 delle istanze
Ridurre i costi se non vengono gestite richieste. Tieni presente che stai
addebitato per il numero di istanze specificato
che ricevono traffico o meno.
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 ulteriormente il numero di istanze inattive
gradualmente quando i livelli di carico tornano alla normalità dopo un picco. Questo
consente alla tua applicazione di mantenere un rendimento costante
delle fluttuazioni nel carico delle richieste, ma aumenta anche il numero di
di Compute Engine (e conseguenti costi di esecuzione) durante tali periodi
carico di lavoro.
Un valore massimo basso mantiene bassi i costi di gestione, ma può peggiorare le prestazioni in presenza di livelli di carico volatili.
Nota:per tornare ai livelli normali dopo un
un picco di carico, il numero di istanze inattive può superare temporaneamente
il valore massimo specificato. Tuttavia, non ti verranno addebitati costi aggiuntivi
più istanze rispetto al numero massimo 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
gestire il traffico attuale delle applicazioni in base alla scalabilità
impostazioni come target_cpu_utilization e
target_throughput_utilization. L'impostazione 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ù altre 2 per min_idle_instances).
Tieni presente che ti viene addebitato il costo per il numero di istanze specificate, indipendentemente dal fatto che ricevano o meno traffico. Tieni presente che:
Un numero minimo ridotto consente di ridurre i costi di gestione durante i periodi di inattività, ma significa che potrebbero essere disponibili meno istanze immediatamente per rispondere a un picco di carico improvviso.
Un valore minimo elevato ti consente di preparare l'applicazione per picchi rapidi nel carico delle richieste. App Engine mantiene il minimo
di istanze in esecuzione per gestire le richieste in entrata. Ti viene addebitato il numero di istanze specificate, indipendentemente dal fatto che gestiscano o meno le richieste.
Se imposti un numero minimo di istanze inattive, latenza in sospeso
avrà meno impatto sulle prestazioni della tua applicazione.
target_cpu_utilization
Facoltativa. Specifica un valore compreso tra 0,5 e 0,95. Il valore predefinito è
0.6.
Questo parametro specifica
la soglia di utilizzo della CPU alla quale le nuove istanze
iniziato a gestire il traffico, consentendoti di bilanciare
le prestazioni e i costi, con valori più bassi che aumentano le prestazioni e
un aumento dei costi e valori più alti che riducono il rendimento,
e la riduzione dei costi. Ad esempio, il valore 0,7 significa che
vengono avviate quando l'utilizzo della CPU raggiunge 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
di richieste in parallelo raggiunge un valore uguale a
max_concurrent_requests volte
target_throughput_utilization, lo scheduler prova
per avviare una nuova istanza.
max_concurrent_requests
Facoltativo. Il numero di richieste in parallelo che un'istanza con scalabilità automatica può accettare prima che lo scheduler generi una nuova istanza (valore predefinito: 10, valore massimo: 1000).
Utilizzato con target_throughput_utilization per
specificare quando viene avviata una nuova istanza a causa di richieste simultanee.
Quando il numero di richieste in parallelo raggiunge un valore uguale a
max_concurrent_requests volte
target_throughput_utilization, lo scheduler prova a
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 singolo thread. Un valore
meno di 10, è probabile che un numero maggiore di istanze
del necessario per un'app threadsafe, con possibili conseguenze
costi inutili.
Se questa impostazione è troppo alta, l'API potrebbe essere aumentata
una latenza di pochi millisecondi. Tieni presente che il programmatore 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 rimanere in coda in attesa prima di avviare istanze aggiuntive per gestire le richieste in modo da ridurre la latenza in attesa. Quando questo
soglia è stata raggiunta, è un segnale di fare lo scale up e
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 avviate nuove istanze.
Un valore massimo basso significa che App Engine avvierà nuove istanze
per le richieste in attesa, migliorando il rendimento e aumentando
i costi di gestione.
Un valore massimo elevato significa che gli utenti potrebbero attendere più a lungo per la pubblicazione delle loro richieste (se ci sono richieste in attesa e non sono disponibili istanze inattive per gestirle), ma il costo di esecuzione dell'applicazione sarà inferiore.
min_pending_latency
Un elemento facoltativo che puoi impostare per specificare la quantità minima
tempo in cui App Engine deve consentire l'attesa di una richiesta
in attesa prima di avviare una nuova istanza per gestirla.
Specificare un valore può ridurre i costi di gestione, ma aumentare il tempo
e gli utenti devono attendere
la risposta alle loro richieste.
Per le app gratuite, il valore predefinito è 500ms. Per le app pagate, il valore predefinito è 0.
Questo elemento funziona insieme all'elemento max_pending_latency
per determinare quando App Engine crea nuove istanze.
Se sono presenti richieste in attesa in coda:
Meno del valore di min_pending_latency specificato,
App Engine non creerà nuove istanze.
Più di max_pending_latency, App Engine
proverà a creare una nuova istanza.
Tra l'ora specificata da min_pending_latency
e max_pending_latency, App Engine tenterà di riutilizzare un'istanza esistente. Se nessuna istanza è in grado di elaborare la richiesta prima di max_pending_latency, App Engine creerà una nuova istanza.
Le applicazioni che utilizzano
istanza
di B1 o superiore, deve specificare questo elemento oppure
manual_scaling.
Questo elemento consente la scalabilità di base delle classi di istanza B1 e superiori,
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
Facoltativa. L'istanza verrà arrestata per questo periodo di tempo dopo
che riceve l'ultima richiesta. Il valore predefinito è 5 minuti
(5m).
Esempio
basic_scaling:max_instances:11idle_timeout:10m
manual_scaling
Le applicazioni che utilizzano
istanza
di B1 o superiore, deve specificare questo elemento oppure
basic_scaling.
Questo elemento consente la scalabilità manuale delle classi di istanze B1 e successive
e può contenere il seguente elemento:
instances
Il numero di istanze da assegnare al servizio all'inizio.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2024-10-15 UTC."],[],[]]
