Riferimento app.yaml di App Engine

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 il giorno Febbraio 2020, REGION_ID.r è incluso in URL di 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 in app.yaml . Il file app.yaml contiene anche informazioni sui tuoi il codice dell'app, ad esempio il runtime e la versione più recente identificativo dell'utente.

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 servizi aggiuntivi all'interno della tua app.

Per Go 1.11, app.yaml deve contenere almeno un Voce runtime. Per una breve panoramica, vedi Definizione del runtime Impostazioni.

Struttura delle directory

La cartella di ogni servizio deve contenere un file app.yaml e una o più origini Go che includono l'istruzione package main all'inizio. Per scoprire di più sulla strutturazione di più servizi nella tua app, consulta Strutturare i servizi web in App Engine.

Esempio

Di seguito è riportato un esempio di file app.yaml per un'applicazione Go 1.11:

runtime: go111

instance_class: F2

env_variables:
  BUCKET_NAME: "example-gcs-bucket"

handlers:
- url: /stylesheets
  static_dir: stylesheets

- url: /(.*\.(gif|png|jpg))$
  static_files: static/\1
  upload: static/.*\.(gif|png|jpg)$

- url: /.*
  script: auto

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 file utilizzano la sintassi delle espressioni regolari estese POSIX, esclusi gli elementi di confronto e le 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
build_env_variables

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

Per ulteriori informazioni, vedi Utilizzo delle variabili di ambiente di build.
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 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 dalla prima richiesta del file. Se omesso, il server di produzione imposta la scadenza su 10 minuti.

Esempio: 
runtime: go111

default_expiration: "4d 5h"

handlers:
  # ...

Per ulteriori informazioni, vedi Cache scadenza.

entrypoint

Facoltativo. Sostituisce il comportamento di avvio predefinito eseguendo il comando entrypoint all'avvio dell'app. Per fare in modo che la tua app ricevono richieste HTTP, l'elemento entrypoint deve contengono un comando che avvia un server web in ascolto sulla porta 8080.

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

Esempio: 
env_variables:
  MY_VAR: "my value"
 dove MY_VAR e my value sono il nome e della variabile di ambiente che vuoi definire e ognuno la voce della variabile di ambiente è rientrata di due spazi sotto la Elemento env_variables. Le variabili di ambiente a cui non è stato assegnato un valore predefinito sono "None".

Puoi quindi ottenere questi valori utilizzando os.Getenv:

import "os"
//...
if v := os.Getenv("MY_VAR"); v != "" {
  //...
}

Vedi anche l'elenco di variabili di ambiente di runtime che non possono essere sovrascritte.

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
Facoltativa. error_code può essere uno dei seguenti:
over_quota
Indica che l'app dispone di quota di risorse superata
timeout
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 sugli errori 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 oppure tramite la pubblicazione di file statici caricati con il codice, ad esempio immagini, CSS o JavaScript.

Consulta la sintassi degli elementi di gestione e dei sottoelementi

inbound_services

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

warmup
Abilita le richieste di warmup. Consulta Configurazione delle richieste di warmup.
Esempio: 
inbound_services:
- warmup
instance_class

Facoltativo. La classe di istanza per questo servizio.

I seguenti valori sono disponibili a seconda del servizio scalabilità:

Scalabilità automatica
F1, F2, F4 e 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 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 e B8
Predefinito: B2

Le classi di istanza di base e manuali richiedono di specificare o basic_scaling o l'elemento manual_scaling.

main

Facoltativo. Il percorso o il nome del pacchetto completo del pacchetto principale. Questa impostazione si applica solo se la tua app utilizza la modalità modulo Go.

Devi dichiarare il percorso del pacchetto principale se package main non si trova nella stessa directory di app.yaml. L'elemento main supporta i percorsi file relativi a app.yaml o ai nomi completi dei pacchetti. Per Ad esempio, se l'app ha questa struttura di directory: 

myapp/
├── app.yaml
├── go.mod
├── cmd
│   └── web
│       └── main.go
└── pkg
    └── users
        └── users.go

Allora devi utilizzare: 

main: ./cmd/web

o

main: example.com/myapp/cmd/web
runtime

Obbligatorio. Il nome dell'ambiente di runtime utilizzato dal tuo dell'app. Ad esempio, per specificare Go 1.11, utilizza: 

runtime: go111
service

Obbligatorio se crei un Google Cloud. 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 per 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 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à.

Esempio: 
service_account: [SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com
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: 
"projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME"
egress_setting
Facoltativo. Il valore predefinito è private-ranges-only. La 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 collegata. Le richieste agli indirizzi IP esterni vengono inviate alla rete internet pubblica.
all-traffic
Tutte le richieste vengono inviate tramite il connettore Accesso VPC serverless alla rete VPC collegata.
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 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. La prima mappatura il cui pattern corrisponde all'URL è quella utilizzata per gestire la richiesta.

Nella tabella seguente sono elencati i sottoelementi dell'elemento handlers che controllano il comportamento di script, file statici directory statiche e altre impostazioni.

Elemento Descrizione
auth_fail_action

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
Valore predefinito. L'utente viene reindirizzato alla pagina di accesso a Google o /_ah/login_required se viene utilizzata l'autenticazione OpenID. L'utente viene reindirizzato all'URL dell'applicazione dopo aver eseguito l'accesso o creato un account.
unauthorized
La richiesta è stata rifiutata con un codice di stato HTTP 401 e un messaggio di errore.

Se un'applicazione richiede un comportamento diverso, l'applicazione stessa può implementare la gestione degli accessi utente. Vedi Utenti API per saperne di più.

L'esempio seguente richiede un accesso per /profile/ e un accesso amministratore per /admin/ directory:

Puoi configurare un gestore per negare l'accesso agli URL protetti quando l'utente non ha eseguito l'accesso, invece di reindirizzarlo alla pagina di accesso, aggiungendo auth_fail_action: unauthorized alla la 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, 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.

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 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 eseguire un XMLHttpRequest di JavaScript su myassets, non avrà esito positivo a meno che l'handler per 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 obbligatorio dell'intestazione di risposta: 

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

Nota: se vuoi consentire a tutti di accedere ai tuoi asset, puoi utilizza il carattere jolly '*', anziché https://mygame.uc.r.appspot.com.

login

Facoltativo. Determina se il gestore URL richiede che l'utente abbia firmato in.

Questo elemento ha tre possibili valori:

optional
Predefinita. Non è necessario che l'utente abbia eseguito l'accesso.
required
Se l'utente ha eseguito l'accesso, il gestore procede normalmente. Altrimenti, l'azione specificata in auth_fail_action è già in uso.
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, verrà visualizzato un messaggio di errore indipendentemente da auth_fail_action dell'ambientazione. Se l'utente è un amministratore, il gestore procede.

Quando un gestore URL con un'impostazione login diversa da optional corrisponde a un URL, il gestore controlla innanzitutto se l'utente ha eseguito l'accesso all'applicazione utilizzando la sua 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 dell'accesso di admin è soddisfatta anche per per le quali App Engine imposta le richieste X-Appengine intestazioni speciali. Ad esempio: cron attività pianificate soddisfano le admin perché App Engine imposta un'intestazione HTTP X-Appengine-Cron: true sulle rispettive richieste. Tuttavia, le richieste non soddisferanno i required limitazione di accesso, perché le attività pianificate dalla cron non vengono eseguiti come nessun 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 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.

Per saperne di più sui possibili tipi di contenuti multimediali MIME, visita il sito web dei tipi di contenuti multimediali MIME IANA

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 permanente spostato.
302
Codice di risposta trovato.
303
Vedi Codice di risposta: altro.
307
Codice di risposta di reindirizzamento temporaneo.
Esempio 
handlers:
- url: /youraccount/.*
  script: auto
  secure: always
  redirect_http_response_code: 301

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 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 i gestori statici, almeno uno dei gestori deve contenere la riga script: auto o definire un elemento entrypoint per il deployment. 

handlers:
- url: /images
  static_dir: static/images

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

secure Facoltativo. Qualsiasi gestore di URL può usare l'impostazione secure, inclusi gestori di script gestori di file statici. L'elemento secure ha quanto segue 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 di un URL che corrispondono a questo gestore e che non utilizzano HTTPS vengono reindirizzate automaticamente all'URL HTTPS con lo stesso percorso. I parametri di query vengono conservati per il reindirizzamento.
Esempio 
handlers:
- url: /youraccount/.*
  script: auto
  secure: always

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

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

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.

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

Facoltativo. Un gestore di pattern di file statici associa un pattern URL ai percorsi dei file statici caricati con l'applicazione. L'espressione regolare del pattern URL può definire raggruppamenti di espressioni regolari da utilizzare nella 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.

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 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 gestiti separatamente dai file dell'applicazione. L'esempio in alto potrebbe utilizzare il seguente pattern upload: archives/(.*)/items/(.*)

url

Elemento obbligatorio in handlers. Il pattern dell'URL come expression regolare. L'espressione può contenere raggruppamenti che possono essere a cui viene fatto riferimento nel percorso file dello script con un'espressione regolare i backreference. 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:

static_dir
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.
static_files
Un gestore di pattern di file statici associa un pattern URL ai percorsi da i file statici caricati con l'applicazione. L'espressione regolare del pattern URL può definire raggruppamenti di espressioni regolari da utilizzare nella compilazione 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.

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
Facoltativa. 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. Questa opzione è utile per limitare i costi di un modulo.

min_instances
Facoltativo. Il numero minimo di istanze che App Engine deve 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 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 mantiene bassi i costi di gestione, ma può peggiorare le prestazioni in presenza 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 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 gestire il traffico attuale delle applicazioni in base alla scalabilità impostazioni come target_cpu_utilization e target_throughput_utilization. Impostazione di min_idle_instances specifica il numero di istanze a cui eseguire in aggiunta a questo numero calcolato. Ad esempio: se App Engine calcola cinque istanze sono necessarie per gestire il traffico e min_idle_instances è impostato su 2, App Engine eseguirà 7 istanze (5, calcolate in base al traffico, più altri 2 per min_idle_instances).

Tieni presente che stai addebitato per il numero di istanze specificato che ricevono traffico o meno. 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 minimo elevato ti consente di preparare l'applicazione dei picchi nel carico delle richieste. App Engine mantiene in esecuzione il numero minimo di istanze 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
Facoltativo. Specifica un valore compreso tra 0,5 e 0,95. L'impostazione predefinita è 0.6.

Questo parametro specifica la soglia di utilizzo della CPU a cui verranno avviate nuove istanze per gestire il traffico, consentendoti di trovare il giusto equilibrio tra prestazioni e costi: i valori più bassi aumentano le prestazioni e i costi, mentre i valori più elevati riducono le prestazioni, ma anche i costi. Ad esempio, il valore 0,7 significa che vengono avviate quando l'utilizzo della CPU raggiunge il 70%.

target_throughput_utilization
Facoltativa. 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 concorrenti. 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, 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 potrebbe comportare la creazione di più istanze di quante siano necessarie per un'app sicura per i thread e questo 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 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 viene raggiunta questa soglia, viene attivato un indicatore di scalabilità 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 il tempo minimo che App Engine deve consentire a una richiesta di attendere nella fila 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. A pagamento app, il valore predefinito è 0.

Questo elemento funziona insieme a 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 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 istanza di B1 o superiore, deve specificare questo elemento oppure 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 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: 11
  idle_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.
Esempio 
manual_scaling:
  instances: 5