Ejecución distribuida
Un solo grafo de workflow. Workers en todas las plataformas.
El modo distribuido de Dagu es el mismo binario único en dos papeles: un coordinador que despacha trabajo y workers que lo consultan. Arranca dagu worker en Linux, macOS o Windows, describe la máquina con labels y enruta DAGs completos o pasos individuales con worker_selector. Los workers se conectan hacia fuera por gRPC protegido con TLS mutuo, así que no hay broker, ni base compartida, ni puerto de entrada en el 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 solo binario es el servidor, el coordinador y cada worker
Los workers corren en Linux, macOS y Windows, en amd64 y arm64
worker_selector enruta un DAG completo o un solo paso por labels
Los workers salen por gRPC protegido con mTLS; NAT y redes privadas funcionan sin más
At a glance
Dagu distribuido frente a una pila de workers con broker
Coordinador y workers desde un solo binario; sin broker ni backend de resultados.
Scheduler, broker, almacén de resultados y workers desplegados y actualizados por separado.
Workers nativos en Linux, macOS y Windows.
Los workers suelen ser solo Linux; Windows pasa por WSL o contenedores.
Labels declarativos de worker_selector por DAG o por paso.
Colas con nombre cableadas en la configuración de los workers y en el código de las tareas.
Los workers salen por un solo puerto protegido con mTLS.
Los workers necesitan endpoints de broker alcanzables y credenciales compartidas.
In depth
Where each tool fits
Escalar sin adoptar una plataforma
La ejecución distribuida es una decisión de despliegue, no una reescritura. El YAML que corre en una máquina corre igual en una flota, la cola sigue limitando la concurrencia antes del despacho, y un DAG que debe quedarse en la instancia principal se fija allí con worker_selector: local.
- Un worker es un solo comando: dagu worker --worker.coordinators=<host>:50055 --worker.labels gpu=true
- Las definiciones de DAG viajan a los workers por gRPC en el momento del despacho, así que los workers no guardan copia del repositorio
- default_execution_mode: distributed envía cada ejecución a la flota; sin él, solo se despachan los DAGs con worker_selector
Los labels enrutan el trabajo, las máquinas siguen siendo intercambiables
Un worker anuncia lo que es con labels clave-valor. Un DAG declara lo que necesita con worker_selector. El coordinador empareja ambos, así que añadir capacidad es arrancar otro worker con los mismos labels, no editar workflows.
- Un selector vacío coincide con cualquier worker; un selector con labels exige coincidencia exacta de cada clave
- Los workers con labels extra siguen coincidiendo, así que una máquina puede servir varios pools a la vez
- worker_selector en un paso dag.run envía ese sub-DAG a un worker distinto del de su padre
Una flota que mezcla sistemas operativos y arquitecturas
Los workers son el mismo binario Go, publicado para Linux, macOS y Windows en amd64 y arm64. En el mismo grafo, un worker de Windows ejecuta pasos de PowerShell junto a un worker de Linux ejecutando bash, con un único lugar para ver estado, logs e historial.
- Etiqueta por convención, por ejemplo os=windows o arch=arm64, y enruta con los mismos selectores
- El modo shared-nothing transmite logs y estado al coordinador por gRPC, así que no hace falta NFS ni volumen compartido
- Los workers solo hacen conexiones salientes, así que máquinas detrás de NAT, en VPN o en otra nube pueden unirse a la flota
Listo para la nube y Kubernetes
El Helm chart oficial despliega la UI, el scheduler, el coordinador y pools de workers opcionales en Kubernetes. Los workers también pueden unirse desde mucho más allá del clúster: VMs, bare metal o un equipo Windows de oficina, con TLS mutuo autenticando ambos extremos cuando el tráfico cruza una frontera.
- helm repo add dagu https://dagucloud.github.io/dagu, y después helm install con tus values
- El coordinador solo necesita un host:port alcanzable; basta un Service de Kubernetes o un balanceador interno
- El coordinador verifica los certificados de los workers y los workers verifican al coordinador mediante mTLS
FAQ
Practical questions before adopting Dagu
¿Necesito un broker de mensajes o una base de datos externa?
No. El coordinador despacha tareas por gRPC y los workers lo consultan, devolviendo heartbeats, estado y logs por la misma conexión. En modo shared-nothing no hay almacenamiento compartido en absoluto; en modo shared-filesystem, los workers escriben en el mismo volumen que lee el servidor.
¿Pueden los workers estar detrás de NAT o en una red privada?
Sí. El único camino necesario va del worker al coordinador por un puerto TCP, y el coordinador nunca abre una conexión de vuelta hacia el worker. Las máquinas detrás de NAT, en VPN o en otra nube se unen simplemente marcando la dirección del coordinador.
¿Cómo encajan los workers de Windows?
Instala el mismo binario, ejecuta dagu worker con labels como os=windows y dale a los DAGs de Windows un worker_selector que coincida. Los pasos en esa máquina corren bajo el shell que configures, por ejemplo shell: powershell -NoProfile, mientras el resto del grafo corre en otros sitios.
¿Puedo ejecutar todo Dagu en Kubernetes?
Sí. El Helm chart oficial genera Deployments para la UI, el scheduler, el coordinador y los pools de workers que definas, con un Service ClusterIP delante del coordinador. Los workers fuera del clúster apuntan a ese Service a través del ingress o balanceador con el que lo expongas.
¿Qué pasa si un worker se desconecta en mitad de una ejecución?
Los workers envían heartbeats cada segundo. Cuando el heartbeat de un worker lleva más de 30 segundos sin actualizarse, el coordinador marca sus tareas en ejecución como fallidas, de modo que los handlers de fallo y las notificaciones se disparan en lugar de dejar la ejecución colgada para siempre.
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.