Il file app.yaml
definisce le impostazioni di configurazione per il runtime, nonché le impostazioni generali dell'app, della rete e di altre risorse.
Non aggiungere app.yaml
al file .gcloudignore
. Per il deployment potrebbe essere necessario app.yaml
e la sua aggiunta a
.gcloudignore
comporterà la mancata riuscita del deployment.
Sintassi
La sintassi del file app.yaml
è nel formato YAML.
Il formato YAML supporta i commenti, in cui qualsiasi riga che inizia con il simbolo hash (#
) viene ignorata, ad esempio:
# This is a comment.
I pattern per URL e percorsi file utilizzano la sintassi delle espressioni regolari estese, esclusi gli elementi di confronto e le classi di confronto. Sono supportati i riferimenti a corrispondenze raggruppate (ad es. \1
), così come le seguenti estensioni Perl: \w \W \s \S \d \D
.
Impostazioni generali
Un file app.yaml
può includere queste impostazioni generali. Tieni presente che alcuni
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 Per scoprire di più, consulta Utilizzo delle 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, usa: |
runtime_config |
Specifica la versione del runtime Python. A partire dalla versione 3.8 di Python, devi specificare la versione del sistema operativo.
runtime_config: operating_system: "ubuntu22" runtime_version: "3.12"
|
runtime_config |
Specifica la versione Go. A partire dalla versione 1.18 di Go, devi specificare la versione del sistema operativo. Ad esempio, se scegli Vai 1.22:
runtime_config: operating_system: "ubuntu22" runtime_version: "1.22"
|
runtime_config |
Specifica la versione di Node.js. A partire dalla versione 18 di Node.js, devi specificare la versione del sistema operativo.
runtime_config: operating_system: "ubuntu22" runtime_version: "22"
|
runtime_config |
Specifica la versione Java. A partire dalla versione 11 di Java, devi specificare la versione del sistema operativo.
runtime_config: operating_system: "ubuntu22" runtime_version: "21"
|
runtime_config |
A partire da Ruby versione 3.2, devi specificare la versione del sistema operativo.
runtime_config: operating_system: "ubuntu22"
Obbligatorio per la versione 3.2 e successive. Non supportato per Ruby versione 3.1 e precedenti. Vedi le versioni e i runtime di Ubuntu supportati nella pagina dei runtime Ruby. |
runtime_config |
A partire da .NET versione 6 e successive, devi specificare la versione del sistema operativo.
runtime_config: operating_system: "ubuntu22"
|
runtime_config |
Specifica la versione PHP. A partire dalla versione 7.4 di PHP, devi specificare la versione del sistema operativo.
runtime_config: operating_system: "ubuntu22" runtime_version: "8.3"
|
env: flex |
Obbligatorio: seleziona l'ambiente flessibile. |
entrypoint |
Il comando per avviare l'applicazione. Il punto di ingresso avvia un processo che risponde alle richieste HTTP sulla porta definita dalla variabile di ambiente PORT .
|
service: service_name |
Obbligatorio se si crea 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 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.
Se esegui il deployment senza specificare un nome 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 servizio che non esiste, vengono creati un nuovo servizio e una nuova versione. Ti consigliamo di utilizzare un nome univoco per ogni combinazione servizio-versione. Nota: in precedenza i servizi erano chiamati "moduli". |
service_account |
Facoltativo. L'elemento L'account di servizio deve essere fornito nel seguente formato: service_account: [SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com |
skip_files |
Facoltativo.
L'elemento
Ad esempio, per saltare i file i cui nomi terminano con skip_files: - ^.*\.bak$ |
Impostazioni di rete
Puoi specificare le impostazioni di rete nel file di configurazione di 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 |
Ogni istanza VM nell'ambiente flessibile viene assegnata a una rete Google Compute Engine al momento della creazione. Utilizza questa impostazione per specificare un nome di rete. Assegna 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 il nome di una subnet, devi specificare un nome di rete. |
instance_ip_mode |
Facoltativo. Per impedire alle istanze di ricevere un indirizzo IP esterno temporaneo, impostalo su internal e abilita l'accesso privato Google. Se il deployment dell'istanza è stato precedentemente eseguito senza questa impostazione o se il deployment è stato eseguito con il valore impostato su external , il nuovo deployment con questo criterio impostato su internal rimuove gli indirizzi IP esterni temporanei dalle tue istanze. L'impostazione internal ha limitazioni. Il valore predefinito è external . |
instance_tag |
Facoltativo. Un tag con questo nome viene assegnato a ciascuna istanza del servizio quando viene creato. I tag possono essere utili nei comandi gcloud per indirizzare un'azione a un gruppo di istanze. Ad esempio, osserva 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 un VPC condiviso, l'istanza include sia aef-INSTANCE_ID |
subnetwork_name |
Facoltativo. Puoi segmentare la rete e utilizzare una subnet personalizzata. Assicurati che la rete name sia specificata. Assegna 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 instradare più richieste sequenziali per un determinato utente alla stessa istanza di App Engine, ad esempio quando i dati utente vengono archiviati localmente durante una sessione. L'affinità sessione consente di ispezionare il valore di un cookie per identificare più richieste dello stesso utente, quindi indirizza tutte queste richieste alla stessa istanza. Se l'istanza viene riavviata, non è integro, è sovraccarico o non è disponibile dopo lo scale down del numero di istanze, l'affinità sessione verrà interrotta e ulteriori richieste vengono instradate a un'altra istanza. Tieni presente che l'attivazione dell'affinità sessione può influire sulla configurazione del bilanciamento del carico. Questo parametro è disattivato per impostazione predefinita. |
forwarded_ports |
Facoltativo. Puoi inoltrare le porte dall'istanza (HOST_PORT ) al container Docker (CONTAINER_PORT ). HOST_PORT deve essere compreso tra 1024 e 65535 e non può essere in conflitto con le seguenti porte: 22, 8080, 8090, 8443, 10000, 10001, 10400-10500, 21231. 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 un valore PORT , App Engine presuppone che si tratti della stessa porta sull'host e sul container. Per impostazione predefinita, viene inoltrato il traffico TCP e UDP. Il traffico deve essere indirizzato direttamente all'indirizzo IP dell'istanza di destinazione anziché sul dominio appspot.com o sul tuo dominio personalizzato. |
Configurazione di rete avanzata
Puoi segmentare la rete Compute Engine in subnet. Ciò consente di abilitare scenari VPN, ad esempio l'accesso ai database all'interno della rete aziendale.
Per abilitare le subnet per la tua applicazione App Engine:
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 le connessioni dirette al container Docker nelle tue istanze. Questo traffico può viaggiare su qualsiasi protocollo. Il port forwarding è pensato per aiutare a situazioni in cui potrebbe essere necessario collegare un debugger o un profiler. Il traffico deve essere indirizzato direttamente all'indirizzo IP dell'istanza di destinazione anziché sul dominio appspot.com o sul tuo dominio personalizzato.
Per impostazione predefinita, il traffico in entrata dall'esterno della rete non è consentito attraverso 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 rete della
console Google Cloud
oppure utilizzando i comandi gcloud
.
Ad esempio, se vuoi inoltrare il traffico TCP dalla porta 2222
:
Nelle impostazioni della rete di
app.yaml
, includi:network: forwarded_ports: - 2222/tcp
Se utilizzi il runtime Python, modifica
app.yaml
in modo da includere:entrypoint: gunicorn -b :$PORT -b :2222 main:app
Specifica una regola firewall nella console Google Cloud oppure utilizzando
gcloud compute firewall-rules create
per consentire il traffico da qualsiasi origine (0.0.0.0/0
) e datcp:2222
.
Impostazioni risorse
Queste impostazioni controllano le risorse di calcolo. App Engine assegna un tipo di macchina in base alla quantità di CPU e memoria specificata. La macchina dispone di almeno il livello di risorse specificato, potrebbe averne di più.
Puoi specificare fino a otto volumi di tmpfs nelle impostazioni delle risorse. Puoi abilitare 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
Quando configuri le impostazioni delle risorse, puoi utilizzare le seguenti opzioni:
Opzione | Descrizione | Predefinita |
---|---|---|
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 la tua applicazione, che non include i circa 0,4 GB di memoria necessari per l'overhead di alcuni processi. Ogni core della CPU richiede una memoria totale compresa tra 1,0 e 6,5 GB. Per calcolare la memoria richiesta:
Nell'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 è impostata dall'ambiente di runtime come variabile
di ambiente |
0,6 GB |
disk_size_gb |
Dimensioni in GB. Il valore minimo è 10 GB e il massimo è 10.240 GB. | 13 GB |
name |
Obbligatorio, se utilizzi volumi. Nome del volume. I nomi devono essere univoci e hanno una lunghezza compresa tra 1 e 63 caratteri. 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 volumi. Deve essere tmpfs . |
|
size_gb |
Obbligatorio, se utilizzi volumi. Dimensione del volume, in GB. Il minimo è 0,001 GB e il massimo è la quantità di memoria disponibile nel container dell'applicazione e sul dispositivo sottostante. Google non aggiunge ulteriore RAM al sistema per soddisfare i requisiti del disco. La RAM allocata per i volumi tmpfs verrà sottratta dalla memoria disponibile per il container di app. La precisione dipende dal sistema. |
Suddividi i controlli di integrità
Per impostazione predefinita, sono abilitati i controlli di integrità suddivisi. Puoi utilizzare richieste di controllo di integrità periodiche per confermare che il deployment di un'istanza VM sia stato eseguito correttamente e per verificare che un'istanza in esecuzione mantenga lo stato integro. Ogni controllo di integrità deve rispettare entro un intervallo di tempo specificato.
Un'istanza non è integro quando non riesce a rispondere 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à alcuna richiesta del client. Un controllo di integrità può anche avere esito negativo se non c'è spazio libero su disco.
Puoi utilizzare due tipi di controlli di integrità:
- I controlli di attività confermano che la VM e il container Docker sono in esecuzione. App Engine riavvia le istanze in stato non integro.
- I controlli di idoneità confermano che l'istanza è pronta per accettare richieste in arrivo. Le istanze che non superano il controllo di idoneità non vengono aggiunte al pool di istanze disponibili.
Per impostazione predefinita, le richieste HTTP dei controlli di integrità non vengono inoltrate al container delle applicazioni. Se vuoi estendere i controlli di integrità alla tua applicazione,
specifica un percorso per i controlli di attività o i
controlli di idoneità. Un controllo di integrità personalizzato della 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 non integre vengono riavviate.
Puoi personalizzare le richieste di controllo di attività 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 attività sono disponibili le seguenti impostazioni:
Campo | Predefinita | Intervallo (minimo-massimo) | Descrizione |
---|---|---|---|
path |
Nessuna | Se vuoi che i controlli di attività vengano inoltrati al tuo container dell'applicazione, specifica un percorso dell'URL, ad esempio "/liveness_check" |
|
timeout_sec |
4 secondi | 1-300 | Intervallo di timeout in secondi per ogni richiesta. |
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 non è integro dopo aver superato questo numero di controlli consecutivi. |
success_threshold |
2 controlli | 1-10 | Un'istanza in stato non integro diventa di nuovo integro 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ò concedere a una nuova istanza più tempo per essere operativa. L'impostazione ritarda il controllo della riparazione automatica e la ricreazione prematura dell'istanza se è in fase di avvio. Il timer del ritardo iniziale si avvia quando l'istanza è in modalità IN ESECUZIONE. 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 le 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 | Predefinita | Intervallo (minimo-massimo) | Descrizione |
---|---|---|---|
path |
Nessuna | Se vuoi che i controlli di idoneità vengano inoltrati al tuo container dell'applicazione, specifica un percorso dell'URL, ad esempio "/readiness_check" |
|
timeout_sec |
4 secondi | 1-300 | Intervallo di timeout in secondi per ogni richiesta. |
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 non è integro dopo aver superato questo numero di controlli consecutivi. |
success_threshold |
2 controlli | 1-10 | Un'istanza in stato non integro diventa integro 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 riesce e viene eseguito il rollback. Il timer parte dopo che è stato eseguito il provisioning delle istanze di Compute Engine e la creazione del servizio di backend del bilanciatore del carico. Ad esempio, puoi aumentare il timeout se vuoi fornire timeout più lunghi durante i deployment affinché un numero sufficiente di istanze si integrino. |
Frequenza del controllo di integrità
Per garantire l'alta disponibilità, App Engine crea copie ridondanti di ogni controllo di integrità. In caso di errore di un controllo di integrità, ne può prendere il controllo uno ridondante senza ritardi.
Se esamini i log nginx.health_check
per la tua applicazione, potresti notare che il polling del controllo di integrità avviene più spesso di quanto configurato, a causa dei controlli di integrità ridondanti che seguono le tue impostazioni. Questi
controlli di integrità ridondanti vengono creati automaticamente e non è possibile
configurarli.
Impostazioni di scalabilità del servizio
Le chiavi utilizzate per controllare la scalabilità di un servizio dipendono dal tipo di scalabilità assegnato al servizio.
Puoi utilizzare la scalabilità automatica 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 tabella seguente elenca le impostazioni che puoi utilizzare con la scalabilità automatica:
Nome | Descrizione |
---|---|
automatic_scaling |
Per impostazione predefinita viene utilizzata la scalabilità automatica. Includi questa riga se specificherai una delle impostazioni di scalabilità automatica. |
min_num_instances |
Il numero minimo di istanze assegnato al tuo servizio. Quando viene eseguito il deployment di un servizio, riceve questo numero di istanze e scala in base al traffico.
Deve essere 1 o superiore; il valore predefinito è 2 per ridurre
la latenza.
|
max_num_instances |
Il numero massimo di istanze fino a cui è possibile
fare lo scale up del tuo servizio. Il numero massimo di istanze nel progetto è limitato dalla quota delle risorse del progetto.
Il valore predefinito è 20 .
|
cool_down_period_sec |
Il numero di secondi che il gestore della scalabilità automatica deve attendere prima di iniziare a raccogliere informazioni da una nuova istanza. Questo impedisce al gestore della scalabilità automatica di raccogliere informazioni durante l'inizializzazione dell'istanza, durante il quale l'utilizzo raccolto non sarebbe affidabile. Il periodo di attesa deve essere maggiore o uguale a 60 secondi.
Il valore predefinito è 120 .
|
cpu_utilization |
Utilizza questa intestazione se specificherai 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 di destinazione di connessioni simultanee per istanza. Se specifichi un valore per questo parametro, il gestore della scalabilità automatica utilizza il numero medio di connessioni simultanee tra tutte le istanze in esecuzione per decidere quando ridurre o aumentare il numero di istanze. Un'istanza viene scalata 25 secondi dopo aver ricevuto il segnale di arresto, indipendentemente dalle richieste in corso. Se non specifichi un valore per questo parametro, il gestore della scalabilità automatica non sceglie 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 la scalabilità manuale aggiungendo una sezione manual_scaling
al file app.yaml
. Ad esempio:
manual_scaling:
instances: 5
La tabella seguente elenca le impostazioni che puoi utilizzare con la scalabilità manuale:
Nome | Descrizione |
---|---|
manual_scaling |
Necessario per abilitare la scalabilità manuale di un servizio. |
instances |
Il numero di istanze da assegnare al servizio. |
definisci le 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
da definire e ogni voce della variabile di ambiente è rientrata di due
spazi sotto l'elemento env_variables
.
Utilizzo delle variabili di ambiente