Denne artikel er den sjette i serien "Sådan tager du kontrol over din netværksinfrastruktur." Indholdet af alle artikler i serien og links kan findes .
Efter at have efterladt flere emner, besluttede jeg at starte et nyt kapitel.
Jeg vender tilbage til sikkerheden lidt senere. Her vil jeg diskutere én enkel, men effektiv tilgang, som jeg er sikker på, i en eller anden form, kan være nyttig for mange. Dette er mere en kort historie om, hvordan automatisering kan ændre en ingeniørs liv. Vi vil tale om at bruge skabeloner. Til sidst er der en liste over mine projekter, hvor du kan se, hvordan alt beskrevet her fungerer.
DevOps til netværket
Oprettelse af en konfiguration med et script, brug af GIT til at kontrollere ændringer i IT-infrastrukturen, fjern "upload" - disse ideer kommer først, når du tænker på den tekniske implementering af DevOps-tilgangen. Fordelene er indlysende. Men der er desværre også ulemper.
Da vores udviklere for mere end 5 år siden kom til os, netværkerne, med disse forslag, var vi ikke glade.
Jeg må sige, at vi har arvet et ret broget netværk, bestående af udstyr fra omkring 10 forskellige leverandører. Det var praktisk at konfigurere nogle ting gennem vores foretrukne cli, men i andre foretrak vi at bruge GUI. Derudover har langt arbejde med "live" udstyr lært os at kontrollere i realtid. For eksempel, når jeg laver ændringer, føler jeg mig meget mere tryg ved at arbejde direkte gennem cli'en. På denne måde kan jeg hurtigt se, at noget gik galt og rulle ændringerne tilbage. Alt dette var 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å dit script til at oprette den forkerte "config". Jeg vil ikke bruge produktionen til at "indkøre".
Eller hvordan forstår man, at konfigurationskommandoerne blev anvendt korrekt, og hvad skal man gøre i tilfælde af en fejl?
Jeg vil ikke sige, at alle disse problemer er uløselige. Bare det at sige "A" giver nok også mening at sige "B", og hvis du vil bruge de samme processer til ændringsstyring som i udvikling, så skal du have dev- og iscenesættelsesmiljøer ud over produktionen. Så ser denne tilgang komplet ud. Men hvor meget vil det koste?
Men der er én situation, hvor ulemperne praktisk talt udlignes, og kun fordelene er tilbage. Jeg taler om designarbejde.
Projekt
De sidste to år har jeg deltaget i et projekt om at bygge et datacenter for en stor udbyder. Jeg er ansvarlig for F5 og Palo Alto i dette projekt. Fra Ciscos synspunkt er dette "tredjepartsudstyr".
For mig personligt er der to adskilte stadier i dette projekt.
Første fase
Det første år havde jeg uendeligt travlt, jeg arbejdede nat og weekend. Jeg kunne ikke løfte hovedet. Presset fra ledelsen og kunden var stærkt og vedvarende. I en konstant rutine kunne jeg ikke engang forsøge at optimere processen. Det var ikke kun og ikke så meget konfigurationen af udstyr som udarbejdelsen af designdokumentation.
De første test er begyndt, og jeg ville blive overrasket over, hvor mange små fejl og unøjagtigheder der blev lavet. Alt fungerede selvfølgelig, men der manglede et bogstav i navnet, der manglede en linje i kommandoen... Testene blev ved og ved, og jeg var allerede i en konstant daglig kamp med fejl, test og dokumentation .
Dette fortsatte i et år. Projektet var så vidt jeg forstår ikke let for alle, men efterhånden blev bygherren mere og mere tilfreds, og det gjorde det muligt at ansætte yderligere ingeniører, der selv kunne påtage sig en del af rutinen.
Nu kunne vi se os lidt omkring.
Og dette var begyndelsen på anden fase.
Trin to
Jeg besluttede at automatisere processen.
Hvad jeg forstod fra min kommunikation med udviklerne på det tidspunkt (og vi skal hylde, vi havde et stærkt team) er, at tekstformatet, selvom det ved første øjekast virker som noget fra DOS-operativsystemets verden, har et nummer af værdifulde ejendomme.
Så for eksempel vil tekstformatet være nyttigt, hvis du vil drage fuld fordel af GIT og alle dets derivater. Og det ville jeg gerne.
Nå, det ser ud til, at du simpelthen kan gemme en konfiguration eller en liste over kommandoer, men at lave ændringer er ret ubelejligt. Derudover er der en anden vigtig opgave under design. Du bør have dokumentation, der beskriver dit design som helhed (Low Level Design) og specifik implementering (Network Implementation Plan). Og i dette tilfælde ser brugen af skabeloner ud som en meget passende mulighed.
Så når du bruger YAML og Jinja2, opfylder en YAML-fil med konfigurationsparametre såsom IP-adresser, BGP AS-numre, ... perfekt rollen som NIP, mens Jinja2-skabeloner inkluderer syntaks svarende til designet, det vil sige, det er i det væsentlige en afspejling af LLD.
Det tog to dage at lære YAML og Jinja2. Et par gode eksempler er nok til at forstå, hvordan dette fungerer. Derefter tog det omkring to uger at skabe alle de skabeloner, der matchede vores design: en uge for Palo Alto og endnu en uge for F5. Alt dette blev lagt ud på corporate githab.
Nu så forandringsprocessen således ud:
- ændrede YAML-filen
- oprettet en konfigurationsfil ved hjælp af en skabelon (Jinja2)
- gemt i et fjernlager
- uploadede den oprettede konfiguration til udstyret
- Jeg så en fejl
- ændret YAML-filen eller Jinja2-skabelonen
- oprettet en konfigurationsfil ved hjælp af en skabelon (Jinja2)
- ...
Det er tydeligt, at der først blev brugt meget tid på redigeringer, men efter en uge eller to blev det en sjældenhed.
En god test og mulighed for at fejlsøge alt var kundens ønske om at ændre navnekonventionen. De, der arbejdede med F5, forstår det pikante i situationen. Men for mig var det hele ret simpelt. Jeg ændrede navnene i YAML-filen, slettede hele konfigurationen fra udstyret, genererede en ny og uploadede den. Alt, inklusive fejlrettelser, tog 4 dage: to dage for hver teknologi. Herefter var jeg klar til næste fase, nemlig oprettelsen af DEV og Staging datacentre.
Dev og iscenesættelse
Iscenesættelse gentager faktisk produktionen fuldstændigt. Dev er en stærkt strippet kopi bygget hovedsageligt på virtuel hardware. En ideel situation for en ny tilgang. Hvis jeg isolerer den tid, jeg brugte fra den samlede proces, så tror jeg, at arbejdet ikke tog mere end 2 uger. Den vigtigste tid er at vente på den anden side og søge efter problemer sammen. Implementeringen af 3. part gik næsten ubemærket hen af andre. Der var endda tid til at lære noget og skrive et par artikler om Habré :)
For at opsummere
Så hvad har jeg på bundlinjen?
- Alt jeg skal gøre for at ændre konfigurationen er at ændre en enkel, klart struktureret YAML-fil med konfigurationsparametre. Jeg ændrer aldrig python-scriptet og meget sjældent (kun hvis der er en fejl) ændrer jeg Jinja2 heatlate
- Fra et dokumentationssynspunkt er dette en næsten ideel situation. Du ændrer dokumentationen (YAML-filer fungerer som NIP) og uploader denne konfiguration til udstyret. På denne måde er din dokumentation altid opdateret
Alt dette førte til, at
- fejlprocenten er faldet til næsten 0
- 90 procent af rutinen er væk
- implementeringshastigheden er steget markant
PAY, F5Y, ACY
Jeg sagde, at et par eksempler er nok til at forstå, hvordan det fungerer.
Her er en kort (og selvfølgelig modificeret) version af, hvad der blev skabt under mit arbejde.
= indsættelse Palo Alto fra Yaml = Palo Alto fra Yaml
= indsættelse F5 fra Yaml = F5 fra Yaml (kommer snart)
= indsættelse ACjeg fra Yaml = F5 fra YAML
Jeg vil tilføje et par ord om ACY (ikke at forveksle med ACI).
Dem, der har arbejdet med ACI, ved, at dette mirakel (og på en god måde også) bestemt ikke blev skabt af netværkere :). Glem alt, hvad du vidste om netværket - det vil ikke være nyttigt for dig!
Det er lidt overdrevet, men det formidler nogenlunde følelsen af, at jeg de sidste 3 år konstant har oplevet at arbejde med ACI.
Og i dette tilfælde er ACY ikke kun en mulighed for at opbygge en forandringskontrolproces (hvilket er især vigtigt i tilfældet med ACI, fordi det formodes at være den centrale og mest kritiske del af dit datacenter), men giver dig også en brugervenlig grænseflade til oprettelse af konfiguration.
Ingeniørerne på dette projekt bruger Excel til at konfigurere ACI i stedet for YAML til nøjagtig de samme formål. Der er selvfølgelig fordele ved at bruge Excel:
- dit NIP i én fil
- smukke skilte, som er behagelige for kunden at se på
- du kan bruge nogle excel-værktøjer
Men der er et minus, og efter min mening opvejer det fordelene. At kontrollere ændringer og koordinere teamarbejde bliver meget vanskeligere.
ACY er faktisk en applikation af de samme tilgange, som jeg brugte til 3. part til at konfigurere ACI.
Kilde: www.habr.com