Rundeck-Alternative
Runbook-Automation ohne JVM, ohne SQL-Datenbank und ohne in der GUI erstellte Jobs.
Dagu ist eine Rundeck-Alternative für Ops-Teams, die geplante Jobs, On-Demand-Runbooks und eine Web UI aus einem einzigen kleinen Binary wollen. Jobdefinitionen leben als YAML in Git statt hinter einer Konsole, der Zustand liegt in Dateien statt in MySQL oder Postgres, und bestehende Server werden über SSH oder mit gelabelten Workern erreicht. Diese Seite beschreibt auch den Migrationspfad und die Stellen, an denen Rundeck die stärkere Wahl bleibt.
# restart-app.yaml
params:
- name: host
default: app01.internal
ssh:
user: ops
host: ${params.host}
key: ~/.ssh/ops_key
steps:
- id: drain
run: /opt/app/bin/drain --wait
- id: restart
run: sudo systemctl restart app
depends: [drain]
- id: health_check
run: curl -fsS http://localhost:8080/healthz
retry_policy:
limit: 5
interval_sec: 10
depends: [restart]
handler_on:
failure:
run: ./scripts/notify-oncall.sh
Execution order
Ein Binary mit Zustand in Dateien, ohne JVM und ohne SQL-Datenbank
Jobs sind YAML unter Versionskontrolle, geprüft wie jede andere Änderung
SSH-Schritte und gelabelte Worker erreichen bestehende Server
SSO, RBAC und Audit-Logging zu einem öffentlichen Preis pro Server
At a glance
Rundeck vs. Dagu für Ops-Automation
Ein Binary mit Zustand in Dateien; Queues und Worker sind optional.
Java-Dienst plus MySQL oder Postgres in Produktion.
Deklaratives YAML im Git-Review.
Web-Konsole zuerst; YAML-Export und SCM-Sync als sekundärer Weg.
SSH-Schritte oder gelabelte Worker mit ausgehender Verbindung über mTLS-gRPC.
Node-Dispatch aus einem Resource-Model-Inventar über SSH oder WinRM.
Systemweite Rollen, mit SSO und Audit-Logging in der lizenzierten Version.
Feingranulare ACL-Richtlinien pro Projekt und pro Job.
Kostenlos mit unbegrenzten Servern; bezahlte Pläne lizenziert pro Dagu-Server mit unbegrenzten Workern.
Open-Source-Kern; die kommerzielle Process Automation mit Preis auf Anfrage.
Einzelne Scheduler-Instanz; HA ist ein Deployment-Design in Ihrer Verantwortung.
Die kommerzielle Version bietet Cluster-Konfigurationen.
In depth
Where each tool fits
Das Runbook behalten, den Stack loswerden
Rundeck läuft als Java-Dienst vor einer SQL-Datenbank; Jobs werden pro Projekt über die Web-Konsole definiert. Dagu hält dieselben operativen Konzepte in einem einzelnen Prozess, der seinen Zustand in Dateien speichert.
- Aus Jobs werden DAG-Dateien, aus Job-Steps werden Schritte, und Fehler-Handler entsprechen handler_on.failure.
- Job-Optionen entsprechen params: typisierte Eingaben mit Standardwerten, zur Laufzeit über UI, CLI oder API übergeben.
- Kein MySQL oder Postgres, das dimensioniert und gesichert werden muss, und kein JVM-Heap, der getunt werden muss; eine kleine VM genügt.
Jobs als Code, nicht als Klicks in der Konsole
Rundeck kann Definitionen exportieren und über sein SCM-Plugin synchronisieren, aber die Konsole ist die primäre Authoring-Oberfläche. Dagu dreht das um: Die YAML-Datei in Ihrem Repository ist die Definition.
- Jeder Job ist eine YAML-Datei in Git; Änderungen kommen als prüfbare Diffs an statt als Edits in der Konsole.
- dagu validate prüft generierte und handgeschriebene Definitionen in der CI, bevor sie den Scheduler erreichen.
- Die Web UI bleibt für den Betrieb: Läufe mit Parametern starten, Logs verfolgen, Retries auslösen und Zeitpläne aussetzen.
Bestehende Server erreichen, ohne einen Agenten zu installieren
Rundeck dispatcht Kommandos aus einem Resource-Model-Inventar an Nodes. Dagu deckt dasselbe Terrain mit zwei Mechanismen ab: SSH für agentenlose Hosts und Worker dort, wo ein dauerhaft laufender Executor besser passt.
- Den SSH-Executor nutzen, um Schritte auf bestehenden Linux- und UNIX-Hosts ohne residenten Agenten auszuführen.
- dagu worker auf Maschinen starten, die lokale Ausführung brauchen, und Schritte über worker_selector-Labels dorthin routen.
- Worker verbinden sich ausgehend über mTLS-gesichertes gRPC; segmentierte Netzwerke brauchen also keine eingehenden Ports.
Die Personen, die Jobs ausführen, von den Personen trennen, die sie ändern
Das klassische Rundeck-Deployment gibt einer breiteren Gruppe einen sicheren Ausschnitt der Operationen in die Hand. Die lizenzierte Self-Host-Version von Dagu deckt diese Trennung mit Rollen, SSO und Audit-Logging ab.
- Die Rolle operator kann Läufe starten und stoppen, aber keine Definitionen bearbeiten; viewer ist rein lesend; developer und manager können Workflows ändern.
- Per OIDC über den bestehenden Identity Provider anmelden, statt ein zweites Benutzerverzeichnis zu pflegen.
- Audit-Logging zeichnet administrative und sicherheitsrelevante Aktivitäten für die Nachprüfung auf.
Ein öffentlicher Preis statt eines Vertriebsgesprächs
Rundecks kommerzielle Version wurde zu PagerDuty Process Automation, mit Preis auf Anfrage. Die Community-Version von Dagu ist kostenlos mit unbegrenzten Servern und Workern, und die lizenzierte Version hat einen öffentlichen Preis pro Server.
- Die Community-Version umfasst die komplette Orchestrierungs-Engine, die Web UI, Cron-Zeitpläne und die Docker-, SSH- und HTTP-Executors.
- Die lizenzierte Self-Host-Version beginnt bei 500 US-Dollar pro Jahr für drei Serverlizenzen und ergänzt SSO, RBAC, Audit-Logging, Incident-Routing und E-Mail-Support.
- Worker bleiben in jedem Plan unbegrenzt; ein zusätzlicher ausführender Host ändert die Lizenzanzahl also nie.
Wo Rundeck die stärkere Wahl ist
Ein Vergleich, der nur Siege auflistet, hilft bei einer Evaluation nicht. Das sind die Stellen, an denen ein Team mit Rundeck Mehraufwand einplanen oder besser bei Rundeck bleiben sollte.
- Das Node-Inventar von Rundeck ist reicher: Resource-Model-Quellen und Node-Filter können ein Kommando auf Hunderte Hosts auffächern. Dagu richtet Schritte an SSH-Hosts oder gelabelte Worker und kennt kein Flotten-Inventar.
- Rundecks ACL-Richtlinien pro Projekt und pro Job können genau einen parametrisierten Job an eine Helpdesk-Gruppe geben. Dagus Rollen gelten systemweit, nicht pro Job.
- Die kommerzielle Process Automation bietet Cluster-Konfigurationen für Hochverfügbarkeit, und das Plugin-Ökosystem, einschließlich WinRM-Node-Executors und Benachrichtigungs-Plugins, ist größer.
FAQ
Practical questions before adopting Dagu
Ist Dagu ein direkter Ersatz für Rundeck?
Nein. Die Konzepte lassen sich sauber abbilden: Aus Jobs werden DAG-Dateien, aus Job-Steps werden Schritte, aus Optionen wird params, und aus Fehler-Handlern wird handler_on.failure. Es gibt aber keinen Importer, und Rundecks Node-Filter-Modell hat keine direkte Entsprechung. Migration heißt, jeden Job als YAML-Datei neu zu schreiben; für kommandobasierte Jobs ist das mechanische Arbeit.
Können Jobs weiterhin mit Parametern aus einer UI gestartet werden?
Ja. params deklariert typisierte Eingaben mit Standardwerten, und ein Lauf lässt sich aus der Web UI, der CLI oder der API mit Werten zur Laufzeit starten. Was Dagu nicht hat, ist Rundecks ACL pro Job, mit der sich genau ein Job für eine Gruppe freigeben lässt; Rollen gelten systemweit.
Wie führt Dagu Kommandos auf vielen Servern aus?
Auf zwei Wegen. Der SSH-Executor führt Schritte auf agentenlosen Hosts aus, und im verteilten Modus laufen Worker auf Maschinen, die Schritte passend zu ihren worker_selector-Labels abholen. Ein Resource-Model-Inventar gibt es nicht; ein Fan-out über eine große Flotte wird mit parallelen Schritten oder einem Wrapper-Skript ausgedrückt.
Braucht Dagu eine Datenbank wie Rundeck?
Nein. Laufhistorie, Logs und Queue-Zustand sind Dateien auf der Festplatte. Genau das macht auch geschlossene Netzwerke unkompliziert: ein Binary, keine JVM und keine externen Dienste, die erreichbar sein müssen.
Was ersetzt Rundecks Zeitpläne und Webhooks?
Cron-Zeitpläne mit Zeitzonen-Unterstützung sind eingebaut, und Läufe lassen sich extern über die API oder einen Webhook auslösen, wobei die Payload im Workflow verfügbar ist. Die Parallelität ist standardmäßig pro Workflow begrenzt, und geteilte Limits nutzen benannte Queues.
Next step
Start with one workflow.
Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.