Rundeck का विकल्प
JVM, SQL डेटाबेस और GUI में बनाए गए जॉब्स के बिना runbook automation।
Dagu उन operations टीमों के लिए Rundeck का विकल्प है जिन्हें scheduled जॉब्स, on-demand runbooks और एक Web UI, सब कुछ एक छोटी बाइनरी से चाहिए। जॉब परिभाषाएँ console के पीछे नहीं, बल्कि git में YAML के रूप में रहती हैं; state MySQL या Postgres के बजाय files में रहता है; और मौजूदा सर्वरों तक SSH या लेबल वाले workers से पहुँचा जाता है। यह पेज migration का रास्ता और वे जगहें भी बताता है जहाँ Rundeck अब भी ज़्यादा मज़बूत विकल्प है।
# 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
File-backed state वाली एक बाइनरी, न JVM, न SQL डेटाबेस
जॉब्स version control में YAML हैं और किसी भी अन्य बदलाव की तरह review होते हैं
SSH steps और लेबल वाले workers मौजूदा सर्वरों तक पहुँचते हैं
SSO, RBAC और audit logging, सार्वजनिक प्रति-सर्वर कीमत पर
At a glance
Ops automation के लिए Rundeck बनाम Dagu
File-backed state वाली एक बाइनरी; queues और workers वैकल्पिक।
Java service, और production में MySQL या Postgres।
git में review होने वाला declarative YAML।
Web console प्राथमिक है; YAML export और SCM sync सहायक रास्ता।
SSH steps, या mTLS gRPC पर बाहर की ओर जुड़ने वाले लेबल वाले workers।
Resource-model inventory से SSH या WinRM पर nodes को dispatch।
पूरे system पर लागू roles; licensed tier पर SSO और audit logging।
Project और जॉब स्तर की बारीक ACL policies।
असीमित सर्वरों के साथ मुफ़्त; सशुल्क प्लान प्रति Dagu सर्वर लाइसेंस होते हैं, workers असीमित।
Open-source core; commercial Process Automation की कीमत quote से तय होती है।
Scheduler का एक ही instance; HA एक deployment design है जिसकी ज़िम्मेदारी आपकी है।
Commercial tier cluster configurations देता है।
In depth
Where each tool fits
Runbook रखें, stack हटाएँ
Rundeck एक SQL डेटाबेस के आगे Java service के रूप में चलता है, और जॉब्स हर project में web console से परिभाषित होते हैं। Dagu वही operational अवधारणाएँ एक ऐसे single process के अंदर रखता है जो अपना state files में सहेजता है।
- जॉब्स DAG फ़ाइलें बन जाते हैं, job steps सीधे steps बनते हैं, और error handlers handler_on.failure से map होते हैं
- Job options, params से map होते हैं: defaults वाले typed inputs, जिनकी values run time पर UI, CLI या API से दी जाती हैं
- न कोई MySQL या Postgres जिसका size और backup सँभालना पड़े, न कोई JVM heap जिसे tune करना पड़े; एक छोटा VM इसे चला लेता है
Console clicks नहीं, जॉब्स code के रूप में
Rundeck परिभाषाएँ export कर सकता है और अपने SCM plugin से उन्हें sync कर सकता है, लेकिन authoring की मुख्य जगह console ही है। Dagu इसे उलट देता है: आपकी repository की YAML फ़ाइल ही परिभाषा है।
- हर जॉब git में एक YAML फ़ाइल है, इसलिए बदलाव console edits के बजाय review-योग्य diffs के रूप में आते हैं
- dagu validate, generated और हाथ से लिखी दोनों तरह की परिभाषाओं को scheduler तक पहुँचने से पहले CI में जाँचता है
- Web UI संचालन के लिए बना रहता है: parameters के साथ runs शुरू करें, logs देखें, retry करें और schedules suspend करें
बिना agent इंस्टॉल किए मौजूदा सर्वरों तक पहुँचें
Rundeck एक resource-model inventory से nodes पर commands dispatch करता है। Dagu वही ज़मीन दो तरीकों से cover करता है: agentless hosts के लिए SSH, और जहाँ स्थायी executor बेहतर बैठता है वहाँ workers।
- SSH executor से मौजूदा Linux और UNIX hosts पर steps चलाएँ, बिना किसी resident agent के
- जिन मशीनों पर local execution चाहिए वहाँ dagu worker शुरू करें, और worker_selector labels से steps उन तक route करें
- Workers mTLS से सुरक्षित gRPC पर बाहर की ओर जुड़ते हैं, इसलिए segmented networks में किसी inbound port की ज़रूरत नहीं
जॉब चलाने वाले और जॉब बदलने वाले लोगों को अलग-अलग रखें
क्लासिक Rundeck deployment operations का एक सुरक्षित हिस्सा एक बड़े समूह को सौंपता है। Dagu का licensed self-host tier यह अलगाव roles, SSO और audit logging से cover करता है।
- operator role runs शुरू और बंद कर सकता है लेकिन परिभाषाएँ edit नहीं कर सकता; viewer read-only है; developer और manager workflows बदल सकते हैं
- दूसरी user directory सँभालने के बजाय OIDC से अपने मौजूदा identity provider के ज़रिए sign in करें
- Audit logging प्रशासनिक और security से जुड़ी गतिविधियों को review के लिए दर्ज करती है
Sales call के बजाय एक सार्वजनिक कीमत
Rundeck का commercial tier PagerDuty Process Automation बन गया, जिसकी कीमत quote से तय होती है। Dagu का community tier असीमित सर्वरों और workers के साथ मुफ़्त है, और licensed tier की एक सार्वजनिक प्रति-सर्वर कीमत है।
- Community में पूरा orchestration engine, Web UI, cron scheduling, और Docker, SSH व HTTP executors शामिल हैं
- Licensed self-host तीन सर्वर लाइसेंस के लिए $500 प्रति वर्ष से शुरू होता है और SSO, RBAC, audit logging, incident routing तथा email support जोड़ता है
- हर प्लान में workers असीमित रहते हैं, इसलिए executing host जोड़ने से लाइसेंस की गिनती कभी नहीं बदलती
जहाँ Rundeck ज़्यादा मज़बूत विकल्प है
जो तुलना सिर्फ़ जीतें गिनाती है वह मूल्यांकन में काम नहीं आती। ये वे जगहें हैं जहाँ Rundeck इस्तेमाल करने वाली टीम को अतिरिक्त काम की उम्मीद रखनी चाहिए या वहीं बने रहना चाहिए।
- Rundeck की node inventory ज़्यादा समृद्ध है: resource-model sources और node filters एक ही command को सैकड़ों hosts पर फैला सकते हैं। Dagu steps को SSH hosts या लेबल वाले workers पर target करता है और इसमें fleet-inventory जैसी कोई अवधारणा नहीं है
- Rundeck की per-project और per-job ACL policies किसी helpdesk समूह को ठीक एक parameterized जॉब सौंप सकती हैं। Dagu के roles पूरे system पर लागू होते हैं, per job नहीं
- Commercial Process Automation high availability के लिए cluster configurations देता है, और WinRM node executors तथा notification plugins समेत plugin ecosystem भी बड़ा है
FAQ
Practical questions before adopting Dagu
क्या Dagu, Rundeck का drop-in replacement है?
नहीं। अवधारणाएँ साफ़ तरीके से map होती हैं: जॉब्स DAG फ़ाइलें बनते हैं, job steps सीधे steps बनते हैं, options, params बनते हैं और error handlers, handler_on.failure बनते हैं। लेकिन कोई importer नहीं है, और Rundeck के node-filter model का कोई सीधा समकक्ष नहीं है। migration का मतलब है हर जॉब को YAML फ़ाइल के रूप में फिर से लिखना, जो command-based जॉब्स के लिए यांत्रिक काम है।
क्या लोग अब भी UI से parameters के साथ जॉब्स trigger कर सकते हैं?
हाँ। params, defaults वाले typed inputs घोषित करते हैं, और run को Web UI, CLI या API से शुरू किया जा सकता है, जिसमें values run time पर दी जाती हैं। Dagu के पास जो नहीं है वह है Rundeck का per-job ACL, जो किसी समूह को ठीक एक जॉब expose करता है; roles पूरे system पर लागू होते हैं।
Dagu कई सर्वरों पर commands कैसे चलाता है?
दो तरीकों से। SSH executor agentless hosts पर steps चलाता है, और distributed mode में मशीनों पर workers शुरू होते हैं जो worker_selector labels से match हुए steps खींचते हैं। कोई resource-model inventory नहीं है; बड़े fleet पर fan-out को parallel steps या किसी wrapper script से व्यक्त किया जाता है।
क्या Dagu को Rundeck की तरह किसी database की ज़रूरत है?
नहीं। Run history, logs और queue state disk पर files हैं। यही बात closed networks को भी आसान बनाती है: एक बाइनरी, कोई JVM नहीं, और पहुँचने के लिए कोई external services नहीं।
Rundeck के schedules और webhooks की जगह क्या लेता है?
Timezone support वाले cron schedules built-in हैं, और runs को API या webhook से बाहर से trigger किया जा सकता है, जिसमें payload workflow को उपलब्ध रहता है। Concurrency डिफ़ॉल्ट रूप से हर workflow पर सीमित रहती है और साझा सीमाओं के लिए named queues इस्तेमाल होती हैं।
Next step
Start with one workflow.
Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.