Alternativa ao Rundeck
Automação de runbooks sem JVM, sem banco de dados SQL e sem criar jobs pela GUI.
O Dagu é uma alternativa ao Rundeck para equipes de operações que querem jobs agendados, runbooks sob demanda e uma Web UI a partir de um único binário pequeno. As definições de jobs vivem no Git como YAML em vez de atrás de um console, o estado vive em arquivos em vez de MySQL ou Postgres, e os servidores existentes são alcançados via SSH ou com workers rotulados. Esta página também cobre o caminho de migração e os pontos em que o Rundeck continua sendo a escolha mais forte.
# restart-app.yaml
params:
- name: host
default: app01.internal
ssh:
user: ops
host: ${params.host}
key: ~/.ssh/ops_key
steps:
- id: drain
run: /opt/app/bin/drain --wait
- id: restart
run: sudo systemctl restart app
depends: [drain]
- id: health_check
run: curl -fsS http://localhost:8080/healthz
retry_policy:
limit: 5
interval_sec: 10
depends: [restart]
handler_on:
failure:
run: ./scripts/notify-oncall.sh
Execution order
Um binário único com estado em arquivos, sem JVM e sem banco de dados SQL
Jobs são YAML sob controle de versão, revisados como qualquer outra mudança
Etapas SSH e workers rotulados alcançam os servidores existentes
SSO, RBAC e logs de auditoria com preço público por servidor
At a glance
Rundeck vs. Dagu para automação de operações
Um binário único com estado em arquivos; filas e workers são opcionais.
Serviço Java mais MySQL ou Postgres em produção.
YAML declarativo revisado no Git.
Console web primeiro; exportação de YAML e sincronização via SCM como caminho secundário.
Etapas SSH, ou workers rotulados conectando para fora via gRPC com mTLS.
Despacho para nós a partir de um inventário de modelo de recursos via SSH ou WinRM.
Papéis para o sistema todo, com SSO e logs de auditoria no plano licenciado.
Políticas de ACL granulares por projeto e por job.
Gratuito com servidores ilimitados; planos pagos licenciados por servidor Dagu, com workers ilimitados.
Núcleo open source; o Process Automation comercial tem preço sob consulta.
Instância única do scheduler; alta disponibilidade é um design de implantação por sua conta.
O nível comercial oferece configurações em cluster.
In depth
Where each tool fits
Mantenha o runbook, dispense a stack
O Rundeck roda como um serviço Java na frente de um banco de dados SQL, com jobs definidos por projeto no console web. O Dagu mantém os mesmos conceitos operacionais dentro de um único processo que guarda o estado em arquivos.
- Jobs viram arquivos de DAG, job steps viram etapas e os error handlers correspondem a handler_on.failure.
- As job options correspondem a params: entradas tipadas com valores padrão, fornecidas pela UI, pela CLI ou pela API em tempo de execução.
- Sem MySQL ou Postgres para dimensionar e fazer backup, e sem heap de JVM para ajustar; uma VM pequena dá conta.
Jobs como código, não cliques no console
O Rundeck consegue exportar definições e sincronizá-las pelo plugin de SCM, mas o console é a principal superfície de autoria. O Dagu inverte isso: o arquivo YAML no seu repositório é a definição.
- Cada job é um arquivo YAML no Git, então as mudanças chegam como diffs revisáveis em vez de edições no console.
- dagu validate verifica definições geradas e escritas à mão no CI antes de chegarem ao scheduler.
- A Web UI fica para a operação: iniciar execuções com parâmetros, acompanhar logs, fazer retry e suspender agendamentos.
Alcance servidores existentes sem instalar um agente
O Rundeck despacha comandos para os nós a partir de um inventário de modelo de recursos. O Dagu cobre o mesmo terreno com dois mecanismos: SSH para hosts sem agente e workers onde um executor persistente encaixa melhor.
- Use o executor SSH para rodar etapas em hosts Linux e UNIX existentes sem agente residente.
- Inicie dagu worker nas máquinas que precisam de execução local e roteie etapas para elas com labels de worker_selector.
- Os workers conectam para fora via gRPC protegido com mTLS, então redes segmentadas não precisam de portas de entrada.
Separe quem executa os jobs de quem os altera
A implantação clássica do Rundeck entrega um subconjunto seguro de operações a um grupo mais amplo. O plano self-host licenciado do Dagu cobre essa separação com papéis, SSO e logs de auditoria.
- O papel operator pode iniciar e parar execuções, mas não pode editar definições; viewer é somente leitura; developer e manager podem alterar workflows.
- Faça login pelo seu provedor de identidade existente com OIDC em vez de manter um segundo diretório de usuários.
- Os logs de auditoria registram atividades administrativas e relevantes para a segurança, prontas para revisão.
Um preço público em vez de uma conversa com vendas
O nível comercial do Rundeck virou o PagerDuty Process Automation, com preço sob consulta. O plano Community do Dagu é gratuito com servidores e workers ilimitados, e o plano licenciado tem preço público por servidor.
- O Community cobre o motor de orquestração completo, a Web UI, o agendamento cron e os executores Docker, SSH e HTTP.
- O self-host licenciado começa em US$ 500 por ano por três licenças de servidor e adiciona SSO, RBAC, logs de auditoria, roteamento de incidentes e suporte por email.
- Os workers continuam ilimitados em todos os planos, então adicionar um host de execução nunca muda a contagem de licenças.
Onde o Rundeck é a escolha mais forte
Uma comparação que só lista vitórias não é útil durante uma avaliação. Estes são os pontos em que uma equipe que usa o Rundeck deve esperar trabalho extra ou ficar onde está.
- O inventário de nós do Rundeck é mais rico: fontes de modelo de recursos e filtros de nós conseguem espalhar um comando por centenas de hosts. O Dagu direciona etapas a hosts SSH ou workers rotulados e não tem o conceito de inventário de frota.
- As políticas de ACL por projeto e por job do Rundeck conseguem entregar exatamente um job parametrizado a um grupo de help desk. Os papéis do Dagu valem para o sistema todo, não por job.
- O Process Automation comercial oferece configurações em cluster para alta disponibilidade, e o ecossistema de plugins, incluindo executores de nó WinRM e plugins de notificação, é maior.
FAQ
Practical questions before adopting Dagu
O Dagu é um substituto direto do Rundeck?
Não. Os conceitos correspondem de forma direta: jobs viram arquivos de DAG, job steps viram etapas, options viram params e os error handlers viram handler_on.failure. Mas não há importador, e o modelo de filtros de nós do Rundeck não tem equivalente direto. Migrar significa reescrever cada job como um arquivo YAML, o que é mecânico para jobs baseados em comandos.
Ainda dá para disparar jobs com parâmetros a partir de uma UI?
Sim. params declara entradas tipadas com valores padrão, e uma execução pode ser iniciada pela Web UI, pela CLI ou pela API com valores fornecidos em tempo de execução. O que o Dagu não tem é a ACL por job do Rundeck para expor exatamente um job a um grupo; os papéis valem para o sistema todo.
Como o Dagu executa comandos em muitos servidores?
De duas formas. O executor SSH roda etapas em hosts sem agente, e o modo distribuído inicia workers em máquinas que buscam as etapas correspondentes aos labels de worker_selector. Não há inventário de modelo de recursos; uma distribuição por uma frota grande é expressa com etapas paralelas ou um script wrapper.
O Dagu precisa de um banco de dados como o Rundeck?
Não. Histórico de execução, logs e estado da fila são arquivos em disco. É isso que também torna redes fechadas simples: um binário, sem JVM e sem serviços externos para alcançar.
O que substitui os agendamentos e webhooks do Rundeck?
Agendamentos cron com suporte a fuso horário já vêm incluídos, e execuções podem ser disparadas externamente pela API ou por um webhook, com o payload disponível para o workflow. A concorrência é limitada por workflow por padrão, e limites compartilhados usam filas nomeadas.
Next step
Start with one workflow.
Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.