Freie Automatisierungstools mit GUI
Immer der Reihe nach
Veröffentlicht in Ausgabe 01/2025 - SCHWERPUNKT
Administratoren automatisieren wiederkehrende Aufgaben mit Skripten und Tools wie Ansible oder Terraform, die in ihrem Basissetup auf der Kommandozeile arbeiten. Aber es gibt auch grafische Werkzeuge, die den Umgang mit den Automatisierungsumgebungen verbessern und zusätzliche Funktionen wie Workflows bieten. Wir betrachten im Folgenden drei Open-Source-Tools für diesen Aufgabe: Den Jungspund Semaphore UI, den vermeintlichen Alleskönner Rundeck sowie den Altmeister Jenkins.
Das Ende von AWX
Unter Ansible-Anwendern war AWX als GUI sehr beliebt. Die Betonung liegt hier auf "war", denn seit Juli 2024 wird AWX nicht mehr weiterentwickelt. Der Grund ist simpel: AWX war die Entwicklungsplattform für Ansible Tower/Controller. Für Ansible gibt es noch zwei weitere Tools, "Event Driven Ansible" und "Ansible Hub", und diese drei Werkzeuge nutzen bislang ihre eigenen Komponenten wie Webserver und Datenbanken und wurden als eigene Applikationen gebaut. Die Ansible-Entwickler wollen die Komponenten künftig aber nicht mehr separat weiterentwickeln, sondern in eine einzige Umgebung mit Service-Architektur zusammenführen, die zentrale Komponenten wie das Web-UI oder die Datenbank gemeinsam verwendet. Daher braucht es kein Entwicklungsprojekt für einen Standalone-Controller mehr. Der Umbau dauert derzeit noch an und daher gibt esaktuell kein komfortables Upstream-Setup mit einem vorgefertigten Kubernetes-Operator. Wer sich eine aktuelle Version bauen möchte, kann dies aus den offenen Sourcen durchaus tun, jedoch ist der Aufwand erheblich größer als bisher.
Schlank und sparsam:Semaphore UI
Das Projekt Semaphore UI [1] entspricht einer abgespeckten Variante von Ansible Tower/Controller oder AWX (siehe auch Kasten rechte Seite). Und "abgespeckt" gilt hier in zweierlei Hinsicht: Zum einen hat Semaphore UI einen deutlich geringeren Funktionsumfang als AWX, gleichzeitig belegt es viel weniger Ressourcen als AWX oder Tower. Das in Go programmierte Tool ist klein, schlank und schnell. Es kommt theoretisch ohne eine SQL-Datenbank aus, der einfache Key/Value-Store "BoltDB" (basierend auf dem aktuellen "BboltDB"-Projekt, nicht dem 2017 eingestellten "Bolt-DB") genügt.
Während Tower ein spezielles Python Virtual Environment für Ansible mitbrachte und der Ansible-Controller beziehungsweise AWX auf Execution Environments mit "ansible runner" setzt, führt Semaphore UI unter der Haube einfach nur das ansible-playbook-Executable mit einigen zusätzlichen Parametern aus. Dieser Wrapper reicht für einfache Aufgaben aus und läuft gerade bei simplen Playbooks mit kleinen Inventories auch recht flott. Immerhin muss Semaphore nicht erst einen Execution Environment Container laden, bauen und starten.
Administratoren automatisieren wiederkehrende Aufgaben mit Skripten und Tools wie Ansible oder Terraform, die in ihrem Basissetup auf der Kommandozeile arbeiten. Aber es gibt auch grafische Werkzeuge, die den Umgang mit den Automatisierungsumgebungen verbessern und zusätzliche Funktionen wie Workflows bieten. Wir betrachten im Folgenden drei Open-Source-Tools für diesen Aufgabe: Den Jungspund Semaphore UI, den vermeintlichen Alleskönner Rundeck sowie den Altmeister Jenkins.
Das Ende von AWX
Unter Ansible-Anwendern war AWX als GUI sehr beliebt. Die Betonung liegt hier auf "war", denn seit Juli 2024 wird AWX nicht mehr weiterentwickelt. Der Grund ist simpel: AWX war die Entwicklungsplattform für Ansible Tower/Controller. Für Ansible gibt es noch zwei weitere Tools, "Event Driven Ansible" und "Ansible Hub", und diese drei Werkzeuge nutzen bislang ihre eigenen Komponenten wie Webserver und Datenbanken und wurden als eigene Applikationen gebaut. Die Ansible-Entwickler wollen die Komponenten künftig aber nicht mehr separat weiterentwickeln, sondern in eine einzige Umgebung mit Service-Architektur zusammenführen, die zentrale Komponenten wie das Web-UI oder die Datenbank gemeinsam verwendet. Daher braucht es kein Entwicklungsprojekt für einen Standalone-Controller mehr. Der Umbau dauert derzeit noch an und daher gibt esaktuell kein komfortables Upstream-Setup mit einem vorgefertigten Kubernetes-Operator. Wer sich eine aktuelle Version bauen möchte, kann dies aus den offenen Sourcen durchaus tun, jedoch ist der Aufwand erheblich größer als bisher.
Schlank und sparsam:Semaphore UI
Das Projekt Semaphore UI [1] entspricht einer abgespeckten Variante von Ansible Tower/Controller oder AWX (siehe auch Kasten rechte Seite). Und "abgespeckt" gilt hier in zweierlei Hinsicht: Zum einen hat Semaphore UI einen deutlich geringeren Funktionsumfang als AWX, gleichzeitig belegt es viel weniger Ressourcen als AWX oder Tower. Das in Go programmierte Tool ist klein, schlank und schnell. Es kommt theoretisch ohne eine SQL-Datenbank aus, der einfache Key/Value-Store "BoltDB" (basierend auf dem aktuellen "BboltDB"-Projekt, nicht dem 2017 eingestellten "Bolt-DB") genügt.
Während Tower ein spezielles Python Virtual Environment für Ansible mitbrachte und der Ansible-Controller beziehungsweise AWX auf Execution Environments mit "ansible runner" setzt, führt Semaphore UI unter der Haube einfach nur das ansible-playbook-Executable mit einigen zusätzlichen Parametern aus. Dieser Wrapper reicht für einfache Aufgaben aus und läuft gerade bei simplen Playbooks mit kleinen Inventories auch recht flott. Immerhin muss Semaphore nicht erst einen Execution Environment Container laden, bauen und starten.
Allerdings stoßen Ansible-Anwender schnell an die Grenzen der Software: Soll beispielsweise ein Playbook zum Einsatz kommen, das virtuelle Maschinen auf der Google-Cloud ausrollt, wertet Semaphore zwar die "collections/requirements.yml-"Datei korrekt aus und installiert die benötigte Google-Cloud- Collection, doch es ignoriert das "requirements.txt"-File mit der Python-Dependency für "google-auth". Also muss der Anwender hier direkt auf dem System eingreifen und die Python-Abhängigkeiten manuell auflösen. Speziell wenn Semaphore dabei in einem Container läuft, ist dieser Hack problematisch.
Auch der Umgang mit Passwörtern und Schlüsseln fällt bei Semaphore aufwendig aus. Das Tool integriert das Credentials-Konzept von Ansible-Vault nur teilweise. Der "Key Store" kann nur Passwörter oder Schlüssel sichern, aber keine komplexeren Credentials. So fällt es beispielsweise schwer, das JSON-Credential-File zur Authentisierung bei der Google-Cloud irgendwo sicher abzulegen. Semaphore offeriert, Geheimnisse als Extra- oder Environment-Variables zu sichern und zur Laufzeit einzufügen. In der Praxis klappt das aber nicht, wenn der Admin den kompletten JSON-formatierten Inhalt des Google-Credentials in eine eigene Variable packt. Semaphore UI unterstützt nur statische Inventories, aber keine dynamischen. Zudem gibt es keine Workflow-Features, die mehrere Playbooks verketten.
Allerdings beschränkt sich Semaphore UI nicht auf Ansible. Anwender können optional Skripte in Bash, Python und PowerShell oder Terraform/OpenTofu-Code ausführen. Gerade die Integration von Terraform, OpenTofu und Skripten dürfte für viele IT-Verantwortliche von Interesse sein. So können sie in einer Management-UI sowohl Terraform-Infrastructure-Rollouts verwalten als auch die passenden Ansible-Playbooks, um auf den per Terraform generierten Infrastrukturknoten Applikationen zu installieren und zu konfigurieren.
Semaphore UI läuft problemlos, ressourcensparend und ziemlich flott in einem Docker- oder Podman-Container. Für erste Testzwecke spricht der Admin das Tool via HTTP und Port 3000 an. Für den produktiven Betrieb kann ein Reverse-Proxy für die TLS-Terminierung sorgen und den Dienst wie gewohnt auf dem HTTPS-Port 443 bereitstellen. Das noch junge Tool kann sich durchaus als Alternative zur kommerziellen AAP (Ansible Automation Platform) oder AWX entwickeln, zumindest in kleineren Umgebungen.
Aber noch mangelt es Semaphores Credential-Modul an Funktionen, um Zugangsdaten wie Schlüssel, Cloudaccounts und ähnliche Secrets zuverlässig abzusichern. Für die Entwickler wäre es sicher kein riesiger Aufwand, das bestehende Ansible-vault-Tool zu integrieren. Semaphore würde auch ein Workflow-Modul gut stehen, speziell wenn es Flows aus Terraform- und Ansible-Automatisierung miteinander verknüpfen könnte.
Rundeck alsvermeintlicher Alleskönner
Rundeck [2] sieht sich als universelles Runbook-Automation-Tool. Es verfügt über eine Plug-in-Architektur, mit der es unterschiedliche Zielplattformen anspricht und verschiedene Automatisierungswerkzeuge integriert. Rundeck teilt seine Runbooks auf verschiedene Projekte auf und jedem davon weist das Tool einen sogenannten "Node Executor" zu, also das Werkzeug, das die Jobs ausführt. Zu den Basis-Executern zählen SSH für den Remote-Zugriff auf andere Systeme oder auch Ansible. Dabei mag verwirren, dass es drei verschiedene SSH-Executer gibt und es sich nicht erschließt, wo dabei eigentlich der Unterschied besteht.
Innerhalb der Projekte erstellt der Admin die Automatisierung in Form von Jobs. Jeder davon besteht aus einem oder mehreren Schritten, die Rundeck sequenziell abarbeitet. Für jeden Job gibt es ein Inventory, also eine Liste an Knoten, für die die Software die Jobs ausführt. Dabei kann jeder einzelne Schritt darin als "Node Step" oder "Workflow Step" arbeiten. Node Steps führt das Tool jeweils einmal pro Host im Inventory aus, während Workflow Steps unabhängig von der Zahl der Hosts im Inventory nur einmal laufen. Am Ende jedes Schritts kann Rundeck über den sogenannten Log Filter Variablen aus dem Output des Schritts erzeugen. Das passiert – zur großen "Freude" der Anwender – natürlich mit Regular Expressions.
In den Workflow lassen sich auch "Conditionals" einbauen. In Sachen Workflow-Control und -Conditionals begnügt sich Rundeck jedoch mit dem minimalen Funktionsumfang eines Workflow-Utilities. Eigentlich gibt es als konditionale Ausführung nur folgendes Modul: Führe einen Job "xxx" aus, wenn der vorhergehende Job mit dem Status "abc" beendet wurde (Error Handler). Es gibt nicht einmal eine Option wie "führe nach Step "abc" den Job/Step "efg" aus, wenn die Return-Variable "a" von Step "abc" des vorhergehenden Jobs den Inhalt "bla" hat. Aber genau das ist es nun einmal, was einen Workflow ausmacht: die Option, den Ablauf an einer bestimmten Stelle zu verzweigen, in Abhängigkeit zu Werten und Variablen, die von früheren Schritten stammen. Um diese Funktionalität nachzurüsten, muss der Anwender manuell das Conditional-Logic-Plug-in nachrüsten. Dieses hat den Status "Stable Release Candidate" – und das auch schon seit seiner Veröffentlichung im März 2020.
Auch für die Inventories greift Rundeck auf Plug-ins zurück. Der Anwender kann die Liste der zu verwaltenden Hosts beispielsweise aus einer XML-formatierten Datei lesen oder über ein Plug-in ein Ansible-Inventory importieren. Als Node-Source lassen sich aber auch dynamische Quellen wie AWS EC2 befragen oder ein benutzereigenes Skript ausführen. Weitere Sources, Workflow-Steps und Node-Execution findet der Rundeck-Admininistrator im Plug-in-Katalog.
Etliche Plug-ins in diesem Katalog bleiben allerdings zahlenden Anwendern vorbehalten. Solche für Github Webhooks, Datadog oder ServiceNow sind beispielsweise "Available in Rundeck Enterprise only". Andere haben den Status "Rundeck Supported" und lassen sich dann automatisiert über den Katalog mit einem einzelnen Klick auf dem eigenen Rundeck-Server einrichten. Community-Plug-ins verweisen in der Regel auf die Github-Sourcen. Diese muss der IT-Verantwortliche händisch auf dem Rundeck-Server installieren, da etliche dieser Zusätze auch weitere Abhängigkeiten zu Tools und Bibliotheken benötigen.
Rundeck bringt einen simplen Vault "Key Storage" mit, in dem sich Geheimnisse wie Passwörter oder private Keys sichern lassen. Prinzipiell kann Rundeck auch auf externe Key-Server wie CyberArk zugreifen – aber die dazu nötigen Plug-ins sind der Enterprise-Version vorbehalten.
Komplexer Rundeck-Betrieb
Zwar offeriert Rundeck die Option, via Docker oder Podman als Container zu arbeiten, aber davon sollten Administratoren absehen. Denn sie benötigen oft Zugriff auf das Dateisystem des Dienstes unter "/var/lib/rundeck" und müssen im Zweifelsfall auch mithilfe des jeweiligen Paketmanagers Abhängigkeiten und Bibliotheken nachinstallieren. Wer genau weiß, was sein Rundeck-Setup braucht und wo es hingehört, kann ein passendes Container-File mit allen Abhängigkeiten erstellen. Bis dahin sollte der IT-Verantwortliche eine virtuelle Maschine mit einer Linux-Server-Distribution und der passenden Java-Runtime für Rundeck nutzen. Der Hersteller offeriert Paket-Repositories für alle gängigen Distributionen. Somit lässt sich Rundeck auf Debian und Ubuntu via apt, auf RPM-basierten Distributionen mit dnf installieren.
Einmal eingerichtet läuft Rundeck mit seinem Webserver auf dem Port 4440 des Hosts. Für den Betrieb mit SSL und dem regulären Port 443 können Sie die Konfiguration anpassen oder einfach einen Reverse-Proxy mit TLS-Terminierung vorschalten. Die Konfigurationsdateien des Diensts finden sich in nach erfolgter Installation unter "/etc/rundeck". Skripte und andere Dateien für die Automatisierung sortieren Sie in der Verzeichnisstruktur unter "/var/lib/rundeck" ein. Alternativ nutzen Sie das SCM-Plug-in "Git import" und lesen Projekte von einem Git-Repository ein.
Haben Sie in der Vergangenheit mit Tools wie Ansible Tower/Controller oder AWX gearbeitet, werden Sie sich mit Rundeck ziemlich schwertun. Denn die Verwaltung von Jobs und Projekten erfordert einen großen Aufwand und verlangt von Ihnen, redundante Informationen wiederholt an verschiedenen Stellen einzutragen. Eigentlich sollte es genügen, in der Konfiguration des Node-Executors für Ansible dessen Konfiguration zu hinterlegen. Aber das allein reicht nicht: Vielmehr müssen Sie in jedem einzelnen Job-Step, den Ansible verwendet, Informationen wie den "Ansible base directory path" angeben.
Zudem funktioniert das Rundeck-Inventory-System nicht für Ansible – es sei denn, Sie wollen ein Playbook als Node-Step, also einmal separat pro Rundeck-Inventory Host starten – was der Ansible-Architektur widerspricht. Hier müssen Sie Ansible Playbooks also als "Workflow-Step" erzeugen und diesem das Ansible-Inventory via "-i hosts" übergeben; damit läuft Ansible wiederum unabhängig vom Rundeck-Inventory. Rundeck ist damit eigentlich keine brauchbare Alternative zu Tower, Controller oder AWX. Wer ein mit diesen Tools vergleichbares Feature-Set sucht, ist mit Semaphore UI wesentlich besser beraten.
Rundeck überzeugt nicht
Bei Automatisierungsaufgaben ohne Ansible macht Rundeck eine etwas bessere Figur. Hierfür ist das Tool ursprünglich auch gemacht. Jobs wie Shell-, Python- oder PowerShell-Skripte delegiert das Werkzeug via SSH oder WinRM an die Remote-Systeme des Rundeck-eigenen Inventories, die Rückantworten fängt es über Logfilter ab. Dennoch fällt bei diesem Tool der Verwaltungsaufwand, um Skripte und Workflows zu erstellen, sehr aufwendig aus. Auch die eher mäßige Übersicht und inkonsequente Benutzerführung der Rundeck-UI helfen hier nicht weiter.
Zudem zeigen sich im praktischen Betrieb immer wieder Unstimmigkeiten. Ein Beispiel: Wir "parken" den Private Key des Benutzers im Key-Storage. In einem Ansible-Runbook können die einzelnen Workflow-Steps "Ansible Playbook Inline" auf diesen Schlüssel zugreifen. In demselben Projekt legen wir aber auch eine Node-Source mit dem "Ansible Resource Model" ein. Das wiederum kann den Schlüssel nicht verwenden und quittiert ohne klare Fehlermeldung den Dienst. Um das Modul ans Laufen zu bringen, legen wir stattdessen die Originaldatei des privaten Schlüssels in einem Verzeichnis unter "/var/lib/rundeck" ab und weisen diesem der Node-Source zu, dann funktioniert das Plug-in.
Hier lässt sich nicht genau nachvollziehen, warum zwar der Node-Step, nicht aber das Inventory den Schlüssel verwenden kann. Immerhin offeriert Rundeck verschiedene Wege, um mit Schlüsseln umzugehen. Aber gerade diese Freiheit, Funktionen wie eine Authentisierung mit ver- schiedenen Methoden (Key-Storage, Key-File, Username/Password) durchzuführen und im Zweifelsfall in jedem einzelnen Schritt eines Runbooks eine andere Methode heranzuziehen, verkompliziert die Verwaltung. Theoretisch könnten Sie in einem einzigen Job fünf einzelne Schritte mit jeweils anderen Tools und Runtime-Umgebungen durchführen. Die Möglichkeiten wären grenzenlos – damit aber auch das Chaos. Immerhin können Sie Ihre in der UI zusammengestellten Runbooks als XML-Datei exportieren und auf andere Systeme übertragen. Damit lässt sich dann auch eine fertig nutzbare As-Code-Umgebung für Rundeck erstellen.
Auf der einen Seite ist Rundeck auf der einen Seite Rundeck sehr offen dem gegenüber, wie der Admin die Automatisierung gestaltet und welche Tools er dafür verwendet. Auf der anderen Seite sorgt genau diese Offenheit für ziemlich komplizierte Job-Setups und funktioniert eigentlich nur gut mit simplen Skripten. Leider zeigt sich Rundeck zwar bei der Gestaltung der Jobs sehr offen, nicht aber bei den Plug-ins. Die wirklich wichtigen funktionellen Erweiterungen gibt es nur für zahlende Kunden. Auf den ersten Blick zeigt die GUI zwar eine große Fülle frei verfügbarer Plug-ins. Wer dann aber die Git-Repositories dieser offenen Plug-ins durchstöbert, wird leider feststellen müssen, dass alle zwischen drei und elf Jahre alt sind und nicht mehr weiterentwickelt oder gepflegt werden.
Rundeck bleibt damit alte Schule: Es arbeitet brauchbar als Wrapper, um Shell-Skripte via SSH oder WinRM auf anderen Systemen auszuführen. Die Konfiguration und Verwaltung ist recht aufwendig und verwirrend. Rundeck kann dabei aber nicht gut mit modernen Automatisierungstools wie beispielsweise Ansible oder Terraform umgehen, weil diese Tools andere Architekturen verwenden und sich nur mit Tricks in die Runbooks integrieren.
Außenseiter Jenkins sorgt für Überraschung
Vielen Administratoren dürfte Jenkins [3] wenig bekannt sein, denn eigentlich ist es kein Tool für den IT-Betrieb – auch wenn es dort immer häufiger auftaucht. Jenkins stammt aus dem Entwicklerumfeld und kommt dort für Build-Pipelines zum Einsatz. Darin legen Softwareentwickler die einzelnen Schritte fest, die zum Bau, Test und Deployment ihres Softwareprojekts nötig sind. Build-Pipelines lassen sich via Web-UI zusammenbauen oder in einem eigenen Codeformat – dem Jenkins-File – erstellen. Jenkins erzeugt auch die temporären Umgebungen, die für den Build der Software vonnöten sind.
Der "Controller" mit dem Web-UI verwaltet nur die Pipelines und die dazugehörigen Informationen. Die eigentlichen Builds führen Agenten durch, also virtuelle Maschinen oder Container, die der Controller via SSH oder Jenkins-Client kontaktiert, um dort die jeweiligen Tools zu starten. Dadurch können Anwender ihre Build-Jobs auf mehrere Zielsysteme auslagern. In der Praxis kommen dabei Agent-Nodes mit verschiedenen Konfigurationen zum Einsatz, sowohl was die CPU-Architektur als auch die auf den Nodes installierten Build-Tools angeht.
Jenkins setzt auf eine offene, modulare Architektur und anders als bei Rundeck gibt es hier jede Menge aktiv betreuter Community-Plug-ins, wie beispielsweise das für Ansible. Admins, die bereits über eine funktionierendes Jenkins-Setup für Software-Builds verfügen, können mit relativ wenig Aufwand weitere Agent-Nodes hinzufügen und diese für die Infrastruktur-Automatisierung verwenden. Dazu kommen dann Tools wie Ansible, Terraform, Chef oder andere zum Einsatz. Jedoch steht Administratoren ohne Jenkins-Kenntnisse eine steile Lernkurve bevor, sollten sie dieses Tool nur für die Infrastruktur einsetzen wollen. Aber ehrlich gesagt erscheint das Erlernen von Rundeck schwieriger als der Neueinstieg in Jenkins. Das liegt vor allem auch daran, dass Jenkins als Automation-Tool viel häufiger zum Einsatz kommt als Rundeck und es deshalb auch viel mehr Dokumentation, Know-how, Support und offene Plug-ins dafür gibt.
Ein kompliziertes Pipeline-Build-Tool für Workflows im IT-Betrieb heranzuziehen, erscheint auf den ersten Blick ein wenig zu viel des Guten. Allerdings ist das Tool weniger kompliziert als befürchtet und wirkt selbst für Neueinsteiger tatsächlich einfacher und aufgeräumter als Rundeck. Die Installation des Java-basierten Automation-Controllers und seiner Nodes ist recht einfach und die Vielzahl der Plug-ins hilft bei Funktionalität und Sicherheit. Anders als beispielsweise Semaphore UI kann Jenkins Secrets aus bestehenden Ansible- oder Hashicorp-Vaults in den Pipelines verwenden und der integrierte Credential-Storage kann verschlüsselte Dateien mit nahezu beliebigen Inhalten sicher aufbewahren.
Fazit
In kleinen bis mittelgroßen Umgebungen mit Terraform oder Ansible lassen sich mit Semaphore UI schnell und einfach gute Ergebnisse erzielen. Das Tool ist noch jung und es bleibt zu hoffen, dass es einige der hier bemängelten Funktionen wie einen besseren Vault-Support nachrüstet. Rundeck enttäuscht ein wenig, denn für moderne Tools wie Ansible ist es nur mäßig geeignet. Nur IT-Verantwortliche mit Automatisierung per Shell-Skript ziehen einen Nutzen daraus – wobei der Aufwand recht hoch ausfällt. Negativ fällt ins Gewicht, dass eigentlich nur noch Plug-ins für die Enterprise-Version gewartet werden, während die Open-Source-Community das Projekt immer mehr im Stich zu lassen scheint.
Ganz anders sieht das wiederum beim Altmeister Jenkins aus, mit einer sehr aktiven Community und zeitgemäßen Plug-ins. Obwohl es sich als ein sehr umfangreiches und damit auch kompliziertes Tool für Build-Pipelines präsentiert, sind diese Funktionen doch erstaunlich einfach für Automatisierungsaufgaben im IT-Betrieb verwendbar. Bestehendes Jenkins-Know-how hilft zwar, doch die Lernkurve ist weniger steil als anzunehmen. Für Jenkins sprechen sowohl die gute Integration mit Vault-Tools und der verteilte Ansatz mit Agenten als auch die große und aktive Community, die das Projekt vorantreibt.
(jp)
Link-Codes
[1] Semaphore UI: https://semaphoreui.com/
[2] Rundeck: https://www.rundeck.com/
[3] Jenkins: https://www.jenkins.io/