Reprezentarea infrastructurii ca cod într-un format de text repetabil este o practică simplă pentru sistemele care nu necesită manipularea șoarecilor. Această practică are un nume - și până acum există două instrumente populare pentru a-l implementa, în special în AWS: и .
Comparând experiența cu Terraform și CloudFormation
Înainte de a veni la (Aka ) Am lucrat și a folosit Terraform timp de trei ani. La noul loc, am folosit și Terraform din toată puterea mea, iar apoi compania a făcut tranziția la tot ceea ce este la Amazon, inclusiv CloudFormation. Am dezvoltat cu sârguință cele mai bune practici pentru ambele și am folosit ambele instrumente în fluxuri de lucru foarte complexe, la nivelul întregii organizații. Mai târziu, după ce am cântărit atent implicațiile migrării de la Terraform la CloudFormation, m-am convins că Terraform a fost probabil cea mai bună alegere pentru organizație.
Terraform Oribil
Software beta
Terraform nu a lansat încă versiunea 1.0, ceea ce este un motiv bun pentru a nu o folosi. S-a schimbat foarte mult de când l-am încercat eu însumi, dar pe atunci terraform apply adesea s-a defectat după mai multe actualizări sau pur și simplu după câțiva ani de utilizare. Aș spune că „totul este diferit acum”, dar... asta pare să spună toată lumea, nu? Există modificări care sunt incompatibile cu versiunile anterioare, deși sunt adecvate și chiar se simte că sintaxa și abstracțiile depozitelor de resurse sunt acum ceea ce avem nevoie. Instrumentul pare să se fi îmbunătățit cu adevărat, dar... :-0
Pe de altă parte, AWS a făcut o treabă bună menținând compatibilitatea cu versiunea anterioară. Acest lucru se datorează probabil pentru că serviciile lor sunt adesea testate temeinic în cadrul organizației și abia apoi, redenumite, sunt publicate. Deci „au încercat din greu” este o subestimare. Menținerea compatibilității cu API-urile pentru un sistem la fel de variat și complex precum AWS este incredibil de dificilă. Oricine a fost nevoit să mențină API-uri publice care sunt utilizate la fel de larg, ar trebui să înțeleagă cât de dificil este să facă acest lucru de atâția ani. Dar comportamentul CloudFormation, în memoria mea, nu s-a schimbat niciodată de-a lungul anilor.
Faceți cunoștință cu piciorul... este un glonț
Din câte știu eu, ștergeți resursa străin Nu este posibilă stiva CloudFormation din stiva dumneavoastră CF. Același lucru este valabil și cu Terraform. Vă permite să importați resursele existente în stiva dvs. Se poate spune că funcția este uimitoare, dar cu o mare putere vine o mare responsabilitate. Trebuie doar să adăugați o resursă la stivă și, în timp ce lucrați cu stiva dvs., nu puteți șterge sau modifica această resursă. Într-o zi a fost invers. Într-o zi, pe Twitch, cineva a importat din greșeală grupul de securitate AWS al altcuiva în propriul stiv Terraform, fără să facă vreo răutate. Am introdus mai multe comenzi și... grupul de securitate (împreună cu traficul de intrare) a dispărut.
Terraform Grozav
Recuperarea din stări incomplete
Uneori, CloudFormation nu reușește să treacă complet de la o stare la alta. În același timp, va încerca să revină la precedentul. Păcat că acest lucru nu este întotdeauna fezabil. Poate fi destul de înfricoșător să depanezi ceea ce s-a întâmplat mai târziu - nu știi niciodată dacă CloudFormation va fi fericit că este piratat - chiar și doar pentru a o remedia. Indiferent dacă va fi sau nu posibil să se întoarcă la starea anterioară, el chiar nu știe cum să stabilească și, implicit, așteaptă ore întregi în așteptarea unui miracol.
Terraform, pe de altă parte, tinde să se recupereze din tranzițiile eșuate mult mai grațios și oferă instrumente avansate de depanare.
Modificări mai clare ale stării documentului
„Bine, echilibrator de încărcare, te schimbi. Dar cum?"
—inginer anxios, gata să apese butonul „accepta”.
Uneori trebuie să fac unele manipulări cu echilibrul de încărcare din stiva CloudFormation, cum ar fi adăugarea unui număr de port sau schimbarea unui grup de securitate. ClouFormation afișează slab modificările. Eu, pe ace și ace, verific fișierul yaml de zece ori pentru a mă asigura că nu am șters nimic necesar și că nu am adăugat nimic inutil.
Terraform este mult mai transparent în acest sens. Uneori este chiar prea transparent (a se citi: enervant). Din fericire, cea mai recentă versiune include afișarea îmbunătățită a modificărilor, astfel încât acum puteți vedea exact ce se schimbă.
flexibilitate
Scrieți software-ul înapoi.
Pe scurt, cea mai importantă caracteristică a software-ului de lungă durată este capacitatea de a se adapta la schimbare. Scrieți orice software invers. Cel mai adesea am făcut greșeli luând un serviciu „simplu” și apoi am început să înghesui totul într-o singură stivă CloudFormation sau Terraform. Și, desigur, luni mai târziu s-a dezvăluit că am înțeles totul greșit, iar serviciul nu a fost de fapt simplu! Și acum trebuie să sparg cumva o stivă mare în componente mici. Când lucrați cu CloudFormation, acest lucru se poate face doar recreând mai întâi stiva existentă, iar eu nu fac asta cu bazele de date. Terraform, pe de altă parte, a făcut posibilă disecția stivei și împărțirea lui în părți mai mici mai ușor de înțeles.
Module în git
Partajarea codului Terraform pe mai multe stive este mult mai ușoară decât partajarea codului CloudFormation. Cu Terraform, puteți pune codul într-un depozit git și îl puteți accesa folosind controlul semantic al versiunii. Oricine are acces la acest depozit poate reutiliza codul partajat. Echivalentul lui CloudFormation este S3, dar nu are aceleași beneficii și nu există niciun motiv pentru care să renunțăm la git în favoarea S3.
Organizația a crescut și capacitatea de a partaja stive comune a atins un nivel critic. Terraform face totul ușor și natural, în timp ce CloudFormation vă va face să săriți printre cercuri înainte de a putea face ca ceva de genul acesta să funcționeze.
Operații ca cod
„Hai să scriem scenariul și bine.”
—un inginer cu 3 ani înainte de a inventa bicicleta Terraform.
Când vine vorba de dezvoltarea de software, Go sau un program Java nu este doar cod.
Codați ca cod
Există și infrastructura pe care funcționează.
Infrastructura ca Cod
Dar de unde este ea? Cum să-l monitorizezi? Unde locuiește codul tău? Dezvoltatorii au nevoie de permisiunea de acces?
Operațiuni ca cod
A fi dezvoltator de software nu înseamnă doar a scrie cod.
AWS nu este singurul: probabil că utilizați alți furnizori. SignalFx, PagerDuty sau Github. Poate aveți un server intern Jenkins pentru CI/CD sau un tablou de bord intern Grafana pentru monitorizare. Infra as Code este ales din diferite motive și fiecare este la fel de important pentru tot ceea ce ține de software.
Când lucram la Twitch, am accelerat serviciile în cadrul sistemelor mixte încorporate și AWS ale Amazon. Am creat și am susținut multe microservicii, crescând costurile operaționale. Discuțiile au decurs cam așa:
- Я: La naiba, sunt o mulțime de gesturi pentru a overclocka un microserviciu. Va trebui să folosesc acest gunoi pentru a crea un cont AWS (am mers la 2 conturi pe microserviciu), apoi acesta pentru configurarea alertelor, acesta pentru un depozit de coduri și acesta pentru o listă de e-mail, apoi acesta...
- Conduce: Să scriem scenariul și bine.
- Я: Bine, dar scenariul în sine se va schimba. Vom avea nevoie de o modalitate de a verifica dacă toate aceste gadgeturi Amazon încorporate sunt la zi.
- Conduce: Sună bine. Și vom scrie un scenariu pentru asta.
- Я: Grozav! Și probabil că scriptul va trebui să seteze parametri. Le va accepta?
- Conduce: Lasă-l să ia unde se duce!
- Я: Procesul se poate schimba și compatibilitatea cu versiunea anterioară se va pierde. Va fi necesar un fel de control semantic al versiunii.
- Conduce: Buna idee!
- Я: Instrumentele pot fi schimbate manual, în interiorul interfeței cu utilizatorul. Vom avea nevoie de o modalitate de a verifica și remedia asta.
…3 ani mai tarziu:
- Conduce: Și am luat terraform.
Morala poveștii este: chiar dacă tu cap peste tocuri în tot Amazon, încă utilizați ceva care nu este de la AWS, iar aceste servicii au o stare care utilizează un limbaj de configurare pentru a menține acea stare sincronizată.
CloudFormation lambda vs modulele git terraform
lambda este soluția CloudFormation pentru problema de logică personalizată. Cu lambda poți sau . Această abordare introduce complexități suplimentare care nu sunt prezente în versiunea semantică a modulelor git de la Terraform. Pentru mine, cea mai presantă problemă a fost gestionarea permisiunilor pentru toate aceste lambda de utilizatori (și acestea sunt zeci de conturi AWS). O altă problemă importantă a fost problema „ce a venit mai întâi, găina sau oul: era legată de codul lambda”. Această funcție în sine este infrastructură și cod și are nevoie de monitorizare și actualizări. Ultimul cui din sicriu a fost dificultatea de a actualiza semantic modificările codului lambda; De asemenea, a trebuit să ne asigurăm că acțiunile stivei fără o comandă directă nu se schimbau între rulări.
Îmi amintesc când am vrut să creez o implementare canary pentru mediul Elastic Beanstalk cu un echilibrator de încărcare clasic. Cel mai ușor ar fi să faci o a doua implementare pentru EB lângă mediul de producție, făcând-o un pas mai departe: combinarea grupului de implementare auto-scaling canary cu implementarea LB în mediul de producție. Și din moment ce Terraform folosește , acest lucru va necesita 4 linii suplimentare de cod în Terraform. Când am întrebat dacă există o soluție comparabilă în CloudFormation, mi-au indicat un întreg depozit git cu o conductă de implementare și totul, totul de dragul a ceva ce ar putea face cele 4 linii de cod Terraform sărace.
Detectează mai bine deriva
Asigurați-vă că realitatea corespunde așteptărilor.
este o funcție foarte puternică pentru operațiuni ca cod, deoarece ajută la asigurarea faptului că realitatea corespunde așteptărilor. Este disponibil atât cu CloudFormation, cât și cu Terraform. Dar, pe măsură ce stiva de producție a crescut, căutarea derivei în CloudFormation a produs tot mai multe detectări false.
Cu Terraform aveți cârlige mult mai avansate pentru ciclul de viață pentru detectarea derivei. De exemplu, introduceți comanda direct în definiția sarcinii ECS dacă doriți să ignorați modificările aduse unei anumite definiții de activitate fără a ignora modificările aduse întregii implementări ECS.
CDK și viitorul CloudFormation
CloudFormation este dificil de gestionat la scară largă, între infrastructuri. Multe dintre aceste dificultăți sunt recunoscute și instrumentul are nevoie de lucruri precum , un cadru pentru definirea infrastructurii cloud în cod și rularea acesteia prin AWS CloudFormation. Va fi interesant de văzut ce îi rezervă viitorul pentru aws-cdk, dar îi va fi greu să concureze cu celelalte puncte forte ale Terraform; pentru a actualiza CloudFormation, vor fi necesare modificări globale.
Pentru ca Terraform să nu dezamăgească
Aceasta este „infrastructura ca cod” și nu „ca text”.
Prima mea impresie despre Terraform a fost destul de proastă. Cred că pur și simplu nu am înțeles abordarea. Aproape toți inginerii îl percep involuntar ca pe un format de text care trebuie convertit în infrastructura dorită. NU FACEȚI AȘA.
Truismele dezvoltării software bune se aplică și pentru Terraform.
Am văzut multe practici adoptate pentru a crea cod bun fiind ignorate în Terraform. Ai studiat ani de zile ca să devii un programator bun. Nu renunțați la această experiență doar pentru că lucrați cu Terraform. Truismele dezvoltării software bune se aplică Terraform.
Cum poate codul să nu fie documentat?
Am văzut stive uriașe Terraform fără absolut nicio documentare. Cum poți scrie cod în pagini - fără absolut nicio documentație? Adăugați documentație care vă explică cod Terraform (accent pe cuvântul „cod”), de ce această secțiune este atât de importantă și ce faci.
Cum putem implementa servicii care au fost cândva o mare funcție principală ()?
Am văzut stive Terraform foarte complexe prezentate ca un singur modul. De ce nu implementăm software-ul în acest fel? De ce împărțim funcțiile mari în altele mai mici? Aceleași răspunsuri se aplică și pentru Terraform. Dacă modulul este prea mare, trebuie să-l împărțiți în module mai mici.
Compania ta nu folosește biblioteci?
Am văzut cum inginerii, creând un nou proiect folosind Terraform, au copiat în mod prostesc bucăți uriașe din alte proiecte în propriile lor, apoi le-au schimbat până când a început să funcționeze. Ați lucra așa cu codul „de luptă” în compania dumneavoastră? Nu folosim doar biblioteci. Da, dar unde suntem fără biblioteci partajate în principiu?!
Nu folosești PEP8 sau gofmt?
Majoritatea limbilor au o schemă de formatare standard, acceptată. În Python, acesta este PEP8. În Go - gofmt. Terraform are propriile sale: terraform fmt. Utilizați pentru sănătate!
Veți folosi React fără să cunoașteți JavaScript?
Modulele Terraform pot simplifica o parte din infrastructura complexă pe care o creați, dar asta nu înseamnă că nu o puteți schimba deloc. Doriți să utilizați Terraform corect fără a înțelege resursele? Ești condamnat: timpul va trece și nu vei stăpâni niciodată Terraform.
Codați cu singleton-uri sau injecție de dependență?
Injecția de dependență este cea mai bună practică recunoscută pentru dezvoltarea de software și este preferată față de singleton-urile. Cum este util acest lucru în Terraform? Am văzut module Terraform care depind de starea de la distanță. În loc să scrieți module care preiau starea de la distanță, scrieți un modul care preia parametri. Și apoi transmiteți acești parametri la modul.
Bibliotecile tale fac zece lucruri bine sau un lucru grozav?
Bibliotecile care funcționează cel mai bine sunt cele care se concentrează pe o sarcină pe care o fac foarte bine. În loc să scrieți module Terraform mari care încearcă să facă totul deodată, construiți părți din ele care fac un lucru bine. Și apoi combinați-le după cum este necesar.
Cum faci modificări în biblioteci fără compatibilitate inversă?
Un modul comun Terraform, ca o bibliotecă obișnuită, trebuie să comunice cumva modificările utilizatorilor fără a fi compatibil cu invers. Este enervant când aceste modificări au loc în biblioteci și este la fel de enervant atunci când se fac modificări necompatibile cu versiunea inversă în modulele Terraform. Este recomandat să folosiți etichetele git și semver atunci când utilizați modulele Terraform.
Serviciul dvs. de producție rulează pe laptop sau într-un centru de date?
Hashicorp are instrumente precum să-ți conduci terraforma. Aceste servicii centralizate facilitează gestionarea, auditarea și aprobarea modificărilor de terraform.
Nu scrii teste?
Inginerii recunosc că codul trebuie testat, dar ei înșiși uită adesea de testare atunci când lucrează cu Terraform. Pentru infrastructură, aceasta este plină de momente perfide. Sfatul meu este să „testați” sau să „creați exemple” de stive folosind module care pot fi implementate corect pentru testare în timpul CI/CD.
Terraform și microservicii
Viața și moartea companiilor de microservicii depind de viteza, inovația și întreruperea noilor stive de lucru pentru microservicii.
Cel mai frecvent aspect negativ asociat cu arhitecturile de microservicii, și care nu poate fi eliminat, este legat de muncă, nu de cod. Dacă te gândești la Terraform doar la o modalitate de a automatiza doar partea de infrastructură a unei arhitecturi de microservicii, atunci pierzi adevăratele beneficii ale sistemului. Acum este deja .
Sursa: www.habr.com