Task Scheduler का विकल्प
Task Scheduler कमांड चलाता है। ऐसा शेड्यूल नहीं देता जिसे आप संचालित कर सकें।
Dagu एक Windows सेवा के रूप में स्थापित होता है और वह सब जोड़ता है जो Task Scheduler में कभी नहीं था: जॉब्स के बीच निर्भरता, पुनःप्रयास, प्रति-चरण लॉग, रन इतिहास, और हर मशीन के लिए अलग RDP सत्र के बजाय सभी सर्वरों के लिए एक ब्राउज़र कंसोल।
# 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: trueWindows सेवा के रूप में स्थापित
PowerShell, pwsh और cmd.exe चरण
जॉब परिभाषाएँ वर्शन-नियंत्रित YAML में
सभी सर्वरों के लिए एक वेब कंसोल
At a glance
Windows Server पर Task Scheduler और Dagu
depends से घोषित; विफलता आगे के चरण रोक देती है।
कोई नहीं। क्रम प्रारंभ समय से अनुमानित किया जाता है।
पुनःप्रयास, रिकवरी हैंडलर और मेल सूचना।
एक अंतिम परिणाम कोड, जिसे व्यक्ति देखता है।
Git में समीक्षित YAML, किसी भी होस्ट पर तैनात।
प्रति-मशीन GUI विन्यास, XML के रूप में निर्यात योग्य।
रन इतिहास और प्रति-चरण लॉग वाला ब्राउज़र कंसोल।
प्रति सर्वर स्थानीय MMC स्नैप-इन और इवेंट लॉग।
In depth
Where each tool fits
घड़ी के समय से बताया गया क्रम निर्भरता नहीं है
Task Scheduler एक निर्धारित समय पर कार्य शुरू करता है। एक कार्य दूसरे की प्रतीक्षा करे, ऐसी अवधारणा उसमें नहीं है, इसलिए टीमें अवधि का अनुमान लगाकर और प्रारंभ समय अलग-अलग रखकर क्रम व्यक्त करती हैं।
- 02:30 वाला कार्य तब भी चलता है जब 02:00 वाला सफल न हुआ हो, और आमतौर पर उसी अधूरे परिणाम पर काम करता है
- depends क्रम सीधे बताता है, इसलिए विफल पूर्ववर्ती चरण आगे का काम रोक देता है, बिगाड़ता नहीं
- जो जॉब वास्तव में स्वतंत्र हैं वे समानांतर चलते हैं, सावधानी के नाम पर अलग-अलग समय पर नहीं
विफलताएँ जो खुद बताती हैं
विफल कार्य केवल अंतिम परिणाम कोड सेट करता है और प्रतीक्षा करता है कि कोई देखे। अधिकांश टीमों को अगली सुबह पता चलता है, डेटा के आगे बैठे व्यक्ति से।
- retry_policy किसी को जगाने से पहले अस्थायी विफलताओं को दोबारा आज़माता है
- handler_on.failure रिकवरी जॉब चलाता है और mail_on सूचना भेजता है
- हर रन प्रति चरण stdout और stderr रखता है, केवल एक रिटर्न कोड और इवेंट लॉग तक पहुँची बात नहीं
समीक्षा-योग्य परिभाषाएँ और पहुँच-योग्य कंसोल
Task Scheduler की परिभाषाएँ एक मशीन के GUI में रहती हैं। निर्यात से ऐसा XML बनता है जिसकी समीक्षा कोई नहीं करता, और दस सर्वर जाँचने का अर्थ है दस रिमोट सत्र।
- वर्कफ़्लो Git में YAML हैं, इसलिए शेड्यूल परिवर्तन एक pull request बनता है और परीक्षण तथा उत्पादन एक ही परिभाषा रख सकते हैं
- वेब UI किसी भी ब्राउज़र से वर्तमान और पुराने रन दिखाता है, प्रति सर्वर RDP के बिना
- PowerShell, pwsh और cmd.exe सभी उपलब्ध हैं, इसलिए मौजूदा स्क्रिप्ट बिना बदलाव के चलती हैं
FAQ
Practical questions before adopting Dagu
क्या Dagu Windows सेवा के रूप में चलता है?
हाँ। PowerShell इंस्टॉलर इसे वर्शन-पिन किए गए WinSW रैपर के ज़रिए Windows सेवा के रूप में पंजीकृत कर सकता है, जिससे यह मशीन के साथ शुरू होता है और Get-Service में किसी भी अन्य सेवा की तरह दिखता है। Windows बिल्ड amd64, 386 और arm64 के लिए प्रकाशित होते हैं।
क्या मेरी मौजूदा PowerShell और batch स्क्रिप्ट चलती रहेंगी?
हाँ। एक चरण PowerShell, pwsh या cmd.exe के माध्यम से कमांड चलाता है, जिसे प्रति वर्कफ़्लो या प्रति चरण चुना जा सकता है। शेल विन्यस्त न हो तो Dagu पहले PowerShell, फिर pwsh, फिर cmd.exe को प्राथमिकता देता है। स्क्रिप्ट उसी तरह बुलाई जाती हैं जैसे Task Scheduler बुलाता था।
क्या एक Dagu कई Windows सर्वरों पर जॉब प्रबंधित कर सकता है?
हाँ, दो तरीकों से। वर्कर अन्य मशीनों पर चल सकते हैं और coordinator से काम ले सकते हैं, और रिमोट नोड्स एक वेब UI को अलग-अलग Dagu परिनियोजनों के बीच स्विच करने देते हैं। दोनों स्थितियों में कंसोल एक ब्राउज़र है, रिमोट डेस्कटॉप सत्र नहीं।
कौन-से Windows संस्करण समर्थित हैं?
Windows Server 2019 और उसके बाद का संस्करण सुरक्षित लक्ष्य है। AF_UNIX समर्थन रहित पुराने बिल्ड भी वर्कफ़्लो चलाते हैं, लेकिन लाइव स्थिति और स्टॉप-कंट्रोल सॉकेट उपलब्ध नहीं होता, इसलिए Dagu चेतावनी दर्ज करके उसके बिना चलता रहता है।
Next step
Start with one workflow.
Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.