Wer einmal auf den Geschmack gekommen ist, IT-Abläufe mit Ansible zu automatisieren, wird in kürzester Zeit einen großen Haufen an Playbooks in einem – mehr oder weniger – sortierten Verzeichnisbaum anhäufen. Mitten unter den Playbooks finden sich dann auch Login-Informationen, Passwörter und private Schlüssel, die die Playbooks zur Authentisierung mit Zielsystemen benötigen. Kein Administrator wird dieses Verzeichnis also mit anderen teilen. Doch eine der Stärken von Ansible ist die Möglichkeit, Automatisierungen von verschiedenen Teams und Autoren zu leistungsstarken Workflows zusammenzuführen.

Bevor das Unternehmen Ansible von Red Hat übernommen wurde, vertrieb die Firma das kommerzielle Closed-Source-Tool "Ansible Tower". Nach der Übernahme hat Red Hat das Werkzeug, genauer gesagt die Entwickler-Sourcen zukünftiger Versionen, quelloffen im Project "AWX" veröffentlicht. Wie "Ansible Controller" (der neue Name von Tower) durchläuft auch AWX aktuell einen massiven Wandel. Red Hat trennt sich vom monolithischen Design eines Diensts in einer einzelnen virtuellen Maschine und baut AWX zu einer Reihe von Containern um, die auf einer Kubernetes-Plattform laufen. Daher ist es aktuell nicht ganz einfach, AWX zum Laufen zu bekommen, aber dazu später mehr im Artikel.

Ordnung ins Chaos bringen
AWX bringt eine Reihe wichtiger Funktionen für Teams mit. Zuerst sortiert es Playbooks in "Projekte". Hinter jedem Projekt steht ein Git-Repository, das den eigentlichen Ansible-Code enthält. Innerhalb der Projekte erstellt der Administrator "Templates". Jedes "Job-Template" verweist auf ein Playbook, kann aber gesonderte Variablendeklarationen und Credentials enthalten. Mehrere "Job-Templates" lassen sich zu einem "Workflow-Template" zusammenfügen.

Wer also von Anfang an, wie in den vorhergehenden Artikeln beschrieben, die Logik von den Variablen getrennt hat, kommt schnell mit AWX zurecht. Templates aus einem Project dürfen über eine "requirements"-Datei auch auf Ansible-Quellen aus anderen Git-Repositories zugreifen. So können Administratoren Workflows mit dem Code verschiedener Teams zusammenfügen.

Die schicke UI von AWX verfügt zudem über sogenannte "Surveys". Das sind grafische Dialoge, die Nutzereingaben in Variablen übernehmen und an die Automatisierung weitergeben. Damit eignet sich AWX auch sehr gut als "Self-Service-Portal" für Nutzer, die Workflows starten dürfen, aber die Details dahinter, wie den Ansible-Code oder Credentials, nicht zu Gesicht bekommen sollen.

Ein sehr wichtiges Kernelement von AWX sind daher die "Credentials", hinter denen das Tool "Ansible Vault" steht. Hier kann der Administrator alle nötigen Zugangscodes wie Passwörter, Zertifikate und Schlüssel sicher aufbewahren. Einmal im Vault eingefügt, lassen sich die Geheimnisse nicht mehr in Benutzer-lesbarer Form exportieren. Weist ein Administrator einem Template ein Credential zu, werden die darin gespeicherten Geheimnisse nur während der Playbook-Ausführung in einem Python-Virtual-Environment entschlüsselt und zur Verfügung gestellt.

Im sogenannten vEnv stehen die Secrets dann entweder als Environment-Variablen oder als Ansible-Variablen zur Verfügung, die das darin laufende Playbook aufgreift. AWX verwaltet Nutzer und Gruppen mit verschiedenen Zugriffsrechten. Ein Administrator kann Credentials und Templates erstellen. Ein gewöhnlicher Nutzer darf dann ein solches Template mit den Credentials des Administrators per Klick ausführen. Er hat jedoch keine Möglichkeit, den Code des Playbooks oder die Zugangsdaten einzusehen sowie die Credentials für irgendetwas anders als dieses eine Template zu nutzen.

Damit kann der Administrator einen komplexen Automatisierungs-Workflow anlegen, wie beispielsweise: Erstelle eine VM auf EC2 und installiere eine Webapplikation. Im Template stecken die Secrets zum Zugriff auf EC2 und der private SSH-Key für die EC2-VM. Der ausführende Nutzer kann diese Zugangsdaten aber nur im Rahmen des erlaubten Templates nutzen. AWX offeriert Credential-Typen für gängige Systeme wie Git, AWS, vSphere oder SSH-Keys. Der Administrator kann aber auch eigene Credential-Typen erstellen und in seiner Automatisierung nutzen.

AWX installieren
Aktuell gibt es zwei Wege, AWX zum Laufen zu bekommen. Der eine ist relativ simpel, erfordert jedoch eine Kubernetes-Umgebung. Der zweite braucht lediglich einen Rechner mit Docker und Docker-Composer, dafür muss der Administrator ein wenig um Bugs im Roll-out herumtüfteln.

Jetzt werden viele fragen: Warum der ganze Container-Aufwand, wo Tower 3.x sich doch stabil und simpel in einer einzelnen VM installieren lässt? Die Gründe liegen in der Skalierung und Geschwindigkeit. In einer klassischen Tower-Installation führt die lokale Ansible-Installation in einem Python-vEnv die Templates aus. Das geht mit ein paar Dutzend Zielsystemen noch ganz gut, bei hunderten dauert es etwas länger. Hier kommen nun die Projekte "Ansible Builder" und "Ansible Runner" ins Spiel.

Mit Builder bauen Sie sich individuelle Container-Templates (Runner) mit Ansible und ein paar wenigen, dringend benötigten Python-Dependencies zusammen. Als Plattformen der Container kommen Docker oder Podman zum Einsatz. Starten Sie nun ein Template für ein großes Inventory mit hunderten Zielsystemen, kontaktiert AWX eine Kubernetes-Umgebung und ordert dort ein "Execution Environment" aus mehreren der zuvor per Builder erstellten Runner-Containern. Dann schickt AWX das Template mit einem segmentierten Inventory an alle Runner-Container zur parallelen Ausführung.

Der neue Ansible-Controller und AWX bestehen daher selbst aus mindestens zwei PODs mit drei Containern: Ein separater POD beherbergt die Postgres-Datenbank. Der Administrator kann sich diesen POD auch sparen und mit einem bestehenden PostgreSQL-Server arbeiten. Ein weiterer POD betreibt mindestens zwei Container: den AWX-Controller selbst und Redis für die Kommunikation zwischen PODs und Containern. Im Standardsetup bring AWX einen dritten Container namens "AWX-Task" mit. Dieser Runner führt in der Grundkonfiguration Playbooks aus, solange Sie kein zusätzliches "Excecution Environment" für die Skalierung anlegen.

ln/dr/Andreas Stolzenberger

Im zweiten Teil der Workshopserie zeigen wir, wie Sie AWX im Zusammenspiel mit Kubernetes und Docker Compose nutzen und Playbooks für AWX anpassen.