Prístup IaC (Infrastructure as Code) pozostáva nielen z kódu, ktorý je uložený v úložisku, ale aj z ľudí a procesov, ktoré tento kód obklopujú. Je možné znovu použiť prístupy od vývoja softvéru po správu a popis infraštruktúry? Bolo by dobré mať túto myšlienku na pamäti pri čítaní článku.

Toto je môj prepis výkony na DevopsConf 2019.

Snímky a videá

Angielski verzia
Ruská verzia
Suchá prevádzka 2019-04-24 SpbLUG
Video (RU) z konferencie DevopsConf 2019
Video(RU) z DINS DevOps EVENING 2019-06-20
šmykľavky

Infraštruktúra ako bash história

Predpokladajme, že prídete do nového projektu a oni vám povedia: „Máme Infraštruktúra ako kód". V skutočnosti sa ukazuje Infraštruktúra ako bash história alebo napr Dokumentácia ako história bash. Toto je veľmi reálna situácia, napríklad podobný prípad opísal v prejave Denis Lysenko Ako vymeniť celú infraštruktúru a začať pokojne spať, povedal, ako získali koherentnú infraštruktúru pre projekt z bash histórie.

S určitou túžbou to môžeme povedať Infraštruktúra ako bash história toto je ako kód:

reprodukovateľnosť: Môžete si vziať históriu bash, spustiť príkazy odtiaľ a mimochodom môžete získať fungujúcu konfiguráciu ako výstup.
verziovanie: viete, kto prišiel a čo urobil, opäť nie je pravda, že vás to privedie k funkčnej konfigurácii na výstupe.
história: príbeh o tom, kto čo urobil. iba ak stratíte server, nebudete ho môcť použiť.

Čo robiť?

Infraštruktúra ako kód

Aj taký zvláštny prípad ako Infraštruktúra ako bash história môžete ho ťahať za uši Infraštruktúra ako kód, ale keď chceme robiť niečo zložitejšie ako starý dobrý LAMP server, prídeme na to, že tento kód treba nejako upraviť, zmeniť, vylepšiť. Ďalej by sme chceli zvážiť paralely medzi nimi Infraštruktúra ako kód a vývoj softvéru.

D.R.Y.

Na projekte vývoja úložného systému bola čiastková úloha pravidelne konfigurovať SDS: vydávame nové vydanie – je potrebné ho spustiť na ďalšie testovanie. Úloha je mimoriadne jednoduchá:

prihláste sa tu cez ssh a vykonajte príkaz.
skopírujte súbor tam.
opravte konfiguráciu tu.
spustiť službu tam
...
ZISK!

Pre popísanú logiku bash viac než postačuje, najmä v raných fázach projektu, keď sa ešte len rozbieha. Toto nie je zlé, že používaš bash, no postupom času sa objavujú požiadavky na nasadenie niečoho podobného, no trochu iného. Prvá vec, ktorá vás napadne, je copy-paste. A teraz už máme dva veľmi podobné skripty, ktoré robia takmer to isté. Postupom času rástol počet skriptov a stretávali sme sa s tým, že existuje určitá obchodná logika nasadzovania inštalácie, ktorú je potrebné synchronizovať medzi rôznymi skriptami, je to dosť komplikované.

Ukazuje sa, že existuje taká prax ako D.R.Y. (Neopakujte sa). Myšlienkou je opätovné použitie existujúceho kódu. Znie to jednoducho, ale neprišli sme na to hneď. V našom prípade to bol banálny nápad: oddeliť konfigurácie od skriptov. Tie. obchodná logika toho, ako je inštalácia nasadená samostatne, konfigurácia samostatne.

S.O.L.I.D. pre CFM

Postupom času sa projekt rozrastal a prirodzené pokračovanie bol vznik Ansible. Hlavným dôvodom jeho vzhľadu je, že v tíme sú odborné znalosti a že bash nie je navrhnutý pre komplexnú logiku. Ansible tiež začal obsahovať komplexnú logiku. Aby sa zložitá logika nepremenila na chaos, existujú zásady organizácie kódu pri vývoji softvéru S.O.L.I.D. Napríklad Grigory Petrov v správe „Prečo potrebuje IT špecialista osobnú značku“ nastolil otázku, že človek je navrhnutý tak, aby sa mu ľahšie spolupracovalo s niektorými sociálnymi subjektmi, pri vývoji softvéru tieto sú predmety. Ak tieto dva nápady spojíme a budeme ich ďalej rozvíjať, všimneme si, že môžeme aj použiť S.O.L.I.D. aby bolo možné túto logiku v budúcnosti ľahšie udržiavať a upravovať.

Princíp jednotnej zodpovednosti

Každá trieda plní iba jednu úlohu.

Nie je potrebné miešať kód a vytvárať monolitické božské špagetové príšery. Infraštruktúra by mala pozostávať z jednoduchých tehál. Ukazuje sa, že ak rozdelíte príručku Ansible na malé kúsky, prečítate si roly Ansible, potom sa budú ľahšie udržiavať.

Princíp otvoreného uzavretého

Princíp otvorený/zatvorený.

Otvorené pre rozšírenie: znamená, že správanie entity možno rozšíriť vytvorením nových typov entít.
Uzavreté pre zmeny: V dôsledku rozšírenia správania entity by sa nemali robiť žiadne zmeny v kóde, ktorý tieto entity používa.

Spočiatku sme testovaciu infraštruktúru nasadzovali na virtuálnych strojoch, ale vzhľadom na to, že obchodná logika nasadenia bola oddelená od implementácie, bez problémov sme pridali roll-out na baremetall.

Liskovský princíp substitúcie

Substitučný princíp Barbary Liskovovej. objekty v programe musia byť nahraditeľné inštanciami ich podtypov bez zmeny správneho vykonávania programu

Ak sa na to pozriete širšie, nie je to vlastnosť žiadneho konkrétneho projektu, ktorý by sa tam dal uplatniť S.O.L.I.D., vo všeobecnosti ide o CFM, napríklad na inom projekte je potrebné nasadiť krabicovú Java aplikáciu nad rôzne Javy, aplikačné servery, databázy, OS atď. Na tomto príklade zvážim ďalšie princípy S.O.L.I.D.

V našom prípade existuje dohoda v rámci tímu infraštruktúry, že ak máme nainštalovanú rolu imbjava alebo oraclejava, máme spustiteľný binárny súbor java. Je to potrebné, pretože Upstream role závisia od tohto správania; očakávajú java. Zároveň nám to umožňuje nahradiť jednu implementáciu/verziu java inou bez zmeny logiky nasadenia aplikácie.

Problém je v tom, že v Ansible to nie je možné implementovať, v dôsledku čoho sa v tíme objavujú nejaké dohody.

Princíp segregácie rozhrania

Princíp oddelenia rozhrania: „Mnohé rozhrania špecifické pre klienta sú lepších ako jedno univerzálne rozhranie.

Pôvodne sme sa snažili dať všetku variabilitu nasadzovania aplikácií do jedného Ansible playbooku, ale bolo to náročné na podporu a prístup, keď máme špecifikované externé rozhranie (klient očakáva port 443), tak sa dá infraštruktúra zostaviť z jednotlivých tehly na konkrétnu realizáciu.

Princíp inverzie závislosti

Princíp inverzie závislosti. Moduly na vyšších úrovniach by nemali závisieť od modulov na nižších úrovniach. Oba typy modulov musia závisieť od abstrakcií. Abstrakcie by nemali závisieť od detailov. Podrobnosti musia závisieť od abstrakcií.

Tu bude príklad založený na antivzore.

Jeden zo zákazníkov mal súkromný cloud.
Virtuálne stroje sme objednali v cloude.
Ale vzhľadom na povahu cloudu bolo nasadenie aplikácií viazané na to, na ktorom hypervízore bol VM zapnutý.

Tie. Logika nasadzovania aplikácií na vysokej úrovni plynula so závislosťami na nižších úrovniach hypervízora, čo znamenalo problémy pri opätovnom použití tejto logiky. Nerobte to týmto spôsobom.

Interakcie

Infraštruktúra ako kód nie je len o kóde, ale aj o vzťahu medzi kódom a ľuďmi, o interakciách medzi vývojármi infraštruktúry.

Autobusový faktor

Predpokladajme, že máte vo svojom projekte Vasyu. Vasya vie všetko o vašej infraštruktúre, čo sa stane, ak Vasya náhle zmizne? Toto je veľmi reálna situácia, pretože by ho mohol zraziť autobus. Niekedy sa to stane. Ak sa to stane a znalosti o kóde, jeho štruktúre, fungovaní, vzhľade a heslách nie sú medzi tímom rozdelené, môžete sa stretnúť s množstvom nepríjemných situácií. Na minimalizáciu týchto rizík a distribúciu vedomostí v rámci tímu môžete použiť rôzne prístupy

Rozvíjanie párov

To nie je ako ako vtip, že admini pili pivo, menili si heslá a obdobu párového programovania. Tie. dvaja inžinieri si sadnú k jednému počítaču, jednej klávesnici a začnú spolu nastavovať vašu infraštruktúru: nastavenie servera, písanie role Ansible atď. Znie to pekne, ale u nás to nefungovalo. Ale špeciálne prípady tejto praxe fungovali. Prichádza nový zamestnanec, jeho mentor s ním preberá skutočnú úlohu, pracuje a odovzdáva vedomosti.

Ďalším špeciálnym prípadom je incidentové volanie. Počas problému sa zhromaždí skupina tých, ktorí sú v službe, a tých, ktorých sa to týka, je menovaný jeden vodca, ktorý zdieľa svoju obrazovku a vyjadruje tok myšlienok. Ostatní účastníci sledujú myšlienky vodcu, špehujú triky z konzoly, kontrolujú, či nevynechali riadok v denníku, a učia sa nové veci o systéme. Tento prístup fungoval častejšie ako nie.

Kontrola kódu

Subjektívne bolo efektívnejšie šíriť poznatky o infraštruktúre a jej fungovaní pomocou kontroly kódu:

Infraštruktúra je opísaná kódom v úložisku.
Zmeny sa vyskytujú v samostatnej vetve.
Počas žiadosti o zlúčenie môžete vidieť rozdiel zmien v infraštruktúre.

Vrcholom tu bolo, že recenzenti boli vyberaní jeden po druhom, podľa harmonogramu, t.j. s istou mierou pravdepodobnosti vleziete do novej časti infraštruktúry.

Štýl kódu

Postupom času sa pri recenziách začali objavovať škriepky, pretože... recenzenti mali svoj vlastný štýl a striedanie recenzentov ich spájalo s rôznymi štýlmi: 2 medzery alebo 4, camelCase alebo snake_case. Nebolo možné to hneď zrealizovať.

Prvou myšlienkou bolo odporučiť používanie linteru, veď každý je inžinier, každý je šikovný. Ale rôzne editory, OS, nie sú pohodlné
To sa vyvinulo do bota, ktorý písal na slack pre každé problematické odovzdanie a pripojil výstup linter. Vo väčšine prípadov však bolo treba urobiť dôležitejšie veci a kód zostal neopravený.

Majster zelenej stavby

Čas plynie a my sme dospeli k záveru, že záväzky, ktoré neprejdú určitými testami, nemôžu byť vpustené do mastera. Voila! Vymysleli sme Green Build Master, ktorý sa už dlho praktizuje vo vývoji softvéru:

Vývoj prebieha v samostatnom odvetví.
Na tomto vlákne prebiehajú testy.
Ak testy zlyhajú, kód sa nedostane do hlavného servera.

Toto rozhodnutie bolo veľmi bolestivé, pretože... vyvolalo veľa kontroverzií, ale stálo to za to, pretože... Recenzie začali dostávať žiadosti o zlúčenie bez rozdielov v štýle a postupom času sa počet problémových oblastí začal znižovať.

Testovanie IaC

Okrem kontroly štýlu môžete použiť aj iné veci, napríklad skontrolovať, či sa vaša infraštruktúra môže skutočne nasadiť. Alebo skontrolujte, či zmeny v infraštruktúre nepovedú k strate peňazí. Prečo by to mohlo byť potrebné? Otázka je zložitá a filozofická, je lepšie odpovedať príbehom, že na Powershell nejako existoval automatický škálovač, ktorý nekontroloval okrajové podmienky => bolo vytvorených viac VM, ako bolo potrebné => klient minul viac peňazí, ako plánoval. Nie je to veľmi príjemné, ale bolo by celkom možné zachytiť túto chybu v skorších štádiách.

Niekto by sa mohol opýtať, prečo robiť komplexnú infraštruktúru ešte zložitejšou? Testy infraštruktúry, rovnako ako kód, nie sú o zjednodušení, ale o tom, ako by mala vaša infraštruktúra fungovať.

IaC testovacia pyramída

Testovanie IaC: Statická analýza

Ak nasadíte celú infraštruktúru naraz a skontrolujete, či funguje, možno zistíte, že to zaberie veľa času a vyžaduje veľa času. Základom preto musí byť niečo, čo funguje rýchlo, je toho veľa a pokryje to veľa primitívnych miest.

Bash je zložitý

Pozrime sa na triviálny príklad. vyberte všetky súbory v aktuálnom adresári a skopírujte ich na iné miesto. Prvá vec, ktorá vás napadne:

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

Čo ak je v názve súboru medzera? Dobre, sme šikovní, vieme používať úvodzovky:

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

Výborne? Nie! Čo ak v adresári nič nie je, t.j. globovanie nebude fungovať.

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

Dobre teraz? Nie... Zabudol som, čo môže byť v názve súboru n.

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

Nástroje statickej analýzy

Problém z predchádzajúceho kroku by sa mohol zachytiť, keď sme zabudli úvodzovky, na to existuje v prírode veľa liekov Shellcheck, vo všeobecnosti ich je veľa a s najväčšou pravdepodobnosťou nájdete linter pre svoj zásobník pod IDE.

Jazyk
Nástroj

tresnúť
Shellcheck

rubín
RuboCop

krajta
pylint

ansible
Ansible Lint

Testovanie IaC: Testy jednotiek

Ako sme videli z predchádzajúceho príkladu, linters nie sú všemocné a nedokážu poukázať na všetky problémové oblasti. Ďalej, analogicky s testovaním vo vývoji softvéru, môžeme pripomenúť unit testy. Čo okamžite príde na myseľ, je šunit, junit, rspec, pytest. Ale čo robiť s ansible, šéfkuchár, saltstack a im podobné?

Na samom začiatku sme hovorili o S.O.L.I.D. a že naša infraštruktúra by mala pozostávať z malých tehál. Prišiel ich čas.

Infraštruktúra je rozdelená do malých kociek, napríklad Ansible role.
Je nasadený nejaký druh prostredia, či už je to docker alebo VM.
Na toto testovacie prostredie aplikujeme našu rolu Ansible.
Skontrolujeme, či všetko fungovalo tak, ako sme očakávali (spustíme testy).
Rozhodneme sa dobre alebo nie.

Testovanie IaC: Nástroje na testovanie jednotiek

Otázka, čo sú testy na CFM? Skript môžete jednoducho spustiť alebo na to môžete použiť hotové riešenia:

CFM
Nástroj

Ansible
Testinfra

šéfkuchár
INSPEC

šéfkuchár
Serverspec

soľnička
Goss

Príklad pre testinfra, ktorý kontroluje používateľov test1, test2 existujú a sú v skupine 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

Čo si vybrať? Otázka je zložitá a nejednoznačná, tu je príklad zmien v projektoch na github na roky 2018-2019:

Testovacie rámce IaC

Vynára sa otázka: ako to všetko spojiť a spustiť? Môcť vezmi si to a urob to sám ak je dostatočný počet inžinierov. Alebo si môžete vziať hotové riešenia, aj keď ich nie je veľa:

CFM
Nástroj

Ansible
molekula

šéfkuchár
Test kuchyne

terraform
Terratest

Príklad zmien v projektoch na githube na roky 2018-2019:

Molekula vs. Testkuchyne

Spočiatku my vyskúšali pomocou testkuchyne:

Vytvorte paralelne VM.
Použiť role Ansible.
Spustite kontrolu.

Pre 25-35 rolí to fungovalo 40-70 minút, čo bolo dlho.

Ďalším krokom bol prechod na jenkins/docker/ansible/molecule. Idiologicky je všetko rovnaké

Lint playbooky.
Zoraďte roly.
Spustiť kontajner
Použiť role Ansible.
Spustite testinfra.
Skontrolujte idempotenciu.

Lining pre 40 rolí a testy pre tucet začali trvať asi 15 minút.

Čo si vybrať, závisí od mnohých faktorov, ako je použitý zásobník, odbornosť v tíme atď. tu sa každý sám rozhodne, ako uzavrie otázku testovania jednotiek

Testovanie IaC: Integračné testy

Ďalším krokom v pyramíde testovania infraštruktúry budú integračné testy. Sú podobné jednotkovým testom:

Infraštruktúra je rozdelená do malých kociek, napríklad Ansible role.
Je nasadený nejaký druh prostredia, či už je to docker alebo VM.
Pre toto testovacie prostredie platí veľa Prípustné role.
Skontrolujeme, či všetko fungovalo tak, ako sme očakávali (spustíme testy).
Rozhodneme sa dobre alebo nie.

Zhruba povedané, nekontrolujeme výkon jednotlivého prvku systému ako pri unit testoch, ale ako je server nakonfigurovaný ako celok.

Testovanie IaC: Testy od konca do konca

Na vrchole pyramídy nás vítajú End to End testy. Tie. Nekontrolujeme výkon samostatného servera, samostatného skriptu alebo samostatnej kocky našej infraštruktúry. Kontrolujeme, či je veľa serverov prepojených, naša infraštruktúra funguje tak, ako očakávame. Bohužiaľ, nikdy som nevidel hotové krabicové riešenia, pravdepodobne preto... Infraštruktúra je často jedinečná a ťažko sa dá vytvoriť a vytvoriť rámec na testovanie. V dôsledku toho si každý vytvára svoje vlastné riešenia. Existuje dopyt, ale neexistuje žiadna odpoveď. Preto vám poviem, čo tam je, aby som prinútil ostatných, aby si mysleli, alebo si šúcham nos v tom, že všetko bolo vynájdené dávno pred nami.

Projekt s bohatou históriou. Používa sa vo veľkých organizáciách a asi každý z vás sa s ním nepriamo stretol. Aplikácia podporuje množstvo databáz, integrácií atď. Vedieť, ako môže infraštruktúra vyzerať, je veľa súborov zostavených dockerom a vedieť, ktoré testy sa majú spustiť v akom prostredí, je Jenkins.

Táto schéma fungovala pomerne dlho, až kým nebola v rámci výskum neskúšali sme to preniesť do Openshift. Kontajnery zostávajú rovnaké, zmenilo sa však prostredie spustenia (ahoj opäť D.R.Y.).

Myšlienka výskumu zašla ešte ďalej a v openshift našli niečo ako APB (Ansible Playbook Bundle), ktoré vám umožňuje zabaliť poznatky o tom, ako nasadiť infraštruktúru do kontajnera. Tie. existuje opakovateľný a testovateľný bod vedomostí o tom, ako nasadiť infraštruktúru.

To všetko znelo dobre, kým sme nenarazili na heterogénnu infraštruktúru: na testy sme potrebovali Windows. Výsledkom je, že znalosti o tom, čo, kde, ako nasadiť a testovať, sú v jenkins.

záver

Infraštruktúra ako kódex

Kód v úložisku.
Ľudská interakcia.
Testovanie infraštruktúry.

Odkazy

Zdroj: hab.com

Čo som sa naučil pri testovaní 200 000 riadkov kódu infraštruktúry