Dit artikel is het zesde in de serie ‘Hoe u de controle over uw netwerkinfrastructuur overneemt’. De inhoud van alle artikelen in de serie en links zijn te vinden .
Nadat ik verschillende onderwerpen achter me had gelaten, besloot ik een nieuw hoofdstuk te beginnen.
Op de beveiliging kom ik later terug. Hier wil ik een eenvoudige maar effectieve aanpak bespreken, waarvan ik zeker weet dat deze, in een of andere vorm, voor velen nuttig kan zijn. Dit is meer een kort verhaal over hoe automatisering het leven van een ingenieur kan veranderen. We zullen het hebben over het gebruik van sjablonen. Aan het einde staat een lijst met mijn projecten waarin je kunt zien hoe alles wat hier wordt beschreven werkt.
DevOps voor het netwerk
Een configuratie maken met een script, GIT gebruiken om wijzigingen in de IT-infrastructuur aan te sturen, ‘uploaden’ op afstand – deze ideeën komen op de eerste plaats als je nadenkt over de technische implementatie van de DevOps-aanpak. De voordelen liggen voor de hand. Maar helaas zijn er ook nadelen.
Toen ruim vijf jaar geleden onze ontwikkelaars bij ons, de netwerkers, kwamen met deze voorstellen, waren we niet blij.
Ik moet zeggen dat we een nogal bont netwerk hebben geërfd, bestaande uit apparatuur van ongeveer tien verschillende leveranciers. Het was handig om sommige dingen via onze favoriete cli te configureren, maar bij andere gebruikten we liever de GUI. Bovendien heeft het lange werk aan ‘live’ apparatuur ons geleerd om realtime controle te hebben. Als ik bijvoorbeeld wijzigingen aanbreng, voel ik me veel comfortabeler als ik rechtstreeks via de cli werk. Zo kan ik snel zien dat er iets mis is gegaan en de wijzigingen terugdraaien. Dit alles was enigszins in tegenspraak met hun ideeën.
Er rijzen ook andere vragen: de interface kan bijvoorbeeld enigszins veranderen van versie tot versie van de software. Dit zal er uiteindelijk voor zorgen dat uw script de verkeerde "config" aanmaakt. Ik zou de productie niet willen gebruiken voor ‘inlopen’.
Of hoe kunt u begrijpen dat de configuratieopdrachten correct zijn toegepast en wat u moet doen in geval van een fout?
Ik wil niet zeggen dat al deze problemen onoplosbaar zijn. Gewoon ‘A’ zeggen is waarschijnlijk ook zinvol om ‘B’ te zeggen, en als je dezelfde processen voor veranderingsbeheer wilt gebruiken als bij ontwikkeling, dan heb je naast productie ook ontwikkel- en staging-omgevingen nodig. Dan lijkt deze aanpak compleet. Maar hoeveel gaat het kosten?
Maar er is één situatie waarin de nadelen praktisch zijn geëgaliseerd en alleen de voordelen overblijven. Ik heb het over ontwerpwerk.
Project
De afgelopen twee jaar heb ik meegewerkt aan een project om een datacenter te bouwen voor een grote provider. In dit project ben ik verantwoordelijk voor F5 en Palo Alto. Vanuit Cisco's standpunt is dit “apparatuur van derden”.
Voor mij persoonlijk zijn er twee verschillende fasen in dit project.
Eerste fase
Het eerste jaar was ik eindeloos bezig, ik werkte nachten en weekenden. Ik kon mijn hoofd niet opheffen. De druk van het management en de klant was groot en voortdurend. In een constante routine kon ik niet eens proberen het proces te optimaliseren. Het ging niet alleen om de configuratie van apparatuur, maar ook om de voorbereiding van ontwerpdocumentatie.
De eerste tests zijn begonnen en ik zou verbaasd zijn hoeveel kleine fouten en onnauwkeurigheden er werden gemaakt. Natuurlijk werkte alles, maar er ontbrak een letter in de naam, er ontbrak een regel in het commando... De tests gingen maar door en ik had al een constante, dagelijkse strijd met fouten, tests en documentatie .
Dit duurde een jaar. Het project was, voor zover ik het begrijp, niet voor iedereen gemakkelijk, maar geleidelijk aan werd de klant steeds tevredener en dit maakte het mogelijk om extra ingenieurs in te huren die een deel van de routine zelf op zich konden nemen.
Nu konden we een beetje rondkijken.
En dit was het begin van de tweede fase.
Fase twee
Ik besloot het proces te automatiseren.
Wat ik destijds begreep uit mijn communicatie met de ontwikkelaars (en we moeten hulde brengen, we hadden een sterk team) is dat het tekstformaat, hoewel op het eerste gezicht iets uit de wereld van het DOS-besturingssysteem lijkt, een aantal van waardevolle eigendommen.
Het tekstformaat zal dus bijvoorbeeld handig zijn als u optimaal wilt profiteren van GIT en al zijn afgeleiden. En ik wilde het.
Het lijkt erop dat je eenvoudig een configuratie of een lijst met opdrachten kunt opslaan, maar wijzigingen aanbrengen is behoorlijk lastig. Daarnaast is er nog een belangrijke taak tijdens het ontwerp. U dient over documentatie te beschikken die uw ontwerp als geheel (Low Level Design) en specifieke implementatie (Network Implementation Plan) beschrijft. En in dit geval lijkt het gebruik van sjablonen een zeer geschikte optie.
Dus bij gebruik van YAML en Jinja2 vervult een YAML-bestand met configuratieparameters zoals IP-adressen, BGP AS-nummers, ... perfect de rol van NIP, terwijl Jinja2-sjablonen de syntaxis bevatten die overeenkomt met het ontwerp, dat wil zeggen dat het in wezen een weerspiegeling van LLD.
Het kostte twee dagen om YAML en Jinja2 te leren. Een paar goede voorbeelden zijn voldoende om te begrijpen hoe dit werkt. Vervolgens duurde het ongeveer twee weken om alle sjablonen te maken die bij ons ontwerp pasten: een week voor Palo Alto en nog een week voor F5. Dit alles werd op corporate githab gepost.
Het veranderingsproces zag er nu als volgt uit:
- het YAML-bestand gewijzigd
- een configuratiebestand gemaakt met behulp van een sjabloon (Jinja2)
- opgeslagen in een externe opslagplaats
- heeft de gemaakte configuratie naar de apparatuur geüpload
- Ik zag een fout
- het YAML-bestand of de Jinja2-sjabloon gewijzigd
- een configuratiebestand gemaakt met behulp van een sjabloon (Jinja2)
- ...
Het is duidelijk dat er in eerste instantie veel tijd aan montages werd besteed, maar na een week of twee werd dit eerder een zeldzaamheid.
Een goede test en mogelijkheid om alles te debuggen was de wens van de klant om de naamgevingsconventie te veranderen. Degenen die met F5 hebben gewerkt, begrijpen het pikante van de situatie. Maar voor mij was het allemaal heel simpel. Ik heb de namen in het YAML-bestand gewijzigd, de volledige configuratie van de apparatuur verwijderd, een nieuwe gegenereerd en deze geüpload. Alles, inclusief bugfixes, duurde vier dagen: twee dagen voor elke technologie. Daarna was ik klaar voor de volgende fase, namelijk het opzetten van DEV- en Staging-datacenters.
Ontwikkelaar en staging
Staging repliceert eigenlijk de productie volledig. Dev is een zwaar uitgeklede kopie die voornamelijk op virtuele hardware is gebouwd. Een ideale situatie voor een nieuwe aanpak. Als ik de tijd die ik heb besteed los van het totale proces, denk ik dat het werk niet meer dan twee weken duurde. De belangrijkste tijd is wachten op de andere kant en samen op zoek gaan naar problemen. De implementatie van 2rd party bleef vrijwel onopgemerkt door anderen. Er was zelfs tijd om iets te leren en een paar artikelen over Habré te schrijven :)
Samenvattend
Dus, wat heb ik onderaan de streep?
- Het enige dat ik hoef te doen om de configuratie te wijzigen, is een eenvoudig, duidelijk gestructureerd YAML-bestand met configuratieparameters wijzigen. Ik verander nooit het Python-script en zeer zelden (alleen als er een fout is) verander ik de Jinja2-heatlate
- Vanuit documentatieoogpunt is dit een vrijwel ideale situatie. Je wijzigt de documentatie (YAML-bestanden dienen als NIP) en uploadt deze configuratie naar de apparatuur. Zo is uw documentatie altijd up-to-date
Dit alles leidde tot het feit dat
- het foutenpercentage is gedaald tot bijna 0
- 90 procent van de routine is verdwenen
- de snelheid van implementatie is aanzienlijk toegenomen
BETALEN, F5Y, ACY
Ik zei dat een paar voorbeelden voldoende zijn om te begrijpen hoe het werkt.
Hier is een korte (en uiteraard aangepaste) versie van wat er tijdens mijn werk is ontstaan.
= inzet Phallo AVan Yaml = Palo Alto van Yaml
= inzet F5 oppompen van Yam = F5 oppompen van Yaml (binnenkort beschikbaar)
= inzet ACik van Yam = F5 oppompen van Yaml
Ik zal een paar woorden toevoegen over ACY (niet te verwarren met ACI).
Degenen die met ACI hebben gewerkt, weten dat dit wonder (en op een goede manier ook) zeker niet door netwerkers is gecreëerd :). Vergeet alles wat u over het netwerk wist - het zal niet nuttig voor u zijn!
Het is een beetje overdreven, maar het geeft grofweg het gevoel weer dat ik de afgelopen drie jaar voortdurend ervaar bij het werken met ACI.
En in dit geval is ACY niet alleen een kans om een change control-proces op te bouwen (wat vooral belangrijk is in het geval van ACI, omdat dit het centrale en meest kritische onderdeel van uw datacenter zou moeten zijn), maar het geeft u ook een gebruiksvriendelijke interface voor het maken van configuraties.
De ingenieurs van dit project gebruiken Excel om ACI in plaats van YAML voor precies dezelfde doeleinden te configureren. Er zijn uiteraard voordelen aan het gebruik van Excel:
- uw NIP in één bestand
- mooie borden die prettig zijn voor de klant om naar te kijken
- je kunt een aantal Excel-tools gebruiken
Maar er is één minpuntje, en naar mijn mening weegt dit zwaarder dan de voordelen. Het beheersen van veranderingen en het coördineren van teamwerk wordt veel moeilijker.
ACY is eigenlijk een toepassing van dezelfde aanpak die ik voor de derde partij heb gebruikt om ACI te configureren.
Bron: www.habr.com