Hierdie artikel is die sesde in die reeks "Hoe om beheer oor jou netwerkinfrastruktuur te neem." Die inhoud van alle artikels in die reeks en skakels kan gevind word .
Nadat ek verskeie onderwerpe agtergelaat het, het ek besluit om 'n nuwe hoofstuk te begin.
Ek kom bietjie later terug na sekuriteit. Hier wil ek een eenvoudige maar effektiewe benadering bespreek, wat ek seker is, in een of ander vorm, vir baie nuttig kan wees. Dit is meer 'n kortverhaal oor hoe outomatisering die lewe van 'n ingenieur kan verander. Ons sal praat oor die gebruik van sjablone. Aan die einde is daar 'n lys van my projekte waar jy kan sien hoe alles wat hier beskryf word werk.
DevOps vir die netwerk
Skep 'n konfigurasie met 'n skrip, gebruik GIT om veranderinge aan die IT-infrastruktuur te beheer, afstand "oplaai" - hierdie idees kom eerste wanneer jy dink aan die tegniese implementering van die DevOps-benadering. Die voordele is voor die hand liggend. Maar daar is ongelukkig ook nadele.
Toe ons ontwikkelaars meer as 5 jaar gelede na ons, die netwerkers, met hierdie voorstelle gekom het, was ons nie verheug nie.
Ek moet sê dat ons 'n taamlik bont netwerk geërf het, bestaande uit toerusting van ongeveer 10 verskillende verskaffers. Dit was gerieflik om sommige dinge deur ons gunsteling cli op te stel, maar in ander het ons verkies om die GUI te gebruik. Daarbenewens het lang werk aan "lewendige" toerusting ons geleer om intydse beheer te hê. Byvoorbeeld, wanneer ek veranderinge maak, voel ek baie meer gemaklik om direk deur die cli te werk. Op hierdie manier kan ek vinnig sien dat iets verkeerd geloop het en die veranderinge terugrol. Dit alles was in 'n mate in teenstrydigheid met hul idees.
Ander vrae ontstaan ook, byvoorbeeld, die koppelvlak kan effens verander van weergawe tot weergawe van die sagteware. Dit sal uiteindelik veroorsaak dat jou script die verkeerde "config" skep. Ek sal nie graag produksie wil gebruik vir “inhardloop” nie.
Of hoe om te verstaan dat die konfigurasie-opdragte korrek toegepas is en wat om te doen in die geval van 'n fout?
Ek wil nie sê dat al hierdie kwessies onoplosbaar is nie. Om net "A" te sê, maak waarskynlik sin om ook "B" te sê, en as jy dieselfde prosesse vir veranderingsbeheer wil gebruik as in ontwikkeling, moet jy bykomend tot produksie ook ontwikkelaar- en staging-omgewings hê. Dan lyk hierdie benadering volledig. Maar hoeveel sal dit kos?
Maar daar is een situasie wanneer die nadele prakties gelykgemaak word, en net die voordele bly oor. Ek praat van ontwerpwerk.
Project
Vir die laaste twee jaar neem ek deel aan 'n projek om 'n datasentrum vir 'n groot verskaffer te bou. Ek is verantwoordelik vir F5 en Palo Alto in hierdie projek. Uit Cisco se oogpunt is dit “derdepartytoerusting”.
Vir my persoonlik is daar twee verskillende stadiums in hierdie projek.
Eerste fase
Die eerste jaar was ek eindeloos besig, ek het nagte en naweke gewerk. Ek kon nie my kop lig nie. Die druk van die bestuur en die kliënt was sterk en deurlopend. In 'n konstante roetine kon ek nie eers probeer om die proses te optimaliseer nie. Dit was nie net en nie soseer die konfigurasie van toerusting as die voorbereiding van ontwerpdokumentasie nie.
Die eerste toetse het begin, en ek sal verbaas wees oor hoeveel klein foute en onakkuraathede gemaak is. Alles het natuurlik gewerk, maar daar ontbreek 'n letter in die naam, daar ontbreek 'n reël in die opdrag... Die toetse het aangehou en aangehou, en ek was reeds in 'n konstante, daaglikse stryd met foute, toetse en dokumentasie .
Dit het vir 'n jaar aangehou. Die projek, sover ek verstaan, was nie vir almal maklik nie, maar gaandeweg het die kliënt meer en meer tevrede geraak, en dit het dit moontlik gemaak om bykomende ingenieurs aan te stel wat self 'n deel van die roetine kon aanneem.
Nou kon ons bietjie rondkyk.
En dit was die begin van die tweede fase.
Stadium twee
Ek het besluit om die proses te outomatiseer.
Wat ek verstaan het uit my kommunikasie met die ontwikkelaars op daardie stadium (en ons moet hulde bring, ons het 'n sterk span gehad) is dat die teksformaat, alhoewel met die eerste oogopslag na iets uit die wêreld van die DOS-bedryfstelsel lyk, 'n nommer het van waardevolle eiendomme.
So, byvoorbeeld, die teksformaat sal nuttig wees as jy ten volle wil voordeel trek uit GIT en al sy afgeleides. En ek wou.
Wel, dit wil voorkom asof u eenvoudig 'n konfigurasie of 'n lys opdragte kan stoor, maar om veranderinge te maak is redelik ongerieflik. Daarbenewens is daar nog 'n belangrike taak tydens ontwerp. Jy moet dokumentasie hê wat jou ontwerp as geheel beskryf (Laevlakontwerp) en spesifieke implementering (Netwerkimplementeringsplan). En in hierdie geval lyk die gebruik van sjablone na 'n baie geskikte opsie.
Dus, wanneer YAML en Jinja2 gebruik word, vervul 'n YAML-lêer met konfigurasieparameters soos IP-adresse, BGP AS-nommers, ... perfek die rol van NIP, terwyl Jinja2-sjablone sintaksis insluit wat ooreenstem met die ontwerp, dit wil sê, dit is in wese 'n weerspieëling van LLD.
Dit het twee dae geneem om YAML en Jinja2 te leer. 'n Paar goeie voorbeelde is genoeg om te verstaan hoe dit werk. Toe het dit ongeveer twee weke geneem om al die sjablone te skep wat by ons ontwerp pas: 'n week vir Palo Alto en nog 'n week vir F5. Dit alles is op korporatiewe githab geplaas.
Nou het die veranderingsproses soos volg gelyk:
- het die YAML-lêer verander
- het 'n konfigurasielêer geskep met 'n sjabloon (Jinja2)
- gestoor in 'n afgeleë bewaarplek
- het die geskepte konfigurasie na die toerusting opgelaai
- Ek het 'n fout gesien
- het die YAML-lêer of Jinja2-sjabloon verander
- het 'n konfigurasielêer geskep met 'n sjabloon (Jinja2)
- ...
Dit is duidelik dat daar eers baie tyd aan redigering bestee is, maar na 'n week of twee het dit nogal 'n rariteit geword.
'n Goeie toets en geleentheid om alles te ontfout was die kliënt se begeerte om die naamkonvensie te verander. Diegene wat met F5 gewerk het, verstaan die pikantheid van die situasie. Maar vir my was dit alles redelik eenvoudig. Ek het die name in die YAML-lêer verander, die hele konfigurasie van die toerusting uitgevee, 'n nuwe een gegenereer en dit opgelaai. Alles, insluitend foutoplossings, het 4 dae geneem: twee dae vir elke tegnologie. Daarna was ek gereed vir die volgende fase, naamlik die skepping van DEV en Staging datasentrums.
Dev en Staging
Staging herhaal eintlik produksie heeltemal. Dev is 'n sterk gestroopte kopie wat hoofsaaklik op virtuele hardeware gebou is. 'n Ideale situasie vir 'n nuwe benadering. As ek die tyd wat ek spandeer het van die algehele proses isoleer, dan dink ek die werk het nie meer as 2 weke geneem nie. Die hooftyd is om vir die ander kant te wag en saam na probleme te soek. Die implementering van 3de party het byna ongemerk deur ander gegaan. Daar was selfs tyd om iets te leer en 'n paar artikels oor Habré te skryf :)
om op te som
So, wat het ek in die onderste lyn?
- Al wat ek hoef te doen om die konfigurasie te verander, is om 'n eenvoudige, duidelik gestruktureerde YAML-lêer met konfigurasieparameters te verander. Ek verander nooit die luislangskrif nie en baie selde (slegs as daar 'n fout is) verander ek die Jinja2 heatlate
- Vanuit 'n dokumentasie-oogpunt is dit 'n byna ideale situasie. Jy verander die dokumentasie (YAML-lêers dien as NIP) en laai hierdie konfigurasie op na die toerusting. Op hierdie manier is jou dokumentasie altyd op datum
Dit alles het daartoe gelei dat
- die foutkoers het tot amper 0 gedaal
- 90 persent van die roetine is weg
- die spoed van implementering het aansienlik toegeneem
PAY, F5Y, ACY
Ek het gesê dat 'n paar voorbeelde genoeg is om te verstaan hoe dit werk.
Hier is 'n kort (en natuurlik gewysigde) weergawe van wat tydens my werk geskep is.
= ontplooiing Palo Alto van Yaml = Palo Alto van Yaml
= ontplooiing F5 van Yaml = F5 van Yaml (binnekort beskikbaar)
= ontplooiing ACek van Yaml = F5 van YJR
Ek sal 'n paar woorde oor ACY byvoeg (nie te verwar met ACI nie).
Diegene wat met ACI gewerk het, weet dat hierdie wonderwerk (en op 'n goeie manier ook) beslis nie deur netwerkers geskep is nie :). Vergeet alles wat jy van die netwerk geweet het – dit sal nie vir jou nuttig wees nie!
Dit is 'n bietjie oordrewe, maar dit dra rofweg die gevoel oor dat ek die afgelope 3 jaar voortdurend met ACI werk.
En in hierdie geval is ACY nie net 'n geleentheid om 'n veranderingsbeheerproses te bou nie (wat veral belangrik is in die geval van ACI, want dit is veronderstel om die sentrale en mees kritieke deel van jou datasentrum te wees), maar gee jou ook 'n gebruikersvriendelike koppelvlak vir die skep van konfigurasie.
Die ingenieurs op hierdie projek gebruik Excel om ACI in plaas van YAML op te stel vir presies dieselfde doeleindes. Daar is natuurlik voordele verbonde aan die gebruik van Excel:
- jou NIP in een lêer
- pragtige tekens wat vir die kliënt aangenaam is om na te kyk
- jy kan 'n paar Excel-instrumente gebruik
Maar daar is een minus, en na my mening weeg dit swaarder as die voordele. Om veranderinge te beheer en spanwerk te koördineer word baie moeiliker.
ACY is eintlik 'n toepassing van dieselfde benaderings wat ek vir die derde party gebruik het om ACI op te stel.
Bron: will.com