Esegui il deployment di un servizio, un job o un pool di worker Cloud Run

Questo documento descrive come eseguire il deployment delle applicazioni, inclusi i servizi Cloud Run, i job Cloud Run e i pool di worker Cloud Run.

Cloud Deploy ti consente di eseguire il deployment dei tuoi carichi di lavoro basati su container in qualsiasi servizio Cloud Run, job o pool di worker. Tutte le funzionalità di Cloud Deploy sono supportate quando esegui il deployment nei target Cloud Run per i servizi o i pool di worker Cloud Run, ma i deployment canary non sono supportati per i job Cloud Run.

Questo documento descrive le tre configurazioni principali che devi completare per eseguire il deployment su Cloud Run:

Limitazioni

  • Puoi eseguire il deployment di un solo servizio, job o pool di worker Cloud Run per destinazione.

  • Non puoi eseguire un canary deployment su un job Cloud Run.

    I servizi Cloud Run e i pool di worker, tuttavia, possono utilizzare un deployment canary.

  • Per eseguire il deployment di una funzione Cloud Run utilizzando Cloud Deploy, devi modificare il flusso di lavoro CI per creare la funzione in un container ed eseguirne il deployment come servizio Cloud Run.

Prima di iniziare

Crea la configurazione del target

La destinazione può essere configurata nel file YAML della pipeline di distribuzione o in un file separato. Inoltre, puoi configurare più di un target nello stesso file.

I target devono essere definiti nello stesso progetto e nella stessa regione della pipeline di distribuzione. Tuttavia, i servizi, i job o i pool di worker a cui vengono implementate le destinazioni possono trovarsi in progetti e regioni diversi, a condizione che il account di servizio abbia accesso a questi progetti.

Nella definizione della destinazione, crea una sezione run per identificare la posizione in cui verrà creato il servizio Cloud Run.

La sintassi per specificare il servizio, il job o il pool di worker Cloud Run nella definizione della destinazione è la seguente:

run:
 location: projects/[project_name]/locations/[region_name]

Questo identificatore di risorsa utilizza i seguenti elementi:

  • project_name è il nome del progetto Google Cloud in cui verrà creato il servizio, il job o il pool di worker Cloud Run.

    Esegui questa operazione per ogni target. Ti consigliamo un progetto diverso per ogni servizio, job o pool di worker Cloud Run. Se vuoi più di un servizio, un job o un pool di lavoratori nello stesso progetto, devi utilizzare i profili Skaffold nel file di configurazione skaffold.yaml.

  • region_name è la regione in cui verrà creato il servizio, il job o il pool di worker. Il servizio, il job o il pool di worker può trovarsi in qualsiasi regione supportata da Cloud Run.

Di seguito è riportata una configurazione di destinazione di esempio che definisce il servizio, il job o il pool di worker Cloud Run da creare:

      apiVersion: deploy.cloud.google.com/v1
      kind: Target
      metadata:
       name: dev
      description: development service
      run:
       location: projects/my-app/locations/us-central1

Puoi definire questo target all'interno di una definizione della pipeline di distribuzione di Cloud Deploy o separatamente. In entrambi i casi, devi registrare la destinazione prima di creare la release per eseguire il deployment del servizio, del job o del pool di worker Cloud Run.

Crea la configurazione di Skaffold

Di seguito è riportato un esempio di file skaffold.yaml per un deployment di Cloud Run:

apiVersion: skaffold/v4beta7
kind: Config
metadata: 
  name: cloud-run-application
manifests:
  rawYaml:
  - service.yaml
deploy:
  cloudrun: {}

In questo file skaffold.yaml

  • manifests.rawYaml fornisce i nomi delle definizioni del servizio Cloud Run.

    In questo esempio, service.yaml è il file che definisce un servizio Cloud Run di cui Skaffold eseguirà il deployment. Questo nome file può essere qualsiasi, ma per convenzione è service.yaml per un servizio, job.yaml per un job e workerpool.yaml per un pool di worker.

  • La stanza deploy specifica come vuoi che venga eseguito il deployment del manifest, in particolare il progetto e la posizione. deploy è obbligatorio.

    Ti consigliamo di lasciare vuoto {}. Cloud Deploy compila questo campo durante il rendering, in base al progetto e alla località della definizione del target.

    Per lo sviluppo locale, tuttavia, puoi fornire valori qui. Tuttavia, Cloud Deploy utilizza sempre il progetto e la località della definizione del target, indipendentemente dal fatto che i valori siano forniti qui.

Crea le definizioni del servizio Cloud Run

Per creare una definizione del servizio Cloud Run, puoi crearne una manualmente o copiarne una da un servizio esistente. Entrambi sono descritti in questa sezione.

Opzione 1: crea un nuovo service.yaml Cloud Run

Il file service.yaml definisce il servizio Cloud Run. Quando crei una release, Skaffold utilizza questa definizione per eseguire il deployment del servizio.

Ecco un esempio semplificato:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
 name: [SERVICE_NAME]
spec:
 template:
  spec:
   containers:
   - image: [IMAGE_PATH]

Dove:

  • [SERVICE_NAME] è un nome per questo servizio Cloud Run.

  • [IMAGE_PATH] indica l'immagine o le immagini container di cui esegui il deployment con questo servizio.

Opzione 2: copia un service.yaml da un servizio esistente utilizzando la console Google Cloud

Puoi creare un servizio utilizzando la console Google Cloud o utilizzarne uno esistente e copiare da lì il tuo service.yaml.

Per ottenere service.yaml utilizzando Google Cloud CLI:

gcloud run services describe [service_name] --format=export

Per ottenere service.yaml dalla console Google Cloud :

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

  2. Seleziona il servizio esistente di cui vuoi utilizzare la definizione.

In alternativa, puoi crearne uno nuovo e selezionarlo. Quando selezioni il servizio, viene visualizzata la pagina Dettagli del servizio:

Pagina dei dettagli del servizio
 nella consoleGoogle Cloud , che mostra la scheda YAML

  1. Seleziona la scheda YAML.

  2. Fai clic su Modifica, quindi copia i contenuti del file YAML in un nuovo file denominato service.yaml nel tuo file system, in modo che Skaffold possa utilizzarlo quando crei una release.

Crea le definizioni dei job Cloud Run

Per eseguire il deployment di una definizione di job Cloud Run, puoi crearne una manualmente o copiarne una da un job esistente. Entrambi sono descritti in questa sezione.

Tieni presente che i job non vengono necessariamente eseguiti dopo il deployment da parte di Cloud Deploy. Questo è diverso dai servizi, che eseguono le applicazioni dopo il deployment. La modalità di chiamata di un job dipende dal job stesso.

Opzione 1: crea un nuovo job.yaml Cloud Run

Il file job.yaml definisce il job Cloud Run. Quando crei una release, Skaffold utilizza questa definizione per eseguire il deployment del job.

Ecco un esempio semplificato:

apiVersion: run.googleapis.com/v1
kind: Job
metadata:
 name: [JOB_NAME]
spec:
  template:
  spec:
   containers:
   - image: [IMAGE_PATH]

Dove:

  • [JOB_NAME] è un nome per questo job Cloud Run.

  • [IMAGE_PATH] punta all'immagine container di cui stai eseguendo il deployment per questo job.

Opzione 2: copia un job.yaml da un job esistente utilizzando la console Google Cloud

Puoi creare un job utilizzando la console Google Cloud o utilizzarne uno esistente e copiare il tuo job.yaml da lì.

Per ottenere job.yaml utilizzando Google Cloud CLI:

gcloud run jobs describe [job_name] --format=export

Per ottenere job.yaml dalla console Google Cloud :

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

  2. Seleziona il job esistente di cui vuoi utilizzare la definizione.

In alternativa, puoi crearne uno nuovo e selezionarlo. Quando selezioni il job, viene visualizzata la pagina Dettagli job:

Pagina dei dettagli del job
consoleGoogle Cloud , che mostra la scheda YAML

  1. Seleziona la scheda YAML.

  2. Fai clic su Modifica, quindi copia i contenuti del file YAML in un nuovo file denominato job.yaml nel tuo file system, in modo che Skaffold possa utilizzarlo quando crei una release.

Crea le definizioni del pool di worker Cloud Run

Per eseguire il deployment di una definizione di pool di worker Cloud Run, puoi crearne una manualmente o copiarne una da un pool di worker esistente. Entrambi sono descritti in questa sezione.

Opzione 1: crea un nuovo workerpool.yaml Cloud Run

Il file workerpool.yaml definisce il pool di worker Cloud Run. Quando crei una release, Skaffold utilizza questa definizione per eseguire il deployment del pool di worker.

Ecco un esempio semplificato:

apiVersion: run.googleapis.com/v1
kind: WorkerPool
metadata:
 name: [WORKERPOOL_NAME]
 annotations:
  run.googleapis.com/launch-stage: BETA
spec:
  template:
   spec:
    containers:
    - image: [IMAGE_PATH]

Dove:

  • [WORKERPOOL_NAME] è un nome per questo pool di worker Cloud Run.

  • [IMAGE_PATH] punta all'immagine container di cui stai eseguendo il deployment per questo pool di worker.

Opzione 2: copia un workerpool.yaml da un worker pool esistente utilizzando la console Google Cloud

Puoi creare un pool di lavoratori utilizzando la Google Cloud console o utilizzarne uno esistente e copiare il tuo workerpool.yaml da lì.

Per ottenere workerpool.yaml utilizzando Google Cloud CLI:

gcloud beta run worker-pools describe [workerpool_name] --format=export

Per ottenere workerpool.yaml dalla console Google Cloud :

  1. Nella console Google Cloud , vai alla pagina Pool di worker Cloud Run.

  2. Seleziona il worker pool esistente di cui vuoi utilizzare la definizione.

In alternativa, puoi crearne uno nuovo e selezionarlo. Quando selezioni il worker pool, viene visualizzata la pagina Dettagli del worker pool:

Pagina dei dettagli del pool di worker
 ConsoleGoogle Cloud , che mostra la scheda YAML

  1. Seleziona la scheda YAML.

  2. Copia i contenuti del file YAML in un nuovo file denominato workerpool.yaml nel tuo file system, in modo che Skaffold possa utilizzarlo quando crei una release.

In sintesi

Ora che hai la definizione del servizio, del job o del pool di worker Cloud Run, la configurazione skaffold.yaml e la definizione della destinazione Cloud Deploy e che hai registrato la destinazione come risorsa Cloud Deploy, puoi richiamare la pipeline di distribuzione per creare una release e farla avanzare nella progressione delle destinazioni definite nella pipeline.

La guida rapida Esegui il deployment di un'app in Cloud Run utilizzando Cloud Deploy mostra tutto questo in azione.

Comportamento dei servizi nelle varie revisioni

Quando esegui nuovamente il deployment di un servizio, la nuova revisione si basa sul service.yaml appena eseguito. Nessun elemento della revisione precedente viene mantenuto, a meno che non sia lo stesso nel file YAML appena implementato. Ad esempio, se nella revisione precedente sono presenti impostazioni di configurazione o etichette che non sono presenti nel nuovo YAML, queste impostazioni o etichette non sono presenti nella nuova revisione.

Attivazione dei job Cloud Run

Dopo aver eseguito il deployment di un job, puoi attivarlo come descritto nella documentazione di Cloud Run.

Deployment di servizi, job e pool di worker Cloud Run in più progetti

Se devi eseguire il deployment di servizi, job o pool di worker che si trovano in progetti diversi, il tuo service account di esecuzione deve disporre dell'autorizzazione per accedere ai progetti in cui sono definiti questi servizi, job o pool di worker.

Per saperne di più, consulta Account di servizio di esecuzione di Cloud Deploy e Ruoli e autorizzazioni di Identity and Access Management.

Deployment di Cloud Run Functions

Cloud Run Functions compila il codice sorgente ogni volta che viene eseguito il deployment di una funzione. Per questo motivo, ogni runtime di destinazione nella pipeline potrebbe ottenere un artefatto leggermente diverso. Ciò è contrario alle best practice di Cloud Deploy. Ti consigliamo invece di utilizzare direttamente un servizio Cloud Run. In questo modo puoi creare un unico artefatto e promuoverlo nei tuoi ambienti.

  1. Controlla service.yaml per la tua funzione Cloud Run.

    Puoi ottenerlo eseguendo questo comando:

    gcloud run services describe FUNCTION_NAME \
    --format=export \
    --region=REGION \
    --project=PROJECT
    
  2. Rimuovi le seguenti annotazioni, se presenti:

    • run.googleapis.com/build-base-image
    • run.googleapis.com/build-name
    • run.googleapis.com/build-source-location
    • run.googleapis.com/build-enable-automatic-updates
  3. Sostituisci il valore in spec.spec.containers.image con IMAGE_TAG.

  4. Crea la pipeline di distribuzione e i target con il servizio Cloud Run come target.

  5. Separa il passaggio di build dal passaggio di deployment nel processo CI. Anziché utilizzare Google Cloud CLI per eseguire il deployment della funzione, sostituiscila con i seguenti passaggi:

    1. Crea la funzione in un container utilizzando Cloud Build:

      gcloud builds submit --pack image=REGION-docker.pkg.dev/PROJECT/cloud-run-source-deploy/IMAGE_NAME \
      --project=PROJECT \
      --region=REGION
      
    2. Crea una release utilizzando Cloud Deploy:

      gcloud deploy releases create RELEASE_NAME \
      --project=DEPLOY_PROJECT \
      --region=REGION \
      --delivery-pipeline=DELIVERY_PIPELINE \
      --images=IMAGE_TAG=REGION-docker.pkg.dev/PROJECT/cloud-run-source-deploy/IMAGE_NAME
      

      In questo comando…

      • RELEASE_NAME è un nome da assegnare a questa release. Il nome deve essere univoco tra tutte le release per questa pipeline di distribuzione.

      • DEPLOY_PROJECT è l'ID progetto del progetto in cui hai creato la pipeline di deployment.

      • DELIVERY_PIPELINE è il nome della pipeline di pubblicazione che gestirà il deployment di questa release attraverso la progressione delle destinazioni. Questo nome deve corrispondere al campo name nella definizione della pipeline.

      • REGION è il nome della regione in cui stai creando la release, ad esempio us-central1. Campo obbligatorio.

      • IMAGE_NAME è il nome che hai assegnato all'immagine nel passaggio precedente, quando hai creato la funzione.

Passaggi successivi