Riferimento app.yaml di App Engine

ID regione

Il REGION_ID è un codice abbreviato che Google assegna in base alla regione selezionata durante la creazione dell'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.

Scopri di più sugli ID regione.

Configura le impostazioni dell'app App Engine nel file di configurazione app.yaml. 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 la sua implementazione. Prima di poter creare e implementare file app.yaml per servizi aggiuntivi all'interno della tua app, devi prima creare il file app.yaml per il servizio default. Per scoprire di più sulla strutturazione di più servizi nella tua app, consulta Strutturazione dei servizi web in App Engine.

Sintassi

La sintassi di app.yaml è il formato YAML.

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.

Esempio

Di seguito è riportato un esempio di file app.yaml:

runtime: python313

instance_class: F2

env_variables:
  BUCKET_NAME: "example-gcs-bucket"

handlers:
# Matches requests to /images/... to files in static/images/...
- url: /images
  static_dir: static/images

- url: /.*
  secure: always
  redirect_http_response_code: 301
  script: auto

Elementi di runtime e dell'app

Elemento Descrizione
app_engine_apis

Facoltativo. Se vuoi utilizzare i servizi in bundle legacy di App Engine per i runtime di seconda generazione, imposta questo campo su true.
build_env_variables

Facoltativo. Se utilizzi un runtime che supporta i buildpack, puoi definire le variabili di ambiente di build nel file app.yaml.

Per scoprire di più, consulta la sezione Utilizzare le variabili di ambiente di build.
default_expiration

Facoltativo. Imposta un periodo di memorizzazione nella cache predefinito globale per tutti i gestori di file statici di un'applicazione. Puoi anche configurare una durata della cache per gestori di file statici specifici. Il valore è una stringa di numeri e unità, separati da spazi, dove le unità possono essere d per 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.

Esempio Python: 
runtime: python313

default_expiration: "4d 5h"

handlers:
# ...

Per ulteriori informazioni, vedi Scadenza della cache.

entrypoint

Facoltativo. Esegue l'override del comportamento di avvio predefinito eseguendo il comando entrypoint all'avvio dell'app. Affinché la tua app riceva richieste HTTP, l'elemento entrypoint deve contenere un comando che avvii un server web in ascolto sulla porta 8080.

Se non specifichi entrypoint per il runtime Python, App Engine configura e avvia il web server Gunicorn.

Per saperne di più, consulta Avvio dell'applicazione.
env_variables

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 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.

Per Python, queste variabili sono disponibili nel dizionario os.environ:

env_variables:
          DJANGO_SETTINGS_MODULE: "myapp.settings"

Consulta anche l'elenco delle variabili di ambiente runtime che non possono essere sovrascritte.
error_handlers

Facoltativo. Utilizzato per configurare pagine di errore personalizzate restituite per diversi tipi di errore.

Questo elemento può contenere i seguenti elementi:

error_code
(Facoltativo) error_code può essere uno dei seguenti:
over_quota
Indica che l'app ha superato una quota di risorse
timeout
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.
Esempio 
error_handlers:
  - file: default_error.html

  - error_code: over_quota
    file: over_quota.html
handlers

Facoltativo. 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.

Consulta la sintassi di gestori ed elementi secondari.

inbound_services

Facoltativo. Le applicazioni devono abilitare questi servizi prima di poter ricevere richieste in entrata. Puoi attivare il servizio per un'app includendo una sezione inbound_services nel file app.yaml.

warmup
Attiva le richieste di warmup. Consulta la sezione Configurazione delle richieste di warmup.
Esempio: 
inbound_services:
- warmup
instance_class

Facoltativo. La classe di istanza per questo servizio.

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.

runtime

Obbligatorio. Il nome dell'ambiente di runtime utilizzato dalla tua app. Ad esempio, per specificare l'ambiente di runtime, utilizza: 

runtime: python313
service

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
service_account

Facoltativo. L'elemento service_account consente di specificare un service account specifico della versione come identità per la versione. Il account di servizio specificato viene utilizzato per accedere ad altri servizi Google Cloud ed eseguire attività.

Esempio: 
service_account: [SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com
vpc_access_connector

Facoltativo. Configura l'applicazione in modo che utilizzi un connettore di accesso VPC serverless, consentendo all'applicazione di inviare richieste a risorse interne nella tua rete VPC. Per saperne di più, vedi Connessione a una rete VPC.

name
Valore letterale stringa. Specifica il nome completo del connettore di accesso VPC serverless tra virgolette: 
"projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME"
egress_setting
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.
Esempio 
vpc_access_connector:
  name: "projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME"
  egress_setting: all-traffic

Elemento Gestori

L'elemento handlers 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 file statici, directory statiche, script in runtime diversi da Node.js e altre impostazioni.

Elemento Descrizione
auth_fail_action

Per utilizzare questo elemento, app_engine_apis deve essere impostato su true.

Facoltativo. Descrive l'azione intrapresa quando l'elemento login viene specificato per un gestore e l'utente non ha eseguito l'accesso. Ha due valori possibili:

redirect
Predefinito. L'utente viene reindirizzato alla pagina di accesso Google oppure /_ah/login_required se viene utilizzata l'autenticazione OpenID. Dopo aver eseguito l'accesso o creato un account, l'utente viene reindirizzato all'URL dell'applicazione.
unauthorized
La richiesta viene rifiutata con un codice di stato HTTP 401 e un messaggio di errore.

Se un'applicazione ha bisogno di un comportamento diverso, può implementare la gestione degli accessi degli utenti. Ad esempio, richiedere l'accesso per la directory /profile/ o l'accesso amministratore per la directory /admin/. Per ulteriori informazioni, consulta l'API Users.

Puoi configurare un gestore per rifiutare l'accesso agli URL protetti quando l'utente non ha eseguito l'accesso, anziché reindirizzarlo alla pagina di accesso, aggiungendo auth_fail_action: unauthorized alla configurazione del gestore.

expiration 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 il 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 gestori script, devi farlo nel codice dell'app. Per informazioni su quali intestazioni di risposta influenzano la memorizzazione nella cache, vedi Memorizzazione nella cache di contenuti statici.

Per ulteriori informazioni sulle intestazioni specifiche di App Engine, consulta Intestazioni delle richieste e risposte.

Esempio 
handlers:
- url: /images
  static_dir: static/images
  http_headers:
    X-Foo-Header: foo
    X-Bar-Header: bar value
    vary: Accept-Encoding
  # ...

Supporto CORS

Un utilizzo importante di questa funzionalità è il supporto della condivisione delle risorse tra origini 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 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: 

handlers:
- url: /images
  static_dir: static/images
  http_headers:
    Access-Control-Allow-Origin: https://mygame.uc.r.appspot.com
  # ...

Suggerimento: per consentire a tutti l'accesso ai tuoi asset, puoi utilizzare il carattere jolly '*', anziché https://mygame.uc.r.appspot.com.

login

Per utilizzare questo elemento, app_engine_apis deve essere impostato su true.

Facoltativo. Determina se il gestore URL richiede che l'utente abbia eseguito l'accesso.

Questo elemento ha tre valori possibili:

optional
Predefinito. Non richiede l'accesso dell'utente.
required
Se l'utente ha eseguito l'accesso, il gestore procede normalmente. In caso contrario, viene eseguita l'azione specificata in auth_fail_action.
admin
Come per required, esegue auth_fail_action se l'utente non ha eseguito l'accesso. Inoltre, se l'utente non è un amministratore dell'applicazione, riceve un messaggio di errore indipendentemente dall'impostazione auth_fail_action. Se l'utente è un amministratore, il gestore procede.

Quando un gestore di URL con un'impostazione login diversa da optional corrisponde a un URL, il gestore verifica innanzitutto se l'utente ha eseguito l'accesso all'applicazione utilizzando la relativa opzione di autenticazione. In caso contrario, per impostazione predefinita, l'utente viene reindirizzato alla pagina di accesso. Puoi anche utilizzare auth_fail_action per configurare l'app in modo che rifiuti semplicemente le richieste di un gestore da parte di utenti che non sono autenticati correttamente, anziché reindirizzare l'utente alla pagina di accesso.

Nota: la limitazione di accesso admin viene soddisfatta anche per le richieste interne per le quali App Engine imposta intestazioni speciali X-Appengine appropriate. Ad esempio, le attività pianificate cron soddisfano la restrizione admin, perché App Engine imposta un'intestazione HTTP X-Appengine-Cron: true sulle rispettive richieste. Tuttavia, le richieste non soddisferebbero la limitazione di accesso required, perché le attività pianificate di cron non vengono eseguite come utente.

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.

Per ulteriori informazioni sui possibili tipi di media MIME, consulta il sito web IANA MIME Media Types.

redirect_http_response_code

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 definitivamente.
302
Codice di risposta trovato.
303
Consulta Altro codice di risposta.
307
Codice di risposta 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 302.

script

Facoltativo. Specifica che le richieste al gestore specifico devono avere come target la tua app. L'unico valore accettato per l'elemento script è auto perché tutto il traffico viene gestito utilizzando il comando del punto di ingresso. Per utilizzare i gestori statici, almeno uno dei tuoi gestori deve contenere la riga script: auto o definire un elemento entrypoint per il deployment riuscito.
secure Facoltativo. Qualsiasi gestore di URL può utilizzare l'impostazione secure, inclusi 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 che corrisponde 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 di query vengono conservati per il reindirizzamento.
Esempio Python 
handlers:
- url: /youraccount/.*
  secure: always
  script: auto

Per scegliere come target una versione specifica della tua app utilizzando il dominio REGION_ID.r.appspot.com, sostituisci i punti che di solito separano i componenti del sottodominio dell'URL con la stringa "-dot-", ad esempio:
https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com

Per utilizzare domini personalizzati con HTTPS, devi prima attivare e configurare i certificati SSL per quel dominio.

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.

Esempio: 
handlers:
# All URLs beginning with /stylesheets are treated as paths to
# static files in the stylesheets/ directory.
- url: /stylesheets
  static_dir: stylesheets
  # ...
static_files

Facoltativo. Un gestore di pattern di file statici associa un pattern URL 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 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/\1
  upload: 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 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 che può contenere raggruppamenti. 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:

static_dir
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.
static_files
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.

Scalare gli elementi

Gli elementi nella tabella seguente configurano la scalabilità dell'applicazione. Se non viene specificato alcun tipo di scalabilità, viene impostata la scalabilità automatica per impostazione predefinita.

Per saperne di più su come viene scalata un'app App Engine, consulta la sezione 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 scaling 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. In questo modo, l'applicazione mantiene prestazioni costanti durante le fluttuazioni del carico di richieste, ma aumenta anche il numero di istanze inattive (e i conseguenti costi di esecuzione) durante i 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 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 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 un costo per 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 prestazioni e costi. I valori più bassi aumentano le prestazioni e i costi, mentre i valori più alti riducono le prestazioni 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, 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 sospeso prima di avviare istanze aggiuntive per gestire le richieste in modo da ridurre la 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.
Esempio 
automatic_scaling:
  target_cpu_utilization: 0.65
  min_instances: 5
  max_instances: 100
  min_pending_latency: 30ms
  max_pending_latency: automatic
  max_concurrent_requests: 50
basic_scaling

Le applicazioni che utilizzano una classe di istanza B1 o superiore 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 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).
Esempio 
basic_scaling:
  max_instances: 11
  idle_timeout: 10m
manual_scaling

Le applicazioni che utilizzano una classe di istanza B1 o superiore devono specificare questo elemento o basic_scaling.

Questo elemento consente il ridimensionamento 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.
Esempio 
manual_scaling:
  instances: 5