Přístup IAC (Infrastructure as Code) se skládá nejen z kódu, který je uložen v úložišti, ale také z lidí a procesů, které tento kód obklopují. Je možné znovu použít přístupy od vývoje softwaru po správu a popis infrastruktury? Bylo by dobré mít tuto myšlenku na paměti při čtení článku.

anglická verze

Toto je můj přepis představení na DevopsConf 2019.

Snímky a videa

• anglická verze
• Ruská verze
• Suchý provoz 2019-04-24 SpbLUG
• Video (RU) z DevopsConf 2019-05-28
• Video(RU) z DINS DevOps EVENING 2019-06-20
• Slides

Infrastruktura jako bash historie

Předpokládejme, že přijdete do nového projektu a oni vám řeknou: „Máme Infrastruktura jako kód". Ve skutečnosti se ukazuje Infrastruktura jako bash historie nebo například Dokumentace jako bash historie. To je velmi reálná situace, například podobný případ popsal v projevu Denis Lysenko Jak vyměnit celou infrastrukturu a začít klidně spát, řekl, jak získali koherentní infrastrukturu pro projekt z historie bash.

S určitou touhou to můžeme říci Infrastruktura jako bash historie toto je jako kód:

1. reprodukovatelnost: Můžete vzít historii bash, spouštět příkazy odtud a mimochodem můžete získat funkční konfiguraci jako výstup.
2. verzování: víte, kdo přišel a co udělal, opět není pravda, že vás to přivede k funkční konfiguraci na výstupu.
3. historie: příběh o tom, kdo co udělal. pouze pokud server ztratíte, nebudete jej moci používat.

Co dělat?

Infrastruktura jako kód

I tak zvláštní případ jako Infrastruktura jako bash historie můžete ho tahat za uši Infrastruktura jako kód, ale když budeme chtít udělat něco složitějšího, než je starý dobrý LAMP server, dojdeme k závěru, že tento kód je potřeba nějak upravit, změnit, vylepšit. Dále bychom rádi zvážili paralely mezi nimi Infrastruktura jako kód a vývoj softwaru.

SCHNOUT

Na projektu vývoje úložného systému byl dílčí úkol pravidelně konfigurovat SDS: vydáváme novou verzi – je třeba ji zavést pro další testování. Úkol je velmi jednoduchý:

• přihlaste se zde přes ssh a spusťte příkaz.
• zkopírujte soubor tam.
• opravte konfiguraci zde.
• spustit službu tam
• ...
• ZISKU!

Pro popsanou logiku bash bohatě stačí, zvláště v raných fázích projektu, kdy se teprve rozbíhá. Tento není špatné, že používáte bash, ale postupem času se objevují požadavky na nasazení něčeho podobného, ​​ale trochu jiného. První věc, která vás napadne: copy-paste. A nyní již máme dva velmi podobné skripty, které dělají téměř totéž. Postupem času rostl počet skriptů a my jsme se potýkali s tím, že existuje určitá obchodní logika pro nasazení instalace, kterou je potřeba synchronizovat mezi různými skripty, to je poměrně složité.

Ukazuje se, že existuje taková praxe jako DRY (Do not Repeat Yourself). Cílem je znovu použít existující kód. Zní to jednoduše, ale nepřišli jsme na to hned. V našem případě to byl banální nápad: oddělit konfigurace od skriptů. Tito. obchodní logiku toho, jak je instalace nasazena samostatně, konfiguruje se samostatně.

SOLID pro CFM

Postupem času se projekt rozrostl a přirozené pokračování byl vznik Ansible. Hlavním důvodem jeho vzhledu je, že tým má odborné znalosti a že bash není navržen pro složitou logiku. Ansible také začal obsahovat složitou logiku. Aby se složitá logika nezměnila v chaos, existují zásady pro organizaci kódu při vývoji softwaru PEVNÝ Také například Grigory Petrov ve zprávě „Proč IT specialista potřebuje osobní značku“ nastolil otázku, že člověk je navržen tak, aby pro něj bylo snazší pracovat s některými sociálními subjekty, při vývoji softwaru jsou předměty. Pokud tyto dva nápady spojíme a budeme je dále rozvíjet, všimneme si, že je můžeme také použít PEVNÝ aby bylo v budoucnu snazší udržovat a upravovat tuto logiku.

Princip jednotné odpovědnosti

Každá třída plní pouze jeden úkol.

Není třeba míchat kód a vytvářet monolitické božské špagetové příšery. Infrastruktura by se měla skládat z jednoduchých cihel. Ukazuje se, že pokud rozdělíte herní knihu Ansible na malé kousky, přečtete si role Ansible, pak se snáze udržují.

Princip Otevřeno Uzavřeno

Princip otevřeno/zavřeno.

• Otevřeno pro rozšíření: znamená, že chování entity lze rozšířit vytvořením nových typů entit.
• Uzavřeno pro změny: V důsledku rozšíření chování entity by neměly být provedeny žádné změny v kódu, který tyto entity používá.

Zpočátku jsme testovací infrastrukturu nasazovali na virtuální stroje, ale vzhledem k tomu, že obchodní logika nasazení byla oddělená od implementace, bez problémů jsme přidali rollout na baremetall.

Liskovský princip substituce

Princip substituce Barbary Liskovové. objekty v programu musí být nahraditelné instancemi jejich podtypů, aniž by se změnilo správné provádění programu

Pokud se na to podíváte šířeji, není to vlastnost žádného konkrétního projektu, který by se tam dal uplatnit PEVNÝ, obecně jde o CFM, např. na jiném projektu je potřeba nasadit krabicovou Java aplikaci nad různé Javy, aplikační servery, databáze, OS atp. Na tomto příkladu zvážím další principy PEVNÝ

V našem případě existuje dohoda v rámci týmu infrastruktury, že pokud jsme nainstalovali roli imbjava nebo oraclejava, pak máme binární spustitelný soubor Java. To je nutné, protože Upstream role závisí na tomto chování; očekávají Java. Zároveň nám to umožňuje nahradit jednu implementaci/verzi Java jinou, aniž bychom měnili logiku nasazení aplikace.

Problém zde spočívá v nemožnosti implementace v Ansible, v důsledku čehož se v týmu objevují určité dohody.

Princip segregace rozhraní

Princip oddělení rozhraní: „Mnoho klientských rozhraní je lepších než jedno univerzální rozhraní.

Zpočátku jsme se snažili dát veškerou variabilitu nasazení aplikací do jednoho Ansible playbooku, ale bylo to náročné na podporu a přístup, kdy máme specifikované externí rozhraní (klient očekává port 443), pak lze sestavit infrastrukturu z jednotlivých cihly pro konkrétní realizaci.

Princip inverze závislosti

Princip inverze závislosti. Moduly na vyšších úrovních by neměly záviset na modulech na nižších úrovních. Oba typy modulů musí záviset na abstrakcích. Abstrakce by neměly záviset na detailech. Podrobnosti musí záviset na abstrakcích.

Zde bude příklad založen na antivzoru.

1. Jeden ze zákazníků měl privátní cloud.
2. Objednali jsme virtuální stroje uvnitř cloudu.
3. Ale kvůli povaze cloudu bylo nasazení aplikací vázáno na to, na kterém hypervizoru byl virtuální počítač.

Tito. Logika nasazení aplikací na vysoké úrovni plynula se závislostmi na nižších úrovních hypervizoru, což znamenalo problémy při opětovném použití této logiky. Nedělejte to takhle.

Interakce

Infrastruktura jako kód není jen o kódu, ale také o vztahu mezi kódem a lidmi, o interakcích mezi vývojáři infrastruktury.

Autobusový faktor

Předpokládejme, že máte ve svém projektu Vasyu. Vasya ví všechno o vaší infrastruktuře, co se stane, když Vasya náhle zmizí? To je velmi reálná situace, protože by ho mohl srazit autobus. Někdy se to stane. Pokud se to stane a znalosti o kódu, jeho struktuře, fungování, vzhledu a heslech nejsou distribuovány mezi tým, pak se můžete setkat s řadou nepříjemných situací. K minimalizaci těchto rizik a distribuci znalostí v rámci týmu můžete použít různé přístupy

Rozvíjení párů

To není jako jako vtip, že admini pili pivo, měnili hesla a obdobu párového programování. Tito. dva inženýři si sednou k jednomu počítači, jedné klávesnici a začnou společně nastavovat vaši infrastrukturu: nastavení serveru, psaní role Ansible atd. Zní to hezky, ale u nás to nefungovalo. Ale speciální případy této praxe fungovaly. Přichází nový zaměstnanec, jeho mentor s ním přebírá skutečný úkol, pracuje a předává znalosti.

Dalším speciálním případem je incidentní volání. Během problému se shromáždí skupina těch, kteří jsou ve službě, a zúčastněných, je jmenován jeden vůdce, který sdílí svou obrazovku a vyjadřuje tok myšlenek. Ostatní účastníci sledují myšlenky vůdce, sledují triky z konzole, kontrolují, zda nevynechali řádek v protokolu, a učí se nové věci o systému. Tento přístup fungoval častěji než ne.

Kontrola kódu

Subjektivně bylo efektivnější šířit znalosti o infrastruktuře a o tom, jak funguje pomocí kontroly kódu:

• Infrastruktura je popsána kódem v úložišti.
• Ke změnám dochází v samostatné větvi.
• Během žádosti o sloučení můžete vidět rozdíl změn v infrastruktuře.

Vrcholem zde bylo, že recenzenti byli vybíráni jeden po druhém, podle harmonogramu, tzn. s určitou mírou pravděpodobnosti vlezete do nového kusu infrastruktury.

Styl kódu

Postupem času se při recenzích začaly objevovat hádky, protože... recenzenti měli svůj vlastní styl a střídání recenzentů jim naskládalo různé styly: 2 mezery nebo 4, camelCase nebo snake_case. Nebylo možné to hned realizovat.

• První nápad byl doporučit používat linter, vždyť každý je inženýr, každý je chytrý. Ale různé editory, OS, nejsou pohodlné
• Z toho se vyvinul bot, který psal do slack pro každé problematické potvrzení a připojoval výstup linter. Ale ve většině případů bylo třeba udělat důležitější věci a kód zůstal neopravený.

Mistr zelené stavby

Čas plyne a my jsme dospěli k závěru, že commity, které neprojdou určitými testy, nelze do masteru vpustit. Voila! Vymysleli jsme Green Build Master, který se ve vývoji softwaru praktikuje již dlouhou dobu:

• Vývoj probíhá v samostatné pobočce.
• Na tomto vláknu probíhají testy.
• Pokud testy selžou, kód se do masteru nedostane.

Toto rozhodnutí bylo velmi bolestivé, protože... vyvolalo spoustu kontroverzí, ale stálo to za to, protože... Do recenzí se začaly dostávat žádosti o sloučení bez rozdílů ve stylu a postupem času začalo ubývat problémových oblastí.

Testování IaC

Kromě kontroly stylu můžete použít i další věci, například zkontrolovat, zda se vaše infrastruktura skutečně umí nasadit. Nebo zkontrolujte, zda změny v infrastruktuře nepovedou ke ztrátě peněz. Proč to může být potřeba? Otázka je složitá a filozofická, je lepší odpovědět příběhem, že na Powershell nějak existoval automatický škálovač, který nekontroloval okrajové podmínky => bylo vytvořeno více VM, než bylo nutné => klient utratil více peněz, než plánoval. To není příliš příjemné, ale bylo by docela možné tuto chybu zachytit v dřívějších fázích.

Někdo by se mohl ptát, proč dělat složitou infrastrukturu ještě složitější? Testy pro infrastrukturu, stejně jako pro kód, nejsou o zjednodušení, ale o tom, jak by měla vaše infrastruktura fungovat.

IaC testovací pyramida

Testování IaC: Statická analýza

Pokud nasadíte celou infrastrukturu najednou a zkontrolujete, že funguje, možná zjistíte, že to zabere spoustu času a vyžaduje spoustu času. Základem proto musí být něco, co funguje rychle, je toho hodně a pokryje to spoustu primitivních míst.

Bash je složitý

Podívejme se na triviální příklad. vyberte všechny soubory v aktuálním adresáři a zkopírujte je do jiného umístění. První, co mě napadne:

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

Co když je v názvu souboru mezera? Dobře, jsme chytří, víme, jak používat uvozovky:

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

Výborně? Ne! Co když v adresáři nic není, tzn. globování nebude fungovat.

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

Dobře teď? Ne... Zapomněl jsem, co může být v názvu souboru n.

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

Nástroje statické analýzy

Problém z předchozího kroku by mohl být zachycen, když jsme zapomněli uvozovky, na to existuje v přírodě mnoho opravných prostředků Shellcheck, obecně je jich hodně a s největší pravděpodobností najdete linter pro svůj stack pod vaším IDE.

Jazyk
Nástroj

praštit
Shellcheck

Rubín
RuboCop

krajta
pylint

ansible
Ansible Lint

Testování IaC: Testy jednotek

Jak jsme viděli z předchozího příkladu, linters nejsou všemocné a nemohou upozornit na všechny problémové oblasti. Dále, analogicky s testováním ve vývoji softwaru, můžeme připomenout unit testy. Co mě hned napadne, je šunit, Junit, rspec, otázka. Ale co dělat s ansibleem, kuchařem, saltstackem a dalšími podobnými?

Na samém začátku jsme mluvili o PEVNÝ a že naše infrastruktura by se měla skládat z malých cihel. Nastal jejich čas.

1. Infrastruktura je rozdělena do malých kostek, například Ansible role.
2. Je nasazeno nějaké prostředí, ať už je to docker nebo virtuální počítač.
3. Na toto testovací prostředí aplikujeme naši roli Ansible.
4. Zkontrolujeme, že vše fungovalo tak, jak jsme očekávali (provádíme testy).
5. Rozhodneme se dobře nebo ne.

Testování IaC: Nástroje pro testování jednotek

Otázka, co jsou testy pro CFM? Skript můžete jednoduše spustit, nebo k tomu můžete použít hotová řešení:

CFM
Nástroj

Možná
Testinfra

Šéfkuchař
Inspect

Šéfkuchař
Specifikace serveru

sůl
Goss

Příklad pro testinfra, kontrola uživatelů test1, test2 existují a jsou ve skupině 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

Co si vybrat? Otázka je složitá a nejednoznačná, zde je příklad změn v projektech na githubu pro roky 2018-2019:

Testovací rámce IaC

Nabízí se otázka: jak to všechno dát dohromady a spustit? Umět vezmi si to a udělej to sám pokud je dostatečný počet inženýrů. Nebo můžete vzít hotová řešení, i když jich není příliš mnoho:

CFM
Nástroj

Možná
Molekula

Šéfkuchař
Test kuchyně

Terraform
Terratest

Příklad změn v projektech na githubu pro roky 2018-2019:

Molekula vs. Testkuchyně

Zpočátku my vyzkoušeli pomocí testovací kuchyně:

1. Vytvořte virtuální počítač paralelně.
2. Použijte role Ansible.
3. Spustit kontrolu.

Pro 25-35 rolí to fungovalo 40-70 minut, což bylo dlouho.

Dalším krokem byl přechod na jenkins/docker/ansible/molecule. Idiologicky je vše stejné

1. Lint playbooky.
2. Seřaďte role.
3. Spusťte kontejner
4. Použijte role Ansible.
5. Spusťte testinfra.
6. Zkontrolujte idempotenci.

Lining pro 40 rolí a testy pro tucet začaly trvat asi 15 minut.

Co si vybrat, závisí na mnoha faktorech, jako je použitý zásobník, odbornost v týmu atd. zde se každý sám rozhodne, jak uzavřít otázku Unit testing

Testování IaC: Integrační testy

Dalším krokem v pyramidě testování infrastruktury budou integrační testy. Jsou podobné jednotkovým testům:

1. Infrastruktura je rozdělena do malých kostek, například Ansible role.
2. Je nasazeno nějaké prostředí, ať už je to docker nebo virtuální počítač.
3. Pro toto testovací prostředí platí mnoho Přípustné role.
4. Zkontrolujeme, že vše fungovalo tak, jak jsme očekávali (provádíme testy).
5. Rozhodneme se dobře nebo ne.

Zhruba řečeno, nekontrolujeme výkon jednotlivého prvku systému jako u unit testů, ale jak je server nakonfigurován jako celek.

Testování IaC: Testy od konce do konce

Na vrcholu pyramidy nás vítají End to End testy. Tito. Nekontrolujeme výkon samostatného serveru, samostatného skriptu nebo samostatné cihly naší infrastruktury. Kontrolujeme, zda je mnoho serverů propojeno, naše infrastruktura funguje tak, jak očekáváme. Bohužel jsem nikdy neviděl hotová krabicová řešení, pravděpodobně proto... Infrastruktura je často jedinečná a je obtížné ji šablonovat a vytvořit rámec pro testování. Výsledkem je, že si každý vytváří vlastní řešení. Existuje poptávka, ale odpověď neexistuje. Proto vám řeknu, co existuje, abych přiměl ostatní, aby si mysleli, nebo si otřeli nos ve skutečnosti, že vše bylo vynalezeno dávno před námi.

Projekt s bohatou historií. Používá se ve velkých organizacích a asi každý z vás se s ním nepřímo zkřížil. Aplikace podporuje mnoho databází, integrací atd. Vědět, jak může infrastruktura vypadat, je spousta souborů sestavených dockerem a vědět, které testy spustit v jakém prostředí, je Jenkins.

Toto schéma fungovalo poměrně dlouho, dokud nebylo v rámci výzkum nezkoušeli jsme to přenést do Openshift. Kontejnery zůstávají stejné, ale změnilo se spouštěcí prostředí (znovu ahoj DRY).

Myšlenka výzkumu šla ještě dál a v openshiftu našli něco jako APB (Ansible Playbook Bundle), který vám umožňuje zabalit znalosti o tom, jak nasadit infrastrukturu do kontejneru. Tito. existuje opakovatelný a testovatelný bod znalostí o tom, jak nasadit infrastrukturu.

To vše znělo dobře, dokud jsme nenarazili na heterogenní infrastrukturu: pro testy jsme potřebovali Windows. V důsledku toho jsou znalosti o tom, co, kde, jak nasadit a testovat, v jenkins.

Proč investovat do čističky vzduchu?

Infrastruktura jako kód

• Kód v úložišti.
• Lidská interakce.
• Testování infrastruktury.

Odkazy

• Anglická verze
• Křížový příspěvek z osobního blogu
• Suchý provoz 2019-04-24 SpbLUG
• Video (RU) z DevopsConf 2019-05-28
• Video(RU) z DINS DevOps EVENING 2019-06-20
• Ponaučení z psaní více než 300,000 XNUMX řádků kódu infrastruktury & textová verze
• Integrace infrastruktury jako kódu do průběžného zásobovacího kanálu
• Testování infrastruktury jako kódu
• Efektivní rozvoj a údržba rolí Ansible
• Ansible není bash!

Zdroj: www.habr.com