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.
# nightly-scan.yaml
schedule: "0 3 * * *"
steps:
- id: build
run: ./scripts/build-image.sh app:nightly
# Only this step needs a container
- id: scan
container:
image: aquasec/trivy:latest
run: trivy image app:nightly
depends: [build]
- id: publish_report
run: ./scripts/upload-report.sh
depends: [scan]
Execution order
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
At a glance
Argo Workflows vs. Dagu em resumo
Um binário único em máquina comum, apoiado em arquivos locais.
Um cluster Kubernetes com um workflow controller.
Um comando: shell, Docker, HTTP, SSH, SQL, sub-workflow ou agente de IA.
Um container que roda como pod no cluster.
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.
In depth
Where each tool fits
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.
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.
Next step
Start with one workflow.
Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.