Ta článek je šestý v cyklu článků „Jak dostat síťovou infrastrukturu pod svou kontrolu“. Obsah všech článků cyklu a odkazy naleznete .
Po opuštění několika témat jsem se rozhodl přece jen začít novou kapitolu.
K bezpečnosti se vrátím později. Zde chci prodiskutovat jeden jednoduchý, ale efektivní přístup, který, jsem si jistý, se v tak či onak 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. Řeč bude o používání šablon. Na konci přikládám 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žití GITu pro kontrolu změn IT infrastruktury, vzdálené nahrávání – tyto myšlenky přicházejí na první místo, 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 přišli naši vývojáři za námi, síťaři, s těmito návrhy, nebyli jsme nadšeni.
Musím říct, že jsme zdědili docela pestrobarevnou síť složenou z vybavení přibližně 10 různých dodavatelů. Něco bylo pohodlné konfigurovat přes náš oblíbený cli, ale někde jsme preferovali používat GUI. Kromě toho nás dlouhá práce na „živém“ vybavení naučila řídit se v reálném čase. Například při provádění změn se cítím mnohem pohodlněji, když pracuji přímo přes cli. Tak mohu rychle vidět, že něco není v pořádku a „vrátit“ změny. To vše bylo v jistém rozporu s jejich nápady.
Objevují se i další otázky, například, že rozhraní se může od verze k verzi softwaru mírně změnit. To nakonec povede k tomu, že váš skript vytvoří nesprávnou „konfigurační“ soubor. Nechtěl bych používat produkční prostředí pro „testování“.
Nebo, jak pochopit, že konfigurační příkazy byly aplikovány správně a co dělat v případě chyby?
Nechci říct, že všechny tyto otázky jsou neřešitelné. Prostě říci „A“, pravděpodobně rozumně znamená říct i „B“, a pokud chcete používat stejné procesy pro kontrolu změn jako při vývoji, musíte mít kromě produkčního prostředí také dev a staging prostředí. Pak tento přístup vypadá dokončeně. Ale kolik to bude stát?
Vendar obstaja ena situacija, ko se slabosti praktično izničijo, in ostanejo le prednosti. Govorim o projektnih delih.
Projekt
V zadnjih dveh letih sem sodeloval v projektu gradnje podatkovnega centra za enega velikega ponudnika. V tem projektu sem odgovoren za F5 in Palo Alto. V smislu Cisco je to „oprema tretjih oseb“.
Zame osebno obstajata dve jasno izraženi fazi v tem projektu.
Prva faza
Prvo leto sem bil neskončno zaposlen, delal sem ponoči in ob koncih tedna. Nisem mogel dvigniti glave. Pritisk s strani menedžmenta in naročnika je bil močan in neprekinjen. V stalni rutini nisem mogel niti poskusiti optimizirati procesa. To ni bilo zgolj konfiguriranje opreme, temveč tudi priprava projektne dokumentacije.
Tukaj so se začeli prvi testi, in bil sem osupel, koliko manjših napak in netočnosti je bilo narejenih. Seveda je vse delovalo, ampak tam je manjkala črka v imenu, tukaj je bila izpuščena vrstica v ukazu… Testi so se nadaljevali in nadaljevali, in že sem bil v stalni, vsakodnevni borbi z napakami, testi in dokumentacijo.
To je trajalo eno leto. Projekt, kolikor razumem, ni bil enostaven za vse, vendar je postopoma naročnik postal vse bolj zadovoljen, kar je omogočilo, da smo pridobili dodatne inženirje, ki so lahko prevzeli del rutinskega dela.
Zdaj je bilo mogoče nekoliko pogledati okoli sebe.
In to je bilo začetek druge faze.
Druga faza
Odločil sem se, da avtomatiziram proces.
Kar sem razumel iz takratne komunikacije z razvijalci (in treba je priznati, imeli smo močno ekipo), je to, da je besedilni format, čeprav se na prvi pogled zdi nekaj iz sveta operacijskega sistema DOS, v resnici zelo koristen.
Na primer, besedilni format bo koristen, če želite v celoti izkoristiti prednosti GIT-a in vseh njegovih derivatov. In to sem želel.
No, zdelo bi se, da lahko preprosto shranite konfiguracijo ali seznam ukazov, vendar je spreminjanje precej neprijetno. Poleg tega pri načrtovanju obstaja še en pomemben cilj. Imate morati dokumentacijo, ki opisuje vašo zasnovo kot celoto (Low Level Design) in konkretno implementacijo (Network Implementation Plan). V tem primeru se zdi uporaba šablon kot zelo primerna rešitev.
Tako, pri uporabi YAML in Jinja2, YAML datoteka s konfiguracijskimi parametri, kot so IP naslovi, številke BGP AS,… odlično opravlja vlogo NIP, medtem ko Jinja2 predloge vključujejo sintakso, ustrezno zasnovi, kar pomeni, da v bistvu odraža LLD.
Učenje jezikov YAML in Jinja2 je trajalo dva dni. Da bi razumeli, kako to deluje, je dovolj nekaj dobrih primerov. Nato je približno dva tedna trajalo, da smo ustvarili vse predloge, ki ustrezajo naši zasnovi: en teden za Palo Alto in še en teden — za F5. Vse to je bilo objavljeno na korporativnem githabu.
Zdaj je proces sprememb izgledal takole:
- spremenil sem YAML datoteko
- ustvaril sem konfiguracijsko datoteko s pomočjo predloge (Jinja2)
- shranil v oddaljen repozitorij
- naložil ustvarjeno konfiguracijo na opremo
- videl sem napako
- spremenil sem YAML datoteko ali Jinja2 predlogo
- ustvaril sem konfiguracijsko datoteko s pomočjo predloge (Jinja2)
- …
Očitno je, da je sprva veliko časa odšlo za popravke, vendar je to po enem do dveh tednih postalo precej redkokot.
Dobra preizkušnja in možnost za vse odpraviti je bila želja stranke, da spremeni naming convention. Tisti, ki so delali s F5, razumejo zapletenost situacije. Vendar je bilo zame vse dokaj preprosto. Spremenil sem imena v YAML datoteki, izbrisal vso konfiguracijo z opreme, ustvaril novo in jo naložil. Vse skupaj, ob upoštevanju popravkov napak, je trajalo 4 dni: po dva dni na vsako tehnologijo. Po tem sem bil pripravljen na naslednjo fazo, in sicer ustvarjanje DEV in Staging podatkovnih centrov.
Dev in Staging
Staging dejansko popolnoma ponavlja produkcijo. Dev je močno okrajšana in predvsem zgrajena na virtualni opremi kopija. Idealna situacija za uporabo novega pristopa. Če iz skupnega procesa izločimo čas, ki sem ga porabil, menim, da dela niso trajala več kot 2 tedna. Glavni čas je čas čakanja druge strani in skupno iskanje težav. Implementacija 3rd party je potekala skoraj neopaženo za okolico. Dovolj časa je bilo celo za učenje in pisanje nekaj člankov na Habré 🙂
Sklepamo
Torej, kaj imam na koncu?
- vse, kar potrebujem za spremembo konfiguracije — spremeniti preprosto, jasno strukturirano YAML datoteko s konfiguracijskimi parametri. Nikoli ne spreminjam python skripte in zelo redko (samo če je napaka) spremenim Jinja2 predlogo.
- Z vidika dokumentacije se skoraj idealna situacija. Spremenite dokumentacijo (datoteke YAML igrajo vlogo NIP) in naložite to konfiguracijo na opremo. Na ta način je vaša dokumentacija vedno posodobljena.
Vse to je privedlo do tega, da
- je odstotek napak praktično padel na 0.
- je 90 odstotkov rutinskih nalog izginilo.
- se je hitrost uvedbe močno povečala.
PAY, F5Y, ACY
Rekel sem, da je nekaj primerov dovolj, da razumete, kako to deluje.
Tukaj je kratka (in seveda spremenjena) različica tistega, kar je bilo ustvarjeno v procesu mojega dela.
= uvajanje Palo Alto iz Yaml = Palo Alto iz Yaml
= uvajanje F5 from Yaml = F5 from Yaml (kmalu bo na voljo)
= uvajanje ACi iz Yaml = F5 from Yaml
Dodal bom nekaj besed o ACY (ne zamenjati z ACI).
Tisti, ki so delali z ACI vedo, da je to čudež (in v dobrem smislu tudi) bilo ustvarjeno zagotovo ne s strani omrežnih strokovnjakov :). Pozabite vse, kar ste vedeli o omrežju — to vam ne bo koristilo!
Malo pretirano, a približno prenaša občutek, ki ga nenehno doživljam, že 3 leta, ko delam z ACI.
In v tem primeru je ACY ne le možnost, da zgradite proces nadzora sprememb (kar je še posebej pomembno v primeru ACI, ker se predvideva, da je to osrednji in najbolj kritičen del vašega podatkovnega centra), ampak vam omogoča tudi prijazen vmesnik za ustvarjanje konfiguracije.
Inženirji v tem projektu za konfiguracijo ACI namesto YAML za enake cilje uporabljajo Excel. V uporabi Excela, seveda, so prednosti:
- vaš NIP v eni datoteki
- lepe tabele, ki jih je prijetno videti stranki
- lahko uporabite nekatere Excel pripomočke
Toda obstaja ena pomanjkljivost, ki po mojem mnenju odtehta prednosti. Nadzor nad spremembami in usklajevanje dela ekipe postane veliko bolj zapleteno.
ACY je dejansko uporaba enakih pristopov, ki sem jih uporabil za 3rd party, za konfiguracijo ACI.
Izvor: habr.com
