ANSIBLE AWX
ALS ZENTRALE
AUTOMATION-
PLATTFORM.

Vorab: AWX (das Open-Source-Upstream-Projekt des automation controller in Red Hat Ansible Automation Platform, früher Ansible Tower) ist eines dieser Tools, die nach "müssen wir uns mal anschauen" klingen und dann unauffällig zur wichtigsten Plattform im Operations-Stack werden. So ist es bei uns passiert.

01 WO WIR HERKOMMEN

Vor 18 Monaten lief jede Automation-Aufgabe bei uns aus einzelnen Ansible-Playbooks, die unsere Engineers von ihren Laptops gestartet haben. Das skaliert genau so lange, bis (a) jemand mit der falschen Inventory-Datei startet, (b) Secrets in Klartext rumliegen, (c) niemand mehr weiß, was wann gegen welche Umgebung gelaufen ist.

Wir hatten alle drei Punkte erlebt.

02 SETUP

Eine zentrale AWX-Instanz, deployed in unserem OpenShift-Cluster, mit folgenden Eigenschaften:

• Organizations als oberste Trennung: eine pro Kunde plus eine für EGW-intern.
• Teams innerhalb der Organizations: getrennte Rollen für Netzwerk, Server, Security.
• Inventories dynamisch aus unserer NetBox-Instanz gezogen. Keine handgepflegten Listen mehr.
• Credentials kommen aus HashiCorp Vault. AWX selber speichert keine Klartext-Secrets.
• Project-Updates über Webhooks aus Git. Neue Playbook-Versionen sind sofort verfügbar.

03 MULTI-TENANT-PATTERNS

Mandantentrennung ist bei AWX vor allem eine Frage der Organization- und Team-Konfiguration. Wir haben gelernt, dass es lohnt, hier konservativ zu sein:

• Keine Cross-Org-Inventories. Wenn ein Engineer Zugriff auf Kunde A und Kunde B braucht, ist er Mitglied beider Orgs.
• Eigene Execution-Environments pro Kunde, wenn die Ansible-Collections kritisch divergieren.
• Audit-Logging zentral nach Loki + Grafana: wer hat wann gegen welches Ziel was gestartet.

04 SELF-SERVICE FÜR FACHABTEILUNGEN

Das war der unerwartete Win: AWX-Surveys (das eingebaute Formular-System) erlauben es, standardisierte Aufgaben für Nicht-Engineers verfügbar zu machen. Beispiel: ein Admin in der Buchhaltung kann selber ein Ad-hoc-Reporting-Skript gegen die Datenbank starten, ohne Ticket. Das Skript läuft aber unter unseren Credentials, mit unseren Berechtigungen, mit unserem Audit-Trail.

05 WAS WIR GELERNT HABEN

• AWX-Upgrades sind nicht trivial, vor allem zwischen Major-Versionen. Snapshot der Postgres-DB vor jedem Upgrade, immer.
• Sync-Performance degradiert ab ein paar tausend Hosts spürbar. Wir splitten dann in mehrere AWX-Instanzen.
• Workflow-Jobs sind unterschätzt: Sie können komplexe Multi-Step-Operationen orchestrieren, ohne den Playbook-Code aufzublähen.
• Templates als API: Wir rufen AWX-Jobs auch aus anderen Tools (ServiceNow, Jira) per REST-API auf. AWX wird so zur Automation-Engine, nicht nur zum UI.

Sprechen Sie mit uns, wenn Sie eine Automation-Plattform brauchen: Kontakt-Seite oder +43 (0)1 235 1277.