Riferimento app.yaml per App Engine

L'approccio consigliato è rimuovere l'elemento application dal file app.yaml e utilizzare 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, consulta la pagina relativa al deployment dell'app.

L'ID applicazione è l'ID progetto della console Google Cloud che hai specificato al momento della creazione dell'applicazione nella console Google Cloud.

Obbligatorio. La versione dell'API nell'ambiente di runtime specificato e utilizzata dalla tua app.

Questo campo è deprecato nei runtime App Engine più recenti.

Quando Google annuncia il supporto di una nuova versione dell'API di un ambiente di runtime, l'app di cui è stato eseguito il deployment continuerà a utilizzare quella per cui è stata scritta. Per eseguire l'upgrade dell'app a una nuova versione dell'API, modifica questo valore ed esegui nuovamente il deployment dell'app in App Engine. Se specifichi il valore 1, viene utilizzato l'ambiente di runtime più recente supportato ogni volta che esegui il deployment dell'app (attualmente ).

Al momento, App Engine ha una versione dell'ambiente di runtime python27: 1

default

Predefinita. Utilizza ID automatici sparsi che sono grandi numeri interi ben distribuiti e sufficientemente piccoli da essere rappresentati da numeri in virgola mobile a 64 bit.

legacy

L'opzione precedente verrà deprecata in una versione futura e alla fine verrà rimossa. Per ulteriori informazioni, consulta il post del blog che annuncia questa modifica.

Facoltativo. L'SDK Python 2 include una serie di gestori integrati per le funzioni dell'applicazione comuni. L'istruzione builtins consente di includere gestori specifici in app.yaml.

Questo campo è deprecato nel runtime di Python 3.

Puoi utilizzare i seguenti gestori integrati:

appstats

Attiva Appstat in /_ah/stats/, che puoi utilizzare per misurare le prestazioni della tua applicazione. Per utilizzare Appstat, devi anche installare il registratore di eventi.

deferred

Abilita il gestore differito in /_ah/queue/deferred. Questa funzionalità integrata consente agli sviluppatori di utilizzare deferred.defer() per semplificare la creazione delle attività delle code di attività.

remote_api

Attiva l'elemento integrato remote_api alle /_ah/remote_api/. Questa tecnologia integrata consente alle applicazioni remote con le credenziali corrette di accedere al datastore da remoto.

builtins:
- deferred: on
- appstats: on

L'istruzione builtins è un'istanza speciale dell'istruzione 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, tutti i gestori definiti nel file include.yaml integrato prevarranno su tutti i gestori definiti nel file app.yaml. Tuttavia, se includi un file che utilizza builtins o includes, i gestori vengono aggiunti in base alla gerarchia di inclusione. In altre parole, i gestori dell'elemento "padre" vengono aggiunti prima dell'inclusione del componente "figlio" incluso e così via.

Ad esempio, considera quanto segue app.yaml, che utilizza i gestori appstats integrati:

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 un file .yaml non modifica il comportamento.

Facoltativo. Imposta un periodo di cache predefinito globale per tutti i gestori di file statici di 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 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 a 10 minuti.

runtime: python27
api_version: 1
threadsafe: true

default_expiration: "4d 5h"

handlers:
# ...

Per maggiori informazioni, consulta Scadenza della cache.

Facoltativo. Puoi definire variabili di ambiente nel file 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 caratteri alfanumerici o "_").

Le variabili di ambiente con prefisso GAE sono riservate per l'uso da parte del sistema e non sono consentite nel file app.yaml.

env_variables:
  DJANGO_SETTINGS_MODULE: "myapp.settings"

Facoltativo. Utilizzato per configurare le pagine di errore personalizzate che vengono restituite per tipi di errori diversi.

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

timeout

Pubblicato se viene raggiunta una scadenza prima di ricevere una risposta dalla tua app.

error_code è facoltativo; se non è specificato, il file fornito è la risposta di errore predefinita per la tua app.

file

Ogni voce di file indica un file statico che deve essere pubblicato 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 per la tua app. I dati di errore personalizzati devono essere inferiori a 10 kilobyte.

error_handlers:
  - file: default_error.html

  - error_code: over_quota
    file: over_quota.html

Obbligatorio. Un elenco di pattern 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.

Vedi la sintassi dei gestori e degli elementi secondari

Facoltativo. L'istruzione includes consente di includere il file di configurazione per qualsiasi libreria o servizio nell'applicazione. Ad esempio, potresti includere una libreria di amministrazione utenti come segue:

includes:
- lib/user_admin.yaml

App Engine risolve il percorso incluso nel seguente ordine:

• Percorso assoluto o relativo della directory di lavoro. Il percorso 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 del file di riferimento e il percorso di inclusione vengono risolti nel file incluso.

Se l'istruzione include specifica una directory, App Engine cerca in quella directory un file denominato include.yaml. Se l'istruzione di inclusione è un file, viene incluso quel file specifico. L'utilizzo di includes recupera solo i seguenti tipi di istruzioni dal file di destinazione (se presente):

• builtins
• includes
• handlers
• skip_files

I pattern skip_files inclusi vengono aggiunti a quelli in app.yaml incluso oppure all'elenco predefinito se non è presente un elenco esplicito in app.yaml. Tieni presente che skip_files confronta i percorsi assoluti.

Facoltativo. Le applicazioni devono abilitare questi servizi prima di poter ricevere richieste in entrata. Puoi abilitare il servizio per un'app Python 2 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 warmup. Consulta la sezione Configurazione delle richieste di riscaldamento.

inbound_services:
  - mail
  - warmup

Facoltativo. La classe istanza per questo servizio.

I seguenti valori sono disponibili a seconda della scalabilità del tuo 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 numero minimo e massimo di istanze, latenza e connessioni simultanee.

Nota: se il criterio instance_class è impostato su F2 o su un valore 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 dell'applicazione.

Scalabilità di base e manuale

B1, B2, B4, B4_1G, B8

Predefinito: B2

Le classi di istanza di base e manuali richiedono di specificare l'elemento basic_scaling o l'elemento manual_scaling.

Facoltativo. Il runtime Python 2.7 include alcune librerie di terze parti. Alcune di queste sono disponibili per impostazione predefinita, mentre altre sono disponibili solo se configurate. Puoi specificare la versione da utilizzare specificando i valori name e version.

Questo campo è deprecato nel runtime di Python 3.

libraries:
- name: PIL
  version: "1.1.7"
- name: webob
  version: "latest"
        

Per un elenco delle librerie di terze parti incluse, consulta Librerie di terze parti. Puoi utilizzare librerie di terze parti pure-python aggiuntive installandole in una directory locale.

Se utilizzi l'ambiente flessibile, consulta Utilizzo delle librerie Python nell'ambiente flessibile.

Nota: i moduli ora si chiamano Servizi.

Per gestire la tua app con gcloud CLI, utilizza invece l'elemento service.

Obbligatorio. Il nome dell'ambiente di runtime utilizzato dalla tua app. Ad esempio, per specificare Python 2.7, usa:

runtime: python27

I Servizi in precedenza erano noti come Moduli.

Supportati solo dai plug-in basati su gcloud CLI o gcloud CLI, ad esempio: gcloud app deploy .

Obbligatorio se si crea un servizio. Facoltativo per il servizio default. Ogni servizio e ogni versione deve 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 tua versione, SERVICE è il nome del servizio e PROJECT_ID è l'ID progetto, non può superare i 63 caratteri e non può iniziare o terminare con un trattino. Scegli un nome univoco per ogni servizio e ogni versione. Non riutilizzare i nomi tra servizi e versioni.

service: service-name

module: service-name

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

service_account: [SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com

Facoltativo. L'elemento skip_files specifica quali file nella directory dell'applicazione non devono essere caricati in App Engine. Il valore è un'espressione regolare o un elenco di espressioni regolari. I nomi file che corrispondono a una qualsiasi delle espressioni regolari vengono omessi dall'elenco dei file da caricare quando viene caricata l'applicazione. 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 formato #...# e ...~, .pyc e .pyo, i file in una directory di controllo delle revisioni 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 riportato sopra 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 riga seguente a quelle descritte in precedenza:

skip_files:
- logs/

Obbligatorio. Configura l'applicazione per l'uso di richieste in parallelo. Se utilizzi la libreria di thread di Python, i dati locali del thread, come restituiti da threading.local(), vengono cancellati dopo ogni richiesta.

Questo campo è deprecato nel runtime di Python 3.

threadsafe: [true | false]

Nota: l'istruzione threadsafe è obbligatoria per le applicazioni Python 2.7. threadsafe: true richiede che tutti i gestori di script siano WSGI. In altre parole, ogni script deve essere specificato in un'istruzione script: utilizzando un percorso del modulo Python, con i nomi dei pacchetti separati da punti. L'ultimo componente di un'istruzione script: che utilizza un percorso di modulo Python è il nome di una variabile globale in service: che la variabile deve essere un'app WSGI e di solito viene chiamata app per convenzione.

L'approccio consigliato consiste nel rimuovere l'elemento version dal file app.yaml e utilizzare invece un flag della riga di comando per specificare il tuo ID versione:

• Per utilizzare il comando gcloud app deploy, specifica il flag -v:

  gcloud app deploy -v [YOUR_VERSION_ID]

Per ulteriori informazioni sull'utilizzo di questo comando, consulta 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. Ciò evita l'ambiguità con URL come 123-dot-my-service.uc.r.appspot.com, che possono essere interpretati in due modi: se esiste la versione "123", il target sarà la versione "123" del servizio specificato. Se questa versione non esiste, il target sarà il numero di istanza 123 della versione predefinita del servizio.

Ogni versione di un'applicazione conserva la propria copia di app.yaml. Quando un'applicazione viene caricata, la versione menzionata nel file app.yaml che viene caricato è quella che viene creata o sostituita dal caricamento. Un amministratore può modificare la versione dell'applicazione che gestisce il traffico utilizzando la console Google Cloud e può anche testare altre versioni prima di configurarle per la ricezione del traffico.

Facoltativo. Configura l'applicazione per l'utilizzo di un connettore di accesso VPC serverless, che consente all'applicazione di inviare richieste alle risorse interne nella tua rete VPC. Per maggiori informazioni, consulta la pagina relativa alla connessione a una rete VPC.

name

Valore letterale stringa. Specifica il nome completo del connettore di accesso VPC serverless tra virgolette:

"projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME"

egress_setting

Facoltativo. Il valore predefinito è private-ranges-only. 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. Le richieste agli indirizzi IP esterni vengono inviate alla rete internet pubblica.

all-traffic

Tutte le richieste vengono inviate tramite il connettore di accesso VPC serverless alla rete VPC connessa.

vpc_access_connector:
  name: "projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME"
  egress_setting: all-traffic

Questo campo è deprecato nei runtime App Engine più recenti.

Facoltativo. Puoi impostare intestazioni HTTP per le risposte dei gestori di file o directory statici. Se devi impostare le 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 sezione Memorizzazione nella cache dei contenuti statici.

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à è il supporto della condivisione delle risorse tra origini (CORS), ad esempio l'accesso a file ospitati da un'altra app di 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 tenta di rendere XMLHttpRequest JavaScript in myassets, l'operazione non riuscirà a meno che il gestore di myassets non restituisca un'intestazione di risposta Access-Control-Allow-Origin: contenente il valore http://mygame.uc.r.appspot.com.

Ecco come dovresti fare in modo che il tuo gestore di file statico restituisca il 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 ai tuoi asset, puoi utilizzare il carattere jolly '*' anziché https://mygame.uc.r.appspot.com.

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à derivato 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 ulteriori informazioni sui possibili tipi multimediali MIME, visita il sito web sui tipi di media MIME di IANA.

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 di reindirizzamento temporaneo.

handlers:
- url: /youraccount/.*
  script: accounts.app
  login: required
  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 302.

Facoltativo. Specifica il percorso dello script dalla directory principale dell'applicazione:

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, ad esempio package.module.app che rimanda a un'applicazione WSGI. L'ultimo componente di un'istruzione script: che utilizza un percorso di modulo Python è il nome di una variabile globale nel modulo: tale variabile deve essere un'app WSGI ed è solitamente chiamata app per convenzione.

Nota: proprio come per un'istruzione import in Python, ogni sottodirectory di un pacchetto deve contenere un file denominato __init__.py.

Nei runtime più recenti di App Engine, il comportamento di questo campo è cambiato.

optional

Le richieste HTTP e 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 non viene fornito secure per un gestore.

never

Le richieste di un URL corrispondente a questo gestore che utilizzano HTTPS vengono reindirizzate automaticamente all'URL HTTP equivalente. Quando la richiesta HTTPS di un utente viene reindirizzata come una richiesta HTTP, i parametri di ricerca vengono rimossi dalla richiesta. In questo modo, un utente non può inviare accidentalmente dati delle query tramite una connessione non sicura destinata a una connessione sicura.

always

Le richieste di un URL corrispondente 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.

handlers:
- url: /youraccount/.*
  script: accounts.app
  login: required
  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 normali connessioni HTTP con il 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 in genere 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 dagli Account Google vengono sempre eseguiti utilizzando una connessione sicura, non correlata alla configurazione degli URL dell'applicazione.

Facoltativo. Il percorso della directory contenente i file statici, dalla directory radice dell'applicazione. Tutto ciò che compare 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 che corrisponde all'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 i file statici separatamente dai file dell'app. I file statici non sono disponibili nel file system dell'app per impostazione predefinita. Questo può essere modificato impostando l'opzione application_readable su true.

handlers:
# All URLs beginning with /stylesheets are treated as paths to
# static files in the stylesheets/ directory.
- url: /stylesheets
  static_dir: stylesheets
  # ...

Facoltativo. 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 i raggruppamenti di espressioni regolari da utilizzare per la creazione del percorso del file. Puoi utilizzare questo metodo anziché static_dir per mappare file specifici in una struttura di directory senza mappare l'intera directory.

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 nel file system dell'applicazione per impostazione predefinita. Questo può essere modificato impostando l'opzione 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 è disponibile per il gestore dinamico.

Facoltativo. Un'espressione regolare che corrisponde ai percorsi di tutti i file a cui questo gestore fa riferimento. Questa operazione è necessaria 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 riportato sopra potrebbe utilizzare il seguente pattern upload: archives/(.*)/items/(.*)

Elemento obbligatorio in handlers. Il pattern URL, come espressione regolare. L'espressione può contenere raggruppamenti a cui è possibile fare riferimento nel percorso del file dello script con back-reference delle espressioni regolari. Ad esempio, /profile/(.*)/(.*) corrisponderà all'URL /profile/edit/manager e userebbe edit e manager come primo e secondo raggruppamento.

Il pattern URL presenta alcune differenze di comportamento se 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 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 i raggruppamenti di espressioni regolari da utilizzare per la creazione del percorso del file. Puoi utilizzare questo metodo anziché static_dir per mappare file specifici in una struttura di directory senza mappare l'intera directory.

Facoltativo. Applicabile solo per le applicazioni che utilizzano una classe istanza di F1 o superiore.

Specifica questo elemento per modificare le impostazioni predefinite per la scalabilità automatica, ad esempio impostando i 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 disabilita l'impostazione.

Questo parametro specifica il numero massimo di istanze che App Engine dovrà creare per questa versione del modulo. Questo è utile per limitare i costi di un modulo.

min_instances

Facoltativo. Il numero minimo di istanze che App Engine deve creare per questa versione del modulo. Queste istanze gestiscono il traffico all'arrivo delle richieste e continuano a gestire il traffico anche quando le istanze aggiuntive vengono avviate 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 delle istanze e ridurre i costi quando non vengono gestite richieste. Tieni presente che ti viene addebitato 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 il numero di istanze inattive in modo più graduale quando i livelli di carico tornano alla normalità dopo un picco. Ciò consente all'applicazione di mantenere prestazioni costanti attraverso le fluttuazioni del carico delle richieste, ma aumenta anche il numero di istanze inattive (e i conseguenti costi di esecuzione) durante questi periodi di carico elevato.
• Un massimo basso riduce i costi di esecuzione, ma può peggiorare le prestazioni a causa di livelli di carico volatili.

Nota:quando si torna ai livelli normali dopo un picco di carico, il numero di istanze inattive può superare temporaneamente il valore massimo specificato. Tuttavia, non ti verrà addebitato un numero di istanze maggiore rispetto al numero massimo specificato.

min_idle_instances

(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 attuale dell'applicazione in base a impostazioni di scalabilità come target_cpu_utilization e target_throughput_utilization. L'impostazione di min_idle_instances consente di specificare il numero di istanze da eseguire oltre al numero calcolato. Ad esempio, se App Engine calcola che sono necessarie cinque istanze per gestire il traffico e min_idle_instances è impostato su 2, App Engine eseguirà 7 istanze (5 calcolate in base al traffico e 2 aggiuntive per min_idle_instances).

Tieni presente che ti viene addebitato il numero di istanze specificate indipendentemente dal fatto che ricevano o meno traffico. Tieni presente che:

• Un minimo basso aiuta a mantenere bassi i costi di esecuzione durante i periodi di inattività, ma significa che meno istanze potrebbero essere immediatamente disponibili per rispondere a un picco di carico improvviso.

• Un minimo elevato ti consente di preparare l'applicazione a picchi rapidi nel 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 specificato, indipendentemente dal fatto che gestiscano o meno le richieste.

  Se imposti un numero minimo di istanze inattive, latenza in sospeso avrà meno effetto sulle prestazioni dell'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 corrispondenza della quale verranno avviate le nuove istanze a gestire il traffico, in modo da bilanciare prestazioni e costo, con valori più bassi che aumentano le prestazioni e i costi e valori più alti riducono le prestazioni, ma anche i costi. Ad esempio, un valore pari a 0,7 significa che le nuove istanze verranno avviate dopo che 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 in parallelo. Quando il numero di richieste in parallelo raggiunge un valore uguale a max_concurrent_requests volte target_throughput_utilization, lo scheduler tenta di 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: 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 ad 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 un numero di istanze maggiore del necessario per un'app threadsafe, il che potrebbe comportare costi inutili.

Se questa impostazione è troppo elevata, potresti riscontrare un aumento della latenza dell'API. Tieni presente che lo scheduler potrebbe generare una nuova istanza prima che venga raggiunto il numero massimo effettivo di richieste.

max_pending_latency

Il tempo massimo che App Engine deve consentire a una richiesta di attendere nella coda in attesa prima di avviare istanze aggiuntive per gestire le richieste in modo da ridurre latenza in sospeso. Quando viene raggiunta questa soglia, è un segnale di fare lo scale up e di aumentare il 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 attivate le nuove istanze.

Un valore massimo basso indica che App Engine avvierà le nuove istanze prima per le richieste in attesa, migliorando le prestazioni ma aumentando i costi di esecuzione.

Un valore massimo elevato significa che gli utenti potrebbero attendere più a lungo per la gestione delle loro richieste (se ci sono richieste in attesa e non ci sono istanze inattive per gestirle), ma l'esecuzione della tua applicazione avrà un costo inferiore.

min_pending_latency

Elemento facoltativo che puoi impostare per specificare la quantità minima di tempo che App Engine deve consentire a una richiesta di attendere nella coda in attesa prima di avviare una nuova istanza per gestirla. Specificare un valore può ridurre i costi di esecuzione, ma aumentare il tempo di attesa degli utenti per la pubblicazione delle richieste.

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 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.
• Nell'intervallo di tempo specificato da min_pending_latency e max_pending_latency, App Engine proverà 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.

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

Le applicazioni che utilizzano una classe istanza di tipo B1 o superiore 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 creare per questa versione del servizio. Questo è utile per limitare i costi di un servizio.

idle_timeout

Facoltativo. L'istanza verrà arrestata per questo periodo di tempo dopo aver ricevuto l'ultima richiesta. Il valore predefinito è 5 minuti (5m).

basic_scaling:
  max_instances: 11
  idle_timeout: 10m

Le applicazioni che utilizzano una classe istanza di tipo 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.

manual_scaling:
  instances: 5