Ansible-Oberfläche: Semaphore UI vs. Ansible Automation Platform (AAP)

AAP 2.6 unterstützt eine containerisierte Podman-Installation auf RHEL und eine Operator-basierte Installation auf OpenShift. Der ältere RPM-Installer bleibt in 2.6 für Migrationen auf RHEL 9 unterstützt, ist aber abgekündigt. Red Hat dokumentiert unterstützte Topologien und einen Produktlebenszyklus für diese Bereitstellungen. Kubernetes ist nicht für jede AAP-Installation erforderlich.

Semaphore UI kann als Binärprogramm oder natives Paket auf einem vorhandenen Host sowie über Docker oder Kubernetes laufen. Ein Team, das eine gemeinsame Ansible-Oberfläche einführt, kann eine herkömmliche Serverinstallation wählen und bereits betriebene Repositories und Infrastruktur wiederverwenden. Enterprise ergänzt Hochverfügbarkeit, wenn der Automatisierungsdienst redundante Anwendungsinstanzen benötigt. Der Semaphore-UI-Server läuft auch nativ unter Windows. Die Ansible-Ausführung benötigt dagegen WSL, einen Container oder einen Linux-Runner.

Semaphore UI kann Patching- und Deployment-Jobs von einem vorhandenen Server aus teilen. Die Deployment-Topologie von AAP hängt von den gewählten Komponenten und der Ausführungskapazität ab, die das Team bereitstellen muss.

AAP verwendet Ansible-Playbooks und Execution Environments, Container-Images mit der Ansible-Laufzeit und den erforderlichen Abhängigkeiten. Seine Terraform-Integrationen umfassen Collections zur Koordination von Terraform-Diensten. Playbooks können weitere Kommandozeilenwerkzeuge aufrufen. Das ist ein schlüssiges Modell, wenn Ansible bereits die gesamte Prozedur orchestriert.

Semaphore UI ist ebenfalls auf praktische Ansible-Vorgänge ausgerichtet und gibt zugleich Terraform/OpenTofu, Terragrunt, Bash, PowerShell und Python eigene Task Templates. Für Terraform/OpenTofu wählt ein Ingenieur Repository, Konfigurationsverzeichnis, Workspace und Variablengruppe in der Oberfläche. Das IaC-Werkzeug läuft direkt, ohne ein Ansible-Playbook, das nur zu seinem Aufruf geschrieben wurde. Ein Ansible-Deployment, ein Terraform-Provisionierungsjob und eine Python-Prüfaufgabe können daher ein Projekt teilen und zugleich ihre eigenen Ausführungseinstellungen behalten.

Eine temporäre Testumgebung benötigt beispielsweise zunächst Infrastruktur, anschließend Anwendungskonfiguration und eine Bereitschaftsprüfung. Semaphore UI belässt diese Schritte in ihren vorhandenen Werkzeugen und verbindet sie durch einen Workflow. Das ist nützlich für Teams, deren Automatisierung über mehrere Repositories und Sprachen gewachsen ist, die aber weiterhin einen Ort zum Starten und Prüfen des Vorgangs möchten.

Konfigurieren Sie getrennte State-/Backend-Adressen oder unterstützte Workspaces für Entwicklung, Staging und Produktion. Workspace-Unterstützung hängt vom gewählten Backend ab. Semaphore UI Pro kann diesen State selbst über sein integriertes HTTP-Backend hosten, mit State-Versionshistorie und Verwaltung in der Oberfläche. Für ein Team, das temporäre Umgebungen erstellt, bleiben Provisionierungsvorlage, State und spätere Ansible-Konfiguration in einem Dienst. Die dokumentierten Terraform-Integrationen von AAP verwenden Terraform-Dienste oder ein konfiguriertes externes Backend für State. Semaphore UI kann ein externes Backend ebenfalls beibehalten, wenn das Team bereits eines besitzt.

Soll ein Prozess genau den gespeicherten Terraform-Plan genehmigen und anwenden, konfigurieren Sie ausdrücklich die Speicherung und Wiederverwendung des Plans. Die Standardausführung von Semaphore UI plant und wendet getrennt an. Ihre Standardbefehle verwenden -lock=false, sofern sie nicht überschrieben werden. Ein bereitgestelltes State-Backend ändert diese Aufgabenbefehlseinstellungen nicht.

Ein AAP Job Template speichert Projekt, Playbook, Inventar, Zugangsdaten und Execution Environment für einen Vorgang. Sein Start erzeugt einen Job. Ein Survey erfasst die für diesen Start freigegebenen Eingaben, sodass ein Bediener eine vorbereitete Prozedur ausführen kann, ohne deren Konfiguration neu zu erstellen.

Semaphore UI verwendet Task Templates für dasselbe Muster wiederverwendbarer Starts bei Ansible und seinen anderen Automatisierungswerkzeugen. Eine Ansible-Vorlage wählt Repository, Playbook, Inventar und Zugangsdaten. Benannte Variablengruppen halten vorlagenübergreifend wiederverwendete Konfiguration. Formularfelder erfassen dagegen die Werte für eine einzelne Ausführung. AAP kann Variablen über Inventare und Dateien in Git wiederverwenden.

Betrachten Sie eine mit Supportkollegen geteilte Dienstneustartprozedur. Ein Ingenieur bereitet Playbook und Umgebungskonfiguration vor und fragt im Startformular nach Dienstname und Änderungsreferenz. Der Kollege wählt den Vorgang, liefert diese Eingaben und verfolgt Status und Ausgabe. Separate Vorlagen können ein Deployment, eine Sicherung oder eine Zertifikatserneuerung mit denselben Projektressourcen bereitstellen.

Beide Produkte planen auch gespeicherte Vorlagen. AAP bietet einmalige und wiederkehrende Zeitpläne. Semaphore UI unterstützt Cron-Ausdrücke und einmalige Ausführungen mit konfigurierten Eingaben. Die Sicherung vor einem manuellen Wartungsfenster kann auch nachts nach Zeitplan laufen. Dadurch verwendet das Team eine Betriebsprozedur wieder, statt einen separaten Cron-Befehl und eine Web-Startkonfiguration zu pflegen.

AAP synchronisiert Inventarquellen in verwaltete Hosts und Gruppen, mit gespeicherten Facts und konstruierten Inventaren für komplexere Ansible-Vorgänge. Ein Bediener kann Informationen einzelner Hosts in derselben Plattform prüfen und verwalten, in der Jobs gestartet werden. Das ist nützlich, wenn das Pflegen dieser Datensätze und das Kombinieren von Inventarquellen zur täglichen Arbeit gehören. AAP kann Inventarquellen nach Zeitplan oder vor dem Start aktualisieren und Host-Facts optional in einem verwalteten Cache behalten.

Semaphore UI verwendet statische oder Git-basierte Inventardefinitionen und Ansible-Discovery-Plugins wieder, darunter solche für NetBox und Cloud-APIs. Bediener können INI/YAML-Definitionen in der Oberfläche bearbeiten oder Git und externe Discovery als Quelle der Hostinformationen beibehalten. Eine Vorlage wählt bei der Ausführung das benötigte Inventar. Dynamische Ermittlung findet während der Ausführung statt. Das konfigurierte Fact-Caching von Ansible bleibt verfügbar. Semaphore UI bietet jedoch keinen controllerverwalteten Fact-Cache.

Für ein Team, das seinen Bestand bereits außerhalb der Automatisierungsoberfläche pflegt, vermeidet das einen zweiten Hostverwaltungsprozess allein zum Teilen von Jobs. Dasselbe Inventar kann Patching, Zertifikatsprüfungen und Deployments dienen, mit getrennten Vorlagen und Eingaben für jeden Vorgang. AAPs synchronisierte Host- und Gruppenansicht bleibt wertvoll, wenn Bediener diese verwaltete Ansicht benötigen und nicht nur ein Inventar als Ausführungsziel.

Beide Produkte speichern Zugangsdatenreferenzen mit dem vorbereiteten Vorgang. Ein Ingenieur kann Repository-Zugriff, Maschinenzugangsdaten und weitere Secrets einmal konfigurieren und anschließend über Deployments und Wartungsjobs hinweg wiederverwenden. Kollegen, die den Vorgang starten, müssen diese Zugangsdaten nicht bei jeder Ausführung erneut angeben.

AAP unterstützt Zugangsdatenobjekte und externe Secret-Lookups, darunter Integrationen für HashiCorp Vault, AWS Secrets Manager, Azure und CyberArk. Semaphore UI bietet einen projektbezogenen Key Store und verbindet HashiCorp Vault oder OpenBao in Pro. Enterprise ergänzt AWS Secrets Manager, Azure Key Vault, Devolutions Server und CyberArk über seine PVWA API. AAP kann die Devolutions-Ansible-Collection in Playbooks verwenden, wenn sie im Execution Environment installiert ist. Seine integrierten Zugangsdaten-Connectors enthalten keinen eigenen OpenBao-Lookup. AAP bietet außerdem Connectors für Centrify Vault und Thycotic Secret Server oder DevOps Secrets Vault, die Semaphore UI nicht als integrierte Speicher bereitstellt. Eine Ansible-Lookup-Collection oder ein Befehl kann Secrets für einen Vorgang abrufen, wenn ein Plattform-Connector fehlt. Diese Integration wird dann in der Automatisierung gepflegt. Teams können daher nach ihrem vorhandenen Vault und den Verbindungen wählen, die sie in der Plattform selbst konfigurieren möchten.

AAP führt Jobs in Execution Environments mit Ansible und den Playbook-Abhängigkeiten aus. Ausführungsknoten erledigen Arbeit getrennt von den Steuerungsdiensten. Automation mesh verbindet diese Knoten und kann Zwischenstationen, sogenannte Hop Nodes, verwenden, um entfernte Netzwerke zu erreichen. Das unterstützt einen verteilten Ansible-Bestand mit definierten Ausführungsimages und Netzwerkpfaden.

Semaphore UI kann Automatisierung auf seinem Server oder auf Runnern nahe den Zielsystemen ausführen. Beispielsweise kann ein Runner in einem privaten Netzwerk einen Ansible-Wartungsjob auf lokalen Hosts ausführen, während die gemeinsame Oberfläche an einem anderen Ort bleibt. Globale Runner sind in Community verfügbar. Pro ergänzt projektgebundene Runner und tagbasiertes Routing für unterschiedliche Ausführungsumgebungen.

Ein Team kann mit direkter Ausführung beginnen und separate Maschinen oder Container pro Aufgabe ergänzen, wenn die Arbeitslasten sie benötigen. Pro bietet Docker-Aufgabenausführung, Enterprise ergänzt Kubernetes-Aufgabenausführung. Ein Dienst mit vorhandenen Playbooks erhält damit einen Weg vom einzelnen Host zur getrennten Ausführung, ohne ein Automation-mesh-Deployment zu benötigen. Die Containerisierung des Anwendungsservers ist eine andere Entscheidung als die Containerisierung jeder Aufgabe.

AAP Workflow Job Templates verbinden Job Templates, Projektupdates, Inventarupdates und andere Workflows. Genehmigungsschritte pausieren eine Ausführung. Ansible-set_stats-Werte können an spätere Jobs übergeben werden. Einen Workflow einzubetten ist wertvoll, wenn mehrere Prozeduren eine vollständige Sequenz teilen, die nur einmal gepflegt werden sollte.

Semaphore-UI-Workflows verbinden Ansible-, Terraform/OpenTofu-, Terragrunt-, Bash-, PowerShell- und Python-Task-Templates direkt, mit Erfolgs- und Fehlerzweigen, Genehmigungen und Verzögerungen. Ein Provisionierungsworkflow kann Infrastruktur mit Terraform/OpenTofu erstellen, sie mit Ansible konfigurieren und eine Python-Bereitschaftsprüfung ausführen. Ein Wartungsworkflow kann mit einer Sicherung beginnen, Updates anwenden und Prüfungen ausführen. Dabei verwendet er Vorlagen wieder, die Kollegen auch separat starten können. AAP kann dieselbe Prozedur über Ansible Job Templates und Terraform-Integrationen orchestrieren. Der Unterschied liegt darin, ob die Ausführungskonfiguration jedes Werkzeugs in einer eigenen Vorlage oder in den Playbooks und Integrationen hinter Ansible-Jobs liegt.

Semaphore UI 2.20 übergibt Ansible-set_stats-Werte, Terraform/OpenTofu/Terragrunt-Ausgaben und JSON aus Bash, PowerShell oder Python an spätere Aufgabeneingaben. Eine von der Provisionierung zurückgegebene Adresse oder Ressourcenkennung kann dadurch zur Eingabe des nächsten Vorgangs werden. AAP übergibt set_stats-Werte zwischen Ansible-Jobs. Beide bieten eine nützliche Werteübergabe. Der Unterschied liegt darin, wie das Ergebnis erzeugt und verwendet wird. Die empfangende Vorlage deklariert die Eingabe, die ihr Playbook oder ihre Inventarkonfiguration anschließend zur Ansprache des neuen Hosts verwendet.

AAP bietet eine zuweisbare Approve-Berechtigung für Workflow-Genehmigungen. Semaphore UI 2.20 knüpft die Genehmigung an die Berechtigung zur Ausführung von Projektaufgaben. Eine separate Genehmigerrolle ist für 2.21.0 angekündigt. Das zählt, wenn Genehmigungsverantwortung eine eigene Berechtigung benötigt.

Ein Provisionierungs- und Konfigurationsworkflow kann erfasste Werte mit dem lokalen Executor zwischen Semaphore-UI-Aufgaben übergeben, auf dem Server oder einem entfernten Runner. Docker- und Kubernetes-Executors erfassen diese Ausgaben nicht. Ein davon abhängiger Workflow braucht daher eine andere Ausführungsanordnung. Einzelne Aufgabenvorlagen bleiben workflowübergreifend wiederverwendbar. Müssen mehrere Prozeduren einen vollständigen mehrstufigen Workflow wiederverwenden, vermeiden verschachtelte AAP-Workflows die getrennte Pflege dieser Sequenzen. In beiden Plattformen benötigen Dateien wie gespeicherte Terraform-Pläne zugänglichen Speicher oder eine ausdrückliche Übertragung zwischen Jobs.

AAP gewährt Zugriff auf einzelne Ressourcen und unterstützt benutzerdefinierte Rollen. Bediener können unabhängig von Jobvorlagen die Berechtigung zur Nutzung bestimmter Inventare und Zugangsdaten erhalten. Das passt zu Teams, deren tägliche Arbeit darin besteht, autorisierte Ansible-Ressourcen zu neuen Vorgängen zu kombinieren.

Semaphore UI organisiert Zugriff rund um Projekte und vorbereitete Vorgänge. Community-Projektrollen unterstützen bereits die Trennung zwischen Ingenieuren, die Automatisierung pflegen, und Kollegen, die sie ausführen. Ein Projekt kann Deployment-, Sicherungs- und Wartungsvorlagen eines Teams mitsamt ihren konfigurierten Ressourcen bündeln.

Enterprise ergänzt benutzerdefinierte Rollen und Ausführungsberechtigungen auf Vorlagenebene, wenn der Zugriff auf bestimmte Vorgänge begrenzt werden muss. Supportmitarbeiter können beispielsweise eine Dienstneustartvorlage erhalten, während Deployments bei einer anderen Rolle bleiben. Inventar, Zugangsdaten und erlaubte Startüberschreibungen gehören zur vorbereiteten Konfiguration. Das ist ein fokussiertes Modell zur Delegation von Vorgängen. AAP bietet dagegen unabhängige Berechtigungen auf den zugrunde liegenden Ressourcen.

Beide unterstützen LDAP-Integration. Semaphore UI Pro bietet außerdem OIDC-Anmeldung. AAP unterstützt OIDC, SAML und weitere zentral konfigurierte Identitätsanbieter. Semaphore UI besitzt keine integrierte SAML-Anbindung. Semaphore UI Pro ergänzt zudem TOTP-Zwei-Faktor-Authentifizierung für lokale Konten.

Betriebliche Ergebnisse stehen an erster Stelle, wenn ein Kollege wissen muss, ob ein Deployment- oder Wartungsjob fertig ist. Beide Produkte speichern Ausführungsoutput und Historie. Semaphore UI erfasst Aufgabenstatus, Repository-Revision und Startdetails. Pro ergänzt eine Ansible-Hostübersicht mit fehlgeschlagenen Aufgaben pro Server. Nach einem Patching- oder Zertifikatsjob kann der Bediener betroffene Hosts identifizieren und die zugehörige Ausgabe prüfen.

Administratives Audit dient einem anderen Zweck. Der Aktivitätsstrom von AAP erfasst Änderungen an Plattformressourcen, und Logging-Integrationen leiten Job- und Systemereignisse weiter. Semaphore UI bietet ein Administrator-Audit-Log für Anmeldungen, Berechtigungsänderungen und weitere aufgezeichnete Aktionen. Pro ergänzt Filter, Dateiexport und Weiterleitung über TLS Syslog oder Splunk HEC. Dadurch können diese Ereignisse in Sicherheitsuntersuchungen und SIEM-Aufzeichnungen der Organisation einfließen.

Der automation hub von AAP verteilt Collections und Ausführungsimages und bietet Zugriff auf von Red Hat zertifizierte und validierte Inhalte. Event-Driven Ansible bewertet Ereignisse anhand von Rulebooks und löst Automatisierung aus. Dies sind Plattformdienste zur Verwaltung und Initiierung von Automatisierung in einer Organisation, die über einen eingehenden Webhook für einen gespeicherten Job hinausgehen.

Semaphore UI passt über seine REST-API und Webhook-Integrationen mit Abgleich und Eingabeextraktion zu vorhandenen CI-, Monitoring- und Anfragesystemen. Eine Build-Pipeline kann eine Version veröffentlichen und ein vorbereitetes Deployment anfordern. Ein Ereignisprozessor kann einen Diagnosevorgang anfordern. Semaphore UI hält Inventar, Zugangsdaten und Ausführungsaufzeichnung dieses Vorgangs vor. Der Aufrufer übernimmt die Authentifizierung und prüft das Aufgabenergebnis, wenn der umgebende Prozess auf den Abschluss warten muss.

Sowohl Semaphore UI als auch automation controller bieten Startformulare für vorbereitete Jobs. AAP bietet außerdem ein separat bereitgestelltes Ansible-Automatisierungsportal auf Basis von Red Hat Developer Hub mit Self-Service-Katalog, Vorlagensynchronisierung und eigenen Integrationen. Die Nutzung von Developer Hub für dieses Portal ist im AAP-Abonnement enthalten. Teams, die gemeinsame Jobausführung ohne diesen Katalog benötigen, erhalten mit Semaphore UI eine fokussierte Oberfläche für Ansible und weitere Automatisierungswerkzeuge.

AAP bietet einen offiziellen MCP-Server, der kompatiblen Assistenten Plattformvorgänge zugänglich macht. Er kann mit der Plattform oder als eigenständiger Container bereitgestellt werden. AAP bietet außerdem einen optionalen intelligenten Automatisierungsassistenten in seiner Oberfläche, verbunden mit einem konfigurierten Modellanbieter. Damit erweitert es seinen integrierten Plattformansatz auf KI-gestützte Vorgänge.

Für Semaphore UI gibt es einen Community-MCP-Connector für die API. Offizielle MCP-Unterstützung für Pro wurde für Version 2.21.0 angekündigt. Claude Code oder Codex können außerdem die öffentliche Dokumentation, den Quellcode und API-Definitionen heranziehen, um Vorlagen vorzubereiten, Integrationscode zu schreiben oder anhand bereitgestellter Konfigurationen und Ausgaben einen fehlgeschlagenen Lauf zu untersuchen. Ein Team kann diese Unterstützung mit seinem bestehenden Automatisierungsdienst nutzen, ohne eine umfassendere Plattform einzuführen.