{"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\/da\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-chetvertaya-avtomatizatsiya-templejty","title":{"rendered":"S\u00e5dan f\u00e5r du kontrol over netv\u00e6rksinfrastrukturen. Kapitel fire. Automatisering. Skabeloner","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Denne artikel er den sjette i en serie af artikler \"S\u00e5dan f\u00e5r du kontrol over dit netv\u00e6rksinfrastruktur\". Indholdet af alle artikler i serien og links findes her<\/a><\/noindex><\/i>.<\/p>\n

Efter at have forladt nogle emner bag mig, besluttede jeg mig for alligevel at starte et nyt kapitel.<\/p>\n

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\u00e6de af i en eller anden form. Dette er snarere en kort historie om, hvordan automatisering kan \u00e6ndre livet for en ingeni\u00f8r. Det handler om brugen af skabeloner. Til sidst pr\u00e6senteres en liste over mine projekter, hvor man kan se, hvordan alt dette fungerer.<\/p>\n

DevOps for netv\u00e6rk<\/h2>\n

\nOprettelse af konfiguration med skript, brug af GIT til at kontrollere \u00e6ndringer i IT-infrastrukturen, fjern \"upload\" \u2014 disse ideer kommer f\u00f8rst i tankerne, n\u00e5r man overvejer den tekniske implementering af DevOps-tilgangen. Fordelene er \u00e5benlyse. Men desv\u00e6rre er der ogs\u00e5 ulemper.<\/p>\n

Da vores udviklere for mere end 5 \u00e5r siden kom til os netv\u00e6rksfolk med disse forslag, var vi ikke begejstrede.
\n<\/a><\/noindex>
\nDet skal siges, at vi arvede et ret broget netv\u00e6rk, best\u00e5ende af udstyr fra cirka 10 forskellige leverand\u00f8rer. Nogle ting var nemme at konfigurere via vores elskede CLI, men andre steder foretrak vi at bruge GUI. Desuden havde langvarigt arbejde p\u00e5 \"live\" udstyr vant os til realtidskontrol. Jeg f\u00f8ler mig for eksempel meget mere komfortabel med at arbejde direkte via CLI, mens jeg foretager \u00e6ndringer. S\u00e5 kan jeg hurtigt se, hvis noget gik galt, og \"rulle\" \u00e6ndringerne tilbage. Alt dette stod i en vis modstrid med deres ideer.<\/p>\n

Der opst\u00e5r ogs\u00e5 andre sp\u00f8rgsm\u00e5l, for eksempel kan gr\u00e6nsefladen \u00e6ndre sig lidt fra version til version af softwaren. Dette vil i sidste ende f\u00f8re til, at dit skript skaber en forkert \"konfig\". Det ville v\u00e6re uheldigt at bruge produktionen til \"testning\". <\/p>\n

Eller, hvordan kan man forst\u00e5, at konfigurationskommandoerne blev anvendt korrekt, og hvad g\u00f8r man i tilf\u00e6lde af fejl?<\/p>\n

Jeg vil ikke sige, at alle disse sp\u00f8rgsm\u00e5l er uopl\u00f8selige. Bare at sige \"A\" er nok fornuftigt at sige \"B\" ogs\u00e5, og hvis du vil bruge de samme processer til \u00e6ndringskontrol som i udviklingen, skal du have, udover produktionen, ogs\u00e5 dev- og staging-milj\u00f8er. S\u00e5 ser denne tilgang komplet ud. Men hvad vil det koste?<\/p>\n

Men der er \u00e9n situation, hvor ulemperne n\u00e6sten udlignes, og der kun er fordele tilbage. Jeg taler om projektarbejde.<\/p>\n

Projekt<\/h2>\n

\nI de seneste to \u00e5r 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\".<\/p>\n

Personligt er der to klart definerede faser i dette projekt. <\/p>\n

F\u00f8rste fase<\/h3>\n

\nI det f\u00f8rste \u00e5r var jeg uendeligt optaget; jeg arbejdede om natten og i weekenderne. Jeg kunne ikke l\u00f8fte hovedet. Presset fra ledelsen og kunden var st\u00e6rkt og vedvarende. I den konstante rutine kunne jeg ikke engang fors\u00f8ge at optimere processen. Det handlede ikke kun om at konfigurere udstyr, men ogs\u00e5 om at udarbejde projektdokumentation. <\/p>\n

Her begyndte de f\u00f8rste tests, og jeg var chokeret over, hvor mange sm\u00e5 fejl og un\u00f8jagtigheder der var blevet beg\u00e5et. Selvf\u00f8lgelig 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. <\/p>\n

S\u00e5dan fortsatte det i et \u00e5r. Projektet, s\u00e5 vidt jeg forst\u00e5r, var ikke let for alle, men gradvist blev kunden mere og mere tilfreds, og det gav mulighed for at tage ekstra ingeni\u00f8rer ind, som kunne tage en del af rutinen p\u00e5 sig.<\/p>\n

Nu kunne man se sig omkring.
\nOg det var starten p\u00e5 den anden fase. <\/p>\n

Anden fase<\/h3>\n

\nJeg besluttede at automatisere processen.<\/p>\n

Det jeg forstod fra dengang, jeg kommunikerede med udviklerne (og man m\u00e5 sige, at vi havde et st\u00e6rkt team), var, at tekstformatet, selvom det ved f\u00f8rste \u00f8jekast virker som noget fra DOS-systemets verden, har en r\u00e6kke v\u00e6rdifulde egenskaber.
\nFor eksempel vil tekstformatet v\u00e6re nyttigt, hvis du vil udnytte fordelene ved GIT og alle dens afledte. Og jeg \u00f8nskede det. <\/p>\n

N\u00e5, det virker som om, man blot kan gemme konfigurationen eller listen over kommandoer, men at foretage \u00e6ndringer er temmelig besv\u00e6rligt. Desuden st\u00e5r 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\u00e6lde ser brugen af skabeloner ud til at v\u00e6re en meget passende l\u00f8sning.<\/p>\n

S\u00e5 n\u00e5r 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. <\/p>\n

Det tog to dage at l\u00e6re YAML- og Jinja2-sprogene. For at forst\u00e5, 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\u00e5d med vores design: en uge til Palo Alto og en uge mere til F5. Alt dette blev uploadet til virksomhedens GitHub.<\/p>\n

Nu s\u00e5 \u00e6ndringsprocessen s\u00e5ledes ud:<\/p>\n