Pristup IaC (Infrastructure as Code) ne sastoji se samo od koda koji je pohranjen u repozitoriju, već i od ljudi i procesa koji okružuju taj kod. Je li moguće ponovno koristiti pristupe od razvoja softvera do upravljanja i opisa infrastrukture? Bilo bi dobro imati ovu ideju na umu dok čitate članak.

Ovo je moj transkript izvedbe na DevopsConf 2019-05-28.

Slajdovi i video zapisi

Infrastruktura kao bash povijest

Pretpostavimo da dođete na novi projekt, a oni vam kažu: “imamo Infrastruktura kao kod". U stvarnosti ispada Infrastruktura kao bash povijest ili primjerice Dokumentacija kao bash povijest. Ovo je vrlo stvarna situacija, na primjer, sličan slučaj opisao je Denis Lysenko u govoru Kako zamijeniti cijelu infrastrukturu i početi mirno spavati, rekao je kako su dobili koherentnu infrastrukturu za projekt iz bash povijesti.

Uz nešto želje, možemo to reći Infrastruktura kao bash povijest ovo je kao kod:

ponovljivost: Možete uzeti bash povijest, pokrenuti naredbe odatle, i možete, usput, dobiti radnu konfiguraciju kao izlaz.
verziranje: znate tko je ušao i što su radili, opet, nije činjenica da će vas to dovesti do radne konfiguracije izlaza.
priča: priča o tome tko je što učinio. samo što ga nećete moći koristiti ako izgubite poslužitelj.

Što učiniti?

Infrastruktura kao kod

Čak i tako čudan slučaj kao Infrastruktura kao bash povijest možeš ga povući za uši Infrastruktura kao kod, ali kada želimo napraviti nešto kompliciranije od dobrog starog LAMP servera, doći ćemo do zaključka da taj kod treba nekako modificirati, promijeniti, poboljšati. Zatim bismo željeli razmotriti paralele između Infrastruktura kao kod i razvoj softvera.

D.R.Y.

Na projektu razvoja sustava za pohranu postojao je podzadatak povremeno konfigurirati SDS: objavljujemo novo izdanje - potrebno ga je pokrenuti za daljnje testiranje. Zadatak je krajnje jednostavan:

prijavite se ovdje putem ssh-a i izvršite naredbu.
kopirajte datoteku tamo.
ispravite konfiguraciju ovdje.
tamo pokrenite uslugu
...
DOBIT!

Za opisanu logiku bash je više nego dovoljan, pogotovo u ranim fazama projekta, kada tek počinje. Ovaj nije loše da koristiš bash, ali s vremenom postoje zahtjevi za implementaciju nečeg sličnog, ali malo drugačijeg. Prvo što pada na pamet je copy-paste. A sada već imamo dvije vrlo slične skripte koje rade gotovo istu stvar. S vremenom je broj skripti rastao, a mi smo se suočili s činjenicom da postoji određena poslovna logika za implementaciju instalacije koju je potrebno sinkronizirati između različitih skripti, to je prilično komplicirano.

Ispostavilo se da postoji takva praksa kao D.R.Y. (Nemojte se ponavljati). Ideja je ponovno upotrijebiti postojeći kod. Zvuči jednostavno, ali nismo odmah došli do ovoga. U našem slučaju, to je bila banalna ideja: odvojiti konfiguracije od skripti. Oni. poslovna logika kako se instalacija postavlja odvojeno, konfiguracije odvojeno.

S.O.L.I.D. za CFM

S vremenom je projekt rastao i prirodni nastavak bila je pojava Ansiblea. Glavni razlog za njegovo pojavljivanje je to što postoji stručnost u timu i što bash nije dizajniran za složenu logiku. Ansible je također počeo sadržavati složenu logiku. Kako bi se spriječilo da se složena logika pretvori u kaos, postoje principi za organiziranje koda u razvoju softvera S.O.L.I.D. Također, na primjer, Grigorij Petrov u izvješću “Zašto IT stručnjaku treba osobni brend” postavio je pitanje da je osoba dizajnirana na takav način da joj je lakše raditi s nekim društvenim entitetima, u razvoju softvera ti su objekti. Spojimo li ove dvije ideje i nastavimo ih razvijati, primijetit ćemo da ih također možemo koristiti S.O.L.I.D. kako bismo olakšali održavanje i modificiranje ove logike u budućnosti.

Načelo jedinstvene odgovornosti

Svaki razred izvodi samo jedan zadatak.

Nema potrebe za miješanjem koda i stvaranjem monolitnih božanskih špageti čudovišta. Infrastruktura bi se trebala sastojati od jednostavnih cigli. Ispostavilo se da ako Ansible playbook podijelite na male dijelove, pročitate Ansible uloge, tada ih je lakše održavati.

Otvoreno zatvoreno načelo

Princip otvoreno/zatvoreno.

Otvoreno za proširenje: znači da se ponašanje entiteta može proširiti stvaranjem novih tipova entiteta.
Zatvoreno za promjene: Kao rezultat proširenja ponašanja entiteta, ne bi se trebale unositi promjene u kod koji koristi te entitete.

U početku smo implementirali testnu infrastrukturu na virtualnim strojevima, ali zbog činjenice da je poslovna logika implementacije bila odvojena od implementacije, dodali smo roll out na baremetall bez ikakvih problema.

Načelo Liskovljeve supstitucije

Princip supstitucije Barbare Liskov. objekti u programu moraju biti zamjenjivi instancama svojih podtipova bez promjene ispravnog izvođenja programa

Ako gledate šire, to nije značajka nekog konkretnog projekta koja bi se tu mogla primijeniti S.O.L.I.D., općenito se radi o CFM-u, na primjer, na drugom projektu potrebno je implementirati Java aplikaciju u kutiji povrh raznih Java, aplikacijskih poslužitelja, baza podataka, OS-a itd. Koristeći ovaj primjer, razmotrit ću daljnja načela S.O.L.I.D.

U našem slučaju, postoji dogovor unutar infrastrukturnog tima da ako smo instalirali ulogu imbjava ili oraclejava, tada imamo Java binarnu izvršnu datoteku. Ovo je potrebno jer Upstream uloge ovise o ovom ponašanju; one očekuju Javu. U isto vrijeme, ovo nam omogućuje zamjenu jedne implementacije/verzije Jave drugom bez promjene logike postavljanja aplikacije.

Problem ovdje leži u činjenici da je to nemoguće implementirati u Ansibleu, zbog čega se pojavljuju neki dogovori unutar tima.

Načelo razdvajanja sučelja

Načelo razdvajanja sučelja: „Mnoga sučelja specifična za klijente bolja su od jednog sučelja opće namjene.

U početku smo pokušali staviti sve varijabilnosti implementacije aplikacija u jedan Ansible playbook, ali to je bilo teško podržati, a pristup kada imamo navedeno vanjsko sučelje (klijent očekuje priključak 443), tada se infrastruktura može sastaviti od pojedinačnih opeke za određenu implementaciju.

Načelo inverzije ovisnosti

Načelo inverzije ovisnosti. Moduli na višim razinama ne bi trebali ovisiti o modulima na nižim razinama. Obje vrste modula moraju ovisiti o apstrakcijama. Apstrakcije ne bi trebale ovisiti o detaljima. Pojedinosti moraju ovisiti o apstrakcijama.

Ovdje će se primjer temeljiti na antiuzorku.

Jedan od kupaca imao je privatni oblak.
Naručili smo virtualne strojeve unutar oblaka.
Ali zbog prirode oblaka, implementacija aplikacije bila je povezana s hipervizorom na kojem je VM.

Oni. Logika postavljanja aplikacije na visokoj razini tekla je s ovisnostima na niže razine hipervizora, a to je značilo probleme prilikom ponovnog korištenja ove logike. Nemojte to raditi na ovaj način.

Interakcija

Infrastruktura kao kod ne odnosi se samo na kod, već i na odnos između koda i ljudi, na interakciju između razvijača infrastrukture.

Faktor autobusa

Pretpostavimo da imate Vasju na svom projektu. Vasya zna sve o vašoj infrastrukturi, što će se dogoditi ako Vasya iznenada nestane? Ovo je vrlo realna situacija, jer bi ga mogao udariti autobus. Ponekad se dogodi. Ako se to dogodi, a znanje o kodu, njegovoj strukturi, načinu rada, izgledima i lozinkama nije raspodijeljeno među timom, tada se možete susresti s nizom neugodnih situacija. Kako biste minimizirali ove rizike i distribuirali znanje unutar tima, možete koristiti različite pristupe

Par Devopsing

Nije kao kao od šale, da su admini pili pivo, mijenjali lozinke i analogno programiranje u paru. Oni. dva inženjera sjednu za jedno računalo, jednu tipkovnicu i počnu zajedno postavljati vašu infrastrukturu: postavljanje poslužitelja, pisanje Ansible uloge, itd. Lijepo zvuči, ali nama nije išlo. Ali posebni slučajevi ove prakse su djelovali. Dolazi novi zaposlenik, njegov mentor zajedno s njim preuzima pravi zadatak, radi i prenosi znanje.

Još jedan poseban slučaj je incidentni poziv. Tijekom problema okuplja se grupa dežurnih i uključenih, imenuje se jedan vođa, koji dijeli svoj ekran i izgovara tijek misli. Ostali sudionici prate voditeljeve misli, špijuniraju trikove s konzole, provjeravaju da nisu propustili redak u dnevniku i uče nove stvari o sustavu. Ovaj je pristup češće funkcionirao nego ne.

Pregled koda

Subjektivno, bilo je učinkovitije širiti znanje o infrastrukturi i načinu na koji ona funkcionira pomoću pregleda koda:

Infrastruktura je opisana kodom u repozitoriju.
Promjene se događaju u zasebnoj grani.
Tijekom zahtjeva za spajanje možete vidjeti deltu promjena u infrastrukturi.

Ovdje je vrhunac bio da su recenzenti birani jedan po jedan, prema rasporedu, tj. s određenim stupnjem vjerojatnosti ćete se popeti na novi dio infrastrukture.

stil koda

S vremenom su se počele javljati trzavice tijekom recenzija jer... recenzenti su imali vlastiti stil i rotacija recenzenata slagala ih je s različitim stilovima: 2 razmaka ili 4, camelCase ili snake_case. To nije bilo moguće odmah provesti.

Prva ideja je bila preporučiti korištenje lintera, na kraju krajeva, svi su inženjeri, svi su pametni. Ali različiti urednici, OS, nisu prikladni
Ovo je evoluiralo u bota koji je pisao u slack za svaki problematični commit i priložio ispis lintera. Ali u većini slučajeva bilo je važnijih stvari za obaviti, a šifra je ostala nepopravljena.

Majstor zelene gradnje

Vrijeme prolazi, a mi smo došli do zaključka da komitovi koji ne prođu određene testove ne mogu biti dopušteni u master. Voila! Izumili smo Green Build Master, koji se već dugo koristi u razvoju softvera:

Razvoj je u tijeku u zasebnoj grani.
Testovi se izvode na ovoj temi.
Ako testovi ne uspiju, kôd neće ući u glavni.

Donošenje ove odluke bilo je vrlo bolno, jer... izazvalo je mnogo kontroverzi, ali vrijedilo je jer... Recenzije su počele primati zahtjeve za spajanje bez razlike u stilu, a s vremenom se broj problematičnih područja počeo smanjivati.

IaC testiranje

Osim provjere stila, možete koristiti i druge stvari, na primjer, da provjerite može li se vaša infrastruktura doista implementirati. Ili provjerite neće li promjene u infrastrukturi dovesti do gubitka novca. Zašto bi ovo moglo biti potrebno? Pitanje je složeno i filozofsko, bolje je odgovoriti pričom da je nekako postojao auto-scaler na Powershellu koji nije provjeravao granične uvjete => stvoreno je više VM-ova nego što je potrebno => klijent je potrošio više novca nego što je planirano. Ovo nije baš ugodno, ali bilo bi sasvim moguće uhvatiti ovu pogrešku u ranijim fazama.

Netko bi se mogao zapitati zašto složenu infrastrukturu činiti još složenijom? Testovi za infrastrukturu, baš kao i kod, ne odnose se na pojednostavljenje, već na znanje kako bi vaša infrastruktura trebala funkcionirati.

IaC testna piramida

IaC testiranje: statička analiza

Ako implementirate cijelu infrastrukturu odjednom i provjerite radi li, možda ćete uvidjeti da to oduzima puno vremena i zahtijeva puno vremena. Dakle, osnova mora biti nešto što brzo radi, ima ga puno, i pokriva puno primitivnih mjesta.

Bash je lukav

Pogledajmo trivijalan primjer. odaberite sve datoteke u trenutnom direktoriju i kopirajte ih na drugo mjesto. Prvo što mi pada na pamet:

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

Što ako postoji razmak u nazivu datoteke? Pa dobro, pametni smo, znamo koristiti navodnike:

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

Dobro napravljeno? Ne! Što ako u imeniku nema ništa, t.j. globiranje neće raditi.

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

Dobro obavljeno sada? Ne... Zaboravio sam što može biti u nazivu datoteke n.

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

Alati za statičku analizu

Problem iz prethodnog koraka mogao bi se uhvatiti kada zaboravimo navodnike, za to postoje mnogi lijekovi u prirodi Shellcheck, općenito ih ima puno i najvjerojatnije možete pronaći linter za svoj stog pod svojim IDE-om.

Jezik
Oruđe

udariti
Shellcheck

Rubin
RuboCop

piton
Pilint

ansible
Ansible lint

IaC testiranje: Jedinični testovi

Kao što smo vidjeli iz prethodnog primjera, linteri nisu svemogući i ne mogu ukazati na sva problematična područja. Nadalje, po analogiji s testiranjem u razvoju softvera, možemo se prisjetiti jediničnih testova. Ono što vam odmah pada na pamet je šuniti, junit, rspec, pytest. Ali što učiniti s ansibleom, chefom, saltstackom i njima sličnim?

Na samom početku razgovarali smo o S.O.L.I.D. i da bi se naša infrastruktura trebala sastojati od malih kockica. Došlo je njihovo vrijeme.

Infrastruktura je podijeljena na male kocke, na primjer, Ansible uloge.
Neka vrsta okruženja je postavljena, bilo da je to docker ili VM.
Primjenjujemo našu Ansible ulogu na ovo testno okruženje.
Provjeravamo je li sve radilo kako smo očekivali (provjeravamo da li je sve radilo kako smo očekivali) (radimo testove).
Mi odlučujemo ok ili ne ok.

IaC testiranje: Alati za jedinično testiranje

Pitanje, koji su testovi za CFM? Možete jednostavno pokrenuti skriptu ili možete koristiti gotova rješenja za ovo:

CFM
Oruđe

Ansible
Testinfra

Kuhar
inspekcija

Kuhar
Specifikacija poslužitelja

hrpa soli
Goss

Primjer za testinfra, provjera korisnika test1, test2 postoje i nalaze se u grupi 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

Što izabrati? Pitanje je složeno i dvosmisleno, evo primjera promjena u projektima na githubu za 2018-2019:

IaC okviri za testiranje

Postavlja se pitanje: kako to sve spojiti i pokrenuti? Limenka uzmi i napravi sam ako postoji dovoljan broj inženjera. Ili možete uzeti gotova rješenja, iako ih nema mnogo:

CFM
Oruđe

Ansible
Molekula

Kuhar
Testna kuhinja

Terraform
Terratest

Primjer promjena u projektima na githubu za 2018-2019:

Molekula vs. Probna kuhinja

U početku mi pokušao koristiti testkitchen:

Paralelno stvorite VM.
Primijenite Ansible uloge.
Pokreni inspekciju.

Za 25-35 uloga radilo se 40-70 minuta, što je bilo dugo.

Sljedeći korak bio je prijelaz na jenkins/docker/ansible/molecule. Idiološki je sve isto

Lint playbooks.
Poređajte uloge.
Lansirni spremnik
Primijenite Ansible uloge.
Pokrenite testinfra.
Provjerite idempotenciju.

Lingiranje 40 uloga i testovi za desetak počeli su trajati oko 15 minuta.

Što odabrati ovisi o mnogim čimbenicima, kao što su korišteni stack, stručnost u timu itd. ovdje svatko odlučuje za sebe kako zatvoriti pitanje o testiranju jedinice

IaC testiranje: integracijski testovi

Sljedeći korak u piramidi testiranja infrastrukture bit će integracijski testovi. Slični su jediničnim testovima:

Infrastruktura je podijeljena na male kocke, na primjer Ansible role.
Neka vrsta okruženja je postavljena, bilo da je to docker ili VM.
Za ovo testno okruženje primijeniti set od Anzibilne uloge.
Provjeravamo je li sve radilo kako smo očekivali (provjeravamo da li je sve radilo kako smo očekivali) (radimo testove).
Mi odlučujemo ok ili ne ok.

Grubo rečeno, ne provjeravamo performanse pojedinog elementa sustava kao u jediničnim testovima, provjeravamo kako je poslužitelj konfiguriran kao cjelina.

IaC testiranje: End to End testovi

Na vrhu piramide dočekuju nas End to End testovi. Oni. Ne provjeravamo performanse zasebnog poslužitelja, zasebne skripte ili zasebne cigle naše infrastrukture. Provjeravamo da su mnogi poslužitelji povezani zajedno, naša infrastruktura radi kako očekujemo. Nažalost, nikad nisam vidio gotova rješenja u kutiji, vjerojatno zato što... Infrastruktura je često jedinstvena i teška za predložak i stvaranje okvira za testiranje. Kao rezultat toga, svatko stvara vlastita rješenja. Postoji zahtjev, ali nema odgovora. Stoga ću vam reći što postoji kako bih druge natjerao na zdrave misli ili natrljao nos činjenici da je sve izmišljeno davno prije nas.

Projekt s bogatom poviješću. Koristi se u velikim organizacijama i vjerojatno se svatko od vas neizravno susreo s njim. Aplikacija podržava mnoge baze podataka, integracije itd. Znati kako bi infrastruktura mogla izgledati je puno docker-compose datoteka, a znati koje testove pokrenuti u kojem okruženju je Jenkins.

Ova je shema funkcionirala dosta dugo, dok nije ušla u okvir istraživanje nismo pokušali ovo prenijeti na Openshift. Spremnici su ostali isti, ali se promijenilo okruženje za pokretanje (pozdrav D.R.Y. opet).

Istraživačka ideja otišla je dalje, au openshiftu su pronašli nešto poput APB (Ansible Playbook Bundle), koji vam omogućuje da spakirate znanje o tome kako implementirati infrastrukturu u spremnik. Oni. postoji ponovljiva, provjerljiva točka znanja o tome kako postaviti infrastrukturu.

Sve je to zvučalo dobro dok nismo naišli na heterogenu infrastrukturu: trebali smo Windows za testove. Kao rezultat toga, znanje o tome što, gdje, kako implementirati i testirati nalazi se u jenkinsu.

Zaključak

Infrastruktura kao kodeks

Kod u repozitoriju.
Ljudska interakcija.
Ispitivanje infrastrukture.

linkovi

Izvor: www.habr.com

Što sam naučio testirajući 200 linija infrastrukturnog koda