Naše společnost je v procesu začleňování týmu SRE. Do celého tohoto příběhu jsem vstoupil z vývojové stránky. Během toho jsem přišel s myšlenkami a postřehy, o které se chci podělit s ostatními vývojáři. V tomto reflexním článku mluvím o tom, co se děje, jak se to děje a jak s tím může každý dál žít.
Pokračování série článků napsaných na základě projevů na naší interní akci :
2. Infrastruktura jako kód. (Jsi tady)
3. Generování smluv Typescript pomocí C# modelů. (Probíhá...)
4. Úvod do konsenzuálního algoritmu Raft. (Probíhá...)
...
Rozhodli jsme se vytvořit tým SRE, implementující nápady . Naverbovali programátory z řad svých vlastních vývojářů a poslali je na několik měsíců trénovat.
Tým měl následující tréninkové úkoly:
- Popište naši infrastrukturu, která je většinou v Microsoft Azure ve formě kódu (Terraform a vše kolem).
- Naučte vývojáře, jak pracovat s infrastrukturou.
- Připravte vývojáře na povinnost.
Představujeme pojem Infrastruktura jako kód
V obvyklém modelu světa (klasická administrativa) se znalosti o infrastruktuře nacházejí na dvou místech:
- Nebo v podobě znalostí v hlavách odborníků.
- Nebo jsou tyto informace na některých psacích strojích, z nichž některé jsou odborníkům známé. Ale není pravda, že někdo zvenčí (v případě, že celý náš tým náhle zemře) bude schopen zjistit, co funguje a jak to funguje. Na stroji může být mnoho informací: příslušenství, cronjobs, zastrašování (viz. ) disk a jen nekonečný seznam toho, co se může stát. Je těžké pochopit, co se skutečně děje.
V obou případech se ocitáme v pasti stát se závislými:
- nebo od člověka, který je smrtelný, trpí nemocí, zamilovaností, změnami nálad a jednoduše banálním propouštěním;
- nebo z fyzicky pracujícího stroje, který také spadne, je ukraden a představuje překvapení a nepříjemnosti.
Je samozřejmé, že v ideálním případě by vše mělo být přeloženo do čitelného, udržovatelného a dobře napsaného kódu.
Infrastruktura jako kód (Incfastructure as Code - IaC) je tedy popis celé stávající infrastruktury ve formě kódu a také související nástroje pro práci s ní a implementaci reálné infrastruktury z ní.
Proč překládat všechno do kódu?Lidé nejsou stroje. Nemohou si všechno pamatovat. Reakce člověka a stroje je jiná. Cokoli automatizovaného je potenciálně rychlejší než cokoli, co dělá člověk. Nejdůležitější je jediný zdroj pravdy.
Odkud pocházejí noví inženýři SRE?Takže jsme se rozhodli najmout nové SRE inženýry, ale kde je získat? Kniha se správnými odpověďmi () nám říká: od vývojářů. Pracují totiž s kódem a vy dosáhnete ideálního stavu.
Dlouho jsme je hodně hledali na personálním trhu mimo naši společnost. Ale musíme přiznat, že jsme nenašli nikoho, kdo by vyhovoval našim požadavkům. Musel jsem hledat mezi svými.
Problémy Infrastruktura jako kód
Nyní se podívejme na příklady toho, jak lze infrastrukturu napevno zakódovat do kódu. Kód je dobře napsaný, kvalitní, s komentáři a odsazením.
Příklad kódu z Terraforma.
Příklad kódu z Ansible.
Pánové, kdyby to bylo tak jednoduché! Jsme v reálném světě a ten je vždy připraven vás překvapit, předložit vám překvapení a problémy. Ani tady to bez nich nejde.
1. První problém je, že ve většině případů je IaC nějaký druh dsl.
A DSL je zase popisem struktury. Přesněji, co byste měli mít: Json, Yaml, úpravy od některých velkých společností, které přišly s vlastním dsl (HCL se používá v terraformu).
Problém je v tom, že snadno nemusí obsahovat takové známé věci jako:
- proměnné;
- podmínky;
- někde nejsou žádné komentáře, například v Json, ve výchozím nastavení nejsou poskytovány;
- funkce;
- a to ani nemluvím o tak vysokých věcech, jako jsou třídy, dědičnost a tak.
2. Druhým problémem takového kódu je, že se nejčastěji jedná o heterogenní prostředí. Obvykle sedíte a pracujete s C#, tzn. s jedním jazykem, jedním zásobníkem, jedním ekosystémem. A tady máte obrovskou škálu technologií.
Je to velmi reálná situace, kdy bash s pythonem spustí nějaký proces, do kterého je vložen Json. Vy to analyzujete, pak nějaký jiný generátor vytvoří dalších 30 souborů. K tomu všemu jsou z Azure Key Vault přijímány vstupní proměnné, které jsou staženy pluginem pro drone.io napsaným v Go, a tyto proměnné procházejí přes yaml, který byl vygenerován jako výsledek generování z jsonnet template engine. Je docela těžké mít striktně dobře popsaný kód, když máte tak rozmanité prostředí.
Tradiční vývoj v rámci jednoho úkolu přichází s jedním jazykem. Zde pracujeme s velkým množstvím jazyků.
3. Třetím problémem je ladění. Jsme zvyklí na cool editory (Ms Visual Studio, Jetbrains Rider), které dělají vše za nás. A i když jsme hloupí, řeknou, že se mýlíme. Zdá se to normální a přirozené.
Ale někde poblíž je VSCode, ve kterém jsou nějaké pluginy, které jsou nějak nainstalovány, podporovány nebo nepodporovány. Vyšly nové verze a nebyly podporovány. Banální přechod k implementaci funkce (i když existuje) se stává komplexním a netriviálním problémem. Jednoduché přejmenování proměnné je přehráním v projektu tuctu souborů. Budete mít štěstí, pokud umístí to, co potřebujete. Sem tam je samozřejmě podsvícení, automatické dokončování, někde formátování (i když v terraformu na Windows mi to nefungovalo).
V době psaní tohoto článku dosud nebyly vydány na podporu verze 0.12, ačkoliv byla vydána již 3 měsíce.
Je čas zapomenout na...
- Ladění.
- Refaktorovací nástroj.
- Automatické dokončení.
- Detekce chyb během kompilace.
Je to legrační, ale také to prodlužuje dobu vývoje a zvyšuje počet chyb, ke kterým nevyhnutelně dochází.
Nejhorší je, že jsme nuceni přemýšlet ne o tom, jak navrhnout, uspořádat soubory do složek, rozložit, udělat kód udržovatelný, čitelný a tak dále, ale o tom, jak mohu tento příkaz napsat správně, protože jsem to nějak napsal špatně .
Jako začátečník se snažíte naučit terraformy a IDE vám vůbec nepomáhá. Až bude dokumentace, jděte dovnitř a podívejte se. Ale pokud byste zadávali nový programovací jazyk, IDE by vám řeklo, že takový typ existuje, ale nic takového neexistuje. Alespoň na úrovni int nebo string. To je často užitečné.
A co testy?
Ptáte se: "A co testy, pánové programátoři?" Vážní chlapi testují všechno na produkci a je to těžké. Zde je příklad testu jednotky pro modul terraform z webu .
Mají dobrou dokumentaci. Microsoft se mi vždy líbil pro jeho přístup k dokumentaci a školení. Ale nemusíte být strýček Bob, abyste pochopili, že to není dokonalý kód. Všimněte si ověření vpravo.
Problém s testem jednotek je v tom, že vy a já můžeme zkontrolovat správnost výstupu Json. Hodil jsem 5 parametrů a dostal jsem nánožník Json s 2000 řádky. Mohu analyzovat, co se tu děje, ověřit výsledek testu...
Je obtížné analyzovat Json v Go. A musíte psát v Go, protože terraform v Go je dobrá praxe pro testování v jazyce, ve kterém píšete. Organizace samotného kódu je velmi slabá. Zároveň se jedná o nejlepší knihovnu pro testování.
Microsoft sám píše své moduly a testuje je tímto způsobem. Samozřejmě je to Open Source. Všechno, o čem mluvím, můžeš přijít a opravit. Můžu si sednout a vše opravit za týden, open source pluginy VS kódu, terraformy, udělat plugin pro jezdce. Možná napsat pár analyzátorů, přidat linters, přispět knihovnou pro testování. Já můžu všechno. Ale to není to, co bych měl dělat.
Osvědčené postupy Infrastruktura jako kód
Pokračujme. Pokud v IaC nejsou žádné testy, IDE a ladění jsou špatné, pak by měly existovat alespoň osvědčené postupy. Právě jsem šel do Google Analytics a porovnal dva vyhledávací dotazy: osvědčené postupy Terraform a osvědčené postupy c#.
co vidíme? Nelítostné statistiky nám nejsou nakloněny. Množství materiálu je stejné. Ve vývoji C# jsme prostě zaplaveni materiály, máme super-osvědčené postupy, existují knihy napsané odborníky a také knihy napsané na knihách od jiných odborníků, kteří tyto knihy kritizují. Moře oficiální dokumentace, článků, školicích kurzů a nyní také open source vývoje.
Pokud jde o požadavek IaC: zde se snažíte sbírat informace kousek po kousku ze zpráv o vysokém zatížení nebo HashiConf, z oficiální dokumentace a mnoha problémů na Githubu. Jak tyto moduly obecně distribuovat, co s nimi dělat? Zdá se, že je to skutečný problém... Existuje komunita, pánové, kde za jakýkoli dotaz dostanete 10 komentářů na Githubu. Ale není to přesně tak.
Bohužel v tuto chvíli se odborníci teprve začínají objevovat. Zatím je jich příliš málo. A komunita samotná se poflakuje na základní úrovni.
Kam to všechno spěje a co dělat
Vše můžete zahodit a vrátit se do C#, do světa jezdce. Ale ne. Proč byste se s tím vůbec obtěžovali, když nemůžete najít řešení. Níže uvádím své subjektivní závěry. Můžete se mnou polemizovat v komentářích, bude to zajímavé.
Osobně sázím na několik věcí:
- Vývoj v této oblasti probíhá velmi rychle. Zde je plán požadavků na DevOps.
Téma může být humbuk, ale už samotný fakt, že sféra roste, dává určitou naději.Pokud něco tak rychle roste, tak se určitě objeví chytří lidé, kteří vám řeknou, co máte dělat a co ne. Nárůst popularity vede k tomu, že možná někdo bude mít čas konečně přidat plugin do jsonnet pro vscode, který vám umožní přejít k implementaci funkce, spíše než ji hledat přes ctrl+shift+f. Jak se věci vyvíjejí, objevuje se více materiálů. Vydání knihy od Googlu o SRE je toho skvělým příkladem.
- V konvenčním vývoji jsou vyvinuté techniky a postupy, které zde můžeme úspěšně aplikovat. Ano, existují nuance s testováním a heterogenní prostředí, nedostatečné nástroje, ale nashromáždilo se obrovské množství postupů, které mohou být užitečné a užitečné.
Triviální příklad: spolupráce prostřednictvím párového programování. Hodně pomáhá to zjistit. Když máte nablízku souseda, který se také snaží něco pochopit, společně si lépe porozumíte.
Pochopení toho, jak se refaktoring provádí, pomáhá k jeho provedení i v takové situaci. To znamená, že nemůžete změnit vše najednou, ale změnit pojmenování, pak změnit umístění, pak můžete zvýraznit nějakou část, ale není zde dostatek komentářů.
Závěr
Navzdory tomu, že se má úvaha může zdát pesimistická, dívám se do budoucnosti s nadějí a upřímně doufám, že nám (i vám) vše klapne.
Další část článku se připravuje. V něm budu hovořit o tom, jak jsme se snažili pomocí agilních vývojových postupů zlepšit proces učení a práci s infrastrukturou.
Zdroj: www.habr.com