Alternative au Planificateur de tâches
Le Planificateur de tâches exécute des commandes. Il ne fournit pas un ordonnancement exploitable.
Dagu s'installe comme service Windows et comble ce qui a toujours manqué au Planificateur de tâches : dépendances entre jobs, reprises, journaux par étape, historique d'exécution et une seule console navigateur pour tous les serveurs au lieu d'une session RDP par machine.
# nightly-close.yaml
schedule: "0 2 * * *"
max_active_runs: 1
shell: powershell -NoProfile
steps:
- id: export
run: .\scripts\Export-Sales.ps1
retry_policy:
limit: 2
interval_sec: 300
- id: transform
run: .\scripts\Transform-Sales.ps1
depends: export
- id: load
run: .\scripts\Import-ToCore.ps1
depends: transform
handler_on:
failure:
run: .\scripts\Notify-Failure.ps1
mail_on:
failure: trueS'installe en service Windows
Étapes en PowerShell, pwsh et cmd.exe
Définitions de jobs en YAML versionné
Une console web pour tous les serveurs
At a glance
Planificateur de tâches et Dagu sur Windows Server
Déclarées avec depends ; un échec arrête les étapes suivantes.
Aucune. L'ordre est approché par les heures de démarrage.
Reprises, gestionnaires de reprise et notification par mail.
Un code de dernier résultat, consulté par un humain.
YAML relu dans Git, déployable sur n'importe quel hôte.
Configuration graphique par machine, exportable en XML.
Console navigateur avec historique et journaux par étape.
Composant MMC local et journal d'événements, par serveur.
In depth
Where each tool fits
Un ordre exprimé en heures n'est pas une dépendance
Le Planificateur de tâches déclenche une tâche à une heure donnée. La notion d'attente d'une autre tâche n'existe pas, alors on exprime l'ordre en estimant les durées et en espaçant les démarrages.
- La tâche de 02h30 s'exécute que celle de 02h00 ait réussi ou non, et consomme généralement ce qu'elle a laissé
- depends déclare l'ordre directement : une étape amont en échec arrête la suite au lieu de la corrompre
- Les jobs réellement indépendants s'exécutent en parallèle plutôt que d'être espacés par prudence
Des échecs qui se signalent
Une tâche en échec positionne un code de dernier résultat et attend qu'on la regarde. La plupart des équipes l'apprennent le lendemain matin, par la personne en aval des données.
- retry_policy relance ce qui est transitoire avant de réveiller qui que ce soit
- handler_on.failure lance un job de reprise et mail_on envoie la notification
- Chaque exécution conserve stdout et stderr par étape, au lieu d'un code de retour et de ce qui a atteint le journal d'événements
Des définitions relisibles et une console accessible
Les définitions du Planificateur vivent dans l'interface d'une machine. L'export produit du XML que personne ne relit, et vérifier dix serveurs signifie dix sessions distantes.
- Les workflows sont du YAML dans Git : un changement de planification devient une pull request, et test et production partagent la même définition
- L'interface web montre les exécutions en cours et passées depuis n'importe quel navigateur, sans RDP par serveur
- PowerShell, pwsh et cmd.exe sont disponibles, les scripts existants migrent tels quels
FAQ
Practical questions before adopting Dagu
Dagu fonctionne-t-il comme service Windows ?
Oui. L'installateur PowerShell peut l'enregistrer comme service Windows via un wrapper WinSW à version figée : il démarre avec la machine et apparaît dans Get-Service comme tout autre service. Des binaires Windows sont publiés pour amd64, 386 et arm64.
Mes scripts PowerShell et batch existants fonctionnent-ils toujours ?
Oui. Une étape exécute une commande via PowerShell, pwsh ou cmd.exe, au choix par workflow ou par étape. Sans shell configuré, Dagu privilégie PowerShell, puis pwsh, puis cmd.exe. Les scripts sont appelés comme le faisait le Planificateur de tâches.
Un seul Dagu peut-il gérer des jobs sur plusieurs serveurs Windows ?
Oui, de deux façons. Des workers peuvent tourner sur d'autres machines et recevoir du travail d'un coordinateur ; les nœuds distants permettent à une interface web de basculer entre des déploiements Dagu séparés. Dans les deux cas la console est un navigateur, pas un bureau à distance.
Quelles versions de Windows sont prises en charge ?
Windows Server 2019 et ultérieur est la cible sûre. Les versions plus anciennes sans AF_UNIX exécutent toujours les workflows, mais le socket de statut en direct et de contrôle d'arrêt est indisponible : Dagu journalise un avertissement et continue sans lui.
Next step
Start with one workflow.
Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.