Jak si vzít síťovou infrastrukturu pod kontrolu. Čtvrtá kapitola. Automatizace. Šablony

Tento článek je šestý v sérii článků „Jak vzít síťovou infrastrukturu pod svou kontrolu“. Obsah všech článků v sérii a odkazy najdete zde.

Poté, co jsem opustil několik témat, jsem se rozhodl, že přece jen začnu novou kapitolu.

K bezpečnosti se vrátím o něco později. Zde chci probrat jeden jednoduchý, ale účinný přístup, který, jsem si jist, se v různých podobách může hodit mnoha lidem. Je to spíše krátký příběh o tom, jak může automatizace změnit život inženýra. Bude se jednat o využití šablon. Na konci je uveden seznam mých projektů, kde si můžete prohlédnout, jak to, co je zde popsáno, funguje.

DevOps pro síť

Vytváření konfigurace skriptem, používání GIT pro kontrolu změn IT infrastruktury, vzdálené 'nahrání' — tyto myšlenky vyvstávají jako první, když přemýšlíte o technické realizaci přístupu DevOps. Klady jsou zřejmé. Ale bohužel jsou zde i zápory.

Když před více než 5 lety naši vývojáři přišli k nám, síťařům, s těmito návrhy, nebyli jsme nadšení.

Je třeba říct, že jsme zdědili docela pestrou síť, složenou z vybavení od zhruba 10 různých dodavatelů. Něco bylo pohodlné konfigurovat přes náš oblíbený CLI, ale někde jsme raději používali GUI. Navíc dlouhá práce na 'živém' zařízení nás naučila k reálnému sledování. Osobně se při provádění změn cítím mnohem pohodlněji, když pracuji přímo přes CLI. Tak mohu rychle vidět, že se něco pokazilo a 'vrátit' změny. To vše bylo v určitém rozporu s jejich myšlenkami.

Objevují se i další otázky, například rozhraní se může mírně měnit od verze k verzi softwaru. To nakonec povede k tomu, že váš skript vytvoří nesprávnou 'konfiguraci'. Nechtěl bych používat produkci pro 'zkoušení'.

Nebo jak zjistit, že konfigurační příkazy byly správně aplikovány a co dělat v případě chyby?

Nechci říkat, že všechny tyto otázky jsou neřešitelné. Pouze říct „A“, je pravděpodobně rozumné říci také „B“, a pokud chcete používat stejné procesy pro kontrolu změn jako ve vývoji, je třeba mít kromě produkčního prostředí také dev a staging prostředí. Tehdy tento přístup vypadá kompletní. Ale kolik to bude stát?

Existuje však jedna situace, kdy se nevýhody prakticky neutralizují a zůstávají jen výhody. Mluvím o projektové práci.

Projekt

Poslední dva roky se účastním projektu na výstavbě datového centra pro jednoho velkého poskytovatele. Jsem zodpovědný v tomto projektu za F5 a Palo Alto. Z pohledu Cisco je to „3rd party equipment“.

Osobně v tomto projektu vnímám dvě jasné fáze.

První fáze

První rok jsem byl neustále zaměstnaný, pracoval jsem v noci a o víkendech. Nemohl jsem ani zvednout hlavu. Tlak ze strany managementu a zadavatele byl silný a neustávající. V neustálé rutině jsem nemohl ani zkusit optimalizovat proces. Nebylo to jen a ani tolik konfigurace zařízení, ale spíše příprava projektové dokumentace.

A najednou začaly první testy a byl jsem ohromen, kolik drobných chyb a nepřesností bylo napácháno. Samozřejmě, vše fungovalo, ale zde chybělo písmeno v názvu, tam chyběl řádek v příkazu… Testy pokračovaly a já jsem byl v neustálém, každodenním boji s chybami, testy a dokumentací.

Takto to trvalo rok. Projekt, jak chápu, byl pro všechny náročný, ale postupně byl klient stále spokojenější a to nám umožnilo přijmout další inženýry, kteří si mohli vzít část rutiny na sebe.

Teď bylo možné se trochu rozhlédnout.
A to bylo začátkem druhé fáze.

Druhá fáze

Rozhodl jsem se automatizovat proces.

Co jsem pochopil z tehdejší komunikace s vývojáři (a musím uznat, že jsme měli silný tým), je, že textový formát, i když se na první pohled zdá jako něco z světa operačního systému DOS, má řadu cenných vlastností.
Například, textový formát bude užitečný, pokud chcete plně využít výhod GIT a všech jeho derivátů. A já chtěl.

No, mohlo by se zdát, že stačí jen uchovávat konfiguraci nebo seznam příkazů, ale provádění změn je v tomto případě docela nešikovné. Kromě toho při návrhu existuje ještě jedna důležitá úloha. Musíte mít dokumentaci, která popisuje váš design celkově (Low Level Design) a konkrétní implementaci (Network Implementation Plan). A v tomto případě se použití šablon ukazuje jako velmi vhodná varianta.

Tak, při použití YAML a Jinja2, YAML soubor s parametry konfigurace, jako jsou IP adresy, čísla BGP AS,… skvěle plní roli NIP, zatímco Jinja2 šablony obsahují syntaxi odpovídající designu, tedy v podstatě odrážejí LLD.

Na studium jazyků YAML a Jinja2 jsem potřeboval dva dny. K pochopení, jak to funguje, stačí několik dobrých příkladů. Poté jsem strávil asi dva týdny vytvářením všech šablon odpovídajících našemu designu: týden pro Palo Alto a další týden — pro F5. Všechny byly nahrány na firemní GitHub.

Nyní proces změn vypadal následovně:

• změnil jsem YAML soubor
• vytvořil jsem pomocí šablony (Jinja2) konfigurační soubor
• uložil do vzdáleného repozitáře
• publikoval vytvořenou konfiguraci na zařízení
• viděl jsem chybu
• změnil jsem YAML soubor nebo Jinja2 šablonu
• vytvořil jsem pomocí šablony (Jinja2) konfigurační soubor
• …

Je jasné, že zpočátku to zabíralo hodně času na úpravy, ale po týdnu až dvou to už bylo spíše výjimečné.

Dobrou zkouškou a možností vše doladit bylo přání klienta změnit naming convention. Kdo pracoval s F5, chápe pikantnost situace. Ale pro mě to bylo celkem jednoduché. Změnil jsem názvy v YAML souboru, smazal celou konfiguraci z zařízení, vygeneroval novou a nahrál ji. Na vše, včetně oprav chyb, jsem potřeboval 4 dny: po dva dny na každou technologii. Poté jsem byl připraven na další etapa, a to vytvoření DEV a Staging datových center.

Dev a Staging

Staging v podstatě zcela kopíruje produkci. Dev — výrazně omezená a převážně postavená na virtuálním vybavení kopie. Ideální situace pro použití nového přístupu. Pokud od celého procesu odečtu čas, který jsem strávil, pak práce, myslím, trvala maximálně 2 týdny. Hlavní část času — to je čas čekání na druhou stranu a společné hledání problémů. Implementace 3rd party probíhala téměř nepozorovaně pro ostatní. Dokonce se objevilo čas na něco se naučit a napsat pár článků na Habru 🙂

Shrnutí

Takže, co mám na konci?

• všechno, co potřebuji pro změnu konfigurace — změnit jednoduchý, jasně strukturovaný YAML soubor s konfiguračními parametry. Nikdy neměním python skript a velmi zřídka (jen pokud je tam chyba) měním Jinja2 šablonu.
• Z pohledu dokumentace se jedná o téměř ideální situaci. Měníte dokumentaci (soubor YAML funguje jako NIP) a nahráváte tuto konfiguraci do zařízení. Tím je vaše dokumentace vždy aktuální.

To vše vedlo k tomu, že

• procento chyb kleslo prakticky na 0.
• odešlo 90 procent rutinní práce.
• rychlost implementace se několikanásobně zvýšila.

PAY, F5Y, ACY

Říkal jsem, že několik příkladů stačí, abyste pochopili, jak to funguje.
Zde je stručná (a samozřejmě upravená) verze toho, co bylo vytvořeno v průběhu mé práce.

PAY = nasazení redicted Frame)alo Alto z Yaml = Palo Alto z Yaml
F5Y = nasazení F5 from Yaml = F5 from Yaml (brzy bude)
ACY = nasazení ACi z Yaml = F5 from Yaml

Přidám několik slov o ACY (neplést s ACI).

Ti, kteří pracovali s ACI, vědí, že tento zázrak (a to v dobrém slova smyslu) byl vytvořen určitě ne síťaři :). Zapomeňte na všechno, co jste věděli o síti — to vám není k užitku!
Trochu přehnané, ale přibližně vystihuje to, co neustále, již 3 roky, pociťuji při práci s ACI.

A v tomto případě je ACY nejen možnost vybudovat proces sledování změn (což je obzvlášť důležité v případě ACI, protože se předpokládá, že to je centrální a nejkritičtější část vašeho datacentra), ale také vám poskytuje přívětivé rozhraní pro vytváření konfigurace.

Inženýři v tomto projektu místo YAML pro konfiguraci ACI používají Excel k dosažení stejných cílů. Používání Excelu má, samozřejmě, své výhody:

• váš NIP v jednom souboru.
• hezké tabulky, na které se klientovi příjemně dívá.
• můžete použít některé nástroje Excelu.

Ale je tu jeden nedostatek, který podle mého názoru převyšuje výhody. Kontrolovat změny a sladit práci týmu se stává mnohem složitější.

ACY je vlastně aplikací těch samých přístupů, které jsem použil pro 3rd party, pro konfiguraci ACI.

Zdroj: habr.com