Esegui il deployment delle immagini container nei servizi Cloud Run

Questa pagina descrive come eseguire il deployment di immagini container in un nuovo servizio Cloud Run o in una nuova revisione di un servizio Cloud Run esistente.

L'immagine container viene importata da Cloud Run al momento del deployment. Cloud Run conserva questa copia dell'immagine container finché viene utilizzata da una revisione di pubblicazione. Le immagini container non vengono estratte dal repository container quando viene avviata una nuova istanza Cloud Run.

Per un esempio dettagliato di deployment di un nuovo servizio, consulta Guida rapida per il deployment di un container di esempio.

Prima di iniziare

Se il tuo progetto è soggetto a un criterio dell'organizzazione con restrizioni di dominio che limitano le chiamate non autenticate, devi accedere al servizio di cui è stato eseguito il deployment come descritto in Test dei servizi privati.

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per distribuire i servizi Cloud Run, chiedi al tuo amministratore di concederti i seguenti ruoli IAM:

Per un elenco di ruoli e autorizzazioni IAM associati a Cloud Run, consulta Ruoli IAM di Cloud Run e Autorizzazioni IAM di Cloud Run. Se il tuo servizio Cloud Run interagisce con le APIGoogle Cloud , come le librerie client Cloud, consulta la guida alla configurazione dell'identità del servizio. Per saperne di più sulla concessione dei ruoli, consulta Autorizzazioni di deployment e Gestisci l'accesso.

Registri e immagini dei container supportati

Puoi utilizzare direttamente le immagini container archiviate in Artifact Registry o le immagini pubbliche di Docker Hub o GitHub Container Registry. Google consiglia l'utilizzo di Artifact Registry. Le immagini pubbliche di GitHub Container Registry e le immagini Docker Hub vengono memorizzate nella cache per un massimo di un'ora.

Puoi utilizzare immagini container da altri registri pubblici o privati (come JFrog Artifactory o Nexus) o immagini private da GitHub Container Registry configurando un repository remoto di Artifact Registry.

Devi prendere in considerazione solo Docker Hub per il deployment di immagini container popolari come le immagini ufficiali Docker o le immagini OSS sponsorizzate da Docker. Per una maggiore disponibilità, Google consiglia di eseguire il deployment di queste immagini di Docker Hub o GitHub Container Registry utilizzando un repository remoto di Artifact Registry.

Cloud Run non supporta layer di immagini container di dimensioni superiori a 9,9 GB quando si effettua il deployment da Docker Hub o da un repository remoto di Artifact Registry con un registro esterno.

Implementare un nuovo servizio

Puoi specificare un'immagine container con un tag (ad esempio us-docker.pkg.dev/my-project/container/my-image:latest) o con un digest esatto (ad esempio us-docker.pkg.dev/my-project/container/my-image@sha256:41f34ab970ee...).

Eseguendo il deployment in un servizio per la prima volta viene creata la prima revisione. Tieni presente che le revisioni sono immutabili. Se esegui il deployment dal tag di un'immagine container, verrà risolto in un digest e la revisione gestirà sempre questo particolare digest.

Console

Per eseguire il deployment di un'immagine container:

  1. Nella console Google Cloud , vai alla pagina Cloud Run:

    Vai a Cloud Run

  2. Fai clic su Esegui il deployment del container per visualizzare il modulo Crea servizio.

  3. Nel modulo, selezionare l'opzione di distribuzione.

    1. Se vuoi eseguire il deployment manuale di un container, seleziona Esegui il deployment di una revisione da un'immagine container esistente e specifica l'immagine container.

    2. Se vuoi automatizzare il deployment continuo, seleziona Esegui il deployment continuo di nuove revisioni da un repository di codice sorgente e segui le istruzioni per i deployment continui.

  4. Inserisci un nome del servizio. I nomi dei servizi devono contenere al massimo 49 caratteri e devono essere univoci per regione e progetto. Il nome del servizio non può essere modificato in seguito ed è visibile pubblicamente.

  5. NelRegione campo, selezionare ilregione dove desideri che venga erogato il servizio.

    Il selettore di regioni indica il livello di prezzo, la disponibilità dei mapping dei domini ed evidenzia le regioni con la minore impronta di carbonio.

  6. Nella sezione Autenticazione, configura quanto segue:

    • Se stai creando un'API o un sito web pubblici, seleziona Consenti accesso pubblico. Se selezioni questa opzione, viene assegnato il ruolo Invoker IAM all'identificatore speciale allUser. Puoi utilizzare IAM per modificare questa impostazione in un secondo momento dopo aver creato il servizio.
    • Se vuoi un servizio sicuro protetto dall'autenticazione, seleziona Richiedi autenticazione.

  7. Imposta la fatturazione in base alle esigenze.

  8. In Scalabilità del servizio, se utilizzi la scalabilità automatica predefinita di Cloud Run, specifica facoltativamente le istanze minime. Se utilizzi la scalabilità manuale, specifica il numero di istanze per il servizio.

  9. Imposta le impostazioni di Ingress nel modulo in base alle esigenze.

  10. Fai clic su Container, networking, sicurezza per impostare altre impostazioni facoltative nelle schede appropriate:

  11. Al termine della configurazione del servizio, fai clic su Crea per eseguire il deployment dell'immagine in Cloud Run e attendi il completamento del deployment.

  12. Fai clic sul link dell'URL visualizzato per aprire l'endpoint univoco e stabile del servizio di cui è stato eseguito il deployment.

gcloud

  1. Nella console Google Cloud , attiva Cloud Shell.

    Attiva Cloud Shell

    Nella parte inferiore della console Google Cloud viene avviata una sessione di Cloud Shell e viene visualizzato un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installata e con valori già impostati per il progetto corrente. L'inizializzazione della sessione può richiedere alcuni secondi.

  2. Per eseguire il deployment di un'immagine container:

    1. Esegui questo comando: 

      gcloud run deploy SERVICE --image IMAGE_URL

      Sostituisci quanto segue:

      • SERVICE: il nome del servizio di cui vuoi eseguire il deployment. I nomi dei servizi devono contenere al massimo 49 caratteri e devono essere univoci per regione e progetto. Se il servizio non esiste ancora, questo comando lo crea durante il deployment. È possibile omettere completamente questo parametro, ma in tal caso verrà richiesto di inserire il nome del servizio.
      • IMAGE_URL: un riferimento all'immagine container, ad esempio us-docker.pkg.dev/cloudrun/container/hello:latest. Se si utilizza Artifact Registry, il repository REPO_NAME deve essere già stato creato. L'URL segue il formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG . Tieni presente che se non fornisci il flag --image, il comando di deployment tenterà di eseguire il deployment dal codice sorgente.

      Se stai creando un'API pubblica o un sito web, consenti l'accesso pubblico al tuo servizio utilizzando il flag --allow-unauthenticated. Assegna il ruolo IAM Invoker di Cloud Run a allUsers. Puoi anche specificare --no-allow-unauthenticated per non consentire l'accesso pubblico. Se ometti uno di questi flag, ti viene chiesto di confermare l'esecuzione del comando deploy.

    2. Attendi il completamento dell'implementazione. Al termine dell'operazione, viene visualizzato un messaggio di operazione riuscita insieme all'URL del servizio di cui è stato eseguito il deployment.

    Tieni presente che per eseguire il deployment in una posizione diversa da quella impostata utilizzando le proprietà run/region gcloud, utilizza:

    gcloud run deploy SERVICE --region REGION

YAML

È possibile memorizzare le specifiche del servizio in un file YAML e quindi distribuirlo utilizzando la gcloud CLI.

  1. Crea un nuovo file service.yaml con il seguente contenuto:

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    spec:
      containers:
      - image: IMAGE

    Sostituisci quanto segue:

    • SERVICE: il nome del tuo servizio Cloud Run. I nomi dei servizi devono contenere al massimo 49 caratteri e devono essere univoci per regione e progetto.
    • IMAGE: l'URL dell'immagine container.

    Puoi anche specificare più configurazioni, ad esempio variabili di ambiente o limiti di memoria.

  2. Esegui il deployment del nuovo servizio utilizzando il seguente comando:

    gcloud run services replace service.yaml

    Il comando gcloud run services replace utilizza per impostazione predefinita il file service.yaml, se presente.

  3. (Facoltativo) Rendi pubblico il servizio se vuoi consentire l'accesso non autenticato al servizio.

Terraform

Per scoprire come applicare o rimuovere una configurazione Terraform, consulta Comandi Terraform di base.

Aggiungi quanto segue a una risorsa google_cloud_run_v2_service nella configurazione Terraform:
  provider "google" {
    project = "PROJECT-ID"
  }

  resource "google_cloud_run_v2_service" "default" {
    name     = "SERVICE"
    location = "REGION"
    client   = "terraform"

    template {
      containers {
        image = "IMAGE_URL"
      }
    }
  }

  resource "google_cloud_run_v2_service_iam_member" "noauth" {
    location = google_cloud_run_v2_service.default.location
    name     = google_cloud_run_v2_service.default.name
    role     = "roles/run.invoker"
    member   = "allUsers"
  }

Sostituisci quanto segue:

  • PROJECT-ID: l' Google Cloud ID progetto
  • REGION: la Google Cloud regione
  • SERVICE: il nome del tuo servizio Cloud Run. I nomi dei servizi devono contenere al massimo 49 caratteri e devono essere univoci per regione e progetto.
  • IMAGE_URL: un riferimento all'immagine container, ad esempio us-docker.pkg.dev/cloudrun/container/hello:latest. Se si utilizza Artifact Registry, il repository REPO_NAME deve essere già stato creato. L'URL segue il formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG

Questa configurazione consente l'accesso pubblico (l'equivalente di --allow-unauthenticated). Per rendere privato il servizio, rimuovi la sezione google_cloud_run_v2_service_iam_member.

Scrivi

Puoi memorizzare il tuoRedigere le specifiche in unYAML file e quindi distribuirlo come servizio Cloud Run utilizzando unsingolo comando gcloud.

Per eseguire il deployment di un file compose.yaml come servizio Cloud Run, segui questi passaggi:

  1. Nella directory del tuo progetto, crea un file compose.yaml con le definizioni del tuo servizio.

    services:
  web:
    image: IMAGE
    ports:
      - "8080:8080"

    Sostituisci IMAGE_URL con l'URL della tua immagine contenitore.

    Puoi anche specificare altre opzioni di configurazione, come variabili di ambiente, secret e montaggi volumi.

Distribuisci il servizio

  1. Per eseguire il deployment dei servizi, esegui il comando gcloud run compose up:

    gcloud run compose up compose.yaml

  2. Rispondi y a qualsiasi richiesta di installare i componenti necessari o di abilitare le API.

  3. (Facoltativo) Rendi pubblico il servizio se vuoi consentire l'accesso non autenticato al servizio.

Dopo il deployment, viene visualizzato l'URL del servizio Cloud Run. Copia questo URL e incollalo nel tuo browser per visualizzare il container in esecuzione. Puoi disattivare l'autenticazione predefinita dalla console Google Cloud .

MCP

Puoi utilizzare un agente AI per eseguire il deployment del servizio utilizzando il server MCP Cloud Run ufficiale.

Per ottenere risultati ottimali, prima di iniziare a utilizzare questo server MCP, comunica al tuo agente di preferire gli strumenti MCP alla gcloud CLI.

  1. Per configurare il server MCP remoto Cloud Run, segui le istruzioni nella guida Utilizzare il server MCP remoto Cloud Run.

  2. Per fare il deployment del servizio da un'immagine container di esempio helloworld, istruisci il tuo agente con il seguente prompt:Deploy service "helloworld" to Cloud Run from the container image us-docker.pkg.dev/cloudrun/container/hello.

    L'agente utilizza lo strumento deploy_service_from_image per eseguire il deployment di un'immagine container come servizio Cloud Run.

Utilizzare il prompt /deploy

Puoi utilizzare il prompt /deploy per eseguire rapidamente il deployment di un servizio utilizzando il server MCP Cloud Run. Potrebbe essere necessario navigare nel menu del chatbot per trovare lo strumento o il comando desiderato.

Per eseguire il deployment della directory di lavoro attuale in Cloud Run, esegui il prompt /deploy seguente:

/deploy SERVICE_NAME \
    --project PROJECT_ID \
    --region REGION \

Sostituisci quanto segue:

  • SERVICE_NAME: il nome del servizio Cloud Run
  • PROJECT_ID: l' Google Cloud ID progetto
  • REGION: il nome della regione

Librerie client

Per eseguire il deployment di un nuovo servizio dal codice:

API REST

Per fare il deployment di un nuovo servizio, inviare unaPOST richiesta HTTP all'API Cloud Run Adminservice endpoint API.

Ad esempio, utilizzando curl:

curl -H "Content-Type: application/json" \
  -H "Authorization: Bearer ACCESS_TOKEN" \
  -X POST \
  -d '{template: {containers: [{image: "IMAGE_URL"}]}}' \
  https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services?serviceId=SERVICE

Sostituisci quanto segue:

  • ACCESS_TOKEN: un token di accesso valido per un account che dispone delle autorizzazioni IAM per distribuire servizi. Ad esempio, se hai eseguito l'accesso a gcloud, puoi recuperare un token di accesso utilizzando gcloud auth print-access-token. Da un'istanza container Cloud Run, puoi recuperare un token di accesso utilizzando il server dei metadati dell'istanza container.
  • IMAGE_URL: un riferimento all'immagine container, ad esempio us-docker.pkg.dev/cloudrun/container/hello:latest. Se si utilizza Artifact Registry, il repository REPO_NAME deve essere già stato creato. L'URL segue il formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG .
  • SERVICE: il nome del servizio di cui vuoi eseguire il deployment. I nomi dei servizi devono essere composti da un massimo di 49 caratteri e devono essere univoci per regione e per progetto.
  • REGION: la Google Cloud regione del servizio.
  • PROJECT-ID: l'ID progetto Google Cloud .

Località Cloud Run

Cloud Run è regionale, il che significa che l'infrastruttura che esegue i tuoi servizi Cloud Run si trova in una regione specifica ed è gestita da Google per essere disponibile in modo ridondante in tutte le zone all'interno di quella regione.

Il rispetto dei requisiti di latenza, disponibilità e durabilità sono fattori primari nella scelta della regione in cui vengono eseguiti i servizi Cloud Run. In genere puoi selezionare la regione più vicina ai tuoi utenti, ma devi considerare la posizione degli altri Google Cloudprodotti utilizzati dal tuo servizio Cloud Run. L'utilizzo combinato dei prodotti Google Cloud in più località può influire sulla latenza e sui costi del servizio.

Cloud Run è disponibile nelle seguenti regioni:

Soggetto ai prezzi di Livello 1

  • asia-east1 (Taiwan)
  • asia-northeast1 (Tokyo)
  • asia-northeast2 (Osaka)
  • asia-south1 (Mumbai, India)
  • asia-southeast3 (Bangkok)
  • europe-north1 (Finlandia)icona foglia Bassa CO2
  • europe-north2 (Stoccolma) icona foglia Bassi livelli di CO2
  • europe-southwest1 (Madrid)icona foglia Bassa CO2
  • europe-west1 (Belgio)icona foglia Bassa CO2
  • europe-west4 (Paesi Bassi)icona foglia Bassa CO2
  • europe-west8 (Milano) icona foglia Bassi livelli di CO2
  • europe-west9 (Parigi)icona foglia Bassa CO2
  • me-west1 (Tel Aviv)
  • northamerica-south1 (Messico)
  • us-central1 (Iowa)icona foglia Bassa CO2
  • us-east1 (Carolina del Sud)
  • us-east4 (Virginia del Nord)
  • us-east5 (Columbus)
  • us-south1 (Dallas)icona foglia Bassa CO2
  • us-west1 (Oregon)icona foglia Bassa CO2

Soggetto ai prezzi di Livello 2

  • africa-south1 (Johannesburg)
  • asia-east2 (Hong Kong)
  • asia-northeast3 (Seul, Corea del Sud)
  • asia-southeast1 (Singapore)
  • asia-southeast2 (Giacarta)
  • asia-south2 (Delhi, India)
  • australia-southeast1 (Sydney)
  • australia-southeast2 (Melbourne)
  • europe-central2 (Varsavia, Polonia)icona foglia Bassa CO2
  • europe-west10 (Berlino)
  • europe-west12 (Turin)icona foglia Bassa CO2
  • europe-west2 (Londra, Regno Unito) icona foglia Bassi livelli di CO2
  • europe-west3 (Francoforte, Germania)
  • europe-west6 (Zurigo, Svizzera) icona foglia Bassi livelli di CO2
  • me-central1 (Doha)
  • me-central2 (Dammam)
  • northamerica-northeast1 (Montreal)icona foglia Bassa CO2
  • northamerica-northeast2 (Toronto)icona foglia Bassa CO2
  • southamerica-east1 (San Paolo, Brasile)icona foglia Bassa CO2
  • southamerica-west1 (Santiago, Cile)icona foglia Bassa CO2
  • us-west2 (Los Angeles)icona foglia Bassa CO2
  • us-west3 (Salt Lake City)
  • us-west4 (Las Vegas)

Se hai già creato un servizio Cloud Run, puoi visualizzare la regione nella dashboard di Cloud Run nella consoleGoogle Cloud .

Esegui il deployment di una nuova revisione di un servizio esistente

Puoi eseguire il deployment di una nuova revisione utilizzando la console Google Cloud , la riga di comandogcloud o un file di configurazione YAML.

Tieni presente che la modifica di qualsiasi impostazione di configurazione comporta la creazione di una nuova revisione, anche se non viene apportata alcuna modifica all'immagine container. Ogni revisione creata è immutabile.

L'immagine container viene importata da Cloud Run al momento del deployment. Cloud Run conserva questa copia dell'immagine container finché viene utilizzata da una revisione di erogazione.

Console

Per implementare una nuova revisione di un servizio esistente:

  1. Nella console Google Cloud , vai alla pagina Servizi di Cloud Run:

    Vai a Cloud Run

  2. Nell'elenco dei servizi, fai clic sul servizio che desideri aggiornare.

  3. Nella scheda Contenitori è possibile configurare quanto segue:

    1. Limiti di memoria e limiti di CPU
    2. Dischi effimeri
    3. GPU
    4. Controlli sanitari
    5. Variabili d'ambiente e segreti
    6. Volumi
    7. Connessioni Cloud SQL
    8. Ambiente di esecuzione

  4. Nella scheda Networking, puoi configurare quanto segue:

    1. Ingresso e disattivazione dell'URL predefinito
    2. Cloud Service Mesh
    3. Connessione VPC
    4. HTTP/2 e affinità sessione

  5. Nella scheda Sicurezza è possibile configurare quanto segue:

    1. Autenticazione preferenze
    2. Service account
    3. Autorizzazione binaria
    4. Chiavi KMS del cliente
    5. Cloud Run Threat Detection

  6. Nella scheda Scalabilità, puoi configurare quanto segue:

    1. Scalabilità automatica o scalabilità manuale
    2. Preferenze di fatturazione
    3. Timeout richieste e concorrenza

  7. Fai clic su Visualizza differenze e fai di nuovo il deployment, poi su Esegui il deployment delle modifiche per eseguire il deployment delle modifiche.

gcloud

  1. Nella console Google Cloud , attiva Cloud Shell.

    Attiva Cloud Shell

    Nella parte inferiore della console Google Cloud viene avviata una sessione di Cloud Shell e viene visualizzato un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installata e con valori già impostati per il progetto corrente. L'inizializzazione della sessione può richiedere alcuni secondi.

  2. Per eseguire il deployment di un'immagine container:

    1. Esegui il comando: 

      gcloud run deploy SERVICE --image IMAGE_URL

      Sostituisci quanto segue:

      • SERVICE: il nome del servizio di cui esegui il deployment. Puoi omettere completamente questo parametro, ma ti verrà chiesto il nome del servizio se lo ometti.
      • IMAGE_URL: un riferimento all'immagine container, ad esempio us-docker.pkg.dev/cloudrun/container/hello:latest. Se si utilizza Artifact Registry, il repository REPO_NAME deve essere già stato creato. L'URL segue il formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG .

      Il suffisso di revisione viene assegnato automaticamente per le nuove revisioni. Se vuoi fornire il tuo suffisso di revisione, utilizza il parametro --revision-suffix di gcloud CLI.

    2. Attendi il completamento dell'implementazione. Al termine dell'operazione, viene visualizzato un messaggio di operazione riuscita insieme all'URL del servizio di cui è stato eseguito il deployment.

YAML

Se devi scaricare o visualizzare la configurazione di un servizio esistente, utilizza il seguente comando per salvare i risultati in un file YAML:

gcloud run services describe SERVICE --format export > service.yaml

Da un file YAML di configurazione del servizio, modifica gli attributi secondari spec.template in base alle esigenze per aggiornare le impostazioni di revisione, quindi esegui il deployment della nuova revisione:

gcloud run services replace service.yaml

Il comando gcloud run services replace utilizza per impostazione predefinita il file service.yaml, se presente.

Terraform

Assicurati di aver configurato Terraform come descritto nell'esempio Deployment di un nuovo servizio.

  1. Apporta una modifica al file di configurazione.

  2. Applica la configurazione Terraform:

    terraform apply

    Conferma di voler applicare le azioni descritte inserendo yes.

Cloud Code

Per distribuire una nuova revisione di un servizio esistente con Cloud Code, consulta le guide IntelliJ e Visual Studio Code.

Scrivi

Puoi archiviare la specifica di composizione in un file YAML e poi eseguirne il deployment come revisione del servizio Cloud Run utilizzando un unico comando gcloud.

Per eseguire il deployment di un file compose.yaml come revisione del servizio Cloud Run, segui questi passaggi:

  1. Nella directory del tuo progetto, crea un file compose.yaml con le definizioni del tuo servizio.

    services:
  web:
    image: IMAGE
    ports:
      - "8080:8080"

    Sostituisci IMAGE_URL con l'URL della tua immagine contenitore.

    Puoi anche specificare altre opzioni di configurazione, come variabili di ambiente, secret e montaggi volumi.

Distribuisci il servizio

  1. Per eseguire il deployment dei servizi, esegui il comando gcloud run compose up:

    gcloud run compose up compose.yaml

  2. Rispondi y a eventuali richieste di installazione dei componenti richiesti o di attivazione delle API.

  3. (Facoltativo) Rendi pubblico il servizio se vuoi consentire l'accesso non autenticato al servizio.

Dopo il deployment, viene visualizzato l'URL del servizio Cloud Run. Copia questo URL e incollalo nel tuo browser per visualizzare il container in esecuzione. È possibile disabilitare l'autenticazione predefinita dalla console Google Cloud .

Librerie client

Per eseguire il deployment di una nuova revisione dal codice:

API REST

Per eseguire il deployment di una nuova revisione, invia una richiesta HTTP PATCH all'endpoint service dell'API Cloud Run Admin.

Ad esempio, utilizzando curl:

curl -H "Content-Type: application/json" \
  -H "Authorization: Bearer ACCESS_TOKEN" \
  -X PATCH \
  -d '{template: {containers: [{image: "IMAGE_URL"}]}}' \
  https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services/SERVICE

Sostituisci quanto segue:

  • ACCESS_TOKEN: un token di accesso valido per un account che dispone delle autorizzazioni IAM per distribuire le revisioni. Ad esempio, se hai eseguito l'accesso a gcloud, puoi recuperare un token di accesso utilizzando gcloud auth print-access-token. Da un'istanza container Cloud Run, puoi recuperare un token di accesso utilizzando il server dei metadati dell'istanza container.
  • IMAGE_URL: un riferimento all'immagine container, ad esempio us-docker.pkg.dev/cloudrun/container/hello:latest. Se si utilizza Artifact Registry, il repository REPO_NAME deve essere già stato creato. L'URL segue il formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG .
  • SERVICE: il nome del servizio di cui esegui il deployment.
  • REGION: la Google Cloud regione del servizio.
  • PROJECT-ID: l'ID progetto Google Cloud .

Località Cloud Run

Cloud Run è regionale, il che significa che l'infrastruttura che esegue i tuoi servizi Cloud Run si trova in una regione specifica ed è gestita da Google per essere disponibile in modo ridondante in tutte le zone all'interno di quella regione.

Il rispetto dei requisiti di latenza, disponibilità o durabilità è un fattore primario per la selezione della regione in cui vengono eseguiti i servizi Cloud Run. In genere puoi selezionare la regione più vicina ai tuoi utenti, ma devi considerare la posizione degli altri Google Cloudprodotti utilizzati dal tuo servizio Cloud Run. L'utilizzo combinato dei prodotti Google Cloud in più località può influire sulla latenza e sui costi del servizio.

Cloud Run è disponibile nelle seguenti regioni:

Soggetto ai prezzi di Livello 1

Soggetto ai prezzi di Livello 2

  • africa-south1 (Johannesburg)
  • asia-east2 (Hong Kong)
  • asia-northeast3 (Seul, Corea del Sud)
  • asia-southeast1 (Singapore)
  • asia-southeast2 (Giacarta)
  • asia-south2 (Delhi, India)
  • australia-southeast1 (Sydney)
  • australia-southeast2 (Melbourne)
  • europe-central2 (Varsavia, Polonia)icona foglia Bassa CO2
  • europe-west10 (Berlino)
  • europe-west12 (Turin)icona foglia Bassa CO2
  • europe-west2 (Londra, Regno Unito)icona foglia Bassa CO2
  • europe-west3 (Francoforte, Germania)
  • europe-west6 (Zurigo, Svizzera)icona foglia Bassa CO2
  • me-central1 (Doha)
  • me-central2 (Dammam)
  • northamerica-northeast1 (Montreal)icona foglia Bassa CO2
  • northamerica-northeast2 (Toronto)icona foglia Bassa CO2
  • southamerica-east1 (San Paolo, Brasile)icona foglia Bassa CO2
  • southamerica-west1 (Santiago, Cile)icona foglia Bassa CO2
  • us-west2 (Los Angeles)icona foglia Bassa CO2
  • us-west3 (Salt Lake City)
  • us-west4 (Las Vegas)

Se hai già creato un servizio Cloud Run, puoi visualizzare la regione nella dashboard di Cloud Run nella consoleGoogle Cloud .

Convalida la configurazione con dry run

È possibile convalidare la configurazione del servizio senza distribuirlo o rendere persistenti le modifiche utilizzando il flag --dry-run.

Quando specifichi il flag --dry-run, il comando esegue le seguenti azioni:

  • Convalida la configurazione.
  • Ignora il processo di compilazione se esegui il deployment dall'origine.
  • Non imposta i criteri di Identity and Access Management.
  • Stampa un messaggio di operazione riuscita della convalida.

Per convalidare il deployment di un'immagine container:

gcloud beta run deploy SERVICE \
    --image IMAGE_URL \
    --dry-run

Sostituisci quanto segue:

  • SERVICE: il nome del servizio di cui esegui il deployment.
  • IMAGE_URL: un riferimento all'immagine container, ad esempio us-docker.pkg.dev/cloudrun/container/hello:latest. Se si utilizza Artifact Registry, il repository REPO_NAME deve essere già stato creato. L'URL segue il formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG .

Esegui il deployment delle immagini di altri Google Cloud progetti

Per eseguire il deployment di immagini da altri progetti Google Cloud , tu o il tuo amministratore dovete concedere all'account di deployment e al service agent Cloud Run i ruoli IAM richiesti.

Per i ruoli richiesti per l'account deployer, consulta Ruoli richiesti.

Per concedere all'agente di servizio Cloud Run i ruoli richiesti, consulta le seguenti istruzioni:

  1. Nella console Google Cloud , apri il progetto per il tuo servizio Cloud Run.

    Vai alla pagina IAM

  2. Seleziona Includi concessioni di ruoli fornite da Google.

  3. Copia l'email dell'agente di servizio Cloud Run. Ha il suffisso @serverless-robot-prod.iam.gserviceaccount.com

  4. Apri il progetto che possiede il registro dei container che desideri utilizzare.

    Vai alla pagina IAM

  5. Fai clic su Aggiungi per aggiungere un nuovo preside.

  6. Nel campo Nuovi responsabili, incolla l'indirizzo email dell'account di servizio che hai copiato in precedenza.

  7. Nel menu Seleziona un ruolo, fai clic su Artifact Registry -> Artifact Registry Reader.

  8. Esegui il deployment dell'immagine container nel progetto che contiene il tuo servizio Cloud Run.

Deployment di immagini da altri registri

Per eseguire il deployment di immagini container pubbliche o private non archiviate in Artifact Registry o Docker Hub o che non sono immagini pubbliche in GitHub Container Registry, configura un repository remoto di Artifact Registry.

I repository remoti di Artifact Registry ti consentono di:

  • Esegui il deployment di qualsiasi immagine container pubblica.
  • Esegui il deployment di immagini container da repository privati che richiedono l'autenticazione, ad esempio JFrog Artifactory o Nexus.

In alternativa, se l'utilizzo di un repository remoto Artifact Registry non è un'opzione, puoi eseguire temporaneamente il pull e il push delle immagini container in Artifact Registry utilizzando docker push per eseguirne il deployment in Cloud Run. L'immagine container viene importata da Cloud Run durante il deployment, quindi dopo il deployment puoi eliminarla da Artifact Registry.

Distribuisci più container su un servizio (sidecar)

In un deployment Cloud Run con sidecar, è presente un container ingress che gestisce tutte le richieste HTTPS in entrata sulla porta del container specificata e uno o più container sidecar. I sidecar non possono ascoltare le richieste HTTP in entrata sulla porta del container di Ingress, ma possono comunicare tra loro e con il container di Ingress utilizzando una porta localhost. La porta localhost utilizzata varia a seconda dei container in uso.

Nel seguente diagramma, il container Ingress comunica con il sidecar utilizzando localhost:5000.

Cloud Run multi-container

Puoi eseguire il deployment di un massimo di 10 container per istanza, incluso il container Ingress. Tutti i container all'interno di un'istanza condividono lo stesso spazio dei nomi di rete e possono anche condividere file utilizzando un volume condiviso in memoria, come mostrato nel diagramma.

Puoi eseguire il deployment di più container nell'ambiente di esecuzione di prima o seconda generazione.

Se usifatturazione su richiesta (impostazione predefinita di Cloud Run), ai sidecar viene allocata la CPU solo nei seguenti scenari:

  • L'istanza sta elaborando almeno una richiesta.
  • Il container di ingresso si sta avviando.

Se il tuo sidecar deve utilizzare la CPU al di fuori dell'elaborazione delle richieste (ad esempio per la raccolta delle metriche), configura l'impostazione di fatturazione in modo che sia basata sulle istanze per il tuo servizio. Per ulteriori informazioni, consultare Impostazioni di fatturazione (servizi).

Se utilizzi la fatturazione basata sulle richieste, configura un probe di avvio per assicurarti che il sidecar non venga limitato dalla CPU all'avvio.

Puoi richiedere che tutti i deployment utilizzino un sidecar specifico creando policy dell'organizzazione personalizzate.

Casi d'uso

I casi d'uso per i sidecar in un servizio Cloud Run includono:

  • Monitoraggio, registrazione e tracciamento delle applicazioni
  • Utilizzo di Nginx, Envoy o Apache2 come proxy davanti al container dell'applicazione
  • Aggiunta di filtri di autenticazione e autorizzazione (ad esempio, Open Policy Agent)
  • Esecuzione di proxy di connessione in uscita come il proxy di autenticazione AlloyDB

Esegui il deployment di un servizio con container sidecar

Puoi eseguire il deployment di più sidecar in un servizio Cloud Run utilizzando la consoleGoogle Cloud , Google Cloud CLI, YAML o Terraform.

Console

Per implementare un nuovo servizio con sidecar:

  1. Nella Google Cloud console, vai alla pagina Servizi Cloud Run :

    Vai a Cloud Run

  2. Fai clic su Esegui il deployment del container per visualizzare il modulo Crea servizio.

  3. Fornisci il nome del servizio e l'URL dell'immagine container di ingresso di cui vuoi eseguire il deployment.

  4. Fai clic su Container, networking, sicurezza.

  5. Nella scheda Modifica contenitore, configura il contenitore di ingresso in base alle esigenze.

  6. Fai clic su Aggiungi container e configura un container sidecar che desideri aggiungere insieme al container ingress. Se il sidecar dipende da un altro container nel servizio, indicarlo nel menu Ordine di avvio del container. Ripeti questo passaggio per ogni container sidecar che stai distribuendo.

  7. Fai clic su Crea.

Per configurare un servizio esistente con i sidecar:

  1. Nella console Google Cloud , vai alla pagina Servizi di Cloud Run:

    Vai a Cloud Run

  2. Per eseguire il deployment in un servizio esistente, fai clic sul servizio.

  3. Fai clic sulla scheda Contenitori.

  4. Fai clic su Aggiungi container e configura un container sidecar che desideri aggiungere insieme al container ingress. Se il sidecar dipende da un altro container nel servizio, indicarlo nel menu Ordine di avvio del container. Ripeti questo passaggio per ogni container sidecar che stai distribuendo.

  5. Fai clic su Visualizza differenze e ridistribuisci.

  6. Per inviare tutto il traffico alla nuova revisione, seleziona Pubblica questa revisione immediatamente. Per un lancio graduale, deseleziona la casella di controllo. Il risultato è un deployment in cui non viene inviato traffico alla nuova revisione. Segui le istruzioni per le implementazioni graduali dopo l'implementazione.

  7. Fare clic su Applica modifiche.

gcloud

  1. Nella console Google Cloud , attiva Cloud Shell.

    Attiva Cloud Shell

    Nella parte inferiore della console Google Cloud viene avviata una sessione di Cloud Shell e viene visualizzato un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installata e con valori già impostati per il progetto corrente. L'inizializzazione della sessione può richiedere alcuni secondi.

  2. Per distribuire più container a un servizio, eseguire il seguente comando:

    gcloud run deploy SERVICE \
 --container INGRESS_CONTAINER_NAME \
 --image='INGRESS_IMAGE' \
 --port='CONTAINER_PORT' \
 --container SIDECAR_CONTAINER_NAME \
 --image='SIDECAR_IMAGE'

    Sostituisci quanto segue:

    • SERVICE: il nome del servizio di cui esegui il deployment. Puoi omettere completamente questo parametro, ma ti verrà chiesto il nome del servizio se lo ometti.
    • INGRESS_CONTAINER_NAME: un nome per il contenitore che riceve le richieste, ad esempio app.
    • INGRESS_IMAGE: un riferimento all'immagine container che deve ricevere le richieste, ad esempio us-docker.pkg.dev/cloudrun/container/hello:latest.
    • CONTAINER_PORT: la porta su cui il container di ingresso è in ascolto per le richieste in entrata. A differenza di un servizio a singolo container, per un servizio contenente sidecar non esiste una porta predefinita per il container di ingresso. È necessario configurare esplicitamente la porta del container per il container di ingresso e solo un container può avere quella porta esposta.
    • SIDECAR_CONTAINER_NAME: un nome per il container sidecar, ad esempio sidecar.
    • SIDECAR_IMAGE: un riferimento all'immagine container sidecar

    Se vuoi configurare ogni container nel comando di deployment, fornisci la configurazione di ogni container dopo i parametri container, ad esempio:

    gcloud run deploy SERVICE \
  --container CONTAINER_1_NAME \
  --image='INGRESS_IMAGE' \
  --set-env-vars=KEY=VALUE \
  --port='CONTAINER_PORT' \
  --container SIDECAR_CONTAINER_NAME \
  --image='SIDECAR_IMAGE' \
  --set-env-vars=KEY_N=VALUE_N

  3. Attendi il completamento dell'implementazione. Al termine dell'operazione, viene visualizzato un messaggio di operazione riuscita insieme all'URL del servizio di cui è stato eseguito il deployment.

YAML

Queste istruzioni mostrano un file YAML di base per il servizio Cloud Run con i sidecar. Crea un file denominato service.yaml e aggiungi quanto segue:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  annotations:
  name: SERVICE
spec:
  template:
    spec:
      containers:
      - image: INGRESS_IMAGE
        ports:
          - containerPort: CONTAINER_PORT
      - image: SIDECAR_IMAGE

Sostituisci quanto segue:

  • SERVICE: il nome del tuo servizio Cloud Run. I nomi dei servizi devono avere una lunghezza massima di 49 caratteri.
  • CONTAINER_PORT: la porta su cui il container di ingresso è in ascolto per le richieste in entrata. A differenza di un servizio a singolo container, per un servizio contenente sidecar non esiste una porta predefinita per il container di ingresso. È necessario configurare esplicitamente la porta del container per il container di ingresso e solo un container può avere quella porta esposta.
  • INGRESS_IMAGE: un riferimento all'immagine container che deve ricevere le richieste, ad esempio us-docker.pkg.dev/cloudrun/container/hello:latest.
  • SIDECAR_IMAGE: un riferimento all'immagine container sidecar. È possibile specificare più sidecar aggiungendo altri elementi all'array containers nel file YAML.

Dopo aver aggiornato il file YAML in modo da includere i container Ingress e sidecar, esegui il deployment su Cloud Run utilizzando il comando:

gcloud run services replace service.yaml

Il comando gcloud run services replace utilizza per impostazione predefinita il file service.yaml, se presente.

Terraform

Per scoprire come applicare o rimuovere una configurazione Terraform, consulta Comandi Terraform di base.

Aggiungi quanto segue a ungoogle_cloud_run_v2_service risorsa nella tua configurazione Terraform:
resource "google_cloud_run_v2_service" "default" {
  name     = "SERVICE"
  location = "REGION"
  ingress = "INGRESS_TRAFFIC_ALL"
  template {
    containers {
      name = "INGRESS_CONTAINER_NAME"
      ports {
        container_port = CONTAINER_PORT
      }
      image = "INGRESS_IMAGE"
      depends_on = ["SIDECAR_CONTAINER_NAME"]
    }
    containers {
      name = "SIDECAR_CONTAINER_NAME"
      image = "SIDECAR_IMAGE"
      }
    }
  }

CONTAINER_PORT rappresenta la porta su cui il container di ingresso è in ascolto per le richieste in entrata. A differenza di un servizio a contenitore singolo, per un servizio contenente sidecar non esiste una porta predefinita per il contenitore di ingresso. È necessario configurare esplicitamente la porta del container per il container di ingresso e solo un container può avere quella porta esposta.

Funzionalità importanti disponibili per i deployment con i sidecar

Ordine di avvio

Puoi specificare l'ordine di avvio del container all'interno di un deployment con più container, se hai dipendenze che richiedono l'avvio di alcuni container prima di altri nel deployment.

Se hai container che dipendono da altri container, devi usare healthchecks nella tua distribuzione. Se si utilizzano i controlli di integrità, Cloud Run segue l'ordine di avvio dei container e verifica lo stato di salute di ciascuno, assicurandosi che ognuno superi il controllo con successo prima che Cloud Run avvii il container successivo nell'ordine. Se non utilizzi i controlli di integrità, i container integri verranno avviati anche se i container da cui dipendono non sono in esecuzione.

Scambiare i dati dei file tra i sidecar

Più container all'interno di una singola istanza possono accedere a un volume in memoria condiviso, accessibile a ogni container utilizzando i punti di montaggio che crei. Questa opzione viene comunemente utilizzata per condividere file tra container. Ad esempio, un container sidecar di telemetria può raccogliere i log da un container dell'applicazione.

Comunicare tra i sidecar

Due container della stessa istanza possono comunicare tra loro sulla rete locale.

Considera questo servizio di esempio:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example
spec:
  template:
    spec:
      containers:
      - name: ingress
        image: ...
        ports:
          - containerPort: 8080
      - name: sidecar
        image: ...

Ogni istanza di questo servizio eseguirà due container: uno denominato ingress e un altro denominato sidecar.

Le richieste che raggiungono il servizio vengono inviate al container ingress sulla porta 8080. In un servizio con più container, solo un container può essere configurato come container di ingresso che gestisce tutte le richieste in entrata, e questo deve essere il container per il quale è configurato un containerPort.

I container ingress e sidecar possono comunicare tra loro su http://localhost. Ad esempio, se il container sidecar è in ascolto delle richieste sulla porta 5000, il container ingress può comunicare con lui su http://localhost:5000.

Poiché i container hanno un nome, possono comunicare tra loro utilizzando il nome del container. Ad esempio, se il contenitoresidecar ascolta le richieste sulla porta5000, quindi il contenitoreingress può comunicare considecar utilizzando suhttp://sidecar:5000.

Adatta i tuoi container per Cloud Run

La maggior parte dei container che creerai o troverai saranno compatibili con il contratto di runtime dei container Cloud Run . Tuttavia, potresti dover modificare alcuni container creati per semplificare lo sviluppo locale o prevedere il controllo completo della macchina per renderli compatibili con gli ambienti di esecuzione di Cloud Run.

Sposta i punti di montaggio nella tua configurazione Cloud Run

Gli script di inizializzazione del container devono presupporre che i montaggi siano già completati prima di chiamare il container. Devi spostare tutte le operazioni di montaggio nella configurazione delle risorse Cloud Run.

Passa a un utente non root quando possibile

Preferisci i container che non utilizzano o non si basano sull'utente root. Questa pratica riduce il rischio di vulnerabilità del servizio Cloud Run, diminuisce la superficie di attacco del container, limita l'accesso degli autori degli attacchi ai tuoi file system e rispetta il principio del privilegio minimo.

Utilizza l'istruzione USER nel tuo Dockerfile per passare a un'identità con privilegi inferiori, poiché l'impostazione predefinita è l'esecuzione come root. Cloud Run utilizza l'utente specificato nel Dockerfile per eseguire il container.

Controllo dell'utilizzo dei file binari setuid

L'esecuzione dei binari setuid non andrà a buon fine se eseguiti dai container in Cloud Run.

Se utilizzi Docker o Podman in locale, utilizza l'argomento --cap-drop=setuid. In alternativa, verifica che i binari da cui dipendi non abbiano il bit setuid impostato.

Verifica che i contenitori root siano compatibili con gli spazi dei nomi utente

Testa le modifiche localmente o in una VM valutando il codice quando viene eseguito negli spazi dei nomi utente, ad esempio quando utilizzi la funzionalità userns-remap di Docker, esegui il container in Podman senza privilegi di root o esegui il deployment di queste modifiche nelle VM che eseguono Container-Optimized OS di Google con l'argomento --userns-remap=default nel comando docker run.

Disattiva il controllo di integrità del deployment

Per impostazione predefinita, Cloud Run verifica che il deployment sia integro avviando un'istanza e attendendo che il probe di avvio venga superato. Se il controllo di integrità non va a buon fine, la revisione verrà contrassegnata come non integra e il traffico non verrà indirizzato.

Se non è necessario o per aumentare la velocità di deployment, il controllo di integrità del deployment può essere disattivato:

gcloud

Per disattivare il controllo di integrità del deployment, utilizza il flag --no-deploy-health-check:

gcloud run deploy --image IMAGE_URL --no-deploy-health-check

Sostituisci quanto segue:

  • IMAGE_URL: un riferimento all'immagine container, ad esempio us-docker.pkg.dev/cloudrun/container/hello:latest. Se si utilizza Artifact Registry, il repository REPO_NAME deve essere già stato creato. L'URL segue il formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG .

Utilizza --deploy-health-check per riattivare il controllo di integrità del deployment se è stato disattivato in precedenza.

YAML

Per disattivare il controllo di integrità del deployment, aggiungi l'annotazione run.googleapis.com/health-check-disabled con il valore 'true' a spec.template.metadata.annotations.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/health-check-disabled: 'true'

Terraform

Per disattivare il controllo di integrità del deployment, imposta l'argomento health_check_disabled su true nel blocco template.

resource "google_cloud_run_v2_service" "default" {
  name     = "SERVICE"
  ...
  template {
    health_check_disabled = true
    ...
  }
}

Passaggi successivi

Dopo aver eseguito il deployment di un nuovo servizio, puoi:

È possibile automatizzare i build e i deployment dei servizi Cloud Run utilizzando i trigger di build di Cloud Build:

Puoi anche utilizzare Cloud Deploy per configurare una pipeline di distribuzione continua per eseguire il deployment dei servizi Cloud Run in più ambienti: