Betreed de automatiseringsdroom met Ansible en AWX
Duik in de wereld van automatisering en ontdek hoe het je hoofd leeg kan maken en je IT-werk een stuk overzichtelijker en rustiger maakt.
Automaception
Ik probeer mijn werk—het beheren van IT-infrastructuren—zo relaxed mogelijk te benaderen. Dat betekent paradoxaal genoeg dat ik enorm veel tijd besteed aan het optimaliseren van mijn werk. Gelukkig lenen machines zich daar uitstekend voor (het spel Factorio slokt meer tijd op dan ik wil toegeven). Computers nog meer, wat waarschijnlijk de helft is van de reden dat ik in dit vakgebied werk. Dus toen ik werd geïntroduceerd aan Ansible, was ik meteen verkocht.
Het stelde me in staat om computers zichzelf te laten beheren met één druk op de knop. Je kunt infrastructuurconfiguratie netjes organiseren in groepen en rollen, en de community levert collections om een enorme hoeveelheid componenten te beheren. Het optimaliseren van het Ansible-book en ervoor zorgen dat het serverpark correct is geconfigureerd en dat wijzigingen op een georganiseerde manier door de servers worden doorgevoerd, is een heerlijke uitdaging. Het afronden van (een deel van) zo’n Ansible-book voelt als pure bliss: je runt het playbook en de controller doet al het werk voor je. En jij? Jij hebt alle tijd om achterover te leunen en naar de automatisering te kijken.
Maar juist daar ontstaat langzaam een klein jeukje. Het begint achter in je hoofd, op een sarcastische toon:
Vind je het niet heerlijk om op knoppen te drukken zodat computers dingen doen?
En eerst snap je het niet, maar dan voegt het eraan toe:
Zou het niet fijn zijn als je dát ook kon automatiseren?
En zo ontstaat een vicieuze cirkel.
Dus natuurlijk dacht een genie (of eigenlijk meerdere) eraan om de automatisering te automatiseren, en zo werd AWX geboren (de upstream versie van de Ansible Automation Platform). Maar dat is natuurlijk nog niet genoeg: we automatiseren ook weer de automatisering die de automatisering automatiseert—de configuratie van de controller. Dit is het verhaal van een mogelijk pad dat je kunt bewandelen, langs al die schildpadden.
Disclaimer: Je hoeft niet veel te weten van AWX en/of de infra.controller_configuration collection om dit artikel te lezen. Maar als je van plan bent mijn pad te volgen, raad ik aan om je er wel in te verdiepen. Het helpt in ieder geval als je conceptueel begrijpt hoe Ansible werkt.
Ik sla het begin van mijn reis over en drop je een paar maanden later, op het punt waar het jeukje in mijn hoofd te luid werd om te negeren. Op dat moment beheerde het team waar ik deel van uitmaak ongeveer 500 virtuele en fysieke servers met één groot Ansible-book. We draaiden handmatig zó veel playbooks dat we er gek van werden. We hadden net AWX draaien en zaten midden in de migratie, toen een toetsenbord-liefhebbende collega luid klaagde:
“Ik heb het gevoel dat ik ben teruggevallen naar klikken in de AWX-webinterface in plaats van echt iets te automatiseren!”
Iedereen wist: zo’n opmerking betekent dat hij ergens op zit. En inderdaad—het bleken er zelfs twee te zijn:
- Het beheren van de daadwerkelijke Ansible-code en projecten die in AWX zijn opgeslagen en uitgevoerd
- Het beheren van AWX zelf en de executies van die code
In dit artikel focus ik me op het beheer van AWX zelf. De migratie laat ik graag over aan een ander moment—en misschien ook aan een andere schrijver.
AWX beheren
Deze nieuwe laag van automatisering die we hebben uitgerold, heeft zijn eigen configuratie die is opgeslagen in een database. Je kunt deze configuratie aanpassen via de AWX API of door te klikken in de webinterface. Dat zijn echter handmatige acties—en die vermijden we liever. De infra.controller_configuration collection helpt hierbij door een Ansible-manier te bieden om de AWX-configuratie te beheren.
We zijn AWX en alle bijbehorende componenten gaan configureren via een Ansible playbook. Dat resulteerde in een playbook dat onder andere de volgende onderdelen van AWX configureert:
-
Globale AWX-instellingen, zoals loginstellingen, LDAP-configuratie (inclusief globale admins en auditors) en algemene properties van deze AWX-instance.
-
Organisaties, teams en hun rollen binnen organisaties.
-
Execution Environments, want de standaardomgeving werkt eigenlijk alleen voor een ‘proof of concept’.
-
Container groups, omdat de default-instelling in de praktijk zelden goed werkt.
-
Credentials, die allemaal afkomstig zijn uit HashiCorp Vault.
-
Projects, uiteraard ingeladen vanuit Git-repositories.
-
Inventories, inclusief variabelen, eveneens uit Git-repositories.
-
Job templates, zodat je wijzigingen gefaseerd kunt uitrollen in plaats van alles in één keer.
-
Schedules, om die jobs daadwerkelijk te laten draaien.
-
Notifications, zodat bij mislukte jobs automatisch een Jira-issue wordt aangemaakt en we een melding krijgen in onze chatapplicatie.
Als we nog op de eerste ‘schildpad’ zaten, zouden we al deze code schrijven, integreren in ons grote Ansible-book en samen met de rest uitvoeren. Maar we waren al een niveau dieper gegaan, dus plaatsten we al deze code in een apart Ansible-book. Dat draaiden we, waarna AWX het grote Ansible-book uitvoerde. Het was bliss.
Die bliss was helaas van korte duur. Niet lang daarna ging AWX ‘stuk’. Oftewel: iemand wijzigde de hierboven beschreven AWX-configuratie, deployde een nieuwe ‘feature’, maakte een fout en alles kwam tot stilstand.
Het team kwam al snel met een keurig proces om dit te voorkomen: iemand anders moest de wijzigingen reviewen en goedkeuren voordat ze in onze Ansible-books werden geïntegreerd. Bij grote wijzigingen zouden zelfs twee collega’s meekijken. Een prachtig proces—met één klein probleem: we waren weer terug bij af. We besteedden opnieuw enorme hoeveelheden tijd aan het dubbel en driedubbel checken van code. Dit diepere schildpadniveau leek ineens een stuk minder nuttig.
Maar als Inception ons één ding heeft geleerd, is het dat je altijd nóg een niveau dieper kunt. Dus daalden we af naar de volgende schildpad.
Daar komt GitOps om de hoek kijken—meer specifiek met GitLab (lees de afsluitende opmerkingen als je verbaasd bent dat we dit niet al gebruikten). We maakten een GitLab-project aan, uploaden het Ansible-book met de AWX-code en bouwden een CI/CD-pipeline om ons van handmatig werk te verlossen. Die pipeline bestaat uit de volgende stappen:
-
Controleert onze YAML-bestanden op correcte syntax met yamllint.
-
Controleert de Ansible-code op valkuilen met ansible-lint.
-
Scant op potentiële kwetsbaarheden met de geautomatiseerde security-scans van GitLab.
-
Voert een dry-run uit van de volledige code.
-
Deployt de wijziging naar onze staging AWX-instance.
-
Deployt de wijziging naar productie, maar alleen na expliciete goedkeuring en planning.
De scherpe lezer ziet dat er nog steeds een handmatige actie in zit. Dat klopt. Maar we hoeven ons geen zorgen meer te maken over syntaxfouten, typfouten of eenvoudige bugs—en dat allemaal zonder op knoppen te drukken. Dankzij een staging AWX-instance kunnen we bovendien eenvoudig testen of een wijziging iets breekt, in plaats van daar alleen theoretisch over na te denken.
Naast het feit dat we dit niet meer zelf hoeven uit te voeren of op deploys hoeven te wachten, is ons change management ook aanzienlijk verbeterd:
- Elke wijziging is gekoppeld aan een Jira-issue.
- Een meerderheid van het team moet goedkeuren, en die goedkeuring wordt vastgelegd.
- Er is meer tijd om eindgebruikers te informeren over aankomende wijzigingen.
- Terugdraaien is eenvoudig.
- Security- en compliance-scans leveren extra inzichten om onze infrastructuur te verbeteren.
- Code quality-rapporten en testresultaten zijn automatisch beschikbaar voor de compliance-afdeling.
Conclusie
Deze nieuwe manier van werken met Ansible biedt het team niet alleen een robuustere manier om de infrastructuur te beheren, maar zorgt ook voor meer schaalbaarheid. Naast de voordelen voor onszelf krijgt de organisatie bovendien beter inzicht in de status van de onderliggende infrastructuur.
Maar het belangrijkste resultaat is natuurlijk dit: ik kan nu eindelijk achteroverleunen en toekijken hoe onze servers zichzelf beheren. Een heerlijk gevoel—een klus die goed is geklaard. Mijn team en ik hebben nu de tijd om na te denken over nieuwe features of om de organisatie te helpen zichzelf verder te verbeteren. Moet er iets aangepast worden? Dan pas ik de code aan, commit deze naar GitLab en kijk hoe de magie zich ontvouwt. Een waar technologisch wonder.
…
“Hou je er niet van om op knoppen te drukken zodat computers dingen doen?”
…
“Zou het niet fijn zijn als je dat ook kon automatiseren?”
Zal ik dat irritante stemmetje in mijn hoofd ooit het zwijgen kunnen opleggen? Of kan AI dat stemmetje misschien eindelijk voor me stil krijgen?
Tot slot
Deze blogpost is gebaseerd op een echte implementatie die ik voor een klant heb uitgevoerd, maar sommige onderdelen zijn aangepast om beter bij het verhaal te passen. Enkele kanttekeningen bij deze aanpassingen:
- GitOps werd al gebruikt, maar is verder uitgebreid en goed geïntegreerd in plaats van volledig vanaf nul geïmplementeerd.
- Veel randzaken zijn vereenvoudigd of weggelaten; anders was dit artikel al snel uitgemond in een whitepaper.
- Naar mijn mening is het implementeren van secret management in AWX geen triviale aangelegenheid en vraagt dit om veel aandacht en zorgvuldigheid.
- De manier waarop wijzigingen in je Ansible-books doorwerken in je projecten en jobs is een interessante, maar uitdagende puzzel op zich.
AWX wordt uitsluitend ondersteund via de AWX-Operator op Kubernetes. Dat zijn draken—je bent gewaarschuwd. Maar eerlijk is eerlijk: ze zijn wel ontzettend cool.
