Salutare, entuziaști ai cloud-ului! Legenda spune că și acum, acolo sus în cloud, există un conflict între un pipeline Terraform și AWS CodeDeploy. Hai să vedem dacă reușim să aducem pace și armonie pe tărâmul blue-green. Din perspectiva infrastructurii, vom merge de sus în jos, ca în imaginile de mai jos.
Să începem prin a răspunde la câteva întrebări pentru cititorii noștri mai puțin tehnici.
CE ESTE TERRAFORM ȘI CUM ÎL FOLOSIM?
Imaginați-vă Terraform ca pe o carte mare de bucate cu multe rețete excelente. Când începem să facem plăcinta cu dovleac (infrastructura noastră), trebuie să respectăm rețeta din carte; în caz contrar, plăcinta nu va fi bună, iar oaspeții noștri (utilizatorii) vor pune la îndoială abilitatea noastră de a găti. Mai multe despre ce este Terraform și cum să îl instalezi aici.
CE ESTE UN PIPELINE TERRAFORM ȘI CUM ÎL FOLOSIM?
Să ne imaginam că pipeline-ul este un robot de bucătărie care va găti plăcinta pentru noi, dar are nevoie de instrucțiuni clare cu privire la ingredientele care trebuie puse în ea.
În procesul de preparare (construire) a plăcintei, robotul va copia mai mult sau mai puțin rețeta din carte pe o bucată separată de hârtie. Acea bucată de hârtie se numește Terraform state file. Fiecare ingredient pe care îl vom adăuga, robotul îl va adăuga, de asemenea, la state file.
Acest lucru asigură că robotul nu va uita cum ar trebui să arate plăcinta noastră (infrastructura). De fiecare dată când pornim robotul (declanșăm pipeline-ul), acesta va verifica dacă plăcinta noastră (infrastructura) are fiecare ingredient din state file. Dacă plăcinta are un ingredient lipsă (din cele care sunt prezente în state file), robotul îl va adăuga la plăcintă. Dacă eliminăm manual un ingredient din plăcintă, robotul, atunci când rulează, va vedea acest lucru și îl va ‘repara’ (va adăuga ingredientul).
CE ESTE CODEDEPLOY ȘI CUM ÎL FOLOSIM?
Continuând pe aceeași notă, imaginează-ți CodeDeploy ca fiind un ingredient din rețeta noastră (infrastructura), dar acest ingredient ar putea fi de fapt el însuși un bucătar. Are capacitatea de a gestiona pe cont propriu alte ingrediente (alte părți ale infrastructurii). CodeDeploy ar putea ‘funcționa’ pe două niveluri diferite: in-place și blue-green.
In-place înseamnă că, dacă actualizăm unele ingrediente, le va actualiza pe rând, unul câte unul.
Blue-green înseamnă că va crea piese noi (green), identice cu piesele existente (blue). Mai întâi le va actualiza pe cele green; se va asigura că acestea arată bine; apoi, când acest proces este finalizat, le va elimina pe cele blue. Strategia de implementare blue/green înseamnă să ai două medii identice, dar separate. Mediul blue rulează versiunea curentă a aplicației, iar cel green rulează noua versiune a aplicației.
De ce este importantă implementarea blue-green? Minimizează timpul de nefuncționare (downtime) al aplicațiilor în timpul implementării.
Pentru că în fiecare poveste fericită va exista și o parte mai puțin bună, în cazul nostru de utilizare cu implementarea blue-green pe AWS, este aceasta: unul dintre principalele dezavantaje ale implementării blue-green este costul său. Deoarece este nevoie de o copie a mediului de funcționare, aceasta înseamnă că vei avea nevoie de resurse duble. Pentru un mediu ce are deja costuri ridicate, această strategie de implementare s-ar putea să nu fie cea mai bună.
CE ESTE ASG (AutoScalingGroup)?
ASG este o colecție de componente (computere) care au caracteristici similare și sunt tratate ca o grupare logică pentru gestionarea flotei și scalarea dinamică. Acesta se poate extinde sau retrage în funcție de necesități.
ÎNCEPEM SĂ ‘ÎMPĂCĂM’ TERRAFORM ȘI CODEDEPLOY:
Acum, după această introducere nu prea scurtă, să ne aruncăm în ‘luptă’. Vom începe de aici:
Și de la această configurare Terraform a CodeDeploy:
Cele de mai sus arată că aplicația CodeDeploy va actualiza colecția noastră de computere unul câte unul, creând un potențial timp de inactivitate.
Dacă dorim să obținem un timp de inactivitate zero atunci când ne actualizăm aplicația, CodeDeploy ne permite să avem un tip de implementare blue-green în loc de in-place.
Cu implementarea blue-green, CodeDeploy creează un nou set de instanțe, păstrându-le în același timp pe cele vechi, apoi comută traficul către noile instanțe, asigurând un timp de inactivitate zero. Și pentru că banii joacă un rol vital și în cloud, nu doar în viața de zi cu zi, vrem să ne asigurăm că nu cheltuim mai mult decât trebuie. Pentru aceasta, putem lăsa CodeDeploy să gestioneze crearea și încetarea ASG-urilor. CodeDeploy va face toată treaba pentru noi, iar noi trebuie doar să avem grijă de aplicația noastră și să nu ne facem griji pentru infrastructură.
Vom trece la acest lucru (comparând cu configurația anterioară):
Dacă aplicăm această configurație, vom lăsa CodeDeploy să gestioneze ASG-urile noastre. Acesta va crea un nou ASG datorită parametrului "COPY_AUTO_SCALING_GROUP" și îl va încheia pe cel vechi după ce totul se va desfășura cu succes datorită parametrului "TERMINATE".
Să reflectăm pentru o secundă. Dacă facem acest lucru, CodeDeploy va crea resurse noi pe cont propriu (ASG nou) și va termina resurse pe cont propriu (ASG vechi) atunci când se execută pipeline-ul Terraform. Acesta va vedea aceste 'diferențe' datorită state file și va recrea totul așa cum a fost la început. Aceasta înseamnă că ASG-ul nostru va fi recreat, iar versiunea anterioară a aplicației va fi din nou online pentru utilizatori. Acest lucru nu este ideal.
CUM PUTEM SĂ NE PĂSTRĂM PIPELINE-UL TERRAFORM MULȚUMIT, LĂSÂND CODEDEPLOY SĂ GESTIONEZE PARTEA DE IMPLEMENTARE (ASG)?
Soluția este ceva numit 'lifecycle' (ciclu de viață). Meta-argumentul 'lifecycle' poate fi utilizat pentru a specifica modul în care Terraform ar trebui să gestioneze crearea, modificarea și distrugerea resurselor.
Meta-argumentele sunt argumente utilizate în resource blocks. Pe baza acestuia: https://developer.hashicorp.com/terraform/language/meta-arguments/lifecycle, avem mai multe opțiuni, dar ne vom concentra doar pe "ignore_changes".
Meta-argumentul Terraform ‘lifecycle’ "ignore_changes" este destinat utilizării atunci când o resursă este creată cu referințe la date care se pot modifica în viitor, dar care nu ar trebui să o afecteze după crearea sa. În unele cazuri rare, setările unui obiect la distanță sunt modificate de procese din afara Terraform, pe care Terraform ar încerca apoi să le ‘repare’ la următoarea execuție. Pentru a face Terraform să împartă responsabilitățile de gestionare a unui singur obiect cu un proces separat, meta-argumentul "ignore_changes" specifică atributele resurselor pe care Terraform ar trebui să le ignore atunci când planifică actualizări ale obiectului la distanță asociat.
PENTRU A SOLUȚIONA ACEST CONFLICT, AVEM DOUĂ OPȚIUNI:
🟧 OPȚIUNEA 1: 'SEMNAREA TRATATULUI DE PACE’ ÎNTR-UN SINGUR PAS.
Pasul 1: adăugarea 'lifecycle' în configurația CodeDeploy.
Acest lucru asigură faptul că Terraform va ignora parametrul ASG din configurația CodeDeploy. Acest pas este necesar deoarece CodeDeploy gestionează crearea și încetarea ASG-urilor. Atunci când se execută pipeline-ul Terraform, aceasta va încerca să revină la ASG-ul anterior (ceea ce nu este ceea ce ne dorim).
🟧 OPȚIUNEA 2: AM PUTEA 'SEMNA TRATATUL DE PACE’ ÎN DOI PAȘI.
Pasul 1: la fel ca înainte, dar cu o mică diferență în configurația noastră CodeDeploy:
Acum, în loc de "TERMINATE", avem "KEEP_ALIVE". Aceasta înseamnă că, după finalizarea implementării noastre, vechiul ASG nu va fi închis, dar acest lucru mai înseamnă și că vechiul ASG va produce costuri pentru noi, iar noi nu avem nevoie de acest lucru, astfel încât acum este necesar pasul 2, suplimentar.
Pasul 2: se va adăuga 'lifecycle' în configurația ASG.
Acest lucru este necesar deoarece, după ce constatăm că implementarea noastră a avut succes și totul este perfect, vom intra manual în Consola de administrare AWS și vom seta aceste trei argumente ("desired_capacity","min_size", "max_size") la 0. Astfel, împiedicăm vechiul ASG să producă costuri.
Ar trebui să folosim a doua abordare numai dacă dorim o mai bună transparență în infrastructura noastră.
Potențial scenariu: să presupunem că aplicăm prima opțiune, iar un nou specialist se alătură echipei pentru a revizui codul Terraform. La început, specialistul nu va înțelege de ce ASG este absent, iar dacă nu este familiarizat cu CodeDeploy blue-green, s-ar putea să nu înțeleagă cum funcționează. Totuși, să presupunem că aplicăm a doua opțiune, iar specialistul vede ASG-ul prezent în AWS Management Console (dar scalat la zero) și același ASG în Terraform, dar cu un 'lifecycle'. În acest caz, ar putea înțelege cu ușurință ce se întâmplă.
CONCLUZIE
În marea poveste a infrastructurii cloud, armonia dintre Terraform și CodeDeploy nu este doar un vis - este o realitate pe care o poți obține cu configurația corectă. Utilizarea meta-argumentului ‘lifecycle’ din Terraform pentru a ignora anumite modificări permite implementări transparente de tip blue-green cu CodeDeploy, asigurând un proces ușor și fiabil de implementare a aplicațiilor.
Așadar, să fie pace în câmpurile blue-green! Fie ca implementările tale să se desfășoare fără probleme, timpii de nefuncționare să fie zero, iar utilizatorii tăi să fie întotdeauna mulțumiți. Implementări fericite, entuziaști ai cloud-ului!
Vezi articolul pe website: Rezolvarea ‘bătăliei’ dintre Terraform și CodeDeploy în câmpurile blue-green ale AWS - SoftServe (softserveinc.com)
*Autor: GEORGE DOBRIȘAN | SOFTSERVE SENIOR AWS DEVOPS ENGINEER
