Meie ettevõttes on käimas SRE meeskonna onboardimise protsess. Alustasin seda teekonda arenduspoolelt. Protsessi käigus tekkisid mul mõtted ja arusaamad, mida tahan teiste arendajatega jagada. Selles mõtteartiklis räägin, mis toimub, kuidas see toimub ja kuidas kõik sellega edasi elavad.
Jätkub artiklite seeria, mis on inspireeritud esinemistest meie siseüritusel. :
2. Infrastruktuur kui kood. (Sa oled siin)
3. TypeScripti lepingute genereerimine C# mudelite põhjal. (Töös…)
4. Sisetulek konsensuse algoritmi Raft. (Töös…)
…
Otsustasime luua SRE meeskonna, ellu viies ideed . Koondasime programmistid oma arendajatest ja saatsime nad mitmeks kuuks koolitusele.
Meeskonna ees seisis järgmine õpiküsimuste loetelu:
- Käesolev infrastruktuur, mis enamasti asub Microsoft Azure'is, peab olema kirjeldatud koodis (Terraform ja kõik muu, mis sellega seondub).
- Koolitada arendajaid infrastruktuuri töödega.
- Valmistada arendajad ette valvekordade jaoks.
Tutvustame mõistet Infrastructure as code.
Tavapärases maailmamudelisse (klassikalises halduses) on teadlikkus infrastruktuurist kahes kohas:
- Kas ekspertide peades olevate teadmiste kujul.
- Või on need andmed mingites masinates, millest osa teavad eksperdid. Aga ei ole kindel, et väljast tulev inimene (kui meie kogu meeskond äkki sureb) suudab aru saada, mis ja kuidas töötab. Masinas võib olla palju teavet: juurdepääsud, cron-tööd, monteeritud (vt ) ketas ja lihtsalt lõputu nimekiri sellest, mis võib juhtuda. Selle põhjal on keeruline mõista, mis tegelikult toimub.
Mõlemas juhul satume lõksu, muutudes sõltuvaks:
- kui inimesest, kes on surelik, haavatav haigustele, armumistele, tuju kõikumisele ja lihtsalt banaalsetele lahkumistele;
- või füüsiliselt töötavast masinast, mis samuti võib laguneda, varastada, tuua esile ootamatusi ja ebamugavusi.
Tuleb loomulikult välja mõelda lahendus, et ideaalis peaks kõik olema viidud arusaadavasse, hooldatavasse ja kvaliteetselt kirjutatud koodi.
Seega infrastruktuur kui kood (Infrastructure as Code – IaC) on olemasoleva infrastruktuuri kirjeldamine koodina, samuti sellega töötamiseks ja selleks reaalse infrastruktuuri elluviimiseks vajalikud tööriistad.
Miks tõlkida kõik koodiInimesed ei ole masinad. Nad ei suuda kõike meeles pidada. Inimese ja masina reaktsioon on erinev. Kõik automatiseeritud töötab potentsiaalselt kiiremini kui kõik, mida inimene teeb. Kõige olulisem on, et oleks üks tõeallikas (single source of truth).
Kust tulevad uued SRE-inseneridNii et oleme otsustanud värvata uusi SRE-insenere, kuid kust neid leida? Raamat õigeid vastuseid () ütleb meile: arendajatest. Lõpp afinal töötavad nad koodiga ja te saavutate ideaalset seisundit.
Oleme palju ja kaua otsinud neid tööjõuturult väljaspool meie ettevõtet. Kuid peame tunnistama, et ei leidnud ühtki, kes vastaks meie nõudmistele. Pidi vaatama oma seast.
Probleemid Infrastructure as Code'iga
Vaadakem nüüd näiteid selle kohta, kuidas infrastruktuur võib olla koodi sisse kirjutatud. Kood on hästi kirjutatud, kvaliteetne, kommentaaride ja sissetõmmetega.
Koodi näide Terraformist.
Koodi näide Ansible'ist.
Härra, kui ainult kõik oleks nii lihtne! Me oleme ju reaalsetes tingimustes ja need on alati valmis üllatama, tuues esile probleeme. Siin ei saa ka ilma nendeta.
1. Esimene probleem on see, et enamikul juhtudel on IaC mingi DSL.
Ja DSL on omakorda struktuuri kirjeldus. Täpsemalt, see, mis sul olema peab: JSON, YAML, suuremate ettevõtete modifikatsioonid, kes on loonud oma DSL-i (Terraformis kasutatakse HCL-i).
Mure on selles, et see võib kergesti mitte sisaldada selliseid tuttavaid elemente nagu:
- muutujad;
- tingimused;
- kusagil ei ole kommentaare, näiteks JSON-is ei ole neid vaikimisi;
- funktsioonid;
- ja ma ei ole veel rääkinud sellistest kõrgema taseme asjadest nagu klassid, pärilikkus ja kõik muu.
2. Teine sellise koodi probleem on see, et see on enamasti heterogeenne keskkond.Tavaliselt istud ja töötad C#-ga, st ühe keele, ühe stack-i, ühe ökosüsteemiga. Ja nüüd on sul tohutu tehnoloogiate mitmekesisus.
Väga reaalne olukord, kus bash Pythonis käivitab mingi protsessi, kuhu sisestatakse Json. Te analüüsite seda, seejärel annab mingi generaator veel 30 faili. Kõik need sisendmuutujad tulevad Azure Key Vaultist, mis on tõmmatud drone.io pistikprogrammiga, mis on kirjutatud Go keeles, ja need muutujad läbivad yaml'i, mis on saadud jsonnet'i mallist genereerimise tulemusena. On üsna keeruline omada rangelt hästi dokumenteeritud koodi, kui teil on nii mitmekesine keskkond.
Traditsiooniline arendus ühe ülesande raames käib ühe keelega. Siiski töötame me siin suure hulga keeltes.
3. Kolmas probleem on tööriistad.. Oleme harjunud ägedate redigeerijate (Ms Visual Studio, Jetbrains Rider) kasutamisega, mis teevad kõik meie eest. Ja isegi kui me eksime, ütlevad nad, et me pole õ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 toetata. Uued versioonid on välja tulnud, kuid neid ei ole toetatud. Lihtne üleminek funktsiooni rakendamisele (isegi kui see olemas on) muutub keeruliseks ja mitte triviaalseks probleemiks. Lihtne muutuja ümbernimetamine on projektis asendus kümnes failis. Õnnestub, kui see tõesti teeb vajalikud asendused. Muidugi on seal kuskil esiletõstmine, automaatne lõpetamine, kuskil on vormindus (tõsi, mul ei hakanud see Windowsis Terrraformis tööle).
Artikli kirjutamise hetkel veel ei ole välja antud versiooni 0.12 toetamiseks, kuigi see on juba kolm kuud välja antud.
On aeg unustada…
- Silumisega.
- Refaktooringutööriist.
- Automaatne lõpetamine.
- Vigu tuvastades kompileerimisel.
Naljakas, aga see tõstab arendusaega ja suurendab vigade arvu, mis paratamatult tekivad.
Kõige hullem on see, et me oleme sunnitud mõtlema mitte sellele, kuidas projekteerida, faile kaustades jaotada, dekompositsioonida, teha koodi hooldatavaks, loetavaks jne, vaid sellele, kuidas ma selle käsu õigesti kirjutaksin, sest ma kirjutasin selle kuidagi valesti.
Kuna algaja proovite mõista Terraformi, ja IDE ei aita teid selle juures sugugi. Kui on dokumentatsioon – logite sisse, vaatate üle. Aga kui te siseneksite uude programmeerimiskeelde, siis IDE annaks teada, et selline tüüp on olemas, aga sellist pole. Vähemalt int või string tasemel. See on sageli kasulik.
Aga kuidas jääb testidega?
Te võite küsida: „Aga kuidas jääb testidega, härra programmistid?” Tõsised kutid testivad kõike tootmises, ja see on karm. Siin on näide ühi-testist Terraformi mooduli jaoks saidilt. .
Neil on hea dokumentatsioon. Microsoft on mulle alati meeldinud oma lähenemise tõttu dokumentatsioonile ja koolitusele. Kuid ei pea olema onu Bob, et mõista, et siin pole ideaalne kood. Pöörake tähelepanu valideerimisele, mis on viidud paremale.
Ühi-testi probleem on see, et me saame kontrollida Jsoni korrektsust väljundis. Ma sisestasin 5 parameetrit, ja mulle anti 2000 rida Jsoni. Ma saan analüüsida, mis siin toimub, valideerida testitulemust...
JSON-i analüüsimine Go-s on keeruline. Samas on vajalik kirjutada Go-s, kuna Terraform Go-s on hea praktika, et testida selles keeles, milles sa kirjutad. Koodi struktuur on väga nõrk. Sellegipoolest on see parim raamatukogu testimiseks.
Isegi Microsoft kirjutab oma mooduleid, testides neid sellisel viisil. Loomulikult on see avatud lähtekoodiga. Kõike, millest ma räägin, saad tulla ja parandada. Ma võin istuda ja nädala jagu kõik parandada, avatud lähtekoodiga VS-koodipluginad, Terraform'i, teha plugina Riderile. Võib-olla kirjutada paar analüsaatorit, lisada linte, anda panuse testimise raamatukokku. Kõike saan teha. Aga ma ei peaks sellega tegelema.
Parimad praktikad infrastruktuuri kui koodi puhul
Liikume edasi. Kui IaC-s ei ole teste, on IDE ja tööriistadega halb, siis peavad olema vähemalt parimad praktikad. Läksin lihtsalt Google Analyticsisse ja tegin võrdluse kahe otsingu vahel: Terraformi parimad praktikad ja C# parimad praktikad.
Mida me näeme? Raudne statistika ei ole meie heaks. Materjali osas on olukord sama. C# arenduses oleme lihtsalt üle ujutatud materjalidest – meil on parimad praktikad, ekspertide kirjutatud raamatud ning samuti raamatud, mis on kirjutatud teiste ekspertide poolt, kes kritiseerivad neid raamatuid. Hulgaliselt ametlikku dokumentatsiooni, artikleid, koolituskursusi ning nüüd ka open source arendust.
Mis puutub IaC päringusse: siin püüate killukehaaval koguda teavet highload konverentsidelt või HashiConf'ilt, ametlikest dokumentatsioonidest ja arvukatest probleemidest GitHubis. Kuidas need moodulid õigesti laiendada, mida nendega teha? Tundub, et see on tõeline probleem… Meil on ju olemas kogukond, head inimesed, kus iga küsimuse peale antakse teile 10 kommentaari GitHubis. Aga see ei ole sugugi kindel.
Kahjuks hakkavad eksperdid alles nüüd välja tulema. Praegu on neid veel liiga vähe. Ja kogu kogukond on veel algusjärgus.
Kuhu see kõik suundub ja mida teha?
Võid kõik ringi teha ja naasta C# maailma, aga miks? Miks sa üldse teeksid nii, kui pole lahendust leida. Allpool toon välja oma subjektiivsed järeldused. Saate minuga kommenteerida, oleks huvitav.
Isiklikult panustan mitmele asjale:
- Areng sellel alal toimub väga kiiresti. Toon välja DevOps'i päringute graafiku.
Võib-olla on teema moes, kuid see, et valdkond kasvab, annab teatud lootust.Kui midagi kasvab nii kiiresti, siis kindlasti tekivad targad inimesed, kes ütlevad, kuidas asju teha ja kuidas mitte. Populaarsuse suurenemine võib tähendada, et lõpuks kellegil on aega lõpetada jsonnet plugin vscode'ile, mis võimaldab liikuda funktsiooni rakenduse juurde, mitte otsida seda läbi ctrl+shift+f. Kui kõik areneb, tuleb rohkem materjale. Google'i uus SRE raamat on suurepärane näide sellest.
- On olemas välja töötatud meetodid ja praktikad tavaarenduses, mida saame siin edukalt rakendada. Jah, testimise ja heterogeense keskkonna osas on nüansse, tööriistade puudujäägid, kuid on kogunenud tohutult praktikaid, mis võivad olla kasulikud ja abi pakkuda.
Üks lihtne näide: koostöö läbi paaritöö. See aitab tõeliselt arusaamist parandada. Kui sul on kõrval naaber, kes üritab ka midagi mõista, siis koos mõistate paremini.
Mõistmine, kuidas refaktoreerida, aitab isegi sellises olukorras seda teostada. See tähendab, et sa ei pea kohe kõike muutma, vaid saad alustada nimedest, seejärel asukohast, ja pärast võib-olla eraldada mingi osa. Oi, ja siia jääb kommenteerimisest puudu.
Kokkuvõte
Kuigi minu mõtted võivad tunduda pessimistlikud, vaatan ma tulevikku lootusrikkalt ja loodan siiralt, et meil (ja teil) läheb kõik hästi.
Järgmine osa artiklist on valmimas. Selles räägin sellest, kuidas proovime rakendada paindliku arenduse praktikaid, et parandada meie õppeprotsessi ja tööd infrastruktuuriga.
Allikas: habr.com
