Python 2.7 ha raggiunto la fine del supporto
e verrà ritirato
il 31 gennaio 2026. Dopo il ritiro, non potrai eseguire il deployment di applicazioni Python 2.7, anche se la tua organizzazione ha utilizzato in precedenza un criterio dell'organizzazione per riattivare i deployment di runtime legacy. Le tue applicazioni Python 2.7 esistenti continueranno a essere eseguite e a ricevere traffico dopo la
data di ritiro. Ti consigliamo di eseguire la migrazione all'ultima versione supportata di Python.
Riferimento app.yaml di App Engine
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
ID regione
Il REGION_ID è un codice abbreviato che Google assegna
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 App Engine. Per le app esistenti create prima di questa data, l'ID regione è facoltativo nell'URL.
Configura le impostazioni dell'app App Engine nel file app.yaml.
Questo file specifica la corrispondenza tra i percorsi URL e i gestori delle richieste e i file statici.
Il file app.yaml contiene anche informazioni sul codice della tua app, come il runtime e l'identificatore dell'ultima versione.
Ogni servizio
nella tua app ha il proprio file app.yaml, che funge da descrittore per la sua
implementazione. Prima di poter creare ed eseguire il deployment dei file app.yaml per servizi aggiuntivi all'interno dell'app, devi prima creare il file app.yaml per il servizio default.
Una direttiva script: può contenere un percorso file che termina con .py, il che significa che lo script utilizza CGI, o 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 il carattere cancelletto (#)
viene ignorata:
# This is a comment.
I pattern di URL e percorsi dei file utilizzano la sintassi delle espressioni regolari estese POSIX, escludendo gli elementi di confronto e le classi di confronto. Sono supportati i riferimenti inversi alle corrispondenze raggruppate (ad es. \1), così come le seguenti estensioni Perl: \w \W \s \S \d \D.
Elementi di runtime e dell'app
Elemento
Descrizione
application
L'approccio consigliato è 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:
gcloudappdeploy--project[YOUR_PROJECT_ID]
Per ulteriori informazioni sull'utilizzo di questi comandi, consulta
Deployment dell'app.
L'ID applicazione è l'ID progetto della console Google Cloud che hai specificato quando hai creato l'applicazione in Google Cloud console.
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 supportato più recente 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 numeri interi grandi e ben distribuiti
abbastanza piccoli da essere rappresentati da numeri in virgola mobile a 64 bit.
legacy
L'opzione legacy verrà ritirata in una release futura e verrà
rimossa definitivamente. Per ulteriori informazioni, consulta il post del blog che annuncia questa
modifica.
builtins
Facoltativo.
L'SDK Python 2 include una serie di gestori integrati per le funzioni comuni delle applicazioni. L'istruzione builtins
ti consente di includere gestori specifici in app.yaml.
Attiva
Appstats all'indirizzo /_ah/stats/, che puoi utilizzare per
misurare il rendimento della tua applicazione. Per utilizzare Appstats,
devi anche
installare il registratore di eventi.
deferred
Attiva il gestore differito alle ore /_ah/queue/deferred.
Questo componente integrato consente agli sviluppatori di utilizzare deferred.defer()
per semplificare la creazione di attività di Task Queue.
remote_api
Attiva l'intent integrato remote_api in
/_ah/remote_api/. Questo intent integrato consente alle applicazioni
remote con le credenziali appropriate di accedere al datastore
da remoto.
Esempio:
builtins:-deferred:on-appstats:on
La direttiva builtins è un'istanza speciale della direttiva
includes. Ogni direttiva builtin
equivale, in Python, a una direttiva includes con
un percorso espanso. Ad esempio:
Quando utilizzi builtins nel file app.yaml,
i gestori definiti nel file include.yaml integrato
hanno la precedenza su quelli definiti nel file app.yaml. Tuttavia, se includi un
file che utilizza builtins o includes,
i gestori vengono aggiunti in base all'ordine della gerarchia di inclusione. In altre
parole, i gestori degli include "padre" vengono aggiunti prima
dei componenti integrati degli include "figlio" e così via.
Ad esempio, considera il seguente app.yaml, che utilizza i gestori appstats integrati:
L'ordine di inserimento della clausola builtins in un file .yaml non modifica il comportamento.
default_expiration
Facoltativo. Imposta un periodo di memorizzazione nella cache predefinito globale per tutti i gestori di file statici per 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 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 dopo la prima richiesta del file. Se omesso,
il server di produzione imposta la scadenza a 10 minuti.
Facoltativo.
Puoi definire le variabili di ambiente nel file app.yaml
per renderle disponibili alla tua app. Assicurati che la chiave in Variabile/i di ambiente corrisponda all'espressione "[a-zA-Z_][a-zA-Z0-9_]*" (inizia con una lettera dell'alfabeto o "_" seguita da qualsiasi carattere alfanumerico o "_").
Le variabili di ambiente precedute dal prefisso
GAE sono riservate all'uso di sistema e non sono consentite nel file
app.yaml.
Queste variabili saranno disponibili nel dizionario os.environ:
Viene pubblicato se viene raggiunta una scadenza prima che la tua app risponda.
error_code è facoltativo; se non viene specificato, il file
fornito è 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
servendo file statici caricati con il codice, come immagini, CSS o JavaScript.
Facoltativo.
La direttiva includes ti consente di includere il
file di configurazione per qualsiasi libreria o servizio in tutta l'applicazione. Ad esempio, potresti 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
rimanda a un file.
Rispetto alla directory dell'applicazione, nota anche come
basepath. Il percorso di base e il percorso vengono risolti in un file.
Relativo al file che includeva il file corrente. La posizione del file di riferimento e il percorso di inclusione vengono risolti nel file incluso.
Se la direttiva include specifica una directory, App Engine cerca in quella directory un file denominato include.yaml. Se la direttiva include è un file, viene incluso quel file specifico. L'utilizzo di includes recupera
solo i seguenti tipi di direttive dal file di destinazione (se
presenti):
I pattern skip_files inclusi vengono aggiunti a quelli
inclusi in app.yaml o all'elenco predefinito se non è presente
un 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 richieste
in entrata. Puoi abilitare il servizio per un'app Python 2
includendo una sezione inbound_services nel file
app.yaml.
A seconda dello scaling del servizio, sono disponibili i seguenti valori:
Scalabilità automatica
F1, F2, F4, F4_1G
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 a quello
predefinito di 10. Per determinare il valore ottimale,
aumentalo gradualmente e monitora il rendimento della tua
applicazione.
Scalabilità di base e manuale
B1, B2, B4, B4_1G, B8
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 Python 2.7 include alcune librerie di terze parti. Alcuni sono disponibili per impostazione predefinita, altri solo
se configurati. Puoi specificare la versione da utilizzare
specificando i valori name e version.
Tieni presente che quando specifichi latest, l'SDK determina
l'ultima versione 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 nuovamente il deployment.
Se stai sviluppando un'applicazione che non ha ancora utenti, non
devi monitorare le nuove versioni. Tuttavia, se la tua applicazione viene
utilizzata attivamente, fai attenzione: potresti rimanere sorpreso dal 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 gcloud CLI, utilizza 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.
Supportato solo da gcloud CLI o da plug-in basati su 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 tuo 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 ogni servizio
e per ogni 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 servizi dichiarati come moduli, ad esempio:
module:service-name
service_account
Facoltativo. L'elemento service_account consente di specificare un service account gestito dall'utente come identità per la versione. Il 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 espressioni regolari. Qualsiasi nome file che corrisponde a una delle espressioni regolari
viene omesso dall'elenco dei file da caricare quando l'applicazione
viene caricata. I nomi file sono relativi alla directory del progetto.
Il pattern predefinito esclude i file di backup di Emacs con nomi del tipo
#...# e ...~, .pyc e
.pyo, i file in una directory di controllo delle revisioni RCS e i file nascosti di Unix con nomi che iniziano con un punto
(.).
Per estendere l'elenco di espressioni regolari riportato sopra, copia e incolla l'elenco
in app.yaml e aggiungi le tue espressioni
regolari. Ad esempio, per ignorare i file i cui nomi terminano con
.bak oltre ai pattern predefiniti, aggiungi una voce
come questa per skip_files:
Per ignorare una directory completa, aggiungi il nome della directory all'elenco. Ad esempio, per ignorare una directory denominata logs,
aggiungi la seguente riga a quelle descritte in precedenza:
skip_files:-logs/
threadsafe
Obbligatorio.
Configura l'applicazione per utilizzare le richieste simultanee. Se utilizzi la
libreria threading di
Python, i dati thread-local, 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 i gestori di script siano
WSGI. ovvero ogni script deve essere specificato in una
direttiva script: utilizzando un percorso del modulo Python,
con i nomi dei pacchetti separati da punti. L'ultimo componente di una
direttiva script: che utilizza un percorso di modulo Python
è il nome di una variabile globale nel service:. Questa variabile
deve essere un'app WSGI e per convenzione viene chiamata app.
version
L'approccio consigliato è rimuovere l'elemento version
dal file app.yaml e utilizzare invece un
flag della riga di comando per specificare l'ID versione:
Per ulteriori informazioni sull'utilizzo di questo comando, consulta
Deployment dell'app.
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
dalle istanze numeriche, che vengono sempre specificate da un numero. In questo modo
si evita l'ambiguità con URL come
123-dot-my-service.uc.r.appspot.com, che possono essere interpretati
in due modi: se esiste la versione "123", il target sarà la versione "123"
del servizio specificato. Se questa versione non esiste, la destinazione
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
menzionata nel file app.yaml caricato è la
versione creata o sostituita dal caricamento. Un amministratore
può modificare la versione dell'applicazione che gestisce il traffico utilizzando
Google Cloud consolee può anche
testare
altre versioni prima di configurarle per ricevere traffico.
vpc_access_connector
Facoltativo.
Configura l'applicazione in modo che utilizzi un connettore di accesso VPC serverless, consentendole di inviare richieste alle risorse interne nella tua rete VPC. Per saperne di più, 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. Il
egress_setting può essere uno dei seguenti:
private-ranges-only
Predefinito. 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 a internet pubblico.
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.
La tabella seguente elenca 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 è 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 l'archiviazione di codice e dati statici.
Facoltativo.
Il periodo di tempo per 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 le ore, m per i
minuti e s per i secondi. Ad esempio,
"4d 5h" imposta la scadenza della cache a 4 giorni e 5 ore dopo
la prima richiesta del file. Se omesso, viene utilizzato
default_expiration dell'applicazione. Per ulteriori dettagli, consulta la sezione Scadenza
della cache.
http_headers
Facoltativo. Puoi impostare le intestazioni
HTTP per le risposte dei gestori di file statici o directory. Se devi impostare le intestazioni HTTP
nei tuoi gestori script, devi farlo nel codice
della tua app. Per informazioni su quali intestazioni delle risposte influenzano la memorizzazione nella cache,
vedi Memorizzazione nella cache
di contenuti statici.
Un utilizzo importante di questa funzionalità è il supporto della condivisione delle risorse tra origini diverse (CORS), ad esempio l'accesso a 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 effettuare una chiamata
XMLHttpRequest JavaScript a myassets, l'operazione non
andrà a buon fine a meno che il gestore di myassets non restituisca un'intestazione
di risposta Access-Control-Allow-Origin: contenente
il valore http://mygame.uc.r.appspot.com.
Ecco come fare in modo che il gestore dei file statici restituisca il valore
dell'intestazione della risposta richiesta:
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
per un file verrà derivato 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:
Quando la richiesta di un utente viene reindirizzata, il codice di stato HTTP verrà impostato
sul valore del parametro
redirect_http_response_code. Se il parametro non è presente, verrà restituito 302.
script
Facoltativo.
Specifica il percorso dello script dalla directory principale 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\.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 Python, ad esempio package.module.app, che rimanda a un'applicazione WSGI. L'ultimo componente di una direttiva script:
che utilizza un percorso di modulo Python è il nome di una variabile
globale nel modulo: questa variabile deve essere un'app WSGI e per
convenzione viene solitamente chiamata app.
Nota: proprio come per un'istruzione Python import, ogni
sottodirectory che è 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
Le richieste HTTP e HTTPS con URL che corrispondono al gestore
vanno a buon fine senza reindirizzamenti. L'applicazione può esaminare la richiesta
per determinare quale protocollo è stato utilizzato e rispondere di conseguenza. Questo
è il valore predefinito quando secure non viene fornito per un
gestore.
never
Le richieste di un URL corrispondente a questo gestore che utilizza HTTPS vengono
reindirizzate automaticamente all'URL HTTP equivalente. Quando la richiesta HTTPS di un utente viene reindirizzata per diventare una richiesta HTTP, i parametri di ricerca vengono rimossi dalla richiesta. In questo modo, un utente non invierà accidentalmente dati di query tramite una connessione non sicura destinata a una connessione sicura.
always
Le richieste di un URL che corrisponde a questo gestore e che non utilizza HTTPS vengono reindirizzate automaticamente all'URL HTTPS con lo stesso percorso. I parametri
della query vengono conservati per il reindirizzamento.
Il server web di sviluppo non supporta le connessioni HTTPS. Ignora
il parametro secure, quindi i percorsi destinati all'uso
con HTTPS possono essere testati utilizzando connessioni HTTP regolari al
server web di sviluppo.
L'accesso e la disconnessione degli Account Google vengono sempre eseguiti utilizzando una
connessione sicura, indipendentemente dalla configurazione degli URL dell'applicazione.
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 sua 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 di questi 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. Per impostazione predefinita, i file statici non sono disponibili nel file system dell'app. Puoi modificare questa impostazione impostando 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:/stylesheetsstatic_dir:stylesheets# ...
static_files
Facoltativo. Un gestore di pattern di file statici associa un pattern URL a
percorsi a file statici caricati con l'applicazione. L'espressione regolare del pattern URL può definire i raggruppamenti di espressioni regolari da utilizzare nella creazione del percorso del file. Puoi utilizzare questo valore 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/\1upload:static/.*\.(gif|png|jpg)$# ...
App Engine archivia e pubblica i file statici separatamente
dai file dell'applicazione. Per impostazione predefinita, i file statici non sono disponibili nel file system dell'applicazione. Puoi modificare questa impostazione impostando
l'opzione application_readable su true.
I file statici non possono essere uguali ai file di codice dell'applicazione.
Se un percorso di 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 i file a cui farà riferimento questo gestore. Ciò è necessario
perché il gestore non può 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 del file allo script con riferimenti
inversi dell'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 se utilizzato con i seguenti elementi:
Utilizza un prefisso URL. Il pattern dell'espressione regolare non deve contenere
raggruppamenti quando viene utilizzato con l'elemento static_dir. Tutti gli URL che iniziano con questo prefisso vengono gestiti da questo gestore, utilizzando la parte dell'URL dopo il prefisso come parte del percorso del file.
Un gestore di pattern di file statici associa un pattern URL a percorsi di
file statici caricati con l'applicazione. L'espressione regolare del pattern URL può definire i raggruppamenti di espressioni regolari da utilizzare nella costruzione del percorso del file. Puoi utilizzare questo valore anziché
static_dir per mappare file specifici in una struttura
di directory senza mappare l'intera directory.
Elementi di scalabilità
Gli elementi nella tabella seguente configurano la scalabilità dell'applicazione. Per saperne di più
su come vengono scalate le app App Engine, consulta
Tipi di scalabilità.
Elemento
Descrizione
automatic_scaling
Facoltativo. Applicabile solo alle applicazioni che utilizzano una
classe
di istanza F1 o superiore.
Specifica questo elemento per modificare le impostazioni predefinite per la scalabilità automatica,
ad esempio impostando i 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
disattiva l'impostazione.
Questo parametro specifica il numero massimo di istanze che App
Engine deve creare per questa versione del modulo. Ciò è utile per limitare
i costi di un modulo.
min_instances
(Facoltativo) Il numero minimo di istanze che App Engine deve
creare per questa versione del modulo. Queste istanze gestiscono il traffico quando arrivano le richieste e continuano a farlo anche quando vengono avviate istanze aggiuntive in base alle esigenze di gestione del traffico.
Specifica un valore compreso tra 0 e 1000. Puoi impostare
il parametro sul valore 0 per consentire lo scale-out a 0 istanze per
ridurre i costi quando non vengono gestite richieste. Tieni presente che ti viene addebitato un costo per il numero di istanze specificato, indipendentemente dal fatto che ricevano 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 viene 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ò
aiuta l'applicazione a mantenere prestazioni stabili durante le
fluttuazioni del carico di 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 mantiene i costi di gestione più bassi, ma può peggiorare
le prestazioni in caso di livelli di carico volatili.
Nota:quando si torna ai livelli normali dopo un picco di carico, il numero di istanze inattive può superare temporaneamente il massimo specificato. Tuttavia, non ti verranno addebitati costi per un numero di istanze superiore a quello 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 per gestire il traffico attuale dell'applicazione in base alle impostazioni di scalabilità, ad esempio target_cpu_utilization e target_throughput_utilization. L'impostazione min_idle_instances
specifica il numero di istanze da
eseguire in aggiunta 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ù 2 aggiuntive per min_idle_instances).
Tieni presente che ti viene addebitato il numero di istanze specificato, indipendentemente dal fatto che ricevano traffico o meno. Tieni presente che:
Un valore minimo basso contribuisce a ridurre i costi di gestione durante i periodi di inattività, ma significa che potrebbero essere disponibili meno istanze per rispondere a un improvviso picco di carico.
Un valore minimo elevato consente di preparare l'applicazione per picchi rapidi
nel carico di richieste. App Engine mantiene in esecuzione il numero minimo di istanze per gestire le richieste in entrata. Ti viene addebitato il numero di istanze specificato, indipendentemente dal fatto che gestiscano o meno le richieste.
Se imposti un numero minimo di istanze inattive, latenza in sospeso
avrà un impatto minore sul rendimento 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 in corrispondenza della quale verranno avviate
nuove istanze per gestire il traffico, consentendoti di trovare un equilibrio tra
rendimento e costi. I valori più bassi aumentano il rendimento e
i costi, mentre i valori più alti riducono il rendimento ma
anche i costi. Ad esempio, un valore di 0,7 significa che le nuove
istanze verranno avviate dopo che 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 simultanee. Quando il numero di richieste simultanee raggiunge un valore pari a max_concurrent_requests volte target_throughput_utilization, lo scheduler tenta di avviare una nuova istanza.
max_concurrent_requests
Facoltativo. Il numero di richieste simultanee che un'istanza di 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 simultanee raggiunge un valore pari a
max_concurrent_requests volte
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 singolo thread. Un valore
inferiore a 10 probabilmente comporterà la creazione di più istanze
di quelle necessarie per un'app thread-safe e potrebbe comportare
costi non necessari.
Se questa impostazione è troppo elevata, potresti riscontrare una maggiore latenza
dell'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 istanze aggiuntive
per gestire le richieste in modo da ridurre latenza in sospeso. Quando viene raggiunta questa soglia, viene inviato un segnale di scalabilità verso l'alto, con conseguente aumento del numero di istanze.
Se non è specificato, il valore predefinito è automatic. Ciò significa che
le richieste possono rimanere nella coda in attesa fino a 10 secondi, il
limite di tempo per le richieste in attesa massimo, prima che vengano attivati gli avvii di nuove istanze.
Un valore massimo basso significa che App Engine avvierà nuove istanze
prima per le richieste in attesa, migliorando le prestazioni ma aumentando
i costi di esecuzione.
Un valore massimo elevato significa che gli utenti potrebbero attendere più a lungo prima che le loro richieste
vengano gestite (se ci sono richieste in attesa e nessuna istanza
inattiva per gestirle), ma l'esecuzione dell'applicazione costerà meno.
min_pending_latency
Un elemento facoltativo che puoi impostare per specificare la quantità minima di
tempo che App Engine deve consentire a una richiesta di attendere nella
coda in attesa prima di avviare una nuova istanza per gestirla.
La specifica di un valore può ridurre i costi di esecuzione, ma aumentare il tempo
che gli utenti devono attendere per la gestione delle loro richieste.
Per le app gratuite, il valore predefinito è 500ms. Per le app a pagamento, il valore predefinito è 0.
Questo elemento funziona insieme all'elemento max_pending_latency
per determinare quando App Engine crea nuove istanze.
Se le richieste in attesa sono nella coda:
Inferiore a min_pending_latency specificato,
App Engine non creerà nuove istanze.
Se il valore è superiore a max_pending_latency, App Engine
tenterà di 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.
Questo elemento consente la scalabilità di base delle classi di istanze 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. Questo è utile per limitare i costi
di un servizio.
idle_timeout
(Facoltativo) L'istanza verrà arrestata dopo questo periodo di tempo
dalla ricezione dell'ultima richiesta. Il valore predefinito è 5 minuti
(5m).
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-12-05 UTC."],[],[]]
