{"id":34742,"date":"2019-10-31T22:00:10","date_gmt":"2019-10-31T19:00:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-chetvertaya-avtomatizatsiya-templejty\/"},"modified":"2019-10-31T22:00:10","modified_gmt":"2019-10-31T19:00:10","slug":"kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-chetvertaya-avtomatizatsiya-templejty","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-chetvertaya-avtomatizatsiya-templejty","title":{"rendered":"Hur man tar kontroll \u00f6ver n\u00e4tverksinfrastrukturen. Kapitel fyra. Automatisering. Mallar","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Denna artikel \u00e4r den sj\u00e4tte i serien \"Hur man tar kontroll \u00f6ver n\u00e4tverksinfrastrukturen\". Inneh\u00e5llet f\u00f6r hela serien och l\u00e4nkar kan hittas h\u00e4r<\/a><\/noindex><\/i>.<\/p>\n

Efter att ha l\u00e4mnat n\u00e5gra \u00e4mnen bakom mig best\u00e4mde jag mig f\u00f6r att \u00e4nd\u00e5 b\u00f6rja ett nytt kapitel.<\/p>\n

Jag \u00e5terkommer till s\u00e4kerheten lite senare. H\u00e4r vill jag diskutera en enkel men effektiv strategi som, jag \u00e4r s\u00e4ker p\u00e5, p\u00e5 ett eller annat s\u00e4tt, kan vara till nytta f\u00f6r m\u00e5nga. Det handlar mer om en kort ber\u00e4ttelse om hur automatisering kan f\u00f6r\u00e4ndra livet f\u00f6r en ingenj\u00f6r. Fokus ligger p\u00e5 anv\u00e4ndningen av mallar. I slutet finns en lista \u00f6ver mina projekt d\u00e4r man kan se hur allt som beskrivs h\u00e4r fungerar.<\/p>\n

DevOps f\u00f6r n\u00e4tverk<\/h2>\n

\nAtt skapa konfigurationer med skript, anv\u00e4nda GIT f\u00f6r att kontrollera \u00e4ndringar i IT-infrastrukturen, fj\u00e4rruppladdning \u2014 dessa id\u00e9er dyker f\u00f6rst upp n\u00e4r man t\u00e4nker p\u00e5 den tekniska implementeringen av DevOps. F\u00f6rdelarna \u00e4r uppenbara. Men tyv\u00e4rr finns det ocks\u00e5 nackdelar.<\/p>\n

N\u00e4r v\u00e5ra utvecklare kom till oss, n\u00e4tverksteknikerna, med dessa f\u00f6rslag f\u00f6r mer \u00e4n 5 \u00e5r sedan, var vi inte s\u00e4rskilt entusiastiska.
\n<\/a><\/noindex>
\nDet \u00e4r v\u00e4rt att n\u00e4mna att vi \u00e4rvde ett ganska brokigt n\u00e4tverk, best\u00e5ende av utrustning fr\u00e5n drygt 10 olika leverant\u00f6rer. Vissa saker var l\u00e4tta att konfigurera via v\u00e5r favorit CLI, men p\u00e5 andra platser f\u00f6redrog vi att anv\u00e4nda GUI. Dessutom hade den l\u00e5nga tiden vi arbetade med 'live' utrustning gett oss vana vid realtids\u00f6vervakning. Jag, till exempel, k\u00e4nner mig mycket mer bekv\u00e4m n\u00e4r jag g\u00f6r \u00e4ndringar direkt via CLI. S\u00e5 kan jag snabbt m\u00e4rka att n\u00e5got gick fel och \"\u00e5terst\u00e4lla\" \u00e4ndringarna. Allt detta stod i viss konflikt med deras id\u00e9er.<\/p>\n

Och andra fr\u00e5gor dyker upp, till exempel kan gr\u00e4nssnittet f\u00f6r mjukvaran f\u00f6r\u00e4ndras n\u00e5got mellan versioner. Det kan i slut\u00e4ndan leda till att ditt skript skapar en felaktig \"konfig\". Man vill inte anv\u00e4nda produktionen f\u00f6r \"testarbeten\". <\/p>\n

Eller hur vet man att konfigurationskommandona har till\u00e4mpats korrekt och vad man ska g\u00f6ra om det uppst\u00e5r ett fel?<\/p>\n

Jag vill inte s\u00e4ga att alla dessa fr\u00e5gor \u00e4r ol\u00f6sliga. Men att s\u00e4ga \"A\" inneb\u00e4r nog att det ocks\u00e5 \u00e4r rimligt att s\u00e4ga \"B\", och om man vill anv\u00e4nda samma processer f\u00f6r \u00e4ndringskontroll som i utvecklingen, s\u00e5 beh\u00f6ver man dessutom ha dev- och staging-milj\u00f6er f\u00f6rutom produktion. D\u00e5 framst\u00e5r denna strategi som komplett. Men vad kommer det att kosta?<\/p>\n

Men det finns en situation d\u00e4r nackdelarna n\u00e4stan upph\u00e4vs och bara f\u00f6rdelarna kvarst\u00e5r. Jag pratar om projektarbeten.<\/p>\n

Projektet<\/h2>\n

\nUnder de senaste tv\u00e5 \u00e5ren har jag deltagit i ett projekt f\u00f6r att bygga ett datacenter f\u00f6r en stor leverant\u00f6r. Jag ansvarar f\u00f6r F5 och Palo Alto i detta projekt. Ur Cisco-perspektiv \u00e4r det \"3rd party equipment\".<\/p>\n

F\u00f6r mig finns det tv\u00e5 tydligt definierade faser i detta projekt. <\/p>\n

Den f\u00f6rsta fasen<\/h3>\n

\nUnder det f\u00f6rsta \u00e5ret var jag konstant upptagen, jag jobbade p\u00e5 nights och helger. Jag kunde knappt lyfta huvudet. Trycket fr\u00e5n ledningen och kunden var starkt och kontinuerligt. I den st\u00e4ndiga rutinen kunde jag inte ens f\u00f6rs\u00f6ka optimera processen. Det handlade inte bara om att konfigurera h\u00e5rdvara, utan \u00e4ven om att skapa projekt dokumentation. <\/p>\n

D\u00e5 b\u00f6rjade de f\u00f6rsta testerna, och jag var f\u00f6rbluffad \u00f6ver hur m\u00e5nga sm\u00e5 misstag och felaktigheter som hade beg\u00e5tts. Sj\u00e4lvklart fungerade allt, men h\u00e4r saknades en bokstav i namnet, d\u00e4r saknades en rad i kommandot... Tester fortsatte och fortsatte, och jag befann mig i en st\u00e4ndig, daglig kamp mot fel, tester och dokumentation. <\/p>\n

S\u00e5 h\u00e4r fortsatte det i ett \u00e5r. Projektet var, s\u00e5vitt jag f\u00f6rst\u00e5r, inte enkelt f\u00f6r n\u00e5gon, men gradvis blev kunden mer och mer n\u00f6jd, vilket gjorde det m\u00f6jligt att ta in fler ingenj\u00f6rer som kunde ta \u00f6ver en del av rutinen.<\/p>\n

Nu kunde jag se mig omkring lite.
\nOch detta var b\u00f6rjan p\u00e5 den andra fasen. <\/p>\n

Den andra fasen<\/h3>\n

\nJag beslutade mig f\u00f6r att automatisera processen.<\/p>\n

Vad jag ins\u00e5g fr\u00e5n kommunikationen med utvecklarna d\u00e5 (och man ska ge kredit, vi hade ett starkt team) \u00e4r att textformatet, \u00e4ven om det vid f\u00f6rsta anblick verkar vara n\u00e5got fr\u00e5n DOS-operativsystemet, faktiskt har en rad v\u00e4rdefulla egenskaper.
\nTill exempel skulle textformatet vara anv\u00e4ndbart om du vill utnyttja f\u00f6rdelarna med GIT och alla dess avl\u00e4ggningar. Och det ville jag. <\/p>\n

Det verkar som om man skulle kunna lagra konfigurationen eller listan \u00f6ver kommandon, men att g\u00f6ra \u00e4ndringar p\u00e5 det s\u00e4ttet \u00e4r ganska besv\u00e4rligt. Dessutom finns det en annan viktig uppgift n\u00e4r man designar. Du m\u00e5ste ha dokumentation som beskriver din \u00f6vergripande design (Low Level Design) och specifik implementation (Network Implementation Plan). Och i detta fall verkar anv\u00e4ndningen av mallar vara ett mycket l\u00e4mpligt alternativ.<\/p>\n

S\u00e5, n\u00e4r man anv\u00e4nder YAML och Jinja2, fungerar YAML-filen med konfigurationsparametrar, som IP-adresser, BGP AS-nummer, \u2026 utm\u00e4rkt som NIP, medan Jinja2-mallar inkluderar syntaxen som motsvarar designen, vilket i stort sett \u00e4r en spegling av LLD. <\/p>\n

Det tog tv\u00e5 dagar att l\u00e4ra sig spr\u00e5ken YAML och Jinja2. F\u00f6r att f\u00f6rst\u00e5 hur det fungerar r\u00e4cker det med n\u00e5gra bra exempel. D\u00e4refter tog det cirka tv\u00e5 veckor att skapa alla mallar som motsvarar v\u00e5r design: en vecka f\u00f6r Palo Alto och ytterligare en vecka f\u00f6r F5. Allt detta lades ut p\u00e5 f\u00f6retagets GitHub.<\/p>\n

Nu s\u00e5g f\u00f6r\u00e4ndringsprocessen ut p\u00e5 f\u00f6ljande s\u00e4tt:<\/p>\n