A megközelítés IaC (Infrastructure as Code) nem csak a tárolóban tárolt kódból áll, hanem a kódot körülvevő emberekből és folyamatokból is. Lehetséges-e újrafelhasználni a megközelítéseket a szoftverfejlesztéstől az infrastruktúra kezeléséig és leírásáig? Jó ötlet lenne ezt a gondolatot szem előtt tartani a cikk olvasása közben.

Ez az én átiratom előadások on DevopsConf 2019-05-28.

Diák és videók

angol verzió
Orosz változat
Száraz futás 2019-04-24 SpbLUG
Videó (RU) a DevopsConf-ból 2019
Videó (RU) a DINS DevOps ESTE 2019-06-20-tól
Diák

Az infrastruktúra mint bash történelem

Tegyük fel, hogy egy új projekthez érkezel, és azt mondják: „Megvan Infrastruktúra mint kód". A valóságban kiderül Az infrastruktúra mint bash történelem vagy például Dokumentáció bash történelemként. Ez egy nagyon is valós helyzet, egy hasonló esetet például Denis Liszenko is leírt beszédében Hogyan cseréljük ki a teljes infrastruktúrát és kezdjünk el nyugodtan aludni, elmondta, hogyan szereztek koherens infrastruktúrát a projekthez a bash history-ból.

Némi vággyal kijelenthetjük Az infrastruktúra mint bash történelem ez olyan mint a kód:

reprodukálhatóság: Vedd a bash előzményeket, onnan lefuttathatod a parancsokat, és lehet, hogy egyébként egy működő konfigurációt kapsz kimenetként.
verziószámítás: tudja, hogy ki jött be és mit csinált, ismét nem tény, hogy ez egy működő konfigurációhoz vezet a kijáratnál.
история: a története, hogy ki mit csinált. csak akkor nem fogja tudni használni, ha elveszti a szervert.

Mit kell tenni?

Infrastruktúra mint kód

Még egy olyan furcsa eset is, mint Az infrastruktúra mint bash történelem a fülénél fogva húzhatod Infrastruktúra mint kód, de amikor valami bonyolultabbat akarunk csinálni, mint a jó öreg LAMP szerver, akkor arra a következtetésre jutunk, hogy ezt a kódot valahogy módosítani, módosítani, javítani kell. A következőkben a közötti párhuzamokat szeretnénk megvizsgálni Infrastruktúra mint kód és szoftverfejlesztés.

SZÁRAZ.

Egy tárolórendszer-fejlesztési projektnél volt egy részfeladat időnként konfigurálja az SDS-t: új kiadást adunk ki – azt ki kell dobni további teszteléshez. A feladat rendkívül egyszerű:

ssh-n keresztül jelentkezz be ide, és hajtsd végre a parancsot.
másolja oda a fájlt.
itt javítsd ki a konfigurációt.
ott indítsa el a szolgáltatást
...
PROFIT!

A leírt logikához a bash bőven elég, különösen a projekt korai szakaszában, amikor még csak most kezdődik. Ez nem rossz, hogy bash-t használsz, de idővel érkeznek kérések valami hasonló, de kissé eltérő telepítésére. Az első dolog, ami eszünkbe jut, a másolás-beillesztés. És most már van két nagyon hasonló szkriptünk, amelyek majdnem ugyanazt a dolgot csinálják. Idővel a szkriptek száma nőtt, és szembesültünk azzal a ténnyel, hogy van egy bizonyos üzleti logika egy telepítés telepítéséhez, amelyet szinkronizálni kell a különböző szkriptek között, ez meglehetősen bonyolult.

Kiderült, hogy létezik olyan gyakorlat, mint a D.R.Y. (Ne ismételd magad). Az ötlet a meglévő kód újrafelhasználása. Egyszerűen hangzik, de nem jöttünk rá azonnal. A mi esetünkben ez egy banális ötlet volt: elválasztani a konfigurációkat a szkriptektől. Azok. a telepítés külön-külön történő telepítésének üzleti logikája, külön a konfigurációk.

SZILÁRD. a CFM számára

Idővel a projekt növekedett és természetes folytatása Ansible megjelenése volt. Megjelenésének fő oka az, hogy a csapatban van szakértelem, és hogy a bash-t nem bonyolult logikára tervezték. Az Ansible is kezdett összetett logikát tartalmazni. Annak elkerülése érdekében, hogy az összetett logikából káosz alakuljon át, a szoftverfejlesztésben megvannak a kódok rendszerezésének alapelvei SZILÁRD. Például Grigorij Petrov „Miért van szüksége egy informatikusnak személyes márkára” című jelentésében felvetette a kérdést, hogy az embert úgy tervezték, hogy könnyebben tudjon működni bizonyos társadalmi entitásokkal, a szoftverfejlesztésben ezek tárgyak. Ha ezt a két ötletet egyesítjük, és tovább fejlesztjük, észre fogjuk venni, hogy hasznosítani is tudjuk SZILÁRD. hogy a jövőben könnyebb legyen fenntartani és módosítani ezt a logikát.

Az egységes felelősség elve

Minden osztály csak egy feladatot hajt végre.

Nem kell kódot keverni és monolitikus isteni spagettiszörnyeket készíteni. Az infrastruktúrának egyszerű téglákból kell állnia. Kiderült, hogy ha az Ansible játékkönyvet apró darabokra osztja, elolvassa az Ansible szerepeket, akkor könnyebben karbantartható.

A nyitott zárt elv

Nyitott/zárt elv.

Kiterjesztésre nyitott: azt jelenti, hogy egy entitás viselkedése kiterjeszthető új entitástípusok létrehozásával.
Változás előtt lezárva: Egy entitás viselkedésének kiterjesztése miatt nem szabad módosítani az entitásokat használó kódot.

Kezdetben virtuális gépeken telepítettük a tesztinfrastruktúrát, de mivel az üzembe helyezés üzleti logikája elkülönült a megvalósítástól, problémamentesen hozzáadtuk a baremetall-hoz a kiépítést.

A Liskov-helyettesítési elv

Barbara Liskov helyettesítési elve. a programban lévő objektumoknak lecserélhetőknek kell lenniük altípusaik példányaival anélkül, hogy megváltoztatnák a program helyes végrehajtását

Ha tágabban nézzük, akkor ez nem egy adott projekt sajátossága, amely ott alkalmazható SZILÁRD., általában a CFM-ről van szó, például egy másik projektben egy dobozos Java alkalmazást kell telepíteni különféle Java, alkalmazásszerverek, adatbázisok, operációs rendszer stb. Ennek a példának a felhasználásával további elveket veszek figyelembe SZILÁRD.

Esetünkben az infrastrukturális csapaton belül van egy megállapodás, hogy ha telepítettük az imbjava vagy oraclejava szerepkört, akkor van egy java bináris végrehajtható fájlunk. Erre azért van szükség Az upstream szerepek ettől a viselkedéstől függenek; Java-t várnak. Ugyanakkor ez lehetővé teszi számunkra, hogy egy Java implementációt/verziót lecseréljünk egy másikra anélkül, hogy megváltoztatnánk az alkalmazás telepítési logikáját.

A probléma itt abban rejlik, hogy ezt az Ansible-ben lehetetlen megvalósítani, aminek következtében kialakul néhány megegyezés a csapaton belül.

Az interfész szegregációs elve

Interfész-elválasztási elv: „Sok kliens-specifikus interfész jobb, mint egy általános célú interfész.

Kezdetben az alkalmazástelepítés minden változatosságát próbáltuk egy Ansible playbookba foglalni, de nehéz volt támogatni, és az a megközelítés, amikor külső interfész van megadva (a kliens a 443-as portot várja), majd az infrastruktúra összeállítható egyénből. téglák egy adott megvalósításhoz.

A függőségi inverzió elve

A függőségi inverzió elve. A magasabb szinteken lévő modulok nem függhetnek az alacsonyabb szinteken lévő moduloktól. Mindkét típusú modulnak az absztrakciótól kell függnie. Az absztrakciók nem függhetnek a részletektől. A részleteknek az absztrakcióktól kell függniük.

Itt a példa egy antimintán fog alapulni.

Az egyik ügyfélnek privát felhője volt.
Virtuális gépeket rendeltünk a felhőn belül.
A felhő természetéből adódóan azonban az alkalmazástelepítést a virtuális gép melyik hipervizorához kötötte.

Azok. A magas szintű alkalmazástelepítési logika függőségekkel áramlott a hypervisor alacsonyabb szintjeihez, és ez problémákat jelentett a logika újrafelhasználásakor. Ne csináld ezt így.

Kölcsönhatás

Az infrastruktúra mint kód nem csak a kódról szól, hanem a kód és az emberek kapcsolatáról, az infrastruktúra-fejlesztők közötti interakcióról is.

Busz faktor

Tegyük fel, hogy Vasya van a projektben. Vasya mindent tud az infrastruktúrájáról, mi lesz, ha Vasya hirtelen eltűnik? Ez egy nagyon valós helyzet, mert elütheti egy busz. Néha megtörténik. Ha ez megtörténik, és a kódról, annak felépítéséről, működéséről, a megjelenésekről és a jelszavakról szóló ismereteket nem osztják szét a csapat között, akkor számos kellemetlen helyzetbe kerülhet. E kockázatok minimalizálása és a tudás csapaton belüli elosztása érdekében különféle megközelítéseket alkalmazhat

Páros Devopsing

Nem olyan mint vicc, hogy az adminok sört ittak, jelszavakat változtattak, és a páros programozás analógja. Azok. két mérnök ül le egy számítógéphez, egy billentyűzethez, és együtt kezdik el az infrastruktúra beállítását: kiszolgálót állítanak fel, Ansible-szerepet írnak, stb. Jól hangzik, de nekünk nem jött be. De ennek a gyakorlatnak a speciális esetei működtek. Jön egy új munkatárs, a mentora együtt vállal egy valós feladatot, dolgozik, tudást ad át.

Egy másik speciális eset egy eseményhívás. Egy probléma során összegyűlik az ügyeletesek és az érintettek csoportja, kineveznek egy vezetőt, aki megosztja a képernyőjét és hangot ad a gondolatmenetnek. A többi résztvevő követi a vezető gondolatait, a konzolról kémkednek trükkök után, ellenőrzik, hogy egy sort sem hagytak-e ki a naplóban, és új dolgokat tanulnak a rendszerről. Ez a megközelítés gyakrabban működött, mint nem.

Kód felülvizsgálata

Szubjektív módon hatékonyabb volt az infrastruktúráról és annak működéséről szóló ismeretek terjesztése kódellenőrzés segítségével:

Az infrastruktúra kóddal van leírva a tárolóban.
A változások külön ágban történnek.
Az összevonási kérelem során láthatja az infrastruktúra változásainak deltáját.

A kiemelés itt az volt, hogy a bírálókat egyenként, ütemezés szerint választották ki, i.e. bizonyos fokú valószínűséggel egy új infrastruktúra-elembe fog mászni.

Kódstílus

Idővel civakodások kezdtek megjelenni a felülvizsgálatok során, mert... a bírálóknak saját stílusuk volt, és a lektorok rotációja különböző stílusokkal halmozta fel őket: 2 szóköz vagy 4, camelCase vagy snake_case. Ezt nem lehetett azonnal megvalósítani.

Az első ötlet az volt, hogy ajánlom a linter használatát, elvégre mindenki mérnök, mindenki okos. De a különböző szerkesztők, OS, nem kényelmesek
Ez egy olyan bottá fejlődött, amely minden problémás commit esetén lazára írt, és csatolta a linter kimenetet. De a legtöbb esetben fontosabb teendők is voltak, és a kód javítatlan maradt.

Green Build Master

Telik az idő, és arra a következtetésre jutottunk, hogy azokat a commitokat, amelyek nem mennek át bizonyos teszteken, nem lehet beengedni a mesterbe. Voálá! Feltaláltuk a Green Build Mastert, amelyet már régóta alkalmaznak a szoftverfejlesztésben:

A fejlesztés külön ágban folyik.
A tesztek futnak ezen a szálon.
Ha a tesztek sikertelenek, a kód nem kerül be a masterbe.

Nagyon fájdalmas volt meghozni ezt a döntést, mert... sok vitát váltott ki, de megérte, mert... A felülvizsgálatok stílusbeli különbségek nélkül kezdtek érkezni az egyesülési kérelmekbe, és idővel a problémás területek száma csökkenni kezdett.

IaC tesztelése

A stílusellenőrzésen kívül más dolgokat is használhat, például annak ellenőrzésére, hogy az infrastruktúra valóban telepíthető-e. Vagy ellenőrizze, hogy az infrastruktúra megváltoztatása nem vezet-e pénzveszteséghez. Miért lehet erre szükség? A kérdés összetett és filozófiai, jobb egy olyan történettel válaszolni, hogy valahogy a Powershell-en volt egy automatikus skálázó, amely nem ellenőrizte a peremfeltételeket => a szükségesnél több virtuális gép készült => a kliens több pénzt költött a tervezettnél. Ez nem túl kellemes, de nagyon is lehetséges lenne ezt a hibát elkapni a korábbi szakaszokban.

Felmerülhet a kérdés, miért kell a komplex infrastruktúrát még bonyolultabbá tenni? Az infrastruktúra tesztjei, csakúgy, mint a kód esetében, nem az egyszerűsítésről szólnak, hanem arról, hogy tudjuk, hogyan kell működnie az infrastruktúrának.

IaC tesztelési piramis

IaC tesztelése: Statikus elemzés

Ha egyszerre telepíti a teljes infrastruktúrát, és ellenőrzi, hogy működik-e, akkor azt tapasztalhatja, hogy ez sok időt vesz igénybe, és sok időt vesz igénybe. Ezért az alapnak olyannak kell lennie, ami gyorsan működik, sok van belőle, és nagyon sok primitív helyet takar.

Bash trükkös

Nézzünk egy triviális példát. jelölje ki az összes fájlt az aktuális könyvtárban, és másolja át egy másik helyre. Az első dolog, ami eszembe jut:

for i in * ; do 
    cp $i /some/path/$i.bak
done

Mi van, ha szóköz van a fájl nevében? Nos, okosak vagyunk, tudjuk, hogyan kell idézőjeleket használni:

for i in * ; do cp "$i" "/some/path/$i.bak" ; done

Szép munka? Nem! Mi van, ha nincs semmi a könyvtárban, pl. a golyózás nem fog működni.

find . -type f -exec mv -v {} dst/{}.bak ;

Most jól sikerült? Nem... Elfelejtette, mi lehet a fájlnévben n.

touch x
mv x  "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dir

Statikus elemző eszközök

Az előző lépés problémája akkor fogható meg, ha elfelejtettük az idézeteket, erre számos orvosság létezik a természetben Shellcheck, általában nagyon sok van belőlük, és nagy valószínűséggel találsz egy lintert a veremhez az IDE alatt.

Nyelv
Szerszám

horpadás
Shellcheck

Rubin
RuboCop

piton
pylint

ansible
Ansible Lint

IaC tesztelése: egységtesztek

Amint az előző példából láttuk, a linterek nem mindenhatóak, és nem mutathatnak rá minden problémás területre. Továbbá, a szoftverfejlesztési teszteléssel analóg módon, felidézhetjük az egységteszteket. Ami azonnal eszembe jut shunit, junit, rspec, kérdés. De mit kezdjünk az ansible-vel, a séffel, a saltstack-kel és a hozzájuk hasonlókkal?

A legelején arról beszéltünk SZILÁRD. és hogy infrastruktúránk kis téglákból álljon. Eljött az ő idejük.

Az infrastruktúra kis téglákra van osztva, például Ansible szerepekre.
Valamilyen környezetet telepítenek, legyen az docker vagy virtuális gép.
Az Ansible szerepkörünket alkalmazzuk erre a tesztkörnyezetre.
Ellenőrizzük, hogy minden úgy működött, ahogy vártuk (teszteket futtatunk).
Eldöntjük, hogy jó vagy nem.

IaC tesztelés: egységtesztelő eszközök

Kérdés, melyek a CFM tesztek? Egyszerűen futtathatja a szkriptet, vagy használhat kész megoldásokat is:

CFM
Szerszám

Ansible
Testinfra

Séf
Inspek

Séf
Szerverspecifik

sóverem
Goss

Példa a testinfra, ellenőrzi, hogy a felhasználók test1, test2 léteznek és egy csoportban vannak sshusers:

def test_default_users(host):
    users = ['test1', 'test2' ]
    for login in users:
        assert host.user(login).exists
        assert 'sshusers' in host.user(login).groups

Mit válasszunk? A kérdés összetett és kétértelmű, íme egy példa a githubon 2018-2019 közötti projektekben bekövetkezett változásokra:

IaC tesztelési keretrendszerek

Felmerül a kérdés: hogyan lehet mindezt összerakni és elindítani? Tud vedd és csináld magad ha van elegendő számú mérnök. Vagy vehet kész megoldásokat, bár nem sok van belőlük:

CFM
Szerszám

Ansible
Molekula

Séf
Tesztkonyha

Terraform
Terratest

Példa a githubon 2018-2019 közötti projektek változásaira:

Molekula vs. Tesztkonyha

Kezdetben mi kipróbálta a testkitchen használatát:

Párhuzamosan hozzon létre egy virtuális gépet.
Alkalmazzon Ansible szerepeket.
Futtassa le az ellenőrzést.

25-35 szerepnél 40-70 percig működött, ami hosszú volt.

A következő lépés a jenkins/docker/ansible/molecule rendszerre való átállás volt. Idiológiailag minden ugyanaz

Lint játékkönyvek.
Sorolja fel a szerepeket.
Indítsa el a tartályt
Alkalmazzon Ansible szerepeket.
Futtassa a tesztinfra.
Ellenőrizze az idempotenciát.

A 40 szerepre való szöszölés és egy tucatnyi teszt 15 percig tartott.

A választás számos tényezőtől függ, például a használt veremtől, a csapat szakértelmétől stb. itt mindenki maga dönti el, hogyan zárja le az egységtesztelési kérdést

IaC tesztelés: integrációs tesztek

Az infrastruktúra tesztelési piramis következő lépése az integrációs tesztek lesz. Hasonlóak az egységtesztekhez:

Az infrastruktúra kis téglákra van osztva, például Ansible szerepekre.
Valamilyen környezetet telepítenek, legyen az docker vagy virtuális gép.
Erre a tesztkörnyezetre vonatkozik sok Lehetséges szerepek.
Ellenőrizzük, hogy minden úgy működött, ahogy vártuk (teszteket futtatunk).
Eldöntjük, hogy jó vagy nem.

Nagyjából nem a rendszer egyes elemeinek teljesítményét ellenőrizzük, mint az egységteszteknél, hanem a szerver teljes konfigurációját.

IaC tesztelés: végponttól végéig tesztek

A piramis tetején End to End tesztek fogadnak bennünket. Azok. Nem ellenőrizzük külön szerver, külön szkript vagy infrastruktúra külön tégla teljesítményét. Ellenőrizzük, hogy sok szerver csatlakozik-e egymáshoz, infrastruktúránk úgy működik, ahogy azt elvárjuk. Sajnos soha nem láttam kész dobozos megoldásokat, valószínűleg azért, mert... Az infrastruktúra gyakran egyedi, és nehéz sablont készíteni és keretet létrehozni a teszteléshez. Ennek eredményeként mindenki megalkotja a saját megoldásait. Van igény, de nincs válasz. Ezért elmondom, mi van ahhoz, hogy másokat hangos gondolatokra késztessem, vagy beledörzsöljem az orrom, hogy mindent régen előttünk találtak ki.

Gazdag történelemmel rendelkező projekt. Nagy szervezetekben használják, és valószínűleg mindegyikőtök útja közvetetten kereszteződött vele. Az alkalmazás számos adatbázist, integrációt stb. támogat. Az infrastruktúra kinézetének ismerete sok docker-compose fájlt tartalmaz, és a Jenkins tudja, hogy melyik környezetben melyik tesztet kell futtatni.

Ez a séma elég sokáig működött, egészen a keretek között kutatás ezt nem próbáltuk átvinni az Openshiftbe. A konténerek ugyanazok maradnak, de az indítási környezet megváltozott (hello D.R.Y. ismét).

A kutatási ötlet tovább ment, és az openshiftben találtak egy olyan dolgot, mint az APB (Ansible Playbook Bundle), amely lehetővé teszi az infrastruktúra telepítésének ismereteit egy konténerbe csomagolni. Azok. van egy megismételhető, tesztelhető tudáspont az infrastruktúra telepítésével kapcsolatban.

Mindez egészen addig jól hangzott, amíg egy heterogén infrastruktúrába nem ütköztünk: Windowsra volt szükség a tesztekhez. Ennek eredményeként a jenkinsben van a tudás arról, hogy mit, hol, hogyan kell telepíteni és tesztelni.

Következtetés

Az infrastruktúra olyan, amilyen a kód

Kód az adattárban.
Emberi kapcsolat.
Infrastruktúra tesztelés.

linkek

Forrás: will.com

Amit 200 000 infrastruktúra-kódsor teszteléséből tanultam