Ez a cikk a hatodik a „Hogyan veheti át az irányítást a hálózati infrastruktúrája felett” sorozatban. A sorozat összes cikkének tartalma és linkjei megtalálhatók .
Miután több témát magam mögött hagytam, úgy döntöttem, hogy új fejezetet kezdek.
Kicsit később visszatérek a biztonságra. Itt egy egyszerű, de hatékony megközelítést szeretnék megvitatni, amely biztos vagyok benne, hogy ilyen vagy olyan formában sokak számára hasznos lehet. Ez inkább egy rövid történet arról, hogyan változtathatja meg az automatizálás egy mérnök életét. Beszélni fogunk a sablonok használatáról. A végén van egy lista a projektjeimről, ahol láthatja, hogyan működik az itt leírtak.
DevOps a hálózathoz
Konfiguráció létrehozása szkripttel, GIT használata az IT-infrastruktúra változásainak vezérlésére, távoli „feltöltés” – ezek az ötletek az elsők, ha a DevOps megközelítés technikai megvalósítására gondolunk. Az előnyök nyilvánvalóak. De sajnos vannak hátrányai is.
Amikor több mint 5 évvel ezelőtt fejlesztőink ezekkel a javaslatokkal kerestek meg minket, hálózatépítőket, nem voltunk elragadtatva.
Azt kell mondanom, hogy egy meglehetősen tarka hálózatot örököltünk, amely körülbelül 10 különböző gyártó berendezéseiből áll. Kényelmes volt néhány dolgot a kedvenc kliensünkön keresztül konfigurálni, másokban viszont inkább a GUI-t választottuk. Ezenkívül az „élő” berendezéseken végzett hosszú munka megtanított minket a valós idejű vezérlésre. Például, amikor változtatásokat hajtok végre, sokkal kényelmesebben érzem magam, ha közvetlenül a klison keresztül dolgozom. Így gyorsan látom, hogy valami elromlott, és visszaállítom a változtatásokat. Mindez némileg ellentmondott az elképzeléseiknek.
Más kérdések is felmerülnek, például a felület kissé változhat a szoftver verziói között. Ez végül azt eredményezi, hogy a szkript rossz "konfigurációt" hoz létre. Nem szívesen használnám a termelést „befutásra”.
Vagy hogyan lehet megérteni, hogy a konfigurációs parancsokat megfelelően alkalmazták-e, és mit kell tenni hiba esetén?
Nem akarom azt mondani, hogy ezek a kérdések mind megoldhatatlanok. Ha csak „A”-t mondunk, akkor valószínűleg „B”-t is mondunk, és ha ugyanazokat a folyamatokat szeretnénk használni a változásvezérléshez, mint a fejlesztés során, akkor a termelés mellett fejlesztői és staging környezetekre is szükségünk van. Akkor ez a megközelítés teljesnek tűnik. De mennyibe fog kerülni?
De van egy helyzet, amikor a hátrányok gyakorlatilag kiegyenlítődnek, és csak az előnyök maradnak. A tervezési munkáról beszélek.
Terv
Az elmúlt két évben egy nagy szolgáltató adatközpontjának felépítésére irányuló projektben vettem részt. Ebben a projektben én vagyok a felelős az F5-ért és a Palo Altóért. A Cisco szemszögéből ez „harmadik fél berendezése”.
Személy szerint ennek a projektnek két külön szakasza van.
Első szakasz
Az első évben végtelenül elfoglalt voltam, éjjel-nappal dolgoztam. Nem tudtam felemelni a fejem. A vezetőség és az ügyfél részéről erős és folyamatos volt a nyomás. Állandó rutinban meg sem tudtam próbálni optimalizálni a folyamatot. Nemcsak és nem is annyira a berendezések konfigurálása, mint inkább a tervdokumentáció elkészítése.
Az első tesztek elkezdődtek, és meglepődnék, mennyi apró hiba és pontatlanság történt. Természetesen minden működött, de a névben hiányzott egy betű, hiányzott egy sor a parancsban... A tesztek mentek és mentek, és máris állandó, napi küzdelemben voltam a hibákkal, tesztekkel, dokumentációval. .
Ez így ment egy évig. A projekt, ha jól értem, nem volt egyszerű mindenkinek, de fokozatosan a megrendelő egyre elégedettebbé vált, és ez lehetővé tette további mérnökök felvételét, akik maguk is vállalhatták a rutin egy részét.
Most körülnézhetnénk egy kicsit.
És ez volt a második szakasz kezdete.
Második szakasz
Úgy döntöttem, hogy automatizálom a folyamatot.
A fejlesztőkkel való akkori kommunikációmból (és tisztelgünk, erős csapatunk volt) azt értettem meg, hogy a szövegformátum, bár első pillantásra valaminek tűnik a DOS operációs rendszer világából, van egy szám értékes ingatlanokról.
Így például a szövegformátum akkor lesz hasznos, ha teljes mértékben ki akarja használni a GIT-t és annak összes származékát. És én akartam.
Nos, úgy tűnik, hogy egyszerűen tárolhat egy konfigurációt vagy egy parancslistát, de a módosítások végrehajtása meglehetősen kényelmetlen. Emellett van még egy fontos feladat a tervezés során. Rendelkeznie kell a terv egészét (alacsony szintű tervezés) és a konkrét megvalósítást (hálózati megvalósítási terv) leíró dokumentációval. És ebben az esetben a sablonok használata nagyon megfelelő lehetőségnek tűnik.
Tehát a YAML és a Jinja2 használatakor egy YAML fájl konfigurációs paraméterekkel, például IP-címekkel, BGP AS számokkal, ... tökéletesen betölti a NIP szerepét, míg a Jinja2 sablonok a tervezésnek megfelelő szintaxist tartalmaznak, vagyis lényegében egy az LLD tükörképe.
Két napig tartott a YAML és a Jinja2 megtanulása. Néhány jó példa elég ahhoz, hogy megértsük, hogyan működik ez. Aztán körülbelül két hétbe telt, mire elkészítettük a tervünkhöz illő összes sablont: egy hét a Palo Alto és egy hét az F5 esetében. Mindezt a vállalati githabon tették közzé.
A változás folyamata most így nézett ki:
- megváltoztatta a YAML fájlt
- létrehozott egy konfigurációs fájlt egy sablon segítségével (Jinja2)
- távoli tárolóba mentve
- feltöltötte a létrehozott konfigurációt a berendezésre
- Hibát láttam
- megváltoztatta a YAML fájlt vagy a Jinja2 sablont
- létrehozott egy konfigurációs fájlt egy sablon segítségével (Jinja2)
- ...
Nyilvánvaló, hogy eleinte sok időt fordítottak a szerkesztésekre, de egy-két hét múlva ez már ritkaságszámba ment.
Jó teszt és lehetőség volt minden hibakeresésre az ügyfél azon vágya, hogy megváltoztassák az elnevezési konvenciót. Akik az F5-tel dolgoztak, megértik a helyzet pikantériáját. De számomra minden nagyon egyszerű volt. Megváltoztattam a neveket a YAML fájlban, töröltem a teljes konfigurációt a berendezésből, generáltam egy újat és feltöltöttem. Minden, beleértve a hibajavításokat is, 4 napig tartott: két napig minden technológia esetében. Ezt követően készen álltam a következő szakaszra, nevezetesen a DEV és a Staging adatközpontok létrehozására.
Fejlesztő és rendezés
A színpadra állítás valójában teljesen megismétli a gyártást. A Dev egy erősen lecsupaszított példány, amely főként virtuális hardverre épül. Ideális helyzet egy új megközelítéshez. Ha elkülönítem az eltöltött időt a teljes folyamattól, akkor szerintem a munka nem tartott tovább 2 hétnél. A fő idő a másik oldalra való várakozás és a közös problémakeresés. A harmadik fél megvalósítása szinte észrevétlen maradt mások számára. Még arra is volt idő, hogy tanuljak valamit, és írjak pár cikket Habréról :)
Összefoglalva
Szóval, mi van az alsó sorban?
- A konfiguráció megváltoztatásához csak egy egyszerű, világosan strukturált YAML fájlt kell módosítanom konfigurációs paraméterekkel. Soha nem változtatom meg a python szkriptet, és nagyon ritkán (csak ha hiba van) módosítom a Jinja2 heatlate
- Dokumentációs szempontból ez szinte ideális helyzet. Megváltoztatja a dokumentációt (a YAML fájlok NIP-ként szolgálnak), és feltölti ezt a konfigurációt a berendezésre. Így a dokumentáció mindig naprakész
Mindez oda vezetett, hogy
- a hibaarány majdnem 0-ra csökkent
- A rutin 90 százaléka eltűnt
- a megvalósítás sebessége jelentősen megnőtt
PAY, F5Y, ACY
Azt mondtam, hogy néhány példa elég ahhoz, hogy megértsük, hogyan működik.
Íme egy rövid (és persze módosított) változata annak, ami munkám során született.
= bevetés Palo Alto from Yaml = Palo Alto a Yaml-tól
= bevetés F5 ból ből Yaml = F5 ból ből Yaml (hamarosan)
= bevetés ACén -tól Yaml = F5 ból ből Yjr
Hozzáteszek néhány szót az ACY-ről (nem tévesztendő össze az ACI-vel).
Akik dolgoztak már az ACI-vel, tudják, hogy ezt a csodát (és jó értelemben véve is) biztosan nem hálózatépítők alkották :). Felejts el mindent, amit a hálózatról tudott – nem lesz hasznos az Ön számára!
Kicsit eltúlzott, de nagyjából azt az érzést közvetíti, amit az elmúlt 3 évben folyamatosan átélek az ACI-vel való együttműködés során.
És ebben az esetben az ACY nem csak lehetőséget ad egy változásvezérlési folyamat felépítésére (ami különösen fontos az ACI esetében, mert állítólag ez az adatközpont központi és legkritikusabb része), hanem felhasználóbarát felület a konfiguráció létrehozásához.
A projekt mérnökei az Excel segítségével konfigurálják az ACI-t a YAML helyett, pontosan ugyanezekre a célokra. Az Excel használatának természetesen vannak előnyei:
- a NIP egy fájlban
- gyönyörű jelek, amelyekre az ügyfél kellemesen néz
- használhat néhány excel eszközt
De van egy mínusz, és véleményem szerint ez meghaladja az előnyöket. A változások kontrollálása és a csapatmunka koordinálása sokkal nehezebbé válik.
Az ACY valójában ugyanazon megközelítések alkalmazása, amelyeket a harmadik félnél használtam az ACI konfigurálásához.
Forrás: will.com