Implementarea Blue-Green și rolul său în DevOps explicate

Abordările tradiționale „big bang” ale dezvoltării software sunt incompatibile cu flexibilitatea ridicată, agilitatea și cerințele de implementare continuă ale platformelor software cloud și DevOps de astăzi.

Pur și simplu nu este suficient să pregătiți o listă de verificare cu pașii manuali de executat în timpul implementării versiunii de producție. Dacă faci asta, nu ești cu adevărat agil și nici nu ești un DevOps adecvat.

Implementarea albastru-verde: o prezentare generală

Implementarea Blue-Green este o abordare a implementării software care reduce timpul de nefuncționare și riscul noilor versiuni de software prin crearea a două medii identice: activ (albastru) și inactiv (verde).

Mediul activ este locul în care rulează versiunea curentă a software-ului, iar utilizatorii generează trafic de producție. Mediul inactiv este locul în care noua versiune a software-ului este implementată și testată.

Odată ce noua versiune este testată și gata, traficul este comutat din mediul activ în mediul inactiv, transformându-l în noul mediu activ. Puteți repeta acest proces după cum este necesar.

Sursă: docs.aws.amazon.com

Contextul DevOps

Implementarea Blue-Green se potrivește bine mentalității și proceselor DevOps, deoarece acceptă livrarea și implementarea continuă a software-ului, minimizând în același timp timpul de nefuncționare pentru utilizatorii de producție și eliminând riscul unei eșecuri a lansării în producție.

Averea a două medii identice face posibilă testarea și implementarea de noi versiuni de software fără a afecta mediul de producție actual. Aceasta înseamnă lansări mai rapide și mai frecvente, care este un aspect cheie al DevOps.

În plus, capacitatea de a comuta rapid traficul între medii este o condiție prealabilă principală pentru derularea rapidă în caz de probleme, ceea ce este, de asemenea, important într-un mediu DevOps.

Principiile cheie ale implementării albastru-verde

#1. Două medii identice

Implementarea albastru-verde necesită crearea a două medii identice. Asta înseamnă identic din punct de vedere al datelor și al proceselor. Unul este activ (albastru), iar celălalt este inactiv (verde).

Mediul albastru este locul în care utilizatorii de producție își desfășoară procesele de zi cu zi. Mediul verde este întotdeauna sincronizat cu cel albastru, dar testerii își rulează cazurile de testare acolo. Chiar dacă acest mediu nu este producția, rulați testele în condiții reale, deoarece este un mediu asemănător producției.

#2. Comutator de trafic

Odată ce noua versiune a software-ului este testată și gata, traficul este comutat din mediul activ în mediul inactiv, transformându-l în noul mediu activ.

Comutarea este instantanee. Toată implementarea este acum un lucru din trecut. Nu există o fereastră de oprire. Utilizatorii nu trebuie să facă nimic pentru a ajunge în noul mediu. Sunt redirecționate automat și toate în același timp.

Sursă: aws.amazon.com

#3. Rollback rapid

Abilitatea de a comuta rapid traficul între medii înseamnă, de asemenea, o revenire rapidă în caz de probleme. Acest lucru asigură un timp de nefuncționare minim, iar aplicația rămâne foarte disponibilă.

Dacă ceva nu merge bine cu mediul verde, toți utilizatorii vor reveni instantaneu la mediul albastru inițial stabil, fără niciun fel de fuzz.

#4. Testare automată

Testarea automată este un aspect cheie al implementării Blue-Green. Se asigură că noua versiune a software-ului este testată temeinic înainte de a fi implementată în mediul activ.

Dacă nu aveți o cantitate semnificativă de teste automatizate în sistemele dvs. (inclusiv teste unitare, teste funcționale și teste de regresie cel puțin), atunci probabil că nici măcar nu are sens să vă gândiți la implementarea implementării Blue-Green.

Lipsa testelor automate vă va încetini dramatic. Timpul necesar pentru a testa noul mediu (verde) va fi atât de lung, încât până când veți putea trece la mediul verde, acesta va fi deja „prea vechi” din perspectiva ciclului de viață al dezvoltării software.

#5. Livrare continuă

Implementarea Blue-Green face parte dintr-o conductă de livrare continuă, ceea ce înseamnă în cele din urmă lansări mai rapide și mai frecvente de software în producție.

Puteți face schimbarea de îndată ce sunteți gata să testați noua versiune de software în mediul verde. Deoarece implementarea a fost deja făcută și trebuie să faceți doar schimbarea traficului în sine, este atât de rapid încât puteți face acest lucru în fiecare zi. Presupunând că sunteți rapid și în activitățile de testare, evident.

Ciclul de viață tipic

Platforma care rulează implementarea Blue-Green are propriul ciclu de viață specific de pași și procese de rulat. Din asta constă de obicei:

Creați o nouă versiune a software-ului. Aceasta implică compilarea codului, rularea de teste automate și crearea unui artefact implementabil.

Următoarea etapă este cea în care implementați noua versiune a software-ului în mediul inactiv (verde). Aceasta implică configurarea mediului, implementarea artefactului și configurarea oricăror setări necesare.

Odată ce noua versiune a software-ului este implementată în mediul ecologic, rulați teste automate pentru a vă asigura că noua versiune funcționează corect. Acestea includ teste funcționale, teste de regresie, teste de integrare și, dacă sunteți excepțional, chiar teste de performanță.

Comutați traficul din mediul activ (albastru) în mediul inactiv (verde). Aceasta implică actualizarea echilibrului de încărcare sau a setărilor DNS pentru a direcționa traficul către mediul verde. Desigur, doriți să faceți acest lucru prin procese automate.

Odată ce comutarea este efectuată, monitorizați aplicația pentru a vă asigura că funcționează corect. Aceasta include monitorizarea erorilor, problemelor de performanță și alte probleme.

Acest pas este opțional și nu doriți să ajungeți prea des la el. Dar dacă cineva detectează probleme substanțiale, comutați traficul înapoi în mediul albastru pentru a efectua o derulare instantanee. Din nou, fără nicio întrerupere sau deconectare legată de utilizatorii de producție. Doar actualizați echilibrul de încărcare sau setările DNS pentru a direcționa traficul către mediul albastru.

Odată ce rezolvați aceste probleme și sunteți gata să reveniți la noua versiune din nou, comutați traficul înapoi în mediul verde. Deci, din nou – actualizați echilibrul de încărcare sau setările DNS pentru a direcționa traficul înapoi către mediul verde.

În cele din urmă, odată ce noua versiune a software-ului este stabilă și funcționează corect, scoateți din funcțiune vechea versiune a software-ului care rulează în mediul albastru. Veți avea nevoie de el pentru a construi o altă versiune nouă a sistemului dumneavoastră.

Implementarea conductelor CI/CD

Implementarea implementării Blue-Green într-o conductă DevOps CI/CD va fi un proces natural.

O condiție prealabilă puternică este să aveți deja acele două medii identice. Deoarece acesta va fi un proces automatizat, puteți utiliza infrastructura ca instrument de cod, cum ar fi AWS CloudFormation sau chiar agnostic de nor Terraform scripturi pentru a crea/recrea/actualiza mediile pentru tine în conductele automate.

Odată ce aveți acest lucru, este un pas relativ ușor către crearea unui proces de implementare complet automatizat. Pur și simplu reutilizați conductele deja existente pentru crearea mediului albastru și verde. Cu toate acestea, de data aceasta trebuie să includeți și procesele de testare.

Procesul de comutare a traficului pe care îl puteți automatiza cu instrumente precum AWS Elastic Load Balancer sau NGINX. Aceasta implică actualizarea echilibrului de încărcare sau a setărilor DNS pentru a direcționa traficul către mediul verde odată ce noua versiune a software-ului este testată și gata.

Următoarea piesă a puzzle-ului este monitorizarea. Pentru asta, folosiți instrumente precum AWS CloudWatch, New Relicsau Datadog.

În cele din urmă, reutilizați conductele existente chiar și pentru dezafectarea vechiului mediu albastru. Depinde de dvs. dacă executați mai întâi distrugerea pentru toate serviciile și componentele înainte de a le recrea de la zero sau, alternativ, puteți doar să actualizați scripturile pentru fiecare serviciu din lanț. De obicei, distrugerea și recrearea este o opțiune mai sigură, deoarece cu actualizarea aveți mult mai multe cazuri de colț de luat în considerare.

Cele mai bune practici de implementare Blue-Green

Sunteți curios despre cum să utilizați cât mai bine implementarea Blue-Green? Iată câteva dintre sfaturile care vin din practică.

Aveți o strategie solidă de migrare a bazelor de date

Când implementați o nouă versiune a software-ului, este important să vă asigurați că schema bazei de date este actualizată corect. Utilizați o strategie de migrare a bazei de date, cum ar fi Calea de zbor sau Liquibase pentru a gestiona modificările schemei bazei de date.

Utilizați un instrument de analiză Canary

Chiar dacă implementarea Canary este o abordare alternativă, puteți utiliza totuși unele dintre tehnicile sale pentru a vă perfecționa implementarea Blue-Green.

Utilizați un instrument de analiză canar, cum ar fi Kayenta sau Spinnaker pentru a analiza performanța noii versiuni a software-ului într-un mediu real. Aceasta implică compararea performanței noii versiuni a software-ului cu performanța versiunii vechi a software-ului.

Utilizați un cadru de comutare a funcțiilor, cum ar fi Togglz pentru a activa sau dezactiva funcțiile din noua versiune a software-ului. Acest lucru permite o lansare treptată a noilor funcții și permite derularea rapidă, dacă este necesar.

Utilizați un Load Balancer cu verificări de sănătate

Utilizați un echilibrator de încărcare, cum ar fi AWS Elastic Load Balancer sau NGINX cu verificări de sănătate pentru a vă asigura că traficul este direcționat numai către instanțe sănătoase. Acest lucru asigură că aplicația rămâne foarte disponibilă și că timpul de nefuncționare este minimizat.

Folosiți un plan de rollback cu Rollback automat

Aveți un plan de rollback în vigoare în caz de probleme și automatizați procesul de rollback folosind un instrument precum AWS CodeDeploy sau Octopus Deploy. Acest lucru asigură că timpul de nefuncționare este minimizat și că aplicația rămâne foarte disponibilă.

Acest lucru se aplică mai ales mediului verde ori de câte ori descoperiți o problemă semnificativă cu noua versiune.

Nu aveți nevoie de un plan de rollback pentru mediul albastru, deoarece acesta rămâne neatins de comutator și vă puteți întoarce la acest mediu stabil oricând este necesar și instantaneu.

Provocări cu implementarea albastru-verde

Implementarea implementării Blue-Green poate prezenta unele provocări pentru echipele de dezvoltare. Iată câteva provocări tipice:

Configurarea și gestionarea a două medii identice poate fi complexă și consumatoare de timp. Acest lucru necesită experiență în infrastructură ca instrumente de cod, cum ar fi Terraform sau CloudFormation. Trebuie să aveți o echipă de dezvoltare senior capabilă să facă față unor astfel de provocări tehnice.

Când implementați o nouă versiune a software-ului, este important să vă asigurați că schema bazei de date este actualizată corect. Acest lucru poate fi o provocare, mai ales dacă schema bazei de date este complexă. Aveți nevoie de procese solide de implementare a bazei de date care să poată gestiona automat și fiabil activitățile de actualizare a schemei.

Analizarea performanței noii versiuni a software-ului într-un mediu real poate fi o provocare. Acest lucru necesită experiență în instrumente de analiză canar, cum ar fi Kayenta sau Spinnaker.

Implementarea comutărilor de funcții poate fi o provocare, mai ales dacă aplicația are un număr mare de funcții. Acest lucru necesită o planificare atentă și o coordonare între echipele de dezvoltare.

Testarea noii versiuni a software-ului într-un mediu real poate fi o provocare, mai ales dacă aplicația are un număr mare de utilizatori sau servere. Trebuie să aveți cazuri de testare automatizate cât mai mult posibil. De asemenea, procesele dumneavoastră de rutină vor ajunge să includă multă coordonare între echipele de dezvoltare și testare.

A avea o soluție bună de monitorizare este o realitate foarte rară, dar pentru operațiuni DevOps adecvate, aceasta este o necesitate. De îndată ce este posibil, du-te și investește timp în construirea acelei soluții cu servicii dovedite (AWS CloudWatch, New Relic, Datadog).

Diferența dintre desfășurarea albastru-verde și Canary

În timp ce diferența față de procesele tradiționale de implementare este destul de evidentă (nu există două medii paralele care rulează cu versiuni diferite de software în procesele tradiționale de implementare), diferența față de implementarea Canary ar putea fi puțin mai interesantă.

Implementarea albastru-verde înseamnă două medii (albastru și verde). Dar, în același timp, cele două medii sunt în mod constant sincronizate în ceea ce privește datele. Odată ce noua versiune este testată și considerată gata, traficul este comutat din mediul activ în mediul inactiv, transformându-l în noul mediu activ. Nu petreceți timp implementând cod nou și nu este implicat niciun timp de întrerupere a producției. Toți utilizatorii de producție lucrează tot timpul în mediul activ în prezent și nici măcar nu observă schimbarea.

Implementarea Canary implică implementarea unei noi versiuni a software-ului unui subset mic de utilizatori, în timp ce majoritatea utilizatorilor sau serverelor continuă să utilizeze versiunea actuală. Aceasta este o implementare graduală, mai degrabă decât o schimbare completă. Testerii sunt, în acest caz, utilizatori direcți de producție, chiar dacă doar un subset definit dintre ei. Acest grup testează în mod activ noua versiune cu procesele de producție, iar când va fi stabilă, noua versiune se va răspândi la restul utilizatorilor.

Deci, care este mai bun?

Răspunsul unui consultant „depinde” se potrivește cel mai mult aici, pe cât de rău ar putea suna.

Dacă prioritatea sistemului dvs. este disponibilitatea ridicată mai presus de toate, atunci implementarea Blue-Green va fi alegerea dvs.

Dacă preferința dvs. puternică este un feedback mai rapid și o lansare mai controlată (deși mai lentă) a noii versiuni de sistem, atunci implementarea Canary are avantaje față de Blue-Green.

Important este că amândoi sunt suficient de agile pentru a se considera suficient de buni pentru crearea serioasă a sistemului DevOps.

Studii de caz

Netflix folosește implementarea Blue-Green pentru a implementa noi versiuni ale serviciului său de streaming. Utilizând implementarea Blue-Green, Netflix poate implementa versiuni noi ale serviciului său fără a afecta experiența utilizatorului. De fapt, Netflix folosește și implementarea Canary în paralel pentru alte cazuri, așa că nu este nerealist să combinați abordări diferite ale implementării DevOps sub același acoperiș.

De asemenea, Amazon și Etsy folosesc implementarea Blue-Green pentru a implementa versiuni noi ale platformei lor de comerț electronic.

Un alt caz este LinkedIn, care folosește implementarea Blue-Green pentru a implementa versiuni noi ale platformei sale de rețele sociale.

Nu în ultimul rând, IBM folosește implementarea Blue-Green pentru a implementa noi versiuni ale platformei sale cloud.

Aceste companii au implementat cu succes implementarea Blue-Green în infrastructurile platformei lor și servesc ca un bun exemplu pentru alții.

Cuvinte finale

La fel ca și Canary, implementarea Blue-Green se străduiește pentru cea mai bună optimizare a proceselor și metodologiilor agile deja existente pentru a oferi software nou fără probleme, astfel încât nimeni să nu-l observe deloc. Acesta este scopul final al unor astfel de abordări. Livrezi în mod constant și foarte des, dar nimeni nu știe despre asta, nimeni nu o observă și, până la urmă, nimănui nu-i pasă.

Ar putea fi puțin frustrant pentru echipa de dezvoltare faptul că nu există bârfe în jurul companiei despre ultimele lor lansări. Dar dacă mă întrebați pe mine, acesta este exact cel mai bun serviciu pe care îl puteți oferi. Nimeni nu vorbește despre asta, dar toată lumea o folosește zi de zi.

Apoi, consultați întrebările și răspunsurile frecvente la interviul DevOps.