Riferimento app.yaml di App Engine

ID regione

REGION_ID è un codice abbreviato assegnato da Google in base alla regione selezionata al momento della creazione dell'app. Il codice non corrispondono a un paese o a una provincia, anche se potrebbero essere visualizzati alcuni ID regione in modo simile ai codici paese e provincia 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.

Ok

Configura le impostazioni dell'app App Engine nel file app.yaml. Questo file specifica in che modo i percorsi degli URL corrispondono ai gestori di richieste e file statici. 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.

Struttura delle directory

Per scoprire di più 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 file PHP 5 applicazione:

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 riportato sopra servirà i file con estensione gif, png o jpg come risorse statiche. I file sono stati configurati in modo da essere leggibili dal del codice dell'applicazione in fase di runtime.

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

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

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

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
application	Avviso: l'elemento application in oltre a utilizzare gli strumenti appcfg sono state arresto. Segui le istruzioni riportate di seguito per specificare la tua applicazione utilizzando il Strumenti Google Cloud CLI come gcloud. L'approccio consigliato consiste nel rimuovere application del file app.yaml e utilizza invece un del 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'uso di questi comandi, vedi Deployment dell'app. L'ID applicazione è l'ID progetto della console Google Cloud specificato quando hai creato l'applicazione nella console Google Cloud.
api_version	Obbligatorio. La versione dell'API utilizzata nell'ambiente di runtime specificato dalla tua app. Questo campo è obsoleto nei runtime App Engine più recenti. Quando Google annuncia il supporto di una nuova versione di l'API dell'ambiente di runtime, l'app di cui hai eseguito il deployment continuerà a utilizzare una per cui è stata scritta. Per eseguire l'upgrade dell'app a una nuova versione di l'API, modifichi questo valore ed esegui nuovamente il deployment dell'app di ricerca. Se specifichi il valore 1 viene utilizzato l'ambiente di runtime più recente supportato ogni volta che implementare l'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 tipi di dati statici gestori di file 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, dove le unità possono essere d per giorni, h per 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 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 la sezione Scadenza della cache.
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 "_"). Variabili di ambiente precedute dal prefisso GAE sono riservate all'uso del sistema e non sono consentite in 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 recuperare il valore di queste variabili utilizzando getenv() o $_SERVER, ma non $_ENV. I seguenti comandi restituiscono il valore della variabile di ambiente MY_VAR: echo getenv('MY_VAR'); oppure echo $_SERVER['MY_VAR'];
error_handlers	Facoltativo. Utilizzato per configurare pagine di errore personalizzate restituite per diversi tipi di errore. Questo elemento può contenere i seguenti elementi: error_code 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 che la tua app risponda. Il codice errore è facoltativo; se non è specificato, il file specificato è la risposta di errore predefinita per l'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. Avviso: assicurati che il percorso del file di risposta di errore non si sovrapponga ai percorsi dei gestori dei file statici. I dati di errore personalizzati devono essere inferiori a 10 kilobyte. Esempio error_handlers: - file: default_error.html - error_code: over_quota file: over_quota.html
handlers	Obbligatorio. 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 abilitare questi servizi prima di poter ricevere messaggi in entrata richieste. Puoi attivare il servizio per un'app PHP 5 includendo una sezione inbound_services nel app.yaml file. Sono disponibili i seguenti servizi in entrata: mail Consente all'applicazione di ricevere posta. warmup Abilita le richieste di warmup. Consulta Configurazione delle richieste di warmup. Esempio: inbound_services: - mail - warmup
instance_class	Facoltativo. La classe 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, B8 Valore predefinito: B2 Le classi di istanze di base e manuali richiedono di specificare l'elemento basic_scaling o l'elemento manual_scaling.
module	Nota: i moduli ora si chiamano Servizi. Per gestire la tua app con gcloud CLI, utilizza service.
runtime	Obbligatorio. Il nome dell'ambiente di runtime utilizzato dalla tua app. Ad esempio, per specificare PHP 5, utilizza: runtime: php55
service	I servizi erano precedentemente noti come Moduli. Supportato solo dall'interfaccia a riga di comando gcloud o dai plug-in basati su gcloud CLI, ad esempio: gcloud app deploy . 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 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 i servizi dichiarati come moduli, ad esempio: module: service-name
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 viene utilizzato per accedere ad altri servizi 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 nell'elemento della directory delle applicazioni non devono essere caricate in App Engine. Il valore è un'espressione regolare o un elenco di espressioni regolari. Qualsiasi nome file corrispondente a una qualsiasi delle espressioni regolari viene omesso dall'elenco dei file da caricare quando l'applicazione viene caricato. I nomi file sono relativi alla directory del progetto. skip_files ha le seguenti impostazioni predefinite: skip_files: - ^(.*/)?#.*#$ - ^(.*/)?.*~$ - ^(.*/)?.*\.py[co]$ - ^(.*/)?.*/RCS/.*$ - ^(.*/)?\..*$ Il pattern predefinito esclude i file di backup di Emacs con nomi nel modulo #...# e ...~, .pyc e .pyo file, file in un controllo di revisione RCS e i file nascosti Unix i cui nomi iniziano con un punto (.). Per estendere l'elenco di espressioni regolari riportato sopra, copia e incolla l'elenco in app.yaml e aggiungi le tue espressioni regolari. Ad esempio, per saltare i file i cui nomi terminano con .bak oltre ai pattern predefiniti, aggiungi una voce come questa per skip_files: skip_files: - ^(.*/)?#.*#$ - ^(.*/)?.*~$ - ^(.*/)?.*\.py[co]$ - ^(.*/)?.*/RCS/.*$ - ^(.*/)?\..*$ - ^(.*/)?.*\.bak$ Per saltare una directory completa, aggiungi il nome della directory all'elenco. Ad esempio, per saltare una directory denominata logs, aggiungi la seguente riga a quelle descritte in precedenza: skip_files: - logs/
version	L'approccio consigliato consiste nel rimuovere version del file app.yaml e utilizza invece un del flag della riga di comando per specificare l'ID versione: Per utilizzare il comando gcloud app deploy, devi specificare Flag -v: gcloud app deploy -v [YOUR_VERSION_ID] Per ulteriori informazioni sull'uso di questo comando, vedi 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. it non può iniziare con il prefisso ah- e i nomi default e latest sono prenotati e non possono . Nota: i nomi delle versioni devono iniziare con una lettera per distinguerli dalle istanze numeriche, che sono sempre specificate da un numero. Questo 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, il target sarà la versione "123" del servizio in questione. Se questa versione non esiste, il target sarà l'istanza numero 123 della versione predefinita del servizio. Ogni versione di un'applicazione conserva la propria copia app.yaml. Quando un'applicazione viene caricata, la versione menzionato nel file app.yaml che viene caricato, che viene creata o sostituita dal caricamento. Un amministratore può cambiare la versione dell'applicazione che gestisce il traffico mediante la console Google Cloud e anche prova altre versioni prima di configurarle per ricevere traffico.

Elemento Handlers

L'elemento handlers è obbligatorio nel file di configurazione app.yaml. L'elemento 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, a partire da dall'alto verso il basso. Il primo mapping il cui pattern corrisponde all'URL è quello utilizzato per gestire la richiesta.

La tabella seguente elenca 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 in gestori di file statici vengono caricati come dati statici e mostrati solo agli utenti finali. Loro 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 per il codice e i dati statici. Questo campo è ritirato nei runtime di App Engine più recenti.
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 i minuti e s per i 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 valore È in uso default_expiration. Per ulteriori dettagli, consulta la sezione Scadenza della cache.
http_headers	Facoltativo. Puoi impostare HTTP intestazioni per le risposte del file statico o della directory e i gestori di rete. Se devi impostare le intestazioni HTTP nei gestori script, devi farlo nel codice dell'app. Per informazioni su quali intestazioni di risposta influenzano la memorizzazione nella cache, consulta la sezione Memorizzazione nella cache 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 la condivisione delle risorse tra origini (CORS), ad esempio l'accesso ai file ospitati da un'altra app App Engine. Ad esempio, potresti avere l'app di gioco mygame.uc.r.appspot.com che accede agli asset ospitati da myassets.uc.r.appspot.com. Tuttavia, se mygame tenta di creare un codice JavaScript XMLHttpRequest a myassets, non riuscito a meno che il gestore di myassets non restituisca un L'intestazione della risposta Access-Control-Allow-Origin: contiene 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 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 saranno pubblicati utilizzando il tipo MIME specificato. Se non specificato, il tipo MIME di un file verrà ricavata dall'estensione del nome file del 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 Impostazione secure per configurare il codice di risposta HTTP restituito quando si esegue un reindirizzamento richiesto da secure l'impostazione è stata configurata. L'elemento redirect_http_response_code ha quanto segue valori possibili: 301 Codice di risposta Spostato in modo permanente. 302 Codice di risposta trovato. 303 Vedi Codice di risposta: altro. 307 Codice di risposta del reindirizzamento temporaneo. Esempio handlers: - url: /youraccount/.* script: accounts.php 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 il percorso dello script dalla directory radice dell'applicazione directory: ... handlers: - url: /profile/(.*)/(.*) script: /employee/\2/\1.php # specify a script Nei runtime App Engine più recenti, il comportamento di questo campo è cambiato.
secure	Facoltativo. Qualsiasi gestore di URL può utilizzare l'impostazione secure, inclusi i gestori di script e i 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 è il valore predefinito quando secure non viene fornito per un gestore. 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: accounts.php secure: always Il server web di sviluppo non supporta le connessioni HTTPS. Ignora il parametro secure, pertanto i percorsi destinati all'utilizzo con HTTPS possono essere testati utilizzando connessioni HTTP standard al server web di sviluppo. Per scegliere come target una versione specifica della tua app utilizzando il dominio REGION_ID.r.appspot.com, sostituisci i punti che di solito separano i componenti del sottodominio dell'URL con la stringa "-dot-", ad esempio: https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com Per utilizzare domini personalizzati con HTTPS, devi prima attivare e configurare i certificati SSL per quel dominio. L'accesso e la disconnessione 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 corrispondente all'estensione del nome file, a meno che non venga sostituito dall'impostazione mime_type della directory. Tutti i file della 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 in formato statico . App Engine archivia e pubblica i file statici separatamente dai file dell'app. I file statici non sono disponibili nell'app per impostazione predefinita. Questa opzione può essere modificata impostando il 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 i percorsi dei file statici caricati con l'applicazione. Pattern URL l'espressione regolare può definire i 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 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 in del file system dell'applicazione per impostazione predefinita. Questa opzione può essere modificata impostando application_readable su true. I file statici non possono essere uguali ai file di codice dell'applicazione. Se un percorso file statico corrisponde a un percorso di 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 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 vengono gestiti separatamente dai file dell'applicazione. L'esempio riportato sopra potrebbe utilizzare il seguente pattern upload: archives/(.*)/items/(.*)
url	Elemento obbligatorio in handlers. Il pattern URL, come un'espressione regolare. L'espressione può contenere raggruppamenti a cui fare riferimento nel percorso del file dello script con i riferimenti incrociati delle espressioni regolari. 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 dei 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 directory senza dover mappare l'intera directory.

Ridimensionare gli elementi

Gli elementi nella tabella seguente configurano la scalabilità dell'applicazione. Per apprendere ulteriori informazioni sulla scalabilità delle app di App Engine, vedi Tipi di scalabilità.

Elemento	Descrizione
automatic_scaling	Facoltativo. Applicabile solo per le applicazioni che utilizzano un'etichetta istanza F1 o superiore. Specifica questo elemento per modificare le impostazioni predefinite per la scalabilità automatica, come l'impostazione di livelli minimi e massimi per il numero di istanze, la latenza e le 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 per l'applicazione Motore da creare per questa versione del modulo. È utile per limitare solo i costi di un modulo. min_instances Avviso: per il corretto funzionamento di questa funzionalità, devi assicurarti che le richieste di preriscaldamento siano attivate e che la tua applicazione le gestisca. Nota: questa impostazione si applica solo se la versione dell'app definita da questo file app.yaml è configurata per ricevere traffico. Per scoprire di più sui percorsi, il traffico verso versioni diverse di un'app, consulta Suddivisione del traffico. Facoltativo. Il numero minimo di istanze che App Engine deve per questa versione del modulo. Queste istanze gestiscono il traffico quando e continuano a gestire il traffico anche e le istanze aggiuntive avviate in base alle necessità 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 delle istanze Ridurre i costi se non vengono gestite richieste. Tieni presente che ti viene addebitato il costo per il 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 ulteriormente il numero di istanze inattive gradualmente 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 riduce i costi di gestione, ma può ridurne la qualità le prestazioni a fronte di livelli di carico volatile. Nota:per tornare ai livelli normali dopo un 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 Avviso: per il corretto funzionamento di questa funzionalità, devi assicurarti che le richieste di preriscaldamento siano attivate e che la tua applicazione le gestisca. Nota: questa impostazione si applica solo se la versione dell'app definita da questo file app.yaml è configurata per ricevere traffico. Per scoprire di più su come indirizzare il traffico su versioni diverse di un'app, consulta Sdividere il traffico. (Facoltativo) Il numero di istanze aggiuntive da mantenere in esecuzione e pronte a gestire il traffico per questa versione. App Engine calcola il numero di istanze necessarie per gestire il traffico corrente dell'applicazione in base alle impostazioni di scalabilità come target_cpu_utilization e target_throughput_utilization. L'impostazione min_idle_instances specifica il numero di istanze da 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 stai addebitato per il numero di istanze specificato che ricevono traffico o meno. Tieni presente che: Un minimo basso aiuta a mantenere bassi i costi di esercizio in caso di inattività ma significa che un numero minore di istanze potrebbe disponibili per rispondere a un improvviso picco di carico. Un minimo elevato ti consente di preparare l'applicazione dei picchi nel carico delle richieste. App Engine mantiene il 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, latenza in sospeso avrà meno impatto sulle prestazioni della tua applicazione. target_cpu_utilization Facoltativa. Specifica un valore compreso tra 0,5 e 0,95. L'impostazione predefinita è 0.6. Questo parametro specifica la soglia di utilizzo della CPU alla quale le nuove istanze iniziato a gestire il traffico, consentendoti di bilanciare le prestazioni e i costi, con valori più bassi che aumentano le prestazioni e un aumento dei costi e valori più alti che riducono il rendimento, e la riduzione dei costi. Ad esempio, il valore 0,7 significa che vengono avviate quando l'utilizzo della CPU raggiunge il 70%. target_throughput_utilization Facoltativo. Specifica un valore compreso tra 0,5 e 0,95. Il valore predefinito è 0.6. Utilizzato con max_concurrent_requests per specificare quando viene avviata una nuova istanza a causa di richieste concorrenti. Quando di richieste in parallelo raggiunge un valore uguale a max_concurrent_requests volte target_throughput_utilization, lo scheduler prova per 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: 5, valore massimo: 1000). Utilizzato con target_throughput_utilization per specificare quando viene avviata una nuova istanza a causa di richieste in parallelo. 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 elevata, la latenza dell'API potrebbe aumentare. Tieni presente che il programmatore potrebbe generare una nuova istanza prima che venga raggiunto il numero massimo effettivo di richieste. max_pending_latency Il periodo di tempo massimo che App Engine deve consentire di inviare una richiesta di attendere in coda prima di avviare istanze aggiuntive per gestire le richieste in modo da ridurre latenza in sospeso. 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 la pubblicazione delle loro richieste (se ci sono richieste in attesa e non sono disponibili istanze inattive per gestirle), ma il costo di esecuzione dell'applicazione sarà inferiore. min_pending_latency Un elemento facoltativo che puoi impostare per specificare la quantità minima tempo in cui App Engine deve consentire l'attesa di una richiesta in attesa prima di avviare una nuova istanza per gestirla. La specifica di un valore può ridurre i costi di gestione, ma aumentare il tempo di attesa degli utenti per l'elaborazione delle 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: Meno del valore di 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'orario specificato da min_pending_latency e max_pending_latency, App Engine eseguirà e provare a 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 istanze di B1 o versioni successive devono specificare questo elemento o manual_scaling. Questo elemento consente la scalabilità di base delle classi di istanza B1 e superiori, 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 Facoltativo. L'istanza verrà arrestata dopo questo periodo di tempo dalla ricezione dell'ultima richiesta. Il valore predefinito è 5 minuti (5m). Esempio basic_scaling: max_instances: 11 idle_timeout: 10m
manual_scaling	Le applicazioni che utilizzano una classe di istanze di B1 o versioni successive 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