Verteilte Ausführung
Ein Workflow-Graph. Worker auf jeder Plattform.
Der verteilte Modus von Dagu ist dasselbe einzelne Binary in zwei Rollen: ein Koordinator, der Arbeit verteilt, und Worker, die sie abholen. Starten Sie dagu worker unter Linux, macOS oder Windows, beschreiben Sie die Maschine mit Labels und routen Sie ganze DAGs oder einzelne Schritte über worker_selector. Worker verbinden sich ausgehend per gRPC, gesichert mit beidseitigem TLS. Es gibt keinen Broker, keine geteilte Datenbank und keinen eingehenden Port auf dem Worker.
# nightly-close.yaml
schedule: "0 2 * * *"
max_active_runs: 1
steps:
# Windows box exports from the line-of-business system
- id: export_sales
action: dag.run
with: { dag: export-sales }
worker_selector:
os: windows
# Linux worker near the data transforms it
- id: transform
action: dag.run
with: { dag: transform-sales }
worker_selector:
os: linux
region: us-east-1
depends: [export_sales]
# GPU worker scores the result
- id: score
action: dag.run
with: { dag: score-models }
worker_selector:
gpu: "true"
depends: [transform]Ein Binary ist Server, Koordinator und jeder Worker
Worker laufen unter Linux, macOS und Windows, auf amd64 und arm64
worker_selector routet einen ganzen DAG oder einen einzelnen Schritt über Labels
Worker verbinden sich ausgehend per mTLS-gesichertem gRPC; NAT und private Netze sind kein Problem
At a glance
Verteiltes Dagu vs. ein Worker-Stack mit Broker
Koordinator und Worker aus einem Binary; kein Broker, kein Result-Backend.
Scheduler, Broker, Result-Store und Worker werden getrennt deployt und aktualisiert.
Native Worker unter Linux, macOS und Windows.
Worker sind meist Linux-only; Windows läuft über WSL oder Container.
Deklarative worker_selector-Labels pro DAG oder Schritt.
Benannte Queues, verdrahtet in Worker-Konfiguration und Task-Code zugleich.
Worker verbinden sich ausgehend auf einen mTLS-gesicherten Port.
Worker brauchen erreichbare Broker-Endpunkte und geteilte Zugangsdaten.
In depth
Where each tool fits
Skalieren, ohne eine Plattform einzuführen
Verteilte Ausführung ist eine Deployment-Entscheidung, kein Umbau. Das YAML, das auf einer Maschine läuft, läuft unverändert auf einer Flotte, die Queue begrenzt die Parallelität weiterhin vor dem Dispatch, und ein DAG, der auf der Hauptinstanz bleiben muss, heftet sich dort mit worker_selector: local fest.
- Ein Worker ist ein einziger Befehl: dagu worker --worker.coordinators=<host>:50055 --worker.labels gpu=true
- DAG-Definitionen wandern beim Dispatch per gRPC zu den Workern, Worker halten also keine Kopie des Repositories
- default_execution_mode: distributed schickt jeden Lauf an die Flotte; ohne diese Einstellung werden nur DAGs mit worker_selector verteilt
Labels routen die Arbeit, Maschinen bleiben austauschbar
Ein Worker beschreibt mit Key-Value-Labels, was er ist. Ein DAG erklärt mit worker_selector, was er braucht. Der Koordinator bringt beides zusammen. Kapazität hinzufügen heißt also, einen weiteren Worker mit denselben Labels zu starten, nicht Workflows zu bearbeiten.
- Ein leerer Selektor passt auf jeden Worker; ein Selektor mit Labels verlangt für jeden Key eine exakte Übereinstimmung
- Worker mit zusätzlichen Labels passen trotzdem, eine Maschine kann also mehrere Pools zugleich bedienen
- worker_selector an einem dag.run-Schritt schickt diesen Sub-DAG an einen anderen Worker als den des Elternteils
Eine Flotte aus gemischten Betriebssystemen und Architekturen
Worker sind dasselbe Go-Binary, veröffentlicht für Linux, macOS und Windows auf amd64 und arm64. Im selben Graphen führt ein Windows-Worker PowerShell-Schritte neben einem Linux-Worker mit bash aus, mit einem einzigen Ort für Status, Logs und Historie.
- Labeln Sie nach Konvention, etwa os=windows oder arch=arm64, und routen Sie mit denselben Selektoren
- Der Shared-Nothing-Modus streamt Logs und Status per gRPC zum Koordinator, NFS oder geteilte Volumes sind unnötig
- Worker bauen nur ausgehende Verbindungen auf, daher können Maschinen hinter NAT, im VPN oder in einer anderen Cloud der Flotte beitreten
Bereit für Cloud und Kubernetes
Das offizielle Helm-Chart deployt UI, Scheduler, Koordinator und optionale Worker-Pools auf Kubernetes. Worker können auch von weit außerhalb des Clusters beitreten: VMs, Bare Metal oder ein Windows-Rechner im Büro, wobei beidseitiges TLS beide Enden authentifiziert, sobald Verkehr eine Grenze überquert.
- helm repo add dagu https://dagucloud.github.io/dagu, dann helm install mit Ihren Values
- Der Koordinator braucht nur ein erreichbares host:port; ein Kubernetes Service oder ein interner Load Balancer genügt
- Der Koordinator prüft die Worker-Zertifikate und die Worker prüfen den Koordinator über mTLS
FAQ
Practical questions before adopting Dagu
Brauche ich einen Message-Broker oder eine externe Datenbank?
Nein. Der Koordinator verteilt Aufgaben per gRPC, Worker pollen ihn und senden Heartbeats, Status und Logs über dieselbe Verbindung zurück. Im Shared-Nothing-Modus gibt es überhaupt keinen geteilten Speicher; im Shared-Filesystem-Modus schreiben Worker auf dasselbe Volume, das der Server liest.
Können Worker hinter NAT oder in einem privaten Netz stehen?
Ja. Der einzige nötige Pfad führt vom Worker zum Koordinator über einen TCP-Port, und der Koordinator öffnet niemals eine Verbindung zurück zum Worker. Maschinen hinter NAT, im VPN oder in einer anderen Cloud treten bei, indem sie einfach die Adresse des Koordinators wählen.
Wie fügen sich Windows-Worker ein?
Installieren Sie dasselbe Binary, starten Sie dagu worker mit Labels wie os=windows und geben Sie Windows-DAGs einen passenden worker_selector. Schritte auf dieser Maschine laufen in der von Ihnen konfigurierten Shell, etwa shell: powershell -NoProfile, während der Rest des Graphen anderswo läuft.
Kann ich ganz Dagu auf Kubernetes betreiben?
Ja. Das offizielle Helm-Chart rendert Deployments für UI, Scheduler, Koordinator und die von Ihnen definierten Worker-Pools, mit einem ClusterIP-Service vor dem Koordinator. Worker außerhalb des Clusters erreichen diesen Service über den Ingress oder Load Balancer, mit dem Sie ihn freigeben.
Was passiert, wenn ein Worker mitten im Lauf ausfällt?
Worker senden jede Sekunde einen Heartbeat. Bleibt der Heartbeat eines Workers länger als 30 Sekunden aus, markiert der Koordinator dessen laufende Aufgaben als fehlgeschlagen. Fehler-Handler und Benachrichtigungen feuern also, statt dass ein Lauf für immer hängt.
Keep reading
Next step
Start with one workflow.
Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.