V našej spoločnosti prebieha proces onboardingu SRE tímu. Začal som sa tejto téme venovať z pohľadu vývoja. Počas toho som mal myšlienky a postrehy, o ktoré by som sa chcel podeliť s ostatnými vývojármi. V tomto článku sa zamýšľam nad tým, čo sa deje, ako sa to deje a ako s tým všetkým ďalej žiť.
Pokračovanie série článkov napísaných na základe prezentácií na našej vnútornej akcii :
2. Infrastructure as code. (Tu ste)
3. Generácia Typescript kontraktov podľa C# modelov. (V priebehu…)
4. Úvod do algoritmu konsenzu Raft. (V priebehu…)
…
Rozhodli sme sa vytvoriť SRE tím, realizujúc myšlienky . Nabrali sme programátorov z našich vlastných vývojárov a poslali ich na pár mesiacov na školenie.
Pred tímom stáli nasledujúce vzdelávacie úlohy:
- Opísať našu infraštruktúru, ktorá je väčšinou v Microsoft Azure, vo forme kódu (Terraform a všetko, čo s tým súvisí).
- Naučiť vývojárov pracovať s infraštruktúrou.
- Pripraviť vývojárov na pohotovosti.
Zavádzame pojem Infrastructure as code
V bežnom modely sveta (tradičné spravovanie) sa znalosti o infraštruktúre nachádzajú na dvoch miestach:
- Buď vo formě vedomostí v hlavách expertov.
- Alebo sú tieto informácie na nejakých strojov, z ktorých časť poznajú experti. No nie je isté, že osoba zvonka (ak by naša celá tím náhle zomrela) dokáže pochopiť, čo a ako funguje. Na stroji môže byť veľa informácií: prístupy, cron joby, podmačkaný (pozri ) disk a proste nekonečný zoznam toho, čo sa môže diať. Na základe toho je zložité pochopiť, čo sa v skutočnosti deje.
V oboch prípadoch sa ocitáme v pasci, stávajúc sa závislými:
- buď od človeka, ktorý je smrteľný, podliehajúci chorobám, zamilovanostiam, výkyvom nálady a jednoducho bežným výpovediam;
- alebo od fyzicky fungujúceho stroja, ktorý tiež padá, kradne sa, prináša prekvapenia a nepohodlia.
Sám sa prirodzene nabíja názor, že ideálne by všetko malo byť prevedené do ľahko čitateľného, udržiavaného a kvalitne napísaného kódu.
Takže infraštruktúra ako kód (Infrastructure as Code – IaC) je popis celej existujúcej infraštruktúry vo forme kódu, ako aj sprievodné prostriedky na prácu s ním a jeho pretransformovanie do reálnej infraštruktúry.
Prečo všetko previesť do kóduĽudia nie sú stroje. Nedokážu si všetko zapamätať. Reakcia človeka a stroja sa líši. Všetko automatizované potenciálne funguje rýchlejšie ako všetko, čo robí človek. Najdôležitejšie je mať jeden zdroj pravdy (single source of truth).
Odkiaľ sa berú noví SRE inžinieriTakže sme sa rozhodli zapojiť nových SRE inžinierov, ale odkiaľ ich získať? Kniha s správnymi odpoveďami () nám hovorí: od vývojárov. Predsa len pracujú s kódom a vy dosahujete ideálny stav.
Dlho a intenzívne sme ich hľadali na trhu práce mimo našu spoločnosť. Ale musíme priznať, že sme nenašli ani jedného spĺňajúceho naše požiadavky. Museli sme sa poobzerať medzi našimi.
Problémy infraštruktúry ako kódu
Poďme sa teraz pozrieť na príklady toho, ako môže byť infraštruktúra zakódovaná. Kód je dobre napísaný, kvalitný, s komentármi a odsadením.
Príklad kódu z Terraformu.
Príklad kódu z Ansible.
Páni, ale keby to bolo také jednoduché! Veď žijeme v reálnom svete, ktorý vás vždy dokáže prekvapiť, ponúknuť prekážky a problémy. Ani tu sa im nevyhneme.
1. Prvý problém spočíva v tom, že väčšinou je IaC akýmsi DSL.
A DSL je zase popis štruktúry. Presnejšie toho, čo by ste mali mať: Json, Yaml, modifikácie od nejakých veľkých spoločností, ktoré vymysleli svoj DSL (v Terraforme sa používa HCL).
Problém je, že v ňom môžu ľahko chýbať také nám známe veci ako:
- premenné;
- podmienky;
- niekde chýbajú komentáre, napríklad v Json, pre ne je predvolene nepripravený;
- funkcie;
- a to ešte nehovorím o takých vysokoúrovňových veciach, ako sú triedy, dedenie a podobne.
2. Druhý problém takéhoto kódu je, že väčšinou ide o heterogénne prostredie.Zvyčajne sedíte a pracujete s C#, teda s jedným jazykom, jedným stackom, jednou ekosystémou. A tu máte obrovské množstvo technológií.
Celkom reálna situácia, keď bash s Pythonom spúšťa nejaký proces, do ktorého sa podstrčí Json. Analyzujete ho, potom nejaký generátor vyprodukuje ďalších 30 súborov. Pre toto všetko prichádzajú vstupné premenné z Azure Key Vault, ktoré sú stiahnuté pluginom k drone.io napísaným v Go, a tieto premenné prechádzajú cez yaml, ktorý vznikol generovaním z šablónovača jsonnet. Pomerne zložité mať prísne dobre popísaný kód, keď máte tak pestré prostredie.
Tradičný vývoj v rámci jednej úlohy prebieha s jedným jazykom. Tu však pracujeme s veľkým množstvom jazykov.
3. Tretí problém – to je tooling. Sme zvyknutí na skvelé editory (Ms Visual Studio, Jetbrains Rider), ktoré všetko robia za nás. A aj keď zlyháme, povedia nám, že nie sme pravdu. Zdá sa, že je to normálne a prirodzené.
Ale niekde je VSCode, v ktorom sú nejaké pluginy, ktoré sa nejako inštalujú, podporujú alebo nepodporujú. Vyšli nové verzie, a tie neboli podporované. Banálny prechod k implementácii funkcie (aj keď je) sa stáva zložitým a netriviálnym problémom. Jednoduché premenovanie premennej je nahradenie v projekte z desiatich súborov. Bude šťastím, ak to bude to, čo je potrebné nahradiť. Samozrejme, niekde je zvýraznenie, je auto-doplnenie, niekde je formátovanie (pravda, u mňa v terraform na Windows sa to nespustilo).
V čase písania článku ešte nevydali na podporu verzie 0.12, hoci je už vydaná 3 mesiace.
Prišiel čas zabudnúť na...
- Ladenie.
- Nástroj na refaktoring.
- Automatické doplnenie.
- Odhaľovanie chýb pri kompilácii.
Je to smiešne, ale to predlžuje čas na vývoj a zvyšuje počet chýb, ktoré nevyhnutne vznikajú.
Najstrašnejšie je, že sme nútení myslieť nie na to, ako navrhnúť, rozdeliť súbory do priečinkov, dekomponovať, urobiť kód udržiavateľným, čitateľným a tak ďalej, ale na to, ako správne napísať tento príkaz, pretože som ho napísal nesprávne.
Ako nováčik sa pokúšate pochopiť terraform, a IDE vám v tom vôbec nepomáha. Keď je dokumentácia – vojdem, pozriem. Ale keby ste sa dostávali do nového programovacieho jazyka, IDE by naznačila, že takýto typ existuje, a taký nie. Aspoň na úrovni int alebo string. To je často užitočné.
A čo testy?
Pýtate sa: „Ako to je s testami, páni programátori?“ Seriózni chlapci testujú všetko na produkcii, a to je tvrdé. Tu je príklad jednotkového testu pre terraform modul z webovej stránky. .
Majú dobrú dokumentáciu. Microsoft sa mi vždy páčil svojím prístupom k dokumentácii a vzdelávaniu. Ale netreba byť strýkom Bobom, aby ste pochopili, že tu nie je ideálny kód. Všimnite si validáciu presunutú doprava.
Problém jednotkového testu je ten, že môžeme overiť správnosť JSONu na výstupe. Dal som 5 parametrov a dostal som výstup JSON s 2000 riadkami. Môžem analyzovať, čo sa tu deje, overiť výsledok testu...
Je ťažké analyzovať JSON v Go. Ale treba písať v Go, pretože terraform v Go – to je dobrá prax, pri ktorej testujete v tom jazyku, v ktorom píšete. Samo o sebe je organizácia kódu veľmi slabá. A pritom – to je najlepšia knižnica na testovanie.
Sám Microsoft píše svoje moduly a testuje ich týmto spôsobom. Samozrejme, je to Open Source. Všetko, o čom hovorím, môžete prísť a opraviť. Môžem si sadnúť a za týždeň všetko opraviť, open-source pluginy VS-kódu, terraform, vytvoriť plugin pre Rider. Možno napísať pár analyzátorov, pripojiť linters, prispieť do knižnice na testovanie. Všetko môžem urobiť. Ale tým sa nemám zaoberať.
Najlepšie praktiky Infrastructure as code.
Ideme ďalej. Ak v IaC nie sú testy, zle s IDE a toolingom, aspoň by mali byť najlepšie praktiky. Jednoducho som šiel do Google Analytics a porovnal dve vyhľadávacie dotazy: Terraform best practices a C# best practices.
Čo vidíme? Bezohľadná štatistika nie v náš prospech. Čo sa týka množstva materiálu – rovnaké. V C# vývoji sa jednoducho kúpeme v materiáloch, máme nadpriemerné praktiky, sú knihy napísané expertmi, a tiež knihy, ktoré napísali iní experti, ktorí kritizujú tie knihy. Množstvo oficiálnej dokumentácie, článkov, vzdelávacích kurzov, teraz ešte aj open source vývoj.
Čo sa týka dotazu na IaC: tu sa snažíte zozbierať informácie z prezentácií vysokého zaťaženia alebo HashiConf, z oficiálnej dokumentácie a početných issue na GitHub. Ako vlastne rozmiestniť tieto moduly, čo s nimi robiť? Zdá sa, že je to skutočný problém... Existuje predsa komunita, páni, kde na akúkoľvek otázku vám dajú 10 komentárov na GitHub. Ale to nie je isté.
Bohužiaľ, v súčasnosti sa experti iba začínajú objavovať. Doteraz ich je príliš málo. A samotné komunity sú ešte vo fáze začiatku.
Kam to všetko smeruje a čo robiť
Môžete všetko nechať a vrátiť sa späť k C#, do sveta jazdca. Ale nie. Prečo by ste sa vôbec mali zapodievať týmto, ak nie aby ste našli riešenie. Nižšie uvádzam svoje subjektívne závery. Môžete so mnou polemizovať v komentároch, bude to zaujímavé.
Osobne sa prikláňam k niekoľkým otázkam:
- Rozvoj v tejto oblasti sa deje veľmi rýchlo. Uvádzam graf dopytu po DevOps.
Možno je to hype téma, ale samotný fakt, že oblast rastie, vnáša určitú nádej.Ak niečo rastie tak rýchlo, určite sa objavia inteligentní ľudia, ktorí povedia, ako to robiť a ako nie. Nárast popularity vedie k tomu, že možno niekto konečne nájde čas doplniť plugin k jsonnet pre vscode, ktorý umožní prechádzať k implementácii funkcie, namiesto aby ju hľadali cez ctrl+shift+f. Keď sa všetko vyvíja, objavuje sa viac materiálov. Rovnaký príklad je vydanie knihy od Google o SRE.
- Existujú vyvinuté metódy a praktiky v bežnom vývoji, ktoré môžeme úspešne aplikovať aj tu. Áno, sú tu nuansy s testovaním a heterogénnym prostredím, nedostatočné nástroje, ale nahromadilo sa obrovské množstvo praktík, ktoré môžu byť užitočné a pomôcť.
Banálny príklad: spolupráca cez pair programming. Veľmi pomáha porozumieť. Keď máte vedľa seba kolegu, ktorý tiež niečo sa snaží pochopiť, spolu porozumiete lepšie.
Porozumenie tomu, ako sa robí refaktoring, pomáha aj v takejto situácii ho vykonávať. Teda môžete zmeniť nie všetko naraz, ale zmeniť pomenovanie, potom zmeniť umiestnenie, potom môže vyčleniť nejakú časť, och, a tu chýbajú komentáre.
Záver
Napriek tomu, že moje úvahy sa môžu zdať pesimistické, s nádejou pozerám do budúcnosti a úprimne dúfam, že sa nám (a vám) všetkým podarí.
Nasleduje druhá časť článku. V nej poviem, ako sme sa pokúsili aplikovať praktiky agilného vývoja, aby sme zlepšili náš proces učenia a prácu s infraštruktúrou.
Zdroj: habr.com
