Execução distribuída
Um grafo de workflow. Workers em todas as plataformas.
O modo distribuído do Dagu é o mesmo binário único em dois papéis: um coordenador que despacha o trabalho e workers que o buscam. Inicie dagu worker em Linux, macOS ou Windows, descreva a máquina com labels e roteie DAGs inteiros ou etapas individuais com worker_selector. Os workers conectam para fora via gRPC protegido com TLS mútuo, então não há broker, nem banco compartilhado, nem porta de entrada no 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]Um único binário é o servidor, o coordenador e cada worker
Workers rodam em Linux, macOS e Windows, em amd64 e arm64
worker_selector roteia um DAG inteiro ou uma única etapa por labels
Workers conectam para fora via gRPC protegido com mTLS; NAT e redes privadas funcionam sem ajustes
At a glance
Dagu distribuído vs uma pilha de workers com broker
Coordenador e workers de um único binário; sem broker nem backend de resultados.
Scheduler, broker, armazenamento de resultados e workers implantados e atualizados separadamente.
Workers nativos em Linux, macOS e Windows.
Workers geralmente só em Linux; Windows via WSL ou contêineres.
Labels declarativos de worker_selector por DAG ou etapa.
Filas nomeadas cabeadas na configuração dos workers e no código das tarefas.
Workers saem por uma única porta protegida com mTLS.
Workers precisam de endpoints de broker alcançáveis e credenciais compartilhadas.
In depth
Where each tool fits
Escalar sem adotar uma plataforma
Execução distribuída é uma escolha de implantação, não uma reescrita. O YAML que roda em uma máquina roda igual em uma frota, a fila continua limitando a concorrência antes do despacho, e um DAG que precisa ficar na instância principal se fixa lá com worker_selector: local.
- Um worker é um comando só: dagu worker --worker.coordinators=<host>:50055 --worker.labels gpu=true
- As definições de DAG viajam até os workers via gRPC no momento do despacho, então os workers não guardam cópia do repositório
- default_execution_mode: distributed envia toda execução para a frota; sem ele, só DAGs com worker_selector são despachados
Labels roteiam o trabalho, máquinas continuam intercambiáveis
Um worker anuncia o que ele é com labels chave-valor. Um DAG declara o que precisa com worker_selector. O coordenador combina os dois, então adicionar capacidade é iniciar outro worker com os mesmos labels, não editar workflows.
- Um seletor vazio combina com qualquer worker; um seletor com labels exige correspondência exata de cada chave
- Workers com labels extras ainda combinam, então uma máquina pode servir vários pools ao mesmo tempo
- worker_selector em uma etapa dag.run envia esse sub-DAG para um worker diferente do pai
Uma frota que mistura sistemas operacionais e arquiteturas
Os workers são o mesmo binário Go, lançado para Linux, macOS e Windows em amd64 e arm64. Um worker Windows executa etapas PowerShell ao lado de um worker Linux executando bash no mesmo grafo, com um único lugar para ver status, logs e histórico.
- Rotule por convenção, por exemplo os=windows ou arch=arm64, e roteie com os mesmos seletores
- O modo shared-nothing transmite logs e status ao coordenador via gRPC, então não precisa de NFS nem volume compartilhado
- Workers só fazem conexões de saída, então máquinas atrás de NAT, em VPN ou em outra nuvem entram na frota
Pronto para nuvem e Kubernetes
O Helm chart oficial implanta a UI, o scheduler, o coordenador e pools de workers opcionais no Kubernetes. Workers também podem entrar de bem longe do cluster: VMs, bare metal ou um host Windows do escritório, com TLS mútuo autenticando as duas pontas quando o tráfego cruza uma fronteira.
- helm repo add dagu https://dagucloud.github.io/dagu, depois helm install com seus values
- O coordenador precisa de um único host:port alcançável; um Service do Kubernetes ou um load balancer interno basta
- O coordenador verifica os certificados dos workers e os workers verificam o coordenador via mTLS
FAQ
Practical questions before adopting Dagu
Preciso de um broker de mensagens ou banco de dados externo?
Não. O coordenador despacha tarefas via gRPC e os workers fazem polling, devolvendo heartbeats, status e logs pela mesma conexão. No modo shared-nothing não há armazenamento compartilhado algum; no modo shared-filesystem, os workers escrevem no mesmo volume que o servidor lê.
Workers podem ficar atrás de NAT ou em rede privada?
Sim. O único caminho necessário é do worker para o coordenador em uma porta TCP, e o coordenador nunca abre conexão de volta para o worker. Máquinas atrás de NAT, em VPNs ou em outra nuvem entram discando o endereço do coordenador.
Como workers Windows se encaixam?
Instale o mesmo binário, rode dagu worker com labels como os=windows e dê aos DAGs de Windows um worker_selector correspondente. As etapas nessa máquina rodam no shell que você configurar, por exemplo shell: powershell -NoProfile, enquanto o resto do grafo roda em outros lugares.
Posso rodar o Dagu inteiro no Kubernetes?
Sim. O Helm chart oficial renderiza Deployments para a UI, o scheduler, o coordenador e os pools de workers que você definir, com um Service ClusterIP na frente do coordenador. Workers fora do cluster apontam para esse Service pelo ingress ou load balancer que você expuser.
O que acontece se um worker cair no meio de uma execução?
Workers enviam heartbeats a cada segundo. Quando o heartbeat de um worker fica sem atualização por mais de 30 segundos, o coordenador marca as tarefas em execução daquele worker como falhas, então os handlers de falha e as notificações disparam em vez de a execução ficar pendurada para sempre.
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.