Hur man tar kontroll över nätverksinfrastrukturen. Kapitel fyra. Automatisering. Mallar

Denna artikel är den sjätte i serien "Hur man tar kontroll över nätverksinfrastrukturen". Innehållet för hela serien och länkar kan hittas här.

Efter att ha lämnat några ämnen bakom mig bestämde jag mig för att ändå börja ett nytt kapitel.

Jag återkommer till säkerheten lite senare. Här vill jag diskutera en enkel men effektiv strategi som, jag är säker på, på ett eller annat sätt, kan vara till nytta för många. Det handlar mer om en kort berättelse om hur automatisering kan förändra livet för en ingenjör. Fokus ligger på användningen av mallar. I slutet finns en lista över mina projekt där man kan se hur allt som beskrivs här fungerar.

DevOps för nätverk

Att skapa konfigurationer med skript, använda GIT för att kontrollera ändringar i IT-infrastrukturen, fjärruppladdning — dessa idéer dyker först upp när man tänker på den tekniska implementeringen av DevOps. Fördelarna är uppenbara. Men tyvärr finns det också nackdelar.

När våra utvecklare kom till oss, nätverksteknikerna, med dessa förslag för mer än 5 år sedan, var vi inte särskilt entusiastiska.

Det är värt att nämna att vi ärvde ett ganska brokigt nätverk, bestående av utrustning från drygt 10 olika leverantörer. Vissa saker var lätta att konfigurera via vår favorit CLI, men på andra platser föredrog vi att använda GUI. Dessutom hade den långa tiden vi arbetade med 'live' utrustning gett oss vana vid realtidsövervakning. Jag, till exempel, känner mig mycket mer bekväm när jag gör ändringar direkt via CLI. Så kan jag snabbt märka att något gick fel och "återställa" ändringarna. Allt detta stod i viss konflikt med deras idéer.

Och andra frågor dyker upp, till exempel kan gränssnittet för mjukvaran förändras något mellan versioner. Det kan i slutändan leda till att ditt skript skapar en felaktig "konfig". Man vill inte använda produktionen för "testarbeten".

Eller hur vet man att konfigurationskommandona har tillämpats korrekt och vad man ska göra om det uppstår ett fel?

Jag vill inte säga att alla dessa frågor är olösliga. Men att säga "A" innebär nog att det också är rimligt att säga "B", och om man vill använda samma processer för ändringskontroll som i utvecklingen, så behöver man dessutom ha dev- och staging-miljöer förutom produktion. Då framstår denna strategi som komplett. Men vad kommer det att kosta?

Men det finns en situation där nackdelarna nästan upphävs och bara fördelarna kvarstår. Jag pratar om projektarbeten.

Projektet

Under de senaste två åren har jag deltagit i ett projekt för att bygga ett datacenter för en stor leverantör. Jag ansvarar för F5 och Palo Alto i detta projekt. Ur Cisco-perspektiv är det "3rd party equipment".

För mig finns det två tydligt definierade faser i detta projekt.

Den första fasen

Under det första året var jag konstant upptagen, jag jobbade på nights och helger. Jag kunde knappt lyfta huvudet. Trycket från ledningen och kunden var starkt och kontinuerligt. I den ständiga rutinen kunde jag inte ens försöka optimera processen. Det handlade inte bara om att konfigurera hårdvara, utan även om att skapa projekt dokumentation.

Då började de första testerna, och jag var förbluffad över hur många små misstag och felaktigheter som hade begåtts. Självklart fungerade allt, men här saknades en bokstav i namnet, där saknades en rad i kommandot... Tester fortsatte och fortsatte, och jag befann mig i en ständig, daglig kamp mot fel, tester och dokumentation.

Så här fortsatte det i ett år. Projektet var, såvitt jag förstår, inte enkelt för någon, men gradvis blev kunden mer och mer nöjd, vilket gjorde det möjligt att ta in fler ingenjörer som kunde ta över en del av rutinen.

Nu kunde jag se mig omkring lite.
Och detta var början på den andra fasen.

Den andra fasen

Jag beslutade mig för att automatisera processen.

Vad jag insåg från kommunikationen med utvecklarna då (och man ska ge kredit, vi hade ett starkt team) är att textformatet, även om det vid första anblick verkar vara något från DOS-operativsystemet, faktiskt har en rad värdefulla egenskaper.
Till exempel skulle textformatet vara användbart om du vill utnyttja fördelarna med GIT och alla dess avläggningar. Och det ville jag.

Det verkar som om man skulle kunna lagra konfigurationen eller listan över kommandon, men att göra ändringar på det sättet är ganska besvärligt. Dessutom finns det en annan viktig uppgift när man designar. Du måste ha dokumentation som beskriver din övergripande design (Low Level Design) och specifik implementation (Network Implementation Plan). Och i detta fall verkar användningen av mallar vara ett mycket lämpligt alternativ.

Så, när man använder YAML och Jinja2, fungerar YAML-filen med konfigurationsparametrar, som IP-adresser, BGP AS-nummer, … utmärkt som NIP, medan Jinja2-mallar inkluderar syntaxen som motsvarar designen, vilket i stort sett är en spegling av LLD.

Det tog två dagar att lära sig språken YAML och Jinja2. För att förstå hur det fungerar räcker det med några bra exempel. Därefter tog det cirka två veckor att skapa alla mallar som motsvarar vår design: en vecka för Palo Alto och ytterligare en vecka för F5. Allt detta lades ut på företagets GitHub.

Nu såg förändringsprocessen ut på följande sätt:

• ändrade YAML-filen
• skapade en konfigurationsfil med hjälp av mallen (Jinja2)
• sparade i det fjärrlagrade arkivet
• laddade upp den skapade konfigurationen på utrustningen
• såg ett fel
• ändrade YAML-filen eller Jinja2-mallen
• skapade en konfigurationsfil med hjälp av mallen (Jinja2)
• …

Det är klart att mycket tid gick åt till ändringar i början, men efter en vecka eller två blev det snarare en sällsynthet.

En bra kontroll och möjlighet att felsöka blev kundens önskan att ändra namnsättningen. De som har arbetat med F5 förstår situationens känslighet. Men för mig var allt ganska enkelt. Jag ändrade namnen i YAML-filen, raderade all konfiguration från utrustningen, genererade en ny och laddade upp. Totalt tog det fyra dagar, med hänsyn till buggfixar: två dagar för varje teknologi. Därefter var jag redo för nästa steg, nämligen att skapa DEV- och Staging-datacenter.

Dev och Staging

Staging återspeglar i stort sett produktionen fullt ut. Dev är en kraftigt nedskuren kopia som främst bygger på virtuell utrustning. En perfekt situation för att tillämpa det nya tillvägagångssättet. Om man ser på den tid jag spenderade på hela processen, tror jag att arbete inte tog mer än två veckor. Den största delen av tiden var väntan på den andra sidan och gemensamma sökande efter problem. Implementeringen av 3rd party passerade nästan obemärkt för omgivningen. Det fanns till och med tid att lära sig något nytt och skriva ett par artiklar på Habr 🙂

Sammanfattningsvis

Så, vad har jag kvar i det korta?

• allt jag behöver för att ändra konfigurationen — är att ändra en enkel, tydligt strukturerad YAML-fil med konfigurationsparametrar. Jag ändrar aldrig python-skript och mycket sällan (bara om det finns ett fel) ändrar jag Jinja2-mallen.
• ur dokumentation förefaller nästan perfekt. Du ändrar dokumentationen (YAML-filer fungerar som NIP) och laddar upp denna konfiguration på utrustningen. På så sätt är din dokumentation alltid aktuell.

Allt detta har lett till att

• felet har minskat nästan till 0
• 90 procent av rutinarbetet har försvunnit
• implementeringshastigheten har ökat flera gånger

PAY, F5Y, ACY

Jag sa att några exempel är tillräckliga för att förstå hur det fungerar.
Här är en kort (och förstås omarbetad) version av vad som skapades under mitt arbete.

PAY = deployment Palo Alto från Yaml = Palo Alto från Yaml
F5Y = deployment F5 från Yaml = F5 från Yaml (snart kommer det)
ACY = deployment ACi från Yaml = F5 från Yaml

Jag lägger till några ord om ACY (förväxla inte med ACI).

De som har arbetat med ACI vet att detta underverk (och i goda avseenden också) skapades definitivt inte av nätverksingenjörer :). Glöm allt du visste om nätverk — det kommer inte att vara till hjälp!
Lite överdrivet, men det fångar ungefär den känsla jag ständigt, i nu tre år, har upplevt när jag arbetar med ACI.

I det här fallet är ACY inte bara en möjlighet att styra förändringsprocessen (vilket är särskilt viktigt i fallet med ACI, eftersom det antas vara den centrala och mest kritiska delen av ditt datacenter), men det ger dig också ett användarvänligt gränssnitt för att skapa konfigurationer.

Ingengörerna i detta projekt använder Excel istället för YAML för att konfigurera ACI för samma syften. Användningen av Excel har förstås sina fördelar:

• din NIP i en fil
• vackra tabeller som är trevliga att se på för kunden
• du kan använda vissa verktyg i Excel

Men det finns en nackdel, och jag anser att den väger tyngre än fördelarna. Att kontrollera förändringar och koordinera teamets arbete blir mycket svårare.

ACY är faktiskt tillämpningen av samma metoder som jag använde för 3rd party, för att konfigurera ACI.

Källa: habr.com