Questa pagina è stata tradotta dall'API Cloud Translation.

File di configurazione app.yaml

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

Non aggiungere app.yaml a .gcloudignore . app.yaml potrebbe essere necessario per il deployment e aggiungerlo a .gcloudignore causerà la mancata riuscita del deployment.

Sintassi

La sintassi del file app.yaml è nel formato YAML. Il formato YAML supporta i commenti, in cui qualsiasi riga che inizia con l'hash (#) viene ignorato, ad esempio:

# 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. Riferimenti precedenti a corrispondenze raggruppate (ad es. \1) così come le seguenti estensioni Perl: \w \W \s \S \d \D.

Impostazioni generali

Un file app.yaml può includere queste impostazioni generali. Tieni presente che alcuni sono obbligatori:

Nome	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.
`runtime`	Obbligatorio. Il nome dell'ambiente di runtime utilizzato dalla tua app. Ad esempio, per specificare l'ambiente di runtime, usa:
`runtime_config`	Specifica la versione del runtime Python. A partire dalla versione 3.8 di Python, devi specificare la versione del sistema operativo. runtime_config: operating_system: "ubuntu22" runtime_version: "3.12" `operating_system`: specifica la versione di Ubuntu che vuoi utilizzare. Obbligatorio per Python versione 3.8 e successive. Non supportata per la versione Python 3.7 e precedenti. Vedi le versioni e i runtime di Ubuntu supportati su i runtime Python . `runtime_version`: facoltativo per tutte le versioni del runtime. Specifica la versione del runtime Python che vuoi utilizzare. Vedi le versioni supportate e i valori predefiniti nella Runtime 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 Vai 1.22: runtime_config: operating_system: "ubuntu22" runtime_version: "1.22" `operating_system`: specifica la versione di Ubuntu che vuoi utilizzare. Obbligatorio per la versione 1.18 e successive. Non supportata per la versione Go 1.15 e precedenti. Vedi le versioni e i runtime di Ubuntu supportati su i runtime Go . `runtime_version`: facoltativo per tutte le versioni del runtime. Specifica la versione del runtime Go che vuoi utilizzare. Vedi le versioni supportate e i valori predefiniti nella Runtime Go .
`runtime_config`	Specifica la versione di Node.js. A partire dalla versione 18 di Node.js, devi e specificare la versione del sistema operativo. runtime_config: operating_system: "ubuntu22" runtime_version: "22" `operating_system`: specifica la versione di Ubuntu che vuoi utilizzare. Obbligatorio per la versione 18 e successive. Non supportato per Node.js versione 16 e precedenti. Vedi le versioni e i runtime di Ubuntu supportati su i runtime di Node.js . `runtime_version`: facoltativo per tutte le versioni del runtime. Specifica la versione del runtime Node.js che vuoi utilizzare. Vedi le versioni supportate e i valori predefiniti nella Runtime Node.js .
`runtime_config`	Specifica la versione Java. A partire dalla versione 11 di Java, devi specificare la versione del sistema operativo. runtime_config: operating_system: "ubuntu22" runtime_version: "21" `operating_system`: specifica la versione di 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 su i runtime Java . `runtime_version`: facoltativo per tutte le versioni del runtime. Specifica la versione del runtime Java che vuoi utilizzare. Vedi le versioni supportate e i valori predefiniti nella Runtime Java .
`runtime_config`	A partire dalla versione 3.2 di Ruby, devi specificare la versione del sistema operativo. runtime_config: operating_system: "ubuntu22" `operating_system`: specifica la versione di Ubuntu che vuoi utilizzare. Obbligatorio per la versione 3.2 e successive. Non supportata per la versione Ruby 3.1 e precedenti. Vedi le versioni e i runtime di Ubuntu supportati su i runtime 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 di Ubuntu che vuoi utilizzare. Obbligatorio per la versione 6 e successive. Non supportato per la versione .NET 3.1 e precedenti. Vedi le versioni e i runtime di Ubuntu supportati su i runtime.NET . `runtime_version`: facoltativo per tutte le versioni del runtime. Specifica la versione del runtime .NET che vuoi utilizzare. Vedi le versioni supportate e i valori predefiniti nella Runtime.NET .
`runtime_config`	Specifica la versione PHP. A partire dalla versione 7.4 di PHP, devi specificare la versione del sistema operativo. runtime_config: operating_system: "ubuntu22" runtime_version: "8.3" `operating_system`: specifica la versione di Ubuntu che vuoi utilizzare. Obbligatorio per la versione 7.4 e successive. Non supportato per la versione PHP 7.3 e precedenti. Vedi le versioni e i runtime di Ubuntu supportati su i runtime PHP . `runtime_version`: facoltativo per tutte le versioni del runtime. Specifica la versione del runtime PHP che desideri utilizzare. Vedi le versioni supportate e i valori predefiniti nella Runtime PHP .
`env: flex`	Obbligatorio: seleziona l'ambiente flessibile.
`entrypoint`	Il comando per avviare l'applicazione. Il punto di ingresso avvia un processo risponde alle richieste HTTP sulla porta definita dalla variabile di ambiente `PORT`.
`service: service_name`	Obbligatorio se si crea un servizio. Facoltativo per il servizio predefinito. Ciascuna e ogni versione deve avere un nome. Un nome può contenere numeri, lettere e trattini. Nell'ambiente flessibile, la durata combinata dei `VERSION-dot-SERVICE-dot-PROJECT_ID` (dove `VERSION` è il nome della versione, `SERVICE` è il nome del tuo servizio, `PROJECT_ID` è il tuo ID progetto) non può essere più lungo più di 63 caratteri e non può iniziare o terminare con un trattino. Se esegui il deployment senza specificare un nome servizio, viene creata una nuova versione viene creato un servizio predefinito. Se esegui il deployment un nome di servizio già esistente, una nuova versione del servizio è stato creato. Se esegui il deployment con un nuovo nome di servizio che non esiste, verrà il servizio e la versione. Ti consigliamo di utilizzare un nome univoco per ogni combinazione di servizio e versione. Nota: in precedenza i servizi erano chiamati "moduli".
`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 per accedere ad altri servizi e servizi Google Cloud durante l'esecuzione di 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 della directory delle applicazioni non devono essere caricate in App Engine. Il valore è un'espressione regolare o un elenco di espressioni regolari. Qualsiasi che corrisponda a una qualsiasi delle espressioni regolari viene omesso dalla l'elenco dei file da caricare quando viene caricata l'applicazione. Ad esempio, per saltare i file il cui nome termina 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 di app.yaml, ad esempio 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`). Per 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 precedentemente eseguito senza questa impostazione o se il deployment è stato eseguito con il valore impostato su `external`, il nuovo deployment con questo criterio impostato su `internal` rimuove gli indirizzi IP esterni temporanei dalle tue 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 indirizzare un'azione a un gruppo di istanze. Ad esempio, osserva l'utilizzo dei flag `--source-tags` e `--target-tags` nel comando compute firewalls-create. Se non specificato, l'istanza viene taggata con `aef-INSTANCE_ID` quando non viene utilizzato il VPC condiviso. Se viene utilizzato un VPC condiviso, l'istanza include sia `aef-INSTANCE_ID and aef-instance.`
`subnetwork_name`	Facoltativo. Puoi segmentare la rete e utilizzare una subnet personalizzata. Assicurati che la rete `name` sia specificata. 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/subnetworks/default`).La subnet deve trovarsi nella stessa regione dell'applicazione.
`session_affinity`	Facoltativo. Imposta `true` per configurare App Engine in modo da instradare più richieste sequenziali per un determinato utente alla stessa istanza di App Engine, ad esempio quando i dati utente vengono archiviati localmente durante una sessione. L'affinità sessione consente di ispezionare il valore di un cookie per identificare più richieste dello stesso utente, quindi indirizza tutte queste richieste alla stessa istanza. Se l'istanza viene riavviata, non è integro, è sovraccarico o non è disponibile dopo lo scale down del numero di istanze, l'affinità sessione viene interrotta e ulteriori richieste vengono instradate a un'altra istanza. Tieni presente che l'attivazione 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`). `HOST_PORT` deve essere compreso tra 1024 e 65535 e non può essere in conflitto con le seguenti porte: 22, 8080, 8090, 8443, 10000, 10001, 10400-10500, 11211, 24231. `CONTAINER_PORT` deve essere compreso tra 1 e 65535 e non può essere in conflitto con le seguenti porte: 22, 10001, 10400-10500, 11211. Se specifichi solo un valore `PORT`, App Engine presuppone che si tratti della stessa porta sull'host e sul container. Per impostazione predefinita, viene inoltrato il traffico TCP e UDP. Il traffico deve essere indirizzato direttamente all'indirizzo IP dell'istanza di destinazione anziché sul dominio appspot.com o sul 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 azienda in ogni rete.

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. In caso contrario, scopri come creare altri tipi di VPN.

Port forwarding

Il port forwarding consente le connessioni dirette al container Docker sulla di Compute Engine. Questo traffico può viaggiare su qualsiasi protocollo. Il port forwarding è il suo scopo è aiutare nelle situazioni in cui potrebbe essere necessario collegare un debugger o profiler. Il traffico deve essere indirizzato direttamente all'indirizzo IP dell'istanza di destinazione anziché sul dominio appspot.com o sul tuo dominio personalizzato.

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

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

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

Nelle impostazioni della 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 nel Console Google Cloud o utilizzando gcloud compute firewall-rules create per consentire il traffico da qualsiasi sorgente (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. La macchina viene di fornire almeno il livello di risorse che hai specificato, averne di più.

Puoi specificare fino a otto volumi di tmpfs nelle impostazioni delle risorse. Puoi quindi abilitare i carichi di lavoro che richiedono memoria condivisa tramite tmpfs e possiamo migliorare 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 la tua applicazione, che non includono i circa 0,4 GB di memoria necessari per l'overhead di i processi di machine learning. 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 tra 1,6 e 12,6 GB. La quantità totale di memoria disponibile l'applicazione viene impostata dall'ambiente di runtime come ambiente la variabile `GAE_MEMORY_MB`.	0,6 GB
`disk_size_gb`	Dimensioni in GB. Il valore minimo è 10 GB e il massimo è 10.240 GB.	13 GB
`name`	Obbligatorio, se utilizzi volumi. Nome del volume. I nomi devono essere univoci 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 è montato nel container dell'app come `/mnt/NAME`.
`volume_type`	Obbligatorio, se utilizzi volumi. Deve essere `tmpfs`.
`size_gb`	Obbligatorio, se utilizzi volumi. Dimensione del volume, in GB. Il minimo è 0,001 GB e il massimo è la quantità di memoria disponibile container di applicazioni e sul dispositivo sottostante. Google non aggiunge di RAM aggiuntiva al sistema per soddisfare i requisiti del disco. RAM allocata per volumi tmpfs sarà sottratta dalla memoria disponibile il container dell'app. La precisione dipende dal sistema.

Suddividi i controlli di integrità

Per impostazione predefinita, sono abilitati i controlli di integrità suddivisi. Puoi usare il controllo di integrità periodico per confermare l'avvenuto deployment di un'istanza VM e per verifica che un'istanza in esecuzione mantenga uno stato integro. Ogni controllo di integrità deve in un intervallo di tempo specificato.

Un'istanza è in stato non integro quando non riesce a rispondere a un numero specificato di di richieste di controllo di integrità consecutive. Se un'istanza non è attiva, è stata riavviata. Se un'istanza non è pronta, non riceverà alcun client richieste. Un controllo di integrità può anche avere esito negativo 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 in esecuzione. App Engine riavvia le istanze in stato non integro.
I controlli di idoneità confermano che l'istanza è pronta per l'accettazione richieste in arrivo. Le istanze che non superano il controllo di idoneità non vengono aggiunte al e il pool di istanze disponibili.

Per impostazione predefinita, le richieste HTTP dei controlli di integrità non vengono inoltrate al tuo container di applicazioni. Se vuoi estendere i controlli di integrità alla tua applicazione, e specificare un percorso per i controlli di attività controlli di idoneità. Un controllo di integrità personalizzato un'applicazione viene considerata riuscita 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 considerate non integre vengono riavviate.

Puoi personalizzare le richieste di controllo dell'attività aggiungendo un elemento liveness_check facoltativo sezione al tuo 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`	Nessuno		Se vuoi che i controlli di attività vengano inoltrati alla tua richiesta container, specifica un percorso dell'URL, ad esempio `"/liveness_check"`
`timeout_sec`	4 secondi	1-300	Intervallo di timeout in secondi per ogni richiesta.
`check_interval_sec`	30 secondi	1-300	Intervallo di tempo tra i controlli, in secondi. Tieni presente che questo valore deve sia maggiore di timeout_sec.
`failure_threshold`	4 controlli	1-10	Un'istanza è in stato non integro dopo aver generato un errore in questo numero di istanze controlli.
`success_threshold`	2 controlli	1-10	Un'istanza in stato non integro diventa di nuovo integro dopo a questo numero di controlli consecutivi.
`initial_delay_sec`	300 secondi	0-3600	Il ritardo, in secondi, dopo l'avvio dell'istanza durante il quale l'integrità le risposte di controllo vengono ignorate. Questa impostazione si applica a ogni creata e può concedere a una nuova istanza più tempo per funzionare in esecuzione. L'impostazione ritarda la riparazione automatica durante il controllo e, potenzialmente, ricreando prematuramente l'istanza se è in corso all'avvio. Il timer del ritardo iniziale si avvia quando l'istanza è in Modalità ESECUZIONE. Ad esempio, potresti voler aumentare il ritardo se le tue un'applicazione presenta attività di inizializzazione che richiedono molto tempo pronto a gestire il traffico.

Controlli di idoneità

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

Puoi personalizzare le richieste di controllo di integrità aggiungendo un elemento readiness_check facoltativo sezione al tuo 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`	Nessuno		Se vuoi che i controlli di idoneità vengano inoltrati alla tua richiesta container, specifica un percorso dell'URL, ad esempio `"/readiness_check"`
`timeout_sec`	4 secondi	1-300	Intervallo di timeout in secondi per ogni richiesta.
`check_interval_sec`	5 secondi	1-300	Intervallo di tempo tra i controlli, in secondi. Tieni presente che questo valore deve sia maggiore di timeout_sec.
`failure_threshold`	2 controlli	1-10	Un'istanza è in stato non integro dopo aver generato un errore in questo numero di istanze controlli.
`success_threshold`	2 controlli	1-10	Un'istanza in stato non integro diventa integro dopo 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 tempo di istanze di un deployment per superare i controlli di integrità. Se questo di durata superiore, il deployment non va a buon fine e ne viene eseguito il rollback. Il timer si avvia quando le istanze Compute Engine sono state di cui è stato eseguito il provisioning ed è stato creato il servizio di backend del bilanciatore del carico. Ad esempio, puoi aumentare il timeout se vuoi fornire timeout più lunghi durante i deployment per un numero sufficiente di l'integrità delle istanze.

Frequenza del controllo di integrità

Per garantire l'alta disponibilità, App Engine crea copie ridondanti di ogni integrità controllo. In caso di errore di un controllo di integrità, ne può prendere il controllo uno ridondante senza in ritardo.

Se esamini i log nginx.health_check per la tua applicazione, potresti vedere il polling del controllo di integrità si verifica più spesso di quanto tu abbia configurato, a causa i controlli di integrità ridondanti che seguono le tue impostazioni. Questi I controlli di integrità ridondanti vengono creati automaticamente e non è possibile configurare che li rappresentano.

Impostazioni di scalabilità del servizio

Le chiavi utilizzate per controllare la scalabilità di un servizio dipendono dal tipo 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

La tabella seguente elenca le impostazioni che puoi utilizzare con la scalabilità automatica:

Nome	Descrizione
`automatic_scaling`	Per impostazione predefinita viene utilizzata la scalabilità automatica. Includi questa riga se e specificare una qualsiasi delle impostazioni di scalabilità automatica.
`min_num_instances`	Il numero minimo di istanze assegnato al tuo servizio. Quando un servizio viene eseguito il deployment, riceve questo numero di istanze e scala al traffico. Deve essere `1` o superiore; il valore predefinito è `2` per ridurre una latenza di pochi millisecondi. Nota: il numero di istanze in esecuzione può diminuire inferiore a questo valore per un breve periodo di tempo durante alcuni eventi. Se richiede l'esecuzione continua su un certo numero di di Compute Engine, considera l'overprovisioning.
`max_num_instances`	Il numero massimo di istanze di cui il tuo servizio a cui è possibile fare lo scale up. Il numero massimo di istanze in il tuo progetto è limitato dalle quota delle risorse. Il valore predefinito è `20`.
`cool_down_period_sec`	Il numero di secondi che il gestore della scalabilità automatica deve attendere prima inizia a raccogliere informazioni da una nuova istanza. In questo modo al gestore della scalabilità automatica di raccogliere informazioni durante l'inizializzazione dell'istanza, durante i quali l'utilizzo raccolto non sarebbe affidabile. Relax deve essere maggiore o uguale a 60 secondi. Il valore predefinito è `120`.
`cpu_utilization`	Utilizza questa intestazione se specificherai la CPU target all'utilizzo delle risorse.
`target_utilization`	Utilizzo CPU target. L'utilizzo della CPU viene calcolato in media in tutte le istanze in esecuzione e viene utilizzato per decidere quando ridurre aumenta il numero di istanze. Tieni presente che le istanze sono ridimensionate indipendentemente dalle richieste in corso, 25 secondi dopo che un'istanza riceve il segnale di spegnimento. Il valore predefinito è `0.5`.
`target_concurrent_requests`	(Beta) Numero di destinazione 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 decidere quando ridurre o aumentare il numero di istanze. Un'istanza è ridimensionato 25 secondi dopo aver ricevuto il segnale di arresto, indipendentemente di richieste in corso. Se non specifichi un valore per questo parametro, il gestore della scalabilità automatica non ha come target un numero di connessioni simultanee per istanza. Le connessioni sono diverse dalle richieste. Una connessione può essere riutilizzata 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

La tabella seguente elenca le impostazioni che puoi utilizzare con la scalabilità manuale:

Nome	Descrizione
`manual_scaling`	Necessario per abilitare la scalabilità manuale di un servizio.
`instances`	Il numero di istanze da assegnare al servizio. Nota: il numero di istanze in esecuzione può diminuire inferiore a questo valore per un breve periodo di tempo durante alcuni eventi. Se richiede l'esecuzione continua su un certo numero di di Compute Engine, considera l'overprovisioning.

definisci le variabili di ambiente

Puoi definire le variabili di ambiente in app.yaml per renderle disponibili la 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 che vuoi definire e ogni voce di variabile di ambiente è rientrata di due spazi sotto l'elemento env_variables.