Terraform-Oberfläche: Semaphore UI vs. Gaia

Gaia trennt seine Java-Webanwendung, MongoDB-Datenbank und den Ausführungs-Runner. Der Runner startet Terraform in Docker-Containern oder Kubernetes-Pods, mit einem konfigurierbaren Limit für parallele Jobs. Docker Compose stellt diese Dienste zusammen. Ein experimentelles Helm-Chart bietet eine Kubernetes-Installationsmöglichkeit.

Semaphore UI läuft als Binärprogramm oder natives Paket sowie in Docker oder Kubernetes. Ein Team, das Routineautomatisierung von den Laptops seiner Ingenieure verlagert, kann auf einem vorhandenen Server beginnen und denselben Dienst für Terraform-Provisionierung und Ansible-Wartung verwenden. Der gewählte Ausführungsmodus bestimmt, ob Jobcontainer erforderlich sind.

Gaia führt Terraform-Module über eine generierte Terraform-Befehlssequenz aus. Terraform-Provisioner können Ansible oder Kommandozeilenprogramme aufrufen, wenn das Runner-Image oder das entfernte Ziel die erforderlichen Werkzeuge bereitstellt. Damit kann eine neu bereitgestellte Ressource konfiguriert werden. Der Befehl bleibt aber an eine Terraform-Ausführung gebunden, statt ein unabhängiger Gaia-Vorgang zu werden. Die standardmäßige Befehlserzeugung bietet keine separate OpenTofu- oder Terragrunt-Vorlage.

Semaphore UI hat direkte Vorlagen für Ansible, Terraform/OpenTofu, Terragrunt, Bash, PowerShell und Python. Ein Team kann Infrastruktur mit OpenTofu erstellen, Pakete mit Ansible konfigurieren und eine Python-Bereitschaftsprüfung ausführen. Später können die Ansible-Konfiguration oder der PowerShell-Wartungsvorgang allein laufen, ohne einen weiteren Terraform-Lebenszyklus zu starten. Das integrierte Pro-State-Backend hält außerdem Terraform/OpenTofu State und dessen Historie neben diesen Jobs.

Der Modulautor in Gaia definiert Quellrepository, Terraform-Version und Variablenschema. Nutzer erstellen Stacks aus diesem Modul und liefern passende Werte und Cloud-Zugangsdaten für ihre Umgebung. Der Stack wird zu einer dauerhaften Instanz mit eigenem State und eigenen Jobs. Das passt zu einem Katalog unabhängig angeforderter Infrastruktur. Gaia validiert Pflichtwerte und konfigurierbare reguläre Ausdrücke. Semaphore-UI-Eingabeformulare validieren Pflichtfelder, Ganzzahlen und Auswahlwerte, ohne gleichwertige konfigurierbare Regex-Regel.

Semaphore UI nennt den gespeicherten Vorgang Task Template. Es verbindet ein Repository, Werkzeugkonfiguration, Variablen und die benötigten Inventare oder Zugangsdaten. Benannte Variablengruppen verwenden Umgebungseinstellungen über Vorlagen hinweg wieder. Formularfelder erfassen die Starteingaben. Eine Dienstneustartvorlage kann beispielsweise eine Auswahl von Dienst und Umgebung anbieten, statt den Kollegen einen Befehl zusammenstellen zu lassen. Eine Provisionierungsvorlage kann dasselbe Muster für Umgebungsparameter nutzen.

Gaia führt plan, apply und destroy mit dem konfigurierten Modul, den Eingaben und Cloud-Zugangsdaten eines Stacks aus. Sein integriertes Backend hält den State dieses Stacks. Die Stack-Seite sammelt Ausgaben und Jobhistorie. Separate Testumgebungen können daher unabhängigen State und eigene Ausführungsaufzeichnungen behalten, auch wenn sie aus demselben Modul stammen.

Semaphore UI verwendet ein Task Template zur Auswahl von Terraform/OpenTofu-Repository, Workspace und Konfiguration. Variablengruppen verwenden Einstellungen über verwandte Jobs hinweg wieder. Eingabeformulare erfassen Werte beim Start. Ein Ingenieur kann einen Umgebungsbereitstellungsvorgang einmal vorbereiten und Kollegen ihn anschließend über diese gespeicherte Konfiguration anfordern lassen. Jede Umgebung benötigt auch eigene Variablen, Zugangsdaten und Backend-State. Gaia stellt diese als separate Stack-Instanzen dar. In Semaphore UI bereitet das Team die entsprechende Vorlagen-, Workspace- und Backend-Konfiguration vor. Workspace-Isolation hängt vom Backend ab. Allein die Auswahl eines Workspace trennt daher nicht bei jedem Backend den State. Terragrunt und OpenTofu stehen neben Terraform als direkte Vorlagenoptionen bereit.

State ist ein eigener Teil dieser Einrichtung. Gaia enthält ohne kommerzielle Lizenz ein State-Backend für jeden Stack. Semaphore UI verwendet das für den Terraform/OpenTofu-Code konfigurierte Backend. Pro bietet zusätzlich ein integriertes HTTP-State-Backend mit Historie und Verwaltung in der Oberfläche. Dieses Backend in Semaphore UI zu halten platziert den gemeinsamen State neben die Jobs, die ihn ändern, statt einen weiteren State-Dienst hinzuzufügen.

Keines der Produkte wendet standardmäßig eine zuvor gespeicherte Plandatei an. Gaia 2.4.0 zeigt das Planungsergebnis, aber sein apply-Befehl verwendet nicht die gespeicherte Plandatei. Die Standardausführung von Semaphore UI plant und wendet ebenfalls getrennt an. Muss eine Genehmigung genau die vorgeschlagene Änderung umfassen, braucht die Prozedur eine ausdrückliche Speicherung und Wiederverwendung dieses Plans.

Gaia hält Terraform-Ressourcen und Ausgaben bei jedem Stack. Eine Terraform-Ausgabe kann die von einem Provisioner oder einem anderen System benötigte Hostadresse liefern, erstellt aber keine Ansible-Inventarressource in Gaias Oberfläche. Über einen Provisioner aufgerufenes Ansible muss sein Inventar als Teil dieser Automatisierung erhalten oder erzeugen.

Semaphore UI speichert Ansible-Inventare als wiederverwendbare Projektressourcen. Teams können eine statische Definition bearbeiten, eine Datei aus Git verwenden oder Ansible-Inventarplugins Hosts beim Jobstart ermitteln lassen. Dasselbe Inventar kann Deployment, Patching und Zertifikatsprüfungen dienen. Das ist besonders nützlich, wenn Provisionierung nur der Anfang der Arbeit ist und Bediener während des gesamten Lebenszyklus zu einem bestehenden Bestand zurückkehren.

Gaia trennt die Anwendung von ihrem Runner. Der Runner fragt ausstehende Terraform-Schritte ab und führt sie in Docker-Containern oder Kubernetes-Pods mit konfigurierbarer Parallelität aus. Er kann nahe an privater Infrastruktur laufen, solange er die Gaia-API und die vom Modul verwendeten Dienste erreicht. Das gewählte Image liefert Terraform und zusätzliche Programme, die Provisioner benötigen.

Semaphore UI kann Jobs auf seinem Anwendungsserver oder auf Runnern nahe den Zielsystemen ausführen. So kann eine kleine Installation ohne Containerplattform beginnen und eine größere getrennte Netzwerke über Runner erreichen. Pro ergänzt Projekt-Runner und Docker-Jobausführung. Enterprise ergänzt Kubernetes-Job-Pods. Die Webanwendung in Docker zu installieren und jeden Job in seinem eigenen Container auszuführen bleiben getrennte Entscheidungen.

Semaphore UI speichert Cron- und einmalige Zeitpläne für vorbereitete Vorlagen. Eine nächtliche Sicherung, eine wiederkehrende Zertifikatsprüfung oder ein Patching-Job können Inventar, Zugangsdaten und Starteinstellungen des Autors wiederverwenden. Manuelle und geplante Ausführungen erscheinen anschließend in derselben Ausführungshistorie.

Gaia 2.4.0 enthält keine Zeitplanungsoberfläche. Ein externer Scheduler kann einen RUN- oder DESTROY-Job über POST /api/stacks/{id}/{jobType} erstellen und dessen Plan anschließend über POST /api/jobs/{jobId}/plan starten. Nach Abschluss des Plans wird die Änderung mit einem separaten POST an /api/jobs/{jobId}/apply angewendet. Ein Scheduler muss diesen Lebenszyklus verarbeiten und das endgültige Jobergebnis prüfen, statt die Erstellung einer Job-ID als abgeschlossene Ausführung zu behandeln.

Gaia führt einen Stack durch Planung und Anwendung. Seine Oberfläche bietet nach dem Plan eine separate Bestätigung, auch beim Zerstören eines Stacks. Terraform-Provisioner können weitere Aktionen innerhalb dieses Lebenszyklus ausführen. Ein externes System kann mehrere Jobs über die API koordinieren. Gaia bietet keinen visuellen Graphen unabhängig wiederverwendbarer Ansible-, Terraform- und Skriptvorgänge.

Semaphore UI verbindet gespeicherte Vorlagen durch einen visuellen Workflow mit Genehmigung sowie Erfolgs- und Fehlerpfaden. Ein Rollout kann Infrastruktur bereitstellen, auf Genehmigung warten, Hosts konfigurieren und einen Prüfschritt ausführen. Jede Vorlage bleibt für spätere Wartung verfügbar. Erfasste Werte können mit dem lokalen Executor auf dem Server oder einem Runner zwischen Schritten übergeben werden. Erzeugte Dateien und gespeicherte Terraform-Pläne benötigen weiterhin zugänglichen Speicher oder eine ausdrückliche Übertragung. Keines der Produkte wendet standardmäßig einen zuvor gespeicherten Terraform-Plan an.

Gaia verwendet Organisationen zum Teilen von Modulen und besitzt Administrator- und Nutzerrollen. Ein Modulautor kann einem Team eine genehmigte Terraform-Definition bereitstellen, während Nutzer die Konfiguration ihrer eigenen Stacks liefern. GitHub- und GitLab-Integrationen verbinden OAuth2-Anmeldung mit Repository-Import. LDAP wird ebenfalls unterstützt.

Semaphore UI Community organisiert gemeinsame Automatisierung in Projekten. Projektrollen steuern, wer Automatisierung im Projekt ansehen, ausführen oder bearbeiten darf. Kollegen mit Ausführungsberechtigung können ein Deployment, eine Sicherung oder einen Wartungsjob starten und das Ergebnis prüfen. Der Ingenieur bereitet den Vorgang vor. Der Kollege nutzt dessen gespeicherte Konfiguration und Starteingaben.

Enterprise ergänzt benutzerdefinierte Rollen und Ausführungsberechtigungen auf Vorlagenebene, wenn der Zugriff auf ausgewählte Vorgänge beschränkt werden muss. Beispielsweise kann ein Team eine Dienstneustartvorlage delegieren, ohne dem Bediener allgemeine Projektbearbeitungsrechte zu geben. Diese Grenze ergibt sich gemeinsam aus Rollenberechtigungen und Vorgangskonfiguration, nicht allein aus dem Eingabeformular. Pro ergänzt LDAP- und OIDC-Anmeldung für Teams mit einem zentralen Identitätsanbieter. Semaphore UI Pro ergänzt außerdem TOTP-Zwei-Faktor-Authentifizierung für lokale Konten.

Gaia liefert Cloud-Zugangsdaten für AWS, Google Cloud und Azure. Seine optionale Vault-Integration verwendet die Transit Engine zur Verschlüsselung und kann dynamische AWS-Zugangsdaten von einer Vault Secrets Engine anfordern. Diese Zugangsdaten unterstützen den Terraform-Stack-Lebenszyklus.

Der Key Store von Semaphore UI unterstützt die in den Teamprozeduren verwendeten Zugangsdaten, einschließlich SSH-Schlüsseln und Passwörtern für Ansible-Hosts. Ein vorbereiteter Vorgang verweist auf diese gespeicherten Einträge, statt den Bediener bei jedem Start zum Einfügen von Zugangsdaten aufzufordern. Pro ergänzt Secret-Lookups aus HashiCorp Vault und OpenBao. Enterprise ergänzt Integrationen für AWS Secrets Manager, Azure Key Vault und Devolutions Server sowie CyberArk über seine PVWA API.

Beispielsweise kann eine Umgebung Cloud-Zugangsdaten für die Provisionierung und einen SSH-Schlüssel für die anschließende Ansible-Konfiguration nutzen. Es bleiben getrennte Zugangsdaten, die dem jeweiligen Vorgang zugeordnet sind. Beide Plattformen können mit Vault arbeiten. Gaias Verschlüsselung und dynamische Zugangsdaten unterscheiden sich jedoch vom Abruf eines gespeicherten Secrets für einen Job. Die integrierten Zugangsdatenarten von Gaia enthalten keine Connectors für die anderen oben aufgeführten Secret-Speicher. Terraform-Code kann Secrets über eigene Datenquellen oder externe Befehle abrufen. Dieser Lookup wird in der Automatisierung konfiguriert und gepflegt, nicht in Gaias Zugangsdatenoberfläche.

Gaia erfasst Nutzer, Status, Zeitangaben und plan/apply-Schritte eines Stack-Jobs. Diese Historie hilft dem Team, Provisionierungsänderungen einer Umgebung und die Terraform-Ausgabe zu untersuchen. Sie dokumentiert Stack-Vorgänge und ist keine Ansible-Hostberichts- oder administrative Audit-Oberfläche.

Semaphore UI speichert die Aufgabenhistorie über alle unterstützten Werkzeuge hinweg. Ansible-Übersichten in Pro ergänzen Host- und Aufgabenergebnisse und helfen Bedienern zu erkennen, auf welchen Servern ein Patch oder eine Zertifikatsprüfung fehlgeschlagen ist. Das Audit-Log erfasst Anmeldungen und unterstützte administrative Aktionen getrennt von der Aufgabenausgabe. Ein Team mit Provisionierung und Hostwartung kann diese Vorgänge daher im selben Dienst untersuchen, ohne Terraform State als Bericht über jede Aktion auf einem Server zu behandeln. Pro ergänzt Audit-Filter und Export, einschließlich Syslog- und Splunk-HEC-Übertragung für die SIEM-Pipeline des Teams.

Gaia importiert Module aus GitHub oder GitLab und stellt APIs für Stacks, Jobs und ihre Ergebnisse bereit. Eine CI-Pipeline oder ein externer Anfragedienst kann einen Stack-Job erstellen, die Planung starten und entscheiden, wann der Plan angewendet wird. Eine webhookgesteuerte Einrichtung braucht einen Adapter, der diese Aufrufe ausführt und das Ergebnis verfolgt. Semaphore UI bietet eine REST-API und eingehende Integrationswebhooks, die Anfragen abgleichen und ihre Werte den vorbereiteten Aufgabeneingaben zuordnen.

Ein Team, das Gaias Terraform-Katalog beibehält, kann über eine API-Integration nach abgeschlossener Provisionierung eine Ansible-Konfigurations- oder Wartungsvorlage in Semaphore UI auslösen. Semaphore UI verwaltet dann Inventar, Zugangsdaten und Ausführungsaufzeichnung dieses Vorgangs. Diese Verbindung implementiert das Team selbst. Sie ist keine integrierte Gaia-zu-Semaphore-Integration. Beide Projekte veröffentlichen außerdem Dokumentation und Quellcode, die ein Programmierassistent beim Entwerfen dieser Verbindung oder Untersuchen von Konfiguration und Jobausgabe heranziehen kann.