Naše podjetje je v procesu vključevanja ekipe SRE. V celotno to zgodbo sem prišel z razvojne strani. V procesu sem prišel do misli in spoznanj, ki jih želim deliti z drugimi razvijalci. V tem članku o razmišljanju govorim o tem, kaj se dogaja, kako se dogaja in kako lahko vsi še naprej živijo s tem.
Nadaljevanje serije člankov, nastalih na podlagi govorov na našem internem dogodku :
2. Infrastruktura kot koda. (Tukaj ste)
3. Generiranje pogodb Typescript z uporabo modelov C#. (V delu...)
4. Uvod v algoritem soglasja Raft. (V delu...)
...
Odločili smo se, da ustvarimo ekipo SRE, ki bo implementirala ideje . Programerje so zaposlili med lastnimi razvijalci in jih poslali na večmesečno usposabljanje.
Ekipa je imela naslednje vadbene naloge:
- Opišite našo infrastrukturo, ki je večinoma v Microsoft Azure v obliki kode (Terraform in vse okoli).
- Naučite razvijalce, kako delati z infrastrukturo.
- Pripravite razvijalce na dolžnost.
Predstavljamo koncept infrastrukture kot kode
V običajnem modelu sveta (klasični administraciji) se znanje o infrastrukturi nahaja na dveh mestih:
- Ali pa v obliki znanja v glavah strokovnjakov.
- Ali pa so te informacije na nekaterih pisalnih strojih, od katerih so nekateri poznani strokovnjakom. Vendar ni dejstvo, da bo zunanji sodelavec (v primeru, da naša celotna ekipa nenadoma umre) lahko ugotovil, kaj deluje in kako deluje. Na stroju je lahko veliko informacij: dodatki, cronjobs, prestrašeni (glejte. ) disk in samo neskončen seznam tega, kar se lahko zgodi. Težko je razumeti, kaj se v resnici dogaja.
V obeh primerih se znajdemo ujeti v odvisnost:
- ali od osebe, ki je smrtna, podvržena bolezni, zaljubljenosti, nihanju razpoloženja in preprosto banalnim odpuščanjem;
- ali iz fizično delujočega stroja, ki tudi pade, ga ukradejo in predstavlja presenečenja in neprijetnosti.
Samoumevno je, da bi bilo idealno vse prevedeno v človeku berljivo, vzdržljivo in dobro napisano kodo.
Tako je infrastruktura kot koda (Incfastructure as Code - IaC) opis celotne obstoječe infrastrukture v obliki kode ter pripadajočih orodij za delo z njo in iz nje implementacijo prave infrastrukture.
Zakaj vse prevesti v kodo?Ljudje nismo stroji. Ne morejo si zapomniti vsega. Reakcija človeka in stroja je različna. Vse, kar je avtomatizirano, je potencialno hitrejše od česar koli, kar naredi človek. Najpomembnejši je en sam vir resnice.
Od kod prihajajo novi SRE inženirji?Zato smo se odločili zaposliti nove SRE inženirje, a kje jih dobiti? Knjiga s pravilnimi odgovori () nam pove: od razvijalcev. Navsezadnje delajo s kodo in dosežete idealno stanje.
Dolgo smo jih veliko iskali na kadrovskem trgu izven našega podjetja. Vendar moramo priznati, da nismo našli nikogar, ki bi ustrezal našim zahtevam. Moral sem iskati med svojimi.
Problemi Infrastruktura kot koda
Zdaj pa si poglejmo primere, kako je mogoče infrastrukturo trdo kodirati v kodo. Koda je dobro napisana, kvalitetna, s komentarji in vdolbinami.
Primer kode iz Terraforme.
Primer kode iz Ansible.
Gospodje, ko bi le bilo tako preprosto! Smo v resničnem svetu, ki vas je vedno pripravljen presenetiti, vam postaviti presenečenja in težave. Tudi tukaj ne gre brez njih.
1. Prvi problem je, da je IaC v večini primerov neke vrste dsl.
DSL pa je opis strukture. Natančneje, kaj bi morali imeti: Json, Yaml, modifikacije nekaterih velikih podjetij, ki so si omislila svoj dsl (HCL se uporablja v terraformu).
Težava je v tem, da zlahka ne vsebuje znanih stvari, kot so:
- spremenljivke;
- pogoji;
- nekje ni komentarjev, na primer v Jsonu, privzeto niso na voljo;
- funkcije;
- in sploh ne govorim o stvareh na tako visoki ravni, kot so razredi, dedovanje in vse to.
2. Druga težava takšne kode je, da gre največkrat za heterogeno okolje. Običajno sedite in delate s C#, tj. z enim jezikom, enim skladom, enim ekosistemom. In tukaj imate ogromno različnih tehnologij.
Zelo realna situacija je, ko bash s pythonom zažene nek proces, v katerega je vstavljen Json. Vi ga analizirate, nato pa nek drug generator proizvede dodatnih 30 datotek. Za vse to so vhodne spremenljivke prejete iz Azure Key Vault, ki jih združi vtičnik za drone.io, napisan v Go, te spremenljivke pa gredo skozi yaml, ki je bil ustvarjen kot rezultat generiranja iz mehanizma predlog jsonnet. Precej težko je imeti strogo dobro opisano kodo, če imate tako raznoliko okolje.
Tradicionalni razvoj v okviru ene naloge prinaša en jezik. Tukaj delamo z velikim številom jezikov.
3. Tretji problem je uglaševanje. Navajeni smo kul urednikov (Ms Visual Studio, Jetbrains Rider), ki naredijo vse namesto nas. In tudi če smo neumni, bodo rekli, da se motimo. Zdi se normalno in naravno.
Ampak nekje v bližini je VSCode, v katerem so nekateri vtičniki, ki so nekako nameščeni, podprti ali ne. Izšle so nove različice, ki niso bile podprte. Banalen prehod na izvajanje funkcije (tudi če obstaja) postane zapleten in netrivialen problem. Preprosto preimenovanje spremenljivke je ponovno predvajanje ducata datotek v projektu. Imeli boste srečo, če vam bo postavil tisto, kar potrebujete. Seveda je tu in tam osvetlitev ozadja, samodokončanje, nekje oblikovanje (čeprav mi v terraformu v Windowsih ni delovalo).
V času tega pisanja še niso bili izdani za podporo različice 0.12, čeprav je bila izdana že 3 mesece.
Čas je, da pozabimo na...
- Odpravljanje napak.
- Orodje za preoblikovanje.
- Samodejno dokončanje.
- Odkrivanje napak med prevajanjem.
Smešno je, toda to tudi poveča čas razvoja in poveča število napak, ki se neizogibno pojavijo.
Najslabše je, da nismo prisiljeni razmišljati o tem, kako oblikovati, organizirati datoteke v mape, razstaviti, narediti kodo vzdržljivo, berljivo in tako naprej, ampak o tem, kako lahko pravilno napišem ta ukaz, ker sem ga nekako napačno napisal .
Kot začetnik se poskušate naučiti teraform, IDE pa vam nič ne pomaga. Ko bo dokumentacija, pojdite noter in poglejte. Toda če bi vnašali nov programski jezik, bi vam IDE povedal, da obstaja tak tip, vendar tega ni. Vsaj na ravni int ali nizov. To je pogosto koristno.
Kaj pa testi?
Sprašujete: "Kaj pa testi, gospodje programerji?" Resni fantje testirajo vse v proizvodnji in to je težko. Tukaj je primer testa enote za modul terraform s spletnega mesta .
Imajo dobro dokumentacijo. Microsoft mi je bil vedno všeč zaradi njegovega pristopa k dokumentaciji in usposabljanju. Vendar vam ni treba biti stric Bob, da razumete, da to ni popolna koda. Upoštevajte potrditev na desni.
Težava pri testu enote je, da lahko vi in jaz preverimo pravilnost izhoda Json. Dodal sem 5 parametrov in dobil krpico Json z 2000 vrsticami. Lahko analiziram, kaj se tukaj dogaja, potrdim rezultate testa ...
Težko je razčleniti Json v Go. In morate pisati v Go, ker je terraform v Go dobra praksa za testiranje v jeziku, v katerem pišete. Sama organizacija kode je zelo šibka. Hkrati je to najboljša knjižnica za testiranje.
Microsoft sam piše svoje module in jih na ta način preizkuša. Seveda je odprtokoden. Vse, o čemer govorim, lahko prideš in urediš. Lahko se usedem in vse popravim v enem tednu, odprtokodne vtičnike VS kode, terraforme, naredim vtičnik za voznika. Morda napišete nekaj analizatorjev, dodate linterje, prispevate knjižnico za testiranje. Vse zmorem. Ampak to ni tisto, kar bi moral početi.
Najboljše prakse Infrastruktura kot koda
Gremo naprej. Če v IaC ni testov, sta IDE in nastavitev slaba, potem bi morale obstajati vsaj najboljše prakse. Pravkar sem šel v Google Analytics in primerjal dve iskalni poizvedbi: najboljše prakse Terraform in najboljše prakse c#.
Kaj vidimo? Neusmiljena statistika nam ni v prid. Količina materiala je enaka. Pri razvoju C# smo preprosto preplavljeni z materiali, imamo super najboljše prakse, obstajajo knjige, ki so jih napisali strokovnjaki, in tudi knjige, ki so jih napisali na knjige drugih strokovnjakov, ki te knjige kritizirajo. Morje uradne dokumentacije, člankov, izobraževanj in zdaj tudi odprtokodnega razvoja.
Kar zadeva zahtevo IaC: tukaj poskušate zbrati informacije po delih iz poročil highload ali HashiConf, iz uradne dokumentacije in številnih vprašanj na Githubu. Kako na splošno razdeliti te module, kaj narediti z njimi? Zdi se, da je to resen problem ... Obstaja skupnost, gospodje, kjer boste za vsako vprašanje dobili 10 komentarjev na Githubu. Ampak ni ravno.
Na žalost se v tem trenutku strokovnjaki šele pojavljajo. Zaenkrat jih je premalo. In sama skupnost se druži na osnovni ravni.
Kam vse to pelje in kaj storiti
Lahko opustite vse in se vrnete v C#, v svet kolesarjev. Vendar ne. Zakaj bi se sploh trudil s tem, če ne najdeš rešitve. V nadaljevanju predstavljam svoje subjektivne ugotovitve. Lahko se prepirate z mano v komentarjih, zanimivo bo.
Osebno stavim na nekaj stvari:
- Razvoj na tem področju poteka zelo hitro. Tukaj je razpored zahtev za DevOps.
Tema je morda hype, vendar dejstvo, da sfera raste, daje nekaj upanja.Če nekaj tako hitro raste, potem se bodo zagotovo pojavili pametni ljudje, ki vam bodo povedali, kaj morate in česa ne. Povečanje priljubljenosti vodi do dejstva, da bo morda kdo imel čas, da končno doda vtičnik v jsonnet za vscode, ki vam bo omogočil, da nadaljujete z implementacijo funkcije, namesto da jo iščete prek ctrl+shift+f. Ko se stvari razvijajo, se pojavlja več materialov. Izid Googlove knjige o SRE je odličen primer tega.
- Obstajajo razvite tehnike in prakse v konvencionalnem razvoju, ki jih lahko uspešno uporabljamo pri nas. Da, obstajajo nianse s testiranjem in heterogenim okoljem, nezadostnim orodjem, vendar se je nabralo ogromno praks, ki so lahko koristne in koristne.
Trivialen primer: sodelovanje prek programiranja v paru. Zelo pomaga ugotoviti. Ko imaš v bližini soseda, ki prav tako poskuša nekaj razumeti, bosta skupaj bolje razumela.
Razumevanje, kako poteka preoblikovanje, ga pomaga izvesti tudi v takšni situaciji. To pomeni, da ne morete spremeniti vsega naenkrat, ampak spremenite poimenovanje, nato spremenite lokacijo, potem lahko označite kakšen del, oh, vendar tukaj ni dovolj komentarjev.
Zaključek
Kljub temu, da se zdi moje razmišljanje pesimistično, zrem v prihodnost z upanjem in iskreno upam, da se nam (in vam) vse izide.
Drugi del članka je v pripravi. V njem bom govoril o tem, kako smo poskušali uporabiti agilne razvojne prakse za izboljšanje našega učnega procesa in dela z infrastrukturo.
Vir: www.habr.com