Exécution distribuée
Un seul graphe de workflow. Des workers sur toutes les plateformes.
Le mode distribué de Dagu, c'est le même binaire unique dans deux rôles : un coordinateur qui distribue le travail et des workers qui viennent le chercher. Lancez dagu worker sous Linux, macOS ou Windows, décrivez la machine avec des labels, puis routez des DAG entiers ou des étapes individuelles avec worker_selector. Les workers se connectent vers l'extérieur en gRPC sécurisé par TLS mutuel : pas de broker, pas de base partagée, pas de port entrant côté 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]Un seul binaire fait office de serveur, de coordinateur et de chaque worker
Les workers tournent sous Linux, macOS et Windows, en amd64 et arm64
worker_selector route un DAG entier ou une seule étape par labels
Les workers sortent en gRPC sécurisé par mTLS : NAT et réseaux privés ne posent aucun problème
At a glance
Dagu distribué face à une pile de workers à broker
Coordinateur et workers issus d'un seul binaire ; ni broker ni backend de résultats.
Scheduler, broker, stockage de résultats et workers déployés et mis à jour séparément.
Workers natifs sous Linux, macOS et Windows.
Workers le plus souvent Linux uniquement ; Windows passe par WSL ou des conteneurs.
Labels worker_selector déclaratifs par DAG ou par étape.
Files nommées câblées à la fois dans la config des workers et dans le code des tâches.
Les workers sortent sur un seul port sécurisé par mTLS.
Les workers exigent des endpoints de broker joignables et des identifiants partagés.
In depth
Where each tool fits
Passer à l'échelle sans adopter une plateforme
L'exécution distribuée est un choix de déploiement, pas une réécriture. Le YAML qui tourne sur une machine tourne tel quel sur une flotte, la file d'attente continue de limiter la concurrence avant la répartition, et un DAG qui doit rester sur l'instance principale s'y épingle avec worker_selector: local.
- Un worker tient en une commande : dagu worker --worker.coordinators=<host>:50055 --worker.labels gpu=true
- Les définitions de DAG sont transmises aux workers en gRPC au moment de la répartition : les workers ne gardent aucune copie du dépôt
- default_execution_mode: distributed envoie chaque exécution vers la flotte ; sans lui, seuls les DAG avec worker_selector sont répartis
Les labels routent le travail, les machines restent interchangeables
Un worker annonce ce qu'il est avec des labels clé-valeur. Un DAG déclare ce dont il a besoin avec worker_selector. Le coordinateur fait correspondre les deux : ajouter de la capacité, c'est démarrer un worker de plus avec les mêmes labels, pas modifier les workflows.
- Un sélecteur vide correspond à n'importe quel worker ; un sélecteur avec labels exige une correspondance exacte de chaque clé
- Les workers avec des labels en plus correspondent quand même : une même machine peut servir plusieurs pools
- worker_selector sur une étape dag.run envoie ce sous-DAG vers un autre worker que son parent
Une flotte qui mélange systèmes et architectures
Les workers sont le même binaire Go, publié pour Linux, macOS et Windows en amd64 et arm64. Dans un même graphe, un worker Windows exécute des étapes PowerShell à côté d'un worker Linux qui exécute bash, avec un seul endroit pour le statut, les logs et l'historique.
- Étiquetez par convention, par exemple os=windows ou arch=arm64, et routez avec les mêmes sélecteurs
- Le mode shared-nothing diffuse logs et statut vers le coordinateur en gRPC : ni NFS ni volume partagé
- Les workers ne font que des connexions sortantes : les machines derrière un NAT, sur un VPN ou dans un autre cloud rejoignent la flotte
Prêt pour le cloud et Kubernetes
Le chart Helm officiel déploie l'UI, le scheduler, le coordinateur et des pools de workers optionnels sur Kubernetes. Les workers peuvent aussi venir de bien au-delà du cluster : VM, bare metal ou poste Windows de bureau, le TLS mutuel authentifiant les deux extrémités quand le trafic franchit une frontière.
- helm repo add dagu https://dagucloud.github.io/dagu, puis helm install avec vos values
- Le coordinateur n'a besoin que d'un host:port joignable ; un Service Kubernetes ou un load balancer interne suffit
- Le coordinateur vérifie les certificats des workers et les workers vérifient le coordinateur via mTLS
FAQ
Practical questions before adopting Dagu
Faut-il un broker de messages ou une base de données externe ?
Non. Le coordinateur distribue les tâches en gRPC et les workers l'interrogent, renvoyant heartbeats, statut et logs sur la même connexion. En mode shared-nothing, il n'y a aucun stockage partagé ; en mode shared-filesystem, les workers écrivent sur le volume que lit le serveur.
Les workers peuvent-ils être derrière un NAT ou dans un réseau privé ?
Oui. Le seul chemin requis va du worker vers le coordinateur sur un port TCP, et le coordinateur n'ouvre jamais de connexion vers le worker. Les machines derrière un NAT, sur un VPN ou dans un autre cloud rejoignent la flotte en composant simplement l'adresse du coordinateur.
Comment intégrer des workers Windows ?
Installez le même binaire, lancez dagu worker avec des labels comme os=windows, et donnez aux DAG Windows un worker_selector correspondant. Les étapes sur cette machine s'exécutent dans le shell que vous configurez, par exemple shell: powershell -NoProfile, pendant que le reste du graphe tourne ailleurs.
Peut-on faire tourner tout Dagu sur Kubernetes ?
Oui. Le chart Helm officiel génère les Deployments de l'UI, du scheduler, du coordinateur et des pools de workers que vous définissez, avec un Service ClusterIP devant le coordinateur. Les workers hors cluster pointent vers ce Service via l'ingress ou le load balancer avec lequel vous l'exposez.
Que se passe-t-il si un worker se déconnecte en pleine exécution ?
Les workers envoient un heartbeat chaque seconde. Quand le heartbeat d'un worker reste muet plus de 30 secondes, le coordinateur marque ses tâches en cours comme échouées : les handlers d'échec et les notifications se déclenchent au lieu de laisser l'exécution pendre indéfiniment.
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.