Wer schon mit Ansible gearbeitet hat weiß, dass das Automatisierungstool ohne Client auskommt. Es pusht die Automation-Playbooks und -Templates vom Automation-Server zum jeweiligen Zielsystem. Damit scheint Ansible eigentlich für das Clientmanagement ungeeignet, denn anders als Server oder Infrastrukturgeräte wie Switches und Router sind Clients nicht rund um die Uhr in Betrieb. Um Aufgaben hier zu automatisieren, bedarf es einer Pull-Funktion, über die sich der Client beim Management melden kann.
Eine häufig unterschätzte Funktion von AWX ist das "Provisioning Callback". Dies erlaubt, dass der "Anruf" eines Clients via Rest-API am AWX-Server den Start eines Templates auslöst. Dabei ändern sich die Laufparameter dieses Templates nicht. Lediglich die eigentliche Ausführung beschränkt sich auf das Zielsystem, das den Callback auslöst.
Diese Funktion beschreibt am besten ein praktisches Beispiel: Sie erstellen ein Ansible-Playbook, das eine bestimmte Software auf ihren Zielsystemen installiert, und erzeugen auf AWX damit ein Automation-Template. Als Inventory – die Liste aller Systeme, die Ansible mit der Automation anspricht – nutzen Sie dabei alle Clients im LAN. In AWX hinterlegen Sie Credentials, die ihrem AWX-Server dabei Root/Admin-Rechte auf den Zielsystemen für die Automatisierung gewähren.
Würden Sie das Template direkt in AWX ausführen, installierte es die definierte Software auf allen Clients. Hier kommt nun der Trick mit dem Callback ins Spiel: Weisen Sie dem Template ein Provisioning Callback zu, gibt Ihnen AWX eine URL zurück, die das Template von außerhalb starten lässt. Den Zugang zum Callback schützt ein Passwort. Ruft nun ein Client die Callback-URL mit dem korrekten Passwort auf, startet AWX das Automation-Template und nutzt dabei die Option "limit", die die Ausführung des Playbooks auf das
...Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.