În compania noastră se desfășoară procesul de integrare a echipei SRE. Am început toată această poveste din perspectiva dezvoltării. Pe parcurs, am avut gânduri și insight-uri pe care vreau să le împărtășesc cu alți dezvoltatori. În acest articol-reflecție, discut despre ce se întâmplă, cum se întâmplă și cum putem trăi cu asta mai departe.
Continuarea seriei de articole scrise pe baza prezentărilor de la evenimentul nostru intern :
2. Infrastructure as code. (Ești aici)
3. Generarea contractelor Typescript pe baza modelelor c#. (În progres…)
4. Introducere în algoritmul de consens Raft. (În progres…)
…
Am decis să formăm o echipă SRE, realizând ideile de . Am selectat programatori din rândul dezvoltatorilor noștri și i-am trimis să se instruiască timp de câteva luni.
Echipa avea următoarele obiective de învățare:
- Să descrie infrastructura noastră, care este în mare parte în Microsoft Azure, sub formă de cod (Terraform și tot ce este în jur).
- Să învețe dezvoltatorii să lucreze cu infrastructura.
- Să pregătească dezvoltatorii pentru ture de supraveghere.
Introducem conceptul de Infrastructure as code
În modelul obișnuit (administrare clasică), cunoștințele despre infrastructură se află în două locuri:
- Fie în mințile experților.
- Fie aceste informații se găsesc pe anumite mașini, parte dintre ele fiind cunoscute de experți. Dar nu este garantat că o persoană din exterior (în cazul în care întreaga noastră echipă moare brusc) va putea să înțeleagă ce și cum funcționează. Pe o mașină pot exista multe informații: accesuri, cronuri, un disc montat (vezi ) și o listă infinită a tot ce poate să se întâmple. Este greu de înțeles ce se petrece cu adevărat.
În ambele cazuri ne aflăm într-o capcană, devenind dependenți:
- Fie de o persoană care este muritoare, supusă bolilor, îndrăgostelilor, schimbărilor de dispoziție și pur și simplu concedierilor;
- Fie de o mașină care funcționează fizic, care, de asemenea, cedează, poate fi furată, aduce surprize și neplăceri.
Încă o dată, se impune soluția ideală: totul ar trebui să fie transformat în cod ușor de citit, întreținut, și bine scris.
Astfel, infrastructura ca și cod (Infrastructure as Code – IaC) este descrierea întregii infrastructuri existente sub formă de cod, precum și instrumentele însoțitoare pentru a lucra cu acesta și a crea o infrastructură reală din același cod.
De ce să traduci totul în codOamenii nu sunt mașini. Ei nu pot reține tot. Reacția unei persoane și a unei mașini este diferită. Tot ceea ce este automatizat funcționează potențial mai repede decât tot ce face omul. Cel mai important este să existe o singură sursă de adevăr (single source of truth).
De unde provin noii ingineri SREDeci, am decis să angajăm noi ingineri SRE, dar de unde să-i luăm? O carte cu răspunsuri corecte () ne spune: din rândul dezvoltatorilor. Aceștia lucrează cu cod, iar tu atingi starea ideală.
Am căutat mult și bine pe piața muncii din afara companiei noastre. Dar suntem nevoiți să recunoaștem că nu am găsit nicio persoană conform cerințelor noastre. A trebuit să ne uităm printre cei din interior.
Problemele infrastructurii ca și cod
Acum să ne uităm la exemplele de cum infrastructura poate fi codificată. Codul este bine scris, de calitate, cu comentarii și indentare.
Exemplu de cod din Terraform.
Exemplu de cod din Ansible.
Domnilor, dar dacă totul ar fi fost atât de simplu! Noi suntem în lumea reală, care este pregătită întotdeauna să te surprindă cu probleme și dificultăți. Nu lipsesc nici aici.
1. Prima problemă este că, în cele mai multe cazuri, IaC este un fel de DSL.
Iar DSL, la rândul său, este o descriere a structurii. Mai exact, ceea ce ar trebui să ai: Json, Yaml, modificări de la anumite companii mari care au creat propriul DSL (în Terraform se folosește HCL).
Problema este că în acesta pot lipsi cu ușurință lucruri atât de obișnuite pentru noi, cum ar fi:
- variabile;
- condiții;
- undeva nu sunt comentarii, de exemplu, în Json, nu sunt prevăzute în mod implicit;
- funcții;
- și aici nici nu am menționat lucruri de nivel înalt, cum ar fi clasele, moștenirea și toate celelalte.
2. A doua problemă a acestui cod este că, cel mai adesea, este un mediu heterogen. De obicei, stai și lucrezi cu C#, adică cu un singur limbaj, un singur stack, un singur ecosistem. Dar aici ai o varietate imensă de tehnologii.
O situație destul de reală este când un bash cu Python lansează un proces, în care se introduce un Json. Îl analizezi, apoi un alt generator emite încă 30 de fișiere. Toate aceste variabile de intrare vin din Azure Key Vault, care sunt obținute printr-un plugin pentru drone.io, scris în Go, iar aceste variabile trec printr-un yaml, care a rezultat din generarea dintr-un motor de șablonizare jsonnet. Este destul de greu să ai un cod bine descris atunci când mediul tău este atât de diversificat.
Dezvoltarea tradițională într-o singură sarcină folosește un singur limbaj. Aici, însă, lucrăm cu un număr mare de limbaje.
3. A treia problemă este uneltele.. Ne-am obișnuit cu editoare grozave (Ms Visual Studio, Jetbrains Rider), care fac totul pentru noi. Și chiar dacă ne bloca, ele ne vor spune că nu avem dreptate. Pare că aceasta este normal și firesc.
Dar undeva aproape este VSCode, în care sunt unele plugin-uri, care sunt instalate, întreținute sau nu întreținute. Au apărut versiuni noi, și nu au fost suportate. O trecere banală la implementarea unei funcții (chiar dacă există) devine o problemă complicată și netradițională. O simplă redenumire a unei variabile implică un înlocuit în proiect din zeci de fișiere. Norocul tău să fie acela care înlocuiește ceea ce trebuie. Există, desigur, ceva evidențiere, există autocompletare, undeva există formatare (adevărat că în terrafom pe Windows nu a funcționat).
La momentul redactării articolului încă nu a fost lansat pentru suportul versiunii 0.12, deși a fost lansată acum 3 luni.
A venit timpul să uităm de...
- Debugging.
- Instrument de refactoring.
- Auto completare.
- Detectarea erorilor la compilare.
Amuzant, dar aceasta crește timpul de dezvoltare și crește numărul de erori, care apar inevitabil.
Cel mai înfricoșător este că suntem nevoiți să ne gândim nu la cum să proiectăm, să aranjăm fișierele în foldere, să decompunem, să facem codul întreținut, citit și așa mai departe, ci la cum să scriu corect acestă comandă, pentru că am scris-o oarecum greșit.
Ca începător, încerci să înveți Terraform, iar IDE-ul tău nu te ajută deloc în acest sens. Când există documentație – intri, te uiți. Dar dacă ai intra într-un nou limbaj de programare, IDE-ul ți-ar sugera că există un tip, iar altul nu. Cel puțin, la nivelul int sau string. Aceasta poate fi adesea util.
Dar ce se întâmplă cu testele?
Veți întreba: „Cum rămâne cu testele, domnilor programatori?” Tipii serioși testează totul în producție, și este sever. Iată un exemplu de test unitar pentru un modul Terraform de pe site. .
Au o documentație bună. Microsoft mi-a plăcut întotdeauna pentru abordarea lor față de documentație și învățare. Dar nu trebuie să fii un unchi Bob pentru a înțelege că aici nu este codul ideal. Observați validarea, care este desfășurată în dreapta.
Problema testului unitar este că noi putem verifica corectitudinea JSON-ului la ieșire. Am introdus 5 parametrii, și am obținut un șir de JSON de 2000 de linii. Pot analiza ce se întâmplă aici, valida rezultatul testului...
Este dificil să analizezi JSON în Go. Dar trebuie să scrii în Go, pentru că Terraform pe Go este o practică bună, testând în limbajul în care scrii. Organizația codului este foarte slabă. Totuși, aceasta este cea mai bună bibliotecă pentru testare.
Microsoft însuși scrie module sale, testându-le în acest mod. Desigur, este Open Source. Tot ce spun puteți veni și corecta. Pot să mă așez și în o săptămână să rezolv totul, să open-sourcific pluginuri pentru VS Code, Terraform, să fac un plugin pentru Rider. Poate să scriu câțiva analizatori, să integrez linteri, să contribui la biblioteca de testare. Pot face totul. Dar nu despre asta ar trebui să mă ocup.
Cele mai bune practici Infrastructure as Code
Să continuăm. Dacă în IaC nu sunt teste, dacă IDE-ul și uneltele sunt slabe, atunci ar trebui să existe măcar cele mai bune practici. Am mers în Google Analytics și am făcut o comparație între două interogări de căutare: Cele mai bune practici Terraform și cele mai bune practici C#.
Ce vedem? Statistici nemiloase, nu în favoarea noastră. În ceea ce privește cantitatea de material – e aceeași poveste. În dezvoltarea C# ne scufundăm în materiale, avem cele mai bune practici, avem cărți scrise de experți, și, de asemenea, cărți scrise pe cărți de alți experți care critică acele cărți. O multitudine de documentație oficială, articole, cursuri de formare, iar acum și dezvoltare open source.
Cât despre interogarea IaC: aici adunați informații cu greu din prezentările hi-load-ului sau HashiConf, din documentația oficială și numeroasele probleme de pe GitHub. Cum să distribuim aceste module, ce să facem cu ele? Pare că aceasta este o problemă reală... Există o comunitate, domnilor, unde pentru orice întrebare veți primi 10 comentarii pe GitHub. Dar nu este sigur.
Din păcate, în acest moment, experții abia încep să apară. Încă sunt prea puțini. Comunitatea este la un nivel incipient.
Încotro se îndreaptă totul și ce trebuie să facem
Poți renunța la tot și să te întorci la C#, în lumea Rider. Dar nu. De ce ai face asta, dacă nu pentru a găsi o soluție? Mai departe, voi prezenta concluziile mele subiective. Puteți să contestați în comentarii, ar fi interesant.
Personal, mizez pe câteva lucruri:
- Dezvoltarea în acest domeniu are loc foarte rapid. Iată un grafic al solicitărilor legate de DevOps.
Poate că tema este una populară, dar faptul că domeniul crește aduce o oarecare speranță.Dacă ceva crește atât de repede, cu siguranță vor apărea oameni inteligenți care vor spune cum trebuie să facem, și cum nu. Creșterea popularității conduce la faptul că poate cineva va avea în sfârșit timp să completeze un plugin pentru jsonnet pentru vscode, care va permite să treci la implementarea unei funcții, în loc să o cauți prin ctrl+shift+f. Pe măsură ce totul se dezvoltă, apar mai multe materiale. Lansarea acelei cărți de la Google despre SRE este un exemplu excelent.
- Există metode și practici dezvoltate în programarea obișnuită, pe care le putem aplica cu succes aici. Da, sunt nuanțe cu testarea și medii heterogene, instrumentația insuficientă, dar s-au acumulat o mulțime de practici care pot fi utile și de ajutor.
Un exemplu banal: colaborarea prin programare în pereche. Aceasta ajută enorm la clarificarea conceptelor. Când ai un coleg lângă tine care încearcă, de asemenea, să înțeleagă ceva, împreună veți înțelege mai bine.
Înțelegerea modului în care se face refactorizarea ajută chiar și în astfel de situații. Adică, poți să nu schimbi totul deodată, ci să schimbi denumirile, apoi să schimbi poziționarea, apoi poate să evidențiezi o parte, oh, și aici lipsesc comentariile.
Concluzie
Deși raționamentele mele pot părea pesimiste, privesc cu speranță către viitor și sper sincer că noi (și voi) vom reuși.
Următoarea parte a articolului este în pregătire. În aceasta voi povesti despre cum am încercat să aplicăm practici de dezvoltare agilă pentru a îmbunătăți procesul nostru de învățare și munca cu infrastructura.
Sursa: habr.com
