File di configurazione app.yaml

Il file app.yaml definisce le impostazioni di configurazione per il runtime, nonché le impostazioni generali dell'app, della rete e di altre risorse.

Non aggiungere app.yaml al file .gcloudignore. Per il deployment potrebbe essere necessario app.yaml e la sua aggiunta a .gcloudignore comporterà un errore del deployment.

Sintassi

La sintassi del file app.yaml è il formato YAML. Il formato YAML supporta i commenti, in cui qualsiasi riga che inizia con il carattere del simbolo hash (#) viene ignorata, ad esempio:

# This is a comment.

I pattern URL e di percorso file utilizzano la sintassi di espressioni regolari estese POSIX, escludendo gli elementi di confronto e le classi di confronto. Sono supportati i riferimenti a ritroso alle corrispondenze raggruppate (ad esempio \1), così come le seguenti estensioni Perl: \w \W \s \S \d \D.

Impostazioni generali

Un file app.yaml può includere queste impostazioni generali. Alcuni di questi sono obbligatori:

Nome	Descrizione
`build_env_variables`	Facoltativo. Se utilizzi un runtime che supporta buildpacks, puoi definire le variabili di ambiente di build nel tuo file `app.yaml`. Per scoprire di più, consulta Utilizzare le variabili di ambiente di build.
`runtime`	obbligatorio. Il nome dell'ambiente di runtime utilizzato dalla tua app. Ad esempio, per specificare l'ambiente di runtime, utilizza:
`runtime_config`	Specifica la versione del runtime Python. A partire dalla versione Python 3.8, devi specificare la versione del sistema operativo. runtime_config: operating_system: "ubuntu22" runtime_version: "3.12" `operating_system`: specifica la versione del sistema operativo Ubuntu che vuoi utilizzare. Obbligatorio per Python 3.8 e versioni successive. Non supportato per Python versione 3.7 e precedenti. Consulta le versioni e i runtime di Ubuntu supportati sulla pagina Runtime di Python. `runtime_version`: facoltativo per tutte le versioni del runtime. Specifica la versione del runtime Python che vuoi utilizzare. Controlla le versioni supportate e i valori predefiniti sulla pagina Runtime di Python.
`runtime_config`	Specifica la versione Go. A partire da Go versione 1.18, devi specificare la versione del sistema operativo. Ad esempio, se scegli Go 1.22: runtime_config: operating_system: "ubuntu22" runtime_version: "1.22" `operating_system`: specifica la versione del sistema operativo Ubuntu che vuoi utilizzare. Obbligatorio per la versione 1.18 e successive. Non supportato per Go versione 1.15 e precedenti. Consulta le versioni e i runtime di Ubuntu supportati sulla pagina Runtime Go. `runtime_version`: facoltativo per tutte le versioni del runtime. Specifica la versione del runtime di Go che vuoi utilizzare. Visualizza le versioni supportate e i valori predefiniti nella pagina Runtime Go.
`runtime_config`	Specifica la versione di Node.js. A partire dalla versione 18 di Node.js, devi specificare la versione del sistema operativo. runtime_config: operating_system: "ubuntu22" runtime_version: "20" `operating_system`: specifica la versione del sistema operativo Ubuntu che vuoi utilizzare. Obbligatorio per la versione 18 e successive. Non supportato per Node.js versione 16 e precedenti. Consulta le versioni e i runtime di Ubuntu supportati sulla pagina dei runtime Node.js. `runtime_version`: facoltativo per tutte le versioni del runtime. Specifica la versione del runtime Node.js che vuoi utilizzare. Consulta le versioni supportate e i valori predefiniti nella pagina relativa ai runtime Node.js.
`runtime_config`	Specifica la versione Java. A partire da Java versione 11, devi specificare la versione del sistema operativo. runtime_config: operating_system: "ubuntu22" runtime_version: "21" `operating_system`: specifica la versione del sistema operativo Ubuntu che vuoi utilizzare. Obbligatorio per la versione 11 e successive. Non supportato per Java 8. Vedi le versioni e i runtime di Ubuntu supportati nella pagina Runtime Java. `runtime_version`: facoltativo per tutte le versioni del runtime. Specifica la versione del runtime Java che vuoi utilizzare. Controlla le versioni supportate e i valori predefiniti nella pagina Runtime Java.
`runtime_config`	A partire da Ruby versione 3.2, devi specificare la versione del sistema operativo. runtime_config: operating_system: "ubuntu22" `operating_system`: specifica la versione del sistema operativo Ubuntu che vuoi utilizzare. Obbligatorio per la versione 3.2 e successive. Non supportato per Ruby versione 3.1 e precedenti. Consulta le versioni e i runtime di Ubuntu supportati sulla pagina Runtime di Ruby.
`runtime_config`	A partire da .NET versione 6 e successive, devi specificare la versione del sistema operativo. runtime_config: operating_system: "ubuntu22" `operating_system`: specifica la versione del sistema operativo Ubuntu che vuoi utilizzare. Obbligatorio per la versione 6 e successive. Non supportato per .NET versione 3.1 e precedenti. Consulta le versioni e i runtime di Ubuntu supportati sulla pagina dei runtime.NET. `runtime_version`: facoltativo per tutte le versioni del runtime. Specifica la versione del runtime .NET che vuoi utilizzare. Consulta le versioni supportate e i valori predefiniti nella pagina relativa ai runtime.NET.
`runtime_config`	Specifica la versione PHP. A partire dalla versione PHP 7.4, devi specificare la versione del sistema operativo. runtime_config: operating_system: "ubuntu22" runtime_version: "8.3" `operating_system`: specifica la versione del sistema operativo Ubuntu che vuoi utilizzare. Obbligatorio per la versione 7.4 e successive. Non supportato per PHP versione 7.3 e precedenti. Consulta le versioni e i runtime di Ubuntu supportati nella pagina Runtime PHP. `runtime_version`: facoltativo per tutte le versioni del runtime. Specifica la versione del runtime PHP che vuoi utilizzare. Consulta le versioni supportate e i valori predefiniti nella pagina Runtime PHP.
`env: flex`	Obbligatorio: seleziona l'ambiente flessibile.
`entrypoint`	Il comando per avviare l'applicazione. Il punto di ingresso avvia un processo che risponde alle richieste HTTP sulla porta definita dalla variabile di ambiente `PORT`.
`service: service_name`	Obbligatorio se stai creando un servizio. Facoltativo per il servizio predefinito. Ogni servizio e ogni versione devono avere un nome. Un nome può contenere numeri, lettere e trattini. Nell'ambiente flessibile, la lunghezza combinata di `VERSION-dot-SERVICE-dot-PROJECT_ID` (dove `VERSION` è il nome della versione, `SERVICE` è il nome del servizio e `PROJECT_ID` è l'ID progetto) non può superare i 63 caratteri e non può iniziare o terminare con un trattino. Se esegui il deployment senza specificare un nome del servizio, viene creata una nuova versione del servizio predefinito. Se esegui il deployment con un nome di servizio già esistente, ne viene creata una nuova versione. Se esegui il deployment con un nuovo nome di servizio che non esiste, vengono creati un nuovo servizio e una nuova versione. Consigliamo di utilizzare un nome univoco per ogni combinazione di servizio-versione. Nota: in precedenza, i servizi erano chiamati "moduli".
`service_account`	Facoltativo. L'elemento `service_account` consente di specificare un account di servizio gestito dall'utente come identità per la versione. L'account di servizio specificato verrà utilizzato per accedere ad altri servizi Google Cloud ed eseguire attività. L'account di servizio deve essere fornito nel seguente formato: service_account: [SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com
`skip_files`	Facoltativo. L'elemento `skip_files` specifica quali file nella directory dell'applicazione non devono essere caricati in App Engine. Il valore è un'espressione regolare o un elenco di espressioni regolari. Tutti i nomi file che corrispondono a una qualsiasi delle espressioni regolari vengono omessi dall'elenco dei file da caricare al momento del caricamento dell'applicazione. Ad esempio, per saltare i file i cui nomi terminano con `.bak`, aggiungi una sezione `skip_files` come la seguente: skip_files: - ^.*\.bak$

Impostazioni di rete

Puoi specificare le impostazioni di rete nel file di configurazione app.yaml, ad esempio:

network:
  name: NETWORK_NAME
  instance_ip_mode: INSTANCE_IP_MODE
  instance_tag: TAG_NAME
  subnetwork_name: SUBNETWORK_NAME
  session_affinity: true
  forwarded_ports:
    - PORT
    - HOST_PORT:CONTAINER_PORT
    - PORT/tcp
    - HOST_PORT:CONTAINER_PORT/udp

Quando configuri le impostazioni di rete, puoi utilizzare le seguenti opzioni:

Opzione	Descrizione
`name`	Ogni istanza VM nell'ambiente flessibile viene assegnata a una rete Google Compute Engine al momento della creazione. Utilizza questa impostazione per specificare un nome di rete. Assegna il nome breve, non il percorso della risorsa (ad esempio, `default` anziché `https://www.googleapis.com/compute/v1/projects/my-project/global/networks/default`). Se non specifichi un nome di rete, le istanze vengono assegnate alla rete predefinita del progetto (che ha il nome `default`). Se vuoi specificare il nome di una subnet, devi specificare un nome di rete.
`instance_ip_mode`	Facoltativo. Per impedire alle istanze di ricevere un indirizzo IP esterno temporaneo, impostalo su `internal` e abilita l'accesso privato Google. Se il deployment dell'istanza è stato già eseguito senza questa impostazione o se è stato eseguito con questa impostazione su `external`, eseguire nuovamente il deployment con l'impostazione `internal` rimuove gli indirizzi IP esterni temporanei dalle istanze. L'impostazione `internal` ha limitazioni. Il valore predefinito è `external`.
`instance_tag`	Facoltativo. Un tag con questo nome viene assegnato a ciascuna istanza del servizio quando viene creato. I tag possono essere utili nei comandi `gcloud` per scegliere come target di un'azione un gruppo di istanze. Ad esempio, vedi l'utilizzo dei flag `--source-tags` e `--target-tags` nel comando compute firewalls-create. Se non specificato, l'istanza è codificata con `aef-INSTANCE_ID` quando non viene utilizzato il VPC condiviso. Se viene utilizzato un VPC condiviso, l'istanza è codificata con entrambi i valori `aef-INSTANCE_ID and aef-instance.`
`subnetwork_name`	Facoltativo. Puoi segmentare la rete e utilizzare una subnet personalizzata. Assicurati che sia specificata la rete `name`. Specifica il nome breve, non il percorso della risorsa (ad esempio, `default` anziché `https://www.googleapis.com/compute/v1/projects/my-project/global/networks/default/subnetworks/default`).La subnet deve trovarsi nella stessa regione dell'applicazione.
`session_affinity`	Facoltativo. Impostalo su `true` per configurare App Engine in modo che instrada più richieste sequenziali per un determinato utente alla stessa istanza di App Engine, ad esempio per l'archiviazione locale dei dati utente durante una sessione. L'affinità sessione consente di esaminare il valore di un cookie per identificare più richieste dello stesso utente e indirizzarle tutte alla stessa istanza. Se l'istanza viene riavviata, non è integro, è sovraccarico o non è più disponibile dopo lo scale down del numero di istanze, l'affinità sessione verrà interrotta e ulteriori richieste verranno instradate a un'istanza diversa. Tieni presente che l'abilitazione dell'affinità sessione può influire sulla configurazione del bilanciamento del carico. Questo parametro è disattivato per impostazione predefinita.
`forwarded_ports`	Facoltativo. Puoi inoltrare le porte dalla tua istanza (`HOST_PORT`) al container Docker (`CONTAINER_PORT`). Il valore `HOST_PORT` deve essere compreso tra 1024 e 65535 e non può entrare in conflitto con le seguenti porte: 22, 8080, 8090, 8443, 10000, 10001, 10400-10500, 114231, 114231. Il valore `CONTAINER_PORT` deve essere compreso tra 1 e 65535 e non può entrare in conflitto con le seguenti porte: 22, 10001, 10400-10500, 11211. Se specifichi solo un `PORT`, App Engine presuppone che si tratti della stessa porta sull'host e sul container. Per impostazione predefinita, viene inoltrato sia il traffico TCP sia quello UDP. Il traffico deve essere indirizzato direttamente all'indirizzo IP dell'istanza di destinazione anziché al dominio appspot.com o al tuo dominio personalizzato.

Configurazione di rete avanzata

Puoi segmentare la rete Compute Engine in subnet. Ciò consente di abilitare scenari VPN, come l'accesso ai database all'interno della tua rete aziendale.

Per abilitare le subnet per la tua applicazione App Engine:

Crea una rete di subnet personalizzata.
Aggiungi il nome della rete e della subnet al file app.yaml, come specificato sopra.
Per stabilire una VPN semplice basata sul routing statico, crea un gateway e un tunnel per una rete di subnet personalizzata. Altrimenti, scopri come creare altri tipi di VPN.

Port forwarding

Il port forwarding consente le connessioni dirette al container Docker sulle tue istanze. Questo traffico può viaggiare su qualsiasi protocollo. Il port forwarding è pensato per aiutare in situazioni in cui potrebbe essere necessario collegare un debugger o un profiler. Il traffico deve essere indirizzato direttamente all'indirizzo IP dell'istanza di destinazione anziché al dominio appspot.com o al tuo dominio personalizzato.

Per impostazione predefinita, il traffico in entrata dall'esterno della rete non è consentito attraverso i firewall di Google Cloud. Dopo aver specificato il port forwarding nel file app.yaml, devi aggiungere una regola firewall che consenta il traffico dalle porte che vuoi aprire.

Puoi specificare una regola firewall nella pagina Regole firewall di rete nella console Google Cloud o utilizzando i comandi gcloud.

Ad esempio, se vuoi inoltrare il traffico TCP dalla porta 2222:

Nelle impostazioni di rete di app.yaml, includi:
```
network:
  forwarded_ports:
    - 2222/tcp
```
1. Se utilizzi il runtime Python, modifica app.yaml in modo da includere:
```
entrypoint: gunicorn -b :$PORT -b :2222 main:app
```
Specifica una regola firewall nella console Google Cloud o utilizzando gcloud compute firewall-rules create per consentire il traffico da qualsiasi origine (0.0.0.0/0) e da tcp:2222.

Impostazioni risorse

Queste impostazioni controllano le risorse di calcolo. App Engine assegna un tipo di macchina in base alla quantità di CPU e memoria specificate. È garantito che la macchina abbia almeno il livello di risorse che hai specificato, che potrebbe averne di più.

Puoi specificare fino a otto volumi di tmpfs nelle impostazioni delle risorse. Abilita i carichi di lavoro che richiedono memoria condivisa tramite tmpfs e migliora l'I/O del file system.

Ad esempio:

resources:
  cpu: 2
  memory_gb: 2.3
  disk_size_gb: 10
  volumes:
  - name: ramdisk1
    volume_type: tmpfs
    size_gb: 0.5

Quando configuri le impostazioni delle risorse, puoi utilizzare le seguenti opzioni:

Opzione	Descrizione	Predefinito
`cpu`	Il numero di core; deve essere uno, un numero pari compreso tra 2 e 32 o un multiplo di 4 compreso tra 32 e 80.	1 core
`memory_gb`	RAM in GB. La memoria richiesta per l'applicazione, che non include i ~0,4 GB di memoria necessari per l'overhead di alcuni processi. Ogni core della CPU richiede una memoria totale compresa tra 1,0 e 6,5 GB. Per calcolare la memoria richiesta: `memory_gb` = `cpu` * [1,0 - 6,5] - 0,4 Nell'esempio precedente in cui hai specificato 2 core, puoi richiedere tra 1,6 e 12,6 GB. La quantità totale di memoria disponibile per l'applicazione è impostata dall'ambiente di runtime come variabile di ambiente `GAE_MEMORY_MB`.	0,6 GB
`disk_size_gb`	Dimensioni in GB. Il minimo è 10 GB e il massimo è 10.240 GB.	13 GB
`name`	Obbligatorio, se utilizzi volumi. Nome del volume. I nomi devono essere univoci e devono avere una lunghezza compresa tra 1 e 63 caratteri. I caratteri possono essere lettere minuscole, numeri o trattini. Il primo carattere deve essere una lettera e l'ultimo non può essere un trattino. Il volume viene montato nel container dell'app come `/mnt/NAME`.
`volume_type`	Obbligatorio, se utilizzi volumi. Deve essere `tmpfs`.
`size_gb`	Obbligatorio, se utilizzi volumi. Dimensioni del volume in GB. Il valore minimo è 0,001 GB e il valore massimo è la quantità di memoria disponibile nel container dell'applicazione e sul dispositivo sottostante. Google non aggiunge ulteriore RAM al tuo sistema per soddisfare i requisiti del disco. La RAM allocata per i volumi tmpfs verrà sottratta dalla memoria disponibile per il container dell'app. La precisione dipende dal sistema.

Suddividi controlli di integrità

Per impostazione predefinita, i controlli di integrità suddivisi sono abilitati. Puoi utilizzare richieste di controllo di integrità periodiche per verificare che il deployment di un'istanza VM sia stato eseguito correttamente e per controllare che un'istanza in esecuzione mantenga uno stato integro. A ogni controllo di integrità deve essere data risposta entro un intervallo di tempo specificato.

Un'istanza non è integro quando non risponde a un numero specificato di richieste di controllo di integrità consecutive. Se un'istanza non è attiva, viene riavviata. Se un'istanza non è pronta, non riceverà alcuna richiesta del client. Un controllo di integrità può avere esito negativo anche se non c'è spazio libero su disco.

Puoi utilizzare due tipi di controlli di integrità:

I controlli di attività confermano che la VM e il container Docker sono in esecuzione. App Engine riavvia le istanze in stato non integro.
I controlli di idoneità confermano che l'istanza è pronta per accettare richieste in entrata. Le istanze che non superano il controllo di idoneità non vengono aggiunte al pool di istanze disponibili.

Per impostazione predefinita, le richieste HTTP dei controlli di integrità non vengono inoltrate al container dell'applicazione. Se vuoi estendere i controlli di integrità alla tua applicazione, specifica un percorso per i controlli di attività o i controlli di idoneità. Un controllo di integrità personalizzato per la tua applicazione viene considerato positivo se restituisce un codice di risposta 200 OK.

Controlli di attività

I controlli di attività confermano che la VM e il container Docker sono in esecuzione. Le istanze ritenute non integre vengono riavviate.

Puoi personalizzare le richieste di controllo dell'attività aggiungendo una sezione liveness_check facoltativa al file app.yaml, ad esempio:

liveness_check:
  path: "/liveness_check"
  check_interval_sec: 30
  timeout_sec: 4
  failure_threshold: 2
  success_threshold: 2

Per i controlli di attività sono disponibili le seguenti impostazioni:

Campo	Predefinito	Intervallo (minimo-massimo)	Descrizione
`path`	Nessuna		Se vuoi che i controlli di attività vengano inoltrati al container dell'applicazione, specifica un percorso dell'URL, ad esempio `"/liveness_check"`
`timeout_sec`	4 secondi	1-300	Intervallo di timeout per ogni richiesta, in secondi.
`check_interval_sec`	30 secondi	1-300	Intervallo di tempo tra i controlli, in secondi. Tieni presente che questo valore deve essere maggiore di timeout_sec.
`failure_threshold`	4 controlli	1-10	Un'istanza non è integro dopo non aver superato questo numero di controlli consecutivi.
`success_threshold`	2 controlli	1-10	Un'istanza in stato non integro diventa nuovamente in stato integro dopo aver risposto correttamente a questo numero di controlli consecutivi.
`initial_delay_sec`	300 secondi	0-3600	Il ritardo, in secondi, successivo all'avvio dell'istanza, durante il quale le risposte del controllo di integrità vengono ignorate. Questa impostazione si applica a ogni istanza appena creata e può concedere a una nuova istanza più tempo per essere operativa. L'impostazione ritarda la riparazione automatica dopo il controllo dell'istanza e la sua potenziale creazione prematura, se è in fase di avvio. Il timer di ritardo iniziale si avvia quando l'istanza è in modalità IN ESECUZIONE. Ad esempio, potresti voler aumentare il ritardo se l'applicazione ha attività di inizializzazione che richiedono molto tempo prima di essere pronta per gestire il traffico.

Controlli di idoneità

I controlli di idoneità confermano che un'istanza può accettare richieste in entrata. Le istanze che non superano il controllo di idoneità non vengono aggiunte al pool di istanze disponibili.

Puoi personalizzare le richieste di controllo di integrità aggiungendo una sezione readiness_check facoltativa al file app.yaml, ad esempio:

readiness_check:
  path: "/readiness_check"
  check_interval_sec: 5
  timeout_sec: 4
  failure_threshold: 2
  success_threshold: 2
  app_start_timeout_sec: 300

Per i controlli di idoneità sono disponibili le seguenti impostazioni:

Campo	Predefinito	Intervallo (minimo-massimo)	Descrizione
`path`	Nessuna		Se vuoi che i controlli di idoneità vengano inoltrati al container dell'applicazione, specifica un percorso dell'URL, ad esempio `"/readiness_check"`
`timeout_sec`	4 secondi	1-300	Intervallo di timeout per ogni richiesta, in secondi.
`check_interval_sec`	5 secondi	1-300	Intervallo di tempo tra i controlli, in secondi. Tieni presente che questo valore deve essere maggiore di timeout_sec.
`failure_threshold`	2 controlli	1-10	Un'istanza non è integro dopo non aver superato questo numero di controlli consecutivi.
`success_threshold`	2 controlli	1-10	Un'istanza non integro diventa integro dopo aver risposto correttamente a questo numero di controlli consecutivi.
`app_start_timeout_sec`	300 secondi	1-1800	Questa impostazione si applica ai nuovi deployment, non alle singole VM. Specifica il tempo massimo in secondi consentito per un numero sufficiente di istanze in un deployment per superare i controlli di integrità. Se questa durata viene superata, il deployment non va a buon fine e viene eseguito il rollback. Il timer si avvia una volta eseguito il provisioning delle istanze Compute Engine e dopo la creazione del servizio di backend del bilanciatore del carico. Ad esempio, ti consigliamo di aumentare il timeout se vuoi fornire timeout più lunghi durante i deployment affinché un numero sufficiente di istanze sia in stato integro.

Frequenza del controllo di integrità

Per garantire l'alta disponibilità, App Engine crea copie ridondanti di ogni controllo di integrità. Se un controllo di integrità non va a buon fine, uno ridondante può prendersi il controllo senza ritardi.

Se esamini i log nginx.health_check per la tua applicazione, potresti notare che il polling del controllo di integrità avviene più spesso di quanto hai configurato, a causa dei controlli di integrità ridondanti che seguono le tue impostazioni. Questi controlli di integrità ridondanti vengono creati automaticamente e non è possibile configurarli.

Impostazioni di scalabilità del servizio

Le chiavi utilizzate per controllare la scalabilità di un servizio dipendono dal tipo di scalabilità che assegni al servizio.

Puoi utilizzare la scalabilità automatica o manuale. L'impostazione predefinita è la scalabilità automatica.

Scalabilità automatica

Puoi configurare la scalabilità automatica aggiungendo una sezione automatic_scaling al file app.yaml. Ad esempio:

automatic_scaling:
  min_num_instances: 1
  max_num_instances: 15
  cool_down_period_sec: 180
  cpu_utilization:
    target_utilization: 0.6
  target_concurrent_requests: 100

Nella tabella seguente sono elencate le impostazioni utilizzabili con la scalabilità automatica:

Nome	Descrizione
`automatic_scaling`	Per impostazione predefinita è prevista la scalabilità automatica. Includi questa riga se vuoi specificare una delle impostazioni di scalabilità automatica.
`min_num_instances`	Il numero minimo di istanze assegnate al tuo servizio. Quando viene eseguito il deployment di un servizio, ne vengono assegnate tutte le istanze e si applica la scalabilità in base al traffico. Deve essere `1` o superiore, il valore predefinito è `2` per ridurre la latenza. Nota: il numero di istanze in esecuzione potrebbe scendere al di sotto di questo valore per un breve periodo di tempo durante alcuni eventi. Se la tua applicazione richiede l'esecuzione continua su un determinato numero di istanze, valuta la possibilità di overprovisioning.
`max_num_instances`	Il numero massimo di istanze fino a cui è possibile fare lo scale up del tuo servizio. Il numero massimo di istanze nel progetto è limitato dalla quota di risorse del progetto. Il valore predefinito è `20`.
`cool_down_period_sec`	Il numero di secondi che il gestore della scalabilità automatica deve attendere prima di iniziare a raccogliere informazioni da una nuova istanza. Ciò impedisce al gestore della scalabilità automatica di raccogliere informazioni durante l'inizializzazione dell'istanza, periodo durante il quale l'utilizzo raccolto non sarebbe affidabile. Il periodo di attesa deve essere superiore o uguale a 60 secondi. Il valore predefinito è `120`.
`cpu_utilization`	Utilizza questa intestazione se vuoi specificare l'utilizzo target della CPU.
`target_utilization`	Utilizzo CPU target. L'utilizzo della CPU viene calcolato in media su tutte le istanze in esecuzione e viene utilizzato per decidere quando ridurre o aumentare il numero di istanze. Tieni presente che le istanze vengono sottoposte a scale down indipendentemente dalle richieste in corso 25 secondi dopo che un'istanza riceve l'indicatore di arresto. Il valore predefinito è `0.5`.
`target_concurrent_requests`	(Beta) Numero target di connessioni simultanee per istanza. Se specifichi un valore per questo parametro, il gestore della scalabilità automatica utilizza il numero medio di connessioni simultanee tra tutte le istanze in esecuzione per decidere quando ridurre o aumentare il numero di istanze. Un'istanza viene sottoposta a scale down 25 secondi dopo la ricezione dell'indicatore di arresto, indipendentemente dalle richieste in corso. Se non specifichi un valore per questo parametro, il gestore della scalabilità automatica non sceglie come target un numero di connessioni simultanee per istanza. Le connessioni sono diverse dalle richieste. Una connessione può essere riutilizzata da un client per inviare più richieste.

Scalabilità manuale

Puoi configurare la scalabilità manuale aggiungendo una sezione manual_scaling al file app.yaml. Ad esempio:

manual_scaling:
  instances: 5

Nella tabella seguente sono elencate le impostazioni utilizzabili con la scalabilità manuale:

Nome	Descrizione
`manual_scaling`	Necessaria per abilitare la scalabilità manuale per un servizio.
`instances`	Il numero di istanze da assegnare al servizio. Nota: il numero di istanze in esecuzione potrebbe scendere al di sotto di questo valore per un breve periodo di tempo durante alcuni eventi. Se la tua applicazione richiede l'esecuzione continua su un determinato numero di istanze, valuta la possibilità di overprovisioning.

Definizione delle variabili di ambiente

Puoi definire le variabili di ambiente in app.yaml per renderle disponibili nella tua app, ad esempio:

env_variables:
  MY_VAR: "my value"

dove MY_VAR e my value sono il nome e il valore della variabile di ambiente da definire e ogni voce di variabile di ambiente rientra in due spazi sotto l'elemento env_variables.