Automation: vijf veelgestelde vragen

Een applicatie staat nooit op zich, je hebt een infrastructuur nodig om deze aan je gebruikers beschikbaar stellen. Zo’n infrastructuur varieert van een netwerk en virtuele machines tot bijvoorbeeld databases en load balancers. Daarom moet je het uitrollen van een toepassing altijd in het licht van het totale applicatielandschap bekijken. Met welke stappen heb je binnen dat landschap te maken? Wat dient er precies in elke stap te gebeuren? Wie zijn daarbij betrokken? En waar zitten de afhankelijkheden in het proces? Je netwerkbeheerder moet bijvoorbeeld eerst een IP-adres binnen je vLAN opleveren. En zonder het benodigde besturingssysteem of bepaalde goedkeuringen kun je ook niet verder. Wil je applicaties echt snel uitrollen, dan is het zaak automation toe te passen in alle stappen van dit proces. Kijk dus over alle silo’s, afdelingen en teams in je applicatieomgeving heen, maak een stroomschema met alle stappen en bepaal hoe je die stappen zo snel mogelijk laat verlopen met automation. Hoe meer teams je bij je automation strategie aanhaakt, hoe meer tijdswinst je behaalt.

Wat je het liefste zo snel mogelijk wilt automatiseren, zijn beheerwerkzaamheden die regelmatig terugkomen. Daarbij kun je veel winst pakken. Vooral bij vaak terugkerende workloads waar je met wachttijden zit omdat je afhankelijk bent van andere teams, heeft automation een hoop pluspunten. Een activiteit waar elke organisatie mee te maken heeft, is het patchen van servers. Als je dat buiten kantooruren geautomatiseerd laat verlopen, is je voordeel nog groter. Je kunt de automation dan zo instellen dat je enkel handmatig hoeft in te grijpen als een bepaalde patchronde is mislukt en je daarvan een signaal krijgt. Zo kun je ‘s nachts of in het weekend patches draaien met een minimale bezetting. Je investering in automation is op die manier snel terugverdiend. Dat kan zelfs een kwestie van maanden zijn. Overigens kun je ook randzaken in het patchingproces automatiseren, zoals de communicatie naar applicatiebeheerders of eindgebruikers, het bijwerken van een wiki of CMDB. Nog een voorbeeld van een activiteit waarbij automation loont, is het updaten van applicaties die continu beschikbaar moeten zijn. Bij dit soort rolling updates kun je met automation een complex proces inregelen, waarbij je bijvoorbeeld één webserver update terwijl de rest van de webservers doorwerkt. Dat doe je door elke afzonderlijke server uit de monitoring en uit de actieve load balancer-configuratie te halen voordat je deze voorziet van een update. Aan het einde van het proces zitten alle servers weer in de load balancer-configuratie en worden ze actief gemonitord. Zo voer je een upgrade door zonder downtime, ook al bestaat die uit veel verschillende stappen en zijn er meerdere teams bij betrokken.

Netwerken bestaan vaak uit apparatuur van verschillende leveranciers, die je op verschillende manieren aanstuurt en beheert. Je zou dus denken dat het lastig is om automatisch updates door te voeren in je netwerkconfiguratie. Toch is dat geen probleem. Het mooie van bijvoorbeeld Red Hat Ansible Automation Platform, een van de automation tools die we vanuit Conclusion Xforce inzetten, is namelijk dat deze tool zelf uitzoekt welke commando’s nodig zijn voor elk van je netwerkplatformen. Jij beschrijft in een zogenaamd ‘playbook’ wat je wilt updaten, met welke frequentie dat gebeurt en onder welke condities dat mag gebeuren. Ansible zorgt vervolgens onder water dat er per merk de juiste commando’s worden gegeven voor het uitvoeren van de configuratiewijzigingen. Zo adresseer je eenvoudig tientallen uiteenlopende switches en routers.

Daar kunnen we kort over zijn. Een generieke tool zoals Ansible heeft een belangrijk pluspunt. Je kunt er namelijk niet alleen een ‘desired state’ mee afdwingen, je kunt er je hele netwerk dynamisch mee in kaart brengen, over alle apparatuur en merken heen. Switches, routers, firewalls, load balancers, storage … je hebt een actuele situatieschets van zowel de aantallen, de instellingen als het gebruik van alle apparatuur in je netwerkomgeving. Zelfs cloud infrastructuurcomponenten kun je erin opnemen. Denk aan API’s van cloudproviders zoals AWS en Microsoft Azure, ook die kun je via Ansible aansturen. 

Door een centraal versiebeheersysteem zoals GIT te combineren met een automation tool zoals Ansible kun je aan infrastructure-as-a-code doen bij je netwerkbeheer. Dit maakt het gemakkelijk om wijzigingen door te voeren. Het gaat als volgt in z’n werk. In het versiebeheersysteem leg je de gewenste situatie van je netwerkomgeving vast in code, dus wat de instellingen van je verschillende infrastructuurcomponenten zijn. Bij een wijziging van deze parameters zorgt Ansible er met behulp van een trigger voor dat alle componenten automatisch  worden bijgewerkt. Heel handig is dat je op deze manier inzicht hebt in je versiehistorie en daarmee in alle veranderingen die in de loop van de tijd zijn doorgevoerd. Bovendien kun je teruggaan in de tijd, bijvoorbeeld als er op een bepaald moment iets mis is gegaan met een update. En moet je netwerkapparatuur vervangen? Dan configureer je de nieuwe vervangende hardware automatisch volgens de code in je versiebeheersysteem. Infra-as-code is de heilige graal in network automation. Als je die hebt bereikt, dan heb je geen omkijken meer naar het updaten van je infrastructuur.