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 quando crei l'app. Il codice non corrisponde a un paese o a una provincia, anche se alcuni ID regione possono sembrare simili ai codici di paesi e province di uso comune. Per le app create dopo febbraio 2020, REGION_ID.r è incluso negli URL di App Engine. Per le app esistenti create prima di questa data, l'ID regione è facoltativo nell'URL.
Configura le impostazioni dell'app App Engine in app.yaml
di configurazione del deployment. Il file di configurazione deve specificare almeno una voce runtime.
Ogni servizio
nella tua app ha il proprio file app.yaml, che funge da descrittore per
e deployment continuo. 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. Per scoprire di più su come strutturare più servizi nella tua app, vedi
Strutturare i servizi web in App Engine.
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. I riferimenti a ritroso alle corrispondenze raggruppate (ad es. \1)
sono supportati, così come queste estensioni Perl: \w \W \s \S \d \D.
Esempio
Di seguito è riportato un esempio di file app.yaml:
Elementi di runtime e app
Elemento
Descrizione
build_env_variables
Facoltativo. Se utilizzi un runtime che supporta
buildpack, puoi
definire le variabili di ambiente di compilazione nel
file app.yaml.
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 i 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 su 10 minuti.
Facoltativo.
Puoi definire le variabili di ambiente nel file app.yaml
per renderle disponibili alla tua app. Assicurati che la chiave in 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.
error_handlers
Facoltativo.
Utilizzato per configurare pagine di errore personalizzate che vengono restituite per diverse
tipi di errori.
Questo elemento può contenere i seguenti elementi:
error_code
Facoltativo. error_code può essere uno dei seguenti:
Viene pubblicato se viene raggiunta una scadenza prima di ricevere una risposta da
la tua app.
Il codice errore è facoltativo; se non è specificato, il file specificato è la risposta di errore predefinita per l'app.
file
Ogni voce di file indica un file statico che deve essere pubblicato in
della risposta di errore generico. Se specifichi
Elemento file senza un corrispondente
Elemento error_code, il file statico sarà il valore predefinito
pagina di errore relativa alla tua app.
I dati di errore personalizzati devono essere inferiori a 10 kilobyte.
Facoltativo.
Un elenco di pattern 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, come immagini, CSS o JavaScript.
Facoltativo.
Le applicazioni devono attivare questi servizi prima di poter ricevere richieste in entrata. Puoi abilitare il servizio per un'app
includendo una sezione inbound_services nella
app.yaml file.
I seguenti valori sono disponibili in base al
scaling del servizio:
Scalabilità automatica
F1, F2, F4 e F4_1G
Predefinito:F1
Facoltativamente, utilizza la
Elemento automatic_scaling per modificare il valore predefinito
impostazioni per la scalabilità automatica, come il valore minimo e massimo
numero di istanze, latenza e 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 il rendimento della
tua 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.
runtime
Obbligatorio. Il nome dell'ambiente di runtime utilizzato dalla tua
app. Ad esempio, per specificare l'ambiente di runtime, utilizza:
service
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 durata combinata
VERSION-dot-SERVICE-dot-PROJECT_ID, dove VERSION è il nome di
la tua versione, SERVICE è il nome del tuo servizio, e PROJECT_ID
è l'ID progetto, non può contenere più di 63 caratteri e non può
iniziano o terminano 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
service_account
Facoltativo. L'elemento service_account ti consente di specificare un
account di servizio specifico per la versione come identità per la versione. L'account di servizio specificato viene utilizzato per accedere ad altri servizi Google Cloud ed eseguire attività.
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 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
Predefinito. Le richieste agli indirizzi IP interni vengono inviate tramite
il connettore di accesso VPC serverless
alla rete VPC connessa. Richieste a IP esterno
indirizzi IP vengono inviati alla rete internet pubblica.
all-traffic
Tutte le richieste vengono inviate tramite il connettore Accesso VPC serverless alla rete VPC collegata.
L'elemento handlers 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 per file statici, directory statiche, script in runtime diversi da Node.js e altre impostazioni.
Elemento
Descrizione
expiration
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
se viene richiesto per la prima volta. Se omesso, viene utilizzato il valore default_expiration dell'applicazione. Vedi Cache
data di scadenza per ulteriori dettagli.
http_headers
Facoltativo. Puoi impostare le intestazioni HTTP per le risposte degli elaboratori di directory o file statici.
Se devi impostare le intestazioni HTTP
nei gestori script, devi farlo nel
codice dell'app. 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 le risorse multiorigine
condivisione (CORS), ad esempio l'accesso a file ospitati da un altro
dell'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 della risposta:
Suggerimento: per consentire a tutti di accedere ai tuoi asset, puoi:
utilizza il carattere jolly '*', anziché
https://mygame.uc.r.appspot.com.
mime_type
Facoltativo. Se specificato, tutti i file pubblicati da questo gestore saranno
pubblicati utilizzando il tipo MIME specificato. Se non specificato, il tipo MIME
per un file, verrà ricavata 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.
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 Spostato in modo permanente.
302
Codice di risposta trovato.
303
Vedi Altro codice di risposta.
307
Codice di risposta del reindirizzamento temporaneo.
Quando la richiesta di un utente viene reindirizzata, viene impostato il codice di stato HTTP
al valore dell'attributo redirect_http_response_code
. Se il parametro non è presente, verrà restituito il valore 302.
script
Facoltativo.
Specifica che le richieste all'handler specifico devono avere come target la tua app. L'unico valore accettato per l'elemento script è auto perché tutto il traffico viene pubblicato utilizzando il comando entrypoint. Per utilizzare gli handler statici, almeno uno dei
tuoi handler deve contenere la riga script: auto
o definire un elemento entrypoint per il deployment.
secure
Facoltativo. Qualsiasi gestore di URL può utilizzare l'impostazione secure,
inclusi i gestori di file statici. L'elemento secure ha quanto segue
valori possibili:
optional
Sia le richieste HTTP che quelle HTTPS con URL corrispondenti 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
è l'impostazione predefinita quando secure non viene fornito per un
.
never
Le richieste di un URL che corrispondono a questo gestore e che utilizzano HTTPS vengono reindirizzate automaticamente all'URL HTTP equivalente. Quando un utente
La richiesta HTTPS viene reindirizzata a una richiesta HTTP
vengono rimossi dalla richiesta. In questo modo
all'utente di inviare accidentalmente dati di query su una piattaforma
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. I parametri di query vengono conservati per il reindirizzamento.
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 dopo la fine
il 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 della directory specificata vengono caricati come file statici e nessuno di questi può essere eseguito come script.
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. Pattern URL
l'espressione regolare può definire i 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)$# ...
I file statici non possono essere uguali ai file di codice dell'applicazione.
upload
Facoltativo. Un'espressione regolare che corrisponde ai percorsi dei file per tutti
file a cui fa riferimento questo gestore. Questa operazione è necessaria
perché il gestore non è in grado di determinare quali file nella tua applicazione
della directory corrispondano agli attributi urlstatic_files pattern. I file statici vengono caricati e 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 che può contenere raggruppamenti. Ad esempio:
/profile/(.*)/(.*) corrisponde all'URL
/profile/edit/manager e utilizza
edit e manager come primo e secondo
raggruppandoli.
Il pattern URL presenta alcune differenze di comportamento se utilizzato con
i seguenti elementi:
Utilizza un prefisso URL. Il pattern espresso normale non deve contenere
raggruppamenti quando 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
del percorso del file. Puoi utilizzarlo al posto di
static_dir per mappare file specifici in una directory
senza dover mappare l'intera directory.
Elementi di scalabilità
Gli elementi nella tabella seguente configurano la scalabilità dell'applicazione. In caso contrario
del tipo specificato, la scalabilità automatica è impostata per impostazione predefinita.
Per scoprire di più sulla scalabilità delle app App Engine, consulta
Tipi di scalabilità.
Elemento
Descrizione
automatic_scaling
Facoltativo. Applicabile solo per le applicazioni che utilizzano un'etichetta
istanza
F1 o superiore.
Specifica questo elemento per modificare le impostazioni predefinite per la scalabilità automatica, come l'impostazione di livelli minimi e massimi per il numero di istanze, la latenza e le connessioni simultanee per un servizio.
Questo elemento può contenere i seguenti elementi:
max_instances
Facoltativa. 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 che App Engine deve
per questa versione del modulo. Queste istanze gestiscono il traffico quando
e continuano a gestire il traffico anche
e vengono avviate altre istanze in base alle necessità per gestire il traffico.
Specifica un valore compreso tra 0 e 1000. Puoi impostare il parametro sul valore 0 per consentire il ridimensionamento a 0 istanze al fine di ridurre i costi quando non vengono inviate 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 il numero di istanze inattive in modo più graduale quando i livelli di carico tornano alla normalità dopo un picco. In questo modo,
l'applicazione mantiene prestazioni costanti durante le oscillazioni del carico delle richieste, ma aumenta anche il numero di istanze inattive (e i conseguenti costi di gestione) durante questi periodi di carico elevato.
Un valore massimo basso riduce i costi di gestione, ma può ridurne la qualità
le prestazioni a fronte di livelli di carico volatile.
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 pronto a gestire il traffico
per questa versione.
App Engine calcola il numero di istanze necessarie per gestire il traffico corrente dell'applicazione in base alle impostazioni di scalabilità 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 minimo basso aiuta a mantenere bassi i costi di esercizio in caso di inattività
ma significa che un numero minore di istanze potrebbe
disponibili per rispondere a un improvviso picco di carico.
Un minimo elevato ti consente di preparare l'applicazione per
dei picchi nel carico delle richieste. App Engine mantiene il minimo
di istanze in esecuzione per gestire le richieste in entrata. Tu
il costo viene addebitato per il numero di istanze specificato,
non stanno gestendo 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, un valore di 0,7 indica che le nuove istanze verranno avviate quando l'utilizzo della CPU raggiunge il 70%.
target_throughput_utilization
Facoltativo. Specifica un valore compreso tra 0,5 e 0,95. L'impostazione predefinita è
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 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 con 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 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 inferiore a 10 potrebbe comportare la creazione di più istanze di quante siano necessarie per un'app sicura per i thread e potrebbe comportare costi non necessari.
Se questa impostazione è troppo alta, l'API potrebbe essere aumentata
una latenza di pochi millisecondi. Tieni presente che lo scheduler potrebbe generare una nuova istanza prima
viene raggiunto il numero massimo effettivo di richieste.
max_pending_latency
Il periodo di tempo massimo che App Engine deve consentire di inviare una richiesta
di attendere in coda prima di avviare istanze aggiuntive
per gestire le richieste in modo da ridurre
latenza in sospeso. Quando viene raggiunta questa
soglia, viene attivato un indicatore di aumento e si verifica
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 le loro richieste
la pubblicazione (se ci sono richieste in attesa e non
di Compute Engine, ma la tua applicazione costerà meno
vengono eseguiti tutti i test delle unità.
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
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:
Se il valore è inferiore a 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 una
classe
di istanze di B1 o versioni successive devono specificare questo elemento o
manual_scaling.
Questo elemento consente la scalabilità di base delle classi di istanze B1 e successive e può contenere i seguenti elementi:
max_instances
Obbligatorio. Il numero massimo di istanze che App Engine deve creare per questa versione del servizio. Questa opzione è 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 una
classe
di istanze di B1 o versioni successive devono specificare questo elemento o
basic_scaling.
Questo elemento consente la scalabilità manuale delle classi di istanza B1 e superiori,
e può contenere il seguente elemento:
instances
Il numero di istanze da assegnare al servizio all'avvio.
