Denne artikkelen er den sjette i serien "Hvordan ta kontroll over nettverksinfrastrukturen din." Innholdet i alle artiklene i serien og lenker finner du .
Etter å ha lagt igjen flere emner, bestemte jeg meg for å starte et nytt kapittel.
Jeg kommer tilbake til sikkerheten litt senere. Her ønsker jeg å diskutere én enkel, men effektiv tilnærming, som jeg er sikker på, i en eller annen form, kan være nyttig for mange. Dette er mer en novelle om hvordan automatisering kan endre livet til en ingeniør. Vi vil snakke om bruk av maler. På slutten er det en liste over mine prosjekter hvor du kan se hvordan alt som er beskrevet her fungerer.
DevOps for nettverket
Å lage en konfigurasjon med et skript, bruke GIT til å kontrollere endringer i IT-infrastrukturen, ekstern "opplasting" - disse ideene kommer først når du tenker på den tekniske implementeringen av DevOps-tilnærmingen. Fordelene er åpenbare. Men det er dessverre også ulemper.
Da utviklerne våre for mer enn 5 år siden kom til oss, nettverksbyggerne, med disse forslagene, var vi ikke glade.
Jeg må si at vi arvet et ganske broket nettverk, bestående av utstyr fra ca 10 forskjellige leverandører. Det var praktisk å konfigurere noen ting gjennom vår favoritt-cli, men i andre foretrakk vi å bruke GUI. I tillegg har langt arbeid med "live" utstyr lært oss sanntidskontroll. For eksempel, når jeg gjør endringer, føler jeg meg mye mer komfortabel med å jobbe direkte gjennom cli. På denne måten kan jeg raskt se at noe gikk galt og rulle tilbake endringene. Alt dette var i en viss motsetning til deres ideer.
Andre spørsmål dukker også opp, for eksempel kan grensesnittet endre seg litt fra versjon til versjon av programvaren. Dette vil til slutt føre til at skriptet ditt oppretter feil "config". Jeg vil ikke bruke produksjonen til å "kjøre inn".
Eller hvordan forstå at konfigurasjonskommandoene ble brukt riktig og hva du skal gjøre i tilfelle feil?
Jeg vil ikke si at alle disse problemene er uløselige. Bare det å si "A" gir sannsynligvis mening å si "B" også, og hvis du vil bruke de samme prosessene for endringskontroll som i utvikling, så må du ha dev- og iscenesettelsesmiljøer i tillegg til produksjon. Da ser denne tilnærmingen komplett ut. Men hvor mye vil det koste?
Men det er en situasjon når ulempene praktisk talt jevnes ut, og bare fordelene gjenstår. Jeg snakker om designarbeid.
Prosjekt
De siste to årene har jeg deltatt i et prosjekt for å bygge et datasenter for en stor leverandør. Jeg er ansvarlig for F5 og Palo Alto i dette prosjektet. Fra Ciscos synspunkt er dette "tredjepartsutstyr".
For meg personlig er det to forskjellige stadier i dette prosjektet.
Steg ett
Det første året jeg var uendelig opptatt, jobbet jeg netter og helger. Jeg klarte ikke å heve hodet. Presset fra ledelsen og kunden var sterkt og kontinuerlig. I en konstant rutine klarte jeg ikke engang å prøve å optimalisere prosessen. Det var ikke bare og ikke så mye konfigurasjonen av utstyr som utarbeidelsen av designdokumentasjon.
De første testene har begynt, og jeg vil bli overrasket over hvor mange små feil og unøyaktigheter som ble gjort. Alt fungerte selvfølgelig, men det manglet en bokstav i navnet, det manglet en linje i kommandoen... Testene fortsatte og fortsatte, og jeg var allerede i en konstant daglig kamp med feil, tester og dokumentasjon .
Dette pågikk i ett år. Prosjektet var så vidt jeg forstår ikke lett for alle, men etter hvert ble oppdragsgiveren mer og mer fornøyd, og dette gjorde det mulig å ansette flere ingeniører som selv kunne ta på seg en del av rutinen.
Nå kunne vi se oss litt rundt.
Og dette var begynnelsen på den andre etappen.
Trinn to
Jeg bestemte meg for å automatisere prosessen.
Det jeg forsto av kommunikasjonen min med utviklerne på den tiden (og vi må hylle, vi hadde et sterkt team) er at tekstformatet, selv om det ved første øyekast virker som noe fra DOS-operativsystemets verden, har et nummer av verdifulle eiendommer.
Så for eksempel vil tekstformatet være nyttig hvis du vil dra full nytte av GIT og alle dets derivater. Og jeg ville.
Vel, det ser ut til at du ganske enkelt kan lagre en konfigurasjon eller en liste over kommandoer, men å gjøre endringer er ganske upraktisk. I tillegg er det en annen viktig oppgave under design. Du bør ha dokumentasjon som beskriver designet som helhet (Low Level Design) og spesifikk implementering (Network Implementation Plan). Og i dette tilfellet ser bruken av maler ut som et veldig passende alternativ.
Så når du bruker YAML og Jinja2, oppfyller en YAML-fil med konfigurasjonsparametere som IP-adresser, BGP AS-numre, ... perfekt rollen som NIP, mens Jinja2-maler inkluderer syntaks som tilsvarer designet, det vil si at det i hovedsak er en refleksjon av LLD.
Det tok to dager å lære YAML og Jinja2. Noen få gode eksempler er nok til å forstå hvordan dette fungerer. Deretter tok det omtrent to uker å lage alle malene som matchet designet vårt: en uke for Palo Alto og en uke til for F5. Alt dette ble lagt ut på corporate githab.
Nå så endringsprosessen slik ut:
- endret YAML-filen
- opprettet en konfigurasjonsfil ved hjelp av en mal (Jinja2)
- lagret i et eksternt depot
- lastet opp den opprettede konfigurasjonen til utstyret
- Jeg så en feil
- endret YAML-filen eller Jinja2-malen
- opprettet en konfigurasjonsfil ved hjelp av en mal (Jinja2)
- ...
Det er klart at det først ble brukt mye tid på redigeringer, men etter en uke eller to ble dette en sjeldenhet.
En god test og mulighet til å feilsøke alt var kundens ønske om å endre navnekonvensjonen. De som jobbet med F5 forstår det pikante i situasjonen. Men for meg var alt ganske enkelt. Jeg endret navnene i YAML-filen, slettet hele konfigurasjonen fra utstyret, genererte en ny og lastet den opp. Alt, inkludert feilrettinger, tok 4 dager: to dager for hver teknologi. Etter det var jeg klar for neste trinn, nemlig opprettelsen av DEV og Staging datasentre.
Dev og Staging
Iscenesettelse replikerer faktisk produksjonen fullstendig. Dev er en sterkt nedstrippet kopi bygget hovedsakelig på virtuell maskinvare. En ideell situasjon for en ny tilnærming. Hvis jeg isolerer tiden jeg brukte fra den totale prosessen, så tror jeg at arbeidet ikke tok mer enn 2 uker. Hovedtiden er å vente på den andre siden og lete etter problemer sammen. Implementeringen av 3. part gikk nesten ubemerket av andre. Det var til og med tid til å lære noe og skrive et par artikler om Habré :)
For å oppsummere
Så, hva har jeg på bunnlinjen?
- Alt jeg trenger å gjøre for å endre konfigurasjonen er å endre en enkel, tydelig strukturert YAML-fil med konfigurasjonsparametere. Jeg endrer aldri python-skriptet og svært sjelden (bare hvis det er en feil) endrer jeg Jinja2 heatlate
- Fra et dokumentasjonssynspunkt er dette en nærmest ideell situasjon. Du endrer dokumentasjonen (YAML-filer fungerer som NIP) og laster opp denne konfigurasjonen til utstyret. På denne måten er dokumentasjonen alltid oppdatert
Alt dette førte til det faktum at
- feilraten har sunket til nesten 0
- 90 prosent av rutinen er borte
- hastigheten på implementeringen har økt betydelig
PAY, F5Y, ACY
Jeg sa at noen få eksempler er nok til å forstå hvordan det fungerer.
Her er en kort (og selvfølgelig modifisert) versjon av det som ble skapt under arbeidet mitt.
= utplassering Palo Alto fra Yaml = Palo Alto fra Yaml
= utplassering F5 fra Yaml = F5 fra Yaml (kommer snart)
= utplassering ACjeg fra Yaml = F5 fra Yjr
Jeg vil legge til noen ord om ACY (ikke å forveksle med ACI).
De som har jobbet med ACI vet at dette miraklet (og på en god måte også) definitivt ikke ble skapt av nettverkere :). Glem alt du visste om nettverket - det vil ikke være nyttig for deg!
Det er litt overdrevet, men det formidler grovt sett følelsen av at jeg konstant har opplevd, de siste 3 årene, å jobbe med ACI.
Og i dette tilfellet er ACY ikke bare en mulighet til å bygge en endringskontrollprosess (som er spesielt viktig når det gjelder ACI, fordi det er ment å være den sentrale og mest kritiske delen av datasenteret ditt), men gir deg også et brukervennlig grensesnitt for å lage konfigurasjon.
Ingeniørene i dette prosjektet bruker Excel til å konfigurere ACI i stedet for YAML for nøyaktig de samme formålene. Det er selvfølgelig fordeler med å bruke Excel:
- din NIP i én fil
- vakre skilt som er hyggelige for kunden å se på
- du kan bruke noen excel-verktøy
Men det er ett minus, og etter min mening veier det opp for fordelene. Å kontrollere endringer og koordinere teamarbeid blir mye vanskeligere.
ACY er faktisk en applikasjon av de samme tilnærmingene som jeg brukte for tredjeparten for å konfigurere ACI.
Kilde: www.habr.com