Ansible erfreut sich größter Beliebtheit unter Systemadministratoren, was vor allem auf seine relativ einfach zu erlernende Syntax zurückzuführen sein dürfte. Wer schon einmal mit Puppet oder SaltStack hantiert hat, der weiß, welche Infrastruktur für deren Betrieb im Hintergrund nötig ist. Ansible geht die Sache deutlich leichtfüßiger an: Auf der Kommandozeile genügt de facto ein SSH-Zugang, der wahlweise direkt als "root" erfolgt oder mittels "sudo" auf dem Zielsystem zumindest in die Rolle des Systemadministrators schlüpfen kann.

Obendrein setzt Ansible nicht grundsätzlich auf eine komplizierte deklarative Syntax wie etwa Puppet. Ansible-Anweisungen sind stattdessen eher kommentierte Shell-Skripte, denn sie listen Schritt für Schritt die zu erledigenden Arbeiten in genau der Reihenfolge auf, die später auf dem System auch zur Anwendung kommen. Obendrein bieten sie für jeden einzelnen Schritt die Möglichkeit, eine Erläuterung gleich mit anzugeben.

Wer nur mal eben auf einem Zielsystem etwas automatisiert abarbeiten möchte, dem reicht dieser Funktionsumfang. Komplizierter wird die Sache, wenn die Automation in ein externes Regelwerk eingebunden sein muss, etwa in Compliance- und Sicherheitsvorgaben. Ist eine fein granulierte Rechteverwaltung nötig, wird es ebenfalls schwierig: Wer unterschiedlichen Nutzern auf Systemen unterschiedliche Befehle erlauben will, kommt mit Ansible in der Standardvariante schon nicht mehr ganz so weit.

Die Ansible-Macher selbst hatten das längst erkannt und boten in Form von AWX lange eine Lösung für das Problem an: Ansible AWX legt sich wie ein Umhang um Ansible auf der Kommandozeile und stattet es mit zusätzlichen Funktionen aus. Dazu gehört eine umfassende Rechteverwaltung auf RBAC-Basis ebenso wie die Möglichkeit, CI/CD-Pipelines für das automatisierte Ausführen bestimmter Aufgaben zu schaffen, die dann stets aus sauberen Umgebungen heraus frisch startet. So umgehen Unternehmen zudem das Problem, dass der Aufruf bestimmter Ansible-Befehle auf nicht standardkonformen Systemen zu unerwünschten Effekten auf den Zielhosts führt.

Während AWX als Open-Source-Software frei verfügbar ist, hat Red Hat auch ein kommerzielles Produkt auf AWX-Basis im Portfolio, das mit Support daherkommt: Die Ansible Automation Platform, kurz AAP (Bild 1). Die hat in jüngerer Vergangenheit etliche Erweiterungen erfahren: Während es sich früher vorrangig um ein GUI zum Aufrufen von Ansible-Playbooks handelte, haben viele der beschriebenen Neuerungen ihren Weg in die Software erst in AAP 2.0 gefunden.

Für uns Grund genug, genauer hinzuschauen: Was bekommen Administratoren, die sich AAP ins Unternehmen holen? Was bietet AAP in Sachen Grundfunktionalität verglichen mit anderen Produkten ähnlicher Art, welche Spezialfunktionen hat es an Bord? Welche Erleichterungen bringt AAP in Sachen Sicherheit und Compliance? Wie gut unterstützt es den Administrator beim Erstellen moderner CI/CD-Umgebungen? Und wie flexibel ist AAP bei der Anbindung lokaler oder Hyperscaler-gestützer Dienste? Der folgende Test verrät, womit Sie bei AAP rechnen dürfen (und müssen).

Schon beim ersten Blick auf AAP fällt auf: Hier geht es um viel mehr als den bloßen Aufruf von Playbooks im Ansible-Format. Ein Playbook ist bei Ansible grundsätzlich eine Art Template, das einer eigenen Syntax folgend eine Reihe von Arbeitsschritten für Zielsysteme auflistet und dabei die Parameter vorgibt, die für diese Aufrufe gelten. Der Aufruf einzelner Funktionen muss dabei nicht direkt erfolgen, sondern kann über Rollen geschehen, die ihrerseits eine eigene Einheit in Ansible sind und anzuwendende Konfigurationsschritte mit der dazugehörenden Dienstkonfiguration und eventuellen Zusatzoperationen umfassen.

AAP geht darüber aber weit hinaus. Wer die Plattform installiert, holt sich eine Vielzahl zusätzlicher Dienste in seine Umgebung, die AAP zum Funktionieren braucht. Eine Kernkomponente im gesamten AAP-Konstrukt ist etwa Redis, das als Konsens-Algorithmus im Hintergrund sicherstellt, dass sämtliche zu AAP gehörenden Systeme stets dieselben Informationen zu allen verwalteten Systemen und Ressourcen haben. Denn auch das ist bereits ein zentraler Aspekt des Basisumfangs: Die gesamte Plattform skaliert nahtlos in die Breite. Das Platform Gateway etwa, das alle Zugriffe auf AAP steuert, kann ebenfalls in beliebig vielen Instanzen ausgerollt sein wie die eigentliche Automationslogik, die im Automation Hub Container steckt. Auch der Event-Driven-Ansible-Teil, die Komponente, die auf Zuruf Ansible-Befehle auf Zielsystemen ausführt, kommt nahtlos in die Breite skalierbar daher.

Praktisch: Um all diese Details braucht der Administrator sich bei AAP nur bedingt zu kümmern. Solange er genug Systeme für AAP zur Verfügung stellt, kümmert dieses sich um die eigene Skalierbarkeit weitgehend autark und so, dass die Benutzererfahrung so gut wie möglich ist.

Nutzer greifen auf AAP im Normalfall über das Web-GUI zu. Dies hat durchaus Ähnlichkeit mit anderen von Red Hat angebotenen Werkzeugen für moderne IT. Wer etwa das OpenShift-GUI kennt, wird sich in AAP flott zurechtfinden. Denn Aufbau und Logik folgen weitgehend dem, was eben auch von anderen Produkten bekannt ist. Die Liste der Menüpunkte links bietet schnellen Zugriff auf die Schlüsselfunktionen von AAP, darunter etwa das beschriebene Event-Driven Ansible (EDA) für das automatisierte Durchführen von Ansible-Aufrufen oder den Automation Hub, eine Art Marktplatz für Ansible-Integrationen, vom Hersteller kuratiert.

Die eigentliche Kernfunktionalität ist insbesondere im Automation Controller und EDA enthalten. Hier lassen sich also im Stil einer CI/CD-Pipeline Playbooks hinterlegen, erfassten und von AAP verwalteten Systemen zuweisen, entsprechend konfigurieren sowie letztlich auch ausführen. Nützlich ist, dass AAP dabei verschiedene Zielplattformen mit jeweils eigenen Inventories verwalten und diesen spezifische Ansible-Konfigurationen zuweisen kann. Das hilft beträchtlich dabei, den Überblick in größeren Umgebungen zu behalten und ein einmal definiertes Ordnungskonzept umzusetzen. Insgesamt kommt der Teil von AAP, der die größte Menge der Automation-Controller-Features umfasst, einer vollständigen CI/CD-Umgebung unter Verwendung von Ansible recht nahe. Denn hier lassen sich etwa externe GitHub-Verzeichnisse nahtlos integrieren, um Infrastructure-as-Code-Systeme umzusetzen.

Ebenfalls zum AAP-Kern gehört mittlerweile das bereits erwähnte Event-Driven Ansible. Die Software ist nicht ganz so alt wie Ansible selbst, erfreut sich aber schon jetzt großer Beliebtheit. Denn mit EDA lassen sich die Systeme eines Ansible Inventories gezielt im Hinblick auf einzelne Ereignisse hin überwachen. Die Regeln dafür legt der Administrator selbst fest (Bild 2). Tritt ein bestimmtes Ereignis ein oder geraten die von EDA gemanagten Systeme in einen zuvor durch ein Regelwerk definierten Zustand, kümmert sich AAP automatisch um einen Ansible-Lauf, um den gewünschten Zustand wiederherzustellen.

Insgesamt präsentiert die Ansible Automation Platform sich im Hinblick auf ihre Grundfunktionalität in einem Zustand, der mit den Erwartungen an ein Enterprise-Produkt von einem Hersteller wie Red Hat in Einklang zu bringen ist. Ganze Flotten von Systemen lassen sich per AAP sinnvoll automatisiert mit Software und Konfiguration versorgen und dauerhaft in diesem Zustand halten – EDA sei Dank.

Perfekt ist bei AAP aber längst nicht alles. Wer etwa Ansible vor allem von der Kommandozeile her kennt und erstmals mit AAP zu tun hat, merkt schnell: Zwar begegnen dem Admin hier im Großen und Ganzen dieselben Begriffe und es ist erkennbar, dass unter der Haube letztlich irgendwo bekannte Werkzeuge wie "ansible-playbook" laufen. Durch das GUI aber, das der bevorzugte Weg der AAP-Nutzung ist, sind viele Dinge deutlich komplizierter als unmittelbar auf der Shell. Was natürlich auch daran liegt, dass sich mit AAP viel mehr Dinge anstellen lassen.

Definitiv außerhalb des Bereichs der typischen Ansible-Funktionen bewegen sich die diversen Zusatzfunktionen, die AAP an Bord hat. Das geht schon bei jenen Komponenten los, die aus Ansible eine halbe CI/CD-Plattform (Continuous Integration/Continuous Delivery) machen. Zugegeben: Das Thema CI/CD ist selten ein Quell echter Freude. Wer schon einmal mit Jenkins oder ArgoCD zu tun hatte, kennt das Problem nur zu gut.

Dafür können die involvierten Werkzeuge aber meist nichts. Denn die klassische Pipeline für CI/CD-Setups, die auf Grundlage etwa eines Check-ins in ein Git-Verzeichnis einen Automatismus in Gang setzt, diverse Arbeitsschritte nacheinander abarbeitet und letztlich idealerweise zu einer laufenden, gut konfigurierten Produktionsinstanz eines Systems oder eines spezifischen Dienstes kommt, ist inhärent hochkomplex.

Hier bietet AAP dem Administrator diverse Hilfsleinen, etwa eine eingebaute Versionsverwaltung der genutzten Repositories und der hinterlegten Pipelines selbst.

Das macht den Rollback leichter, falls die Veränderung an einer Pipeline schiefgelaufen ist. Auch lassen sich per Web-GUI relativ simpel einzelne Teile einer CI/CD-Pipeline aus AAP heraus separat starten. Das ist hilfreich, wenn es sich um eine große Pipeline handelt, deren Abarbeiten viel Zeit verschlingt und bei der sich ein Fehler gen Ende der anstehenden Arbeiten eingeschlichen hat. Denn so vermeidet AAP es, eine ewig lange Pipeline wieder ganz von vorn beginnen zu lassen.

Abzüge bei der B-Note gibt es aber hinsichtlich des Handlings von Pipelines, ihren Versionen und allem, was damit zusammenhängt. Denn auch hier ist das Web-GUI de facto ein Kapitel für sich, und Admins, die AAP eben dafür aufsetzen, haben zunächst einige Hausaufgaben zu erledigen, um die zentralen Konzepte zu verstehen und sie im GUI dann auch einzusetzen. Hier wäre an einigen Stellen ein Wizard praktisch, der beim Aufsetzen der ersten Einstellungen oder Pipelines hilft.

AAP bietet insgesamt umfassende Möglichkeiten, um Systemen durch CI/CD-Pipelines automatisiert mit Software und der dazugehörenden Konfiguration zu versorgen. Ziel ist es auch hier, ein funktionierendes System zu erhalten, das den eigenen Anforderungen genügt.

Ebenfalls von zentraler Bedeutung in AAP ist der Automation Hub (Bild 3). Erfahrene Ansible-Nutzer kennen das Problem: Wer für eine spezifischen Aufgabe die passende Ansible-Rolle oder ein geeignetes Modul sucht, wirft im Regelfall Google an. Meist findet sich in den ersten Treffern etwas Brauchbares, doch der Euphorie folgt die Ernüchterung auf den Fuß: Ansible-Rollen etwa, die irgendjemand vor Jahren ins Netz gestellt und seither nicht wieder angefasst hat, waren entweder schon beim ersten Aufschlag perfekt. Oder ihr ursprünglicher Autor hat seither das Interesse an ihnen verloren und der Code gammelt vor sich hin.

Red Hat versucht, des Problems mit dem Automation Hub Herr zu werden: Hier sammelt der Hersteller Integrationen für einen bunten Strauß an Anwendungen direkt in Ansible. Praktisch handelt es sich um eine Art Ansible Universe, die der Hersteller der AAP-Klientel exklusiv und kuratiert zur Verfügung stellt. Was in Automation Hub liegt, wird mit deutlich höherer Wahrscheinlichkeit funktionieren und aktiv gepflegt sein als zufällige Google-Treffer. Obendrein ist der Automation Hub gut in AAP integriert, sodass wenige Mausklicks reichen, um die Integration für bestimmten Code zu erreichen. Praktisch trägt Red Hat über AAP effizient zu höherer operativer Sicherheit und Nachhaltigkeit bei den eigenen Ansible-Kunden bei: Daumen hoch!

Nicht unerwähnt bleiben darf in einem Automationsartikel im Jahr 2025 freilich das Thema künstliche Intelligenz. Und natürlich lässt Red Hat sich in Sachen KI nicht lumpen: "Ansible Lightspeed" hat IBMs watsonx im Rücken und soll auf diese Weise den Administrator dabei unterstützen, Ansible-Code schneller selbst zu schreiben (Bild 4). Das geschieht, indem Lightspeed die Umgebung kontinuierlich überwacht und vereinfacht ausgedrückt errät, was der Administrator wohl im nächsten Schritt tun können wollte.

Das wirkt anfangs etwas gespenstisch, gerade für den, der dem KI-Hype bisher eher ablehnend gegenübersteht und sich mit dem Thema noch nicht großartig befasst hat. In einigen schnellen Tests gelang es Lightspeed aber tatsächlich, sinnvollen Ansible-Code vorherzusagen und die anstehende Aufgabe so flotter zu erledigen. Noch steckt die Technologie freilich in den Kinderschuhen. Was mit ihr heute schon möglich ist, weiß aber durchaus zu begeistern, zumal vergleichbare Funktionalität aktuell bei keiner anderen Software zur Verfügung steht.

Wichtig ist Red Hat schließlich, dass ein AAP-Administrator stets weiß, was in der eigenen Umgebung los ist. Dazu kommt Automation Analytics zum Einsatz: Die Funktion scannt die Umgebung regelmäßig und erhebt so verschiedene Vitalwerte. Sie ist im Hintergrund an Event-Driven Ansible gekoppelt, hier kommen also etwaige Benachrichtigungen für Ereignisse her, auf deren Grundlage EDA dann losläuft. Obendrein ist Automation Insights auch mit dem Mutterschiff Red Hat Insights verbunden. Dabei verfolgt die Software mehrere Ziele: Sie soll aus Sicht des Admins vorhandene Probleme schneller offensichtlich machen, soll durch Compliance-Vorgaben schon im Vorfeld Probleme verhindern und obendrein den Administrator auch noch bunte Graphen dazu malen, wie viel Geld ihm der ganze Spaß auf der Ausgabenseite einspart.

Wer Red Hat Insights schon einmal benutzt hat, findet die Automation Insights vermutlich praktisch. Insgesamt müssen sie aber als nettes Add-on gelten – die Entscheidung für oder gegen AAP wird von dieser Funktion jedenfalls eher nicht abhängen.

Dem Wesen nach existiert AAP ja überhaupt erst, um dort Compliance und geregelte Prozesse zu ermöglichen, die mit bloßen Ansible-Bordmitteln schwierig oder gar nicht zu erreichen sind. Entsprechend leistet der Anbieter sich auch hier keinen Lapsus. Wer AAP beispielsweise an ein bestehendes Benutzerverzeichnis anschließen möchte, hat dazu umfassende Optionen, inklusive des Ankoppelns an LDAP oder ans Active Directory. AAP selbst ist obendrein ein stark standardisiertes Produkt.

Die Installation selbst kommt also, wenn richtig aufgesetzt, mit diversen Garantien und Zusagen vom Anbieter, die sich im Idealfall an den eigenen Auditor weitergeben lassen und die obendrein nutzbar sind, um zentrale Compliance-Anforderungen umzusetzen und letztlich auch zu erzwingen. Hier wildert Ansible durch EDA in Gefilden klassischer Compliance-Erzwinger wie InSpec von Chef. Weil AAP zudem implizit die Option bietet, CI/CD-Pipelines zu bauen, kann es zentraler Baustein in einer unternehmensweiten Immutable-Infrastructure-Agenda sein.

Obendrein lassen sich mit EDA und den Automation Insights diverse Sicherheitsprobleme in der eigenen Plattform erkennen und markieren oder automatisiert beseitigen. Dadurch leistet AAP einen echten Beitrag zur Security der Systeme eines Unternehmens insgesamt. Enthalten ist in AAP entsprechend beispielsweise eine Komponente, die veraltete, mit Sicherheitsfehlern behaftete Versionen installierter Software automatisch erkennt und die Antwort im Rahmen eines definierten Incident-Response-Vorgangs automatisch auslöst.

Wer das Spiel auf die Spitze treiben will, kombiniert AAP in einer Red-Hat-Umgebung mit Komponenten wie Satellite und erreicht dadurch einen noch höheren Grad der Automation. Last but not least kann AAP auch als Bestandteil eines SIEM-Konzepts zum Einsatz kommen. Über eine eigene Funktion zum Aggregieren von Logdateien etwa von IDS oder Firewallsystemen trägt es dabei relevante Informationen zusammen, wertet sie aus und handelt entsprechend der festgelegten Automatismen. Ein Selbstläufer ist das natürlich nicht, und bis ein solches Konzept geplant und umgesetzt ist, geht einige Zeit ins Land.

Bei einem Produkt wie Ansible Automation Platform stellt sich letztlich natürlich die Frage, wie gut dieses mit externen Diensten verzahnt ist. Bei AAP ergeben sich hier zwei Dimensionen: Einerseits ist es natürlich denkbar, AAP als gehosteten Dienst von einem Hyperscaler zu beziehen oder als Anwendung auf einer Orchestrierungsplattform wie OpenShift zu betreiben. Das erleichtert das Setup erheblich, und das weiß Red Hat offensichtlich gut: So existiert zum Beispiel eine umfassende Anleitung, wie sich AAP auf OpenShift, also Red Hats Kubernetes-Distribution, ausrollen und betreiben lässt. Ein Schelm, wer Böses dabei denkt: IT-Verantwortliche, die sowohl AAP als auch OpenShift von Red Hat beziehen, zahlen dem Anbieter freilich auch für beide Produkte Subskriptionsgebühren – eine Art Portfolio-interner Upsell also.

Wer diesen Weg nicht beschreiten möchte, kann AAP als gehosteten Dienst via AWS oder Azure beziehen. Das erspart ebenfalls einige Reibereien beim Setup, verursacht im Gegenzug aber fortlaufende Kosten, die in die eigene Budgetplanung einzurechnen sind, um zu einem realistischen Gesamtpreis zu kommen. Die Methode des Deployments zu Fuß unterstützt AAP zwar, hiervon rät der Anbieter allerdings ab.

Die andere Dimension des Zusammenspiels mit anderen Orchestrierern besteht darin, aus AAP heraus Aktionen zu starten, die ihrerseits zu bestimmten Resultaten in Zielplattformen wie AWS oder Kubernetes führen. Hier macht sich AAP zunutze, dass es für die Interaktion sowohl mit Kubernetes als auch mit den großen Hyperscalern umfassende Ansible-Integrationen gibt, die Ressourcen anlegen, verwalten oder entfernen können. Das geht so weit, dass sich für eine Vielzahl von Zielplattformen – darunter VMware vCenter oder OpenStack – die Zugangsdaten zentral hinterlegen lassen, um im nächsten Schritt die jeweilige Plattform als Deployment-Ziel etwa im Rahmen einer Pipeline zu definieren. Auch hier ist weitgehend nahtlose Integration also vorhanden und gut umgesetzt.

Ansible Automation Platform ist eine Art Selbstläufer für jene Unternehmen, die mit Ansible mehr tun möchten als nur ein paar Ansible-Playbooks auszuführen – vor allem, weil es praktisch keine Konkurrenz gibt: Von Art und Umfang her ist AAP zweifelsohne das umfangreichste Produkt seiner Art. Das nimmt es aber nicht als Vorwand, nur das Nötigste zu tun, im Gegenteil: Wer eine Managementschicht um Ansible herum benötigt, wer Pipelines bauen möchte oder wer einfach mehr Einblick in den Zustand der eigenen Automation braucht, für den bietet Ansible Automation Platform sinnvolle Funktionen. Besser sein könnte insbesondere die grafische Oberfläche, die phasenweise nur wenig intuitiv daherkommt und einiges an Einarbeitung benötigt. Wer den Bogen raus hat, kommt mit AAP aber schnell zu verwertbaren und messbaren Erfolgen.