Deployment delle immagini container
Cloud Run offre diverse opzioni di deployment. Tutte le opzioni di deployment generano un'immagine container che viene eseguita come servizio, job o pool di worker Cloud Run sull'infrastruttura completamente gestita e altamente scalabile di Cloud Run.
Immagini container di cui è possibile eseguire il deployment
Puoi eseguire il deployment di qualsiasi immagine container conforme al contratto di runtime del container di Cloud Run in un servizio, un job o un pool di worker Cloud Run.
Eseguire il deployment dal codice sorgente
Per comodità, Cloud Run ti consente di creare ed eseguire il deployment del codice sorgente con un unico comando. Per i dettagli, consulta Deployment di servizi dal codice sorgente e Deployment di pool di worker dal codice sorgente.
Quando esegui il deployment dal codice sorgente, Cloud Build trasforma il codice in un container
immagine archiviata in Artifact Registry. Puoi eseguire il deployment del codice sorgente che include un Dockerfile o che utilizza uno dei
runtime dei linguaggi supportati.
Funzioni
Puoi eseguire il deployment di funzioni monouso che rispondono agli eventi generati dall'infrastruttura 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.
Deployment continuo del codice sorgente da git
Cloud Run ti aiuta a configurare il deployment continuo da Git.
Come per i deployment del codice sorgente, puoi eseguire il deployment del codice sorgente che include un
Dockerfile o è scritto in uno dei runtime del linguaggio supportati.
Il deployment continuo da Git è disponibile per i servizi Cloud Run. Puoi configurarli manualmente in Cloud Build per i job Cloud Run.
Servizi Cloud Run
I servizi sono una delle risorse principali di Cloud Run. Ogni servizio si trova in una Google Cloud regione specifica. Per fornire ridondanza e failover, Cloud Run replica automaticamente i servizi in più zone all'interno di una regione. Un determinato Google Cloud progetto può eseguire molti servizi in diverse regioni.
Ogni servizio espone un endpoint unico. Per impostazione predefinita, Cloud Run scala automaticamente per gestire le richieste in entrata. Se necessario, puoi modificare il comportamento di scalabilità in scalabilità manuale. 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 progetto Google Cloud 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 copie della sua applicazione.
Il servizio C ha richieste ed è stato scalato per gestire il carico creando più istanze. Ogni istanza contiene più container e funziona come un set indipendente. In ogni set, solo il container di ingresso riceve la richiesta, ma gli altri container contribuiscono 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 contemporaneità 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 indirizza automaticamente le richieste il prima possibile all'ultima revisione del servizio in stato 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 della contemporaneità delle richieste, puoi impostare il numero massimo di richieste che possono essere inviate in parallelo a ciascuna istanza di una revisione.
Job Cloud Run
Ogni job si trova in una Google Cloud regione specifica ed è costituito da una o più attività del job che vengono eseguite per completare uno o più container. Le attività del job sono indipendenti e possono essere eseguite in parallelo in una determinata esecuzione del job.
Esecuzioni dei job Cloud Run
Quando un job viene eseguito, viene creata un'esecuzione del job in cui vengono avviate tutte le attività del job. Tutte le attività di un'esecuzione del job devono essere completate correttamente affinché l'esecuzione del job vada a buon fine. Puoi impostare timeout per l'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 tue risorse di backend, ad esempio un database, lo richiede.
Attività del job Cloud Run
Ogni esecuzione del job esegue un numero di attività in parallelo e ogni attività 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 carichi di lavoro non di richiesta, 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 ascoltare le 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.
Le istanze del pool di worker possono essere scalate manualmente in base alle esigenze per scalare un numero sufficiente di istanze per i workload. Tuttavia, puoi creare un gestore della scalabilità automatica personalizzato, se necessario. Un esempio è il gestore della scalabilità automatica di Kafka, che gestisce la scalabilità per i carichi di lavoro in arrivo dalla coda di messaggi Kafka.