Tento článek je šestý ze série „Jak převzít kontrolu nad svou síťovou infrastrukturou“. Obsah všech článků v seriálu a odkazy naleznete .
Po několika tématech jsem se rozhodl začít novou kapitolu.
K bezpečnosti se vrátím o něco později. Zde chci diskutovat o jednom jednoduchém, ale účinném přístupu, o kterém jsem si jistý, že v té či oné podobě může být pro mnohé užitečný. Toto je spíše krátký příběh o tom, jak automatizace může změnit život inženýra. Budeme mluvit o používání šablon. Na konci je seznam mých projektů, kde se můžete podívat, jak vše zde popsané funguje.
DevOps pro síť
Vytváření konfigurace pomocí skriptu, používání GIT pro řízení změn v IT infrastruktuře, vzdálené „nahrávání“ – tyto nápady přicházejí jako první, když přemýšlíte o technické implementaci přístupu DevOps. Výhody jsou zřejmé. Ale bohužel existují i nevýhody.
Když před více než 5 lety za námi, networkery, přišli naši vývojáři s těmito návrhy, nebyli jsme nadšeni.
Musím říci, že jsme zdědili poměrně pestrou síť, skládající se ze zařízení od asi 10 různých prodejců. Bylo pohodlné konfigurovat některé věci přes naše oblíbené cli, ale v jiných jsme raději používali GUI. Dlouhá práce na „živém“ zařízení nás navíc naučila ovládat v reálném čase. Například při provádění změn se cítím mnohem pohodlněji při práci přímo přes cli. Tímto způsobem mohu rychle zjistit, že se něco pokazilo, a vrátit změny zpět. To vše bylo v určitém rozporu s jejich představami.
Vyvstávají i další otázky, například rozhraní se může mírně měnit verze od verze softwaru. To nakonec způsobí, že váš skript vytvoří nesprávnou "konfiguraci". Nerad bych využíval produkci k „záběhu“.
Nebo jak pochopit, že konfigurační příkazy byly použity správně a co dělat v případě chyby?
Nechci tvrdit, že všechny tyto problémy jsou neřešitelné. Pouhé říkat „A“ má pravděpodobně smysl říkat také „B“, a pokud chcete pro řízení změn používat stejné procesy jako při vývoji, musíte mít kromě výroby i vývojová a stagingová prostředí. Pak tento přístup vypadá kompletní. Ale kolik to bude stát?
Existuje však jedna situace, kdy se nevýhody prakticky vyrovnají a zůstanou pouze výhody. Mluvím o designérské práci.
projekt
Poslední dva roky se podílím na projektu výstavby datového centra pro velkého poskytovatele. V tomto projektu jsem zodpovědný za F5 a Palo Alto. Z pohledu společnosti Cisco se jedná o „zařízení třetí strany“.
Pro mě osobně jsou v tomto projektu dvě odlišné fáze.
První fáze
První rok jsem byl nekonečně vytížený, pracoval jsem po nocích a víkendech. Nemohl jsem zvednout hlavu. Tlak ze strany vedení a zákazníka byl silný a nepřetržitý. V neustálé rutině jsem se ani nemohl pokusit proces optimalizovat. Nešlo jen a ani ne tak o konfiguraci zařízení jako o přípravu projektové dokumentace.
Začaly první testy a divil bych se, kolik drobných chyb a nepřesností se udělalo. Vše samozřejmě fungovalo, ale v názvu chybělo písmeno, v příkazu chyběl řádek... Testy pokračovaly dál a dál a už jsem byl v neustálém, každodenním boji s chybami, testy a dokumentací .
Tak to pokračovalo rok. Projekt, pokud vím, nebyl pro každého jednoduchý, ale postupně byl klient stále spokojenější a to umožnilo najmout další inženýry, kteří byli schopni část rutiny převzít sami.
Teď bychom se mohli trochu rozhlédnout.
A to byl začátek druhé etapy.
Druhá fáze
Rozhodl jsem se proces automatizovat.
Co jsem ze své tehdejší komunikace s vývojáři pochopil (a musíme vzdát hold, měli jsme silný tým), že textový formát, ač na první pohled vypadá jako něco ze světa operačního systému DOS, má řadu cenných vlastností.
Takže například textový formát se vám bude hodit, pokud chcete naplno využít GIT a všechny jeho odvozeniny. A já chtěl.
Zdá se, že můžete jednoduše uložit konfiguraci nebo seznam příkazů, ale provádění změn je docela nepohodlné. Kromě toho je zde další důležitý úkol při návrhu. Měli byste mít dokumentaci popisující váš návrh jako celek (Low Level Design) a konkrétní implementaci (Network Implementation Plan). A v tomto případě vypadá použití šablon jako velmi vhodná možnost.
Při použití YAML a Jinja2 tedy YAML soubor s konfiguračními parametry, jako jsou IP adresy, čísla BGP AS, ... dokonale plní roli NIP, zatímco šablony Jinja2 obsahují syntaxi odpovídající designu, to znamená, že se v podstatě jedná o odraz LLD.
Naučit se YAML a Jinja2 trvalo dva dny. K pochopení toho, jak to funguje, stačí pár dobrých příkladů. Pak trvalo asi dva týdny, než jsme vytvořili všechny šablony, které odpovídaly našemu návrhu: týden pro Palo Alto a další týden pro F5. To vše bylo zveřejněno na firemním githabu.
Nyní proces změny vypadal takto:
- změnil soubor YAML
- vytvořil konfigurační soubor pomocí šablony (Jinja2)
- uloženy ve vzdáleném úložišti
- nahrál vytvořenou konfiguraci do zařízení
- Viděl jsem chybu
- změnil soubor YAML nebo šablonu Jinja2
- vytvořil konfigurační soubor pomocí šablony (Jinja2)
- ...
Je jasné, že zpočátku se úpravami strávilo hodně času, ale po týdnu či dvou se to stalo spíše vzácností.
Dobrým testem a příležitostí vše odladit bylo přání klienta změnit konvenci pojmenování. Ti, kteří pracovali s F5, chápou pikantnost situace. Ale pro mě to bylo všechno docela jednoduché. Změnil jsem názvy v souboru YAML, smazal celou konfiguraci ze zařízení, vygeneroval novou a nahrál. Vše, včetně oprav chyb, trvalo 4 dny: dva dny pro každou technologii. Poté jsem byl připraven na další etapu, a to vytvoření datových center DEV a Staging.
Dev a Staging
Staging vlastně zcela kopíruje produkci. Dev je silně ořezaná kopie postavená hlavně na virtuálním hardwaru. Ideální situace pro nový přístup. Pokud oddělím čas, který jsem strávil od celkového procesu, pak si myslím, že práce netrvala déle než 2 týdny. Hlavní čas je čekání na druhou stranu a společné hledání problémů. Implementace 3. strany zůstala ostatními téměř nepovšimnuta. Dokonce byl čas se něco naučit a napsat pár článků o Habrém :)
Abychom to shrnuli
Takže, co mám ve výsledku?
- Vše, co musím udělat pro změnu konfigurace, je změnit jednoduchý, jasně strukturovaný YAML soubor s konfiguračními parametry. Nikdy neměním python skript a velmi zřídka (pouze pokud je chyba) měním Jinja2 heatlate
- Z dokumentačního hlediska je to téměř ideální stav. Změníte dokumentaci (soubory YAML slouží jako NIP) a nahrajete tuto konfiguraci do zařízení. Vaše dokumentace je tak vždy aktuální
To vše vedlo k tomu, že
- chybovost klesla téměř na 0
- 90 procent rutiny je pryč
- rychlost implementace se výrazně zvýšila
PAY, F5Y, ACY
Řekl jsem, že k pochopení toho, jak to funguje, stačí pár příkladů.
Zde je krátká (a samozřejmě upravená) verze toho, co během mé práce vzniklo.
= nasazení Palo Alto od Yaml = Palo Alto z Yaml
= nasazení F5 od Yaml = F5 od Yaml (již brzy)
= nasazení ACjá z Yaml = F5 od YAML
Přidám pár slov o ACY (neplést s ACI).
Ti, kteří s ACI spolupracovali, vědí, že tento zázrak (a v dobrém slova smyslu) rozhodně nevytvořili síťaři :). Zapomeňte na vše, co jste o síti věděli – nebude vám k ničemu!
Je to trochu přehnané, ale zhruba to vyjadřuje pocit, který jsem poslední 3 roky neustále prožíval při práci s ACI.
A v tomto případě je ACY nejen příležitostí k vybudování procesu řízení změn (což je v případě ACI obzvláště důležité, protože se předpokládá, že jde o centrální a nejkritičtější část vašeho datového centra), ale také vám poskytuje uživatelsky přívětivé rozhraní pro vytváření konfigurace.
Inženýři na tomto projektu používají Excel ke konfiguraci ACI namísto YAML pro přesně stejné účely. Používání Excelu má samozřejmě své výhody:
- váš NIP v jednom souboru
- krásné cedule, na které se klient příjemně dívá
- můžete použít některé excelové nástroje
Ale je tu jedno mínus a podle mě převažuje nad plusy. Kontrola změn a koordinace týmové práce se stává mnohem obtížnější.
ACY je ve skutečnosti aplikací stejných přístupů, které jsem použil pro třetí stranu ke konfiguraci ACI.
Zdroj: www.habr.com