Che cos'è Cloud Run

Cloud Run è una piattaforma di applicazioni completamente gestita per eseguire codice, funzioni o container sull'infrastruttura ad alta scalabilità di Google.

Puoi eseguire il deployment di codice scritto in qualsiasi linguaggio di programmazione su Cloud Run se puoi creare un'immagine container. In realtà, la creazione di immagini container è facoltativa. Se usi Go, Node.js, Python, Java, .NET, Ruby o un framework supportato, puoi usare l' opzione di deployment basato sull'origine che crea il container per te, usando le best practice per il linguaggio che stai utilizzando.

Google ha creato Cloud Run per funzionare bene con altri servizi su Google Cloud, in modo che tu possa creare applicazioni complete.

In breve, Cloud Run consente agli sviluppatori di dedicare il proprio tempo alla scrittura del codice e di dedicare pochissimo tempo al funzionamento, alla configurazione e alla scalabilità del servizio Cloud Run. Non devi creare un cluster o gestire l'infrastruttura per essere produttivo con Cloud Run.

Servizi, job, pool di worker e istanze: quattro modi per eseguire il codice

Su Cloud Run, il codice può essere eseguito come un servizio, job, pool di worker o istanza. Tutti questi tipi di risorse eseguono istanze container in sandbox nello stesso ambiente di esecuzione e possono integrarsi con Google Cloud i servizi.

Decidi quale Cloud Run è più adatto al tuo workload.
Decidi quale risorsa Cloud Run è appropriata per il tuo workload.

La tabella seguente fornisce una panoramica generale delle opzioni fornite da ogni tipo di risorsa Cloud Run.

Risorsa Descrizione
Servizio Risponde alle richieste HTTP inviate a un endpoint univoco e stabile, utilizzando istanze container stateless che supportano sia la scalabilità automatica dinamica sia la scalabilità manuale, e risponde anche a eventi e funzioni.
Job Esegue attività parallelizzabili eseguite manualmente o in base a una pianificazione e completate.
Pool di worker Gestisce i workload in background sempre attivi, come i workload delle code di messaggi (Kafka, Pub/Sub, RabbitMQ).
Istanza Esegue workload di lunga durata che richiedono un ambiente di runtime singleton.

Servizi Cloud Run

Un servizio Cloud Run fornisce l'infrastruttura necessaria per eseguire un endpoint HTTPS affidabile. Per utilizzare questo servizio, devi assicurarti che il codice sia in ascolto su una porta TCP e gestisca le richieste HTTP in entrata.

Il seguente diagramma illustra come un servizio Cloud Run esegue più istanze container per elaborare le richieste web e gli eventi di un client:

Un servizio Cloud Run esegue i container per gestire le richieste web e
gli eventi

Un servizio standard include le seguenti funzionalità:

Endpoint HTTPS univoco per ogni servizio
Ogni servizio Cloud Run ha un endpoint HTTPS su un sottodominio univoco del dominio *.run.app e puoi configurare anche domini personalizzati. Cloud Run gestisce TLS per te e supporta WebSocket, HTTP/2 (end-to-end) e gRPC (end-to-end).
Scalabilità automatica rapida basata sulle richieste
Cloud Run esegue rapidamente lo scale out per gestire tutte le richieste in entrata o per gestire l'aumento dell'utilizzo della CPU al di fuori delle richieste se l'impostazione di fatturazione è impostata sulla fatturazione basata sulle istanze. Un servizio può eseguire rapidamente lo scale out fino a mille istanze o anche di più se richiedi un aumento della quota. Se la domanda diminuisce, Cloud Run rimuove i container inattivi. Se ti preoccupano i costi o il sovraccarico dei sistemi downstream, puoi limitare il numero massimo di istanze.
Scalabilità manuale facoltativa
Per impostazione predefinita, Cloud Run esegue automaticamente lo scale out a più istanze per gestire più traffico, ma puoi sostituire questo comportamento utilizzando la scalabilità manuale per controllare il comportamento di scalabilità.
Gestione del traffico integrata

Per ridurre il rischio di eseguire il deployment di una nuova revisione, Cloud Run supporta l'esecuzione di un rollout graduale, inclusi l'instradamento del traffico in entrata all'ultima revisione, il rollback a una revisione precedente e la suddivisione del traffico in più revisioni contemporaneamente.

Ad esempio, puoi iniziare inviando l'1% delle richieste a una nuova revisione e aumentare questa percentuale durante il monitoraggio della telemetria.

Servizi pubblici e privati

Un servizio Cloud Run può essere raggiungibile da internet oppure puoi limitare l'accesso nei seguenti modi:

Puoi erogare asset memorizzabili nella cache da una località edge più vicina ai client anteponendo un servizio Cloud Run con una rete CDN (Content Delivery Network), come Firebase Hosting e Cloud CDN.

Scalabilità fino a zero e istanze minime

Per impostazione predefinita, se la fatturazione è impostata sulla fatturazione basata sulle istanze, Cloud Run aggiunge e rimuove automaticamente le istanze per gestire tutte le richieste in entrata o per gestire l'aumento dell'utilizzo della CPU al di fuori delle richieste.

Scalabilità fino a zero

Se non ci sono richieste in entrata al tuo servizio, verrà rimossa anche l'ultima istanza rimanente. Questo comportamento è comunemente chiamato scalabilità fino a zero.

Quando arriva una nuova richiesta per un servizio senza istanze attive, Cloud Run crea una nuova istanza. Questo processo può aumentare il tempo di risposta per queste richieste iniziali, a seconda della velocità con cui il container diventa pronto a gestire il traffico.

Modificare il comportamento di scalabilità

Puoi modificare questo comportamento predefinito utilizzando uno dei seguenti metodi:

  • Istanze minime: configura Cloud Run in modo che mantenga attivo un numero minimo di istanze in modo che il servizio non venga scalato fino a zero.
  • Scalabilità manuale: utilizza la scalabilità manuale per mantenere un maggiore controllo sul comportamento di scalabilità del servizio.

Prezzi a consumo per i servizi

La scalabilità fino a zero è interessante per motivi economici, poiché ti vengono addebitati i costi per la CPU e la memoria allocate a un'istanza con una granularità di 100 ms. Se non configuri le istanze minime, non ti vengono addebitati costi se il servizio non viene utilizzato. È disponibile un livello senza costi generoso. Per ulteriori informazioni, consulta i prezzi.

Puoi abilitare due impostazioni di fatturazione:

Basata sulle richieste
Se un'istanza non elabora le richieste, non ti vengono addebitati costi. Paghi una tariffa per richiesta.
Basata sulle istanze
Ti vengono addebitati i costi per l'intera durata di un'istanza. Non è prevista una tariffa per richiesta.

È disponibile un livello senza costi generoso. Per ulteriori informazioni, consulta i prezzi e le impostazioni di fatturazione per scoprire come abilitare la fatturazione basata sulle richieste o sulle istanze per il tuo servizio.

Un file system container usa e getta

Le istanze su Cloud Run sono usa e getta. Ogni container ha una sovrapposizione del file system scrivibile in memoria, che non viene mantenuta se il container viene arrestato. Cloud Run determina quando interrompere l'invio di richieste a un' istanza e arrestarla, ad esempio durante lo scale in.

Per ricevere un avviso quando Cloud Run sta per arrestare un'istanza, l'applicazione può intercettare il segnale SIGTERM. In questo modo, il codice può fare il flush dei buffer locali e rendere persistenti i dati locali in un datastore esterno.

Per rendere persistenti i file in modo permanente, esegui l'integrazione con Cloud Storage o monta un file system di rete (NFS).

Quando utilizzare i servizi Cloud Run

I servizi Cloud Run sono ideali per il codice che gestisce richieste, eventi o funzioni. Esempi di casi d'uso:

Siti web e applicazioni web
Crea la tua app web utilizzando il tuo stack preferito, accedi al tuo database SQL ed esegui il rendering di pagine HTML dinamiche.
API e microservizi
Puoi creare un'API REST, un'API GraphQL o microservizi privati che comunicano tramite HTTP o gRPC.
Elaborazione dei flussi di dati
I servizi Cloud Run possono ricevere messaggi da sottoscrizioni push di Pub/Sub ed eventi da Eventarc.
Workload asincroni
Cloud Run Functions può rispondere a eventi asincroni, come un messaggio in un argomento Pub/Sub, una modifica in un bucket Cloud Storage o un evento Firebase.
Inferenza AI
I servizi Cloud Run, con o senza GPU configurata, possono ospitare workload AI come modelli di inferenza e addestramento di modelli.

Job Cloud Run

Se il codice esegue un'attività e poi si arresta, ad esempio utilizzando uno script, puoi utilizzare un job Cloud Run per eseguire il codice. Puoi eseguire un job da riga di comando utilizzando Google Cloud CLI, pianificando un job ricorrente, o eseguendolo come parte di un workflow.

I job di array sono un modo più rapido per eseguire i job

Un job può avviare una singola istanza per eseguire il codice: questo è un modo comune per eseguire uno script o uno strumento.

Tuttavia, puoi anche utilizzare un job di array, avviando in parallelo molte istanze identiche e indipendenti. I job di array sono un modo più rapido per elaborare i job che possono essere suddivisi in più attività indipendenti.

Il seguente diagramma mostra come un job con sette attività impiega più tempo per essere eseguito in sequenza rispetto allo stesso job quando quattro istanze possono elaborare attività indipendenti in parallelo:

I job array sono un modo più rapido per eseguire job parallelizzabili

Ad esempio, se stai ridimensionando e ritagliando 1000 immagini da Cloud Storage, l'elaborazione consecutiva è più lenta rispetto all'elaborazione in parallelo con molte istanze, con Cloud Run che gestisce la scalabilità automatica.

Quando utilizzare i job Cloud Run

I job Cloud Run sono adatti per l'esecuzione di codice che esegue un'attività (un job) e si arresta al termine dell'attività. Ecco alcuni esempi:

Script o strumento
Esegui uno script per eseguire migrazioni di database o altre attività operative.
Job di array
Esegui l'elaborazione altamente parallelizzata di tutti i file in un bucket Cloud Storage.
Job programmato
Crea e invia fatture a intervalli regolari oppure salva i risultati di una query di database come XML e carica il file ogni poche ore.
Workload AI
I job Cloud Run con o senza GPU configurata possono ospitare workload AI come l'inferenza batch, la messa a punto dei modelli e l'addestramento dei modelli.

Pool di worker Cloud Run

I pool di worker sono progettati per i workload che non si basano sulla gestione delle richieste HTTP. Forniscono un pool flessibile e scalabile di risorse di computing personalizzate per l'elaborazione in background continua, non HTTP e basata sul pull. Le seguenti caratteristiche chiave definiscono il funzionamento dei pool di worker:

  • I pool di worker non scalano automaticamente. Scala manualmente il numero di istanze richieste dal pool di worker Cloud Run per gestire il suo workload. Per avviare e rimanere attivo, il workload deve avere almeno un'istanza. Se imposti le istanze minime su 0, l'istanza worker non verrà avviata, anche se il deployment è andato a buon fine.

  • Per regolare dinamicamente le istanze in base alla domanda in tempo reale, crea il tuo gestore della scalabilità automatica. Per un esempio, vedi Scalare automaticamente i workload dei consumer Kafka.

  • I pool di worker gestiscono i rollout suddividendo le istanze tra le revisioni, anziché suddividendo il traffico. Ad esempio, per un pool di worker con quattro istanze, puoi allocare il 25% (un'istanza) a una nuova revisione e il 75% (tre istanze) a una revisione stabile.

  • I pool di worker supportano il traffico in uscita e in entrata VPC diretto e non hanno un endpoint o un URL con bilanciamento del carico. Per ulteriori informazioni sul supporto del server di metadati (MDS) e sul recupero degli indirizzi IP privati dell'istanza del pool di worker, consulta il contratto di runtime del container.

  • Cloud Run ti addebita solo la durata di esecuzione delle istanze del pool di worker.

Quando utilizzare i pool di worker Cloud Run

I pool di worker non richiedono endpoint HTTP pubblici. In questo modo la rete è più sicura e il codice dell'applicazione è semplificato. Inoltre, non devi gestire le porte per i controlli di integrità. I seguenti casi d'uso si applicano ai pool di worker:

  • Workload basati sul pull: esegui il deployment di un workload per eseguire il pull dei messaggi da una coda per la gestione. Ad esempio, Kafka Consumer, pull Pub/Sub e RabbitMQ.

    Il seguente diagramma mostra i casi d'uso per il deployment di pool di worker per workload basati sul pull:

    Carichi di lavoro basati sul pull dei pool di worker Cloud Run

    In un caso d'uso di Pub/Sub, un sottoscrittore Cloud Run con scalabilità automatica esegue il pull dei messaggi da una sottoscrizione Pub/Sub. In un caso d'uso di Kafka, un consumer Cloud Run con scalabilità automatica esegue il pull dei messaggi da un argomento Kafka.

  • Workload generici non basati su richieste: esegui un workload basato su container che non è destinato a gestire le richieste in entrata.

Istanze Cloud Run

Un'istanza Cloud Run è progettata per i workload che richiedono un runtime singleton stabile, continuo e indirizzabile individualmente, anziché la scalabilità orizzontale basata sulle richieste.

A differenza di un servizio, che può avere più istanze container e può essere configurato per la scalabilità automatica o manuale, un'istanza Cloud Run è una sola istanza.

Confronta un servizio Cloud Run e un'istanza Cloud Run
Confronta un servizio Cloud Run e un'istanza Cloud Run.

Un'istanza Cloud Run include le seguenti caratteristiche:

  • Gestibile individualmente: puoi creare, aggiornare ed eliminare ogni istanza singolarmente, avviare e arrestare l'istanza e monitorare le esecuzioni.
  • Indirizzabile individualmente: a ogni istanza viene assegnato un URL univoco.
  • Di lunga durata: l'istanza può essere eseguita ininterrottamente per ore o giorni o anche più a lungo se è configurata per il riavvio automatico dopo gli aggiornamenti periodici dell'infrastruttura (ogni 1-2 settimane).
  • Creazione rapida: il provisioning dell'istanza viene eseguito in circa 20 secondi o meno.

Quando utilizzare le istanze Cloud Run

Le istanze Cloud Run sono progettate per i workload di computing singleton persistenti progettati per l'esecuzione di workload agentici e workflow non AI. Esempi di casi d'uso:

Motori di workflow AI e agenti AI di lunga durata
Crea agenti in background di lunga durata che eseguono piani di esecuzione in più passaggi, esegui assistenti di codifica asincrona o gestisci workflow stateful che richiedono un ambiente a istanza singola.
Computing serverless di lunga durata
Esegui il deployment di server leggeri e sempre attivi, simili a un server privato virtuale (VPS) che viene eseguito continuamente. Questa opzione è ideale se vuoi workload che non richiedono la scalabilità automatica o la gestione del traffico su scala web e vuoi dare la priorità a costi inferiori e alla longevità singleton rispetto all'alta affidabilità.
Ambienti di sviluppo e loop di debug
Esegui il deployment di ambienti dedicati per eseguire il debug dei processi container in remoto, sincronizzare le modifiche del codice e risolvere i problemi relativi agli arresti anomali senza la terminazione automatica dei container.

Google Cloud Integrazioni

Cloud Run si integra con l'ecosistema più ampio di Google Cloud, che ti consente di creare applicazioni complete.

Le integrazioni essenziali includono:

Archiviazione dei dati
Cloud Run si integra con Cloud SQL (MySQL, PostgreSQL e SQL Server gestiti), Memorystore (Redis e Memcached gestiti), Firestore, Spanner, Cloud Storage e altro ancora. Per un elenco completo, consulta Archiviazione dei dati.
Logging e segnalazione degli errori
Cloud Logging acquisisce automaticamente i log dei container. Se nei log sono presenti eccezioni, Error Reporting le aggrega e ti invia una notifica. Sono supportati i seguenti linguaggi: Go, Java, Node.js, PHP, Python, Ruby e .NET.
Identità di servizio
Ogni revisione di Cloud Run è collegata a un service account, e le Google Cloud librerie client utilizzano in modo trasparente questo account di servizio per l'autenticazione con le Google Cloud API.
Distribuzione continua
Se memorizzi il codice sorgente in GitHub, puoi configurare Cloud Run in modo che esegua automaticamente il deployment dei nuovi commit.
Networking privato
Le istanze Cloud Run possono raggiungere le risorse nella rete Virtual Private Cloud (VPC) tramite il connettore di accesso VPC serverless. In questo modo il servizio può connettersi a macchine virtuali Compute Engine o a prodotti basati su Compute Engine come Google Kubernetes Engine o Memorystore.
Google Cloud API
Il codice del servizio esegue l'autenticazione in modo trasparente con le Google Cloud API. Sono incluse le API AI e Machine Learning, come l'API Cloud Vision, l'API Speech-to-Text, l'API Natural Language AutoML, l'API Cloud Translation e molte altre.
Attività in background
Puoi pianificare l'esecuzione del codice in un secondo momento o immediatamente dopo la restituzione di una richiesta web. Cloud Run funziona bene con Cloud Tasks per fornire un'esecuzione asincrona scalabile e affidabile.

Per un elenco dei molti Google Cloud servizi che funzionano bene con Cloud Run, consulta Connessione ai Google Cloud servizi.

Il codice è in esecuzione in un'immagine container

Sebbene non sia necessario avere familiarità con i container per eseguire il deployment del codice in Cloud Run, il codice viene sempre eseguito in istanze container in sandbox.

Se non hai familiarità con i container, ecco una breve introduzione concettuale.

Creazione di immagini container

Come mostrato nel diagramma, utilizzi il codice sorgente, gli asset e le dipendenze delle librerie per creare un'immagine container. Questa immagine è un pacchetto che contiene tutto ciò di cui il servizio ha bisogno per essere eseguito, inclusi artefatti di build, asset, pacchetti di sistema e, facoltativamente, un runtime. Le applicazioni containerizzate sono intrinsecamente portabili e vengono eseguite ovunque possa essere eseguito un container. Gli artefatti di build includono file binari compilati o file di script e i runtime includono il runtime JavaScript Node.js o una macchina virtuale Java.

Gli utenti esperti apprezzano il fatto che Cloud Run non impone oneri aggiuntivi sull'esecuzione del codice e che puoi eseguire qualsiasi programma binario su Cloud Run.

Se vuoi maggiore praticità o vuoi delegare la containerizzazione delle applicazioni a Google, Cloud Run si integra con i buildpack open source di Google Cloud per offrire un deployment basato sull'origine.

Passaggi successivi