Alternative à Rundeck
L'automatisation des runbooks sans JVM, sans base de données SQL, sans jobs créés dans une console graphique.
Dagu est une alternative à Rundeck pour les équipes d'exploitation qui veulent des jobs planifiés, des runbooks à la demande et une Web UI dans un seul petit binaire. Les définitions de jobs vivent dans Git sous forme de YAML plutôt que derrière une console, l'état vit dans des fichiers plutôt que dans MySQL ou Postgres, et les serveurs existants sont atteints via SSH ou avec des workers étiquetés. Cette page couvre aussi le chemin de migration et les endroits où Rundeck reste le meilleur choix.
# 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
Un seul binaire avec l'état dans des fichiers, sans JVM ni base de données SQL
Des jobs en YAML sous gestion de version, relus comme tout autre changement
Des étapes SSH et des workers étiquetés atteignent les serveurs existants
SSO, RBAC et journal d'audit à un prix public par serveur
At a glance
Rundeck vs. Dagu pour l'automatisation ops
Un seul binaire avec l'état dans des fichiers ; files d'attente et workers optionnels.
Un service Java plus MySQL ou Postgres en production.
YAML déclaratif relu dans Git.
Console web d'abord ; export YAML et synchronisation SCM en voie secondaire.
Étapes SSH, ou workers étiquetés qui se connectent vers l'extérieur en gRPC mTLS.
Répartition vers les nœuds depuis un inventaire resource model via SSH ou WinRM.
Rôles à l'échelle du système, avec SSO et journal d'audit dans l'offre sous licence.
Politiques ACL fines par projet et par job.
Gratuit avec serveurs illimités ; les offres payantes comptent les licences par serveur Dagu, avec workers illimités.
Cœur open source ; Process Automation commercial tarifé sur devis.
Une seule instance de scheduler ; la haute disponibilité est un choix de déploiement à votre charge.
L'offre commerciale propose des configurations en cluster.
In depth
Where each tool fits
Gardez le runbook, abandonnez la stack
Rundeck tourne comme un service Java devant une base de données SQL, avec des jobs définis par projet dans la console web. Dagu garde les mêmes concepts opérationnels dans un seul processus qui stocke son état dans des fichiers.
- Les jobs deviennent des fichiers DAG, les étapes de job deviennent des étapes, et les gestionnaires d'erreur correspondent à handler_on.failure.
- Les options de job correspondent à params : des entrées typées avec valeurs par défaut, fournies depuis l'UI, la CLI ou l'API au moment de l'exécution.
- Pas de MySQL ni de Postgres à dimensionner et sauvegarder, pas de heap JVM à régler ; une petite VM suffit.
Des jobs comme du code, pas des clics dans une console
Rundeck peut exporter les définitions et les synchroniser via son plugin SCM, mais la console reste la principale surface d'écriture. Dagu inverse cela : le fichier YAML dans votre dépôt est la définition.
- Chaque job est un fichier YAML dans Git : les changements arrivent comme des diffs relisibles plutôt que des modifications en console.
- dagu validate vérifie en CI les définitions générées ou écrites à la main avant qu'elles n'atteignent le scheduler.
- La Web UI reste pour opérer : lancer des exécutions avec des paramètres, suivre les logs, relancer et suspendre des plannings.
Atteindre les serveurs existants sans installer d'agent
Rundeck répartit des commandes vers les nœuds depuis un inventaire resource model. Dagu couvre le même terrain avec deux mécanismes : SSH pour les hôtes sans agent, et des workers là où un processus d'exécution résident convient mieux.
- Utilisez l'exécuteur SSH pour lancer des étapes sur les hôtes Linux et UNIX existants, sans agent résident.
- Démarrez dagu worker sur les machines qui exigent une exécution locale, et routez les étapes vers elles avec des labels worker_selector.
- Les workers se connectent vers l'extérieur en gRPC sécurisé par mTLS : les réseaux segmentés n'ont besoin d'aucun port entrant.
Séparer ceux qui exécutent les jobs de ceux qui les modifient
Le déploiement Rundeck classique confie un sous-ensemble sûr d'opérations à un groupe plus large. L'offre auto-hébergée sous licence de Dagu couvre cette séparation avec des rôles, le SSO et le journal d'audit.
- Le rôle operator peut lancer et arrêter des exécutions mais pas modifier les définitions ; viewer est en lecture seule ; developer et manager peuvent changer les workflows.
- Connectez-vous via votre fournisseur d'identité existant avec OIDC plutôt que de maintenir un second annuaire d'utilisateurs.
- Le journal d'audit enregistre l'activité administrative et de sécurité à des fins de revue.
Un prix public plutôt qu'un appel commercial
L'offre commerciale de Rundeck est devenue PagerDuty Process Automation, tarifée sur devis. L'offre communautaire de Dagu est gratuite avec serveurs et workers illimités, et l'offre sous licence a un prix public par serveur.
- L'offre communautaire couvre le moteur d'orchestration complet, la Web UI, la planification cron et les exécuteurs Docker, SSH et HTTP.
- L'auto-hébergement sous licence démarre à 500 $ par an pour trois licences serveur et ajoute SSO, RBAC, journal d'audit, routage des incidents et support par e-mail.
- Les workers restent illimités quelle que soit l'offre : ajouter un hôte d'exécution ne change jamais le nombre de licences.
Là où Rundeck reste le meilleur choix
Un comparatif qui ne liste que des victoires n'aide pas une évaluation. Voici les endroits où une équipe Rundeck doit s'attendre à un surcroît de travail, voire ne pas migrer.
- L'inventaire de nœuds de Rundeck est plus riche : les sources resource model et les filtres de nœuds peuvent diffuser une même commande vers des centaines d'hôtes. Dagu cible les étapes vers des hôtes SSH ou des workers étiquetés, sans notion d'inventaire de flotte.
- Les politiques ACL par projet et par job de Rundeck peuvent confier exactement un job paramétré à un groupe helpdesk. Les rôles de Dagu s'appliquent à tout le système, pas job par job.
- Le Process Automation commercial propose des configurations en cluster pour la haute disponibilité, et l'écosystème de plugins, dont les exécuteurs de nœuds WinRM et les plugins de notification, est plus vaste.
FAQ
Practical questions before adopting Dagu
Dagu est-il un remplacement direct de Rundeck ?
Non. Les concepts se correspondent proprement : les jobs deviennent des fichiers DAG, les étapes de job des étapes, les options des params, et les gestionnaires d'erreur handler_on.failure. Mais il n'y a pas d'importateur, et le modèle de filtres de nœuds de Rundeck n'a pas d'équivalent direct. Migrer signifie réécrire chaque job en fichier YAML, ce qui reste mécanique pour les jobs à base de commandes.
Peut-on toujours déclencher des jobs avec des paramètres depuis une UI ?
Oui. params déclare des entrées typées avec valeurs par défaut, et une exécution peut être lancée depuis la Web UI, la CLI ou l'API avec des valeurs fournies au moment de l'exécution. Ce que Dagu n'a pas, c'est l'ACL par job de Rundeck qui expose exactement un job à un groupe ; les rôles s'appliquent à tout le système.
Comment Dagu exécute-t-il des commandes sur de nombreux serveurs ?
De deux façons. L'exécuteur SSH lance des étapes sur des hôtes sans agent, et le mode distribué démarre des workers sur des machines qui récupèrent les étapes correspondant à leurs labels worker_selector. Il n'y a pas d'inventaire resource model ; une diffusion vers une grande flotte s'exprime avec des étapes parallèles ou un script wrapper.
Dagu a-t-il besoin d'une base de données comme Rundeck ?
Non. L'historique d'exécution, les logs et l'état des files d'attente sont des fichiers sur disque. C'est aussi ce qui rend les réseaux fermés simples : un seul binaire, pas de JVM, et aucun service externe à atteindre.
Qu'est-ce qui remplace les plannings et les webhooks de Rundeck ?
Les plannings cron avec prise en charge des fuseaux horaires sont intégrés, et les exécutions peuvent être déclenchées de l'extérieur via l'API ou un webhook, avec le payload accessible au workflow. La concurrence est plafonnée par workflow par défaut, et les limites partagées passent par des files nommées.
Next step
Start with one workflow.
Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.