Dagu vs Argo Workflows

O Argo Workflows vive no Kubernetes. O Dagu roda em uma máquina comum.

Os dois definem DAGs e executam etapas em ordem. O Argo Workflows é integrado ao Kubernetes e agenda cada etapa como um pod. O Dagu é um binário único que chama os comandos que você já tem, sem cluster para operar.

Um workflow que roda em um único host
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]

Um binário único e autossuficiente, sem cluster Kubernetes

YAML declarativo que executa comandos existentes

Sem banco de dados externo nem message broker

Executors para shell, Docker, HTTP, SSH, SQL, sub-workflows e agentes de IA

Orquestração sem um cluster por baixo

O Argo Workflows pressupõe um cluster Kubernetes em execução e um controller que transforma cada etapa em um pod. O Dagu não tem esse requisito. Você coloca um binário em um servidor, notebook ou VM e ele roda.

  • Roda em uma máquina comum, sem Kubernetes, sem controller e sem etcd.
  • Mantém o estado em arquivos locais, não em um banco de dados ou broker separado.
  • Comece local e depois passe para o modo em fila ou distribuído quando a carga crescer.

Etapas são comandos, não apenas containers

No Argo Workflows, cada etapa é um container que roda em um pod. O Dagu também roda um container, mas chama diretamente um script shell, um endpoint HTTP, um comando SSH, uma consulta SQL, um sub-workflow ou uma etapa de agente de IA.

  • Reaproveite scripts e binários que você já tem sem empacotar cada um como image.
  • Misture etapas Docker com shell, HTTP e SSH no mesmo workflow.
  • Veja execuções, logs e histórico em uma Web UI integrada.

Quando escolher o Argo Workflows

O Argo Workflows encaixa melhor quando o Kubernetes já é a sua plataforma. Ele é Kubernetes-native, agenda cada etapa como um pod próprio e foi feito para container fan-out pesado. O Dagu não faz nada disso.

  • Você roda no Kubernetes e quer workflows definidos como CRDs junto aos outros manifestos.
  • Você precisa de pod scheduling, node selectors e autoscaling de cluster por tarefa.
  • Seus pipelines se espalham por milhares de containers em vários nós de uma vez.

Argo Workflows vs. Dagu em resumo

Dimension
Dagu
Typical alternative
Runtime
Um binário único em máquina comum, apoiado em arquivos locais.
Um cluster Kubernetes com um workflow controller.
O que é uma etapa
Um comando: shell, Docker, HTTP, SSH, SQL, sub-workflow ou agente de IA.
Um container que roda como pod no cluster.
Melhor encaixe
Jobs de ops, scripts e pipelines mistos em hosts que você já mantém.
Pipelines Kubernetes-native, pesados em containers ou de ML em escala.

FAQ

Practical questions before adopting Dagu

O Dagu substitui o Argo Workflows?

Não para toda equipe. Se você está padronizado no Kubernetes e quer cada etapa rodando como um pod, o Argo Workflows é a ferramenta certa. O Dagu encaixa melhor quando você quer orquestrar comandos em uma máquina comum sem operar um cluster.

O Dagu funciona sem Kubernetes?

Sim. O Dagu é um binário único e autossuficiente que roda em servidor, VM ou notebook. Ele não precisa de cluster Kubernetes, banco de dados externo nem message broker.

O Dagu ainda consegue rodar containers?

Sim. O Dagu tem um executor Docker para etapas que precisam de um container. A diferença é que o container é uma opção entre etapas shell, HTTP, SSH, SQL e sub-workflow, não a única unidade de execução.

Start with one workflow.

Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.

Install Dagu