Questa guida descrive come Cloud Run gestisce i deployment, suddivisi in tre aree:
- Tipi di deployment: cosa porti in Cloud Run, ad esempio codice sorgente o immagini container.
- Risorse Cloud Run: cosa viene eseguito il deployment in Cloud Run (servizio, job, pool di worker o istanza).
- Metodi di deployment: come esegui il deployment, ad esempio utilizzando la Google Cloud console, gcloud CLI, YAML o Terraform.
Tipi di deployment
Cloud Run offre più opzioni di deployment. Dopo il deployment, tutti i deployment, le esecuzioni o le creazioni vengono eseguiti come istanze container in sandbox sull'infrastruttura completamente gestita e altamente scalabile di Cloud Run. La tabella seguente mostra le opzioni di deployment supportate per ogni tipo di risorsa:
| Opzione di deployment | Servizi | Job | Pool di worker | Istanze |
|---|---|---|---|---|
| Esegui il deployment delle immagini container | Supportato | Supportato | Supportato | Supportato |
| Esegui il deployment dal codice sorgente | Supportato | Supportato | Supportato | — |
| Esegui il deployment delle funzioni1 | Supportato | — | — | — |
| Deployment continuo da git | Supportato | — | — | — |
1 Le funzioni sono una versione specializzata del deployment del codice sorgente per il codice basato su eventi a uso specifico.
Esegui il deployment delle immagini container
Puoi eseguire il deployment di qualsiasi immagine container conforme al contratto di runtime container di Cloud Run in un servizio Cloud Run o in un servizio job, un job, un pool di worker o un'istanza.
Esegui il deployment dal codice sorgente
Per comodità, Cloud Run ti consente di creare ed eseguire il deployment del codice sorgente da un singolo comando. Per i dettagli, consulta Eseguire il deployment dei servizi dal codice sorgente, Eseguire job dal codice sorgente ed Eseguire il deployment dei pool di worker dal codice sorgente.
Quando esegui il deployment dal codice sorgente, Cloud Build trasforma il codice in un'immagine container archiviata in Artifact Registry. Puoi eseguire il deployment del codice sorgente che include
un Dockerfile o che utilizza uno dei runtime di linguaggio supportati.
Funzioni
Puoi eseguire il deployment di funzioni a uso specifico che rispondono agli eventi generati dall'infrastruttura cloud e dai servizi cloud. Cloud Run attiva la funzione quando viene attivato un evento monitorato.
Il deployment di una funzione è un tipo speciale di deployment del codice sorgente, in cui devi fornire solo il codice della funzione. Puoi scrivere funzioni Cloud Run utilizzando una serie di linguaggi di programmazione supportati.
Il deployment di una funzione crea un servizio Cloud Run service.
Deployment continuo del codice sorgente da git
Cloud Run ti aiuta a configurare il deployment continuo da
Git. Come per i deployment
di origine, puoi eseguire il deployment del codice sorgente che
include un Dockerfile o scritto in uno dei runtime di linguaggio supportati.
Il deployment continuo da Git è disponibile per i servizi Cloud Run . Puoi configurarli manualmente in Cloud Build per i job Cloud Run .
Risorse Cloud Run
Le sezioni seguenti descrivono le risorse Cloud Run in modo più dettagliato.
Confronto delle risorse Cloud Run
| Funzionalità | Servizi | Job | Pool di worker | Istanze |
|---|---|---|---|---|
| Caso d'uso primario | Basato su richieste (siti web, API, microservizi) | Basato su attività (script, elaborazione dei dati, migrazioni) | Basato su eventi/pull (consumer Kafka/Pub/Sub) | Singleton gestito (workload agentici, esigenze di calcolo specifiche) |
| Trigger | Richieste HTTP/gRPC, Eventarc | Modalità di esecuzione: standard (immediata), ritardata. Trigger: esecuzione manuale, utilizzo di Scheduler, utilizzo di Workflows |
Sempre attivo O con scalabilità automatica utilizzando il lavoro in background basato su pull | Nessuno |
| Scalabilità | Automatica/manuale: scala a zero o in base alle richieste | Automatica: scala a N attività indipendenti eseguite in sequenza o in parallelo. | Automatica/manuale: numero fisso di istanze che utilizzano la scalabilità manuale o la scalabilità automatica integrata in base all'utilizzo della CPU o al backlog dei messaggi Pub/Sub (scalabilità automatica basata su KEDA che utilizza il gestore della scalabilità automatica esterna) | Nessuna: nessuna scalabilità automatica; gestibile singolarmente |
| Ciclo di vita | Temporaneo, si riduce in caso di inattività | Esegue fino al completamento per un massimo di 7 giorni (di breve durata) | Scelta tra processi in background sempre attivi O istanze temporanee con scalabilità automatica. | Di lunga durata (può essere eseguito per giorni/settimane) e riavviarsi automaticamente a tempo indeterminato |
| Indirizzamento | URL del servizio stabile (con bilanciamento del carico) | Nessun endpoint pubblico. URL interno per i trigger (ad es. scheduler) |
Nessun endpoint pubblico. Accesso in entrata basato su IP VPC diretto privato |
URL individuale per istanza |
| Traffico in entrata | HTTP/gRPC pubblico/interno | Nessuno | Ingresso L4 basato su IP con VPC diretto | URL pubblico/interno per istanza |
| Fatturazione | Basata sulle richieste o sulle istanze | Durata per esecuzione | Durata per istanza | Durata per istanza |
Servizi Cloud Run
Un servizio è il tipo di risorsa principale in Cloud Run e rappresenta un carico di lavoro basato su richieste che scala automaticamente le istanze container per gestire il traffico web in entrata, le richieste HTTP o gli eventi. Ogni servizio si trova in una regione Google Cloud specifica. Per fornire ridondanza e failover, Cloud Run replica automaticamente i servizi su più zone all'interno di una regione. Un determinato Google Cloud progetto può eseguire molti servizi in regioni diverse.
Ogni servizio espone un endpoint univoco. Per impostazione predefinita, Cloud Run scala automaticamente per gestire le richieste in entrata. Se necessario, puoi modificare il comportamento di scalabilità in manual scaling. Puoi eseguire il deployment di un servizio da un container, un repository o un codice sorgente.
Il seguente diagramma mostra il modello di risorse Cloud Run per i servizi:
Il diagramma mostra un Google Cloud progetto contenente tre servizi Cloud Run, Servizio A, Servizio B e Servizio C, ognuno dei quali ha diverse revisioni:
- Il servizio A riceve più richieste, quindi Cloud Run ha avviato più istanze per gestire il carico. Ognuna di queste istanze esegue un solo container (il container dell'applicazione).
- Il servizio B non ha richieste, quindi è inattivo e Cloud Run non esegue alcuna istanza.
- Il servizio C ha richieste ed è stato scalato per gestire il carico creando più istanze. In questo caso, ognuna di queste istanze esegue un insieme di più container. In ogni insieme, solo il container di ingresso riceve la richiesta, ma gli altri container aiutano a soddisfarla.
Revisioni del servizio Cloud Run
Ogni deployment in un servizio crea una revisione. Una revisione è composta da una o più immagini container, insieme a impostazioni di configurazione come variabili di ambiente, limiti di memoria o valore di concorrenza delle richieste.
Non puoi modificare una revisione dopo la sua creazione. Ad esempio, quando esegui il deployment di un'immagine container in un nuovo servizio, Cloud Run crea la prima revisione. Se poi esegui il deployment di un'immagine container diversa nello stesso servizio, Cloud Run crea una seconda revisione. Se in seguito imposti una variabile di ambiente, Cloud Run crea una terza revisione. Nel tempo, Cloud Run rimuove le revisioni inutilizzate.
Cloud Run instrada automaticamente le richieste il prima possibile all'ultima revisione del servizio integro.
Istanze del servizio Cloud Run
Cloud Run scala automaticamente ogni revisione del servizio che riceve richieste al numero di istanze necessarie per gestire tutte queste richieste. Tieni presente che le istanze possono ricevere molte richieste contemporaneamente. Con l'impostazione di concorrenza delle richieste, puoi impostare il numero massimo di richieste che possono essere inviate in parallelo a ogni istanza di una revisione.
Job Cloud Run
Ogni job si trova in una Google Cloud regione specifica ed è composto da una o più attività di job che eseguono uno o più container fino al completamento. Le attività di job sono indipendenti e possono essere eseguite in parallelo in una determinata esecuzione di job.
Esecuzioni di job Cloud Run
Quando esegui un job, Cloud Run crea un'esecuzione di job e avvia tutte le attività di job. Tutte le attività in un'esecuzione di job devono essere completate correttamente affinché l'esecuzione del job abbia esito positivo. Puoi impostare i timeout per le attività e specificare il numero di nuovi tentativi in caso di errore dell'attività.
Se un'attività supera il numero massimo di nuovi tentativi, Cloud Run la contrassegna come non riuscita e il job come non riuscito. Per impostazione predefinita, le attività vengono eseguite in parallelo fino a un massimo di 100, ma puoi specificare un massimo inferiore se una delle risorse di backup, ad esempio un database, lo richiede.
Attività di job Cloud Run
Ogni esecuzione di job esegue una serie di attività in parallelo, con ogni attività che esegue un'istanza. Cloud Run tenta automaticamente di eseguire di nuovo le attività non riuscite, a seconda della configurazione del job per maxRetries.
Pool di worker Cloud Run
I pool di worker sono una risorsa Cloud Run progettata specificamente per i carichi di lavoro non basati su richieste, come le code pull. Tieni presente che i pool di worker non hanno le seguenti funzionalità:
- Nessun endpoint/URL
- Nessun requisito per il container di cui è stato eseguito il deployment per rimanere in ascolto delle richieste su una porta
- Nessuna scalabilità automatica
Analogamente a un servizio Cloud Run, il deployment o l'aggiornamento di un pool di worker crea una nuova revisione.
Puoi scalare manualmente le istanze del pool di worker in base alle esigenze per gestire i carichi di lavoro. Tuttavia, se necessario, puoi creare la tua scalabilità automatica. Un esempio è la scalabilità automatica di Kafka, che gestisce la scalabilità per i carichi di lavoro in entrata dalla coda di messaggi Kafka.
Quando è connessa a una rete Virtual Private Cloud (VPC), ogni istanza del pool di worker riceve un indirizzo IP sulla rete VPC ed è in grado di inviare e ricevere traffico da e verso questo VPC.
Istanze Cloud Run
Un'istanza Cloud Run rappresenta un ambiente di runtime singleton autonomo. A differenza di un servizio, che scala automaticamente o manualmente le istanze container per gestire il traffico, un'istanza Cloud Run è una risorsa di primo livello con un proprio indirizzo URL diretto e operazioni del ciclo di vita.
Ogni istanza Cloud Run include le seguenti funzionalità:
- Endpoint URL dedicato: assegna un URL di ingresso stabile per impostazione predefinita. Puoi disattivare l'URL predefinito per consentire solo il traffico proveniente dagli altri percorsi di ingresso dell'istanza.
- Criteri di riavvio: supporta le condizioni di riavvio (
always,on-failure,never) per ripristinare automaticamente il processo del container in caso di arresti anomali. - Allocazione CPU condivisa: viene eseguita su un modello di CPU condivisa in cui la CPU viene allocata completamente in base a un budget di burst e limitata a un limite di risorse di base del 6,25% al di fuori di questo budget.