Als Red Hat sich Ansible vor ein paar Jahren einverleibte, rätselten viele Beobachter, was die Produktstrategie hinter der Akquisition sein könnte. Ansible hatte sich damals den Ruf erarbeitet, einerseits ein sehr potenter Automatisierer zu sein, andererseits war die Software aber wesentlich weniger komplex als Puppet oder als das in den USA weit verbreitete Chef. Als "Full-Stack-Anbieter", dessen Kunden keinen Anlass haben sollen, sich mit dem Produktportfolio anderer Unternehmen zu beschäftigen, konnte Red Hat das Thema Automatisierung im eigenen Sortiment nicht völlig unbesetzt lassen.

 Ob Ansible dafür das richtige Werkzeug sei, zogen so manche kritische Experten seinerzeit allerdings in Zweifel. Diese hat Red Hat mittlerweile eindrucksvoll widerlegt. Dazu trimmte der neue Anbieter die Roadmap, integrierte Ansible in die eigenen Prozesse und stattete die neue interne Abteilung mit weiteren Entwicklungskapazitäten aus. Schnell entstanden neue Produkte, deren Kern Ansible war. Ansible Tower ist hierfür eindrücklicher Beleg.

Ende 2021 konsolidierte der Hersteller sein Automationsportfolio ein weiteres Mal und bündelte unter dem Namen "Red Hat Ansible Automation Platform" (RHAAP) diverse Komponenten zu einem neuen Produkt. Seither ist RHAAP der zentrale Baustein in Red Hats Automationsstrategie, und die Software versteht sich durchaus als "All-in"-Produkt: Wer RHAAP nutzt, soll für die Automation von Aufgaben keine anderen Werkzeuge brauchen.

Wir stellen RHAAP auf den Prüfstand und nehmen fünf Faktoren ins Visier: Welche Features erhalten Admins für Automation, wenn sie sich für RHAAP in ihrer Umgebung entscheiden? Welche Zielsysteme lassen sich mittels RHAAP steuern und bedienen? Welche Anbindungen an externe Umgebungen wie die diversen Public Clouds oder Kubernetes stehen zur Verfügung? Auch die Themen Security und Compliance spielen freilich eine Rolle: Wieviel Arbeit nimmt RHAAP dem Admin hier ab? Harmoniert es mit schon bestehenden Komponenten wie einem LDAP- oder Active-Directory-Server?

Nicht zuletzt spielt auch die Integration in CI/CD-Pipelines heute eine wichtige Rolle. Immer mehr Unternehmen setzen auf DevOps und das Prinzip von "Continuous Development and Continuous Deployment", also das fortwährende Ausrollen von Änderungen in die Produktion. Ansible als Automatisierer spielt dabei in der Theorie eine große Rolle.

Es schadet nicht, sich mit den Grundlagen von RHAAP zu befassen, um dessen Funktionsumfang zu erfassen und zu bewerten. Wie schon erwähnt, ist die Ansible Automation Platform ein Konglomerat aus diversen Einzelteilen. Wobei das großspuriger klingt, als es eigentlich ist – denn die Hauptkomponente des Produkts ist weiterhin jener Teil, der zuvor bereits als "Ansible Tower" firmierte. Für RHAAP haben die Red-Hat-Entwickler Tower allerdings umgebaut und Funktionen, die im Programm zuvor bereits vorhanden waren, in eigene Bereiche ausgelagert. Dadurch werden manche Features, die auch vorher schon vorhanden waren, nun überhaupt erst sichtbar.

Im Zentrum der RHAAP-Funktionalität steht eine Komponente namens "Automation Controller". Der Controller erfüllt mehrere Aufgaben: Er hinterlegt die zu Ansible gehörenden Daten im Hintergrund in einer PostgreSQL-Datenbank und ist die zentrale Stelle für Admins, um Arbeitsaufträge in RHAAP zu definieren. Das geschieht ausschließlich über eine REST-API, für die sowohl ein Kommandozeilen-Client ("ansible-navigator") als auch das von Ansible Tower bekannte Web-UI zur Verfügung stehen. Automationsfunktionen sind im Automation Controller selbst allerdings nicht definiert.

Hier kommen stattdessen die "Execution Environments" ins Spiel, die ein echtes Novum in RHAAP darstellen. Ruft ein Admin ein Ansible-Playbook auf, verbindet dieses sich in aller Regel per SSH oder WinRM mit dem Zielsystem und führt dort Befehle aus. Welche Standardeinstellungen es dabei nutzt und welche Umgebungsvariablen gegeben sind, das hängt vom System ab, auf dem der Admin den Befehl aufruft. Was ein Problem im Hinblick auf Idempotenz darstellt: Rufen mehrere Admins Ansible von ihren Arbeitsplatzsystemen auf, kann es auf den Zielsystemen zu unterschiedlichen Ergebnissen kommen, falls differierende Versionen von Ansible vorliegen.

Diesem Problem schiebt Red Hat in RHAAP einen Riegel vor. Denn RHAAP pflegt eigene Podman-Container, die Execution Environments (EE) heißen und vom Automation Controller gesteuert werden. Ein eigens erfundenes Werkzeug namens "Execution Environment Creator" erlaubt es, die Podman-Container schnell und nach den eigenen Vorgaben zu erstellen. Aus ihnen heraus ruft der Controller Ansible später auf, sodass Befehle für bestimmte Aufgaben auf die stets gleiche und reproduzierbare Umgebung zurückgreifen. Eine zentrale, von Red Hat betriebene Container-Registry ermöglicht es, die Container-Abbilder zu verteilen. Wer möchte, findet in RHAAP aber auch eine private Container-Registry, deren Inhalte den lokalen Systemen vorbehalten bleiben.

Seit Version 2.1 bietet RHAAP zudem eine Mesh-Komponente: Diese macht es möglich, über verschiedene, geographisch verteilte Ansible-Setups dieselben EEs und dieselbe Konfiguration zu verteilen und zu nutzen.

Darüber hinaus gehören zu RHAAP auch die "Content Tools" und die "Content Collections". Ersterer Begriff bezieht sich auf eine Reihe von Werkzeugen und Funktionen, die weiterhin den eigentlichen Kern von Ansible bildet, also auf den Zielsystemen die Automation regelt. Hinter den "Content Collections" verstecken sich hingegen die diversen Module für Ansible, die bis vor ein paar Ansible-Releases noch zum Kern der Software gehörten. Red Hat hat hier schon vor langem mit dem Ausmisten begonnen und auch bestimmte Kernfunktionen reduziert.

Die Content Collections sind ebenfalls von Red Hat kuratierte Module, doch kann der Admin sich bei diesen nicht mehr blind darauf verlassen, dass sie auf jedem System mit Ansible auch tatsächlich vorhanden sind. Hier eilt dem Admin aber wieder der Execution Environment Creator zur Hilfe: Wenn der IT-Verantwortliche mittels RHAAP ein "Execution Environment" erzeugt, legt er die Module aus der Content Collection, die Teil des fertigen Containers werden sollen, per Abhängigkeitsanweisung fest. Im fertigen Container sind sie dann tatsächlich vorhanden, was in unserem Test auch tadellos klappte.

Was im Übrigen auch für den Rest der RHAAP-Grundfunktionen gilt. Wer bereits mit Ansible gearbeitet hat, muss sich trotz des Wustes an neuen Funktionen in RHAAP nicht komplett umgewöhnen. Ist ein EE erst erstellt, lässt es sich per TUI (Text User Interface) oder GUI unmittelbar einzelnen Systemen zuweisen. Auf diesen tut Ansible dann genau das, was Admins mit Ansible-Erfahrung bereits von ihren "ansible-playbook"-Aufrufen kennen: Es versetzt das Zielsystem zuverlässig in den gewünschten Zustand. Bei der Basisfunktionalität leistet RHAAP sich also keinen Lapsus, und einen Extrapunkt in der Wertung gibt es für das nunmehr zum Lieferumfang gehörende Ansible-Mesh-Feature. Denn dieses macht das Skalieren in die Breite fundamental einfacher und erleichtert die Ansible-Administration in großen, verteilten Umgebungen.

RHAAP ist ein Werkzeug, das Admins auch beim Erzwingen von Compliance auf den Zielsystemen unterstützt. Weil Ansible Idempotenz umfassend implementiert, darf der Admin darauf vertrauen, dass seine Systeme nach einem Ansible-Lauf den in der Konfiguration definierten Status haben – falls Ansible nicht zuvor per Fehlermeldung den Dienst quittiert hat. Freilich stellt sich im Kontext von Security und Compliance aber auch die Frage, inwiefern RHAAP sich selbst mit bestehenden Compliance-Mechanismen kombinieren lässt. Und hier bietet der Hersteller einen durchaus beachtlichen Umfang.

Warum das so ist, erschließt sich, wenn wir uns ein fundamentales Problem der Ansible-Architektur vor Augen führen: Andere Werkzeuge wie Puppet oder Chef setzen auf einen eigenen Agenten auf den Systemen, um dort Befehle auszuführen. Das impliziert eine eigene Kontrollmöglichkeit, weil kein Standardprotokoll wie SSH zum Einsatz kommt und das Ausführen von Kommandos auf den Zielen auch nicht an deren Benutzerverwaltung gekoppelt ist. Puppet etwa sorgt über maschinenspezifische SSL-Zertifikate dafür, dass wirklich nur der jeweilige Puppet-Master auf dem Zielsystem Befehle ausführen darf.

Das ist bei Ansible fundamental anders. Gerade weil SSH oder WinRM zum Einsatz kommen, muss für den ausführenden Benutzer in Ansible stets ein lokaler Benutzer vorhanden sein. Und wenn Ansible zentrale Teile der Systemkonfiguration bearbeiten soll, muss dieser Benutzer auch mit entsprechenden Berechtigungen ausgestattet sein, etwa per "sudo". Wer allerdings schon mal eine "sudoers"-Datei gepflegt hat, um Ansible auf bestimmte Aktionen zu beschränken, weiß: Das ist eher eine unbequeme Arbeit.

Viele Unternehmen statten ihren Ansible-Nutzer deshalb gleich mit den Berechtigungen des Nutzers "root" aus. Was in der Praxis allerdings eigene Probleme mit sich bringt: Wer Ansible etwa einsetzt, um Systeme von Kunden zu betreuen, braucht de facto eine Beschränkung dessen, was Ansible-Accounts dürfen. Schließlich soll der Helpdesk womöglich in der Lage sein, die Apache-Konfiguration oder jene von MariaDB im Kundenauftrag auf dem kleinen Dienstweg zu ändern – die Berechtigung, neue Benutzer anzulegen, sollte allerdings den Admins vorbehalten sein.

Weil Ansible selbst hierfür keine Funktionalität bietet, rüstet Red Hat die Features im Ansible Controller nach. Dabei hat der Admin die Möglichkeit, die Benutzer entweder direkt in Ansible zu verwalten oder seine Benutzerdatenbank vollständig aus einem existierenden Verzeichnis zu beziehen. In Umgebungen ausschließlich auf Linux-Basis wird das regelmäßig LDAP sein, doch kann über sein LDAP-Interface auch das Active Directory diese Aufgabe schultern. In Ansible selbst ist es dann möglich, verschiedene Berechtigungen fein granuliert an die existierenden Nutzer zu verteilen. Das Ausführen bestimmter Execution Environments lässt sich einzelnen Benutzern, Gruppen oder Rollen mithin explizit erlauben oder verbieten. Gerade weil diese Features in Ansible selbst fehlen, leistet RHAAP hier wichtige Arbeit. Und ohne diese Funktion wäre RHAAP im Enterprise-Einsatz kaum sinnvoll zu nutzen.

Auch beim Setup von Ansible hält Red Hat sich penibel an die eigenen Best Practices: Die gesamte Umgebung kommt in Form fertiger Container daher, die bei Bedarf schnell zu ersetzen sind. Lediglich die Konfigurationsdateien sind lokal notwendig. Das macht nicht nur die Wartung der Umgebung leichter, sondern ermöglicht auch das sehr schnelle Reagieren auf Sicherheitsprobleme in Ansible selbst. Bei den Themen Security und Compliance gibt RHAAP sich insofern keine Blöße, hebt sich von der Konkurrenz aber auch nicht besonders ab.

Hybride Umgebungen sind heute gar nicht mehr so selten, wie mancher Admin es vielleicht annimmt. Klar: In den Serverräumen dieser Welt hat Linux längst das Regiment übernommen und zum Teil hat Microsoft einst existierende eigene Komponenten wegen ihrer Chancenlosigkeit gegenüber Linux eingestampft. Webserver auf Windows-Basis etwa finden sich heute nur noch selten. Bei Automationswerkzeugen wie Ansible gehen Admins dennoch oft davon aus, dass diese nur für Linux gemacht seien und auch nur mit diesem funktionierten.

Das ist gerade bei Ansible aber ausdrücklich nicht der Fall. Hier wird der fehlende Agent auf den Zielsystemen, der im Kontext der Sicherheit noch ein Pferdefuß war, zum Vorteil: Weil Ansible selbst keinen auf Windows portierten Agenten benötigt, lässt es sich ohne Probleme auch auf Windows-Systemen nutzen. Voraussetzung dafür ist, dass die Windows-Remote-Management-(WinRM)-Komponente installiert und aktiv ist. Windows selbst ist kein POSIX-kompatibles Dateisystem, in Ansible sind aber alle Vorkehrungen getroffen, damit das Programm mit den Windows-Eigenheiten zurechtkommt.

Das umfasst eine Vielzahl von Arbeitsschritten. Dienste lassen sich per eigener Funktion in Windows starten oder stoppen sowie aktivieren und deaktivieren. Dateien im Dateisystem befüllt der IT-Verantwortliche auf Wunsch ebenso mit eigenen Inhalten wie Schlüssel in der Windows Registry. Wer Programme installieren möchte, die im EXE- oder MSI-Format vorliegen, kann das per Ansible ebenfalls erledigen. So ist es problemlos möglich, einen Host in einen Hyper-V-Server zu verwandeln, der virtuelle Maschinen betreibt.

Naturgemäß versteht Ansible sich ebenfalls auf zumindest basales Handling der meisten UNIX-artigen Betriebssysteme. Das umfasst die BSD-Derivate ebenso wie macOS, auf dem sich per Ansible ebenfalls verschiedene Aufgaben durchführen lassen. Grundsätzlich gilt: Sobald auf einem System ein Weg zur Verfügung steht, eine klassische Shell wie die Bash zu nutzen, lässt sich beinahe jede Aufgabe in Ansible für die betroffenen Systeme implementieren – und sei es in Form von direkten Shell-Befehlen. Für die genannten Betriebssysteme kommt Ansible und mithin RHAAP jedoch mit vielen Funktionen daher, die die Administration essenziell vereinfachen.

Ähnlich vielseitig gibt RHAAP sich bei der Verbindung zu modernen Schnittstellen von Hyperscalern wie AWS, Microsoft Azure und GCP. Möchte der Admin Ressourcen in diesen Umgebungen verwenden, muss er dies nicht händisch programmieren, sondern findet in Ansible selbst fertige Module für die meisten Dienste, die diese Clouds anbieten. Wer lieber eine private OpenStack-Cloud steuert, hat auch hierfür entsprechende Funktionen in RHAAP. Das Prinzip ist dabei stets dasselbe: Ansible redet (zum Teil mittels der entsprechenden CLI-Werkzeuge) direkt mit den Cloud-APIs und kann so in diesen nicht nur schauen, was Sache ist, sondern auch Ressourcen anlegen und wieder löschen.

Mustergültig ist zudem die in RHAAP eingebaute Unterstützung von Kubernetes. Aus Ansible heraus lassen sich unmittelbar Container in einer bestehenden Kubernetes-Umgebung konfigurieren, starten und stoppen sowie anlegen und löschen. Die große Vielfalt im Hinblick auf externe Umgebungen gilt mithin zurecht als ausgesprochene Stärke der Lösung, auch wenn andere Produkte am Markt mittlerweile aufgeholt haben und die Lücke zu Puppet & Co. längst nicht mehr so gewaltig ist, wie sie einst war.

Für das fünfte Kriterium im Test ist zunächst eine Abgrenzung nötig, denn externe Werkzeuge sind AWS & Co. auch, mit denen sich der vorherige Abschnitt unseres Tests bereits ausgiebig beschäftigt hat. Passend dazu bezieht sich unser letzter Aspekt auch nicht auf die Verbindung mit externen Umgebungen, sondern eher auf die Frage, wie gut RHAAP sich mit externen Diensten verkuppeln lässt.

Warum das notwendig sein kann, macht ein Beispiel schnell deutlich. Auf ihrer Reise von der klassischen Turnschuhadninistration haben sich viele Admins daran gewöhnt, andernfalls händisch ausgeführte Arbeiten in eine Ansible-Rolle zu packen und dieses manuell mittels Playbook aufzurufen. Das ist grundsätzlich kein Problem, heißt aber, dass der Admin selbst "Herr des Verfahrens" bleibt. Für moderne DevOps-Teams, in denen Entwicklung und Deployment nicht streng voneinander getrennt sind, ist das aber möglicherweise nicht gewünscht. Werden die auszurollenden Anwendungen hier etwa in Form von Containern bereitgestellt, müsste der Admin im Idealfall zunächst den Container neu bauen, nachdem er eine Änderung in dessen in Git hinterlegter Konfiguration vorgenommen hat. Danach folgt das manuelle Ausrollen des neuen Containers, damit die gemachte Modifikation in der Produktion auch sicher zum Einsatz kommt.

Dieses und andere Beispiele bedingen funktionierende Mechanismen für das, was heute unter den Schlagwörtern Continuous Integration sowie Continuous Deployment firmiert. Red Hat ist das klar und RHAAP liefert in dieser Hinsicht entsprechend. Bereits Erwähnung hat die API-Schnittstelle vom Automation Controller gefunden, über die sich beliebige REST-Befehle an Ansible schicken lassen. Komfortabel ist das aber nicht, denn hierfür müsste ein Entwickler sich umfassendes Wissen zu den Befehlen aneignen, die die Automation-Controller-API bietet.

Um dem Systemverwalter diese Fingerübung zu ersparen, bietet die Ansible Automation auch eine Webhook-Funktion, komplett mit fertigen Beispielen für GitHub und GitLab. Der Rest ist Schema F: Ist Ansible mit RHAAP verbunden, führt ein Commit in ein überwachtes Verzeichnis in Git automatisch zum Aufruf des Webhooks in Ansible. Was Ansible bei einem solchen Ereignis machen soll, legt der IT-Verantwortliche direkt in Ansible per YML-Datei fest. Aus Ansible heraus lassen sich zudem weitere Events in anderen REST-Diensten aufrufen. Im Test hat das gut funktioniert, sodass einer automatischen CI/CD Deployment Chain aus Ansible-Sicht nichts im Wege steht.

Red Hat geht bei der Ansible Automation Platform konsequent den für Ansible eingeschlagenen Weg weiter und macht sie zum zentralen Werkzeug für Automation im RHEL-Universium. Art und Umfang der gebotenen Funktionen überzeugen, wenn sie auch nicht sonderlich aus der Masse der Automatisierer hervorstechen. Wer die Arbeit mit Ansible gewohnt ist, wird sich in der Software schnell zurechtfinden und mit ihr den Grad der Automation im eigenen Unternehmen deutlich steigern.

Besonders sinnvoll ist RHAAP freilich für jene Unternehmen, wo bereits vorrangig Red-Hat-Produkte zum Einsatz kommen. Andere Systeme und Linux-Distributionen lassen sich mit Ansible zudem ebenfalls verwalten. Doch ist erkennbar, dass RHAAP erst im Tandem mit den anderen Red-Hat-Produkten seine volle Schlagkraft entfaltet. Wer etwa Red Hat Satellite einsetzt, um den Bare-Metal-Lebenszyklus der eigenen Server zu verwalten, verzahnt Satellite und RHAAP spielend leicht miteinander.

Das Fazit fällt also zwiegespalten aus: RHEL-Nutzer erhalten eine leichtfüßige Software für die komplette Automation mit wenig Aufwand. Nutzer anderer Systeme müssen mehr Aufwand investieren, kommen dann jedoch zu vergleichbar guten Ergebnissen.