Soms kan het gebeuren dat er in een instantie van AWX (of Ansible Tower, of Red Hat Ansible Automation Platform) credentials staan opgeslagen die belangrijk zijn, maar die nergens anders terug te vinden zijn. Ga je in zo een geval naar de web interface van AWX, die krijg je overal bij de belangrijke velden $encrypted$ te zien, maar niet de waardes die je zo hard nodig hebt.

Gelukkig is er een manier om via het awx-manage commando deze waardes niet alleen op te vragen, maar ook te laten ontsleutelen.

Niet iedereen is gelukkig genoeg om het budget te hebben voor Ansible Automation Platform (AAP), en sommige mensen gebruiken liever een upstream open-source versie van een product dan de betaalde, ondersteunde, versie. Voor Ansible orkestratie kom je dan al snel uit op Ansible AWX.

Recente versies van AWX zijn alleen geschreven om op een Kubernetes platform te draaien, en uitgerold te worden via een operator. Nu kun je wel een dev versie met podman draaien, maar dat levert ook weer problemen op.

Hoe doe je dat dan als je geen (toegang tot) een Kubernetes cluster hebt? De minikube variant zoals beschreven in de AWX documentatie is alleen bedoelt voor test omgevingen, niet productie… Het antwoord kan zijn: “K3S”. Deze lichtgewicht Kubernetes implementatie is wel geschikt voor productie, en kan ook redelijk eenvoudig geïnstalleerd worden.

In een heterogene server omgeving wil je vaak dezelfde (soort) taken uitvoeren op machines die verschillende distributies draaien. Nu kun je hiervoor verschillende playbooks gebruiken, maar je kunt je playbooks ook slim hiermee om laten gaan en voor één doel ook één playbook gebruiken.

Ansible is een geweldige tool, maar versie verschillen tussen jouw versie van Ansible en die van je collega kunnen voor vervelende problemen zorgen, bijvoorbeeld als je nieuwere functionaliteit probeert te gebruiken dan wat de versie van Ansible van je collega ondersteunt.

Dit probleem wordt alleen nog maar erger als je ook gaat kijken naar de verschillende versies van geïnstalleerde collections, modules, en python dependencies. Gooi daar een sausje van benodigde systeem-pakketten (RPM, DPKG, etc.) overheen, en je eindigt al snel met een “Op mijn machine werkte het wel..” scenario.

Zodra je Ansible playbooks wat interessanter worden kom je al snel op het punt waarbij je minimaal één van de volgende punten tegenkomt:

• Je wilt een bepaalde taak maar één keer uitvoeren, dus niet op alle hosts
• Je wilt een bepaalde taak op een andere host uitvoeren dan de host die het doelwit is van je play
• Je wilt een aantal taken achter elkaar uitvoeren op één host, voordat het play doorgaat naar de volgende host.

In veel gevallen is het nuttig om in je Ansible playbooks bepaalde acties te laten afhangen van het wel of niet iets gewijzigd hebben in een vorige stap. Zo kun je bijvoorbeeld het laten herstarten van een Web server laten afhangen van het gewijzigd zijn van een configuratie.

Red Hat heeft begin maart aangekondigd dat de Red Hat Enterprise Linux (RHEL) System Roles Collection gecertificeerd is voor het Ansible Automation Platform. Dat geleverd gaat worden aan organisaties via Ansible Automation Hub. Dit betekent dat vanaf de aankomende RHEL 8.4 release de System Roles Collection beschikbaar komen onder Tech Preview en gepland staan om volledig ondersteund te worden. Geen vervelende, foutgevoelige handmatige handelingen en configuratie meer… De RHEL system roles bieden dé oplossing naar een herhaalbare en voorspelbare configuratie.

Ansible en OpenShift zijn uitermate goed samen te gebruiken. In dit artikel zullen we kijken hoe we Ansible kunnen inzetten om een OpenShift cluster te beheren en applicaties uit te rollen op een OpenShift cluster. Traditioneel worden applicaties uitgerold vanuit OpenShift templates, Helm charts, pipelines en soortgelijke tools. In dit artikel zullen we de basis leggen voor het uitbreiden of vervangen van deze deployment methodes met Ansible.

In navolging van Ansible Automates 2019 werd er op 17 februari ‘Tech Talk Next Level Ansible’ georganiseerd. Tijdens Ansible Automates gaf Maxim Burgerhout een ijzersterke demo waarbij een Enterprise multi-cloud omgeving werd opgezet met Ansible Tower. Sprekers Maxim Burgerhout en Fred van Zwieten van Red Hat gaven ons tijdens de Tech Talk een kijkje onder de motorkap van deze live-demo voor zowel Windows als Linux. In deze blog geef ik een verslag van deze demo’s en neem ik je mee in de opmerkelijke verschillen tussen beiden.

Onder de gastvrije, nuchtere en open begeleiding van Jasper Geraerts hebben wij afgelopen woensdag een verfrissende reis mogen maken in de waanzinnige wereld van Ansible Automation tijdens Red Hat Ansible Automates 2019 in Bussum. Hoe hebben we de dag ervaren? En wat zijn onze take aways? Lees mijn uitgebreide verslag van Ansible Automates 2019.