Comprendere le strategie di distribuzione

Le architetture descritte in questo articolo illustrano come creare e distribuire un'applicazione moderna con strategie di implementazione Blue-Green e Canary. Le strategie di distribuzione sono modelli e procedure che consentono la modifica o l'aggiornamento dell'applicazione. Le strategie di distribuzione consentono ai team DevOps di definire il modo in cui le applicazioni vengono distribuite nell'ambiente di produzione.

La scelta tra strategie di implementazione diverse consente agli amministratori di fare il giusto compromesso tra il rischio di distribuire una nuova release, l'impatto della nuova release sugli utenti e il sovraccarico dell'infrastruttura necessario per implementare la strategia. Vogliamo offrire ai nostri clienti più opzioni per fare il giusto compromesso in base alle loro esigenze applicative.

Informazioni sulle distribuzioni blu-verde

Con una strategia di implementazione Blue-Green, i team di DevOps desiderano rilasciare una nuova versione dell'applicazione utilizzando due ambienti identici in cui uno di essi è attivo in un dato momento. Viene eseguito il provisioning della versione corrente dell'applicazione nell'ambiente attivo, mentre la nuova versione viene distribuita nell'ambiente in standby.

La distribuzione nell'ambiente in standby non ha alcun impatto sull'ambiente attivo o sul traffico utente. La pipeline di release DevOps può eseguire test di convalida sulla nuova versione e, una volta approvata, viene promossa alla produzione semplicemente passando il traffico utente all'ambiente in standby. Questo processo verrà ripetuto per ogni nuova release dell'applicazione.

Il vantaggio principale di questa strategia è che offre tempi di inattività quasi nulli e funzionalità di rollback istantaneo. In caso di problemi con la nuova versione, il traffico può ripristinare immediatamente la versione stabile precedente. Inoltre, l'ambiente in standby è disponibile per il debug degli errori che si sono verificati nella release dell'applicazione.

Questo diagramma illustra un'architettura di implementazione Blue-Green:

Descrizione dell'immagine blue-green-deployment.png

Comprendere i componenti di distribuzione blu-verde

Di seguito sono riportati i componenti dell'architettura precedente.

• Area

  Un'area geografica OCI è un'area geografica localizzata che contiene uno o più data center, denominati domini di disponibilità. Le regioni sono indipendenti da altre regioni e le grandi distanze possono separarle (tra paesi o addirittura continenti). L'architettura utilizza una singola area.

• Progetto DevOps

  Raggruppamento logico delle risorse DevOps necessarie per implementare un flusso di lavoro di integrazione e distribuzione continue. Le risorse DevOps possono essere artifact, pipeline di build, pipeline di distribuzione, connessioni esterne, trigger e ambienti. I progetti DevOps semplificano la registrazione, il monitoraggio e le notifiche di tutte le risorse DevOps.

• Pipeline di build

  Una pipeline di build accetta un ID commit dai repository di codici sorgente e utilizza tale codice per eseguire le istruzioni sulla build. Le pipeline di build definiscono un set di fasi per il processo di build: creazione, test e compilazione di artifact software, consegna di artifact ai repository OCI e attivazione facoltativa di una distribuzione. Il flusso e le istruzioni per l'esecuzione della build vengono definite nel file delle specifiche di build.

• Crea fasi

  Le fasi sono singole azioni che si svolgono durante un'esecuzione di una pipeline. Le varie fasi di build menzionate qui sono: Fasi build gestite: una fase di build gestita per creare e sottoporre a test il codice di origine. Fase di consegna artifact: fase per eseguire il PUSH degli output della fase di creazione in vari repository. Come copiare le immagini dei container nel repository dei container e nel file manifest di distribuzione nel registro artifact. Richiama distribuzione: una fase per richiamare una pipeline di distribuzione una volta completate le fasi di creazione, insieme all'analisi delle variabili esportate dalla fase di build gestita alle fasi della pipeline di distribuzione.

• Repository codice

  Repository Git privati ospitati dal servizio DevOps. Puoi memorizzare, gestire e sviluppare il codice sorgente con i nostri repository di codici DevOps. Pipeline di distribuzione Una sequenza di passi per la distribuzione e la distribuzione di un set di artifact in un ambiente di destinazione. Il flusso e la logica della release software possono essere controllati definendo fasi eseguibili in serie o parallele.

• Fasi di distribuzione

  Le fasi sono singole azioni che vengono eseguite durante un'esecuzione di una pipeline. Di seguito sono riportate alcune fasi di costruzione:

  • Distribuzione blu/verde di OKE o Distribuzione del gruppo di istanze blu/verde: area intermedia per distribuire il codice aggiornato negli ambienti di destinazione.
  • Convalida distribuzione: fase facoltativa per convalidare le distribuzioni (tramite le funzioni)
  • Controllo: approvazione: fase di controllo per approvare la distribuzione nell'ambiente di produzione di destinazione.
  • Spostamento del traffico OKE blu/verde o Spostamento del traffico del gruppo di istanze blu/verde: fase finale in cui il traffico di produzione verrà passato all'ambiente di distribuzione più recente.

• Artifact DevOps

  Un artifact DevOps è un riferimento o un puntatore a qualsiasi file, file binario, package, file manifesto o immagine che costituisce l'applicazione. Quando si crea un artifact, informare Oracle DevOps della posizione di origine dell'artifact effettivo. DevOps supporta il registro delle immagini del contenitore OCI e i repository del registro degli artifact OCI.

• Repository artifact

  Il repository di artifact crea repository per raggruppare artifact simili. Quando viene creato il repository, è possibile caricarvi gli artifact. Questi artifact sono una raccolta di file di testo, file binari e file manifest di distribuzione forniti nell'ambiente di distribuzione di destinazione. Ogni artifact ha un nome, che è fatto del percorso: versione. Il percorso è una stringa per organizzare gli artifact.

• Servizi di registrazione e notifica OCI

  Il servizio di log OCI memorizza i log correlati alla distribuzione. L'output di runtime della distribuzione e i risultati finali della distribuzione vengono visualizzati come voci di log. Il servizio di notifiche OCI offre visibilità sullo stato più recente del progetto di distribuzione e delle relative risorse e intraprende le azioni necessarie. Ad esempio, si riceve una notifica quando un evento importante, ad esempio una fase di una pipeline di distribuzione in attesa di approvazione. Quando si riceve il messaggio di notifica, è possibile passare alle pipeline di distribuzione DevOps e approvare la fase.

• Ambienti di distribuzione

  Un ambiente è una raccolta di risorse di calcolo di un cliente in cui vengono distribuiti gli artifact. Gli ambienti possono essere una funzione, una virtual machine (VM) di computazione o un'istanza Bare Metal o un cluster OKE. La distribuzione Blue Green è disponibile solo con i cluster OKE e le virtual machine di computazione.

Comprendi i vantaggi e il consenso delle implementazioni Blue-Green

Quando si distribuisce un'applicazione moderna, sono presenti sia pro che contro per utilizzare una strategia Blue-Green.

I vantaggi delle implementazioni Blue-Green sono:

• Le implementazioni Blue Green consentono implementazioni rapide e prive di rischi.
• Vengono attivati con un meccanismo di rollback semplice ed efficace.
• Un modo efficace per orchestrare i test del software A/B.
• Nessun tempo di inattività o quasi zero in quanto la produzione viene sempre gestita tramite uno degli ambienti attivi (indicare un load balancer).

I vantaggi delle implementazioni Blue-Green sono:

• Mantenere l'ambiente di una distribuzione Blue-Green richiede costi elevati per ambienti e risorse identici.
• Per gestire la release tra due ambienti identici, è necessario monitorare da vicino entrambi gli ambienti.
• La gestione delle dipendenze del database tra le distribuzioni è complessa.

Informazioni sulle distribuzioni canarie

Con una strategia di distribuzione Canary, la release dell'applicazione viene eseguita in modo incrementale in un subset di utenti. Inizialmente, la nuova versione viene distribuita in un ambiente canary senza traffico utente. La pipeline di release DevOps può eseguire test di convalida sulla nuova versione e, una volta pronto, instradare solo un subset di utenti all'ambiente canary.

Questa tecnica consente al team DevOps di valutare la nuova versione dell'applicazione rispetto al traffico utente reale. Possono confrontare le due versioni delle applicazioni affiancate prima di eseguire il rollback della nuova versione a una base utenti più grande. Inoltre, offre la mitigazione dei rischi poiché la nuova versione è abilitata solo per un piccolo sottoinsieme di utenti: questi utenti possono facilmente tornare alla versione precedente in caso di problemi.

Il diagramma riportato di seguito illustra una strategia di distribuzione Canaria.

Descrizione dell'immagine canary-deployment.png

Comprendere i componenti di distribuzione Canarie

Di seguito sono riportati i componenti dell'architettura precedente.

• Area

  Un'area geografica OCI è un'area geografica localizzata che contiene uno o più data center, denominati domini di disponibilità. Le regioni sono indipendenti da altre regioni e le grandi distanze possono separarle (tra paesi o addirittura continenti). L'architettura utilizza una singola area.

• Progetto DevOps

  Raggruppamento logico delle risorse DevOps necessarie per implementare un flusso di lavoro di integrazione e distribuzione continue. Le risorse DevOps possono essere artifact, pipeline di build, pipeline di distribuzione, connessioni esterne, trigger e ambienti. I progetti DevOps semplificano la registrazione, il monitoraggio e le notifiche di tutte le risorse DevOps.

• Pipeline di build

  Una pipeline di build accetta un ID commit dai repository di codici sorgente e utilizza tale codice per eseguire le istruzioni sulla build. Le pipeline di build definiscono un set di fasi per il processo di build: creazione, test e compilazione di artifact software, consegna di artifact ai repository OCI e attivazione facoltativa di una distribuzione. Il flusso e le istruzioni per l'esecuzione della build vengono definite nel file delle specifiche di build.

• Crea fasi

  Le fasi sono singole azioni che vengono eseguite durante un'esecuzione di una pipeline. Di seguito sono riportate diverse fasi di creazione.

  • Fasi build gestite: fase di build gestita per creare e sottoporre a test il codice di origine.
  • Fase di consegna artifact: fase per eseguire il push degli output della fase di build in vari repository. Copia con copia le immagini container nel repository container e nel file manifest di distribuzione nel registro artifact.
  • Richiama distribuzione: una fase per richiamare una pipeline di distribuzione una volta completate le fasi di build, nonché per analizzare le variabili esportate dalla fase di build gestita alle fasi della pipeline di distribuzione.

• Repository codice

  Repository Git privati ospitati dal servizio DevOps. Puoi memorizzare, gestire e sviluppare il codice sorgente con i nostri repository di codici DevOps.

• Pipeline di distribuzione

  Sequenza di passi per la distribuzione e la distribuzione di un set di artifact in un ambiente di destinazione. Il flusso e la logica della release software possono essere controllati definendo fasi eseguibili in serie o parallele.

• Fasi di distribuzione

  Le fasi sono singole azioni che vengono eseguite durante un'esecuzione di una pipeline. Di seguito sono riportate alcune fasi di costruzione:

  • Distribuzione canaria OKE o Distribuzione gruppo di istanze canarie: area intermedia per distribuire il codice aggiornato negli ambienti canary di destinazione.
  • Convalida distribuzione: fase facoltativa per convalidare le distribuzioni (tramite le funzioni)
  • Maiusc del traffico OKE canaria o Maiusc del traffico gruppo di istanze canarie: fase per passare al traffico verso l'ambiente canarino in base al limite di rampa (% del traffico da spostare).
  • Controllo: approvazione: fase di controllo per approvare la distribuzione nell'ambiente di produzione di destinazione.
  • Produzione gruppo di istanze distribuzione canaria o Produzione distribuzione OKE: fase finale in cui il traffico di produzione verrà passato all'ambiente distribuito più recente.

• Artifact DevOps

  Un artifact DevOps è un riferimento o un puntatore a qualsiasi file, file binario, package, file manifesto o immagine che costituisce l'applicazione. Quando si crea un artifact, informare Oracle DevOps della posizione di origine dell'artifact effettivo. DevOps supporta il registro delle immagini del contenitore OCI e i repository del registro degli artifact OCI.

• Repository artifact

  Il repository di artifact crea repository per raggruppare artifact simili. Quando viene creato il repository, è possibile caricarvi gli artifact. Questi artifact sono una raccolta di file di testo, file binari e file manifest di distribuzione forniti nell'ambiente di distribuzione di destinazione. Ogni artifact ha un nome, che è fatto del percorso: versione. Il percorso è una stringa per organizzare gli artifact.

• Servizi di registrazione e notifica OCI

  Il servizio di log OCI memorizza i log correlati alla distribuzione. L'output di runtime della distribuzione e i risultati finali della distribuzione vengono visualizzati come voci di log. Il servizio di notifiche OCI offre visibilità sullo stato più recente del progetto di distribuzione e delle relative risorse e intraprende le azioni necessarie. Ad esempio, si riceve una notifica quando un evento importante, ad esempio una fase di una pipeline di distribuzione in attesa di approvazione. Quando si riceve il messaggio di notifica, è possibile passare alle pipeline di distribuzione DevOps e approvare la fase.

• Ambienti di distribuzione

  Un ambiente è una raccolta di risorse di calcolo di un cliente in cui vengono distribuiti gli artifact. Gli ambienti possono essere una funzione, una virtual machine (VM) di computazione o un'istanza Bare Metal o un cluster OKE. La distribuzione Blue Green è disponibile solo con i cluster OKE e le virtual machine di computazione.

Comprendere i vantaggi e il consenso delle distribuzioni Canarie

Esistono entrambi i pro e contro per usare una strategia Canaria durante la distribuzione di un'applicazione moderna.

I professionisti delle implementazioni Canarie sono:

• Consente di testare due versioni dell'applicazione affiancate a utenti reali.
• Nessun tempo di inattività per la nuova release della versione.
• Il rollback a una versione precedente è molto semplice e offre il minor rischio.

I consensi delle implementazioni Canarie sono:

• Le procedure di test e convalida delle nuove release potrebbero essere complesse su larga scala.
• Il recupero del feedback dal test degli utenti in una nuova release richiede molto tempo.