ANSIBLE AWX
ALS ZENTRALE
AUTOMATION-
PLATTFORM.

Vorab: AWX (das Open-Source-Pendant zu Ansible Automation Platform / 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 (Service-Now, 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.