Deployment delle immagini container in 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 quando viene avviata una nuova istanza Cloud Run.

Per un esempio dettagliato di deployment di un nuovo servizio, vedi 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, dovrai accedere al servizio di cui è stato eseguito il deployment come descritto in Test dei servizi privati.

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per eseguire il deployment dei servizi Cloud Run, chiedi all'amministratore di concederti i seguenti ruoli IAM:

Per un elenco di ruoli e autorizzazioni IAM associati a Cloud Run, consulta Ruoli IAM Cloud Run e Autorizzazioni IAM 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 ulteriori informazioni sulla concessione dei ruoli, consulta Autorizzazioni di deployment e Gestire l'accesso.

Registri e immagini container supportati

Puoi utilizzare direttamente le immagini container archiviate in Artifact Registry o Docker Hub. Google consiglia l'utilizzo di Artifact Registry. 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, Nexus o GitHub Container Registry) configurando un repository remoto di Artifact Registry.

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

Cloud Run non supporta i livelli di immagini container più grandi di 9,9 GB quando esegui il deployment da Docker Hub o da un repository remoto Artifact Registry con un registro esterno.

Deployment di 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.

Fai clic sulla scheda relativa alle istruzioni per l'utilizzo dello strumento che preferisci.

Console

Per eseguire il deployment di un'immagine container:

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

    Vai a Cloud Run

  2. Seleziona Servizi dal menu e fai clic su Esegui il deployment del contenitore per visualizzare il modulo Crea servizio.

    1. Nel modulo, seleziona l'opzione di deployment:

      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.

    2. Inserisci il nome del servizio necessario. 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.

    3. Seleziona la regione in cui vuoi che si trovi il servizio. Il selettore di regioni indica il livello di prezzo, la disponibilità dei mapping dei domini ed evidenzia le regioni con il minore impatto di carbonio.

    4. Imposta la fatturazione in base alle esigenze.

    5. 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.

    6. Imposta le impostazioni di Ingresso nel modulo in base alle esigenze.

    7. In Autenticazione, configura quanto segue:

      • Se stai creando un'API o un sito web pubblici, seleziona Consenti chiamate non autenticate. 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.
  3. Fai clic su Container, volumi, networking, sicurezza per impostare altre impostazioni facoltative nelle schede appropriate:

  4. 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.

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

gcloud

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

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

    1. Esegui questo comando:

      gcloud run deploy SERVICE --image IMAGE_URL

      • Sostituisci SERVICE con il nome del servizio in 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. Puoi omettere completamente questo parametro, ma ti verrà chiesto il nome del servizio se lo ometti.
      • Sostituisci IMAGE_URL con un riferimento all'immagine container, ad esempio us-docker.pkg.dev/cloudrun/container/hello:latest. Se utilizzi Artifact Registry, il repository REPO_NAME deve essere già stato creato. L'URL ha la forma 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 o un sito web pubblici, consenti le chiamate non autenticate del tuo servizio utilizzando il flag --allow-unauthenticated. In questo modo viene assegnato il ruolo IAM Invoker di Cloud Run a allUsers. Puoi anche specificare --no-allow-unauthenticated per non consentire chiamate non autenticate. Se ometti uno di questi flag, ti viene chiesto di confermare l'esecuzione del comando deploy.

    2. Attendi il completamento del deployment. Al completamento 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

Puoi archiviare la specifica del servizio in un file YAML e poi deployarlo utilizzando gcloud CLI.

  1. Crea un nuovo file service.yaml con i seguenti contenuti:

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

    Sostituisci

    • SERVICE con 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 con l'URL dell'immagine container.

    Puoi anche specificare altre configurazioni, come variabili di ambiente o limiti di memoria.

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

    gcloud run services replace service.yaml
  3. Se vuoi consentire l'accesso non autenticato al servizio, rendilo pubblico.

Cloud Code

Per eseguire il deployment con Cloud Code, leggi le guide per IntelliJ e Visual Studio Code.

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"
      }
    }
  }

  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:

  • PROJECT-ID con l' Google Cloud ID progetto
  • REGION con la regione Google Cloud
  • SERVICE con 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 con un riferimento all'immagine container, ad esempio us-docker.pkg.dev/cloudrun/container/hello:latest. Se utilizzi Artifact Registry, il repository REPO_NAME deve essere già stato creato. L'URL ha la forma 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.

Librerie client

Per eseguire il deployment di un nuovo servizio dal codice:

API REST

Per eseguire il deployment di un nuovo servizio, invia una richiesta HTTP POST all'endpoint service dell'API Cloud Run Admin.

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:

  • ACCESS_TOKEN con un token di accesso valido per un account che dispone delle autorizzazioni IAM per il deployment dei 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 di metadati dell'istanza container.
  • IMAGE_URL con un riferimento all'immagine container, ad esempio us-docker.pkg.dev/cloudrun/container/hello:latest. Se utilizzi Artifact Registry, il repository REPO_NAME deve essere già stato creato. L'URL ha la forma LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG .
  • SERVICE con 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.
  • REGION con la regione Google Cloud del servizio.
  • PROJECT-ID con l' Google Cloud ID progetto.

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à sono fattori primari 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 Cloud prodotti utilizzati dal tuo servizio Cloud Run. L'utilizzo Google Cloud combinato di prodotti 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)
  • europe-west10 (Berlino) icona foglia Bassi livelli di CO2
  • europe-west12 (Torino)
  • europe-west2 (Londra, Regno Unito) icona foglia Bassi livelli di CO2
  • europe-west3 (Francoforte, Germania) icona foglia Bassi livelli di CO2
  • europe-west6 (Zurigo, Svizzera) icona foglia Bassi livelli di CO2
  • me-central1 (Doha)
  • me-central2 (Dammam)
  • northamerica-northeast1 (Montreal) icona foglia Bassi livelli di CO2
  • northamerica-northeast2 (Toronto) icona foglia Bassi livelli di CO2
  • southamerica-east1 (San Paolo, Brasile) icona foglia Bassi livelli di CO2
  • southamerica-west1 (Santiago, Cile) icona foglia Bassi livelli di CO2
  • us-west2 (Los Angeles)
  • 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 .

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 pubblicazione.

Fai clic sulla scheda relativa alle istruzioni per l'utilizzo dello strumento che preferisci.

Console

Per eseguire il deployment di una nuova revisione di un servizio esistente:

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

    Vai a Cloud Run

  2. Individua il servizio che vuoi aggiornare nell'elenco dei servizi e fai clic per aprire i relativi dettagli.

  3. Fai clic su Modifica ed esegui il deployment di una nuova revisione per visualizzare il modulo di deployment della revisione.

    1. Se necessario, fornisci l'URL della nuova immagine del container di cui vuoi eseguire il deployment.

    2. Configura il contenitore in base alle esigenze.

    3. Imposta la fatturazione in base alle esigenze.

    4. In Capacità, specifica i limiti di memoria e i limiti di CPU.

    5. Specifica il timeout della richiesta e la contemporaneità in base alle esigenze.

    6. Specifica l'ambiente di esecuzione in base alle esigenze.

    7. In Scalabilità automatica, specifica le istanze minime e massime.

    8. Utilizza le altre schede in base alle esigenze per configurare facoltativamente:

  4. Per inviare tutto il traffico alla nuova revisione, seleziona Pubblica questa revisione immediatamente. Per implementare gradualmente una nuova revisione, deseleziona la casella di controllo. Il risultato è un deployment in cui nessun traffico viene inviato alla nuova revisione. Segui le istruzioni per implementazioni graduali dopo il deployment.

  5. Fai clic su Esegui il deployment e attendi il completamento del deployment.

gcloud

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

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

    1. Esegui il comando:

      gcloud run deploy SERVICE --image IMAGE_URL

      • Sostituisci SERVICE con il nome del servizio in cui esegui il deployment. Puoi omettere completamente questo parametro, ma ti verrà chiesto il nome del servizio se lo ometti.
      • Sostituisci IMAGE_URL con un riferimento all'immagine container, ad esempio us-docker.pkg.dev/cloudrun/container/hello:latest. Se utilizzi Artifact Registry, il repository REPO_NAME deve essere già stato creato. L'URL ha la forma 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 del deployment. Al completamento 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

Cloud Code

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

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.

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:

  • ACCESS_TOKEN con un token di accesso valido per un account che dispone delle autorizzazioni IAM per il deployment delle 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 di metadati dell'istanza container.
  • IMAGE_URL con un riferimento all'immagine container, ad esempio us-docker.pkg.dev/cloudrun/container/hello:latest. Se utilizzi Artifact Registry, il repository REPO_NAME deve essere già stato creato. L'URL ha la forma LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG .
  • SERVICE con il nome del servizio a cui esegui il deployment.
  • REGION con la regione Google Cloud del servizio.
  • PROJECT-ID con l' Google Cloud ID progetto.

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à sono fattori primari 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 Cloud prodotti utilizzati dal tuo servizio Cloud Run. L'utilizzo Google Cloud combinato di prodotti 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)
  • europe-west10 (Berlino) icona foglia Bassi livelli di CO2
  • europe-west12 (Torino)
  • europe-west2 (Londra, Regno Unito) icona foglia Bassi livelli di CO2
  • europe-west3 (Francoforte, Germania) icona foglia Bassi livelli di CO2
  • europe-west6 (Zurigo, Svizzera) icona foglia Bassi livelli di CO2
  • me-central1 (Doha)
  • me-central2 (Dammam)
  • northamerica-northeast1 (Montreal) icona foglia Bassi livelli di CO2
  • northamerica-northeast2 (Toronto) icona foglia Bassi livelli di CO2
  • southamerica-east1 (San Paolo, Brasile) icona foglia Bassi livelli di CO2
  • southamerica-west1 (Santiago, Cile) icona foglia Bassi livelli di CO2
  • us-west2 (Los Angeles)
  • 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 .

Deployment di immagini da altri Google Cloud progetti

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

Per i ruoli richiesti per l'account di deployment, consulta la sezione Ruoli richiesti.

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

  1. Nella Google Cloud console, 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'indirizzo email dell'agente di servizio Cloud Run. Ha il suffisso @serverless-robot-prod.iam.gserviceaccount.com

  4. Apri il progetto proprietario del registro dei container che vuoi utilizzare.

    Vai alla pagina IAM

  5. Fai clic su Aggiungi per aggiungere una nuova entità.

  6. Nel campo Nuove entità, incolla l'email dell'account di servizio che hai copiato in precedenza.

  7. Nel menu a discesa Seleziona un ruolo, fai clic su Artifact Registry -> Lettore Artifact Registry.

  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, configura un repository remoto di Artifact Registry.

I repository remoti di Artifact Registry ti consentono di:

  • Esegui il deployment di qualsiasi immagine container pubblica, ad esempio GitHub Container Registry (ghcr.io).
  • 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.

Deployment di più container in 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 Ingress, ma possono comunicare tra loro e con il container 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 utilizzi la fatturazione basata sulle richieste (l'impostazione predefinita di Cloud Run), i sidecar vengono allocati alla CPU solo in questi scenari:

  • L'istanza sta elaborando almeno una richiesta.
  • Il container in entrata è in fase di avvio.

Se il 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 saperne di più, vedi 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 norme dell'organizzazione personalizzate.

Casi d'uso

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

  • Monitoraggio, logging 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

Deployment di un servizio con container collaterali

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

Fai clic sulla scheda relativa alle istruzioni per l'utilizzo dello strumento che preferisci.

Console

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

    Vai a Cloud Run

    • Per eseguire il deployment in un servizio esistente, individua il servizio nell'elenco dei servizi, fai clic per aprirlo, poi fai clic su Modifica ed esegui il deployment di una nuova revisione per visualizzare il modulo di deployment della revisione.
    • Seleziona Servizi dal menu e fai clic su Esegui il deployment del contenitore per visualizzare il modulo Crea servizio.
  2. Per un nuovo servizio,

    1. Fornisci il nome del servizio e l'URL dell'immagine del container di ingresso di cui vuoi eseguire il deployment.
    2. Fai clic su Container, volumi, networking, sicurezza.
  3. Nella scheda Modifica contenitore, configura il contenitore di ingresso in base alle esigenze.

  4. Fai clic su Aggiungi contenitore e configura un contenitore sidecar da aggiungere insieme al contenitore di ingresso. Se il sidecar dipende da un altro container nel servizio, indicalo nel menu a discesa Ordine di avvio del container. Ripeti questo passaggio per ogni contenitore sidecar che stai eseguendo il deployment.

  5. 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.

  6. Fai clic su Crea per un nuovo servizio o su Esegui il deployment per un servizio esistente, quindi attendi il completamento del deployment.

gcloud

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. Per eseguire il deployment di più container in un servizio, esegui questo comando:

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

    Sostituisci:

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

    Se vuoi configurare ogni contenitore nel comando di deployment, fornisci la configurazione di ciascun contenitore 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 del deployment. 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

  • SERVICE con il nome del tuo servizio Cloud Run. I nomi dei servizi devono contenere al massimo 49 caratteri.
  • CONTAINER_PORT con la porta in cui il container in entrata è in ascolto delle richieste in arrivo. A differenza di un servizio a singolo container, per un servizio contenente sidecar non esiste una porta predefinita per il container di ingresso. Devi configurare esplicitamente la porta del container per il container di ingresso e solo un container può avere la porta esposta.
  • INGRESS_IMAGE con un riferimento all'immagine container che deve ricevere le richieste, ad esempio us-docker.pkg.dev/cloudrun/container/hello:latest.
  • SIDECAR_IMAGE con un riferimento all'immagine container sidecar. Puoi 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

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:
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 ingress rimane in ascolto delle 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. Devi configurare esplicitamente la porta del container per il container di ingresso e solo un container può avere la porta esposta.

Funzionalità importanti disponibili per i deployment con i sidecar

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 utilizzare i controlli di integrità nel deployment. Se utilizzi i controlli di integrità, Cloud Run segue l'ordine di avvio dei container e ispeziona l'integrità di ciascun container, assicurandosi che ognuno superi il controllo 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.

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.

Passaggi successivi

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

Puoi automatizzare le build e i deployment dei tuoi servizi Cloud Run utilizzando i trigger 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: