V naši podjetju poteka postopek uvajanja ekipe SRE. V to zgodbo sem vstopil kot razvijalec. Med procesom so se mi pojavile misli in vpogledi, ki jih želim deliti z drugimi razvijalci. V tem članku razmišljanja govorim o tem, kaj se dogaja, kako se dogaja in kako živeti naprej s tem.
Nadaljevanje serije člankov, napisanih na podlagi predstavitev na našem notranjem dogodku. :
2. Infrastructure as code. (Tukaj ste)
3. Generacija Typescript pogodb iz C# modelov. (V teku…)
4. Uvod v algoritem konsenza Raft. (V teku…)
…
Odločili smo se ustanoviti ekipo SRE, uresničiti ideje . Zbrali smo programerje izmed naših razvijalcev in jih poslali na usposabljanje za več mesecev.
Pred ekipo so bile naslednje učne naloge:
- Opisati našo infrastrukturo, ki je večinoma v Microsoft Azure, v obliki kode (Terraform in vse, kar sodi zraven).
- Naučiti razvijalce dela z infrastrukturo.
- Pripraviti razvijalce na dežurstva.
Uvajamo koncept Infrastructure as code.
V običajnem modelu sveta (klasično administriranje) se znanje o infrastrukturi nahaja na dveh mestih:
- Bodisi kot znanje v glavah strokovnjakov.
- Bodisi so ti podatki shranjeni na nekaterih napravah, o katerih vedo strokovnjaki. Ni pa nujno, da bo nekdo od zunaj (v primeru, da naša ekipa nenadoma umre) lahko razumel, kaj in kako deluje. Na napravi je lahko veliko informacij: dostopi, cron naloge, podprti (glej ) disk in preprosto neskončen seznam stvari, ki se lahko zgodijo. Težko je razumeti, kaj se v resnici dogaja.
V obeh primerih se znajdemo v pasti, postanemo odvisni:
- bodisi od človeka, ki je smrten, podvržen boleznim, zaljubljanju, nihanju razpoloženja in preprostim odpuščanjem;
- bodisi od fizično delujoče naprave, ki tudi odpove, se ukrade, prinaša nepričakovane težave in nevšečnosti.
Seveda se pojavi rešitev, da bi v idealnem primeru vse prenesli v človeku berljivo, vzdrževano, kakovostno napisano kodo.
Tako je infrastruktura kao kod (Infrastructure as Code – IaC) opis cijele postojeće infrastrukture u obliku koda, kao i pratećih sredstava za rad s njom i realizaciju stvarne infrastrukture iz tog koda.
Zašto sve prevesti u kodLjudi nisu mašine. Ne mogu zapamtiti sve. Reakcija čovjeka i mašine je različita. Sve automatizirano potencijalno radi brže od onoga što radi čovjek. Najvažnije je imati jedan izvor istine (single source of truth).
Odakle dolaze novi SRE inženjeriDakle, odlučili smo uključiti nove SRE inženjere, ali gde ih naći? Knjiga sa pravim odgovorima () govori nam: od programera. Jer oni rade s kodom, dok vi dostižete idealno stanje.
Dugo smo tražili na tržištu rada van naše kompanije. Ali moramo priznati da nismo pronašli nijednog koji odgovara našim zahtevima. Morali smo pretražiti među svojim.
Problemi Infrastructure as Code
Sada hajde da pogledamo primere kako infrastruktura može biti utkana u kod. Kod je dobro napisan, kvalitetan, sa komentarima i uvlačenjima.
Primer koda iz Terraforma.
Primer koda iz Ansiblea.
Gospodo, ali da je sve tako jednostavno! Mi smo u stvarnom svetu, a on uvek spreman iznenaditi vas, doneti iznenađenja, probleme. Nema ih ni ovde.
1. Prvi problem je u tome što je u većini slučajeva IaC neka vrsta DSL-a.
A DSL, zauzvrat, je opis strukture. Tačnije, ono što bi ste trebali imati: Json, Yaml, modifikacije koje su osmislile velike kompanije koje su napravile svoj DSL (u Terraformu se koristi HCL).
Mala je neprijatnost da u njemu lako mogu nedostajati poznate stvari kao što su:
- varijable;
- uslovi;
- negde nema komentara, na primer, u Json-u, koji po defaultu nisu predviđeni;
- funkcije;
- i još nisam spomenuo visoko nivošne stvari poput klasa, nasleđivanja i slično.
2. Drugi problem takvog koda – često je to heterogena sredina. Obično sedite i radite s C#, tj. sa jednim jezikom, jednim stekom, jednom ekosistemom. A ovde imate ogromno raznolikost tehnologija.
Povsem realna situacija, ko bash s Pythonom zažene nek proces, v katerega se namesti Json. Analizirate ga, nato še nek generator izda še 30 datotek. Za vse to prihajajo vhodne spremenljivke iz Azure Key Vault, ki jih prenese vtičnik za drone.io, napisan v Go, in te spremenljivke gredo skozi yaml, ki je nastal kot rezultat generiranja iz predloge jsonnet. Kar precej zapleteno je imeti strogo dobro opisano kodo, ko imate tako raznoliko okolje.
Tradicionalni razvoj v okviru enega naloga poteka z enim jezikom. Tukaj pa delamo z veliko število jezikov.
3. Tretji problem – to je orodja.. Navadili smo se na odlične urejevalnike (Ms Visual Studio, Jetbrains Rider), ki vse naredijo namesto nas. In celo, če zgrešimo, nam povedo, da nismo pravi. Zdi se, da je to normalno in naravno.
Ampak nekje blizu je VSCode, v katerem so nekateri vtičniki, ki se nekako namestijo, podpirajo ali ne podpirajo. Izkazali so se nove različice, in jih niso podprli. Prehod k implementaciji funkcije (tudi če obstaja) postane zapletena in nenavadna težava. Enostavno preimenovanje spremenljive je zamenjava v projektu iz desetih datotek. Imate srečo, če zamenja tisto, kar je treba. Seveda je nekje osvetlitev, nekje je avtokompletiranje, nekje je formatiranje (res pa se mi v Terraformu na Windows ni posrečilo).
Ob času pisanja članka še niso izdali za podporo različici 0.12, čeprav je že tri mesece na voljo.
Prišel je čas, da pozabimo na…
- Odpravljanje napak.
- Orodje za prestrukturiranje.
- Samodejno zaključevanje.
- Odkrivanje napak pri prevajanju.
Smešno, a povečuje čas razvoja in povečuje število napak, ki se neizogibno pojavijo.
Najhujše je, da moramo razmišljati ne o tem, kako zasnovati, razvrstiti datoteke po mapah, dekompoziciji, narediti kodo obvladljivo, berljivo in tako naprej, ampak o tem, kako naj pravilno napišem to ukaz, ker sem ga napisal nekako napačno.
Kot novinec poskušate spoznati Terraform, IDE pa vam pri tem ne pomaga. Ko je dokumentacija – vstopite, pogledate. Ampak če bi se učili novega programskega jezika, bi vam IDE povedal, da obstaja tak tip, tak pa ne. Vsaj na ravni int ali string. To je pogosto koristno.
Kaj pa testi?
Pitate se: „Kako testirati, gospodo programeri?“ Ozbiljni momci testiraju sve na produkciji, i to je strogo. Evo primera unit testa za terraform modul sa sajta .
Imaju odličnu dokumentaciju. Microsoft mi je uvek bio simpatičan zbog svog pristupa dokumentaciji i obrazovanju. Ali ne morate biti ujne Bob da shvatite da ovde nije savršen kod. Obratite pažnju na validaciju, koja je pomerena udesno.
Problem unit testa je u tome što možemo proveriti tačnost JSON-a na izlazu. Ubacio sam 5 parametara, dobio sam dugačak JSON od 2000 redova. Mogu analizirati šta se ovde dešava, validirati test rezultat...
Teško je analizirati JSON u Go-u. A potrebno je pisati u Go-u, jer je terraform na Go-u – dobra praksa testiranja u jeziku u kojem pišete. Sama organizacija koda je vrlo slaba. Ipak, ovo je najbolja biblioteka za testiranje.
Microsoft sam piše svoje module, testirajući ih na ovaj način. Naravno, ovo je Open Source. Sve o čemu govorim možete doći i popraviti. Mogu se posvetiti i za nedelju dana sve popraviti, open-sourceovati VS-code dodatke, terraform, napraviti dodatak za rider. Možda napisati nekoliko analizatora, dodati lintere, doprineti biblioteci za testiranje. Sve mogu uraditi. Ali ne bih trebao time da se bavim.
Najbolje prakse Infrastructure as code
Idemo dalje. Ako u IaC nema testova, loša je situacija sa IDE-om i alatima, onda barem moraju postojati najbolje prakse. Jednostavno sam otišao u Google analitiku i uporedio dva pretraživačka upita: Terraform best practices i c# best practices.
Šta vidimo? Nemilosrdnu statistiku koja nije u našu korist. Po količini materijala – isto. U C# razvoju jednostavno se kupamo u materijalima, imamo vrhunske prakse, postoje knjige napisane ekspertima, kao i knjige napisane o knjigama drugih eksperata koji kritikuju te knjige. More zvanične dokumentacije, članaka, obrazovnih kurseva, sada još i open source razvoj.
Što se tiče upita po IaC: ovde pokušavate da sakupite informacije sa predavanja u vezi sa high-load-om ili HashiConf, iz zvanične dokumentacije i brojnih issue-a na GitHub-u. Kako uopšte rasporediti te module, šta raditi s njima? Čini se da je to pravi problem… Postoji zajednica, gospodo, gde na svako pitanje dobijate 10 komentara na GitHub-u. Ali, to nije uvek tačno.
Na žalost, strokovnjaki šele začetki prihajajo na sceno. Trenutno je jih premalo. Samo skupnost je še v povojih.
Kam vse to vodi in kaj storiti
Lahko bi vse pustil in se vrnil k C#, v svet rajderja. A ne. Zakaj bi se sploh ukvarjali s tem, če ne bi iskali rešitve. Tukaj vam prinašam svoje subjektivne zaključke. Lahko me ovržete v komentarjih, bi bilo zanimivo.
Osebno stavim na več stvari:
- Razvoj na tem področju poteka zelo hitro. Prikazujem graf povpraševanja po DevOps.
Morda je tema aktualna, a sam dejstvo, da se področje razvija, daje nek upanje.Če nekaj tako hitro raste, se brez dvoma pojavijo pametni ljudje, ki povedo, kako je treba delati in kako ne. Povečanje priljubljenosti pomeni, da bo morda kdo končno imel čas, da doda vtičnik za jsonnet za vscode, ki bo omogočil prehod na implementacijo funkcije, namesto da jo iščem skozi ctrl+shift+f. Ko se vse razvija, je na voljo več gradiva. Izid knjige od Googla o SRE-ju je odličen primer tega.
- Obstoječe metode in prakse v običajnem razvoju, ki jih lahko uspešno uporabimo tukaj. Da, obstajajo razlike z poznavanjem in heterogenim okoljem, pomanjkljiva orodja, a je zbrano ogromno praks, ki bi lahko bile koristne in pomagale.
Povsem preprost primer: sodelovanje prek pair programming. To zelo pomaga pri razumevanju. Ko imaš ob sebi soseda, ki tudi poskuša razumeti, bosta skupaj bolje razumela.
Razumevanje, kako se izvaja refaktoring, pomaga tudi v taki situaciji. To pomeni, da ne moreš vsega spremeniti hkrati, ampak najprej spremeniš poimenovanje, nato razporeditev, nato lahko izpostaviš določen del, oh, tukaj pa primanjkuje komentarjev.
Zaključek
Kljub temu, da se morda moja razmišljanja zdijo pesimistična, z zaupanje gledam v prihodnost in iskreno upam, da nam (in vam) uspe.
Nato pripravljamo drugi del članka. V njem bom predstavil, kako smo poskušali uporabiti prakse agilnega razvoja za izboljšanje našega učnega procesa in dela z infrastrukturo.
Izvor: habr.com
