Nota: Python 2.7 ha raggiunto fine del supporto il 31 gennaio 2024. Le applicazioni Python 2.7 esistenti continueranno a esistere per eseguire e ricevere traffico. Tuttavia, App Engine potrebbe bloccare il rideployment delle applicazioni che utilizzano i runtime al termine del periodo di assistenza. Ti consigliamo di eseguire la migrazione alla versione più recente supportata di Python.

Questa pagina è stata tradotta dall'API Cloud Translation.

Riferimento app.yaml per 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.

Configura le impostazioni dell'app App Engine in 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 e deployment continuo. Devi prima creare il file app.yaml per il servizio default prima di poter creare ed eseguire il deployment di file app.yaml per i servizi aggiuntivi all'interno di la 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 Python 2 applicazione:

runtime: python27
api_version: 1
threadsafe: true

handlers:
- url: /
  script: home.app

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

- url: /stylesheets
  static_dir: stylesheets

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

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

- url: /.*
  script: not_found.app

Un'istruzione script: può contenere un percorso file che termina con .py, che indica che lo script utilizza CGI, o un percorso del modulo Python, con i nomi dei pacchetti. sono separati da punti, il che significa che lo script utilizza WSGI.

Sintassi

La sintassi di app.yaml è il formato YAML.

Il formato YAML supporta i commenti. Una retta che inizia con il cancelletto (#) viene ignorato:

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

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 al momento della creazione dell'applicazione nel Console Google Cloud.
`api_version`	Obbligatorio. La versione dell'API utilizzata nell'ambiente di runtime specificato dalla tua app. Questo campo è ritirato 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 Ambiente di runtime `python27`: `1`
`auto_id_policy`	Facoltativo. Se sei impostazione automatica degli identificatori di entità, puoi modificare il metodo per impostare il criterio ID automatico. Di seguito sono riportate alcune opzioni valide: `default` Predefinita. Utilizza ID automatici sparsi che sono grandi e ben distribuiti numeri interi sufficientemente piccoli da essere rappresentati da numeri in virgola mobile a 64 bit. `legacy` L'opzione precedente verrà ritirata in una versione futura e verrà rimosso. Per ulteriori informazioni, leggi il post del blog in cui viene presentato modifica.
`builtins`	Facoltativo. L'SDK Python 2 include una serie di gestori integrati per funzioni di applicazione più comuni. Istruzione `builtins` ti consente di includere gestori specifici in `app.yaml`. Questo campo è ritirato nel runtime di Python 3. Puoi utilizzare i seguenti gestori integrati: `appstats` Attiva Appstat di `/_ah/stats/`, che puoi utilizzare per per misurare le prestazioni della tua applicazione. Per utilizzare Appstat, devi inoltre installa il registratore di eventi. `deferred` Attiva il gestore differito in `/_ah/queue/deferred`. Questa funzionalità integrata consente agli sviluppatori di usare `deferred.defer()` per semplificare la creazione delle attività delle code di attività. `remote_api` Consente di attivare `remote_api` integrata alle `/_ah/remote_api/`. Questa modalità integrata consente con le credenziali appropriate per accedere al datastore da remoto. . Esempio: builtins: - deferred: on - appstats: on L'istruzione `builtins` è un'istanza speciale del metodo `includes`. Ogni istruzione `builtin` è equivalente, in Python, a un'istruzione `includes` con un percorso espanso. Ad esempio: builtins: - name: on Equivale a: includes: - $PYTHON_LIB/google/appengine/ext/builtins/name/ Quando utilizzi `builtins` nel file `app.yaml`, a qualsiasi gestore definito nel Il file `include.yaml` prevarrà su tutti i gestori che hai definisci nel tuo file `app.yaml`. Tuttavia, se includi una che utilizza `builtins` o `includes`, I gestori vengono aggiunti in base all'ordine della gerarchia di inclusione. In altre parole, i gestori del "padre" vengono aggiunti prima integrati del "secondario" include e così via. Ad esempio, considera il seguente `app.yaml`, che utilizza il integrato Gestori `appstats`: handlers: - url: /.* script: main.app builtins: - appstats: on L'elenco di gestori risultante è: [/_ah/stats, /.] Se `app.yaml` utilizza un'istruzione `includes`: includes: - included.yaml E il file `included.yaml` utilizza `builtins`: handlers: - url: /. script: main.app builtins: - appstats: on L'elenco di gestori risultante è ora: [/.*, /_ah/stats] L'ordine di posizionamento della clausola `builtins` in una `.yaml` non modifica il comportamento.
`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 file statici specifici e i gestori di rete. 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 a 4 giorni e 5 ore dalla prima richiesta del file. Se omesso, il server di produzione imposta la scadenza a 10 minuti. Esempio: runtime: python27 api_version: 1 threadsafe: true default_expiration: "4d 5h" handlers: # ... Per ulteriori informazioni, vedi Cache scadenza.
`env_variables`	Facoltativo. Puoi definire le variabili di ambiente in `app.yaml` per renderle disponibili per la tua app. Assicurati che la chiave nelle 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. Queste variabili saranno disponibili in `os.environ` dizionario: env_variables: DJANGO_SETTINGS_MODULE: "myapp.settings"
`error_handlers`	Facoltativo. Utilizzato per configurare pagine di errore personalizzate che vengono restituite per diverse tipi di errori. Questo elemento può contenere i seguenti elementi: `error_code` Facoltativa. `error_code` può essere uno dei seguenti: `over_quota` Indica che l'app dispone di quota di risorse superata `timeout` Viene pubblicato se viene raggiunta una scadenza prima di ricevere una risposta da la tua app. . error_code è facoltativo; se non è specificato, il file specificato è la risposta di errore predefinita per la tua app. `file` Ogni voce di file indica un file statico che deve essere pubblicato in della risposta di errore generico. Se specifichi Elemento `file` senza un corrispondente Elemento `error_code`, il file statico sarà il valore predefinito pagina di errore relativa alla tua app. . Avviso: assicurati che il percorso dell'errore il file di risposta non si sovrappone ai percorsi dei gestori di 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 dovrebbero 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. Visualizza i gestori e gli elementi secondari sintassi
`includes`	Facoltativo. L'istruzione `includes` ti consente di includere file di configurazione per qualsiasi libreria o servizio nel tuo un'applicazione. Ad esempio, puoi includere un'amministrazione utenti libreria nel seguente modo: includes: - lib/user_admin.yaml App Engine risolve il percorso incluso nel seguente ordine: Percorso assoluto o relativo della directory di lavoro. Il valore specificato viene risolto in un file. Rispetto alla directory dell'applicazione, nota anche come basepath. Il percorso base e il percorso vengono risolti in un file. Rispetto al file che includeva il file corrente. La posizione di il file di riferimento e il percorso di inclusione si risolvono nel file . Se l'istruzione `include` specifica una directory, allora App Engine cerca in quella directory un file denominato `include.yaml`. Se l'istruzione di inclusione è un file, incluso il file. Utilizzo dei recuperi di `includes` solo i seguenti tipi di istruzioni dal file di destinazione (se attuale): `builtins` `includes` `handlers` `skip_files` `skip_files` pattern inclusi vengono aggiunti a quelli in incluso `app.yaml`, o all'elenco predefinito se non elenco esplicito in `app.yaml`. Tieni presente che `skip_files` confronta i percorsi assoluti.
`inbound_services`	Facoltativo. Le applicazioni devono attivare questi servizi prima di poter ricevere messaggi in entrata richieste. Puoi abilitare il servizio per un'app Python 2 includendo una sezione `inbound_services` nella `app.yaml` file. Sono disponibili i seguenti servizi in entrata: `mail` Consente all'applicazione di ricevere posta. `warmup` Abilita le richieste di warmup. Vedi Configurazione delle richieste di riscaldamento. . 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` Facoltativamente, utilizza la Elemento `automatic_scaling` per modificare il valore predefinito impostazioni per la scalabilità automatica, come il valore minimo e massimo numero di istanze, latenza e connessioni simultanee. Nota: se `instance_class` è impostato su `F2` o su un valore superiore, puoi ottimizzare le tue istanze impostando `max_concurrent_requests` a un valore superiore a il valore predefinito è 10. Per determinare il valore ottimale, aumentarlo gradualmente e monitorare il rendimento un'applicazione. Scalabilità di base e manuale `B1`, `B2`, `B4`, `B4_1G` e `B8` Predefinita: `B2` Le classi di istanza di base e manuali richiedono di specificare o `basic_scaling` o l'elemento `manual_scaling`.
`libraries`	Facoltativo. Il runtime Python 2.7 include alcuni librerie. Alcuni di questi sono disponibili per impostazione predefinita; gli altri sono solo disponibili se configurati. Puoi specificare la versione che vuoi utilizzare specificando i valori `name` e `version`. Questo campo è ritirato nel runtime di Python 3. libraries: - name: PIL version: "1.1.7" - name: webob version: "latest" Nota: rispetto a quando specifichi `latest`, l'SDK determina l'ultima versione della libreria al momento del deployment. Una volta di cui è stato eseguito il deployment, la versione della libreria non cambierà. L'unico modo per ottenere un'altra versione della libreria. Se stai sviluppando un'applicazione che non ha ancora utenti: non c'è bisogno di monitorare le nuove versioni. Ma se la tua applicazione viene utilizzata attivamente, fai attenzione: potrebbe sorprenderti il fatto che la tua applicazione inizia a utilizzare una nuova versione della libreria non compatibile con le versioni precedenti. Per un elenco delle librerie di terze parti incluse, consulta Terze parti Biblioteche. Puoi utilizzare applicazioni di terze parti librerie installandole in una directory locale. Se utilizzi l'ambiente flessibile, consulta Utilizzare librerie Python nell'ambiente flessibile.
`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 dal tuo dell'app. Ad esempio, per specificare Python 2.7, utilizza: runtime: python27
`service`	I Servizi in precedenza erano noti come Moduli. Supportate solo da gcloud CLI o basate su gcloud CLI plug-in, ad esempio: `gcloud app deploy` . Obbligatorio se crei un Google Cloud. Facoltativo per `default` completamente gestito di Google Cloud. 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` è indietro compatibile e supporta i file `app.yaml` esistenti che Includi servizi dichiarati come moduli, ad esempio: module: service-name
`service_account`	Facoltativo. L'elemento `service_account` ti consente di specificare account di servizio gestito dall'utente come identità per la versione. L'account di servizio specificato viene utilizzato per accedere ad altri servizi Google Cloud ed eseguire attività. Esempio: service_account: [SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com
`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 valori le 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 precedenti, copia e incolla quanto riportato sopra elenco nel tuo `app.yaml` e aggiungi il tuo le espressioni regolari. Ad esempio, per saltare i file i cui nomi terminano con `.bak` oltre ai pattern predefiniti, aggiungi una voce in questo modo per `skip_files`: skip_files: - ^(./)?#.#$ - ^(./)?.~$ - ^(./)?.\.py[co]$ - ^(./)?./RCS/.$ - ^(./)?\..$ - ^(./)?.\.bak$ Per saltare una directory completa, aggiungi il nome della directory a dall'elenco. Ad esempio, per saltare una directory denominata `logs`, aggiungi la seguente riga a quelle descritte in precedenza: skip_files: - logs/
`threadsafe`	Obbligatorio. Configura l'applicazione per l'uso di richieste in parallelo. Se utilizzi di Python libreria di thread, i dati locali di thread, come restituiti da `threading.local()`, sono vengono cancellati dopo ogni richiesta. Questo campo è ritirato nel runtime di Python 3. threadsafe: [true \| false] Nota: l'istruzione `threadsafe` è obbligatoria per: delle applicazioni Python 2.7. `threadsafe: true` richiede che tutti i gestori di script siano Quelli WSGI. Ciò significa che ogni script deve essere specificato in un `script:` utilizzando un modulo Python con i nomi dei pacchetti separati da punti. L'ultimo componente di un `script:` utilizzando un modulo Python path è il nome di una variabile globale in `service:` quella variabile deve essere un'app WSGI e di solito è chiamato `app` convenzione.
`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 da 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, la destinazione essere il numero di istanza 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.
`vpc_access_connector`	Facoltativo. Configura la tua applicazione per l'uso di un accesso VPC serverless il connettore dati, consentendo all'applicazione di inviare richieste delle tue risorse nella tua rete VPC. Per ulteriori informazioni, vedi Connessione a una rete VPC. `name` Valore letterale stringa. Specifica il nome completo del tuo Connettore di accesso VPC serverless tra virgolette: "projects/`PROJECT_ID`/locations/`REGION`/connectors/`CONNECTOR_NAME`" . `egress_setting` Facoltativo. Il valore predefinito è `private-ranges-only`. La `egress_setting` può essere uno dei seguenti: `private-ranges-only` Predefinita. Le richieste agli indirizzi IP interni vengono inviate tramite il connettore di accesso VPC serverless alla rete VPC connessa. Richieste a IP esterno indirizzi IP vengono inviati alla rete internet pubblica. `all-traffic` Tutte le richieste vengono inviate tramite Connettore di accesso VPC serverless alla rete VPC connessa. . . Esempio vpc_access_connector: name: "projects/`PROJECT_ID`/locations/`REGION`/connectors/`CONNECTOR_NAME`" egress_setting: all-traffic

Elemento gestori

L'elemento handlers è obbligatorio in di configurazione di 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.

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 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, 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 App Engine più recenti.
`expiration`	Facoltativo. Il periodo di tempo in cui un file statico pubblicato da questo gestore dovrebbe essere memorizzati nella cache da proxy web e browser. Il valore è una stringa di numeri e unità, separati da spazi, in cui le unità possono essere `d` per i giorni, `h` per le ore, `m` per minuti e `s` per i secondi. Ad esempio: `"4d 5h"` imposta la scadenza della cache su 4 giorni e 5 ore dopo se viene richiesto per la prima volta. Se omesso, il valore È in uso `default_expiration`. Vedi Cache data di scadenza per ulteriori dettagli.
`http_headers`	Facoltativo. Puoi impostare HTTP intestazioni per le risposte del file statico o della directory e i gestori di rete. Se devi impostare intestazioni HTTP nei tuoi gestori `script`, devi invece farlo nelle le API nel tuo codice. 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 # ... Assistenza CORS Un uso importante di questa funzionalità è supportare le risorse multiorigine condivisione (CORS), ad esempio l'accesso a file ospitati da un altro dell'app App Engine. Ad esempio, potresti avere 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 restituire il gestore di file statico valore di intestazione 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 ai tuoi asset, puoi utilizza 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 per un file, verrà ricavata dall'estensione del nome file del file. Se lo stesso file viene caricato con più estensioni, può dipendere dall'ordine in cui sono stati eseguiti i caricamenti. Per ulteriori informazioni sui possibili tipi multimediali MIME, visita il sito web sui tipi di media MIME di 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 permanente spostato. `302` Codice di risposta trovato. `303` Vedi Altro codice di risposta. `307` Codice di risposta di reindirizzamento temporaneo. . Esempio handlers: - url: /youraccount/.* script: accounts.app login: required secure: always redirect_http_response_code: 301 Quando la richiesta di un utente viene reindirizzata, viene impostato il codice di stato HTTP al valore dell'attributo `redirect_http_response_code` . Se il parametro non è presente, verrà restituito 302.
`script`	Facoltativo. Specifica il percorso dello script dalla directory radice dell'applicazione directory: handlers: # The root URL (/) is handled by the WSGI application named # "app" in home.py. No other URLs match this pattern. - url: / script: home.app # The URL /index.html is also handled by the home.py script. - url: /index\.html script: home.app # A regular expression can map parts of the URL to the # path of the script. - url: /browse/(books\|videos\|tools) script: \1.catalog.app # All other URLs use the WSGI application named in "app" # in not_found.py. - url: /.* script: not_found.app Un'istruzione `script:` deve essere un percorso di importazione di Python, per esempio, `package.module.app` che rimanda a un WSGI un'applicazione. L'ultimo componente di un'istruzione `script:` utilizzando un percorso di modulo Python è il nome di un nel modulo: la variabile deve essere un'app WSGI ed è di solito viene chiamato `app` per convenzione. Nota: proprio come per un'istruzione `import` di Python, ogni la sottodirectory di un pacchetto deve contenere un file denominato `__init__.py`. Nei runtime di App Engine più recenti, il il comportamento di questo campo è cambiato.
`secure`	Facoltativo. Qualsiasi gestore di URL può usare l'impostazione `secure`, inclusi i gestori di script gestori di file statici. L'elemento `secure` ha quanto segue valori possibili: `optional` Richieste sia HTTP che HTTPS con URL che corrispondono al gestore hanno esito positivo senza reindirizzamenti. L'applicazione può esaminare la richiesta per determinare quale protocollo è stato utilizzato e rispondere di conseguenza. Questo è l'impostazione predefinita quando `secure` non viene fornito per un . `never` Le richieste per un URL corrispondente a questo gestore che utilizzano HTTPS vengono vengono reindirizzati automaticamente all'URL equivalente HTTP. Quando un utente La richiesta HTTPS viene reindirizzata a una richiesta HTTP vengono rimossi dalla richiesta. In questo modo all'utente di inviare accidentalmente dati di query su una piattaforma per una connessione sicura. `always` Le richieste per un URL corrispondente a questo gestore che non utilizzano HTTPS vengono vengono reindirizzati automaticamente all'URL HTTPS con lo stesso percorso. Termine di ricerca vengono conservati per il reindirizzamento. . Esempio handlers: - url: /youraccount/.* script: accounts.app login: required secure: always Il server web di sviluppo non supporta le connessioni HTTPS. it ignora il parametro `secure`, quindi i percorsi destinati all'uso con HTTPS può essere testato utilizzando normali connessioni HTTP di sviluppo software. A scegliere come target una specifica versione dell'app utilizzando `REGION_ID.r.appspot.com` dominio, sostituisci i punti che generalmente separano i componenti di sottodominio dell'URL con la stringa "`-dot-`", ad esempio: `https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com` Per utilizzare domini personalizzati con HTTPS, devi prima attivare e configurare i certificati SSL per quel dominio. L'accesso e la disconnessione dall'Account Google vengono sempre eseguiti utilizzando un connessione sicura, non correlata al modo in cui gli URL dell'applicazione configurato.
`static_dir`	Facoltativo. Il percorso della directory contenente i file statici, da nella directory radice dell'applicazione. Tutto ciò che dopo la fine il pattern `url` corrispondente viene aggiunto a `static_dir` per formare il percorso completo del file richiesto. Ogni file nella directory statica viene pubblicato utilizzando il tipo MIME che corrisponde alla relativa estensione del nome file a meno che non venga sostituito dal dell'impostazione `mime_type` della directory. Tutti i file nel una determinata directory vengono caricati come file statici nessuno di questi può essere eseguito come script. 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 directory senza dover mappare l'intera directory. Esempio: handlers: # All URLs ending in .gif .png or .jpg are treated as paths to # static files in the static/ directory. The URL pattern is a # regular expression, with a grouping that is inserted into the # path to the file. - url: /(.\.(gif\|png\|jpg))$ static_files: static/\1 upload: static/.\.(gif\|png\|jpg)$ # ... 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 una , 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. Questa operazione è necessaria perché il gestore non è in grado di determinare quali file nella tua applicazione della directory corrispondano agli attributi `url` `static_files` pattern. I file statici vengono caricati e vengono gestiti separatamente dai file dell'applicazione. L'esempio in alto potrebbe utilizzare il seguente pattern `upload`: `archives/(.)/items/(.)`
`url`	Elemento obbligatorio in `handlers`. Il pattern URL, come un'espressione regolare. L'espressione può contenere raggruppamenti che possono essere a cui viene fatto riferimento nel percorso file dello script con espressione regolare i backreference. Ad esempio: `/profile/(.)/(.)` corrisponde all'URL `/profile/edit/manager` e utilizza `edit` e `manager` come primo e secondo e i raggruppamenti. Il pattern URL presenta alcune differenze di comportamento se utilizzato con i seguenti elementi: `static_dir` Utilizza un prefisso URL. Il pattern espresso normale non deve contenere raggruppamenti quando utilizzato con l'elemento `static_dir`. Tutti Gli URL che iniziano con questo prefisso vengono gestiti da questo gestore, utilizzando la porzione dell'URL che segue il prefisso come parte del percorso del file. `static_files` Un gestore di pattern di file statici associa un pattern URL ai percorsi da i file statici caricati con l'applicazione. Il pattern URL è regolare può definire raggruppamenti di espressioni regolari da utilizzare nel del percorso del file. Puoi utilizzarlo al posto di `static_dir` per mappare file specifici in una directory senza dover mappare l'intera directory.

Elementi di scalabilità

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

Elemento Descrizione

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 della scalabilità automatica. come l'impostazione dei livelli minimo e massimo per il numero di istanze, latenza e connessioni simultanee per un servizio. Questo elemento può contenere i seguenti elementi: `max_instances` Facoltativa. Specifica un valore compreso tra 0 e 2147483647, dove zero disattiva l'impostazione. Questo parametro specifica il numero massimo di istanze 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 riscaldamento richieste siano abilitate e che la tua applicazione gestisca richieste di riscaldamento. Nota: questa impostazione si applica solo se la versione dell'app definita da questo file `app.yaml` è configurate per ricevere traffico. Per scoprire di più sui percorsi, il traffico verso versioni diverse di un'app, consulta Suddivisione del traffico. Facoltativa. 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 vengono avviate altre istanze 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 stai addebitato per il numero di istanze specificato che ricevono traffico o meno. `max_idle_instances` Facoltativo. Il numero massimo di istanze inattive che App Engine deve mantenere per questa versione. Specifica un valore compreso tra 1 e 1000. Se non specificato, il valore predefinito è `automatic`, il che significa che App Engine gestirà il numero di istanze inattive. Tieni presente che: Un valore massimo elevato riduce ulteriormente il numero di istanze inattive gradualmente quando i livelli di carico tornano alla normalità dopo un picco. Questo consente alla tua applicazione di mantenere un rendimento costante delle fluttuazioni nel carico delle richieste, ma aumenta anche il numero di di Compute Engine (e conseguenti costi di esecuzione) durante questi periodi carico di lavoro. 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 verrà addebitato alcun costo più istanze rispetto al numero massimo specificato. `min_idle_instances` Avviso: per il corretto funzionamento di questa funzionalità, devi assicurarti che riscaldamento richieste siano abilitate e che la tua applicazione gestisca richieste di riscaldamento. Nota: questa impostazione si applica solo se la versione dell'app definita da questo file `app.yaml` è configurate per ricevere traffico. Per scoprire di più sui percorsi, il traffico verso versioni diverse di un'app, consulta Suddivisione del traffico. (Facoltativo) Il numero di istanze aggiuntive da mantenere in esecuzione e pronto a gestire il traffico per questa versione. App Engine calcola il numero di istanze necessarie gestire il traffico attuale delle applicazioni in base alla scalabilità impostazioni come `target_cpu_utilization` e `target_throughput_utilization`. Impostazione di `min_idle_instances` specifica il numero di istanze a cui eseguire in aggiunta a questo numero calcolato. Ad esempio: se App Engine calcola 5 istanze sono necessarie per gestire il traffico e `min_idle_instances` è impostato su 2, App Engine eseguirà 7 istanze (5, calcolate in base al traffico, più altri 2 per `min_idle_instances`). Tieni presente che stai addebitato per il numero di istanze specificato che ricevono traffico o meno. Tieni presente che: Un 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. Tu il costo viene addebitato per il numero di istanze specificato, non stanno gestendo le richieste. Se imposti un numero minimo di istanze inattive, latenza in sospeso avrà meno impatto sulle prestazioni della tua applicazione. `target_cpu_utilization` 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` Facoltativa. Specifica un valore compreso tra 0,5 e 0,95. L'impostazione predefinita è `0.6`. Utilizzato con `max_concurrent_requests` per specificare quando viene avviata una nuova istanza a causa di richieste in parallelo. 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 e una scalabilità automatica l'istanza può accettare prima che lo scheduler crei una nuova istanza (valore predefinito: 10, 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 in parallelo raggiunge un valore uguale a `max_concurrent_requests` volte `target_throughput_utilization`, lo scheduler prova a avviare una nuova istanza. Ti consigliamo di non impostare `max_concurrent_requests` a meno di 10, a meno che tu non abbia bisogno di un singolo thread. Un valore meno di 10, è probabile che un numero maggiore di istanze del necessario per un'app threadsafe, con possibili conseguenze costi inutili. Se questa impostazione è troppo alta, l'API potrebbe essere aumentata una latenza di pochi millisecondi. Tieni presente che lo scheduler potrebbe generare una nuova istanza prima viene raggiunto il numero massimo effettivo di richieste. `max_pending_latency` Il 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 questo soglia è stata raggiunta, è un segnale di fare lo scale up e un aumento del numero di istanze. Se non specificato, il valore predefinito è `automatic`. Ciò significa possono rimanere nella coda di attesa per un massimo di 10 secondi, il limite massimo in attesa del limite di tempo per le richieste in attesa, prima dell'attivazione della nuova istanza. Un valore massimo basso significa che App Engine avvierà nuove istanze per le richieste in attesa, migliorando il rendimento e aumentando i costi di gestione. Un valore massimo elevato significa che gli utenti potrebbero attendere più a lungo per le loro richieste la pubblicazione (se ci sono richieste in attesa e non di Compute Engine, ma la tua applicazione costerà meno vengono eseguiti tutti i test delle unità. `min_pending_latency` Un elemento facoltativo che puoi impostare per specificare 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. Specificare un valore può ridurre i costi di gestione, ma aumentare il tempo Gli utenti devono attendere la risposta alle loro richieste. Per le app gratuite, il valore predefinito è `500ms`. A pagamento app, il valore predefinito è `0`. Questo elemento funziona insieme a `max_pending_latency` per determinare quando App Engine crea nuove istanze. Se sono presenti richieste in attesa in coda: Meno del valore di `min_pending_latency` specificato, App Engine non creerà nuove istanze. Più di `max_pending_latency`, App Engine proverà a 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 istanza di B1 o superiore, deve specificare questo elemento oppure `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. Ciò è utile per limitare i costi di un servizio. `idle_timeout` Facoltativa. L'istanza verrà arrestata per questo periodo di tempo dopo che riceve l'ultima richiesta. Il valore predefinito è 5 minuti (`5m`). . Esempio basic_scaling: max_instances: 11 idle_timeout: 10m
`manual_scaling`	Le applicazioni che utilizzano istanza di B1 o superiore, deve specificare questo elemento oppure `basic_scaling`. Questo elemento consente la scalabilità manuale delle classi di 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

automatic_scaling

Facoltativo. Applicabile solo per le applicazioni che utilizzano un'etichetta istanza F1 o superiore.

Specifica questo elemento per modificare le impostazioni predefinite della scalabilità automatica. come l'impostazione dei livelli minimo e massimo per il numero di istanze, latenza e connessioni simultanee per un servizio.

Questo elemento può contenere i seguenti elementi:

max_instances

Facoltativa. Specifica un valore compreso tra 0 e 2147483647, dove zero disattiva l'impostazione.

Questo parametro specifica il numero massimo di istanze per l'applicazione Motore da creare per questa versione del modulo. È utile per limitare solo i costi di un modulo.

min_instances

Nota: questa impostazione si applica solo se la versione dell'app definita da questo file app.yaml è configurate per ricevere traffico. Per scoprire di più sui percorsi, il traffico verso versioni diverse di un'app, consulta Suddivisione del traffico.

Facoltativa. 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 vengono avviate altre istanze 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 stai addebitato per il numero di istanze specificato che ricevono traffico o meno.

max_idle_instances

Facoltativo. Il numero massimo di istanze inattive che App Engine deve mantenere per questa versione. Specifica un valore compreso tra 1 e 1000. Se non specificato, il valore predefinito è automatic, il che significa che App Engine gestirà il numero di istanze inattive. Tieni presente che:

Un valore massimo elevato riduce ulteriormente il numero di istanze inattive gradualmente quando i livelli di carico tornano alla normalità dopo un picco. Questo consente alla tua applicazione di mantenere un rendimento costante delle fluttuazioni nel carico delle richieste, ma aumenta anche il numero di di Compute Engine (e conseguenti costi di esecuzione) durante questi periodi carico di lavoro.
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 verrà addebitato alcun costo più istanze rispetto al numero massimo specificato.

min_idle_instances

(Facoltativo) Il numero di istanze aggiuntive da mantenere in esecuzione e pronto a gestire il traffico per questa versione.

App Engine calcola il numero di istanze necessarie gestire il traffico attuale delle applicazioni in base alla scalabilità impostazioni come target_cpu_utilization e target_throughput_utilization. Impostazione di min_idle_instances specifica il numero di istanze a cui eseguire in aggiunta a questo numero calcolato. Ad esempio: se App Engine calcola 5 istanze sono necessarie per gestire il traffico e min_idle_instances è impostato su 2, App Engine eseguirà 7 istanze (5, calcolate in base al traffico, più altri 2 per min_idle_instances).

Tieni presente che stai addebitato per il numero di istanze specificato che ricevono traffico o meno. Tieni presente che:

Un 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. Tu il costo viene addebitato per il numero di istanze specificato, non stanno gestendo le richieste.

Se imposti un numero minimo di istanze inattive, latenza in sospeso avrà meno impatto sulle prestazioni della tua applicazione.

target_cpu_utilization

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

Facoltativa. Specifica un valore compreso tra 0,5 e 0,95. L'impostazione predefinita è 0.6.

Utilizzato con max_concurrent_requests per specificare quando viene avviata una nuova istanza a causa di richieste in parallelo. 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 e una scalabilità automatica l'istanza può accettare prima che lo scheduler crei una nuova istanza (valore predefinito: 10, 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 in parallelo raggiunge un valore uguale a max_concurrent_requests volte target_throughput_utilization, lo scheduler prova a avviare una nuova istanza.

Ti consigliamo di non impostare max_concurrent_requests a meno di 10, a meno che tu non abbia bisogno di un singolo thread. Un valore meno di 10, è probabile che un numero maggiore di istanze del necessario per un'app threadsafe, con possibili conseguenze costi inutili.

Se questa impostazione è troppo alta, l'API potrebbe essere aumentata una latenza di pochi millisecondi. Tieni presente che lo scheduler potrebbe generare una nuova istanza prima viene raggiunto il numero massimo effettivo di richieste.

max_pending_latency

Il 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 questo soglia è stata raggiunta, è un segnale di fare lo scale up e un aumento del numero di istanze. Se non specificato, il valore predefinito è automatic. Ciò significa possono rimanere nella coda di attesa per un massimo di 10 secondi, il limite massimo in attesa del limite di tempo per le richieste in attesa, prima dell'attivazione della nuova istanza.

Un valore massimo basso significa che App Engine avvierà nuove istanze per le richieste in attesa, migliorando il rendimento e aumentando i costi di gestione.

Un valore massimo elevato significa che gli utenti potrebbero attendere più a lungo per le loro richieste la pubblicazione (se ci sono richieste in attesa e non di Compute Engine, ma la tua applicazione costerà meno vengono eseguiti tutti i test delle unità.

min_pending_latency

Un elemento facoltativo che puoi impostare per specificare 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. Specificare un valore può ridurre i costi di gestione, ma aumentare il tempo Gli utenti devono attendere la risposta alle loro richieste.

Per le app gratuite, il valore predefinito è 500ms. A pagamento app, il valore predefinito è 0.

Questo elemento funziona insieme a max_pending_latency per determinare quando App Engine crea nuove istanze. Se sono presenti richieste in attesa in coda:

Meno del valore di min_pending_latency specificato, App Engine non creerà nuove istanze.
Più di max_pending_latency, App Engine proverà a 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 istanza di B1 o superiore, deve specificare questo elemento oppure 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. Ciò è utile per limitare i costi di un servizio.
idle_timeout: Facoltativa. L'istanza verrà arrestata per questo periodo di tempo dopo che riceve l'ultima richiesta. Il valore predefinito è 5 minuti (5m).

Esempio

basic_scaling:
  max_instances: 11
  idle_timeout: 10m

manual_scaling

Le applicazioni che utilizzano istanza di B1 o superiore, deve specificare questo elemento oppure basic_scaling.

Questo elemento consente la scalabilità manuale delle classi di 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