Cégünknél zajlik az SRE-csapat on-boarding folyamata. Én a fejlesztés oldaláról léptem be ebbe a történetbe. A folyamat során gondolatok és meglátások merültek fel bennem, amelyeket szeretnék megosztani más fejlesztőkkel. Ebben a cikkben azt írom le, hogy mi történik, hogyan történik, és hogyan élhetünk tovább mindezzel.
A sorozat folytatása, amely a belső rendezvényünk előadásainak alapján készült. :
2. Infrastrukturális kód. (Itt vagy.)
3. Typescript szerződések generálása C# modellek alapján. (Folyamatban...)
4. Bevezetés a Raft konszenzus algoritmusba. (Folyamatban...)
…
Úgy döntöttünk, hogy SRE csapatot alakítunk, megvalósítva az ötleteket . Programozókat toboroztunk saját fejlesztőink közül, és néhány hónapra képzésre küldtük őket.
A csapat előtt a következő tanulmányi feladatok álltak:
- Leírni az infrastruktúránkat, amely nagyrészt Microsoft Azure-ban található, kódként (Terraform és minden, ami e köré épül).
- Megtanítani a fejlesztőket az infrastruktúrával való munkára.
- Felkészíteni a fejlesztőket az ügyeletekre.
Bevezetjük az infrastruktúra mint kód fogalmát.
A hagyományos világmodellben (klasszikus adminisztráció) az infrastruktúrával kapcsolatos ismeretek két helyen találhatók:
- Vagy a szakértők fejében lévő tudás formájában.
- Vagy ezek az információk valamilyen gépen találhatók, amelynek egy részét szakértők ismerik. De nem biztos, hogy egy külső személy (ha a csapatunk hirtelen eltűnik) meg tudja érteni, hogy mi és hogyan működik. A gépen sok információ lehet: hozzáférések, cron-jobok, alélt disk (lásd ) és egyszerűen végtelen lista arról, hogy mi történhet. Nehéz megérteni, mi folyik valójában.
Mindkét esetben csapdában vagyunk, és függőségekbe kerültünk:
- vagy egy halandó embertől, aki hajlamos betegségekre, szerelemre, hangulatingadozásokra és az egyszerű kirúgásra;
- vagy egy fizikailag működő géptől, amely szintén leáll, ellopják, meglepetéseket okoz és kényelmetlenségeket hoz.
Nyilvánvaló, hogy a megoldás az lenne, hogy ideális esetben mindent emberi olvasásra alkalmas, karbantartható, jól megírt kódra kellene átkonvertálni.
Így tehát az infrastruktúra mint kód (Infrastructure as Code – IaC) a meglévő infrastruktúra kód formájában történő leírása, valamint a vele való munkát és a tényleges infrastruktúra megvalósítását lehetővé tevő eszközök összessége.
Miért kell mindent kódba fordítaniAz emberek nem gépek. Nem tudják mindent megjegyezni. Az emberi és a gépi reakció eltérő. Minden automatizált potenciálisan gyorsabban működik, mint amit az ember végez. A legfontosabb dolog egyetlen igazságforrás (single source of truth).
Honnan jönnek az új SRE mérnökökTehát úgy döntöttünk, hogy új SRE mérnököket vonunk be, de honnan szerezzük őket? A helyes válaszok könyve () azt mondja nekünk: fejlesztőkből. Ők is kóddal dolgoznak, és ti eléritek az ideális állapotot.
Sokáig kerestük őket a munkaerőpiacon kívül a vállalatunkon, de be kell vallanunk, hogy nem találtunk egyet sem a kéréseinknek megfelelően. Így kénytelenek voltunk a saját sorainkban keresgélni.
Infrastructure as Code problémák
Most nézzük meg a példákat arra, hogyan lehet az infrastruktúrát kódba ágyazni. A kód jól van megírva, minőségi, megjegyzésekkel és behúzásokkal.
Példa kód a Terraformból.
Példa kód az Ansible-ból.
Uraim, de ha minden ilyen egyszerű lenne! Hiszen a valós világban élünk, amely mindig készen áll arra, hogy meglepjen bennünket, meglepetéseket és problémákat tartogat. Itt sem feltétlenül elkerülhetők.
1. Az első probléma az, hogy a legtöbb esetben az IaC valamilyen DSL.
A DSL pedig a struktúra leírása. Pontosabban arról, ami neked lennie kell: Json, Yaml, a nagyobb cégek által kitalált módosítások, amelyek saját DSL-t hoztak létre (a Terraform HCL-t használ).
A baj az, hogy benne könnyen hiányozhatnak olyan megszokott dolgok, mint:
- változók;
- feltételek;
- valahol nincsenek megjegyzések, például a Json-ban alapértelmezetten nem biztosították őket;
- függvények;
- és még nem is beszéltem az olyan magas szintű dolgokról, mint az osztályok, öröklődés és hasonlók.
2. A második probléma ezzel a kóddal az, hogy gyakran heterogén környezetben dolgozunk. Általában C#-on dolgozol, tehát egy nyelven, egy stackkel, egy ökoszisztémával. De itt hatalmas technológiai változatosság van.
Egészen valós helyzet, amikor egy bash script Python alatt elindít egy olyan folyamatot, amelybe Json-t injektálnak. Ön ezt elemzi, majd egy másik generátor 30 fájlt eredményez. Mindezhez bemeneti változók érkeznek az Azure Key Vault-ból, amelyeket a Go nyelven írt drone.io plugin hív be, és ezek a változók yaml-on keresztül jutnak el, amelyet a jsonnet sablonkezelő generált. Nehéz szigorúan jól dokumentált kódot fenntartani, amikor ennyire változatos a környezet.
A hagyományos fejlesztés keretein belül egy feladatra egy nyelv használatával történik. Itt azonban számos nyelvvel dolgozunk.
3. A harmadik probléma – a tooling.. Hozzá vagyunk szokva a nagyszerű szerkesztőkhöz (Ms Visual Studio, Jetbrains Rider), amelyek mindent elvégeznek helyettünk. És még ha hibázunk is, ők megmondják, hogy tévedünk. Úgy tűnik, hogy ez normális és természetes.
De valahol ott van a VSCode, benne olyan pluginekkel, amelyek valahogyan telepítve vannak, fenntartva vagy nem fenntartva. Új verziók jelentek meg, de nem támogatják őket. Az egyszerű funkció implementálásának átmenete (még ha létezik is) bonyolult és nem trivális problémává válik. Egy egyszerű változónév átnevezése projekt szinten több tucat fájlban. Szerencse, ha pont azt cseréli, amit kellene. Persze néhol van szintaxis kiemelés, van automatikus kiegészítés, valahol van formázás (bár nekem a Terraform Windows alatt nem működik).
A cikk írásának időpontjában még nem adták ki a 0.12-es verzió támogatását, pedig már 3 hónapja kiadták.
Eljött az idő elfelejteni...
- Hibakeresés.
- Refaktorizáló eszköz.
- Automatikus kiegészítés.
- Hibák észlelése fordítás közben.
Vicces, de ez növeli a fejlesztési időt és növeli a hibák számát, amelyek elkerülhetetlenül bekövetkeznek.
A legrosszabb az, hogy nem azt kellene gondolnunk, hogyan tervezzünk, rendszerezzük a fájlokat könyvtárakba, dekomponáljunk, támogathatóvá és olvashatóvá tegyük a kódot, hanem hogy hogyan írjam helyesen ezt a parancsot, mert valahogy rosszul írtam.
Kezdőként próbálja megérteni a Terraformot, de az IDE ebben egyáltalán nem segít. Amikor van dokumentáció – belép, megnézi. De ha új programozási nyelvbe kezdene bele, az IDE jelezné, hogy létezik egy ilyen típus, és egy olyan nem. Legalábbis int vagy string szinten. Ez gyakran hasznos lehet.
De hol vannak a tesztek?
Kérdezni fogják: „Hogyan állnak a tesztek, kedves programozók?” A komoly srácok mindent élesben tesztelnek, és ez kemény. Íme egy példa egy unit tesztre egy Terraform modulról a weboldalról. .
Jó dokumentációjuk van. A Microsoft mindig is tetszett a dokumentációs és oktatási megközelítésével. De nem kell Bob bácsinak lenni ahhoz, hogy észrevegyük, itt nem ideális a kód. Figyelj a validációra, amit jobbra helyeztek.
A unit teszt problémája abban rejlik, hogy ellenőrizhetjük a Json kimenet helyességét. Öt paramétert adtam meg, és egy 2000 soros Json-t kaptam. Elemezhetem, mi történik itt, érvényesíthetem a teszt eredményét...
Nehéz Json-t elemezni Go-ban. De Go-ban kell írni, mert a Terraform Go-ban van, ami jó gyakorlat, hiszen abban a nyelvben tesztelsz, amelyben írsz. A kód szervezése nagyon gyenge. Ennek ellenére ez a legjobb könyvtár a teszteléshez.
A Microsoft is írja a moduljait, tesztelve őket ilyen módon. Nyilvánvalóan ez Open Source. Amit mondok, azt jöhetsz és megjavíthatod. Le tudok ülni, és egy hét alatt mindent meg tudok javítani, open source-ba tudom tenni a VS Code plugineket, a Terraformot, tudok írni egy plugint a Riderhez. Talán írok pár elemzőt, csatolok lintereket, hozzájárulok a tesztelési könyvtárhoz. Mindenképp meg tudom csinálni. De nem ezzel kellene foglalkoznom.
A legjobb gyakorlatok az infrastruktúra kód formájában.
Tovább megyünk. Ha az IaC-nak nincsenek tesztjei, gyenge az IDE és a tooling, akkor legalább legyenek a legjobb gyakorlatok. Egyszerűen csak bementem a Google Analytics-be, és összehasonlítottam két keresési kifejezést: Terraform legjobb gyakorlatok és C# legjobb gyakorlatok.
Mit látunk? Kíméletlen statisztikát, ami nem a mi javunkra szolgál. Anyagmennyiségben ugyanazt tapasztaljuk. A C# fejlesztésben egyszerűen fürdünk az anyagokban, megvannak a szuper legjobb gyakorlatok, vannak könyvek, amelyeket szakértők írtak, és emellett könyvek, amelyeket más szakértők írtak az előző könyvekkel kapcsolatos kritikákhoz. Rengeteg hivatalos dokumentáció, cikk, oktatóanyag, most még open source fejlesztés is elérhető.
Ami az IaC-ra vonatkozó keresést illeti: itt apránként próbálják összehozni az információt a nagy terhelésű előadásokról vagy a HashiConf-ról, a hivatalos dokumentációból és a számos GitHub issue-ból. Hogyan is oszthatók el ezek a modulok, mit lehet velük kezdeni? Úgy tűnik, hogy ez valódi probléma... Van közösség, uraim, ahol bármilyen kérdésre 10 kommentet kapsz a GitHubon. De ez nem biztos.
Sajnálom, jelenleg a szakértők csak most kezdik el megjelenni. Még mindig túl kevesen vannak. Az egész közösség pedig néhány gyermekcipőben jár.
Merre tart mindez és mit tegyünk?
Mindent hátra lehet hagyni és visszatérni a C# világába, a riderhez. De nem. Miért is foglalkoznál vele, ha nem találnád meg a megoldást? Az alábbiakban szubjektív következtetéseimet osztom meg. Érdekes lenne vitatkozni velem a kommentekben.
Személy szerint több dologra is fogadnék:
- A fejlődés ezen a területen nagyon gyorsan zajlik. Bemutatok egy grafikont a DevOps keresésekről.
Lehet, hogy a téma népszerű, de az a tény, hogy a terület növekszik, némi reményt ad.Ha valami így növekszik, biztosan lesznek okos emberek, akik megmondják, hogyan kell csinálni, és hogyan nem. A népszerűség növekedése azt is jelenti, hogy talán valakinek végre lesz ideje befejezni a jsonnet plugint a vscode-hoz, amely lehetővé teszi a funkciók megvalósításához való ugrást, ahelyett, hogy a ctrl+shift+f segítségével keresgélj. Amikor minden fejlődik, több anyag is megjelenik. A Google SRE-ről szóló könyvének megjelenése remek példa erre.
- Vannak kifejlesztett módszerek és gyakorlatok a hagyományos fejlesztésben, amelyeket sikeresen alkalmazhatunk itt is. Igen, vannak nyűgök a tesztelésben és a heterogén környezetben, és a túlságosan alacsony eszközkészlet, de rengeteg gyakorlatot felhalmoztunk, amelyek hasznosak lehetnek.
Egy banális példa: a párban programozás. Nagyon segít abban, hogy rájöjjünk a dolgokra. Amikor melletted ül valaki, aki szintén próbál valamit megérteni, együtt jobban megértitek a dolgokat.
A refaktorálás megértése még így is segít a folyamat végrehajtásában. Tehát, nem kell mindent egyszerre megváltoztatnod, először a névadást változtatod, majd a elhelyezést, esetleg kiemelsz egy részt, óh, itt meg nincsenek megjegyzések.
Zárás
Bár a gondolataim pesszimistának tűnhetnek, reménnyel tekintek a jövőbe, és őszintén bízom benne, hogy nekünk (és nektek) sikerülni fog.
Hamarosan érkezik a cikk második része. Ebben arról fogok beszélni, hogyan próbáltuk alkalmazni a rugalmas fejlesztési gyakorlatokat, hogy javítsuk a tanulási folyamatunkat és a munkát az infrastruktúrával.
Forrás: habr.com
