वितरित निष्पादन
एक वर्कफ़्लो ग्राफ़। हर प्लेटफ़ॉर्म पर workers।
Dagu का वितरित मोड वही एक बाइनरी है, दो भूमिकाओं में: काम बाँटने वाला coordinator और उसे poll करने वाले workers। Linux, macOS या Windows पर dagu worker शुरू करें, मशीन को labels से describe करें, और worker_selector से पूरा DAG या अलग-अलग स्टेप रूट करें। workers mTLS से सुरक्षित gRPC पर बाहर की ओर जुड़ते हैं, इसलिए न broker चाहिए, न साझा डेटाबेस, न worker पर कोई inbound पोर्ट।
# nightly-close.yaml
schedule: "0 2 * * *"
max_active_runs: 1
steps:
# Windows box exports from the line-of-business system
- id: export_sales
action: dag.run
with: { dag: export-sales }
worker_selector:
os: windows
# Linux worker near the data transforms it
- id: transform
action: dag.run
with: { dag: transform-sales }
worker_selector:
os: linux
region: us-east-1
depends: [export_sales]
# GPU worker scores the result
- id: score
action: dag.run
with: { dag: score-models }
worker_selector:
gpu: "true"
depends: [transform]एक ही बाइनरी सर्वर, coordinator और हर worker है
workers Linux, macOS और Windows पर, amd64 और arm64 पर चलते हैं
worker_selector labels के आधार पर पूरा DAG या एक स्टेप रूट करता है
workers mTLS से सुरक्षित gRPC पर बाहर की ओर जुड़ते हैं, NAT और निजी नेटवर्क में भी कोई दिक्कत नहीं
At a glance
वितरित Dagu बनाम broker आधारित worker स्टैक
एक बाइनरी से coordinator और workers; न broker, न result backend।
scheduler, broker, result store और workers अलग-अलग डिप्लॉय और अपग्रेड होते हैं।
Linux, macOS और Windows पर native workers।
workers प्रायः केवल Linux; Windows को WSL या कंटेनर से गुज़रना पड़ता है।
DAG या स्टेप स्तर पर घोषणात्मक worker_selector labels।
नामित कतारें, जो worker कॉन्फ़िग और टास्क कोड दोनों में बाँधनी पड़ती हैं।
workers mTLS से सुरक्षित एक पोर्ट पर बाहर की ओर जुड़ते हैं।
workers को पहुँच योग्य broker endpoints और साझा क्रेडेंशियल चाहिए।
In depth
Where each tool fits
कोई प्लेटफ़ॉर्म अपनाए बिना स्केल करें
वितरित निष्पादन डिप्लॉयमेंट का चुनाव है, कोई पुनर्लेखन नहीं। जो YAML एक मशीन पर चलता है वही पूरे बेड़े पर चलता है, कतार dispatch से पहले concurrency को नियंत्रित करती रहती है, और जिस DAG को मुख्य इंस्टेंस पर ही रहना है वह worker_selector: local से खुद को वहीं टिकाए रखता है।
- एक worker का मतलब एक कमांड: dagu worker --worker.coordinators=<host>:50055 --worker.labels gpu=true
- DAG परिभाषाएँ dispatch के समय gRPC से workers तक पहुँचती हैं, इसलिए workers के पास रिपॉज़िटरी की कोई कॉपी नहीं रहती
- default_execution_mode: distributed हर रन को बेड़े तक भेजता है; इसके बिना केवल worker_selector वाले DAG ही dispatch होते हैं
labels काम रूट करते हैं, मशीनें बदली जा सकती हैं
worker key-value labels से बताता है कि वह क्या है। DAG worker_selector से बताता है कि उसे क्या चाहिए। coordinator दोनों का मिलान करता है, इसलिए क्षमता बढ़ाने का मतलब है उन्हीं labels वाला एक और worker शुरू करना, वर्कफ़्लो में बदलाव नहीं।
- खाली selector किसी भी worker से मेल खाता है; labels वाले selector में हर key का सटीक मिलान ज़रूरी है
- अतिरिक्त labels वाले workers भी मेल खाते हैं, इसलिए एक मशीन कई pools की सेवा एक साथ कर सकती है
- dag.run स्टेप पर लगा worker_selector उस sub-DAG को parent से अलग worker पर भेजता है
अलग-अलग OS और आर्किटेक्चर का एक बेड़ा
workers वही Go बाइनरी हैं, जो Linux, macOS और Windows के लिए amd64 और arm64 पर रिलीज़ होती है। एक ही ग्राफ़ में Windows worker PowerShell स्टेप चलाता है और बगल में Linux worker bash, जबकि स्थिति, लॉग और इतिहास एक ही जगह दिखते हैं।
- परंपरा के अनुसार label लगाएँ, जैसे os=windows या arch=arm64, और उन्हीं selectors से रूट करें
- shared-nothing मोड लॉग और स्थिति gRPC से coordinator तक स्ट्रीम करता है, इसलिए NFS या साझा वॉल्यूम की ज़रूरत नहीं
- workers सिर्फ़ बाहर की ओर जुड़ते हैं, इसलिए NAT के पीछे, VPN पर या दूसरे क्लाउड की मशीनें भी बेड़े में शामिल हो सकती हैं
क्लाउड और Kubernetes के लिए तैयार
आधिकारिक Helm chart Kubernetes पर UI, scheduler, coordinator और वैकल्पिक worker pools डिप्लॉय करता है। workers क्लस्टर के बाहर से भी जुड़ सकते हैं: VM, bare metal या दफ़्तर का Windows होस्ट, और सीमा पार करने वाले ट्रैफ़िक को mutual TLS दोनों सिरों पर प्रमाणित करता है।
- helm repo add dagu https://dagucloud.github.io/dagu, फिर अपनी values के साथ helm install
- coordinator को बस एक पहुँच योग्य host:port चाहिए; एक Kubernetes Service या आंतरिक load balancer काफ़ी है
- coordinator और workers mTLS से एक-दूसरे के प्रमाणपत्र जाँचते हैं
FAQ
Practical questions before adopting Dagu
क्या मुझे message broker या बाहरी डेटाबेस चाहिए?
नहीं। coordinator gRPC पर टास्क बाँटता है और workers उसे poll करते हैं, उसी कनेक्शन पर heartbeat, स्थिति और लॉग लौटाते हैं। shared-nothing मोड में कोई साझा स्टोरेज होता ही नहीं; shared-filesystem मोड में workers उसी वॉल्यूम पर लिखते हैं जिसे सर्वर पढ़ता है।
क्या workers NAT के पीछे या निजी नेटवर्क में रह सकते हैं?
हाँ। एकमात्र ज़रूरी रास्ता worker से coordinator तक एक TCP पोर्ट है, और coordinator कभी worker की ओर उलटा कनेक्शन नहीं खोलता। NAT के पीछे, VPN पर या दूसरे क्लाउड की मशीनें बस coordinator का पता dial करके जुड़ जाती हैं।
Windows workers कैसे जुड़ते हैं?
वही बाइनरी इंस्टॉल करें, os=windows जैसे labels के साथ dagu worker चलाएँ, और Windows वाले DAG को मेल खाता worker_selector दें। उस मशीन के स्टेप आपके कॉन्फ़िगर किए shell में चलते हैं, जैसे shell: powershell -NoProfile, जबकि ग्राफ़ का बाक़ी हिस्सा कहीं और चलता है।
क्या पूरा Dagu Kubernetes पर चल सकता है?
हाँ। आधिकारिक Helm chart UI, scheduler, coordinator और आपके परिभाषित worker pools के Deployment बनाता है, और coordinator के आगे एक ClusterIP Service रखता है। क्लस्टर के बाहर के workers उस Service तक आपके खोले गए ingress या load balancer से पहुँचते हैं।
रन के बीच में worker ऑफ़लाइन हो जाए तो क्या होता है?
workers हर सेकंड heartbeat भेजते हैं। जब किसी worker का heartbeat 30 सेकंड से ज़्यादा पुराना हो जाता है, coordinator उसके चल रहे टास्क को विफल चिह्नित कर देता है, जिससे रन हमेशा के लिए अटकने की बजाय failure handlers और सूचनाएँ चालू हो जाती हैं।
Next step
Start with one workflow.
Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.