Ez a cikk a "Hogyan vegyük kézbe a hálózati infrastruktúrát" című ciklus hatodik része. A ciklus összes cikkének tartalmát és linkjeit itt találja. .
Néhány téma után úgy döntöttem, hogy új fejezetet kezdek.
A biztonságra később visszatérek. Itt egy egyszerű, de hatékony megközelítést szeretnék megvitatni, amely biztosan sokak számára hasznos lehet. Inkább arról lesz szó, hogy az automatizálás hogyan változtathatja meg egy mérnök életét. A téma a sablonok használata lesz. A végén található egy lista a projektjeimről, ahol megnézheti, hogyan működik mindaz, amiről itt írok.
DevOps a hálózati környezetben
A konfigurációs fájlok létrehozása, a GIT használata az IT infrastruktúra változásainak nyomon követésére, a távoli "feltöltés" - ezek az ötletek elsőként jutnak eszünkbe, amikor a DevOps megközelítés technikai megvalósítására gondolunk. Az előnyök nyilvánvalóak. De sajnos, hátrányok is vannak.
Amikor több mint 5 évvel ezelőtt a fejlesztőink ezekkel az ajánlatokkal hozzánk, a hálózati szakemberekhez fordultak, nem voltunk túl lelkesek.
Meg kell mondanom, hogy egy meglehetősen színes hálózatot örököltünk, amely körülbelül 10 különböző beszállító berendezéseiből állt. Valamit kényelmesen konfigurálhattunk a kedvenc CLI-nk segítségével, de máshol inkább a GUI-t használtuk. Ezenkívül, a „valós” berendezésekkel töltött hosszú idő megtanított minket a valós idejű ellenőrzésre. Én például, változtatások végrehajtásakor, sokkal komfortosabban érzem magam, ha közvetlenül a CLI-n keresztül dolgozom. Így gyorsan megláthatom, ha valami nem stimmel, és „visszaállíthatom” a változtatásokat. Mindez ellentmondásban állt az ő elképzeléseikkel.
Felmerülnek más kérdések is, például a szoftver verzióról verzióra az interfész kissé megváltozhat. Ez végül ahhoz vezet, hogy a szkripted helytelen "konfigurációt" hoz létre. Nem szeretnénk, ha a termelés a "tesztelés" helye lenne.
Vagy hogyan tudjuk meg, hogy a konfigurációs parancsok helyesen lettek alkalmazva, és mit tegyünk, ha hiba lép fel?
Nem akarom azt mondani, hogy ezek a kérdések megoldhatatlanok. Csak annyit mondok, hogy ha elmondunk egy "A"-t, akkor talán érdemes a "B"-t is megemlíteni. Ha a fejlesztéshez hasonló változáskezelési folyamatokat szeretnénk alkalmazni, akkor a termelés mellett dev és staging környezetekre is szükség lesz. Akkor ez a megközelítés teljesnek tűnik. De mennyibe fog ez kerülni?
De van egy helyzet, amikor a hátrányok szinte eltűnnek, és csak az előnyök maradnak. Az általam említett helyzet a projektmunkákra vonatkozik.
Projekt
Az utolsó két évben részt vettem egy adatközpont építési projektben egy nagyobb szolgáltató számára. Ebben a projektben az F5 és Palo Alto az én feladatom volt. Cisco szempontjából ez "3rd party equipment."
Személy szerint számomra ennek a projektnek két jól elkülöníthető szakasza van.
Első szakasz
Az első évben végtelenül elfoglalt voltam, éjszakánként és hétvégén is dolgoztam. Nem tudtam felnézni. A menedzsment és az ügyfél nyomása erős és folyamatos volt. A folyamatos rutin miatt még csak megpróbálni sem tudtam optimalizálni a folyamatot. Ez nemcsak a berendezések konfigurálásáról szólt, hanem a projekt dokumentáció elkészítéséről is.
Ezek után kezdődtek az első tesztek, és megrökönyödtem, hogy mennyi apró hiba és pontatlanság történt. Természetesen minden működött, de itt hiányzott egy betű a névből, ott egy sor a parancsból... A tesztek folytatódtak, és én már folyamatos, napi harcot folytattam a hibák, tesztek és dokumentációk ellen.
Ez egy évig tartott. A projekt, ahogy értem, mindenki számára nem volt egyszerű, de fokozatosan az ügyfél egyre elégedettebbé vált, és ez lehetővé tette, hogy további mérnököket bevonjanak, akik át tudták venni a rutin munka egy részét.
Most már lehetett egy kicsit körülnézni.
És ez volt a második szakasz kezdete.
Második szakasz
Úgy döntöttem, hogy automatizálom a folyamatot.
Akkoriban a fejlesztőkkel folytatott kommunikációmból (és el kell ismerni, hogy erős csapatunk volt) arra jutottam, hogy a szöveges formátum, bár első pillantásra olyan, mint valami a DOS operációs rendszer világából, számos értékes tulajdonsággal rendelkezik.
Például a szöveges formátum hasznos lesz, ha teljes mértékben ki szeretné használni a GIT és annak minden származékának előnyeit. Én pedig ezt szerettem volna.
Nos, úgy tűnik, hogy egyszerűen tárolhatnánk a konfigurációt vagy a parancsok listáját, de a változtatások végrehajtása eléggé kényelmetlen. Ezenkívül a tervezés folyamán van egy másik fontos feladat is. Dokumentációra van szükség, amely összefoglalja a teljes tervezést (Low Level Design) és a konkrét megvalósítást (Network Implementation Plan). És ebben az esetben a sablonok használata nagyon megfelelő megoldásnak tűnik.
A YAML és Jinja2 használatakor a konfigurációs paraméterekkel, mint az IP-címek és BGP AS számok, rendelkező YAML fájl kiválóan teljesíti a NIP szerepét, míg a Jinja2 sablonok a tervezéshez illeszkedő szintaxist tartalmaznak, így lényegében a LLD tükörképét alkotják.
A YAML és Jinja2 nyelvek elsajátítására két napot szántam. Annak megértéséhez, hogy miként működnek, elegendő néhány jó példa. Ezt követően körülbelül két hét telt el, amíg elkészítettem az összes, a tervezésünknek megfelelő sablont: egy hét a Palo Alto-ra és még egy hét az F5-re. Mindezt feltöltöttem a vállalati GitHub-ra.
Most a változások folyamata a következőképpen alakult:
- módosítottam a YAML fájlt
- Jinja2 sablon segítségével létrehoztam a konfigurációs fájlt
- elmentettem a távoli repóba
- feltöltöttem a létrehozott konfigurációt a berendezésre
- hibát észleltem
- módosítottam a YAML fájlt vagy a Jinja2 sablont
- Jinja2 sablon segítségével létrehoztam a konfigurációs fájlt
- …
Nyilvánvaló, hogy az elején sok időt vett igénybe a módosítás, de körülbelül egy-két hét után ez már inkább ritkaságnak számított.
Jó tesztelési lehetőség és hibaelhárítás volt a kliens azon vágya, hogy megváltoztassa a névadási konvenciót. Aki dolgozott már az F5-tel, az érti a helyzet pikantériáját. De számomra minden meglehetősen egyszerű volt. Megváltoztattam a neveket a YAML fájlban, eltávolítottam az összes konfigurációt a berendezésről, újrageneráltam és feltöltöttem. Mindez, a hibák javítását is figyelembe véve, 4 napig tartott: két-két nap mindkét technológiára. Ezután készen álltam a következő szakaszra, nevezetesen a DEV és Staging adatközpontok létrehozására.
Dev és Staging
A Staging gyakorlatilag teljesen megismétli a production-t. A Dev pedig egy erősen lecsökkentett, leginkább virtuális berendezésen alapuló másolat. Ideális helyzet az új megközelítés alkalmazására. Ha a folyamatból leválasztom a rám fordított időt, akkor a munka, véleményem szerint, nem tartott tovább két hétnél. A fő idő az a másik félre való várakozással, és a közös problémakereséssel telt. A 3rd party implementálása szinte észrevétlenül zajlott a környezet számára. Még időm is maradt néhány dolog megtanulására és egy-két cikk írására a Habr-ra 🙂
Összegzés
Tehát mit hoztam ki a szituációból?
- Minden, amire szükségem van a konfiguráció megváltoztatásához, egy egyszerű, világosan strukturált YAML fájl módosítása a konfigurációs paraméterekkel. Soha nem változtatok python scriptet, és nagyon ritkán (csak ha hiba van) módosítom a Jinja2 sablont.
- A dokumentáció szempontjából szinte tökéletes helyzet áll elő. Ön módosítja a dokumentációt (a YAML fájlok NIP-ként működnek), és feltölti ezt a konfigurációt a felszerelésre. Így a dokumentációja mindig naprakész.
Mindez odavezetett, hogy
- a hibák aránya gyakorlatilag 0-ra csökkent.
- a rutinfeladatok 90%-a eltűnt.
- többszörösére nőtt a bevezetés sebessége.
PAY, F5Y, ACY
Azt mondtam, hogy néhány példa elegendő ahhoz, hogy megértsük, hogyan működik.
Itt van egy rövid (és természetesen módosított) verziója annak, ami a munkám során készült.
= telepítés Palo Alto from Yaml = Palo Alto from Yaml
= telepítés F5 a Yaml = F5 a Yaml (hamarosan érkezik)
= telepítés ACi from Yaml = F5 a Yaml
Hozzáfűznék néhány szót az ACY-ról (ne keverje össze az ACI-val).
Azok, akik dolgoztak az ACI-val, tudják, hogy ez a csoda (és ez jó értelemben is) biztosan nem hálózatépítők által készült :). Feledje el mindazt, amit a hálózatról tudott — ez nem lesz hasznos!
Kicsit túlzó, de megközelítőleg tükrözi azt az érzést, amit folyamatosan, már 3 éve tapasztalok, miközben az ACI-val dolgozom.
Ebben az esetben az ACY nemcsak lehetőséget ad a változások ellenőrzési folyamatának felállítására (ami különösen fontos az ACI esetében, mert feltételezhető, hogy ez a központi és legkritikusabb része az adatközpontjának), hanem barátságos felületet biztosít a konfiguráció létrehozásához is.
A projekt mérnökei az ACI konfigurálásához az Excel-t használják a YAML helyett az ugyanolyan célok elérése érdekében. Az Excel használatának persze vannak előnyei:
- az NIP egy fájlban
- szép táblázatok, amelyekre öröm ránézni az ügyfélnek
- használhat néhány Excel-eszközt
De van egy hátrány, ami véleményem szerint felülmúlja az előnyöket. Sokkal nehezebb nyomon követni a változásokat és összehangolni a csapat munkáját.
Az ACY valójában ugyanazokat a módszereket alkalmazza, amelyeket a harmadik fél konfigurálásához használtam, az ACI konfigurálásához.
Forrás: habr.com
