Dagu vs Argo Workflows
Argo Workflows lebt auf Kubernetes. Dagu läuft auf einer normalen Maschine.
Beide definieren DAGs und führen Schritte der Reihe nach aus. Argo Workflows ist in Kubernetes eingebettet und plant jeden Schritt als Pod. Dagu ist ein einzelnes Binary, das die Kommandos aufruft, die Sie schon haben, ohne Cluster im Betrieb.
name: nightly-ops
schedule: "0 2 * * *"
steps:
- id: extract
run: python scripts/extract.py
- id: transform
run: ./bin/transform
retry_policy:
limit: 3
depends: [extract]
- id: notify
run: ./scripts/slack-success.sh
depends: [transform]Ein eigenständiges Binary, kein Kubernetes-Cluster
Deklaratives YAML, das bestehende Kommandos ausführt
Keine externe Datenbank und kein Message Broker
Executors für shell, Docker, HTTP, SSH, SQL, Sub-Workflows und KI-Agenten
Orchestrierung ohne Cluster darunter
Argo Workflows setzt ein laufendes Kubernetes-Cluster und einen Controller voraus, der jeden Schritt in einen Pod verwandelt. Dagu hat diese Anforderung nicht. Sie legen ein Binary auf einen Server, ein Notebook oder eine VM, und es läuft.
- Läuft auf einer normalen Maschine, ohne Kubernetes, ohne Controller und ohne etcd.
- Hält den Zustand in lokalen Dateien statt in einer separaten Datenbank oder einem Broker.
- Lokal starten, dann bei wachsender Last in den Queue- oder verteilten Modus wechseln.
Schritte sind Kommandos, nicht nur Container
In Argo Workflows ist jeder Schritt ein Container, der in einem Pod läuft. Dagu kann ebenfalls einen Container starten, ruft aber auch direkt ein Shell-Skript, einen HTTP-Endpoint, ein SSH-Kommando, eine SQL-Abfrage, ein Sub-Workflow oder einen KI-Agenten-Schritt auf.
- Nutzen Sie vorhandene Skripte und Binaries, ohne jedes als Image zu paketieren.
- Mischen Sie Docker-Schritte mit shell, HTTP und SSH im selben Workflow.
- Sehen Sie Läufe, Logs und Historie in einer eingebauten Web UI.
Wann Sie stattdessen Argo Workflows wählen
Argo Workflows passt besser, wenn Kubernetes bereits Ihre Plattform ist. Es ist Kubernetes-native, plant jeden Schritt als eigenen Pod und ist für schweres Container-Fan-out gebaut. Dagu tut nichts davon.
- Sie laufen auf Kubernetes und wollen Workflows als CRDs neben Ihren anderen Manifesten definieren.
- Sie brauchen Pod-Scheduling, Node Selectors und Cluster-Autoscaling pro Aufgabe.
- Ihre Pipelines fächern auf einmal in Tausende Container über viele Nodes auf.
Argo Workflows vs. Dagu im Überblick
FAQ
Practical questions before adopting Dagu
Ersetzt Dagu Argo Workflows?
Nicht für jedes Team. Wenn Sie auf Kubernetes standardisiert sind und jeden Schritt als Pod laufen lassen wollen, ist Argo Workflows das richtige Werkzeug. Dagu passt besser, wenn Sie Kommandos auf einer normalen Maschine orchestrieren wollen, ohne ein Cluster zu betreiben.
Läuft Dagu ohne Kubernetes?
Ja. Dagu ist ein eigenständiges Binary, das auf Server, VM oder Notebook läuft. Es braucht kein Kubernetes-Cluster, keine externe Datenbank und keinen Message Broker.
Kann Dagu trotzdem Container ausführen?
Ja. Dagu hat einen Docker-Executor für Schritte, die einen Container brauchen. Der Unterschied ist, dass der Container eine Option neben shell-, HTTP-, SSH-, SQL- und Sub-Workflow-Schritten ist, nicht die einzige Ausführungseinheit.
Start with one workflow.
Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.