Riferimento app.yaml

ID regione

REGION_ID è un codice abbreviato assegnato da Google in base all'area geografica selezionata al momento della creazione dell'app. Il codice non corrisponde a un paese o a una provincia, anche se alcuni ID di area geografica potrebbero essere simili ai codici di paese e provincia di uso comune. Per le app create dopo febbraio 2020, REGION_ID.r è incluso negli URL di App Engine. Per le app esistenti create prima di questa data, l'ID area geografica è facoltativo nell'URL.

Scopri di più sugli ID dell'area geografica.

OK

Python 2.7/3 |Java 8/11/17 |PHP 5/7 |Ruby |Go 1.11 / 1.12+ |Node.js

Configura le impostazioni dell'app App Engine nel file app.yaml. Questo file specifica in che modo i percorsi dell'URL corrispondono ai gestori delle richieste e ai file statici. Il file app.yaml contiene anche informazioni sul codice dell'app, ad esempio il runtime e l'identificatore della versione più recente.

Ogni servizio nella tua app ha il proprio file app.yaml, che funge da descrittore per il deployment. Devi 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 dell'app.

Struttura delle directory

Per ulteriori informazioni su come strutturare più servizi nella tua app, vedi Strutturare i servizi web in App Engine.

Esempio

Di seguito è riportato un esempio di file app.yaml per un'applicazione PHP 5:

runtime: php55
api_version: 1

handlers:
# Serve images as static resources.
- url: /(.+\.(gif|png|jpg))$
  static_files: \1
  upload: .+\.(gif|png|jpg)$
  application_readable: true

# Serve php scripts.
- url: /(.+\.php)$
  script: \1

L'esempio precedente pubblicherà i file con estensione gif, png o jpg come risorse statiche. I file sono stati configurati in modo da essere leggibili dal codice dell'applicazione in fase di runtime.

L'esempio pubblicherà anche tutti gli script PHP. Puoi limitare il gestore degli script a script a livello principale utilizzando l'espressione url: /([^/]+\.php). Le applicazioni esistenti potrebbero essere utili per simulare Apache mod_rewrite $_GET['q']routing.

Di seguito è riportata una configurazione più completa di app.yaml:

runtime: php55
api_version: 1

handlers:
- url: /
  script: home.php

- url: /index\.html
  script: home.php

- url: /stylesheets
  static_dir: stylesheets

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

- url: /admin/.*
  script: admin.php
  login: admin

- url: /.*
  script: not_found.php

Syntax

La sintassi di app.yaml è il formato YAML.

Il formato YAML supporta i commenti. Una riga che inizia con un carattere di cancelletto (#) viene ignorata:

# This is a comment.

Per i pattern di URL e percorsi dei file viene usata la sintassi estesa delle espressioni regolari, esclusi gli elementi di confronto e le classi di confronto. Sono supportati i riferimenti 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
application	Avviso: l'elemento application oltre a utilizzare gli strumenti appcfg è stato chiuso. Consulta le istruzioni riportate di seguito per specificare la tua applicazione utilizzando gli strumenti dell'interfaccia a riga di comando di Google Cloud, come la riga di comando gcloud. L'approccio consigliato è rimuovere l'elemento application dal file app.yaml e usare invece un flag della riga di comando per specificare l'ID applicazione: Per utilizzare il comando gcloud app deploy, devi specificare il flag --project: gcloud app deploy --project [YOUR_PROJECT_ID] Per ulteriori informazioni sull'utilizzo di questi comandi, vedi Deployment dell'applicazione. L'ID applicazione è l'ID progetto Cloud Console che hai specificato al momento della creazione dell'applicazione in Google Cloud Console.
api_version	Obbligatorio. La versione dell'API nell'ambiente di runtime specificato utilizzata dalla tua app. Questo campo è deprecato nei runtime di App Engine più recenti. Quando Google annuncia il supporto di una nuova versione di un ambiente runtime, l'app di cui hai eseguito il deployment continuerà a utilizzare l'API per cui è stata scritta. Per eseguire l'upgrade dell'app a una nuova versione dell'API, devi modificare questo valore e quindi eseguire nuovamente il deployment dell'app in App Engine. Quando specifichi il valore 1, viene utilizzato l'ambiente di runtime più recente ogni volta che esegui il deployment dell'app (attualmente ). Al momento, App Engine ha una versione dell'ambiente di runtime php: 1
default_expiration	(Facoltativo) Imposta un periodo di cache predefinito globale per tutti i gestori di file statici per 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, in cui le unità possono essere utilizzate d per giorni, h per ore, m per minuti e s per secondi. Ad esempio, "4d 5h" imposta la scadenza della cache su 4 giorni e 5 ore dopo la prima richiesta del file. Se omesso, il server di produzione imposta la scadenza su 10 minuti. Esempio: runtime: php55 api_version: 1 default_expiration: "4d 5h" handlers: # ... Per ulteriori informazioni, consulta Scadenza della cache.
env_variables	(Facoltativo) Puoi definire variabili di ambiente nel file app.yaml per renderle disponibili per la tua app. Le variabili di ambiente con il prefisso GAE sono riservate per l'uso nel sistema e non sono consentite nel file app.yaml. 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 ciascuna voce di variabile di ambiente rientrata di due spazi sotto l'elemento env_variables. Per le variabili di ambiente non assegnato un valore predefinito, "None". Puoi quindi recuperare il valore di queste variabili utilizzando getenv() o $_SERVER, ma non $_ENV. I seguenti comandi fanno eco al valore della variabile di ambiente MY_VAR: echo getenv('MY_VAR'); o echo $_SERVER['MY_VAR'];
error_handlers	(Facoltativo) Utilizzato per configurare pagine di errore personalizzate che vengono 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 dos_api_denial Indica che la richiesta è stata bloccata dalla configurazione della protezione DoS dell'app. timeout Viene pubblicato se viene raggiunta una scadenza prima che si verifichi una risposta dalla tua app. Il campo error_code è facoltativo. Se non è specificato, il file fornito è la risposta all'errore predefinita dell'app. file Ogni voce del file indica un file statico da pubblicare 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 della tua app. Avviso: assicurati che il percorso del file di risposta di errore non si sovrapponga ai percorsi del gestore di file statici. 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	Obbligatorio. Un elenco di pattern URL e delle descrizioni di gestione. 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 e sottoelementi
inbound_services	(Facoltativo) Le applicazioni devono attivare questi servizi prima di poter ricevere richieste in entrata. Puoi abilitare il servizio per un'app PHP 5 includendo una sezione inbound_services nel file app.yaml. Sono disponibili i seguenti servizi in entrata: mail Consente all'applicazione di ricevere posta. warmup Abilita le richieste di preparazione. Consulta la pagina Configurare richieste di preparazione. Esempio: inbound_services: - mail - warmup
instance_class	(Facoltativo) La classe di istanza per questo servizio. I seguenti valori sono disponibili a seconda della scalabilità del servizio: Scalabilità automatica F1, F2, F4, F4_1G Predefinito: F1 Facoltativamente, utilizza l'elemento automatic_scaling per modificare le impostazioni predefinite per la scalabilità automatica, come il numero minimo e massimo di istanze, la latenza e le connessioni simultanee. Nota: se instance_class è impostato su F2 o 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 le prestazioni della tua applicazione. Scalabilità di base e manuale B1, B2, B4, B4_1G, B8 Predefinito: B2 Le classi di istanza manuali e di base richiedono di specificare l'elemento basic_scaling o l'elemento manual_scaling.
module	Nota: i moduli ora si chiamano Servizi. Per gestire l'app con l'interfaccia a riga di comando gcloud, utilizza invece l'elemento service.
runtime	Obbligatorio. Il nome dell'ambiente di runtime utilizzato dalla tua app. Per specificare PHP 5, utilizza: runtime: php55
service	I servizi in precedenza erano noti come Moduli. Supportato solo dall'interfaccia a riga di comando gcloud o gcloud CLI, ad esempio: gcloud app deploy . Obbligatorio se si crea 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 versione, SERVICE è il nome del servizio e PROJECT_ID è l'ID del progetto. Non può superare i 63 caratteri e non può iniziare o terminare con un trattino. Scegli un nome univoco per ogni servizio e ogni versione. Non riutilizzare i nomi tra servizi e versioni. Esempio: service: service-name Nota: il comando gcloud app deploy è compatibile con le versioni precedenti e supporta i file app.yaml esistenti che includono servizi dichiarati come moduli, ad esempio: module: service-name
service_account	Anteprima - Using user-managed service accounts with App Engine Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio. (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 di Google Cloud ed eseguire attività. Esempio: service_account: [SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com
skip_files	(Facoltativo) L'elemento skip_files specifica quali file nella directory delle applicazioni non devono essere caricati in App Engine. Il valore è un'espressione regolare o un elenco di espressioni regolari. I nomi di file che corrispondono a una qualsiasi delle espressioni regolari vengono omessi dall'elenco di file da caricare quando viene caricata l'applicazione. I nomi file sono relativi alla directory del progetto. skip_files ha i seguenti valori predefiniti: skip_files: - ^(.*/)?#.*#$ - ^(.*/)?.*~$ - ^(.*/)?.*\.py[co]$ - ^(.*/)?.*/RCS/.*$ - ^(.*/)?\..*$ Il pattern predefinito esclude i file di backup di Emacs con nomi nel formato #...# e ...~, i file .pyc e .pyo, i file in una directory di controllo delle revisioni RCS e i file nascosti di Unix con nomi che iniziano con un punto (.). Per estendere l'elenco di espressioni regolari riportato sopra, copia e incolla questo elenco in app.yaml e aggiungi le tue espressioni regolari. Ad esempio, per saltare i file i cui nomi terminano in .bak oltre ai pattern predefiniti, aggiungi una voce come questa per skip_files: skip_files: - ^(.*/)?#.*#$ - ^(.*/)?.*~$ - ^(.*/)?.*\.py[co]$ - ^(.*/)?.*/RCS/.*$ - ^(.*/)?\..*$ - ^(.*/)?.*\.bak$ Per ignorare una directory completa, aggiungi il nome della directory all'elenco. Ad esempio, per ignorare una directory denominata logs, aggiungi la seguente riga a quelle descritte in precedenza: skip_files: - logs/
version	L'approccio consigliato è rimuovere l'elemento version dal file app.yaml e usare invece un flag della riga di comando per specificare l'ID versione: Per utilizzare il comando gcloud app deploy, devi specificare il flag -v: gcloud app deploy -v [YOUR_VERSION_ID] Per ulteriori informazioni sull'utilizzo di questo comando, consulta la pagina Deployment dell'app. Un identificatore per la versione del codice dell'applicazione di cui esegui il deployment in App Engine. L'ID versione può contenere lettere minuscole, cifre e trattini. Non può iniziare con il prefisso ah- e i nomi default e latest sono riservati e non possono essere utilizzati. Nota: i nomi delle versioni devono iniziare con una lettera, per distinguerli dalle istanze numeriche che sono sempre specificate da un numero. In questo modo si evita l'ambiguità con URL come 123-dot-my-service.uc.r.appspot.com, che può essere interpretato in due modi: se la versione "123" esiste, la destinazione sarà la versione 123 del servizio fornito. Se la versione non esiste, la destinazione sarà l'istanza numero 123 della versione predefinita del servizio. Ogni versione di un'applicazione conserva la propria copia di app.yaml. Quando viene caricata un'applicazione, la versione menzionata nel file app.yaml è la versione che viene creata o sostituita dal caricamento. Un amministratore può cambiare la versione dell'applicazione che gestisce il traffico mediante Google Cloud Console e puoi anche testare altre versioni prima di configurarle in modo da ricevere il traffico.

Elemento Gestori

L'elemento handlers è un elemento obbligatorio nel file di configurazione app.yaml. L'elemento fornisce un elenco di pattern URL e descrizioni su 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.

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
application_readable	(Facoltativo) Valore booleano. Per impostazione predefinita, i file dichiarati nei gestori dei file statici vengono caricati come dati statici e vengono pubblicati solo per gli utenti finali. Non possono essere letti da un'applicazione. Se questo campo è impostato su true, i file vengono caricati anche come dati di codice, in modo che l'applicazione possa leggerli. Entrambi i caricamenti vengono addebitati in base alle quote delle risorse di archiviazione del codice e dei dati statici. Questo campo è deprecato nei runtime di App Engine più recenti.
expiration	(Facoltativo) La durata di un file statico pubblicato da questo gestore deve essere memorizzato nella cache da proxy e browser web. Il valore è una stringa di numeri e unità separati da spazi, in cui 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 su 4 giorni e 5 ore dopo la richiesta iniziale del file. Se omesso, viene usato il default_expiration dell'applicazione. Consulta Scadenza della cache per ulteriori dettagli.
http_headers	(Facoltativo) Puoi impostare intestazioni HTTP per le risposte dei gestori dei file o delle directory statici. Se devi impostare intestazioni HTTP nei gestori script, devi farlo nel codice dell'app. Per informazioni su quali intestazioni di risposta influiscono sulla memorizzazione nella cache, consulta la 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à è quello di supportare la condivisione delle risorse tra origini (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 cerca di creare un elemento JavaScript XMLHttpRequest in myassets, non avrà esito positivo a meno che il gestore per myassets non restituisca un'intestazione di risposta Access-Control-Allow-Origin: contenente il valore http://mygame.uc.r.appspot.com. Ecco come rendere il gestore del file statico restituire quel valore di intestazione della risposta richiesto: 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 alle tue risorse, puoi utilizzare il carattere jolly '*' anziché https://mygame.uc.r.appspot.com.
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à estratto dall'estensione del nome file. Se lo stesso file viene caricato con più estensioni, l'estensione risultante può dipendere dall'ordine in cui si sono verificati. Per ulteriori informazioni sui possibili tipi di contenuti multimediali 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 configurare il codice di risposta HTTP restituito quando si esegue 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 Altro codice di risposta. 307 Codice di risposta reindirizzamento temporaneo. Esempio handlers: - url: /youraccount/.* script: accounts.php secure: always redirect_http_response_code: 301 Quando viene reindirizzata una richiesta di un utente, il codice di stato HTTP verrà impostato sul valore del parametro redirect_http_response_code. Se il parametro non è presente, verrà restituito 302.
script	(Facoltativo) Specifica il percorso dello script dalla directory principale dell'applicazione: ... handlers: - url: /profile/(.*)/(.*) script: /employee/\2/\1.php # specify a script Nei runtime più recenti di App Engine, il comportamento di questo campo è cambiato.
secure	(Facoltativo) Qualsiasi gestore di URL può utilizzare l'impostazione secure, inclusi i gestori degli script e i gestori di file statici. L'elemento secure ha i seguenti valori possibili: optional Sia le richieste HTTP che HTTPS con URL corrispondenti al gestore hanno esito positivo senza reindirizzamenti. L'applicazione può esaminare la richiesta per determinare quale protocollo è stato utilizzato e rispondere di conseguenza. Questa è l'impostazione predefinita quando secure non è fornito per un gestore. never Le richieste di un URL che corrisponde a questo gestore che utilizzano HTTPS vengono reindirizzate automaticamente all'URL HTTP equivalente. Quando una richiesta HTTPS di un utente viene reindirizzata a una richiesta HTTP, i parametri di ricerca vengono rimossi dalla richiesta. Ciò impedisce a un utente di inviare accidentalmente dati delle query su una connessione non sicura che era prevista per una connessione sicura. always Le richieste di un URL che corrisponde a questo gestore 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: accounts.php secure: always Il server web di sviluppo non supporta le connessioni HTTPS. Ignora il parametro secure; pertanto, i percorsi destinati a essere utilizzati con HTTPS possono essere testati utilizzando normali connessioni HTTP al server web di sviluppo. Per scegliere come target una versione specifica della tua app utilizzando il dominio REGION_ID.r.appspot.com, devi sostituire i punti che generalmente 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 i domini personalizzati con HTTPS, devi prima attivare e configurare i certificati SSL per tale dominio. L'accesso e la disconnessione di Google Account vengono sempre eseguiti utilizzando una connessione sicura, non correlata alla configurazione degli URL dell'applicazione.
static_dir	(Facoltativo) Il percorso della directory contenente i file statici dalla directory radice dell'applicazione. Tutto ciò che si trova dopo 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 corrispondente alla relativa 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. Tutti i file in questa directory vengono caricati con la tua app come file statici. App Engine archivia e pubblica file statici separatamente dai file dell'app. I file statici non sono disponibili per impostazione predefinita nel file system dell'app. Puoi modificare questa opzione impostando l'opzione application_readable su true. 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 ai file statici caricati con l'applicazione. L'espressione regolare del pattern URL può definire raggruppamenti di espressioni regolari da utilizzare nella creazione del percorso del file. Puoi utilizzarlo al posto di static_dir per mappare file specifici in una struttura di directory senza mappare l'intera directory. Esempio: handlers: # All URLs ending in .gif .png or .jpg are treated as paths to # static files in the static/ directory. The URL pattern is a # regular expression, with a grouping that is inserted into the # path to the file. - url: /(.*\.(gif|png|jpg))$ static_files: static/\1 upload: static/.*\.(gif|png|jpg)$ # ... App Engine archivia e pubblica i file statici separatamente dai file dell'applicazione. I file statici non sono disponibili per impostazione predefinita nel file system dell'applicazione. Puoi modificare questa impostazione impostando l'opzione application_readable su true. I file statici non possono essere gli stessi dei file di codice dell'applicazione. Se un percorso di file statico corrisponde a un percorso a uno script utilizzato in un gestore dinamico, lo script non sarà disponibile per il gestore dinamico.
upload	(Facoltativo) Un'espressione regolare che corrisponde ai percorsi di tutti i file a cui verrà fatto riferimento da questo gestore. Ciò è necessario perché il gestore non è in grado di 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. L'espressione può contenere raggruppamenti a cui è possibile fare riferimento nel percorso del file con lo script mediante riferimenti regolari alle espressioni. 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 quando utilizzato con i seguenti elementi: static_dir Utilizza un prefisso URL. Il pattern Express regolare non deve contenere raggruppamenti se 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 raggruppamenti di espressioni regolari da utilizzare nella creazione 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 ulteriori informazioni sulla scalabilità delle app di App Engine, consulta la pagina relativa ai tipi di scalabilità.

Elemento	Descrizione
automatic_scaling	(Facoltativo) Applicabile solo per applicazioni che utilizzano una classe di istanza di livello F1 o superiore. Specifica questo elemento per modificare le impostazioni predefinite per la scalabilità automatica, come l'impostazione dei 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 può creare per questa versione del modulo. Questo è utile per limitare i costi di un modulo. min_instances Avviso: affinché questa funzionalità funzioni correttamente, devi assicurarti che le richieste di preparazione siano abilitate e che la tua applicazione gestisca le richieste di preparazione. Nota: questa impostazione si applica solo se la versione dell'app definita da questo file app.yaml è configurata per ricevere traffico. Per ulteriori informazioni sul routing del traffico a diverse versioni di un'app, consulta la Suddivisione del traffico. (Facoltativo) Il numero minimo di istanze che App Engine deve creare per questa versione del modulo. Queste istanze forniscono traffico all'arrivo delle richieste e continuano a gestire il traffico anche quando vengono avviate altre istanze come richiesto per gestire il traffico. Specifica un valore compreso tra 0 e 1000. Puoi impostare il parametro sul valore 0 per consentire la scalabilità a 0 istanze per ridurre i costi quando non vengono fornite richieste. Tieni presente che ti vengono addebitati i costi relativi al numero di istanze specificate, indipendentemente dal fatto che ricevano o meno traffico. 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. Ciò consente alla tua applicazione di mantenere prestazioni costanti tramite fluttuazioni nel carico delle richieste, ma anche di aumentare il numero di istanze inattive (e conseguenti costi di esecuzione) durante tali periodi di carico elevato. Un limite massimo basso comporta costi inferiori, ma può peggiorare le prestazioni di parità a livelli di carico volatili. Nota: quando si torna a livelli normali dopo un picco del carico, il numero di istanze inattive può superare temporaneamente il massimo specificato. Tuttavia, non ti verranno addebitate più istanze del numero massimo specificato. min_idle_instances Avviso: affinché questa funzionalità funzioni correttamente, devi assicurarti che le richieste di preparazione siano abilitate e che la tua applicazione gestisca le richieste di preparazione. Nota: questa impostazione si applica solo se la versione dell'app definita da questo file app.yaml è configurata per ricevere traffico. Per ulteriori informazioni sul routing del traffico a diverse versioni di un'app, consulta la Suddivisione del traffico. Facoltativo: il numero di istanze aggiuntive da mantenere in esecuzione e pronta per gestire il traffico per questa versione. App Engine calcola il numero di istanze necessarie per gestire il traffico attuale delle applicazioni in base a impostazioni di scalabilità come target_cpu_utilization e target_throughput_utilization. L'impostazione min_idle_instances specifica il numero di istanze per eseguire oltre a questo numero calcolato. Ad esempio, se App Engine calcola che sono necessarie 5 istanze per gestire il traffico e min_idle_instances è impostato su 2, App Engine eseguirà 7 istanze (5, calcolate in base al traffico, più altre 2 per min_idle_instances). Tieni presente che ti vengono addebitati i costi relativi al numero di istanze specificate, indipendentemente dal fatto che ricevano o meno traffico. Tieni presente che: Un minimo minimo aiuta a mantenere bassi i costi di esecuzione durante i periodi di inattività, ma significa che potrebbero essere immediatamente disponibili meno istanze per rispondere a un picco di carico improvviso. Un minimo elevato consente di invocare l'applicazione per picchi rapidi del carico delle richieste. App Engine mantiene il numero minimo di istanze in esecuzione per gestire le richieste in entrata. Ti viene addebitato il numero di istanze specificate, indipendentemente dal fatto che gestiscano o meno le richieste. Se imposti un numero minimo di istanze inattive, la latenza in sospeso avrà un effetto inferiore sulle prestazioni 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 base alla quale le nuove istanze inizieranno a gestire il traffico, consentendoti di bilanciare prestazioni e costi con valori inferiori in grado di aumentare le prestazioni e aumentare i costi, mentre i valori più alti diminuiscono le prestazioni, ma riducono anche i costi. Ad esempio, un valore pari a 0,7 significa che le nuove istanze verranno avviate dopo che l'utilizzo della CPU avrà raggiunto 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 in parallelo. Quando il numero di richieste in parallelo raggiunge un valore pari a max_concurrent_requests volte target_throughput_utilization, il programma di pianificazione tenta di avviare una nuova istanza. max_concurrent_requests (Facoltativo) Il numero di richieste in parallelo che un'istanza di scalabilità automatica può accettare prima che lo scheduler generi una nuova istanza (valore predefinito: 5, massimo 80). Utilizzato con target_throughput_utilization per specificare quando viene avviata una nuova istanza a causa di richieste in parallelo. Quando il numero di richieste in parallelo raggiunge un valore pari a max_concurrent_requests volte target_throughput_utilization, il programma di pianificazione 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 può comportare la creazione di un numero di istanze maggiore di quello necessario per un'app threadsafe, il che potrebbe comportare costi inutili. Se questa impostazione è troppo alta, potresti riscontrare una maggiore latenza API. Tieni presente che il programma di pianificazione potrebbe generare una nuova istanza prima di raggiungere il numero massimo effettivo di richieste. max_pending_latency Periodo di tempo massimo in cui App Engine dovrebbe consentire a una richiesta di attendere in coda in attesa prima di avviare istanze aggiuntive per gestire le richieste in modo da ridurre la latenza in attesa. Quando si raggiunge questa soglia, si tratta di un indicatore di scale up, che comporta un aumento del numero di istanze. Se non viene specificato, il valore predefinito è automatic. Ciò significa che le richieste possono rimanere nella coda in attesa per un massimo di 10 secondi, ovvero il limite massimo di richieste in attesa prima che venga attivata la nuova istanza. Un limite basso indica che App Engine avvia nuove istanze in anticipo per le richieste in attesa, migliorando le prestazioni ma aumentando i costi di esecuzione. Un numero massimo elevato indica che gli utenti potrebbero attendere più a lungo per la pubblicazione delle loro richieste (se sono presenti richieste in attesa e nessuna istanza inattiva al servizio), ma l'applicazione avrà un costo inferiore. min_pending_latency Un elemento facoltativo che puoi impostare per specificare il tempo minimo in cui App Engine deve consentire una richiesta di attesa nella coda in attesa prima di avviare una nuova istanza per gestirla. Se specifichi un valore, puoi ridurre i costi di esecuzione, ma aumentare il tempo di attesa degli utenti prima che le richieste vengano pubblicate. 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 in coda: Inferiore al min_pending_latency specificato, App Engine non creerà nuove istanze. Più di max_pending_latency, App Engine tenterà di creare una nuova istanza. Tra il periodo di tempo specificato 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 del giorno 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 di B1 o superiore devono specificare questo elemento o manual_scaling. Questo elemento consente la scalabilità di base delle classi di istanza B1 e successive, può contenere i seguenti elementi: max_instances Obbligatorio. Il numero massimo di istanze che App Engine può creare per questa versione del servizio. Ciò è utile per limitare i costi di un servizio. idle_timeout (Facoltativo) L'istanza verrà arrestata questo periodo di tempo dopo la 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 di B1 o superiore devono specificare questo elemento o basic_scaling. Questo elemento consente la scalabilità manuale delle classi di istanza B1 e superiori e può contenere il seguente elemento: instances Il numero di istanze da assegnare al servizio all'inizio. Esempio manual_scaling: instances: 5