Usa una strategia di deployment canary

Questo documento descrive come configurare e utilizzare una strategia di deployment canary.

Che cos'è un deployment canary?

Un deployment canary è un'implementazione progressiva di un'applicazione che si divide del traffico tra una versione di cui è già stato eseguito il deployment e una nuova, a un sottoinsieme di utenti prima dell'implementazione completa.

Tipi di target supportati

Il deployment canary in Cloud Deploy supporta tutti i tipi di destinazione, tra cui:

canary funziona anche con più target.

Perché utilizzare una strategia di deployment canary?

Un deployment canary ti offre la possibilità di rilasciare parzialmente la tua applicazione. Nel puoi assicurarti che la nuova versione della tua applicazione sia affidabile prima a tutti gli utenti.

Se esegui il deployment in GKE o GKE Enterprise, Ad esempio, eseguirai il deployment della nuova versione dell'applicazione dei pod. La versione precedente continuerà a essere eseguita, ma con un numero sempre maggiore il traffico inviato ai nuovi pod.

Se esegui il deployment in Cloud Run, Cloud Run suddivide il traffico tra la vecchia e la nuova revisione, in base alla percentuali che configuri.

Tipi di canary

Cloud Deploy consente di configurare i seguenti tipi di deployment deployment:

  • Automatico

    Con un canary automatizzato il deployment, devi configurare Cloud Deploy con una serie che esprimono un'implementazione progressiva. Cloud Deploy esegue operazioni aggiuntive per tuo conto per distribuire il traffico percentuali tra la vecchia e la nuova versione.

  • Personalizzata e automatica

    Per una versione canary custom-automated, puoi fornire seguenti:

    • Il nome della fase
    • L'obiettivo percentuale
    • Il profilo Skaffold da utilizzare per la fase
    • Indica se includere o meno un job di verifica
    • Indica se includere o meno un job di pre-deployment o post-deployment o entrambi

    Tuttavia non è necessario fornire informazioni sul bilanciamento del traffico: Cloud Deploy crea il le risorse necessarie.

  • Personalizzato

    Con una versione canary personalizzata, puoi configurare ogni fase canary separatamente, tra cui:

    • Il nome della fase
    • L'obiettivo percentuale
    • Il profilo Skaffold da utilizzare per la fase
    • Indica se includere o meno un job di verifica
    • Indica se includere o meno un job di pre-deployment o post-deployment o entrambi

    Inoltre, per una versione canary completamente personalizzata, fornisci tutte le del traffico, come descritto qui

Fasi di un deployment canary

Quando crei una release per un deployment canary, l'implementazione viene creata una fase per ogni incremento canary, più una fase stable finale per il 100%.

Ad esempio, se configuri un canary per incrementi del 25%, 50% e 75%, il rollout avrà le seguenti fasi:

  • canary-25
  • canary-50
  • canary-75
  • stable
di Gemini Advanced.

Puoi scoprire di più sulle fasi di implementazione, sui job e sulle esecuzioni dei job in Gestire le implementazioni.

Cosa succede durante una versione canary automatizzata o personalizzata

Per supportare il deployment canary, Cloud Deploy include speciali durante il rendering del manifest Kubernetes Configurazione del servizio Cloud Run:

GKE/Enterprise

Ecco come Cloud Deploy esegue un deployment canary GKE e GKE Enterprise basati sulla rete:

  1. Specifica il nome della risorsa Deployment e della risorsa Servizio.

  2. Cloud Deploy crea un'ulteriore risorsa di deployment, il nome del tuo deployment attuale più -canary.

  3. Cloud Deploy modifica il servizio per regolare il selettore in seleziona i pod nel deployment attuale e i pod canary.

    Cloud Deploy calcola il numero di pod da utilizzare per canary sulla base del calcolo descritto qui Questo calcolo varia a seconda se abiliti o disattivi l'overprovisioning dei pod.

    Se saltiamo alla fase stable Cloud Deploy aggiunge le etichette da utilizzare per abbinare i pod, e sono disponibili per le successive esecuzioni canary.

    Cloud Deploy crea un deployment che include di pod specifici per ogni fase, aggiornandola per ogni fase. Questo è viene eseguita calcolando il numero di pod come percentuale dell'offerta originale dei pod. Ciò può comportare una suddivisione del traffico inesatta. Se hai bisogno una suddivisione del traffico esatta, puoi raggiungerla utilizzando l'API Gateway.

    Inoltre, i volumi Secret e ConfigMap vengono copiati e rinominati con -canary.

  4. Durante la fase stable, viene fatto lo scale down del deployment -canary al e il deployment originale viene sostituito con il nuovo.

    Cloud Deploy non modifica il deployment originale fino a quando stable fase.

Cloud Deploy esegue il provisioning dei pod per raggiungere la versione canary richiesta la percentuale più vicina possibile. Si basa sul numero di pod, non il traffico verso i pod. Se vuoi che la versione canary sia basata sul traffico, devono utilizzare l'API Gateway.

Per GKE basato sulla rete canary, puoi abilitare o disabilitare l'overprovisioning dei pod. Le seguenti sezioni descrivono come Cloud Deploy calcola il numero di pod di cui eseguire il provisioning per il deployment canary per ogni fase canary.

Provisioning dei pod con overprovisioning abilitato

Abilitazione dell'overprovisioning (disablePodOverprovisioning: false) consente a Cloud Deploy di creare un numero sufficiente di pod aggiuntivi per eseguire la percentuale canary desiderata, in base al numero di pod che eseguono un deployment esistente. La seguente formula mostra come Cloud Deploy calcola il numero di pod di cui eseguire il provisioning deployment canary per ogni fase canary, quando l'overprovisioning dei pod attivato:

math.Ceil( percentage * ReplicaCountOfDeploymentOnCluster / (100-percentage))

Con questa formula, il numero di repliche corrente (il numero di pod che hai già, prima di questo canary) viene moltiplicato per la percentuale del canary per la fase e il risultato viene diviso per (100 meno la percentuale).

Ad esempio, se hai già 4 pod e la fase canary è del 50%, il numero di pod canary è 4. (Il risultato di 100-percentage viene utilizzato come percentuale: 100-50=50, trattata come .50.)

L'overprovisioning dei pod è il comportamento predefinito.

Provisioning dei pod con overprovisioning disabilitato

Puoi disattivare l'overprovisioning (disablePodOverprovisioning: true), per assicurarti che Cloud Deploy non aumenti il numero di repliche.

La seguente formula mostra in che modo Cloud Deploy calcola i pod il provisioning del deployment canary per ogni fase canary, quando l'overprovisioning è disabilitato:

math.Ceil( (ReplicaCountOfDeploymentOnCluster + ReplicaCountOfCanaryDeploymentOnCluster) * percentage)

In questa formula, ReplicaCountOfCanaryDeploymentOnCluster esiste solo se esisteva già una fase canary. Se questa è la prima fase canary, non è ReplicaCountOfCanaryDeploymentOnCluster.

Se inizi con 4 pod, questo numero viene moltiplicato per la percentuale canary (ad es. 50% o .5) per ottenere 2. Il deployment originale è ora lo scale down a 2 e la creazione di 2 nuovi pod per il deployment canary. Se hai una fase canary del 75%, hai 2 (deployment originale) +2 (prima fase canary), *.75, per ottenere 3 pod canary e 1 pod che eseguono deployment originale.

Gateway GKE/Enterprise

Ecco come Cloud Deploy esegue un deployment canary GKE e GKE Enterprise con l'API Gateway:

  1. Oltre ai riferimenti a Deployment and Service, puoi fornire Risorsa HTTPRoute con una regola backendRefs che fa riferimento al servizio.

  2. Cloud Deploy crea un nuovo deployment, con il nome del il deployment originale più -canary, oltre a un nuovo servizio con Nome del servizio più -canary.

    Inoltre, vengono copiati anche Secret, ConfigMap e Horizontal Pod Autoscaler e rinominata con -canary.

  3. Per ogni fase canary, Cloud Deploy modifica la richiesta HTTPRoute aggiornare la ponderazione tra i pod del deployment originale e dei pod del deployment canary, in base alla percentuale per quella fase.

    Perché potrebbe verificarsi un ritardo nella propagazione delle modifiche a HTTPRoute puoi utilizzare includono la proprietà routeUpdateWaitTime in configurazione, quindi il sistema attende un determinato periodo di tempo durante la propagazione.

  4. Durante la fase stable, viene fatto lo scale down del deployment -canary al zero e il deployment originale viene aggiornato in modo da utilizzare la classe per il deployment.

    Inoltre, per la HTTPRoute viene ripristinata la versione originale che hai fornito.

    Cloud Deploy non modifica il deployment originale Servizio fino alla fase stable.

Cloud Run

Ecco come Cloud Deploy esegue un deployment canary Cloud Run:

  • Per un deployment canary in Cloud Run, non fornire un traffic stanza nel tuo servizio YAML.

  • Quando si crea una nuova implementazione per la versione canary, Cloud Deploy si divide il traffico tra la revisione precedente il cui deployment è stato eseguito correttamente Cloud Deploy e una nuova revisione.

Se vuoi vedere le differenze tra le fasi di un deployment canary, puoi visualizzare le modifiche nel manifest sottoposto a rendering per fase disponibile release inspector. Puoi farlo anche prima che sia iniziata l'implementazione. Inoltre, se utilizzi deployment parallelo, puoi anche ispezionare con il rendering manifest.

Configurare un deployment canary

Questa sezione descrive come configurare la pipeline di distribuzione e i target per un deployment canary.

Queste istruzioni includono solo gli elementi specifici della configurazione canary. La documento Deploy your application contiene le le istruzioni generali per configurare ed eseguire la pipeline di deployment.

Assicurati di disporre delle autorizzazioni necessarie

Oltre alle altre autorizzazioni di Identity and Access Management necessarie per l'utilizzo a Cloud Deploy, devi disporre delle seguenti autorizzazioni per eseguire azioni aggiuntive che potrebbero essere necessarie per un deployment canary:

  • clouddeploy.rollouts.advance
  • clouddeploy.rollouts.ignoreJob
  • clouddeploy.rollouts.cancel
  • clouddeploy.rollouts.retryJob
  • clouddeploy.jobRuns.get
  • clouddeploy.jobRuns.list
  • clouddeploy.jobRuns.terminate

Vedi Ruoli e autorizzazioni IAM per ulteriori informazioni su quali ruoli disponibili includono queste autorizzazioni.

Prepara il tuo skaffold.yaml

Come per un deployment standard, la versione canary ha bisogno di un file skaffold.yaml, che definisce il modo in cui viene eseguito il rendering e il deployment di manifest e definizioni di servizi.

Il skaffold.yaml che crei per un deployment canary non ha speciali oltre a quello necessario per i requisiti e deployment continuo.

Prepara il manifest o la definizione del servizio

Come per un deployment standard, la versione canary ha bisogno di un manifest Kubernetes o Definizione del servizio Cloud Run.

GKE e GKE Enterprise

Per la versione canary, il file manifest deve avere quanto segue:

  • Un deployment e un servizio.

  • Il servizio deve definire un selettore, che deve selezionare i pod del deployment specificato. Il valore predefinito è app.

  • Se utilizzi una versione canary basata sull'API Gateway, il manifest deve inoltre avere un parametro HTTPRoute.

Cloud Run

Per la versione canary su Cloud Run, la tua normalità il file di definizione del servizio Cloud Run è sufficiente, senza la stanza traffic. Cloud Deploy gestisce la suddivisione il traffico tra l'ultima revisione corretta e la nuova.

Configura una versione canary automatizzata

Le seguenti istruzioni si riferiscono a Cloud Run e Networking basato sui servizi GKE e GKE Enterprise target. Se utilizzi l'API Kubernetes Gateway con GKE GKE Enterprise, consulta questa documentazione.

Configuri il canary automatizzato nella definizione della pipeline di distribuzione:

GKE e GKE Enterprise

Nella fase della pipeline, includi una proprietà strategy, come segue:

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
              podSelectorLabel: "LABEL"
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false
          predeploy:
            actions: "PREDEPLOY_ACTION"
          postdeploy:
            actions: "POSTDEPLOY_ACTION"

In questa configurazione...

  • SERVICE_NAME è il nome del servizio Kubernetes, definita nel file manifest.

  • DEPLOYMENT_NAME è il nome del tuo ambiente Deployment, definito nel manifest.

  • LABEL è un'etichetta del selettore pod. Deve corrispondere all'etichetta nel servizio Kubernetes definito nel manifest. Questo è facoltativo. Il valore predefinito è app.

  • PERCENTAGES è un elenco di valori percentuale separati da virgole che rappresentano gli incrementi canary, ad esempio [5, 25, 50].

    Inoltre, non è incluso 100, perché il deployment al 100% è assunto nella versione canary e viene gestito dal stable fase.

  • Puoi abilitare la verifica del deployment (verify: true). In questo caso, viene abilitato un job verify in ogni fase.

  • PREDEPLOY_ACTION

    È lo stesso di ACTION_NAME che hai usato in skaffold.yaml per definire l'azione personalizzata da eseguire prima durante il deployment.

  • POSTDEPLOY_ACTION

    È lo stesso di ACTION_NAME che hai usato in skaffold.yaml per definire l'azione personalizzata dopo la quale vuoi eseguire l'azione durante il deployment.

Cloud Run

Nella fase della pipeline, includi una proprietà strategy, come segue:

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          cloudRun:
            automaticTrafficControl: true
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false
          predeploy:
            actions: "PREDEPLOY_ACTION"
          postdeploy:
            actions: "POSTDEPLOY_ACTION"

In questa configurazione...

  • PERCENTAGES è un elenco di percentuali separato da virgole valori che rappresentano gli incrementi canary, ad esempio [25, 50, 75]. Nota che non include 100, perché il deployment al 100% è assunto nella versione canary e viene gestito dal stable fase.

  • Puoi abilitare la verifica del deployment (verify: true). In questo caso, viene aggiunto un job verify a ogni la fase canary.

  • PREDEPLOY_ACTION

    È uguale a ACTION_NAME che hai utilizzato in skaffold.yaml per definire l'azione personalizzata da eseguire prima del deployment.

  • POSTDEPLOY_ACTION

    È uguale a ACTION_NAME che hai utilizzato in skaffold.yaml per definire l'azione personalizzata da eseguire dopo il deployment.

Configura una versione canary personalizzata

Puoi configurare la versione canary manualmente invece di affidarti completamente alla l'automazione fornita da Cloud Deploy. Con canary personalizzato devi specificare quanto segue nella definizione della pipeline di distribuzione:

  • Nomi delle fasi di implementazione

    In una versione canary completamente automatizzata, Cloud Deploy denomina le fasi per te (canary-25, canary-75, stable, ad esempio). Con una versione canary personalizzata, tuttavia, puoi assegnare un nome a ogni fase, purché sia univoco tra tutte per questa fase canary e celebra restrizioni relative ai nomi delle risorse. Ma l'ultimo (100%) il nome della fase deve essere stable.

  • Obiettivi percentuali per ogni fase

    Specifica le percentuali separatamente, per fase.

  • Profili Skaffold da utilizzare per la fase

    Puoi utilizzare un profilo Skaffold separato per ogni fase oppure lo stesso profilo, o qualsiasi combinazione di questi ultimi. Inoltre, ogni profilo può utilizzare un manifest Kubernetes o una definizione di servizio Cloud Run diversi. Puoi anche utilizzare più di un profilo per una determinata fase. Cloud Deploy li combina.

  • Indica se esiste un job di verifica per la fase

    Ricorda che se attivi la verifica, devi anche configurare il tuo skaffold.yaml per la verifica.

  • Indica se sono presenti job di pre-deployment o post-deployment per la fase

    Se stai abilitando job di pre-deployment, devi configurare skaffold.yaml per questi job.

Tutti i tipi di target sono supportati per il canary personalizzato.

Elementi di configurazione canary personalizzati

Il seguente codice YAML mostra la configurazione per le fasi del deployment canary completamente personalizzato:

strategy:
  canary:
    # Custom configuration for each canary phase
    customCanaryDeployment:
      phaseConfigs:
      - phaseId: "PHASE1_NAME"
        percentage: PERCENTAGE1
        profiles: [ "PROFILE_NAME" ]
        verify: true | false
        predeploy:
          actions: "PREDEPLOY_ACTION"
        postdeploy:
          actions: "POSTDEPLOY_ACTION"
      - …
      - phaseId: "stable"
        percentage: 100
        profiles: [ "LAST_PROFILE_NAME" ]
        verify: true|false
        predeploy:
          actions: "PREDEPLOY_ACTION"
        postdeploy:
          actions: "POSTDEPLOY_ACTION"

In questo file YAML

  • PHASE1_NAME

    È il nome della fase. Ogni nome di fase deve essere univoco.

  • [ "PROFILE_NAME" ]

    È il nome del profilo da utilizzare per la fase. Puoi usare lo stesso profilo per ogni fase, uno diverso per ciascuna o qualsiasi combinazione. Inoltre, puoi specificare più di un profilo. Cloud Deploy utilizza tutte le profili specificati, più il profilo o il file manifest utilizzato dall'inserzionista durante la fase di sviluppo.

  • stable

    La fase finale deve essere denominata stable.

  • PERCENTAGE1

    È la percentuale da eseguire per la prima fase. Ogni fase deve avere un unico percentuale e tale valore deve essere una percentuale intera (non 10.5, esempio) e le fasi devono essere in ordine crescente.

  • verify: true|false

    Indica a Cloud Deploy se includere un job di verifica per la fase. Tieni presente che per ogni fase da utilizzare nella verifica, Skaffold utilizza lo stesso profilo per e verificare che sia specificato per il rendering e il deployment per quella fase.

  • PREDEPLOY_ACTION

    È lo stesso di ACTION_NAME che hai usato in skaffold.yaml per definire l'azione personalizzata da eseguire prima del deployment.

  • POSTDEPLOY_ACTION

    È lo stesso di ACTION_NAME che hai usato in skaffold.yaml per definire l'azione personalizzata da eseguire dopo il deployment.

La percentuale per l'ultima fase deve essere 100. Le fasi vengono eseguite in base all'ordine in cui le configuri in questa stanza ​customCanaryDeployment, ma se i valori percentuali non sono in ordine crescente, il comando per registrare la pipeline di importazione non va a buon fine e viene visualizzato un errore.

Tieni presente che la configurazione di una versione canary personalizzata non include runtimeConfig stanza. Se includi runtimeConfig, è considerato un canary con automazione personalizzata.

Configura una versione canary automatizzata personalizzata

Una versione canary automatizzata personalizzata è simile a una canary personalizzata perché specifichi le fasi canary separate, con i nomi delle fasi personalizzate, percentuali, profili Skaffold, verifica dei job e pre-deployment di lavoro. Con una versione canary personalizzata, non fornisci configurazioni che definiscono la distribuzione del traffico: ma continui a fornire Profili Skaffold da usare per ogni fase.

Per configurare una versione canary automatizzata personalizzata, includi una stanza runtimeConfig, come come mostrato qui, e includi la stanza customCanaryDeployment, come mostrato qui.

Configurare un deployment canary utilizzando il mesh di servizi dell'API Kubernetes Gateway

Sebbene sia possibile usare un deployment canary di Cloud Deploy eseguire il deployment della tua applicazione nel networking basato sui servizi Kubernetes, In alternativa, puoi utilizzare il mesh di servizi dell'API Gateway di Kubernetes. In questa sezione viene descritto come fare.

Puoi utilizzare l'API Gateway con Istio o qualsiasi implementazione supportata.

  1. Configura le risorse dell'API Gateway:

    Si tratta unicamente di esempi.

  2. Nel manifest Kubernetes, fornito a Cloud Deploy al momento creato la release, includi quanto segue:

    • Un HTTPRoute che fa riferimento alla risorsa Gateway

    • Un deployment

    • Un servizio

  3. Configura la pipeline di distribuzione e il target di cui eseguirai il deployment canary a:

    • La configurazione del target è la stessa di qualsiasi target.

    • La configurazione della pipeline di distribuzione, nella sequenza di avanzamento per target specifico, include una stanza gatewayServiceMesh per fare riferimento al alla configurazione HTTPRoute dell'API Gateway di Kubernetes, nonché al tuo deployment e il Servizio.

      strategy:
 canary:
   runtimeConfig:
     kubernetes:
       gatewayServiceMesh:
         httpRoute: "ROUTE"
         service: "SERVICE"
         deployment: "DEPLOYMENT"
         routeUpdateWaitTime: "WAIT_TIME"
         podSelectorLabel: "LABEL"
   canaryDeployment:
     percentages:
     - 50

      Dove...

      • ROUTE è la configurazione httpRoute che definisce il routing il comportamento desiderato.

      • SERVICE è la configurazione del tuo servizio, Cloud Deploy richiede per i deployment canary GKE e GKE Enterprise.

      • DEPLOYMENT è la tua configurazione di deployment, Cloud Deploy richiede per i deployment canary GKE e GKE Enterprise.

      • WAIT_TIME è il tempo necessario a Cloud Deploy per attendi che venga completata la propagazione delle modifiche alla risorsa HTTPRoute, per per evitare la perdita di richieste. Ad esempio: routeUpdateWaitTime: 60s.

        Se esegui il canary utilizzando l'API Gateway senza Istio e l'API Gateway è collegata a un bilanciatore del carico Google Cloud, una piccola quantità di traffico potrebbe andare persa quando l'istanza canary viene ridotta. Puoi configura questa impostazione se noti questo comportamento.

      • LABEL è un'etichetta del selettore pod. Deve corrispondere all'etichetta selettore nel servizio e nel deployment Kubernetes definiti nel manifest. Questa opzione è facoltativa. Il valore predefinito è app.

Usa il deployment parallelo con una strategia di deployment canary

Puoi eseguire un deployment canary utilizzando il deployment parallelo. Ciò significa che il target in cui esegui progressivamente il deployment può comprendere due o più target secondari. Ad esempio, puoi eseguire il deployment progressivamente in cluster in contemporaneamente in più regioni.

Qual è la differenza tra una versione canary parallela e una canary a target singolo?

  • Come per il deployment canary con un solo target, se esegui il deployment in destinazioni GKE, devi disporre di una configurazione di deployment Kubernetes e di una configurazione di servizio Kubernetes nel manifest.

  • Come per il deployment canary a target singolo, la configurazione della pipeline di distribuzione deve includere una stanza strategy.canary nella definizione di stage per fase applicabile.

  • Inoltre, devi configurare un target multiplo, e devi configurare le destinazioni figlio a cui fa riferimento il target multiplo.

  • Quando crei una release, viene eseguita un'implementazione del controller e le implementazioni figlio.

    Entrambi i tipi di implementazione (controller e secondario) prevedono fasi distinte per tutte le percentuali canary configurate e una fase stable per canary 100%.

  • Non puoi avanzare un'implementazione figlio.

    Puoi avanzare solo le implementazioni dei controller. Quando fai un passo avanti rispetto al controller alla fase successiva, anche le implementazioni secondarie sono avanzate, con Cloud Deploy.

  • Non puoi riprovare di job non riusciti nell'implementazione del controller.

    Puoi riprovare un job solo nelle implementazioni figlio.

  • Non puoi ignorare di job non riusciti nell'implementazione del controller.

    Puoi ignorare i job non riusciti solo nelle implementazioni figlio.

  • Puoi annullare l'implementazione di un controller, ma non puoi annullare le implementazioni figlio.

  • Puoi terminare le esecuzioni del job solo nell'ambito di un'implementazione figlio, non di un'implementazione controller.

Cosa fare se un'implementazione parallela non va a buon fine nella versione canary

Quando un'implementazione secondaria non va a buon fine, l'implementazione del controller può passare a stati diversi, a seconda di cosa succede con le implementazioni secondarie:

  • Se una o più implementazioni secondarie non vanno a buon fine, ma almeno un'implementazione figlio è ancora IN_PROGRESS, l'implementazione del controller rimane IN_PROGRESS.

  • Se una o più implementazioni secondarie non vanno a buon fine, ma almeno una di loro va a buon fine, l'implementazione del controller è HALTED se sono presenti più fasi dopo quella attuale uno.

    Se è la fase stable, l'implementazione del controller è FAILED.

    HALTED ti offre la possibilità di ignora, riprova job non riusciti nell'implementazione figlio non riuscita; annulla l'implementazione del controller e impedire ulteriori azioni sulle implementazioni figlio.

  • Se l'implementazione del controller è in stato HALTED a causa di un errore figlio rollout e ignori il job non riuscito nell'implementazione figlio, l'implementazione torna allo stato IN_PROGRESS.

Esegui la versione canary configurata

Per eseguire il deployment canary:

  1. Registra la pipeline di distribuzione e i target configurati.

    gcloud deploy apply --file=PIPELINE

    La pipeline di distribuzione include la configurazione canary automatizzata o personalizzata, per il runtime scelto.

    Questo comando presuppone che le destinazioni siano definite nello stesso file o che altrimenti già registrati. In caso contrario, assicurati di registrare i tuoi obiettivi .

  2. Crea una release:

    gcloud deploy releases create RELEASE_NAME \
                              --delivery-pipeline=PIPELINE_NAME \
                              --region=REGION

    La pipeline di distribuzione identificata da PIPELINE_NAME contiene la configurazione canary automatizzata o personalizzata descritta in documento.

  3. Passa alla versione canary:

    Interfaccia a riga di comando gcloud 

    gcloud deploy rollouts advance ROLLOUT_NAME \
                            --release=RELEASE_NAME \
                            --delivery-pipeline=PIPELINE_NAME \
                            --region=REGION

    Dove:

    ROLLOUT_NAME è il nome dell'implementazione attuale che stai percorrendo alla fase successiva.

    RELEASE_NAME è il nome della release che di cui fa parte questa implementazione.

    PIPELINE_NAME è il nome della consegna che stai utilizzando per gestire il deployment di questa release.

    REGION è il nome della regione in cui è stata creata la release, ad esempio us-central1. Campo obbligatorio.

    Per ulteriori informazioni sul comando gcloud deploy rollouts advance, consulta la documentazione di riferimento di Google Cloud SDK.

    Console Google Cloud

    1. Apri la consegna del flusso di lavoro.

    2. Fai clic sulla pipeline visualizzata nell'elenco delle pipeline di distribuzione.

      La pagina Dettagli pipeline di distribuzione mostra una rappresentazione grafica l'avanzamento della pipeline di distribuzione.

    3. Nella scheda Implementazioni, nella sezione Dettagli pipeline di distribuzione, fai clic su il nome della tua implementazione.

      Viene visualizzata la pagina dei dettagli dell'implementazione.

      dettagli dell'implementazione nella console Google Cloud

      In questo esempio, l'implementazione ha una fase canary-50 e una stable fase. L'implementazione può avere più fasi o diverse diverse.

    4. Fai clic su Avanza implementazione.

      L'implementazione passa alla fase successiva.

Fasi ignorate

Se esegui il deployment di una versione canary e la tua applicazione non è ancora stata dispiata in quel runtime, Cloud Deploy salta la fase canary ed esegue la fase stabile. Consulta la sezione Saltare le fasi la prima volta per scoprire il motivo.

Passaggi successivi