Ne kemi një proces onboarding të ekipit SRE në kompaninë tonë. Unë hyra në të gjithë këtë histori nga ana e zhvillimit. Gjatë procesit kam pasur mendime dhe njohuri që dëshiroj të ndaja me zhvilluesit e tjerë. Në këtë artikull-reflektim, flas për atë që po ndodh, si po ndodh dhe si mundet secili të jetojë me këtë më pas.
Vazhdimi i serisë së artikujve të shkruar mbi bazën e prezantimeve në ngjarjen tonë të brendshme. :
2. Infrastrukturë si kod. (Ju jeni këtu)
3. Generimi i kontratave Typescript nga modelet c#. (NĂ« procesâŠ)
4. Hyrje nĂ« algoritmin e konsensusit Raft. (NĂ« procesâŠ)
âŠ
Ne vendosëm të formonim një ekip SRE, duke realizuar idetë e . Mblodhëm programuesit nga zhvilluesit tanë dhe i dërguam ata për t'u trajnuar për disa muaj.
Para ekipit u paraqitën këto detyra mësimore:
- Të përshkruajnë infrastrukturën tonë, e cila për pjesën më të madhe ndodhet në Microsoft Azure, në formën e kodit (Terraform dhe gjithçka në lidhje me të).
- Të mësojnë zhvilluesit për të punuar me infrastrukturën.
- Të përgatisin zhvilluesit për turnet.
Po zhvillojmë konceptin e Infrastrukturës si kod.
Në modelin normal të botës (administrimi klasik) njohuritë mbi infrastrukturën ndodhen në dy vende:
- Ose në formën e njohurive në mendjet e ekspertëve.
- Ose kĂ«to informacione ndodhen nĂ« disa makineri, njĂ« pjesĂ« e tĂ« cilave i dinĂ« ekspertĂ«t. Por nuk Ă«shtĂ« fakt se njĂ« person nga jashtĂ« (nĂ«se e gjitha ekipi ynĂ« papritur ndĂ«rron jetĂ«) do tĂ« mund tĂ« kuptojĂ« se çfarĂ« ndodh. NĂ« makinĂ« mund tĂ« ketĂ« shumĂ« informacione: akseset, punĂ«t cron, disku i montuar (shih ) dhe njĂ« listĂ« e pafund e asaj qĂ« mund tĂ« ndodhĂ«. ĂshtĂ« e vĂ«shtirĂ« tĂ« kuptohet se çfarĂ« ka ndodhur nĂ« tĂ« vĂ«rtetĂ«.
Në të dy rastet, ne jemi në një grackë, duke u bërë të varur:
- ose nga një person, i cili është mortal, i ndjeshëm ndaj sëmundjeve, dashurive, ndryshimeve të humorit dhe thjesht pushimeve nga puna;
- ose nga makineria që funksionon fizikisht, e cila gjithashtu bie, vjedhet, sjell surpriza dhe shqetësime.
Natyrisht, zgjidhja duket e qartë, se në mënyrë ideale gjithçka duhet të përkthehet në kod të lexueshëm nga njerëzit, që mirëmbushet dhe është shkruar me cilësi.
Pra pasur infrastrukturen si kod (Infrastructure as Code â IaC) Ă«shtĂ« pĂ«rshkrimi i tĂ«rĂ« infrastrukturĂ«s ekzistuese nĂ« formĂ« kodi, si dhe mjetet pĂ«rkatĂ«se pĂ«r punĂ« me tĂ« dhe pĂ«r realizimin e infrastrukturĂ«s reale nga ky kod.
Pse tĂ« gjitha tĂ« kalohen nĂ« kodNjerĂ«zit nuk janĂ« makina. Ata nuk mund tĂ« mbajnĂ« gjithçka mend. Reagimi i njĂ« njeriu dhe njĂ« makine Ă«shtĂ« ndryshe. Ădo gjĂ« automatike potencialisht punon mĂ« shpejt se çdo gjĂ« qĂ« bĂ«nĂ« njĂ« njeri. MĂ« e rĂ«ndĂ«sishmja Ă«shtĂ« burimi i vetĂ«m i sĂ« vĂ«rtetĂ«s (single source of truth).
Nga vijnĂ« inxhinierĂ«t e rinj SREPra, ne vendosĂ«m tĂ« angazhojmĂ« inxhinierĂ« tĂ« rinj SRE, por nga tâi marrim? Libri me pĂ«rgjigjet e duhura () na thotĂ«: nga zhvilluesit. Ata punojnĂ« me kod, dhe ju arrini tĂ« gjendeni nĂ« njĂ« gjendje ideale.
Kemi kërkuar gjatë për ta në tregun e punës jashtë kompanisë sonë. Por e pranojmë se nuk gjetëm asnjë që i plotëson kërkesat tona. Duhej të kërkonim mes të tanishmëve tanë.
Problemet e Infrastructure as Code
Tani le të shohim shembuj se si infrastruktura mund të jetë e inkorporuar në kod. Kodi është shkruar mirë, me cilësi, me komente dhe hapësira.
Shembulli i kodit nga Terraforma.
Shembulli i kodit nga Ansible.
Zotërinj, po sikur të ishte gjithçka kaq e lehtë! Ne jemi në një botë reale, e cila gjithmonë është gati të na befasojë, të na ofrojë surpriza, probleme. As këtu nuk kemi të shmangim problemet.
1. Problemi i parë është se në shumicën e rasteve IaC është një lloj dsl.
Dhe DSL, nga ana e tij, është një përshkrim i strukturës. Më saktë, çfarë duhet të keni: Json, Yaml, modifikime nga disa kompani të mëdha që kanë shpikur dsl-in e tyre (në terraform përdoret HCL).
E keqja është se në të mund të mos ketë lehtësisht ato gjëra aq të njohura për ne si:
- variablat;
- kushtet;
- ndoshta nuk ka komente, për shembull, në Json, për default ato nuk janë të parashikuara;
- funkcionet;
- dhe këtë kam thënë pa folur për gjëra më të avancuara si klasat, trashëgimia dhe të gjithë atë.
2. Problemi i dytë i këtij kodi është se shpesh herë është një ambient heterogjen. Zakonisht ju punoni me C#, pra me një gjuhë, një stak, një ekosistem. Dhe këtu keni një larmi të madhe teknologjish.
Një situatë mjaft e vërtetë është kur një bash me Python nis një proces, në të cilin futet një Json. Ju e analizoni atë, pastaj një gjenerues tjetër prodhon edhe 30 skedare. Për të gjitha këto, hyjnë variablat nga Azure Key Vault, të cilat janë marrë nga plugini për drone.io, i shkruar në Go, dhe këto variabla kalojnë përmes yaml, i cili rezultoi nga gjenerimi nga templater jsonnet. Mjaft e vështirë të kesh një kod të përshkruar rigorozisht kur ke një ambient kaq të larmishëm.
Zhvillimi tradicional brenda një detyre shkon me një gjuhë. Këtu ne punojmë me një sasi të madhe gjuhësh.
3. Problemi i tretĂ« â Ă«shtĂ« tooling. Jemi tĂ« zakonshĂ«m me redaktorĂ«t e shkĂ«lqyer (Ms Visual Studio, Jetbrains Rider), tĂ« cilĂ«t bĂ«jnĂ« gjithçka pĂ«r ne. Dhe madje, edhe nĂ«se e humbasim fokusin, ata na thonĂ« se nuk kemi tĂ« drejtĂ«. Duket se kjo Ă«shtĂ« normale dhe e natyrshme.
Por diku afĂ«r ka VSCode, i cili ka disa plugina qĂ« instalohen, mbĂ«shteten ose nuk mbĂ«shteten. Dalin versione tĂ« reja dhe ato nuk mbĂ«shteten. NjĂ« kalim banal nĂ« implementimin e funksionit (edhe nĂ«se ekziston) bĂ«het njĂ« problem i komplikuar dhe jo trivial. NjĂ« riemrim i zakonshĂ«m i njĂ« variabli â Ă«shtĂ« njĂ« zĂ«vendĂ«sim nĂ« projekt nga dhjetĂ«ra skedare. Do tĂ« kesh fat nĂ«se zĂ«vendĂ«son atĂ« qĂ« Ă«shtĂ« e nevojshme. Sigurisht, ka ndonjĂ«herĂ« ndriçim, ka auto pĂ«rfundim, diku ka formatim (pavarĂ«sisht se nĂ« Terraform timin nĂ« Windows nuk funksionoi).
Në momentin që po shkruhet ky artikull nuk e kanë lëshuar ende për mbështetje të versionit 0.12, ndonëse është lëshuar prej 3 muajsh.
Ka ardhur koha tĂ« harrohetâŠ
- Debugging.
- Refactoring tool.
- Auto completion.
- Zbulimi i gabimeve gjatë kompilimit.
ĂshtĂ« qesharake, por kjo e rrit kohĂ«n e zhvillimit dhe rrit numrin e gabimeve qĂ« ndodhin pĂ«rherĂ«.
E frikshmja është se ne jemi të detyruar të mendojmë jo se si ta projektojmë, ta rendisim skedarin në dosje, ta dekompozojmë, ta bëjmë të mbështetur, të lehtë për t'u lexuar e kështu me radhë kodin, por se si të shkruaj këtë komandë siç duhet, sepse e kam shkruar ndonjëherë gabim.
Si njĂ« fillestar, ju pĂ«rpiqeni tĂ« kuptoni Terraform, ndĂ«rsa IDE ju ndihmon fare pak. Kur ka dokumentacion â hyni, shikoni. Por nĂ«se do tĂ« ishit duke u njohur me njĂ« gjuhĂ« programuese tĂ« re, IDE do t'ju sugjeronte se ka njĂ« tip tĂ« tillĂ« dhe njĂ« tĂ« tillĂ« nuk ka. TĂ« paktĂ«n, nĂ« nivelin e int ose string. Kjo shpesh Ă«shtĂ« e dobishme.
Por si janë testet?
Do you ask: "What about testing, dear programmers?" Serious professionals test everything in production, and itâs tough. Hereâs an example of a unit test for a Terraform module from the site. .
They have good documentation. I've always liked Microsoft's approach to documentation and training. But you don't have to be Uncle Bob to realize that the code here is not perfect. Pay attention to the validation, moved to the right.
The problem with the unit test is that we can only check the correctness of the JSON output. I input 5 parameters, and it returned a JSON payload with 2000 lines. I can analyze whatâs happening here, validate the test resultâŠ
Itâs hard to analyze JSON in Go. But you should write in Go because Terraform in Go is a good practice of testing in the language you write. The code organization itself is quite weak. However, it is the best library for testing.
Microsoft itself writes its modules, testing them this way. Of course, this is Open Source. Everything I talk about you can come and fix. I can sit down and fix everything in a week, open-source VS Code plugins, Terraform, make a plugin for Rider. Maybe write a couple of analyzers, attach linters, contribute to the testing library. I can do it all. But I shouldnât be dealing with this.
Best practices for Infrastructure as Code
Letâs move on. If there are no tests in IaC, the IDE and tooling are poor, there should at least be best practices. I simply went into Google Analytics and compared two search queries: Terraform best practices and C# best practices.
What do we see? Ruthless statistics that are not in our favor. In terms of material quantity, itâs the same. In C# development, we are just swimming in material, we have super best practices, there are books written by experts, and also books written by other experts that criticize those books. A sea of official documentation, articles, training courses, and now also open source development.
As for the IaC query: here, youâre trying to gather info from high-load talks or HashiConf, from official documentation, and numerous issues on GitHub. How exactly to distribute these modules, what to do with them? It seems like a real problem⊠There is a community, gentlemen, where for any question you will get 10 comments on GitHub. But thatâs not certain.
Fatkeqësisht, në këtë moment ekspertët po fillojnë të shfaqen. Deri tani janë shumë të pakët. Ndërsa komuniteti është në fazën e tij fillestare.
Në drejtimin e çfarë shkon gjithçka dhe çfarë të bëjmë
Mund ta lësh gjithçka dhe të kthesh në C#, në botën e rider-it. Po ashtu, pse do të merreshit me këtë, nëse jo për të gjetur një zgjidhje. Më poshtë paraqes përfundimet e mia subjektive. Mund të më diskutoni në komentet, do të ishte interesante.
Personal unë mbështes disa gjëra:
- Zhvillimi në këtë fushë po ndodh shumë shpejt. Po sjell një grafik të kërkesave për DevOps.
Ndoshta tema është në modë, por vetë fakti se fusha po rritet, ngjall disa shpresa.Nëse diçka rritet kaq shpejt, sigurisht që do të shfaqen njerëz të mençur që do të tregojnë se si duhet vepruar, dhe si jo. Rritja e popullaritetit çon në atë që ndoshta dikush do të ketë kohë të përfundojë një plugin për jsonnet për vscode, i cili do të lejojë kalimin në implementimin e funksionit, dhe jo ta kërkosh atë përmes ctrl+shift+f. Kur gjithçka zhvillohet, shfaqen më shumë materiale. Dalja e librit nga google për SRE është një shembull i shkëlqyer për këtë.
- Ka metodologji dhe praktika të zhvilluara në zhvillimin e zakonshëm, të cilat mund t'i aplikojmë me sukses këtu. Po, ka nuanca me testimin dhe mjedisin heterogjen, mjete të pamjaftueshme, por është grumbulluar një numër i madh praktikash që mund të jenë të dobishme dhe të ndihmojnë.
Një shembull banal: puna e përbashkët përmes pair programming. Ai ndihmon shumë për të kuptuar. Kur ke një fqinj pranë, i cili gjithashtu përpiqet të kuptojë diçka, së bashku do ta kuptoni më mirë.
Kuptimi se si bëhet refaktorizimi ndihmon madje edhe në një situatë të tillë për ta realizuar atë. Pra, ti mund të mos ndryshosh gjithçka menjëherë, por mund të ndryshosh emërtimin, pastaj pozicionin, e më pas ndoshta të veçosh ndonjë pjesë, gjithashtu, oh, këtu mungojnë komentet.
PĂ«rfundim
Pavarësisht se arsyetimet e mia mund të duken pesimiste, unë shikoj me shpresë drejt të ardhmes dhe shpresoj sinqerisht që ne (dhe ju) do t'ia dalim.
Më pas po përgatitet pjesa e dytë e artikullit. Në të do të flas për si u përpoqëm të aplikonim praktikat e zhvillimit të përshtatshëm për të përmirësuar procesin tonë të të mësuarit dhe punën me infrastrukturën.
Burimi: habr.com
