V naší společnosti probíhá onboarding týmu SRE. Do celé této historie jsem vstoupil z pohledu vývoje. V průběhu jsem měl myšlenky a postřehy, o které se chci podělit s dalšími vývojáři. V tomto článku-zamýšlení hovořím o tom, co se děje, jak se to děje, a jak s tím všichni dál žít.
Pokračování série článků napsaných na základě vystoupení na naší interní akci. :
2. Infrastruktura jako kód. (Jste zde)
3. Generování Typescript kontraktů na základě c# modelů. (Probíhá…)
4. Úvod do algoritmu konsensu Raft. (Probíhá…)
…
Rozhodli jsme se vytvořit tým SRE, který realizuje myšlenky . Nabrali jsme programátory z našich vlastních vývojářů a poslali je školit na několik měsíců.
Před týmem stály následující vzdělávací úkoly:
- Popsat naši infrastrukturu, která je převážně v Microsoft Azure, pomocí kódu (Terraform a vše kolem).
- Naučit vývojáře pracovat s infrastrukturou.
- Připravit vývojáře na pohotovosti.
Zavádíme pojem Infrastruktura jako kód.
V běžném modelu světa (klasickém administraci) se znalosti o infrastruktuře nacházejí na dvou místech:
- Buď ve formě znalostí v hlavách expertů.
- Nebo tyto informace nacházejí na nějakých strojích, z nichž část znají experti. Ale není jisté, že osoba zvenčí (v případě, že naše celá tým náhle zemře) dokáže pochopit, co a jak funguje. Na stroji může být mnoho informací: přístupy, crontaby, podučovaný (viz ) disk a prostě nekonečný seznam toho, co se může dít. Podle něj je těžké pochopit, co se ve skutečnosti děje.
V obou případech se ocitáme v pasti, stáváme se závislými:
- buď na člověku, který je smrtelný, náchylný k nemocem, zamilovanostem, změnám nálady a prostým banálním odchodům;
- nebo na fyzicky fungující mašině, která také selhává, krade se, přináší překvapení a nepříjemnosti.
Samozřejmě se nabízí řešení, že ideálně vše je třeba převést do čitelného, udržovatelného, kvalitně napsaného kódu.
Infrastruktura jako kód (Infrastructure as Code – IaC) je popis veškeré existující infrastruktury ve formě kódu, jakož i související nástroje pro práci s ním a jejím přetvářením na skutečnou infrastrukturu.
Proč převádět všechno do kóduLidé nejsou stroje. Nemohou si všechno zapamatovat. Reakce člověka a stroje je odlišná. Vše, co je automatizováno, potenciálně funguje rychleji než cokoliv, co dělá člověk. Nejdůležitější je mít jeden zdroj pravdy (single source of truth).
Odkud přicházejí noví SRE inženýřiRozhodli jsme se tedy zapojit nové SRE inženýry, ale kde je vzít? Kniha s odpověďmi () nám říká: ze zdrojového kódu. Pracují s kódem a vy dosahujete ideálního stavu.
Dlouho jsme je hledali na pracovním trhu mimo naši společnost. Ale musíme přiznat, že jsme nenašli ani jednoho, kdo by vyhovoval našim požadavkům. Museli jsme se podívat mezi vlastními lidmi.
Problémy infrastruktury jako kódu
Podívejme se nyní na příklady toho, jak může být infrastruktura zakódována. Kód je dobře napsán, kvalitně, s komentáři a odsazením.
Příklad kódu z Terraformu.
Příklad kódu z Ansible.
Pánové, ale co kdyby to bylo tak jednoduché! Jsme přece v reálném světě, a ten vždycky překvapí, přinese překvapení a problémy. A tady to není jinak.
1. První problém spočívá v tom, že v mnoha případech je IaC nějakým DSL.
A DSL je popis struktury. Přesněji řečeno toho, co byste měli mít: Json, Yaml, modifikace od několika velkých společností, které vymyslely svůj DSL (v Terraformu se používá HCL).
Problém je v tom, že v něm mohou snadno chybět tolik známé prvky jako:
- proměnné;
- podmínky;
- někde chybí komentáře, například v Jsonu, ty nejsou ve výchozím nastavení zahrnuty;
- funkce;
- a to ještě nemluvím o takových vysoce úrovňových prvcích, jako jsou třídy, dědičnost a podobně.
2. Druhým problémem takového kódu je, že většinou se jedná o heterogenní prostředí. Obvykle sedíte a pracujete s C#, tedy s jedním jazykem, jedním stackem, jednou ekosystémou. A tady máte obrovské množství technologií.
Celkem reálná situace, když bash s Pythonem spouští nějaký proces, do kterého se zasouvá JSON. Analyzujete ho, pak nějaký generátor vygeneruje dalších 30 souborů. Pro to všechno přicházejí vstupní proměnné z Azure Key Vault, které jsou staženy pluginem pro drone.io napsaným v Go, a tyto proměnné procházejí YAML, který vznikl z generace šablonovače JSONnet. Docela obtížné mít přísně dobře popsaný kód, když máte tak různorodé prostředí.
Tradiční vývoj v rámci jednoho úkolu probíhá s jedním jazykem. Tady ale pracujeme s velkým množstvím jazyků.
3. Třetí problém - tooling. Jsme zvyklí na skvělé editory (Ms Visual Studio, Jetbrains Rider), které za nás dělají všechno. A i když se nám něco nepodaří, řeknou nám, že nejsme v pořádku. Zdá se, že to je normální a přirozené.
Ale někde blízko je VSCode, ve kterém jsou nějaké pluginy, které se nějak instalují, podporují nebo nepodporují. Vyšly nové verze a tyto už nebyly podpořeny. Banální přechod k implementaci funkce (i když existuje) se stává složitým a netriviálním problémem. Jednoduché přejmenování proměnné je nahrazení v projektu z deseti souborů. Bude mít štěstí, pokud je to to, co má nahradit. Samozřejmě, někde je zvýraznění, někde je automatické dokončení, někde je formátování (pravda, u mě to na Terraformu ve Windows nefungovalo).
V době psaní tohoto článku ještě nezveřejnili podporu verze 0.12, ačkoliv byla vydána už před 3 měsíci.
Přišel čas zapomenout na...
- Debugging.
- Refactoring tool.
- Auto completion.
- Objevování chyb při kompilaci.
Je to legrační, ale to přece zvyšuje čas na vývoj a zvyšuje počet chyb, které nevyhnutelně vznikají.
Nejhorší je, že musíme myslet ne na to, jak navrhnout, rozložit soubory do složek, decomponovat, udělat kód udržovatelným, čitelným a tak dále, ale na to, jak správně napsat tento příkaz, protože jsem ho nějak napsal špatně.
Jako nováček se snažíte pochopit Terraform, a IDE vám v tom vůbec nepomáhá. Když je dokumentace – přišli jste, podívali jste se. Ale kdybyste vcházeli do nového programovacího jazyka, IDE by vám naznačila, že existuje takový typ, a takový ne. Minimálně na úrovni int nebo string. To často bývá užitečné.
A co testy?
Zeptáte se: „Jak je to s testy, pánové programátoři?“ Odpověď je, že vážní kluci všechno testují na produkci, a to tvrdě. Tady je příklad jednotkového testu pro Terraform modul z webu. .
Mají dobrou dokumentaci. Microsoft mi vždy imponoval svým přístupem k dokumentaci a vzdělávání. Ale není nutné být strýčkem Bobem, abychom pochopili, že zde není ideální kód. Všimněte si validace, která je přesunuta doprava.
Problém s jednotkovým testem je, že můžeme ověřit správnost JSONu na výstupu. Poslal jsem 5 parametrů a vygenerovalo mi to JSON se 2000 řádky. Mohu analyzovat, co se zde děje, validate test result…
Je složité analyzovat JSON v Go. Ale musíte psát v Go, protože Terraform na Go je dobrá praxe, co testujete v jazyce, ve kterém píšete. Samo uspořádání kódu je velmi slabé. Přesto je to nejlepší knihovna pro testování.
Microsoft sám píše své moduly a testuje je tímto způsobem. Samozřejmě, že je to Open Source. Všechno, o čem mluvím, můžete přijít a opravit. Mohu si sednout a za týden všechno opravit, open-source pluginy pro VS Code, Terraform, udělat plugin pro Rider. Možná napsat pár analyzátorů, připojit lintery, přispět do knihovny pro testování. Všechno mohu udělat. Ale tím bych se neměl zabývat.
Nejlepší praxe Infrastructure as code
Jdeme dál. Pokud v IaC nejsou testy, je to špatné s IDE a nástroji, alespoň by měly být nejlepší praxe. Jednoduše jsem šel do Google Analytics a porovnal dva vyhledávací dotazy: Terraform best practices a c# best practices.
Co vidíme? Neúprosné statistiky, které nejsou v náš prospěch. Co se týče množství materiálu, je to stejné. V C# vývoji se doslova koupeme v materiálech, máme nadstandardní praxe, existují knihy napsané odborníky a také knížky napsané dalšími odborníky, které kritizují ty první. Moře oficiální dokumentace, článků, výukových kurzů, a teď ještě open source vývoj.
Co se týče dotazu na IaC: tady se snažíte posbírat informace z prezentací Highload nebo HashiConf, z oficiální dokumentace a z mnoha problémů na GitHubu. Jak vlastně tyto moduly rozložit, co s nimi dělat? Zdá se, že to je skutečný problém… Existuje komunita, pánové, kde na každou otázku vám dají 10 komentářů na GitHubu. Ale to není jisté.
Bohužel, odborníci teprve začínají přibývat. Zatím je jich příliš málo. A samotná komunita se nachází na počátku vývoje.
Kam to všechno směřuje a co dělat
Můžete všechno hodit za hlavu a vrátit se zpět k C#, do světa špičkových programátorů. Ale ne. Proč byste se tím vůbec zabývali, pokud nenajdete řešení? Níže uvádím své subjektivní závěry. Můžete se mnou diskutovat v komentářích, bude to zajímavé.
Osobně sázím na několik věcí:
- Rozvoj v této oblasti probíhá velmi rychle. Uvádím graf vyhledávání týkajícího se DevOps.
Možná je to populární téma, ale samotný fakt, že oblast roste, vnáší naději.Pokud něco roste tak rychle, určitě se objeví chytří lidé, kteří říkají, jak to dělat správně a jak ne. Zvyšující se popularita vede k tomu, že si možná někdo konečně najde čas doplnit plugin k jsonnet pro vscode, který umožní přejít k implementaci funkce, a ne ji hledat přes ctrl+shift+f. Když se vše vyvíjí, vzniká více materiálů. Vydání knihy od Googlu o SRE je skvělým příkladem.
- Existují vyvinuté metodiky a praktiky v běžném vývoji, které můžeme úspěšně aplikovat i zde. Ano, jsou zde nuance s testováním a heterogenním prostředím, nedostatečné nástroje, ale bylo nashromážděno obrovské množství praktik, které mohou být užitečné a pomoci.
Banální příklad: spolupráce prostřednictvím párového programování. To výrazně pomáhá pochopit věci. Když máte vedle sebe někoho, kdo se také snaží něco pochopit, společně porozumíte lépe.
Pochopení, jak provádět refaktoring, pomáhá dokonce i v takové situaci ho provádět. To znamená, že můžete neměnit všechno najednou, ale změnit názvosloví, pak změnit umístění, nakonec možná vyčlenit nějakou část, a hezky, tady chybí komentáře.
Závěr
I když se mé úvahy mohou zdát pesimistické, s nadějí se dívám do budoucnosti a upřímně doufám, že se nám (a vám) všechno podaří.
Druhá část článku se již připravuje. V ní se podělím o to, jak jsme se pokusili aplikovat metodiky agilního vývoje, abychom zlepšili náš proces učení a práci s infrastrukturou.
Zdroj: habr.com
