Aufgabenplanung-Alternative
Die Aufgabenplanung führt Befehle aus. Einen betreibbaren Zeitplan liefert sie nicht.
Dagu installiert sich als Windows-Dienst und ergänzt genau das, was der Aufgabenplanung immer gefehlt hat: Abhängigkeiten zwischen Jobs, Retries, Logs pro Schritt, eine Laufhistorie und eine Browser-Konsole für alle Server statt einer RDP-Sitzung je Maschine.
# 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: trueLäuft als Windows-Dienst
Schritte in PowerShell, pwsh und cmd.exe
Jobdefinitionen als versionierte YAML
Eine Web-Konsole über alle Server
At a glance
Aufgabenplanung und Dagu auf Windows Server
Mit depends deklariert; ein Fehler stoppt nachfolgende Schritte.
Keine. Reihenfolge wird über Startzeiten angenähert.
Retries, Recovery-Handler und Mail-Benachrichtigung.
Ein Ergebniscode, den ein Mensch prüft.
YAML im Git-Review, auf jeden Host ausrollbar.
Konfiguration je Maschine in der GUI, als XML exportierbar.
Browser-Konsole mit Laufhistorie und Logs je Schritt.
Lokales MMC-Snap-in und Ereignisprotokoll, je Server.
In depth
Where each tool fits
Reihenfolge über Uhrzeiten ist keine Abhängigkeit
Die Aufgabenplanung startet eine Aufgabe zu einer Uhrzeit. Ein Warten auf eine andere Aufgabe kennt sie nicht, also wird Reihenfolge über geschätzte Laufzeiten und versetzte Startzeiten ausgedrückt.
- Die 02:30-Aufgabe läuft unabhängig davon, ob die 02:00-Aufgabe erfolgreich war, und verarbeitet meist deren Überreste
- depends benennt die Reihenfolge direkt, sodass ein gescheiterter Vorgängerschritt die nachfolgende Arbeit stoppt statt sie zu verfälschen
- Wirklich unabhängige Jobs laufen parallel, statt vorsichtshalber zeitlich getrennt zu werden
Fehler, die sich selbst melden
Eine gescheiterte Aufgabe setzt einen Ergebniscode und wartet darauf, dass jemand hinsieht. Die meisten Teams erfahren es am nächsten Morgen von der Person weiter unten im Datenfluss.
- retry_policy wiederholt Transientes, bevor jemand geweckt wird
- handler_on.failure startet einen Recovery-Job, mail_on verschickt die Benachrichtigung
- Jeder Lauf behält stdout und stderr je Schritt, statt nur eines Rückgabecodes und dessen, was im Ereignisprotokoll landet
Definitionen zum Review und eine erreichbare Konsole
Definitionen der Aufgabenplanung leben in der Oberfläche einer Maschine. Der Export liefert XML, das niemand reviewt, und zehn Server zu prüfen heißt zehn Remote-Sitzungen.
- Workflows sind YAML in Git, eine Zeitplanänderung wird zum Pull Request, Test und Produktion halten dieselbe Definition
- Die Web-UI zeigt laufende und vergangene Läufe aus jedem Browser, ohne RDP je Server
- PowerShell, pwsh und cmd.exe stehen bereit, bestehende Skripte ziehen unverändert um
FAQ
Practical questions before adopting Dagu
Läuft Dagu als Windows-Dienst?
Ja. Der PowerShell-Installer kann es über einen versionsfixierten WinSW-Wrapper als Windows-Dienst registrieren. Es startet mit der Maschine und ist wie jeder andere Dienst über Get-Service sichtbar. Windows-Builds erscheinen für amd64, 386 und arm64.
Funktionieren bestehende PowerShell- und Batch-Skripte weiter?
Ja. Ein Schritt führt Befehle über PowerShell, pwsh oder cmd.exe aus, wählbar je Workflow oder je Schritt. Ohne konfigurierte Shell bevorzugt Dagu PowerShell, dann pwsh, dann cmd.exe. Skripte werden so aufgerufen wie zuvor durch die Aufgabenplanung.
Kann ein Dagu Jobs auf mehreren Windows-Servern verwalten?
Ja, auf zwei Wegen. Worker laufen auf anderen Maschinen und beziehen Arbeit von einem Coordinator; Remote Nodes lassen eine Web-UI zwischen getrennten Dagu-Installationen wechseln. In beiden Fällen ist die Konsole ein Browser statt einer Remotedesktop-Sitzung.
Welche Windows-Versionen werden unterstützt?
Windows Server 2019 und neuer ist das sichere Ziel. Ältere Builds ohne AF_UNIX führen Workflows weiterhin aus, aber der Socket für Live-Status und Stopp-Steuerung fehlt; Dagu protokolliert eine Warnung und läuft ohne ihn weiter.
Next step
Start with one workflow.
Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.