Denne artikel er den sjette i en serie af artikler "Sådan får du kontrol over dit netværksinfrastruktur". Indholdet af alle artikler i serien og links findes .
Efter at have forladt nogle emner bag mig, besluttede jeg mig for alligevel at starte et nyt kapitel.
Jeg vil vende tilbage til sikkerheden lidt senere. Her vil jeg diskutere en simpel, men effektiv tilgang, som jeg er overbevist om, at mange kan have glæde af i en eller anden form. Dette er snarere en kort historie om, hvordan automatisering kan ændre livet for en ingeniør. Det handler om brugen af skabeloner. Til sidst præsenteres en liste over mine projekter, hvor man kan se, hvordan alt dette fungerer.
DevOps for netværk
Oprettelse af konfiguration med skript, brug af GIT til at kontrollere ændringer i IT-infrastrukturen, fjern "upload" — disse ideer kommer først i tankerne, når man overvejer den tekniske implementering af DevOps-tilgangen. Fordelene er åbenlyse. Men desværre er der også ulemper.
Da vores udviklere for mere end 5 år siden kom til os netværksfolk med disse forslag, var vi ikke begejstrede.
Det skal siges, at vi arvede et ret broget netværk, bestående af udstyr fra cirka 10 forskellige leverandører. Nogle ting var nemme at konfigurere via vores elskede CLI, men andre steder foretrak vi at bruge GUI. Desuden havde langvarigt arbejde på "live" udstyr vant os til realtidskontrol. Jeg føler mig for eksempel meget mere komfortabel med at arbejde direkte via CLI, mens jeg foretager ændringer. Så kan jeg hurtigt se, hvis noget gik galt, og "rulle" ændringerne tilbage. Alt dette stod i en vis modstrid med deres ideer.
Der opstår også andre spørgsmål, for eksempel kan grænsefladen ændre sig lidt fra version til version af softwaren. Dette vil i sidste ende føre til, at dit skript skaber en forkert "konfig". Det ville være uheldigt at bruge produktionen til "testning".
Eller, hvordan kan man forstå, at konfigurationskommandoerne blev anvendt korrekt, og hvad gør man i tilfælde af fejl?
Jeg vil ikke sige, at alle disse spørgsmål er uopløselige. Bare at sige "A" er nok fornuftigt at sige "B" også, og hvis du vil bruge de samme processer til ændringskontrol som i udviklingen, skal du have, udover produktionen, også dev- og staging-miljøer. Så ser denne tilgang komplet ud. Men hvad vil det koste?
Men der er én situation, hvor ulemperne næsten udlignes, og der kun er fordele tilbage. Jeg taler om projektarbejde.
Projekt
I de seneste to år har jeg deltaget i et projekt om opbygning af et datacenter for en stor udbyder. Jeg er ansvarlig for F5 og Palo Alto i dette projekt. Set fra Cisco's perspektiv er det "3rd party equipment".
Personligt er der to klart definerede faser i dette projekt.
Første fase
I det første år var jeg uendeligt optaget; jeg arbejdede om natten og i weekenderne. Jeg kunne ikke løfte hovedet. Presset fra ledelsen og kunden var stærkt og vedvarende. I den konstante rutine kunne jeg ikke engang forsøge at optimere processen. Det handlede ikke kun om at konfigurere udstyr, men også om at udarbejde projektdokumentation.
Her begyndte de første tests, og jeg var chokeret over, hvor mange små fejl og unøjagtigheder der var blevet begået. Selvfølgelig fungerede alt, men der manglede et bogstav i en betegnelse, her manglede en linje i kommandoen... Testene fortsatte og fortsatte, og jeg var allerede i en konstant, daglig kamp med fejl, tests og dokumentation.
Sådan fortsatte det i et år. Projektet, så vidt jeg forstår, var ikke let for alle, men gradvist blev kunden mere og mere tilfreds, og det gav mulighed for at tage ekstra ingeniører ind, som kunne tage en del af rutinen på sig.
Nu kunne man se sig omkring.
Og det var starten på den anden fase.
Anden fase
Jeg besluttede at automatisere processen.
Det jeg forstod fra dengang, jeg kommunikerede med udviklerne (og man må sige, at vi havde et stærkt team), var, at tekstformatet, selvom det ved første øjekast virker som noget fra DOS-systemets verden, har en række værdifulde egenskaber.
For eksempel vil tekstformatet være nyttigt, hvis du vil udnytte fordelene ved GIT og alle dens afledte. Og jeg ønskede det.
Nå, det virker som om, man blot kan gemme konfigurationen eller listen over kommandoer, men at foretage ændringer er temmelig besværligt. Desuden står man over for en vigtig opgave ved designet. Du skal have dokumentation, der beskriver dit design overordnet (Low Level Design) og den specifikke implementering (Network Implementation Plan). Og i dette tilfælde ser brugen af skabeloner ud til at være en meget passende løsning.
Så når man bruger YAML og Jinja2, fungerer YAML-filen med konfigurationsparametre som IP-adresser, BGP AS-numre osv. fremragende som en NIP, mens Jinja2-malerne indeholder syntaks, der er i overensstemmelse med designet, dvs. dybest set er en refleksion af LLD.
Det tog to dage at lære YAML- og Jinja2-sprogene. For at forstå, hvordan det virker, er det nok med nogle gode eksempler. Derefter tog det omkring to uger at oprette alle de skabeloner, der var i tråd med vores design: en uge til Palo Alto og en uge mere til F5. Alt dette blev uploadet til virksomhedens GitHub.
Nu så ændringsprocessen således ud:
- jeg ændrede YAML-filen
- jeg oprettede konfigurationsfilen ved hjælp af skabelonen (Jinja2)
- jeg gemte i det fjerntliggende repository
- jeg uploadede den oprettede konfiguration til udstyret
- jeg så en fejl
- jeg ændrede YAML-filen eller Jinja2-skabelonen
- jeg oprettede konfigurationsfilen ved hjælp af skabelonen (Jinja2)
- …
Det er klart, at i starten tog det meget tid at lave rettelser, men efter en uge eller to blev det snarere en sjældenhed.
En god test og mulighed for at debugge blev kundens ønske om at ændre naming convention. De, der har arbejdet med F5, forstår situationens kompleksitet. Men for mig var det ret simpelt. Jeg ændrede navnene i YAML-filen, slettede hele konfigurationen fra udstyret, genererede en ny og uploadede. Alt i alt, inklusive rettelser af fejl, tog det 4 dage: to dage på hver teknologi. Derefter var jeg klar til næste fase, nemlig oprettelse af DEV og Staging datacentre.
Dev og Staging
Staging gentager faktisk production næsten fuldt ud. Dev er en stærkt forkortet kopi, der primært er bygget på virtuelt udstyr. En ideel situation for at anvende den nye tilgang. Hvis man ser bort fra den tid, jeg brugte, vil jeg mene, at arbejdet ikke tog mere end 2 uger. Den mest betydelige tid var ventetid fra den anden side og fælles problemjagt. Implementeringen af 3rd party skete næsten uset for omgivelserne. Der var endda tid til at lære noget nyt og skrive et par artikler på Habr 🙂
Lad os opsummere
Så hvad har jeg i groft sammentræk?
- alt hvad jeg behøver for at ændre konfigurationen — ændre en simpel, klart struktureret YAML-fil med konfigurationsparametre. Jeg ændrer aldrig python-scriptet og meget sjældent (kun hvis der er en fejl) ændrer jeg Jinja2-skabelonen.
- Fra dokumentationens synspunkt ser det næsten perfekt ud. Du ændrer dokumentationen (YAML-filer fungerer som NIP) og uploader denne konfiguration til udstyret. Derved er din dokumentation altid opdateret.
Alt dette har ført til, at
- fejlprocenten er næsten reduceret til 0
- 90 procent af rutinerne er fjernet
- implementeringshastigheden er mangedoblet
PAY, F5Y, ACY
Jeg sagde, at nogle få eksempler er nok til at forstå, hvordan det fungerer.
Her er en kort (og selvfølgelig ændret) version af det, der blev skabt i løbet af mit arbejde.
= deployment Palo Alto fra Yaml = Palo Alto fra Yaml
= deployment F5 fra Yaml = F5 fra Yaml (kommer snart)
= deployment ACi fra Yaml = F5 fra Yaml
Jeg vil tilføje et par ord om ACY (ikke forveksle med ACI).
De, der har arbejdet med ACI, ved, at dette vidunder (og i god mening) bestemt ikke blev skabt af netværksfolk :). Glem alt, hvad du vidste om netværk — det får du ikke brug for!
Lidt overdrevet, men det fanger rimeligt den følelse, jeg konstant har haft i de sidste 3 år, mens jeg arbejder med ACI.
I dette tilfælde er ACY ikke kun muligheden for at opbygge en ændringskontrolproces (hvilket er særligt vigtigt i tilfælde af ACI, da det antages at være den centrale og mest kritiske del af dit datacenter), men giver dig også et brugervenligt interface til at oprette konfigurationer.
Ingeniørerne i dette projekt bruger Excel i stedet for YAML for at opnå de samme mål med konfiguration af ACI. Der er selvfølgelig fordele ved at bruge Excel:
- dit NIP i én fil
- smukke tabeller, der er behagelige for kunden at se på
- du kan bruge nogle Excel-værktøjer
Men der er en ulempe, og den opvejer efter min mening fordelene. At kontrollere ændringer og koordinere teamets arbejde bliver meget sværere.
ACY er faktisk anvendelsen af de samme tilgange, som jeg brugte til 3rd party, til konfiguration af ACI.
Kilde: habr.com
