{"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\/nl\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-chetvertaya-avtomatizatsiya-templejty","title":{"rendered":"Hoe je je netwerkstructuur onder controle kunt krijgen. Hoofdstuk vier. Automatisering. Templates","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Dit artikel is de zesde in een cyclus van artikelen met de titel 'Hoe jouw netwerkstructuur onder controle te krijgen'. De inhoud van alle artikelen in de cyclus en de links zijn te vinden hier<\/a><\/noindex><\/i>.<\/p>\n

Na een aantal onderwerpen achter te laten, besloot ik toch een nieuw hoofdstuk te beginnen.<\/p>\n

Ik kom later terug op de veiligheid. Hier wil ik een eenvoudige maar effectieve benadering bespreken die, daarvan ben ik overtuigd, in welke vorm dan ook nuttig kan zijn voor velen. Het is eerder een kort verhaal over hoe automatisering het leven van een ingenieur kan veranderen. Het zal gaan over het gebruik van templates. Aan het einde volgt een lijst van mijn projecten waar je kunt zien hoe alles wat hier is beschreven, werkt.<\/p>\n

DevOps voor netwerken<\/h2>\n

\nConfiguratie met een script opzetten, gebruik maken van GIT voor versiebeheer van IT-infrastructuur, remote 'upload' - deze idee\u00ebn komen als eerste naar boven als je nadenkt over de technische uitvoering van de DevOps-aanpak. De voordelen zijn duidelijk. Maar helaas zijn er ook nadelen.<\/p>\n

Toen onze ontwikkelaars meer dan 5 jaar geleden met deze voorstellen bij ons, de netwerkprofessionals, kwamen, waren we niet bepaald enthousiast.
\n<\/a><\/noindex>
\nHet moet gezegd worden dat we een vrij kleurrijk netwerk hebben ge\u00ebrfd, bestaande uit apparatuur van zo'n 10 verschillende leveranciers. Sommige dingen konden we gemakkelijk configureren via onze favoriete cli, maar ergens gaven we de voorkeur aan het gebruik van GUI. Bovendien had langdurig werken met 'live' apparatuur ons gewend aan real-time controle. Persoonlijk voel ik me veel comfortabeler als ik wijzigingen direct via de cli aanbreng. Zo kan ik snel zien dat er iets misgaat en de wijzigingen 'terugdraaien'. Dit stond in zekere zin haaks op hun idee\u00ebn.<\/p>\n

Er rijzen ook andere vragen, bijvoorbeeld hoe de interface van de software van versie tot versie iets kan veranderen. Dit zal er uiteindelijk toe leiden dat jouw script een verkeerde 'config' genereert. Je zou productie niet willen gebruiken voor 'tests'. <\/p>\n

Of, hoe te begrijpen dat de configuratiecommando's correct zijn toegepast en wat te doen in geval van een fout?<\/p>\n

Ik wil niet zeggen dat al deze vragen onoplosbaar zijn. Gewoon 'A' zeggen, betekent waarschijnlijk ook 'B' zeggen, en als je dezelfde processen wilt gebruiken voor versiebeheer als in de ontwikkeling, dan heb je naast productie ook dev- en staging-omgevingen nodig. Dan lijkt deze benadering compleet. Maar wat gaat dit kosten?<\/p>\n

Maar er is \u00e9\u00e9n situatie waarin de nadelen vrijwel worden opgeheven en er alleen maar voordelen overblijven. Ik heb het over projectwerk.<\/p>\n

Project<\/h2>\n

\nDe afgelopen twee jaar neem ik deel aan een project voor de bouw van een datacenter voor een grote provider. Ik ben verantwoordelijk voor F5 en Palo Alto in dit project. Vanuit Cisco's perspectief is dit '3rd party equipment'.<\/p>\n

Persoonlijk zie ik twee duidelijke fasen in dit project. <\/p>\n

Eerste fase<\/h3>\n

\nIn het eerste jaar was ik oneindig druk, ik werkte 's nachts en in het weekeinde. Ik kon mijn hoofd niet boven water houden. De druk van het management en de klant was sterk en continu. In de constante routine kon ik zelfs niet proberen het proces te optimaliseren. Het ging niet alleen, en zelfs niet in de eerste plaats, om het configureren van de apparatuur, maar om het opstellen van projectdocumentatie. <\/p>\n

Toen begonnen de eerste tests, en ik was verrast hoeveel kleine fouten en onnauwkeurigheden er waren gemaakt. Natuurlijk werkte alles, maar hier was een letter gemist in de naam, daar ontbrak een regel in de commando\u2026 De tests gingen maar door en ik was in een constante, dagelijkse strijd met fouten, tests en documentatie. <\/p>\n

Dit ging zo door gedurende een jaar. Het project was, voor zover ik begreep, niet eenvoudig voor iedereen, maar geleidelijk werd de klant steeds blijer en dit maakte het mogelijk om extra ingenieurs aan te nemen die een deel van de routine op zich konden nemen.<\/p>\n

Nu kon ik me een beetje om me heen kijken.
\nEn dit was het begin van de tweede fase. <\/p>\n

Tweede fase<\/h3>\n

\nIk besloot het proces te automatiseren.<\/p>\n

Wat ik begreep uit de communicatie met de ontwikkelaars toen (en dat moet gezegd worden, we hadden een sterk team), was dat het tekstformaat, hoewel het op het eerste gezicht iets uit de wereld van het DOS-besturingssysteem lijkt te zijn, over verschillende waardevolle eigenschappen beschikt.
\nHet tekstformaat is bijvoorbeeld nuttig als je de voordelen van GIT en al zijn afgeleiden volledig wilt benutten. En dat wilde ik. <\/p>\n

Je zou denken dat je de configuratie of de lijst met commando's gewoon kunt opslaan, maar veranderingen aanbrengen is dan best onhandig. Bovendien staat er bij het ontwerpen nog een belangrijke taak. Je moet documentatie hebben die je ontwerp als geheel beschrijft (Low Level Design) en de specifieke implementatie (Network Implementation Plan). En in dit geval lijkt het gebruik van sjablonen een zeer geschikte optie.<\/p>\n

Dus, bij het gebruik van YAML en Jinja2 fungeert het YAML-bestand met configuratieparameters, zoals IP-adressen en BGP AS-nummers,... uitstekend als NIP, terwijl de Jinja2-sjablonen de syntaxis bevatten die overeenkomt met het ontwerp, wat in wezen een reflectie van LLD is. <\/p>\n

De studie van de talen YAML en Jinja2 heeft twee dagen geduurd. Om te begrijpen hoe het werkt, zijn een paar goede voorbeelden voldoende. Daarna heeft het ongeveer twee weken gekost om alle sjablonen te maken die overeenkomen met ons ontwerp: een week voor Palo Alto en nog een week voor F5. Dit alles is gepost op het bedrijfs-github.<\/p>\n

Het proces van wijzigingen zag er nu als volgt uit:<\/p>\n