Questa pagina è stata tradotta dall'API Cloud Translation.

File di configurazione app.yaml

Il file app.yaml definisce le impostazioni di configurazione per il runtime, nonché le impostazioni generali di app, rete e altre risorse.

Non aggiungere app.yaml al file .gcloudignore. app.yaml potrebbe essere necessario per il deployment e l'aggiunta a .gcloudignore causerà l'esito negativo del deployment.

Sintassi

La sintassi del file app.yaml è il formato YAML. Il formato YAML supporta i commenti, in cui qualsiasi riga che inizia con il carattere simbolo hash (#) viene ignorata, ad esempio:

# This is a comment.

I pattern di URL e percorsi dei file utilizzano la sintassi delle espressioni regolari estese POSIX, escludendo gli elementi di confronto e le classi di confronto. Sono supportati i riferimenti inversi alle corrispondenze raggruppate (ad es. \1), così come le seguenti estensioni Perl: \w \W \s \S \d \D.

Impostazioni generali

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

Nome	Descrizione
`build_env_variables`	Facoltativo. Se utilizzi un runtime che supporta i buildpack, puoi definire le variabili di ambiente di build nel file `app.yaml`. Per scoprire di più, consulta la sezione Utilizzare le variabili di ambiente di build.
`runtime`	Obbligatorio. Il nome dell'ambiente di runtime utilizzato dalla tua app. Ad esempio, per specificare l'ambiente di runtime, utilizza:
`env: flex`	Obbligatorio: seleziona l'ambiente flessibile.
`service: service_name`	Obbligatorio se crei un servizio. Facoltativo per il servizio predefinito. Ogni servizio e ogni versione devono avere un nome. Un nome può contenere numeri, lettere e trattini. Nell'ambiente flessibile, la lunghezza combinata di `VERSION-dot-SERVICE-dot-PROJECT_ID` (dove `VERSION` è il nome della tua versione, `SERVICE` è il nome del tuo servizio e `PROJECT_ID` è il tuo ID progetto) non può superare i 63 caratteri e non può iniziare o terminare con un trattino. Se esegui il deployment senza specificare un nome di servizio, viene creata una nuova versione del servizio predefinito. Se esegui il deployment con un nome di servizio già esistente, viene creata una nuova versione del servizio. Se esegui il deployment con un nuovo nome di servizio che non esiste, vengono creati un nuovo servizio e una nuova versione. Ti consigliamo di utilizzare un nome univoco per ogni combinazione di servizio e versione. Nota:i servizi erano precedentemente denominati "moduli".
`service_account`	Facoltativo. L'elemento `service_account` consente di specificare un service account gestito dall'utente come identità per la versione. Il account di servizio specificato verrà utilizzato per accedere ad altri servizi Google Cloud ed eseguire le attività. Il account di servizio deve essere fornito nel seguente formato: service_account: [SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com
`skip_files`	Facoltativo. L'elemento `skip_files` specifica i file nella directory dell'applicazione che non devono essere caricati in App Engine. Il valore è un'espressione regolare o un elenco di espressioni regolari. Qualsiasi nome file che corrisponde a una delle espressioni regolari viene omesso dall'elenco dei file da caricare quando l'applicazione viene caricata. Ad esempio, per ignorare i file i cui nomi terminano con `.bak`, aggiungi una sezione `skip_files` come la seguente: skip_files: - ^.*\.bak$

Impostazioni di rete

Puoi specificare le impostazioni di rete nel file di configurazione app.yaml, ad esempio:

network:
  name: NETWORK_NAME
  instance_ip_mode: INSTANCE_IP_MODE
  instance_tag: TAG_NAME
  subnetwork_name: SUBNETWORK_NAME
  session_affinity: true
  forwarded_ports:
    - PORT
    - HOST_PORT:CONTAINER_PORT
    - PORT/tcp
    - HOST_PORT:CONTAINER_PORT/udp

Quando configuri le impostazioni di rete, puoi utilizzare le seguenti opzioni:

Opzione	Descrizione
`name`	A ogni istanza VM nell'ambiente flessibile viene assegnata una rete Google Compute Engine al momento della creazione. Utilizza questa impostazione per specificare un nome di rete. Fornisci il nome breve, non il percorso della risorsa (ad esempio `default` anziché `https://www.googleapis.com/compute/v1/projects/my-project/global/networks/default`). Se non specifichi un nome di rete, le istanze vengono assegnate alla rete predefinita del progetto (che ha il nome `default`). Se vuoi specificare un nome di subnet, devi specificare un nome di rete.
`instance_ip_mode`	Facoltativo. Per impedire alle istanze di ricevere un indirizzo IP esterno effimero, imposta `internal` e attiva l'accesso privato Google. Se la tua istanza è stata implementata in precedenza senza questa impostazione o con questa impostata su `external`, la nuova implementazione con questa impostata su `internal` rimuove gli indirizzi IP esterni temporanei dalle tue istanze. L'impostazione `internal` presenta limitazioni. Il valore predefinito è `external`.
`instance_tag`	Facoltativo. A ogni istanza del servizio viene assegnato un tag con questo nome al momento della creazione. I tag possono essere utili nei comandi `gcloud` per indirizzare un'azione a un gruppo di istanze. Ad esempio, vedi l'utilizzo dei flag `--source-tags` e `--target-tags` nel comando compute firewalls-create. Se non specificato, l'istanza viene taggata con `aef-INSTANCE_ID` quando non viene utilizzato il VPC condiviso. Se viene utilizzato il VPC condiviso, l'istanza viene taggata sia con `aef-INSTANCE_ID and aef-instance.`
`subnetwork_name`	Facoltativo. Puoi segmentare la rete e utilizzare una subnet personalizzata. Assicurati che sia specificata la rete `name`. Fornisci il nome breve, non il percorso della risorsa (ad esempio `default` anziché `https://www.googleapis.com/compute/v1/projects/my-project/global/networks/default/subnetworks/default`).La subnet deve trovarsi nella stessa regione dell'applicazione.
`session_affinity`	Facoltativo. Imposta `true` per configurare App Engine in modo da indirizzare più richieste sequenziali per un determinato utente alla stessa istanza App Engine, ad esempio quando memorizzi i dati utente localmente durante una sessione. L'affinità sessione consente di esaminare il valore di un cookie per identificare più richieste dello stesso utente e quindi indirizza tutte queste richieste alla stessa istanza. Se l'istanza viene riavviata, non è in stato di integrità, è sovraccarica o non è disponibile quando il numero di istanze è stato ridotto, l'affinità sessione viene interrotta e le richieste successive vengono indirizzate a un'altra istanza. Tieni presente che l'abilitazione della affinità sessione può influire sulla configurazione del bilanciamento del carico. Questo parametro è disattivato per impostazione predefinita.
`forwarded_ports`	Facoltativo. Puoi inoltrare le porte dalla tua istanza (`HOST_PORT`) al container Docker (`CONTAINER_PORT`). `HOST_PORT` deve essere compreso tra 1024 e 65535 e non può entrare in conflitto con le seguenti porte: 22, 8080, 8090, 8443, 10000, 10001, 10400-10500, 11211, 24231. `CONTAINER_PORT` deve essere compreso tra 1 e 65535 e non può essere in conflitto con le seguenti porte: 22, 10001, 10400-10500, 11211. Se specifichi solo una `PORT`, App Engine presuppone che sia la stessa porta sull'host e sul container. Per impostazione predefinita, viene inoltrato sia il traffico TCP che UDP. Il traffico deve essere indirizzato direttamente all'indirizzo IP dell'istanza di destinazione anziché tramite il dominio appspot.com o il tuo dominio personalizzato.

Configurazione di rete avanzata

Puoi segmentare la tua rete Compute Engine in subnet. Ciò consente di attivare scenari VPN, ad esempio l'accesso ai database all'interno della rete aziendale.

Per attivare le subnet per l'applicazione App Engine:

Crea una rete di subnet personalizzata.
Aggiungi il nome della rete e della subnet al file app.yaml, come specificato sopra.
Per stabilire una VPN semplice basata sul routing statico, crea un gateway e un tunnel per una rete di subnet personalizzata. In caso contrario, scopri come creare altri tipi di VPN.

Port forwarding

Il port forwarding consente connessioni dirette al container Docker sulle tue istanze. Questo traffico può viaggiare su qualsiasi protocollo. Il port forwarding è pensato per aiutarti nelle situazioni in cui potresti dover collegare un debugger o un profiler. Il traffico deve essere indirizzato direttamente all'indirizzo IP dell'istanza di destinazione anziché tramite il dominio appspot.com o il tuo dominio personalizzato.

Per impostazione predefinita, il traffico in entrata dall'esterno della rete non è consentito tramite i firewall di Google Cloud Platform. Dopo aver specificato il port forwarding nel file app.yaml, devi aggiungere una regola firewall che consenta il traffico dalle porte che vuoi aprire.

Puoi specificare una regola firewall nella pagina Regole firewall di Networking nella Google Cloud console o utilizzando i gcloudcomandi.

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

Nelle impostazioni di rete del tuo app.yaml, includi:
```
network:
  forwarded_ports:
    - 2222/tcp
```
1. Se utilizzi il runtime Python, modifica app.yaml in modo che includa:
```
entrypoint: gunicorn -b :$PORT -b :2222 main:app
```
Specifica una regola firewall nella consoleGoogle Cloud o utilizzando gcloud compute firewall-rules create per consentire il traffico da qualsiasi origine (0.0.0.0/0) e da tcp:2222.

Impostazioni risorse

Queste impostazioni controllano le risorse di elaborazione. App Engine assegna un tipo di macchina in base alla quantità di CPU e memoria specificate. La macchina ha garantito almeno il livello di risorse che hai specificato, ma potrebbe averne di più.

Puoi specificare fino a otto volumi di tmpfs nelle impostazioni delle risorse. Puoi quindi attivare i carichi di lavoro che richiedono memoria condivisa tramite tmpfs e migliorare l'I/O del file system.

Ad esempio:

resources:
  cpu: 2
  memory_gb: 2.3
  disk_size_gb: 10
  volumes:
  - name: ramdisk1
    volume_type: tmpfs
    size_gb: 0.5

Puoi utilizzare le seguenti opzioni durante la configurazione delle impostazioni delle risorse:

Opzione	Descrizione	Predefinito
`cpu`	Il numero di core deve essere uno, un numero pari compreso tra 2 e 32 o un multiplo di 4 compreso tra 32 e 80.	1 core
`memory_gb`	RAM in GB. La memoria richiesta per l'applicazione, che non include i circa 0,4 GB di memoria necessari per l'overhead di alcuni processi. Ogni core CPU richiede una memoria totale compresa tra 1 e 6,5 GB. Per calcolare la memoria richiesta: `memory_gb` = `cpu` * [1,0 - 6,5] - 0,4 Per l'esempio precedente in cui hai specificato 2 core, puoi richiedere tra 1,6 e 12,6 GB. La quantità totale di memoria disponibile per l'applicazione viene impostata dall'ambiente di runtime come variabile di ambiente `GAE_MEMORY_MB`.	0,6 GB
`disk_size_gb`	Dimensione in GB. Il valore minimo è 10 GB e il valore massimo è 10240 GB.	13 GB
`name`	Obbligatorio se utilizzi i volumi. Nome del volume. I nomi devono essere univoci e composti da un numero di caratteri compreso tra 1 e 63. I caratteri possono essere lettere minuscole, numeri o trattini. Il primo carattere deve essere una lettera e l'ultimo non può essere un trattino. Il volume è montato nel container dell'app come `/mnt/NAME`.
`volume_type`	Obbligatorio se utilizzi i volumi. Deve essere `tmpfs`.
`size_gb`	Obbligatorio se utilizzi i volumi. Dimensioni del volume, in GB. Il valore minimo è 0,001 GB e il valore massimo è la quantità di memoria disponibile nel container dell'applicazione e sul dispositivo sottostante. Google non aggiunge RAM aggiuntiva al sistema per soddisfare i requisiti del disco. La RAM allocata per i volumi tmpfs verrà sottratta dalla memoria disponibile per il container dell'app. La precisione dipende dal sistema.

Controlli di integrità periodici

Per impostazione predefinita, i controlli di integrità periodici sono attivati. Puoi utilizzare le richieste periodiche di controllo di integrità per verificare che un'istanza VM sia stata implementata correttamente e per controllare che un'istanza in esecuzione mantenga uno stato integro. A ogni controllo di integrità deve essere data una risposta entro un intervallo di tempo specificato.

Un'istanza è in stato non integro quando non risponde a un numero specificato di richieste di controllo di integrità consecutive. Se un'istanza non è attiva, viene riavviata. Se un'istanza non è pronta, non riceverà richieste client. Un controllo di integrità può non riuscire anche se non è presente spazio libero sul disco.

Puoi utilizzare due tipi di controlli dell'integrità:

I controlli di attività confermano che la VM e il container Docker sono in esecuzione. App Engine riavvia le istanze non integre.
I controlli di idoneità confermano che la tua istanza è pronta ad accettare le richieste in entrata. Le istanze che non superano il controllo di idoneità non vengono aggiunte al pool di istanze disponibili.

Per impostazione predefinita, le richieste HTTP dai controlli di integrità non vengono inoltrate al container dell'applicazione. Se vuoi estendere i controlli di integrità alla tua applicazione, specifica un percorso per i controlli di attività o controlli di idoneità. Un controllo di integrità personalizzato per la tua applicazione viene considerato riuscito se restituisce un codice di risposta 200 OK.

Controlli di attività

I controlli di attività confermano che la VM e il container Docker sono in esecuzione. Le istanze considerate in stato non integro vengono riavviate.

Puoi personalizzare le richieste di verifica della vitalità aggiungendo una sezione liveness_check facoltativa al file app.yaml, ad esempio:

liveness_check:
  path: "/liveness_check"
  check_interval_sec: 30
  timeout_sec: 4
  failure_threshold: 2
  success_threshold: 2

Per i controlli di vivacità sono disponibili le seguenti impostazioni:

Campo	Predefinito	Intervallo (minimo-massimo)	Descrizione
`path`	Nessuno		Se vuoi che i controlli di vivacità vengano inoltrati al container dell'applicazione, specifica un percorso URL, ad esempio `"/liveness_check"`
`timeout_sec`	4 secondi	1-300	Intervallo di timeout per ogni richiesta, in secondi.
`check_interval_sec`	30 secondi	1-300	Intervallo di tempo tra i controlli, in secondi. Tieni presente che questo valore deve essere maggiore di timeout_sec.
`failure_threshold`	4 controlli	1-10	Un'istanza è in stato non integro dopo aver superato questo numero di controlli consecutivi.
`success_threshold`	2 controlli	1-10	Un'istanza non integra torna a essere integra dopo aver risposto correttamente a questo numero di controlli consecutivi.
`initial_delay_sec`	300 secondi	0-3600	Il ritardo, in secondi, dopo l'avvio dell'istanza durante il quale le risposte del controllo di integrità vengono ignorate. Questa impostazione si applica a ogni istanza appena creata e può consentire a una nuova istanza di avere più tempo per essere operativa. L'impostazione ritarda la riparazione automatica dal controllo e dalla potenziale ricreazione prematura dell'istanza se è in fase di avvio. Il timer del ritardo iniziale si avvia quando l'istanza è in modalità RUNNING. Ad esempio, potresti voler aumentare il ritardo se la tua applicazione ha attività di inizializzazione che richiedono molto tempo prima di essere pronta a gestire il traffico.

Controlli di idoneità

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

Puoi personalizzare le richieste di controllo di integrità aggiungendo una sezione readiness_check facoltativa al file app.yaml, ad esempio:

readiness_check:
  path: "/readiness_check"
  check_interval_sec: 5
  timeout_sec: 4
  failure_threshold: 2
  success_threshold: 2
  app_start_timeout_sec: 300

Per i controlli di idoneità sono disponibili le seguenti impostazioni:

Campo	Predefinito	Intervallo (minimo-massimo)	Descrizione
`path`	Nessuno		Se vuoi che i controlli di idoneità vengano inoltrati al container dell'applicazione, specifica un percorso URL, ad esempio `"/readiness_check"`
`timeout_sec`	4 secondi	1-300	Intervallo di timeout per ogni richiesta, in secondi.
`check_interval_sec`	5 secondi	1-300	Intervallo di tempo tra i controlli, in secondi. Tieni presente che questo valore deve essere maggiore di timeout_sec.
`failure_threshold`	2 controlli	1-10	Un'istanza è in stato non integro dopo aver superato questo numero di controlli consecutivi.
`success_threshold`	2 controlli	1-10	Un'istanza non integra diventa integra dopo aver risposto correttamente a questo numero di controlli consecutivi.
`app_start_timeout_sec`	300 secondi	1-1800	Questa impostazione si applica ai nuovi deployment, non alle singole VM. Specifica il tempo massimo in secondi consentito per un numero sufficiente di istanze in un deployment per superare i controlli di integrità. Se questa durata viene superata, il deployment non va a buon fine e viene eseguito il rollback. Il timer inizia quando le istanze Compute Engine sono state provisionate e il servizio di backend del bilanciatore del carico è stato creato. Ad esempio, potresti voler aumentare il timeout se vuoi fornire timeout più lunghi durante i deployment per un numero sufficiente di istanze per diventare integre.

Frequenza del controllo di integrità

Per garantire l'alta disponibilità, App Engine crea copie ridondanti di ogni controllo di integrità. Se un controllo di integrità non riesce, un controllo ridondante può subentrare senza ritardi.

Se esamini i log nginx.health_check per la tua applicazione, potresti notare che il polling del controllo di integrità viene eseguito più spesso di quanto hai configurato, a causa dei controlli di integrità ridondanti che seguono anche le tue impostazioni. Questi controlli di integrità ridondanti vengono creati automaticamente e non puoi configurarli.

Impostazioni di scalabilità del servizio

Le chiavi utilizzate per controllare lo scaling di un servizio dipendono dal tipo di scaling che assegni al servizio.

Puoi utilizzare lo scaling automatico o manuale. L'impostazione predefinita è la scalabilità automatica.

Scalabilità automatica

Puoi configurare la scalabilità automatica aggiungendo una sezione automatic_scaling al file app.yaml. Ad esempio:

automatic_scaling:
  min_num_instances: 1
  max_num_instances: 15
  cool_down_period_sec: 180
  cpu_utilization:
    target_utilization: 0.6
  target_concurrent_requests: 100

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

Nome	Descrizione
`automatic_scaling`	La scalabilità automatica è presupposta per impostazione predefinita. Includi questa riga se specificerai una delle impostazioni di scalabilità automatica.
`min_num_instances`	Il numero minimo di istanze assegnate al servizio. Quando viene eseguito il deployment di un servizio, gli viene assegnato questo numero di istanze e viene scalato in base al traffico. Deve essere pari o superiore a `1`, il valore predefinito è `2` per ridurre la latenza. Nota: il numero di istanze in esecuzione potrebbe scendere al di sotto di questo valore per un breve periodo di tempo durante alcuni eventi. Se la tua applicazione richiede l'esecuzione continua su un determinato numero di istanze, valuta il provisioning eccessivo.
`max_num_instances`	Il numero massimo di istanze a cui il tuo servizio può scalare. Il numero massimo di istanze nel tuo progetto è limitato dalla quota di risorse del progetto. Il valore predefinito è `20`.
`cool_down_period_sec`	Il numero di secondi che lo strumento di scalabilità automatica deve attendere prima di iniziare a raccogliere informazioni da una nuova istanza. In questo modo, il gestore della scalabilità automatica non raccoglie informazioni durante l'inizializzazione dell'istanza, durante la quale l'utilizzo raccolto non sarebbe affidabile. Il periodo di raffreddamento deve essere maggiore o uguale a 60 secondi. Il valore predefinito è `120`.
`cpu_utilization`	Utilizza questa intestazione se vuoi specificare l'utilizzo target della CPU.
`target_utilization`	Utilizzo CPU target. L'utilizzo della CPU viene calcolato in media su tutte le istanze in esecuzione e viene utilizzato per decidere quando ridurre o aumentare il numero di istanze. Tieni presente che le istanze vengono ridimensionate indipendentemente dalle richieste in corso 25 secondi dopo che un'istanza riceve il segnale di arresto. Il valore predefinito è `0.5`.
`target_concurrent_requests`	(Beta) Numero target di connessioni simultanee per istanza. Se specifichi un valore per questo parametro, il gestore della scalabilità automatica utilizza il numero medio di connessioni simultanee su tutte le istanze in esecuzione per decidere quando ridurre o aumentare il numero di istanze. Il downscaling di un'istanza viene eseguito 25 secondi dopo la ricezione del segnale di arresto, indipendentemente dalle richieste in corso. Se non specifichi un valore per questo parametro, il gestore della scalabilità automatica non ha come target un numero di connessioni simultanee per istanza. Le connessioni sono diverse dalle richieste. Una connessione può essere riutilizzata da un client per inviare più richieste.

Scalabilità manuale

Puoi configurare lo scaling manuale aggiungendo una sezione manual_scaling al file app.yaml. Ad esempio:

manual_scaling:
  instances: 5

La seguente tabella elenca le impostazioni che puoi utilizzare con lo scaling manuale:

Nome	Descrizione
`manual_scaling`	Obbligatorio per attivare la scalabilità manuale per un servizio.
`instances`	Il numero di istanze da assegnare al servizio. Nota: il numero di istanze in esecuzione potrebbe scendere al di sotto di questo valore per un breve periodo di tempo durante alcuni eventi. Se la tua applicazione richiede l'esecuzione continua su un determinato numero di istanze, valuta il provisioning eccessivo.

Definizione delle variabili di ambiente

Puoi definire le variabili di ambiente in app.yaml per renderle disponibili per la tua app, ad esempio:

env_variables:
  MY_VAR: "my value"

dove MY_VAR e my value sono il nome e il valore della variabile di ambiente che vuoi definire e ogni voce della variabile di ambiente è rientrata di due spazi sotto l'elemento env_variables.