Naša tvrtka je u procesu uključivanja SRE tima. Ja sam u cijelu ovu priču ušao s razvojne strane. U procesu sam došao do razmišljanja i uvida koje želim podijeliti s drugim programerima. U ovom članku za razmišljanje govorim o tome što se događa, kako se događa i kako svi mogu nastaviti živjeti s tim.
Nastavak serije članaka nastalih na temelju govora na našem internom događaju :
2. Infrastruktura kao šifra. (Ti si ovdje)
3. Generiranje Typescript ugovora korištenjem C# modela. (U nastajanju...)
4. Uvod u Raftov konsenzusni algoritam. (U nastajanju...)
...
Odlučili smo stvoriti SRE tim koji će implementirati ideje . Regrutirali su programere među vlastitim programerima i poslali ih na nekoliko mjeseci obuke.
Tim je imao sljedeće trenažne zadatke:
- Opišite našu infrastrukturu koja je uglavnom u Microsoft Azureu u obliku koda (Terraform i sve okolo).
- Naučite programere kako raditi s infrastrukturom.
- Pripremite programere za dužnost.
Predstavljamo koncept infrastrukture kao koda
U uobičajenom modelu svijeta (klasična administracija) znanje o infrastrukturi nalazi se na dva mjesta:
- Ili u obliku znanja u glavama stručnjaka.
- Ili se ti podaci nalaze na nekim pisaćim strojevima, od kojih su neki stručnjacima poznati. Ali nije činjenica da će autsajder (u slučaju da cijeli naš tim iznenada umre) moći shvatiti što i kako radi. Na stroju može biti mnogo informacija: pribor, cronjobs, zastrašeni (vidi. ) disk i samo beskonačan popis onoga što se može dogoditi. Teško je razumjeti što se zapravo događa.
U oba slučaja nalazimo se zarobljeni u ovisnosti:
- ili od osobe koja je smrtna, podložna bolestima, zaljubljivanjima, promjenama raspoloženja i jednostavno banalnim otkazima;
- ili od fizički radnog stroja, koji također pada, biva ukraden i predstavlja iznenađenja i neugodnosti.
Podrazumijeva se da bi u idealnom slučaju sve trebalo biti prevedeno u dobro napisan kod koji je čitljiv ljudima i koji se može održavati.
Dakle, infrastruktura kao kod (Incfastructure as Code - IaC) je opis cjelokupne postojeće infrastrukture u obliku koda, kao i povezanih alata za rad s njom i implementaciju stvarne infrastrukture iz nje.
Zašto sve prevoditi u kod?Ljudi nisu strojevi. Ne mogu se svega sjetiti. Reakcija čovjeka i stroja je različita. Sve što je automatizirano potencijalno je brže od bilo čega što radi čovjek. Najvažniji je jedan izvor istine.
Odakle dolaze novi SRE inženjeri?Dakle, odlučili smo zaposliti nove SRE inženjere, ali odakle ih naći? Knjiga s točnim odgovorima () govori nam: od programera. Uostalom, oni rade s kodom, a vi postižete idealno stanje.
Dugo smo ih puno tražili na tržištu kadrova izvan naše tvrtke. No, moramo priznati da nismo našli nikoga tko bi odgovarao našim zahtjevima. Morao sam tražiti među svojima.
Problemi Infrastruktura kao kod
Sada pogledajmo primjere kako se infrastruktura može ukodirati u kod. Kod je dobro napisan, kvalitetan, s komentarima i uvlakama.
Primjer koda iz Terraforme.
Primjer koda iz Ansiblea.
Gospodo, kad bi barem bilo tako jednostavno! Mi smo u stvarnom svijetu, a on je uvijek spreman iznenaditi vas, postaviti vam 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 pak opis strukture. Točnije, ono što trebate imati: Json, Yaml, modifikacije nekih velikih kompanija koje su smislile svoj dsl (u terraformu se koristi HCL).
Problem je u tome što lako ne sadrži tako poznate stvari kao što su:
- varijable;
- Uvjeti;
- negdje nema komentara, na primjer, u Jsonu, prema zadanim postavkama nisu navedeni;
- funkcije;
- a ja čak i ne govorim o tako visokim stvarima kao što su klase, nasljeđe i sve to.
2. Drugi problem s ovakvim kodom je taj što se najčešće radi o heterogenom okruženju. Obično sjedite i radite s C#, tj. s jednim jezikom, jednom hrpom, jednim ekosustavom. A ovdje imate veliki izbor tehnologija.
Vrlo je realna situacija kada bash s pythonom pokrene neki proces u koji se ubaci Json. Vi to analizirate, onda neki drugi generator proizvede još 30 datoteka. Za sve to, ulazne varijable primaju se iz Azure Key Vaulta, koje spaja dodatak za drone.io napisan u Go, a te varijable prolaze kroz yaml, koji je generiran kao rezultat generiranja iz mehanizma predložaka jsonnet. Prilično je teško imati striktno dobro opisan kod kada imate tako raznoliko okruženje.
Tradicionalni razvoj u okviru jedne zadaće dolazi s jednim jezikom. Ovdje radimo s velikim brojem jezika.
3. Treći problem je ugađanje. Navikli smo na cool editore (Ms Visual Studio, Jetbrains Rider) koji rade sve umjesto nas. Pa čak i da smo glupi, reći će da nismo u pravu. Čini se normalnim i prirodnim.
Ali negdje u blizini postoji VSCode, u kojem postoje neki dodaci koji su nekako instalirani, podržani ili nepodržani. Pojavile su se nove verzije koje nisu bile podržane. Banalan prijelaz na implementaciju funkcije (čak i ako postoji) postaje složen i netrivijalan problem. Jednostavno preimenovanje varijable je ponavljanje desetak datoteka u projektu. Bit ćeš sretan ako on postavi ono što ti treba. Naravno, tu i tamo ima pozadinskog osvjetljenja, postoji auto-dovršavanje, negdje postoji formatiranje (iako mi nije radilo u terraformu na Windowsima).
U vrijeme pisanja ovog teksta još nisu izdani za podršku verzije 0.12, iako je objavljena prije 3 mjeseca.
Vrijeme je da zaboravite na...
- Otklanjanje pogrešaka.
- Alat za refaktoriranje.
- Automatsko dovršavanje.
- Otkrivanje grešaka tijekom kompilacije.
Smiješno je, ali ovo također povećava vrijeme razvoja i povećava broj grešaka koje se neizbježno pojavljuju.
Najgora stvar je što smo prisiljeni razmišljati ne o tome kako dizajnirati, organizirati datoteke u mape, dekomponirati, učiniti kod održavanim, čitljivim i tako dalje, već o tome kako mogu ispravno napisati ovu naredbu, jer sam je nekako krivo napisao .
Kao početnik, pokušavate naučiti teraforme, a IDE vam uopće ne pomaže. Kad bude dokumentacija, uđite i pogledajte. Ali ako ste ulazili u novi programski jezik, IDE bi vam rekao da postoji takva vrsta, ali ne postoji takva stvar. Barem na int ili string razini. Ovo je često korisno.
Što je s testovima?
Pitate: "A što je s testovima, gospodo programeri?" Ozbiljni dečki testiraju sve na proizvodnji, a to je teško. Ovdje je primjer jediničnog testa za terraform modul s web stranice .
Imaju dobru dokumentaciju. Uvijek mi se sviđao Microsoft zbog njegovog pristupa dokumentaciji i obuci. Ali ne morate biti ujak Bob da shvatite da ovo nije savršen kod. Obratite pozornost na potvrdu s desne strane.
Problem s jediničnim testom je taj što vi i ja možemo provjeriti ispravnost Json izlaza. Ubacio sam 5 parametara i dobio Json krpu s 2000 redaka. Mogu analizirati što se ovdje događa, potvrditi rezultate testa...
Teško je raščlaniti Json u Gou. I trebate pisati na Go-u jer je terraform na Go-u dobra praksa za testiranje na jeziku na kojem pišete. Sama organizacija koda je vrlo slaba. Ujedno, ovo je najbolja biblioteka za testiranje.
Microsoft sam piše svoje module, testirajući ih na taj način. Naravno da je Open Source. Sve o čemu govorim možete doći i popraviti. Mogu sjesti i popraviti sve u tjedan dana, otvoriti dodatke za VS kod, terraforme, napraviti dodatak za vozača. Možda napisati nekoliko analizatora, dodati lintere, doprinijeti biblioteci za testiranje. Sve mogu. Ali to nije ono što bih trebao raditi.
Najbolje prakse Infrastruktura kao kod
Idemo dalje. Ako nema testova u IaC-u, IDE i podešavanje su loši, onda bi barem trebali postojati najbolji primjeri iz prakse. Upravo sam otišao na Google Analytics i usporedio dva upita za pretraživanje: najbolje prakse za Terraform i najbolje prakse za c#.
Što vidimo? Nemilosrdna statistika nam ne ide u prilog. Količina materijala je ista. U C# razvoju jednostavno smo preplavljeni materijalima, imamo super-najbolje prakse, postoje knjige koje su napisali stručnjaci, a također i knjige napisane na knjigama drugih stručnjaka koji kritiziraju te knjige. More službene dokumentacije, članaka, tečajeva, 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šća, iz službene dokumentacije i brojnih problema na Githubu. Kako uopće distribuirati te module, što s njima? Čini se da je to pravi problem... Postoji zajednica, gospodo, gdje ćete za svako pitanje dobiti 10 komentara na Githubu. Ali nije baš tako.
Nažalost, u ovom trenutku stručnjaci se tek počinju pojavljivati. Zasad ih je premalo. A sama zajednica se druži na rudimentarnoj razini.
Kamo sve ovo ide i što učiniti
Možete odbaciti sve i vratiti se na C#, u svijet vozača. Ali ne. Zašto biste se uopće trudili raditi ovo ako ne možete pronaći rješenje. U nastavku iznosim svoje subjektivne zaključke. Možete se raspravljati sa mnom u komentarima, bit će zanimljivo.
Osobno se kladim na nekoliko stvari:
- Razvoj na ovom području odvija se vrlo brzo. Ovdje je raspored zahtjeva za DevOps.
Tema je možda hype, ali sama činjenica da sfera raste daje neku nadu.Ako nešto tako brzo raste, onda će se sigurno pojaviti pametni ljudi koji će vam reći što da radite, a što ne. Povećanje popularnosti dovodi do činjenice da će možda netko imati vremena konačno dodati dodatak u jsonnet za vscode, što će vam omogućiti da prijeđete na implementaciju funkcije, umjesto da je tražite preko ctrl+shift+f. Kako se stvari razvijaju, pojavljuje se više materijala. Izdanje Googleove knjige o SRE izvrstan je primjer za to.
- 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 nakupljen je ogroman broj praksi koje mogu biti korisne i korisne.
Trivijalan primjer: suradnja kroz programiranje u paru. Puno pomaže da to shvatite. Kad u blizini imate susjeda koji također pokušava nešto razumjeti, zajedno ćete bolje razumjeti.
Razumijevanje načina na koji se vrši refaktoring pomaže u njegovom provođenju čak iu takvoj situaciji. Odnosno, ne možete promijeniti sve odjednom, ali promijenite naziv, pa promijenite lokaciju, pa možete istaknuti neki dio, oh, ali ovdje nema dovoljno komentara.
Zaključak
Unatoč tome što se moje razmišljanje može činiti pesimističnim, s nadom gledam u budućnost i iskreno se nadam da će nam (i vama) sve uspjeti.
Drugi dio članka je u pripremi. U njemu ću govoriti o tome kako smo pokušali upotrijebiti agilne razvojne prakse za poboljšanje procesa učenja i rada s infrastrukturom.
Izvor: www.habr.com