Gestire le implementazioni

Un rollout di Cloud Deploy include fasi. Una fase è un raggruppamento logico ordinato di job da eseguire in un rollout.

Ogni fase include i job, ovvero le azioni da intraprendere in ogni fase (ad esempio, deploy o verify). Ogni job può avere zero o più esecuzioni. L'esecuzione di un job è un'istanza di un job. Se il job non è stato eseguito, non sono presenti esecuzioni del job.

Questo documento descrive fasi, job e esecuzioni di job e come gestirli.

Struttura di un'implementazione

Un'implementazione è una risorsa Cloud Deploy che associa una release a un target.

Fasi

Un rollout è composto da una o più fasi.

Per una strategia di implementazione standard, esiste una sola fase: stable.

Per una strategia di deployment canary, esiste una fase separata per ogni percentuale configurata. Ad esempio, se configuri un canary che esegue il deployment del 25%, poi del 50% e infine del 100%, ci saranno tre fasi:

• canary-25
• canary-50
• stable

Questi nomi di fase sono standard: canary-[PERCENTAGE] per le fasi canary e stable per la fase al 100%. Tuttavia, se configuri un canary automatizzato personalizzato o un canary personalizzato, puoi controllare i nomi delle fasi.

Job ed esecuzioni job

Ogni fase di implementazione include uno o più job.

Per un rollout in una strategia di deployment standard, senza verifica del deployment abilitata, è presente una fase (stable).

Per un'implementazione canary, ci sarà una fase per ogni parte del canary (ad esempio, canary-25, canary-50, stable) e per ogni fase è presente un job deploy. Se la verifica è attivata, è presente anche un job verify per ogni fase.

L'esecuzione di un job è un'istanza di un job. Ad esempio, viene eseguita un'esecuzione di job per un job deploy e, se ha esito positivo, non viene eseguita un'ulteriore esecuzione di job per quel job. Se non va a buon fine, può essere riprovato come un'altra esecuzione del job.

Saltare le fasi la prima volta

Alcune strategie di deployment (ad esempio, canary) ripartiscono il traffico tra le versioni vecchia e nuova. Se esegui il deployment su una destinazione per la prima volta, non esiste una versione precedente, quindi non possiamo ripartire il traffico.

Per questo motivo, quando esegui il deployment di una versione canary per la prima volta, saltiamo la fase o le fasi canary ed eseguiamo la fase stable. Dopodiché, l'applicazione viene implementata e i futuri deployment canary includeranno le fasi canary.

In una situazione reale, in genere esegui un deployment canary in cui l'applicazione è già in esecuzione, quindi questo salto di fase sarà raro.

Stati all'interno di un'implementazione

I rollout, le fasi, i job e le esecuzioni dei job hanno tutti degli stati. Questa sezione descrive gli stati di ciascuno.

Stati di implementazione

Un lancio avrà uno dei seguenti stati:

• APPROVAL_REJECTED

  L'implementazione richiedeva l'approvazione, ma l'approvazione è stata rifiutata.

• CANCELLED

  Lo stato finale per i rollout che sono stati annullati da un utente.

• CANCELLING

  Un utente ha annullato l'implementazione, ma l'annullamento non è stato completato.

• HALTED

  In un deployment parallelo, se una o più implementazioni secondarie non riescono, ma almeno una implementazione secondaria ha esito positivo, l'implementazione del controller viene INTERROTTA se sono presenti altre fasi dopo quella attuale.

  Puoi riprendere l'implementazione interrotta di un controller in uno dei seguenti modi:

  • Annulla l'implementazione del controller

  • Riprova o ignora gli eventuali job non riusciti nelle implementazioni secondarie

• IN_PROGRESS

  È in corso l'elaborazione di un'esecuzione del job.

• FAILED

  Un job non è andato a buon fine e l'utente non ha scelto di ignorare l'errore.

• PENDING

  L'implementazione non è ancora iniziata. Questo stato passa a IN_PROGRESS o CANCELED.

• PENDING_APPROVAL

  L'implementazione richiede l'approvazione, ma non è ancora stata approvata.

• PENDING_RELEASE

  L'implementazione è in attesa del rendering della release.

• SUCCEEDED

  L'implementazione è stata completata senza errori.

Stati delle fasi

Una fase avrà uno dei seguenti stati:

• PENDING

  La fase è in attesa del completamento di un'altra fase dell'implementazione.

• IN_PROGRESS

  La fase è iniziata.

• SUCCEEDED

  La fase è stata completata correttamente.

• FAILED

  Un job nella fase non è andato a buon fine e l'utente non ha scelto di ignorare l'errore.

• ABORTED

  Una fase precedente non è riuscita.

• SKIPPED

  Quando esegui una strategia di deployment, ad esempio una canary, Cloud Deploy passa alla fase stable nei casi in cui non è ancora presente una versione in esecuzione dell'applicazione con cui dividere il traffico. In questo caso, lo stato è impostato su SKIPPED.

Stati del job

Un job avrà uno dei seguenti stati:

• ABORTED

  Se una fase non va a buon fine, le fasi successive vengono interrotte.

  Se un job non va a buon fine e l'errore non viene ignorato, i job successivi vengono interrotti. Ad esempio, se una fase include un job di deployment e un job di verifica e il job di deployment non va a buon fine, il job di verifica viene interrotto.

• DISABLED

  Alcuni job in una fase potrebbero essere disattivati. Ad esempio, le fasi includono sempre la verifica dei job, indipendentemente dal fatto che la verifica sia attivata. Se la verifica non è attivata, il job di verifica è impostato su DISABLED.

• FAILED

  L'esecuzione di un job non è riuscita e l'utente non ha scelto di ignorare l'errore.

  L'utente ha scelto di terminare l'esecuzione del job per questo job.

• IGNORED

  L'esecuzione di un job per questo job non è riuscita e l'utente ha scelto di ignorare l'errore.

• IN_PROGRESS

  Al momento è in esecuzione un'esecuzione del job per questo job.

• PENDING

  L'esecuzione del job per questo job è in attesa di iniziare perché un'altra fase o un altro job non è terminato.

• SKIPPED

  Quando esegui una strategia di deployment, ad esempio una canary, Cloud Deploy passa alla fase stable nei casi in cui non è ancora presente una versione in esecuzione dell'applicazione con cui dividere il traffico. In questo caso, lo stato è impostato su SKIPPED per i job all'interno della fase o delle fasi ignorate.

• SUCCEEDED

  L'esecuzione del job è terminata correttamente ed è iniziato il job successivo nella fase, oppure è iniziata la fase successiva o è pronta per iniziare (forse in attesa dell'input dell'utente) o l'implementazione è terminata.

Stati di esecuzione del job

• FAILED

  L'esecuzione del job non è riuscita.

• IN_PROGRESS

  L'esecuzione del job è iniziata, ma non è terminata.

• TERMINATED

  L'utente ha terminato l'esecuzione del job.

• TERMINATING

  L'utente ha terminato l'esecuzione del job, ma la terminazione non è ancora terminata.

• SUCCEEDED

  Quando l'esecuzione di un job termina correttamente, senza errori o interruzioni da parte di un utente, viene inserita nello stato SUCCEEDED, che

Gestire l'implementazione

Utilizzando la Google Cloud console o Google Cloud SDK, puoi eseguire le seguenti operazioni con un rollout di Cloud Deploy:

• Prosegui con l'implementazione

• Annullare l'implementazione

• Terminare l'esecuzione di un job

• Ignorare un job

• Riprovare un job non riuscito

Se utilizzi il deployment parallelo con una strategia di deployment canary, scopri come gestire i rollout canary paralleli.

Avanzare un'implementazione

Per i target configurati per utilizzare una strategia di implementazione diversa da "standard", devi far avanzare l'implementazione da una fase all'altra.

Ad esempio, se hai una destinazione configurata per eseguire un semplice deployment canary con solo le fasi 50% e stable (100%), dovrai avanzare il rollout una volta, dalla fase canary-50 alla fase stable (100%).

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

Annullare un'implementazione

Puoi annullare qualsiasi implementazione non ancora completata. Puoi anche annullare un'implementazione non riuscita per impedire ulteriori azioni (ad esempio ignorare o riprovare). Il lancio deve essere in uno dei seguenti stati:

• FAILED
• HALTED
• IN_PROGRESS
• PENDING
• PENDING_APPROVAL
• PENDING_RELEASE

Una volta annullata un'implementazione, questa si trova nello stato CANCELLING finché non vengono completate tutte le esecuzioni dei job in sospeso. Puoi terminare le esecuzioni dei job in sospeso che non vuoi attendere. Una volta completato l'implementazioneCANCELLED, non può più essere avanzata o modificata.

Per annullare un lancio:

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

Terminare l'esecuzione di un job

Puoi terminare un'esecuzione del job attualmente in corso. Potresti volerlo fare, ad esempio, se l'esecuzione di un job sembra richiedere troppo tempo o non funziona come previsto. L'esecuzione del job deve essere IN_PROGRESS per poter essere terminata.

gcloud deploy job-runs terminate JOB_RUN_ID \
                               --release=RELEASE_NAME \
                               --delivery-pipeline=PIPELINE_NAME \
                               --rollout=ROLLOUT_NAME \
                               --region=REGION

Dopo aver terminato l'esecuzione di un job, questo viene considerato non riuscito e puoi eseguire una delle seguenti operazioni:

• Lascia tutto così e ignora l'implementazione non riuscita
• Riprova il job
• Ignora il job e continua con il job o la fase successiva dell'implementazione.

Ignorare un job

Puoi ignorare un job non riuscito e passare immediatamente al job successivo della fase. Il job potrebbe non essere riuscito per qualsiasi motivo, incluso il fatto che tu o qualcun altro ha terminato un'esecuzione del job.

Un job non riuscito significa una fase non riuscita e un'implementazione non riuscita. Tuttavia, se ignori l'errore, sia la fase sia l'implementazione possono avanzare e possono infine avere stati SUCCEEDED.

gcloud deploy rollouts ignore-job ROLLOUT_NAME \
                               --release=RELEASE_NAME \
                               --delivery-pipeline=PIPELINE_NAME \
                               --job-id=JOB_ID \
                               --phase-id=PHASE_ID \
                               --region=REGION

Riprovare un job non riuscito

Puoi riprovare un'esecuzione del job non riuscita. Il job può non riuscire per uno dei seguenti motivi:

• L'esecuzione di un job non è stata completata.

  Ad esempio, potrebbe essersi verificato un errore di autorizzazione.

• Un utente ha terminato l'esecuzione di un job da quel job.

  L'interruzione di un'esecuzione del job comporta un job non riuscito, che puoi riprovare.

• Un test di verifica non è riuscito.

  Per un job di verifica, un test di verifica non è riuscito. Anche se il job di verifica è stato completato correttamente, uno dei test di verifica non è riuscito e lo propaghiamo di nuovo al job di verifica. In questo caso, riproverai il job nell'ambito del debug del test non riuscito sulla tua applicazione.

Per riprovare un job non riuscito:

gcloud deploy rollouts retry-job JOB_NAME \
                       --release=RELEASE_NAME \
                       --delivery-pipeline=PIPELINE_NAME \
                       --rollout=ROLLOUT_NAME \
                       --phase=PHASE_ID \
                       --region=REGION

Passaggi successivi

• Scopri di più su come funzionano le strategie di deployment in Cloud Deploy.

• Consulta la documentazione sull'architettura del servizio Cloud Deploy per saperne di più su come implementazioni, fasi, job ed esecuzioni di job si integrano con il resto di Cloud Deploy.