Betrieb & Monitoring
AWX
AWX ist das quelloffene Web-/API-Frontend für Ansible (Upstream der Ansible Automation Platform): zentrale Ausführung, RBAC, Credentials, Scheduling und Workflows.
- Web-UI und REST-API für Ansible
- RBAC und verschlüsselte Credentials
- Job Templates, Workflows, Scheduling
- Execution Environments (Container)
- Apache 2.0, Upstream der AAP
AWX ist das quelloffene Web- und API-Frontend für Ansible. Statt Playbooks verstreut per CLI auf einzelnen Rechnern auszuführen, bündelt AWX die Ausführung zentral: mit Weboberfläche, REST-API, rollenbasierten Rechten, verschlüsselter Secret-Verwaltung und Auditierung. AWX ist das Upstream-Projekt der kommerziellen Red Hat Ansible Automation Platform, vergleichbar mit dem Verhältnis von Fedora zu RHEL.
Dieser Artikel erklärt AWX als Management-Layer, die Kernfunktionen (Projects, Job Templates, Inventories, Credentials), das RBAC-Modell, Surveys und Workflows, die Execution Environments, das verteilte Receptor/Automation Mesh, das Deployment über den AWX Operator auf Kubernetes sowie das sachliche Verhältnis zur Ansible Automation Platform inklusive der aktuellen Release-Pause.
1. Management-Layer über Ansible
AWX fügt Ansible einen zentralen Steuerungs- und Kontroll-Layer hinzu. Alle Ausführungen laufen über die Plattform, werden protokolliert und über Rechte abgesichert. Projects binden ein Git-Repository mit Playbooks an, Job Templates verknüpfen ein Playbook mit Inventory, Credentials und Parametern zu einer wiederverwendbaren, parametrisierten Ausführungseinheit. Inventories verwalten die Ziel-Hosts, statisch oder dynamisch aus Cloud-/CMDB-Quellen.
2. Credentials und RBAC
Credentials werden verschlüsselt in der Datenbank gehalten und nie über die API im Klartext sichtbar gemacht; sensible Werte werden zur Laufzeit über Named Pipes übergeben. Externe Secret-Stores wie HashiCorp Vault, CyberArk, Azure Key Vault oder AWS Secrets Manager lassen sich als Credential-Plugins anbinden (Abruf zur Laufzeit, keine lokale Speicherung). Das RBAC ist hierarchisch: Organizations bündeln Ressourcen, Teams bündeln Nutzer, und Rollen (Admin, Execute, Use, Read) werden feingranular bis auf einzelne Objekte vergeben.
Der eigentliche Gewinn von AWX ist nicht die schicke Oberfläche, sondern die Entkopplung von Mensch und Geheimnis: Ein Mitarbeiter kann ein Playbook gegen Produktivsysteme starten, ohne je das zugehörige Passwort oder den SSH-Key zu sehen. Genau das fehlt der verteilten CLI-Nutzung.
3. Surveys, Workflows und Scheduling
Surveys sind einfache Eingabeformulare vor dem Jobstart; sie erlauben auch Nicht-Technikern, parametrisierte Jobs als Self-Service zu starten. Workflows verketten mehrere Job Templates, Project- und Inventory-Syncs zu einem gerichteten Graphen mit Verzweigung nach Erfolg, Fehler oder „immer“ und Konvergenz-Knoten. Schedules führen Jobs zeitgesteuert (cron-basiert) aus, Notifications melden Start, Erfolg oder Fehler über E-Mail, Webhook, Slack und weitere Kanäle.
4. Execution Environments und Automation Mesh
Execution Environments (EE) sind Container-Images, die Ansible, Python-Abhängigkeiten und Collections reproduzierbar bündeln; sie lösten die früheren Python-Virtual-Environments ab und werden mit ansible-builder erstellt. AWX zieht das passende Image vor der Job-Ausführung. Receptor bildet das Automation Mesh: ein Overlay-Netz, das Control-Knoten (Dienste) von Execution-Knoten (Job-Ausführung, podman-isoliert) trennt und so geografisch verteilte Ausführung erlaubt.
5. Deployment und Verhältnis zur AAP
AWX wird nicht mehr klassisch per Paket installiert, sondern ausschließlich über den AWX Operator auf Kubernetes/OpenShift betrieben (mehrere Pods: Web, Task, PostgreSQL, Redis, Receptor). Das Verhältnis zur Ansible Automation Platform (AAP) ist klar: AWX ist schnell und „bleeding edge“, aber ohne Hersteller-Support und ohne garantierten Upgrade-Pfad; Red Hat empfiehlt es ausdrücklich nicht für Produktion. AAP ist die gehärtete, supportete und kommerziell lizenzierte Variante mit definiertem Lifecycle; Red Hat verweist für produktionskritische Umgebungen auf die AAP.
Release-Pause beachten
Seit Mitte 2024 sind die AWX-Releases im Rahmen eines größeren Refactorings pausiert; Commits laufen weiter, neue Versionen erscheinen vorerst nicht. Wer AWX produktiv einsetzt, sollte das bei Sicherheits-Patches und Upgrade-Planung berücksichtigen und die kommerzielle AAP als Alternative kennen.
6. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Zentrale, auditierbare Ausführung statt verteilter CLI | Läuft nur auf Kubernetes: zusätzlicher Betriebsaufwand |
| RBAC und Credential-Isolation (Secrets bleiben verborgen) | Kein Red-Hat-Support; nicht für Produktion empfohlen |
| REST-API für CI/CD- und ITSM-Integration | Release-Pause seit 2024, kein fester Zeitplan |
| Workflows, Surveys und Scheduling für Self-Service | Ressourcenintensiver als reines CLI-Ansible |
| Execution Environments: reproduzierbare Laufzeit | Kein garantierter Upgrade-Pfad wie bei der AAP |
Häufige Fragen zu AWX
AWX ist das quelloffene Upstream-Projekt: schnell, kostenlos, aber ohne Support und ohne garantierten Upgrade-Pfad. Die Ansible Automation Platform ist die daraus gehärtete, von Red Hat supportete und kommerziell lizenzierte Variante mit definiertem Lebenszyklus, ähnlich dem Verhältnis Fedora zu RHEL.
Ja. AWX wird heute ausschließlich über den AWX Operator auf Kubernetes oder OpenShift betrieben; das klassische Paket-Deployment gibt es nicht mehr. Wer keine Kubernetes-Infrastruktur hat, muss sie für AWX bereitstellen und betreiben.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
AWX im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.