Cégünk egy SRE csapat beépítése folyamatban van. A fejlesztés oldaláról jöttem bele ebbe az egész történetbe. A folyamat során olyan gondolatok és meglátások jutottak eszembe, amelyeket meg szeretnék osztani más fejlesztőkkel. Ebben a reflexiós cikkben arról beszélek, hogy mi történik, hogyan történik, és hogyan élhet tovább mindenki vele.
Belső rendezvényünkön elhangzott beszédek alapján írt cikksorozat folytatása :
2. Infrastruktúra mint kód. (Ön itt van)
3. Typescript szerződések generálása C# modellek segítségével. (Folyamatban...)
4. Bevezetés a Raft konszenzus algoritmusba. (Folyamatban...)
...
Úgy döntöttünk, hogy létrehozunk egy SRE csapatot, megvalósítva az ötleteket . Saját fejlesztőik közül toboroztak programozókat, és több hónapra elküldték őket képzésre.
A csapatnak a következő edzési feladatai voltak:
- Ismertesse az infrastruktúránkat, amely többnyire a Microsoft Azure-ban található kód formájában (Terraform és minden körülötte).
- Tanítsa meg a fejlesztőknek az infrastruktúrával való együttműködést.
- Készítse fel a fejlesztőket a szolgálatra.
Bemutatjuk az Infrastruktúra mint kód fogalmát
A világ szokásos modelljében (klasszikus közigazgatás) az infrastruktúrával kapcsolatos ismeretek két helyen helyezkednek el:
- Vagy tudás formájában a szakértők fejében.
- Vagy ez az információ néhány írógépen található, amelyek közül néhányat a szakértők ismernek. De nem tény, hogy egy kívülálló (ha az egész csapatunk hirtelen meghalna) képes lesz rájönni, mi és hogyan működik. Sok információ lehet egy gépen: tartozékok, cronjobs, megfélemlített (lásd. ) lemez, és csak egy végtelen lista arról, hogy mi történhet. Nehéz megérteni, mi történik valójában.
Mindkét esetben a függővé válás csapdájában találjuk magunkat:
- vagy olyan személytől, aki halandó, ki van téve betegségnek, szerelmesnek, hangulati ingadozásoknak és egyszerűen banális elbocsátásoknak;
- vagy egy fizikailag működő gépről, ami szintén leesik, ellopják, és meglepetéseket, kellemetlenségeket okoz.
Magától értetődik, hogy ideális esetben mindent ember által olvasható, karbantartható, jól megírt kódra kellene lefordítani.
Így az infrastruktúra mint kód (Incfastructure as Code - IaC) a teljes meglévő infrastruktúra leírása kód formájában, valamint a vele való munkavégzéshez és a belőle valós infrastruktúra megvalósításához kapcsolódó kapcsolódó eszközök.
Miért kell mindent kódra fordítani?Az emberek nem gépek. Nem tudnak mindenre emlékezni. Az ember és a gép reakciója más. Bármi, amit automatizálnak, potenciálisan gyorsabb, mint bármi, amit egy ember csinál. A legfontosabb az igazság egyetlen forrása.
Honnan jönnek az új SRE mérnökök?Tehát úgy döntöttünk, hogy új SRE mérnököket veszünk fel, de honnan szerezzük be őket? Könyv a helyes válaszokkal () azt mondja nekünk: a fejlesztőktől. Végül is a kóddal dolgoznak, és Ön eléri az ideális állapotot.
Sokáig kerestük őket a cégünkön kívüli munkaerőpiacon. De el kell ismernünk, hogy nem találtunk senkit, aki megfelelt volna a kéréseinknek. A saját embereim között kellett keresgélnem.
Problémák Az infrastruktúra kódként
Most nézzünk példákat arra, hogyan lehet az infrastruktúrát kódba kódolni. A kód jól megírt, jó minőségű, megjegyzésekkel és behúzással.
Példakód a Terraformától.
Példakód az Ansible-től.
Uraim, ha ez ilyen egyszerű lenne! A való világban élünk, és mindig készen áll arra, hogy meglepjen, meglepetésekkel és problémákkal ajándékozza meg. Itt sem lehet nélkülük.
1. Az első probléma az, hogy a legtöbb esetben az IaC valamilyen dsl.
A DSL pedig a szerkezet leírása. Pontosabban, ami kellene: Json, Yaml, néhány nagy cég módosításai, amelyek saját dsl-vel álltak elő (a HCL-t terraformban használják).
Az a baj, hogy könnyen előfordulhat, hogy nem tartalmaz olyan ismerős dolgokat, mint:
- változók;
- körülmények;
- valahol nincsenek megjegyzések, például a Json-ban, alapértelmezés szerint nincsenek megadva;
- funkciók;
- és nem is beszélek olyan magas szintű dolgokról, mint az osztályok, az öröklés meg minden.
2. A második probléma az ilyen kóddal, hogy legtöbbször heterogén környezetről van szó. Általában C#-al ülsz és dolgozol, pl. egy nyelvvel, egy köteggel, egy ökoszisztémával. És itt van a technológia hatalmas választéka.
Nagyon valós helyzet, amikor a bash with python elindít valamilyen folyamatot, amelybe a Json be van illesztve. Elemezed, majd egy másik generátor további 30 fájlt készít. Mindehhez az Azure Key Vaultból bemeneti változók érkeznek, amelyeket egy Go-ban írt drone.io-hoz tartozó plugin húz össze, és ezek a változók átmennek a yaml-n, amely a jsonnet sablonmotorból történő generálás eredményeként jött létre. Elég nehéz szigorúan jól leírt kóddal rendelkezni, ha ilyen változatos környezetünk van.
Az egy feladat keretein belüli hagyományos fejlesztés egy nyelvvel jár. Itt nagyon sok nyelvvel dolgozunk.
3. A harmadik probléma a hangolás. Megszoktuk a menő szerkesztőket (Ms Visual Studio, Jetbrains Rider), amelyek mindent megtesznek helyettünk. És még ha hülyék is vagyunk, azt fogják mondani, hogy tévedünk. Normálisnak és természetesnek tűnik.
De valahol a közelben van a VSCode, amelyben van néhány plugin, amely valamilyen módon telepítve van, támogatott vagy nem támogatott. Új verziók jelentek meg, és nem támogatottak. Egy funkció megvalósítására való banális átmenet (még ha létezik is) összetett és nem triviális problémává válik. Egy változó egyszerű átnevezése egy tucatnyi fájlból álló projekt újrajátszása. Szerencsés lesz, ha elhelyezi, amire szüksége van. Persze itt-ott van háttérvilágítás, van automatikus kiegészítés, valahol van formázás (bár ez terraformban nekem nem ment Windowson).
Jelen írás idején még nem adták ki a 0.12-es verzió támogatására, bár már 3 hónapja kiadták.
Ideje elfelejteni...
- Hibakeresés.
- Refaktoráló eszköz.
- Automatikus kiegészítés.
- Hibák észlelése a fordítás során.
Vicces, de ez megnöveli a fejlesztési időt és növeli az elkerülhetetlenül előforduló hibák számát.
A legrosszabb az, hogy nem azon vagyunk kénytelenek gondolkodni, hogyan tervezzünk, mappákba rendezzük a fájlokat, bontsuk le, hogyan tegyük karbantarthatóvá, olvashatóvá stb., hanem azon, hogyan tudom helyesen írni ezt a parancsot, mert valahogy rosszul írtam. .
Kezdőként terraformokat próbál tanulni, és az IDE egyáltalán nem segít. Ha megvan a dokumentáció, menjen be és nézze meg. De ha új programozási nyelvet írnál be, akkor az IDE azt mondaná, hogy van ilyen típus, de ilyen nincs. Legalábbis int vagy string szinten. Ez gyakran hasznos.
Mi lesz a tesztekkel?
Azt kérdezed: "Mi a helyzet a tesztekkel, programozó urak?" A komoly srácok mindent tesztelnek a gyártás során, és ez kemény. Íme egy példa egy terraform modul egységtesztjére a webhelyről .
Jó dokumentációjuk van. Mindig is szerettem a Microsoftot a dokumentációhoz és a képzéshez való hozzáállásáért. De nem kell Bob bácsinak lenned ahhoz, hogy megértsd, ez nem tökéletes kód. Jegyezze fel az érvényesítést a jobb oldalon.
Az egységteszttel az a probléma, hogy te és én ellenőrizhetjük a Json kimenet helyességét. 5 paramétert dobtam be és kaptam egy Json lábtörlőt 2000 sorral. Elemezhetem, mi folyik itt, és ellenőrizhetem a teszt eredményét...
Nehéz a Json elemzése a Go-ban. És Go-ban kell írnia, mert a terraform a Go-ban jó gyakorlat a teszteléshez azon a nyelven, amelyen ír. Maga a kód felépítése nagyon gyenge. Ugyanakkor ez a legjobb könyvtár a teszteléshez.
A Microsoft maga írja moduljait, így teszteli őket. Természetesen nyílt forráskódú. Mindent, amiről beszélek, jöhet, és megjavít. Leülhetek és egy hét alatt mindent megjavítok, nyílt forráskódú VS kód pluginokat, terraformokat, készítek plugint a ridernek. Esetleg írjon pár elemzőt, adjon hozzá lintereket, adjon hozzá egy könyvtárat a teszteléshez. Mindent megtudok tenni. De nem ezt kellene tennem.
Bevált gyakorlatok Infrastruktúra kódként
Menjünk tovább. Ha az IaC-ben nincsenek tesztek, rossz az IDE és a hangolás, akkor legalább a legjobb gyakorlatok kellenek. Most felkerestem a Google Analytics szolgáltatást, és összehasonlítottam két keresési lekérdezést: a Terraform legjobb gyakorlatait és a c# legjobb gyakorlatait.
Mit látunk? A kíméletlen statisztikák nem nekünk kedveznek. Az anyag mennyisége azonos. A C# fejlesztésben egyszerűen elárasztjuk az anyagokat, vannak szuper legjobb gyakorlataink, vannak szakértők által írt könyvek, és vannak olyan könyvek is, amelyeket más szakértők írnak könyvekre, akik kritizálják ezeket a könyveket. Hivatalos dokumentációk, cikkek, tanfolyamok és most már nyílt forráskódú fejlesztések tengere is.
Ami az IaC kérést illeti: itt a highload vagy a HashiConf jelentésekből, a hivatalos dokumentációból és a Github számos problémájából próbálunk apránként információkat gyűjteni. Hogyan lehet ezeket a modulokat általában terjeszteni, mit kell tenni velük? Úgy tűnik, ez valós probléma... Van egy közösség, uraim, ahol bármilyen kérdésre 10 megjegyzést kapnak a Githubon. De nem pontosan.
Sajnos ebben az időben a szakértők csak most kezdenek megjelenni. Egyelőre túl kevés van belőlük. Maga a közösség pedig kezdetleges szinten lóg ki.
Hová tart ez az egész és mit kell tenni
Mindent eldobhatsz, és visszatérhetsz a C#-hoz, a rider világába. De nem. Miért is foglalkozol ezzel, ha nem találsz megoldást. Az alábbiakban szubjektív következtetéseimet ismertetem. Hozzászólásban lehet vitatkozni velem, érdekes lesz.
Én személy szerint néhány dologra tippelek:
- A fejlődés ezen a területen nagyon gyorsan megy végbe. Itt található a DevOps kérelmek ütemezése.
A téma lehet hype, de már maga a tény, hogy a szféra növekszik, némi reményt ad.Ha valami ilyen gyorsan fejlődik, akkor biztosan megjelennek okos emberek, akik megmondják, mit tegyél és mit ne. A népszerűség növekedése oda vezet, hogy talán valakinek lesz ideje végre hozzáadni egy plugint a jsonnethez a vscode-hoz, amely lehetővé teszi, hogy a ctrl+shift+f billentyűkombinációval való keresés helyett továbbléphessen a funkció megvalósítására. Ahogy a dolgok fejlődnek, egyre több anyag jelenik meg. Kiváló példa erre, hogy a Google kiadott egy könyvet az SRE-ről.
- Vannak kifejlesztett technikák és gyakorlatok a hagyományos fejlesztésben, amelyeket itt sikeresen alkalmazhatunk. Igen, vannak árnyalatok a teszteléssel és a heterogén környezettel, az elégtelen eszközökkel, de rengeteg gyakorlat halmozódott fel, amelyek hasznosak és hasznosak lehetnek.
Egy triviális példa: együttműködés páros programozáson keresztül. Sokat segít kitalálni. Ha van egy szomszéd a közelben, aki szintén megpróbál megérteni valamit, akkor együtt jobban megértitek.
A refaktorálás módjának megértése még ilyen helyzetben is segít a végrehajtásban. Vagyis nem lehet mindent egyszerre megváltoztatni, hanem megváltoztatni a névadást, utána megváltoztatni a helyszínt, akkor lehet kiemelni valamelyik részt, ja, de itt kevés a komment.
Következtetés
Annak ellenére, hogy érvelésem pesszimistának tűnhet, reménykedve tekintek a jövőbe, és őszintén remélem, hogy nekünk (és neked) minden sikerülni fog.
A cikk második része most készül. Ebben arról fogok beszélni, hogyan próbáltunk agilis fejlesztési gyakorlatokat alkalmazni tanulási folyamatunk fejlesztésére és az infrastruktúrával való együttműködésre.
Forrás: will.com