Naša spoločnosť je v procese začleňovania tímu SRE. Do celého tohto príbehu som vstúpil z vývojovej stránky. V tomto procese som prišiel s myšlienkami a postrehmi, o ktoré sa chcem podeliť s ostatnými vývojármi. V tomto reflexnom článku hovorím o tom, čo sa deje, ako sa to deje a ako s tým môže každý ďalej žiť.
Pokračovanie série článkov napísaných na základe prejavov na našom internom podujatí :
2. Infraštruktúra ako kód. (ste tu)
3. Generovanie zmlúv Typescript pomocou modelov C#. (Prebieha...)
4. Úvod do konsenzuálneho algoritmu Raft. (Prebieha...)
...
Rozhodli sme sa vytvoriť tím SRE, ktorý implementuje nápady . Naverbovali programátorov spomedzi vlastných vývojárov a poslali ich trénovať na niekoľko mesiacov.
Tím mal tieto tréningové úlohy:
- Popíšte našu infraštruktúru, ktorá je väčšinou v Microsoft Azure vo forme kódu (Terraform a všetko okolo).
- Naučte vývojárov, ako pracovať s infraštruktúrou.
- Pripravte vývojárov na povinnosť.
Predstavujeme pojem Infraštruktúra ako kód
V bežnom modeli sveta (klasická administratíva) sa poznatky o infraštruktúre nachádzajú na dvoch miestach:
- Alebo v podobe vedomostí v hlavách odborníkov.
- Alebo sú tieto informácie na niektorých písacích strojoch, z ktorých niektoré sú odborníkom známe. Ale nie je pravda, že cudzinec (v prípade, že celý náš tím náhle zomrie) bude schopný zistiť, čo funguje a ako to funguje. Na stroji môže byť veľa informácií: príslušenstvo, cronjobs, zastrašovanie (pozri. ) disk a len nekonečný zoznam toho, čo sa môže stať. Je ťažké pochopiť, čo sa skutočne deje.
V oboch prípadoch sa ocitneme v pasci stať sa závislými:
- alebo od osoby, ktorá je smrteľná, podlieha chorobe, zamilovaniu, zmenám nálady a jednoducho banálnemu prepúšťaniu;
- alebo z fyzicky pracujúceho stroja, ktorý tiež spadne, ukradne sa a prinesie prekvapenia a nepríjemnosti.
Je samozrejmé, že ideálne by malo byť všetko preložené do ľudsky čitateľného, udržiavateľného a dobre napísaného kódu.
Infraštruktúra ako kód (Incfastructure as Code - IaC) je teda popisom celej existujúcej infraštruktúry vo forme kódu, ako aj súvisiacich nástrojov na prácu s ňou a implementáciu reálnej infraštruktúry z nej.
Prečo všetko prekladať do kódu?Ľudia nie sú stroje. Nemôžu si pamätať všetko. Reakcia človeka a stroja je iná. Čokoľvek automatizované je potenciálne rýchlejšie ako čokoľvek, čo urobí človek. Najdôležitejšia vec je jediný zdroj pravdy.
Odkiaľ pochádzajú noví inžinieri SRE?Takže sme sa rozhodli najať nových SRE inžinierov, ale odkiaľ ich získať? Kniha so správnymi odpoveďami () nám hovorí: od vývojárov. Koniec koncov, pracujú s kódom a dosiahnete ideálny stav.
Dlho sme ich veľa hľadali na personálnom trhu mimo našej spoločnosti. Ale musíme priznať, že sme nenašli nikoho, kto by vyhovoval našim požiadavkám. Musel som hľadať medzi svojimi.
Problémy Infraštruktúra ako kód
Teraz sa pozrime na príklady toho, ako môže byť infraštruktúra pevne zakódovaná do kódu. Kód je dobre napísaný, kvalitný, s komentármi a odrážkami.
Príklad kódu z Terraforma.
Príklad kódu od Ansible.
Páni, keby to bolo také jednoduché! Sme v skutočnom svete a ten je vždy pripravený vás prekvapiť, predstaviť vám prekvapenia a problémy. Nezaobíde sa to bez nich ani tu.
1. Prvý problém je, že vo väčšine prípadov je IaC nejaký druh dsl.
A DSL je zasa popisom štruktúry. Presnejšie, čo by ste mali mať: Json, Yaml, úpravy od niektorých veľkých spoločností, ktoré prišli s vlastným dsl (HCL sa používa v terraforme).
Problém je v tom, že ľahko nemusí obsahovať také známe veci ako:
- premenné;
- podmienky;
- niekde nie sú žiadne komentáre, napríklad v Json, v predvolenom nastavení sa neposkytujú;
- funkcie;
- a to ani nehovorím o takých vysokých veciach, ako sú triedy, dedičstvo a tak ďalej.
2. Druhým problémom takéhoto kódu je, že najčastejšie ide o heterogénne prostredie. Väčšinou sedíte a pracujete s C#, t.j. s jedným jazykom, jedným zásobníkom, jedným ekosystémom. A tu máte obrovské množstvo technológií.
Je to veľmi reálna situácia, keď bash s pythonom spustí nejaký proces, do ktorého je vložený Json. Vy to analyzujete, potom nejaký iný generátor vytvorí ďalších 30 súborov. Na to všetko sa prijímajú vstupné premenné z Azure Key Vault, ktoré sú stiahnuté pomocou pluginu pre drone.io napísaného v Go a tieto premenné prechádzajú cez yaml, ktorý bol vygenerovaný ako výsledok generovania z jsonnet template engine. Je dosť ťažké mať striktne dobre popísaný kód, keď máte také rozmanité prostredie.
Tradičný vývoj v rámci jednej úlohy prichádza s jedným jazykom. Tu pracujeme s veľkým množstvom jazykov.
3. Tretím problémom je ladenie. Sme zvyknutí na cool editory (Ms Visual Studio, Jetbrains Rider), ktoré robia všetko za nás. A aj keď sme hlúpi, povedia, že sa mýlime. Zdá sa to normálne a prirodzené.
Ale niekde nablízku je VSCode, v ktorom sú nejaké pluginy, ktoré sú nejakým spôsobom nainštalované, podporované alebo nepodporované. Vyšli nové verzie a neboli podporované. Banálny prechod k implementácii funkcie (aj keď existuje) sa stáva zložitým a netriviálnym problémom. Jednoduché premenovanie premennej je prehratím v projekte tuctu súborov. Budete mať šťastie, ak umiestni to, čo potrebujete. Samozrejmosťou je sem tam podsvietenie, automatické dokončovanie, niekde formátovanie (aj keď mi to v terraforme na Windowse nefungovalo).
V čase tohto písania ešte neboli vydané na podporu verzie 0.12, hoci je vydaná už 3 mesiace.
Je čas zabudnúť na...
- Ladenie.
- Nástroj na refaktorovanie.
- Automatické dokončovanie.
- Detekcia chýb počas kompilácie.
Je to smiešne, ale tiež to zvyšuje čas vývoja a zvyšuje počet chýb, ktoré sa nevyhnutne vyskytujú.
Najhoršie je, že sme nútení premýšľať nie o tom, ako navrhnúť, usporiadať súbory do priečinkov, rozložiť, urobiť kód udržiavateľným, čitateľným atď. .
Ako začiatočník sa snažíte naučiť terraformy a IDE vám vôbec nepomáha. Keď je dokumentácia, choďte a pozrite sa. Ale ak by ste zadávali nový programovací jazyk, IDE by vám povedalo, že taký typ existuje, ale nič také neexistuje. Aspoň na úrovni int alebo string. Toto je často užitočné.
A čo testy?
Pýtate sa: "A čo testy, páni programátori?" Seriózni chlapi testujú všetko na produkcii a je to ťažké. Tu je príklad testu jednotky pre modul terraform z webovej stránky .
Majú dobrú dokumentáciu. Microsoft sa mi vždy páčil pre jeho prístup k dokumentácii a školeniam. Ale nemusíte byť strýko Bob, aby ste pochopili, že toto nie je dokonalý kód. Všimnite si overenie vpravo.
Problém s testom jednotiek je v tom, že vy a ja môžeme skontrolovať správnosť výstupu Json. Hodil som 5 parametrov a dostal som handričku Json s 2000 riadkami. Môžem analyzovať, čo sa tu deje, potvrdiť výsledok testu...
Je ťažké analyzovať Json v Go. A musíte písať v Go, pretože terraform v Go je dobrá prax na testovanie v jazyku, v ktorom píšete. Organizácia samotného kódu je veľmi slabá. Zároveň je to najlepšia knižnica na testovanie.
Samotný Microsoft píše svoje moduly a testuje ich týmto spôsobom. Samozrejme je to Open Source. Všetko, o čom hovorím, môže prísť a opraviť. Môžem si sadnúť a opraviť všetko za týždeň, open source pluginy VS kódu, terraformy, urobiť plugin pre jazdca. Možno napísať pár analyzátorov, pridať linters, prispieť knižnicou na testovanie. Ja môžem všetko. Ale to nie je to, čo by som mal robiť.
Osvedčené postupy Infraštruktúra ako kód
Poďme ďalej. Ak v IaC nie sú žiadne testy, IDE a ladenie sú zlé, potom by mali existovať aspoň osvedčené postupy. Práve som prešiel do služby Google Analytics a porovnal som dva vyhľadávacie dopyty: osvedčené postupy Terraform a osvedčené postupy c#.
čo vidíme? Neľútostné štatistiky nie sú v náš prospech. Množstvo materiálu je rovnaké. Vo vývoji C# sme jednoducho zaplavení materiálmi, máme super-osvedčené postupy, existujú knihy napísané odborníkmi a tiež knihy napísané na knihách od iných odborníkov, ktorí tieto knihy kritizujú. More oficiálnej dokumentácie, článkov, školení a teraz aj open source vývoja.
Pokiaľ ide o požiadavku IaC: tu sa pokúšate zbierať informácie kúsok po kúsku zo správ o vysokej záťaži alebo HashiConf, z oficiálnej dokumentácie a mnohých problémov na Github. Ako tieto moduly vo všeobecnosti distribuovať, čo s nimi robiť? Zdá sa, že toto je skutočný problém... Existuje komunita, páni, kde za akúkoľvek otázku dostanete 10 komentárov na Github. Ale nie je to presne tak.
Žiaľ, v tomto momente sa odborníci len začínajú objavovať. Zatiaľ je ich príliš málo. A samotná komunita visí na základnej úrovni.
Kam to všetko smeruje a čo robiť
Môžete všetko zahodiť a vrátiť sa späť do C#, do sveta jazdca. Ale nie. Prečo by ste sa s tým vôbec obťažovali, ak nemôžete nájsť riešenie. Nižšie uvádzam svoje subjektívne závery. Môžete so mnou polemizovať v komentároch, bude to zaujímavé.
Osobne vsádzam na niekoľko vecí:
- Vývoj v tejto oblasti prebieha veľmi rýchlo. Tu je plán požiadaviek na DevOps.
Témou je možno hype, ale už samotný fakt, že sféra rastie, dáva určitú nádej.Ak niečo tak rýchlo rastie, určite sa objavia šikovní ľudia, ktorí vám povedia, čo máte robiť a čo nie. Nárast popularity vedie k tomu, že možno bude mať niekto čas konečne pridať doplnok do jsonnet pre vscode, ktorý vám umožní prejsť k implementácii funkcie namiesto hľadania pomocou ctrl+shift+f. Ako sa veci vyvíjajú, objavuje sa viac materiálov. Vydanie knihy od spoločnosti Google o SRE je toho vynikajúcim príkladom.
- V konvenčnom vývoji sú vyvinuté techniky a postupy, ktoré tu môžeme úspešne aplikovať. Áno, existujú nuansy s testovaním a heterogénnym prostredím, nedostatočné nástroje, ale nahromadilo sa obrovské množstvo postupov, ktoré môžu byť užitočné a užitočné.
Triviálny príklad: spolupráca prostredníctvom párového programovania. Veľmi pomáha prísť na to. Keď máte nablízku suseda, ktorý sa tiež snaží niečo pochopiť, spoločne si budete rozumieť lepšie.
Pochopenie toho, ako sa refaktoring robí, pomáha pri jeho realizácii aj v takejto situácii. To znamená, že nemôžete zmeniť všetko naraz, ale zmeniť názov, potom zmeniť umiestnenie, potom môžete zvýrazniť niektorú časť, ale nie je tu dostatok komentárov.
Záver
Napriek tomu, že moje úvahy môžu pôsobiť pesimisticky, do budúcnosti hľadím s nádejou a úprimne dúfam, že nám (aj vám) všetko vyjde.
Ďalej sa pripravuje druhá časť článku. V ňom porozprávam o tom, ako sme sa snažili využiť agilné vývojové postupy na zlepšenie nášho vzdelávacieho procesu a práce s infraštruktúrou.
Zdroj: hab.com