Gestione delle pipeline di distribuzione

Una pipeline di distribuzione contiene i requisiti che devono essere soddisfatti per consegnare un set di artifact all'ambiente di destinazione.

Le pipeline di distribuzione contengono fasi diverse per la distribuzione automatica. Ogni fase è associata a determinate azioni nella pipeline. È possibile eseguire la pipeline di distribuzione in base a una delle strategie di release riportate di seguito.

• Strategia blu-verde: implica l'esecuzione di due ambienti di produzione identici, blu e verde, per ridurre i tempi di inattività e i rischi. Solo uno degli ambienti è attivo in un dato momento, con l'ambiente attivo che esegue il traffico di produzione. Ad esempio, se il blu è attivo (produzione), il verde è in standby (stadio) e viceversa. L'ambiente attivo passa dagli ambienti blu a quelli verdi durante le distribuzioni successive. Durante la distribuzione di una nuova versione dell'applicazione, il test della nuova versione viene eseguito nell'ambiente in standby (verde). Se il test riesce, il traffico viene spostato dall'ambiente attivo (blu) all'ambiente in standby. La versione convalidata del software è stata distribuita correttamente e ora l'ambiente verde diventa attivo e il blu è in standby. La strategia di implementazione Blue-Green riduce notevolmente i tempi di inattività in un modello di distribuzione continua poiché la convalida delle nuove release viene eseguita in ambienti in standby senza influire sull'ambiente di produzione corrente. Inoltre, questa strategia riduce il rischio di errori durante la distribuzione, in quanto è possibile eseguire il rollback alla versione precedente riuscita semplicemente spostando il traffico di produzione.
• Strategia canary: implica il rilascio iniziale della nuova versione del software nell'ambiente canary. Dopo aver convalidato correttamente la release, il software viene rilasciato nell'ambiente di produzione. Questa strategia, come il blu-verde, riduce i tempi di inattività e i rischi legati all'implementazione. Se la release iniziale non riesce, ciò non ha alcun impatto sull'ambiente di produzione. Solo le release approvate e di successo vengono portate in produzione.
• Strategia ricorrente: una nuova versione viene distribuita in modo incrementale nell'ambiente di destinazione aggiornando un set di host alla volta. L'aggiornamento viene convalidato prima di aggiornare il successivo set di host. Questo processo viene ripetuto fino al completamento del rollout della nuova versione.

Gli artifact possono essere modificabili o immutabili. Nel Registro artifact è possibile sostituire un artifact modificabile. A tale scopo, caricare un artifact in un repository modificabile e assegnargli il nome di un artifact eliminato oppure, se esiste un artifact con lo stesso nome, il nuovo artifact elimina e sostituisce quello precedente. La pipeline di distribuzione DevOps recupera gli artifact in base al percorso e alla versione dell'artifact. Per gli artifact modificabili, questo può essere l'artifact più recente trovato nel repository.

Una fase è un'azione nella pipeline di distribuzione. Il servizio DevOps include fasi predefinite, che possono essere facilmente utilizzate in una pipeline di distribuzione. Le funzioni e le formule non supportate sono descritte di seguito:

• Distribuisci in un cluster Kubernetes: utilizza la strategia di aggiornamento in sequenza di Kubernetes predefinita.
• Distribuisci in un gruppo di istanze: rilascia l'aggiornamento in modo incrementale al gruppo di istanze. È possibile specificare il numero massimo di istanze che possono essere offline contemporaneamente. Questo tipo supporta i rollback automatici.
• Distribuisci in base alla strategia blu-verde: utilizza la strategia di rilascio blu-verde per Container Engine for Kubernetes (OKE) e la distribuzione del gruppo di istanze.
• Distribuisci in base alla strategia Canary: utilizza la strategia di rilascio canary per la distribuzione OKE e del gruppo di istanze.
• Distribuisci in funzioni: utilizza la strategia di aggiornamento delle funzioni predefinite.
• Distribuzione di un grafico Helm: installare i grafici Helm nel cluster OKE.
• Controllo:
  • Approvazione: sospendere la distribuzione e attendere una decisione manuale.
  • Traffic Shift: instrada il traffico tra due ambienti.
  • Attendi: sospende la distribuzione per una determinata durata.
• Integrazioni:
  • Richiama funzione: richiama una funzione per eseguire la logica personalizzata.
  • Shell: esegue i passi personalizzati definiti nella specifica dei comandi nella pipeline di distribuzione.

È possibile aggiungere più fasi a una pipeline. Le fasi possono essere aggiunte in sequenza o in parallelo. È possibile rimuovere qualsiasi fase dalla pipeline. Al termine, la fase e le relative risorse associate vengono eliminate.