Infrastruktuur kui kood: esimene tutvustus

Meie ettevõttes on käimas SRE-meeskonna onboardingu protsess. Ma läksin kõikidesse detailidesse arenduse poolelt. Protsessi käigus tekkisid mul mõtted ja teadmised, mida soovin jagada teiste arendajatega. Selles artiklis mõtisklen, mis toimub, kuidas see toimub ja kuidas kõigil edasi elada.

Seeria artiklid, mis on kirjutatud meie sisemise ürituse ettekannete põhjal DevForum:

1. Schrödingeri kass ilma karbita: konsensusprobleem jaotatud süsteemides.
2. Infrastruktur kui kood. (Sa oled siin)
3. Typescripti lepingute genereerimine C# mudelite põhjal. (Töös …)
4. Tutvustus Rafti konsensusalgoritmisse. (Töös …)
…

Oleme otsustanud luua SRE-meeskonna, elluviides ideid google sre. Värbasime oma arendajatest programmeerijaid ja saatsime nad mitmeks kuuks koolitusele.

Meeskonna ees seisis järgmine õpiküsimuste kogum:

• Kirjeldada meie infrastruktuuri, mis enamikus asub Microsoft Azure’is, koodina (Terraform ja kõik, mis selle ümber on).
• Õpetada arendajaid infrastruktuuriga töötama.
• Valmistada arendajad ette vahetusteks.

Tutvustame mõistet Infrastructure as code

Tavapärases maailmamudelis (klassikalises halduses) on teadlikkus infrastruktuurist kahes kohas:

1. Kas ekspertide peades.
2. Või need andmed asuvad mingitel masinatel, millest osa teavad ekspertid. Kuid pole kindel, et keegi väljastpoolt (kui meie meeskond peaks äkki kõik ühesuguste probleemide tõttu lahkuma) suudab aru saada, mis ja kuidas töötab. Masinas võib olla palju andmeid: ligipääsud, cron-tööd, pealeloodud (vt disk mounting) ketas ja lihtsalt lõputu nimekiri sellest, mis võiks juhtuda. Sellest on keeruline aru saada, mis tegelikult toimub.

Mõlemas olukorras satume lõksu, muutes end sõltuvaks:

• kas inimesest, kes on surelik, haigestuv, armumas, tujukas ja lihtsalt tavaliste lahkumiste tõttu;
• või füüsiliselt töötavast masinast, mis ka võib kokku kukkuda, varastada, tuua ootamatuid olukordi ja ebamugavusi.

Ilmselgelt kerkib lahendusena esile mõte, et ideaaljuhul tuleb kõik viia inimloetavasse, hooldatavasse, kvaliteetselt kirjutatud koodi.

Nii et infrastruktuur kui kood (Infrastructure as Code – IaC) on kogu olemasoleva infrastruktuuri kirjeldus koodina, samuti selle tööriistad ja meetodid, mis võimaldavad seda tegelikuks infrastruktuuriks muuta.

Miks tuleks kõik koodi tõlkidaInimesed ei ole masinad. Nad ei suuda kõike meelde jätta. Inimese ja masina reaktsioon on erinev. Kõik automatiseeritud toimib potentsiaalselt kiiremini kui see, mida teeb inimene. Kõige olulisem on see, et oleks üks tõe allikas (single source of truth).

Kust tulevad uued SRE-inseneridNii et me otsustasime kaasata uusi SRE-insenere, aga kust neid saada? Raamat õigete vastustega (Google SRE raamat) ütleb meile: arendajatest. Nad töötavad koodiga, samas kui teie saavutate ideaalse oleku.

Oleme pikka aega ja põhjalikult otsinud neid tööjõuturult väljaspool meie ettevõtet. Aga peame tunnistama, et ei leidnud kedagi, kes vastaks meie nõudmistele. PIDIME uurima oma seast.

Infra struktuuuri kui koodi probleemid

Vaatame nüüd näiteid sellest, kuidas infrastruktuur võib olla koodi sisse kirjutatud. Kood on hästi kirjutatud, kvaliteetne, koos kommentaaride ja sätetega.

Näide koodist Terraformis.

Näide koodist Ansible'is.

Head daamid ja härrad, aga kui kõik oleks nii lihtne! Me oleme reaalsetes oludes ja need suudavad teid alati üllatada, tuues esile probleeme. Siin ei ole erandiks.

1. Esimene probleem seisneb selles, et enamasti on IaC mingi DSL.

Ja DSL on omakorda struktuuri kirjeldus. Täpsemalt, mida sul peaks olema: Json, Yaml, suurte ettevõtete modifikatsioonid, kes on loonud oma DSL-i (Terraformis kasutatakse HCL-i).

Probleem on selles, et seal võivad puududa sellised tuttavad asjad nagu:

• muutujad;
• tingimused;
• mõnes kohas puuduvad kommentaarid, näiteks Jsonis, nende jaoks pole vaikimisi ette nähtud;
• funktsioonid;
• ja ma ei ole veel rääkinud sellistest kõrgema taseme asjadest nagu klassid, pärimine ja kõik selline.

2. Teine probleem sellise koodi puhul on see, et see on enamasti heterogeenne keskkond. Tavaliselt istute ja töötate C#-ga, s.t. ühe keele, ühe tehnoloogia, ühe ökosüsteemiga. Ja nüüd on teil tohutu tehnoloogiate mitmekesisus.

Tavaliselt on olukord, kus bash Pythoniga käivitab mingi protsessi, millele pannakse alla Json. Sa analüüsid seda, siis mingisugune generaator genereerib veel 30 faili. Kõikide nende jaoks sisendi muutujad tulevad Azure Key Vault'ist, mis on drone.io plugina kaudu, mis on kirjutatud Go-s, ja need muutujad lähevad läbi yaml-i, mis on saadud jsonnet'i templati generaatori tulemusena. Suhteliselt keeruline on omada rangelt hästi kirjeldatud koodi, kui sul on nii mitmekesine keskkond.

Traditsiooniline areng ühe ülesande raames toimub ühe keelega. Siin aga töötab suur hulk keeli.

3. Kolmas probleem on tööriistadega.. Oleme harjunud ägedate redaktoritega (Ms Visual Studio, Jetbrains Rider), mis teevad kõik meie eest. Ja isegi, kui me eksime, ütlevad nad, et me ei ole õiged. Tundub, et see on normaalne ja loomulik.

Aga kuskil lähedal on VSCode, kus on mõned pluginad, mis kuidagi installitakse, toetatakse või ei toeta. Tuli välja uusi versioone, kuid neid ei toetatud. Tavaline üleminek funktsiooni rakendamisele (isegi kui see on olemas) muutub keeruliseks ja mitte triviaalseteks probleemiks. Lihtne muutuja nimetuse muutmine – see on asendus projektis kümnes failis. On õnne, kui see asendab õiged asjad. Ükskord, muidugi, on kuskil valgustamine, on automaatkomplekteerimine, kuskil on vormindamine (kuid mul ei läinud see tööle Terraformis Windowsis).

Artikli kirjutamise hetkeks vscode-terraform plugin pole veel välja antud versiooni 0.12 toetamiseks, kuigi see on juba kolm kuud välja lastud.

On aeg unustada…

1. Silumine.
2. Refaktoreerimise tööriist.
3. Automaatne täiendamine.
4. Vigade avastamine kompileerimisel.

Naeruväärne, aga see suurendab arendusaega ja suurendab vigade arvu, mis on paratamatud.

Kõige hullem on, et meie peame mõtlema mitte sellele, kuidas projekteerida, jagada faile kaustadesse, dekompositsioneerida, teha koodi toetavaks, loetavaks ja nii edasi, vaid sellele, kuidas ma pean õigesti seda käsku kirjutama, sest ma kirjutasin selle kuidagi valesti.

Kuna uus inimene proovib õppida Terraformi, ei aita IDE teid selle osas üldse. Kui on dokumentatsioon - sisenen, vaatan. Kuid kui sisenete uude programmeerimiskeelde, siis IDE näitaks, et selline tüüp on olemas ja sellist pole. Ükskõik millisel juhul, int ja string tasemel. See on sageli kasulik.

Aga kuidas testidega?

Küsite: «Kuidas on testide asi, härrased programmeerijad?» Tõsised kutid testivad kõike tootmises, ja see on karm. Siin on näide üksustest terrafomi mooduli jaoks veebisaidilt. Microsoft.

Neil on hea dokumentatsioon. Microsoft on alati mulle meeldinud oma lähenemise tõttu dokumentatsioonile ja õppimisele. Kuid pole vaja olla onu Bob, et mõista, et kood ei ole siin ideaalne. Pange tähele, et valideerimine on tõstetud paremale.

Üksuse testi probleem on see, et saame kontrollida JSON-i korrektsust väljundis. Ma andsin 5 parameetrit, mulle tuli välja 2000 rea pikkune JSON. Ma saan analüüsida, mis siin toimub, valideerida testitulemust...

JSON-i analüüsimine Go-s on keeruline. Kuid tuleb kirjutada Go-s, sest terrafomi kirjutamine Go-s on hea praktika, et testida selles keeles, milles sa kirjutad. Koodi korraldus on väga nõrk. Sellegipoolest on see parim testimise teek.

Isegi Microsoft kirjutab oma mooduleid, testides neid niimoodi. Muidugi, see on avatud lähtekoodiga. Kõike, millest ma räägin, saad tulla ja parandada. Ma saan istuda ja nädalaga kõik korda teha, avada VS koodi pistikprogrammid, terrafomi, kirjutada pistikprogrammi raiderile. Võib-olla kirjutada paar analüsaatorit, lisada linterid, panustada testimise teeki. Ma saan kõik teha. Kuid ma ei peaks sellega tegelema.

Parimad praktikad infrastruktuuri kui koodi osas

Jätkame. Kui IaC-s ei ole teste, on IDE ja tööriistadega kehvasti, peaksid olema vähemalt parimad praktikad. Ma läksin lihtsalt Google Analyticsisse ja võrdlesin kahte otsingupäringut: Terraformi parimad praktikad ja C# parimad praktikad.

Mida me näeme? Raudne statistika ei ole meie kasuks. Materjali arvu poolest on sama. C# arenduses me lihtsalt ujume materjalides, meil on ülbed parimad praktikad, on raamatud, mis on kirjutatud ekspertide poolt, samuti raamatud, mis on kirjutatud raamatute kohta, mis on kirjutatud teiste ekspertide poolt, kes kritiseerivad neid raamatuid. Meres on ametlikku dokumentatsiooni, artikleid, koolituskursusi, praegu veel avatud lähtekoodiga arendust.

Mis puutub IaC päringusse: siin püüate killukaupa koguda teavet kõrgkoormuse ettekannetest või HashiConfi ametlikest dokumentidest ja paljusid probleeme GitHubis. Kuidas need moodulid üldse levitada, mida nendega teha? Tundub, et see on tõeline probleem... On ju olemas kogukond, härrased, kus igale küsimusele antakse sulle 10 kommentaari GitHubis. Kuid see ei ole kindel.

Kahjuks on hetkel eksperdid alles alustamas. Nende on liiga vähe. Ja kogu kogukond on alles algusjärgus.

Kuhu kõik see liigub ja mida teha

Võib kõik visata ja minna tagasi C# maailma, rahu juurde. Aga ei. Miks te üldse selle tegevuse juurde asusite, kui mitte lahenduse leidmiseks. Edasi toon oma subjektiivsed järeldused. Võite minuga kommenteerida, see oleks huvitav.

Isiklikult panustan mitmele asjale:

1. Selles valdkonnas areng toimub väga kiiresti. Toon välja DevOps'i päringute graafiku.

   
   
   Võib-olla on teema ärgitav, kuid see, et valdkond kasvab, annab teatavat lootust.

   Kui midagi kasvab nii kiiresti, siis kindlasti tulevad nutikad inimesed, kes ütlevad, kuidas peab tegema ja kuidas mitte. Populaarsuse suurenemine toob kaasa selle, et ehk on kellelgi aega lõpuks kirjutada jsonnet'i plugin vscode'ile, mis võimaldab minna funktsiooni rakendusse, mitte otsida seda ctrl+shift+f abil. Kui kõik areneb, on rohkem materjale. Google'i väljaanne SRE kohta on sellele hea näide.

2. On välja töötatud meetodid ja praktikaid tavapärases arenduses, mida saame siin edukalt rakendada. Jah, on nüansse testimise ja heterogeense keskkonnaga, puudulikud tööriistad, kuid on kogunenud tohutult praktikaid, mis võivad olla kasulikud ja abiks.

   Lihtne näide: paaristöö kaudu koostöö. See aitab tõeliselt aru saada. Kui sul on kõrval naaber, kes samuti püüab midagi mõista, siis koos saate paremini aru.

   Mõistmine, kuidas refaktoreerimist läbi viia, aitab isegi sellises olukorras seda teostada. See tähendab, et sa ei muuda kõike korraga, vaid muudad nimed, siis muudad asukohta, pärast seda võib-olla eraldad mingisuguse osa, oh, ja siin jääb kommentaaridest puudu.

Kokkuvõte

Kuigi mu mõtisklused võivad tunduda pessimistlikud, vaatan tulevikku lootusrikkalt ja loodan siiralt, et meil (ja teil) kõik õnnestub.

Järgneb teise artikli osa. Selles räägin, kuidas oleme proovinud rakendada paindliku arenduse praktikaid, et parandada meie õppimise ja infrastruktuuri haldamise protsessi.

Allikas: habr.com