Infrastruktura kao šifra: prvo upoznavanje

Naša kompanija je u procesu uključivanja SRE tima. U cijelu ovu priču sam došao sa razvojne strane. U tom procesu došao sam do misli i uvida koje želim podijeliti s drugim programerima. U ovom članku o razmišljanju govorim o tome šta se dešava, kako se dešava i kako svi mogu da nastave da žive sa tim.

Nastavak serije članaka napisanih na osnovu govora na našem internom događaju DevForum:

1. Schrödingerova mačka bez kutije: problem konsenzusa u distribuiranim sistemima.
2. Infrastruktura kao kod. (Ti si ovdje)
3. Generiranje Typescript ugovora korištenjem C# modela. (U toku...)
4. Uvod u Raft konsenzus algoritam. (U toku...)
...

Odlučili smo da napravimo SRE tim koji će implementirati ideje google sre. Angažovali su programere iz reda vlastitih programera i poslali ih na nekoliko mjeseci obuke.

Tim je imao sljedeće trening zadatke:

• Opišite našu infrastrukturu, koja je uglavnom u Microsoft Azureu u obliku koda (Terraform i sve okolo).
• Naučite programere kako da rade sa infrastrukturom.
• Pripremite programere za dužnost.

Uvodimo koncept infrastrukture kao koda

U uobičajenom modelu svijeta (klasična administracija) znanje o infrastrukturi nalazi se na dva mjesta:

1. Ili u vidu znanja u glavama stručnjaka.
2. Ili su ove informacije na nekim pisaćim mašinama, od kojih su neke poznate stručnjacima. Ali nije činjenica da će autsajder (u slučaju da nam cijeli tim iznenada umre) moći shvatiti šta i kako funkcionira. Može biti puno informacija o mašini: dodatna oprema, cronjobs, zastrašeni (vidi. montaža na disk) disk i samo beskrajna lista onoga što se može dogoditi. Teško je razumeti šta se zaista dešava.

U oba slučaja nalazimo se zarobljeni u tome da postanemo zavisni:

• ili od osobe koja je smrtna, podložna bolestima, zaljubljivanjima, promjenama raspoloženja i jednostavno banalnim otpuštanjima;
• ili sa fizički ispravne mašine, koja takođe padne, bude ukradena i predstavlja iznenađenja i neprijatnosti.

Podrazumijeva se da bi u idealnom slučaju sve trebalo biti prevedeno u čovjeku čitljiv, održavan i dobro napisan kod.

Dakle, infrastruktura kao kod (Incfastructure as Code - IaC) predstavlja opis cjelokupne postojeće infrastrukture u obliku koda, kao i pripadajućih alata za rad sa njom i implementaciju stvarne infrastrukture iz nje.

Zašto sve prevoditi u kod?Ljudi nisu mašine. Ne mogu se sjetiti svega. Reakcija osobe i mašine je drugačija. Sve što je automatizirano potencijalno je brže od bilo čega što radi čovjek. Najvažnija stvar je jedan izvor istine.

Odakle dolaze novi SRE inženjeri?Dakle, odlučili smo da zaposlimo nove SRE inženjere, ali odakle ih nabaviti? Rezerviši sa tačnim odgovorima (Google SRE knjiga) nam kaže: od programera. Na kraju krajeva, oni rade sa kodom, a vi postižete idealno stanje.

Dugo smo ih tražili na tržištu kadrova van naše kompanije. Ali moramo priznati da nismo našli nikoga ko bi odgovarao našim zahtjevima. Morao sam tražiti među svojim ljudima.

Problemi Infrastruktura kao kod

Pogledajmo sada primjere kako infrastruktura može biti tvrdo kodirana u kod. Kod je dobro napisan, kvalitetan, sa komentarima i uvlačenjima.

Primjer koda iz Terraforme.

Primjer koda iz Ansiblea.

Gospodo, samo da je tako jednostavno! Mi smo u stvarnom svetu, i on je uvek spreman da vas iznenadi, podnese iznenađenja i probleme. Ni ovdje se ne može bez njih.

1. Prvi problem je što je u većini slučajeva IaC neka vrsta dsl-a.

A DSL je, zauzvrat, opis strukture. Tačnije šta treba da imate: Json, Yaml, modifikacije nekih velikih kompanija koje su smislile svoj dsl (HCL se koristi u terraformu).

Problem je u tome što lako ne sadrži poznate stvari kao što su:

• varijable;
• uslovi;
• negdje nema komentara, na primjer, u Json-u, oni po defaultu nisu dati;
• funkcije;
• a ja čak i ne govorim o tako visokim stvarima kao što su klase, nasljeđe i sve to.

2. Drugi problem kod takvog koda je što je najčešće heterogeno okruženje. Obično sjedite i radite sa C#, tj. sa jednim jezikom, jednim stekom, jednim ekosistemom. I ovdje imate ogromnu raznolikost tehnologija.

Vrlo je realna situacija kada bash sa pythonom pokrene neki proces u koji je umetnut Json. Ti to analiziraš, onda neki drugi generator proizvodi još 30 fajlova. Za sve ovo, ulazne varijable se primaju iz Azure Key Vault-a, koje su spojene pomoću dodatka za drone.io napisan u Go-u, a te varijable prolaze kroz yaml, koji je generiran kao rezultat generiranja iz jsonnet šablonskog motora. Prilično je teško imati striktno dobro opisan kod kada imate tako raznoliko okruženje.

Tradicionalni razvoj u okviru jednog zadatka dolazi sa jednim jezikom. Ovdje radimo sa velikim brojem jezika.

3. Treći problem je podešavanje. Navikli smo na cool editore (Ms Visual Studio, Jetbrains Rider) koji rade sve umjesto nas. A čak i da smo glupi, reći će da nismo u pravu. Deluje normalno i prirodno.

Ali negdje u blizini postoji VSCode, u kojem postoje neki dodaci koji su nekako instalirani, podržani ili nepodržani. Nove verzije su izašle i nisu bile podržane. Banalni prijelaz na implementaciju funkcije (čak i ako postoji) postaje složen i netrivijalan problem. Jednostavno preimenovanje varijable je repriza u projektu od desetak datoteka. Imat ćeš sreće ako stavi ono što ti treba. Naravno, tu i tamo postoji pozadinsko osvjetljenje, postoji auto-dovršavanje, negdje postoji formatiranje (iako meni nije išlo u terraformu na Windows-u).

U vrijeme pisanja ovog teksta vscode-terraform dodatak još nisu objavljeni da podržavaju verziju 0.12, iako je objavljena već 3 mjeseca.

Vrijeme je da zaboravimo na...

1. Otklanjanje grešaka.
2. Alat za refaktoring.
3. Automatsko dovršavanje.
4. Otkrivanje grešaka tokom kompilacije.

Smiješno je, ali ovo također povećava vrijeme razvoja i povećava broj grešaka koje se neizbježno javljaju.

Najgore je što smo primorani da razmišljamo ne o tome kako da dizajniramo, organizujemo fajlove u fascikle, dekomponujemo, učinimo kod održavanim, čitljivim i tako dalje, već o tome kako da pravilno napišem ovu naredbu, jer sam je nekako pogrešno napisao .

Kao početnik, pokušavate naučiti terraforme, a IDE vam uopće ne pomaže. Kad bude dokumentacije, uđite i pogledajte. Ali ako ulazite u novi programski jezik, IDE bi vam rekao da postoji takav tip, ali ne postoji. Barem na nivou int ili niza. Ovo je često korisno.

Šta je sa testovima?

Pitate: "Šta je sa testovima, gospodo programeri?" Ozbiljni momci sve testiraju u proizvodnji, i teško je. Evo primjera jediničnog testa za terraform modul sa web stranice Microsoft.

Imaju dobru dokumentaciju. Oduvijek mi se sviđao Microsoft zbog svog pristupa dokumentaciji i obuci. Ali ne morate biti ujak Bob da biste shvatili da ovo nije savršen kod. Obratite pažnju na validaciju na desnoj strani.

Problem s jediničnim testom je u tome što vi i ja možemo provjeriti ispravnost Json izlaza. Ubacio sam 5 parametara i dobio sam Json krpu za noge sa 2000 linija. Mogu analizirati šta se ovdje dešava, potvrditi rezultate testa...

Teško je raščlaniti Json u Go. I morate pisati u Go, jer je terraform u Go dobra praksa za testiranje na jeziku na kojem pišete. Organizacija samog koda je veoma slaba. Istovremeno, ovo je najbolja biblioteka za testiranje.

Microsoft sam piše svoje module, testirajući ih na ovaj način. Naravno da je otvorenog koda. Sve o čemu pričam možeš doći i popraviti. Mogu sjesti i popraviti sve za tjedan dana, open source VS code dodatke, terraforme, napraviti dodatak za vozača. Možda napisati par analizatora, dodati lintere, dodati biblioteku za testiranje. Mogu sve. Ali to nije ono što bih trebao raditi.

Najbolje prakse Infrastruktura kao kod

Idemo dalje. Ako u IaC-u nema testova, IDE i podešavanje su loši, onda bi barem trebalo postojati najbolje prakse. Upravo sam otišao na Google Analytics i uporedio dva upita za pretraživanje: najbolje prakse Terraforma i najbolje prakse za C#.

šta vidimo? Nemilosrdna statistika nam ne ide u prilog. Količina materijala je ista. U razvoju C#, jednostavno smo preplavljeni materijalima, imamo super-najbolje prakse, postoje knjige koje su napisali stručnjaci, a takođe i knjige koje su napisali na knjigama drugih stručnjaka koji kritikuju te knjige. More službene dokumentacije, članaka, kurseva obuke, a sada i open source razvoja.

Što se tiče IaC zahtjeva: ovdje pokušavate prikupiti informacije malo po malo iz highload ili HashiConf izvještaja, iz službene dokumentacije i brojnih problema na Githubu. Kako općenito distribuirati ove module, šta raditi s njima? Čini se da je ovo pravi problem... Postoji zajednica, gospodo, gdje ćete za svako pitanje dobiti 10 komentara na Githubu. Ali nije baš.

Nažalost, u ovom trenutku stručnjaci tek počinju da se pojavljuju. Za sada ih je premalo. A sama zajednica se druži na rudimentarnom nivou.

Kuda sve ovo vodi i šta da se radi

Možete odbaciti sve i vratiti se na C#, u svijet jahača. Ali ne. Zašto biste se uopće trudili da radite ovo ako ne možete pronaći rješenje. U nastavku iznosim svoje subjektivne zaključke. Možete se svađati sa mnom u komentarima, biće zanimljivo.

Lično se kladim na nekoliko stvari:

1. Razvoj u ovoj oblasti se odvija veoma brzo. Evo rasporeda zahtjeva za DevOps.

   
   
   Tema može biti hype, ali sama činjenica da sfera raste daje nadu.

   Ako nešto tako brzo raste, onda će se sigurno pojaviti pametni ljudi koji će vam reći šta da radite, a šta ne. Povećanje popularnosti dovodi do toga da će možda neko imati vremena da konačno doda dodatak u jsonnet za vscode, koji će vam omogućiti da pređete na implementaciju funkcije, a ne da je tražite preko ctrl+shift+f. Kako se stvari razvijaju, pojavljuje se sve više materijala. Izdanje Google-ove knjige o SRE je odličan primjer za to.

2. Postoje razvijene tehnike i prakse u konvencionalnom razvoju koje ovdje možemo uspješno primijeniti. Da, postoje nijanse s testiranjem i heterogenim okruženjem, nedovoljno alata, ali se nakupio ogroman broj praksi koje mogu biti korisne i korisne.

   Trivijalan primjer: saradnja kroz programiranje u paru. Mnogo pomaže da se to shvati. Kada imate komšiju u blizini koji takođe pokušava nešto da razume, zajedno ćete bolje razumeti.

   Razumijevanje načina na koji se vrši refaktoring pomaže da se izvrši čak iu takvoj situaciji. Odnosno, ne možete promijeniti sve odjednom, već promijenite naziv, pa promijenite lokaciju, onda možete istaknuti neki dio, oh, ali ovdje nema dovoljno komentara.

zaključak

Unatoč činjenici da moje razmišljanje može izgledati pesimistično, gledam u budućnost s nadom i iskreno se nadam da će nam (i vama) sve uspjeti.

U pripremi je drugi dio članka. U njemu ću govoriti o tome kako smo pokušali da iskoristimo agilne razvojne prakse da poboljšamo naš proces učenja i rad sa infrastrukturom.

izvor: www.habr.com