Ansible ervaringen en tips uit de praktijk

Op onze IT afdeling maken we al geruime tijd gebruik van Ansible om onze repeterende IT taken te automatiseren. Ben Wismans, system manager bij Proxy, is een van de enthousiaste gebruikers die hier dagelijks intern mee werkt en ook onze klanten ondersteunt met het inrichten van Ansible in hun werkomgeving. In dit blog deelt hij zijn ervaringen met Ansible, hoe wij hier intern mee zijn begonnen, geeft hij antwoord vanuit de operatie op de vraag: waarom eigenlijk automatiseren en deelt hij een paar waardevolle tips.

Elke keer als ik met Ansible aan de slag ga, valt het me op hoe snel en gemakkelijk je echt wat voor elkaar krijgt. Ik ben altijd al bezig geweest met het automatiseren van repeterende taken. Dit gebeurde natuurlijk veel in scripts. Maar vaak specifiek voor één platform. Bijvoorbeeld Powershell voor Microsoft software of Bash voor Linux. Of specialistische script talen voor apparaten, zoals storages of switches. Ik heb veel ervaring met scripten in de meest uiteenlopende talen. Voor mij is het vaak even de 'spelling en de grammatica' onder de knie krijgen en dan lukt het wel om repeterende taken te automatiseren. Ik heb echter nog nooit een toolkit gezien die alles kan. En ook nog snel en makkelijk!

Waarom automatiseren?

Ik zal eerlijk zijn: Ik houd niet van repeterende taken. Ik ben er niet goed in. Als ik vroeger bijvoorbeeld veel gebruikers aan moest maken, dan werd het altijd een rommeltje. Veel tikfouten, namen niet consistent, en altijd verzon ik er halverwege weer wat bij, bijvoorbeeld dat extra velden, zoals company en telefoonnummer ook ingevuld moesten worden. Als je dan niet weer vooraan begint, dan wordt het geen consistent geheel meer. En wie mij een beetje kent, weet dat ik erg van consistentie houd. Daarnaast ben ik lui. Erg lui. Ik heb liever dat ik iets op 1 plek aanpas, dan dat ik op 20 plekken hetzelfde aan moet passen. Scheelt het tijd? Ik weet het niet. Het automatiseren en het testen kost tijd. Misschien wel meer dan repeterend met de hand. Het resultaat is echter altijd consistent en kleine aanpassingen zijn later altijd makkelijker door te voeren. De waarde daarvan zie ik echt als een besparing.

Hoe zijn wij begonnen met Ansible?

Met Ansible beginnen is eigenlijk erg makkelijk. Je begint gewoon met een inventory waarin je je omgeving beschrijft. Daarbij begin je met enkele servers die op elkaar lijken. Deze zet je in een groep en daarmee ga je aan de slag. Zodra je met je playbook aan de gang gaat, kom je er vanzelf achter dat het handig is om meerdere groepen aan te maken. Denk bijvoorbeeld aan webservers of een database cluster. Je kunt een server in meerdere groepen plaatsen. Je krijgt dus groepen voor specifieke doelen. Enkele voorbeelden van groepen die bij ons gebruikt worden zijn: proxy-openshift-nodes, proxy-icinga2-clients, proxy-windows, proxy-linux en proxy-routers. Het resultaat van je inventory is een lijst met groepen met daarin de systemen.

Let op: juist het makkelijke gebruik van Ansible is vaak een valkuil om geen goede toekomstbestendige structuur aan te brengen. Lees ook onze 5 tips om succesvol met Ansible te beginnen.

De eerste playbook in Ansible

Met je inventory ga je vervolgens aan de slag met een playbook. Je begint met het beschrijven van het doel en op welke groep systemen dit playbook van toepassing is. Al snel ga je de taken beschrijven die op deze groep uitgevoerd moeten worden. Wij zijn ooit begonnen met het beschrijven van de inrichting van een Proxy account. Dit bestaat onder andere uit de volgende stappen:

• Account aanmaken
• Wachtwoord instellen
• Authorized keys inrichten
• Bash profile instellen

In het playbook kom je deze stappen steeds als taak tegen. Als je gaat zoeken naar voorbeelden van playbooks, dan kom je erachter dat deze erg leesbaar zijn. Ook als je maar weinig kennis hebt van Linux kun je toch begrijpen welke stappen uitgevoerd worden om een webserver in te richten.

Let op: niemand is hetzelfde

Geen enkel systeem is gelijk. Alleen al de naam of het IP-adres is al anders. Servers in een cluster zijn op veel punten gelijk maar hebben wel een uniek ID. In je playbook kun je deze verschillen in lijsten beschrijven, maar liever doe je dat centraal: in je inventory, zodat je alles op 1 plek hebt staan. Meerdere playbooks maken namelijk gebruik van dezelfde inventory. Het is dus logisch dat je daar de variabelen in zet. De inventory is dus je centrale plek waar je je omgeving beschrijft.

Variabelen kun je zetten op host, groep of globaal. Configureer bijvoorbeeld een wachtwoord voor een hele groep (natuurlijk niet in plain tekst, maar netjes encrypted). Het wijzigen van een wachtwoord is dan een kwestie van variabelen aanpassen en het playbook draaien in Ansible!

Security binnen Ansible; vertel niemand je geheimen

Je kunt natuurlijk geen wachtwoorden in je inventory file zetten. Als je versiebeheer gebruikt, kun je het natuurlijk verwijderen maar in oudere versies blijft het wachtwoord zichtbaar. Gelukkig kun je gevoelige gegevens beveiligen in de Ansible Vault. Zie dit als een kluis. De informatie wordt dan beveiligd met een password file of een vault password. De inventory kun je vervolgens met een gerust hart in je versiebeheer zetten.

Versiebeheer

Alle onderdelen van Ansible zijn simpele tekst files. Ideaal voor versiebeheer. Als je al ontwikkelaars in dienst hebt, dan is de kans groot dat er al een tool gebruikt wordt voor versiebeheer (in veel gevallen zal dit Git zijn). Mooi moment om samen te werken! Hoe mooi zou het zijn als de ontwikkelaars ook meteen een Ansible script mee leveren om de applicatie te installeren?

Probeer je wijzigingen goed bij te houden. Zo zijn je collega’s op de hoogte wie, wat, wanneer heeft gewijzigd en kun je eenvoudig veranderingen terugdraaien, mocht dat nodig zijn. De trend is Infrastructure as Code, ofwel DevOps. Versiebeheer is daar een belangrijk onderdeel in.

Rolverdeling

Als je meerdere playbooks hebt geschreven, kom je erachter dat sommige onderdelen terugkomen in meerdere playbooks. Voor deze onderdelen kun je een role maken. In je playbook hoef je vervolgens alleen maar een verwijzing te maken naar deze role. De meeste rollen worden universeel opgezet. Met variabelen kun je deze rollen dan bijsturen. Een role voor het aanmaken van gebruikers zal variabelen hebben voor de naam en het wachtwoord. Rollen hoef je in veel gevallen niet zelf te verzinnen. Op de website Ansible Galaxy is voor bijna elke toepassing wel een voorbeeld te vinden. Let er wel op dat de kwaliteit niet gecontroleerd wordt. Kijk de role die je download daarom altijd zelf nog even na.

Verdeel en heers

Sommige playbooks moeten regelmatig (gepland) gestart worden. Playbooks met security-richtlijnen zorgen ervoor dat de systemen beveiligd blijven. Als iemand dan SELinux of de firewall tijdelijk uitzet, wil je natuurlijk wel dat deze weer aangezet wordt. Door het playbook gepland te laten starten zorg je ervoor dat de systemen altijd aan de security-richtlijnen blijven voldoen. Je kunt dit natuurlijk inplannen in bijvoorbeeld een crontab, maar dat wordt met veel playbooks al snel onoverzichtelijk.

Voor dit probleem is Ansible Tower een mooie oplossing. In Tower kun je precies terugzien wie wat, wanneer heeft uitgevoerd. Ook minder ervaren gebruikers kunnen playbooks starten. Of je kunt de API gebruiken om playbooks geautomatiseerd te starten. Bij Proxy gebruiken we dit om plug-ins voor Icinga geautomatiseerd te deployen naar alle servers. Wanneer we een script aanpassen via een push naar Gitlab, wordt daarna automatisch het playbook gestart die de laatste versie op alle servers zet.

Zelf aan de slag met Ansible?

Geïnteresseerd in Ansible en wil je zelf je eerste stapjes zetten in IT Automation? Op diverse data geef ik de gratis workshop Ansible, waarbij ik je leer hoe je Ansible in de praktijk kunt gebruiken en we ook direct hands-on aan de slag gaan. Zie ik je daar?

En toen ging het mis...

Wie wel eens aanpassingen in de configuratie van Sudo heeft gedaan, weet dat je jezelf buiten kunt sluiten als je tikfouten maakt. Het commando visudo beschermt je daartegen, maar dat helpt niet als je de configuratie los trekt in losse onderdelen in /etc/sudoers.d/. In mijn Ansible role maakte ik een tikfout. En fanatiek deployde ik deze kleine wijziging naar tientallen servers. Toen ik erachter kwam dat ik geen sudo meer kon doen door deze tikfout, besefte ik dat het niet gemakkelijk werd om deze fout te herstellen. Ik had namelijk sudo (root) rechten nodig om dit te doen, maar doordat sudo stuk was kon ik deze rechten niet krijgen. Ik heb dit met de hand op tientallen systemen, via de console, moeten herstellen. Niet leuk...

Wat heb ik ervan geleerd? Begin klein. Test _elke_ deployment eerst op een beperkte set servers. Wijzigingen rol je snel uit maar fouten kun je even snel maken. Gelukkig kun je in de meeste situaties ook weer Ansible gebruiken om je fout te herstellen. Kom je er toch niet uit? Ik help je graag!