Atuin Desktop: चलने वाले Runbooks
(blog.atuin.sh)- Atuin Desktop एक local-first runbook editor है जो दस्तावेज़ जैसा दिखता है लेकिन टर्मिनल की तरह चलाया जा सकता है, और इसका उद्देश्य बार-बार होने वाली ऑपरेशनल प्रक्रियाओं को साझा किए जा सकने वाले workflow में बदलना है
- shell commands, database queries, और HTTP requests को script blocks तथा built-in terminal, database client, और Prometheus charts के भीतर साथ में संभाला जाता है
- जहाँ Atuin CLI ने sync और search किए जा सकने वाले shell history की सुविधा दी, वहीं Desktop इसे चलने योग्य दस्तावेज़ तक बढ़ाता है ताकि टीम का ज्ञान सिर्फ व्यक्तिगत याददाश्त या history में सीमित न रह जाए
- Atuin टीम पहले से ही इसे CLI releases, environments के बीच infrastructure migration, staging/prod execution, और live database query management व collaboration के लिए इस्तेमाल कर रही है
- अगले चरण में Team accounts और shell history से runbook बनाने की सुविधा की योजना है, और अभी early access जारी है
व्यक्तिगत याददाश्त पर निर्भर ऑपरेशनल प्रक्रियाओं को दस्तावेज़ित करना
- कई infrastructure tasks किसी समस्या के समय किसी व्यक्ति को याद रहने वाले कुछ commands पर निर्भर होते हैं, और दस्तावेज़ या तो होते नहीं हैं या जल्दी पुराने पड़ जाते हैं
- असली समाधान के संकेत Slack threads, Notion documents, और व्यक्तिगत shell history में बिखरे हो सकते हैं
- Atuin CLI ने sync और searchable shell history के ज़रिए इस समस्या का कुछ हिस्सा हल किया, लेकिन टीमों को history से आगे बढ़कर shareable workflows की ज़रूरत होती है
- Atuin Desktop एक executable runbook editor है, जिसे इस विचार के साथ बनाया गया है कि “runbook को चलाया जा सकना चाहिए”
- डाउनलोड डाउनलोड पेज पर उपलब्ध है
दस्तावेज़ के भीतर चलने वाले terminal workflows
- Atuin Desktop को इस तरह बनाया गया है कि दस्तावेज़ UI के भीतर वास्तविक terminal workflows चलाए जा सकें
-
एक ही जगह पर जुड़ने वाले कार्य घटक
- script blocks
- built-in terminal
- database client
- Prometheus charts
-
उपलब्ध सुविधाएँ
- कम context switching: shell commands, database queries, और HTTP requests को जोड़ता है
- ऐसे दस्तावेज़ जो पुराने न पड़ें: दस्तावेज़ से सीधे चलाकर उन्हें अद्यतन रखा जा सकता है
- पुन: उपयोग योग्य automation: Jinja-style templates से dynamic runbooks बनाए जाते हैं
- तुरंत याद दिलाना: वास्तविक shell history से autocomplete उपलब्ध कराता है
- Local-first, CRDT-powered: जो कुछ terminal में चलता है, वही runbook में भी चलता है
- Atuin Hub sync और sharing: devices और टीमों के बीच नवीनतम स्थिति बनाए रखता है
वास्तविक उपयोग के मामले और डिप्लॉयमेंट की स्थिति
- Atuin टीम पहले से ही Atuin Desktop का वास्तविक कामों में उपयोग कर रही है
- Atuin CLI releases
- environments के बीच infrastructure migration
- staging या prod execution
- live database queries का management और collaboration
- अगली सुविधाओं में Team accounts और shell history से runbook बनाने की क्षमता शामिल होगी
- यह अभी जारी किया जा रहा है, और early access list के माध्यम से शामिल हुआ जा सकता है
1 टिप्पणियां
Hacker News की राय
अगर आपको Emacs में दिलचस्पी है, तो org-babel से ऐसा ही काम किया जा सकता है
एक plain text फ़ाइल program भी हो सकती है और document/notebook/website भी, और यह literate programming का एक दमदार उदाहरण है
अच्छी व्याख्या यहाँ है: https://osem.seagl.org/conferences/seagl2019/program/proposa...
Programming books से पढ़ते समय इससे मुझे बहुत मदद मिली, और बाद में जब उस literate program को दोबारा देखता हूँ तो किताब पहली बार पढ़ने की तुलना में समझ बहुत तेज़ी से वापस आ जाती है
Literate वाला हिस्सा उन “बेवकूफी भरे” सवालों के जवाब दे देता है जो उस समय की reasoning या अपने विचार 100% याद न रहने से पैदा होते हैं
बेशक learning curve है, इसलिए जो लोग ऐसी चीज़ सीखना नहीं चाहते उनके लिए यह सही नहीं है
Presentation video[0] और एक Git repository[1] भी देख सकते हैं जिसमें ज्यादा advanced demo है
[0]: https://www.youtube.com/watch?v=0g9BcZvQbXU
[1]: https://gitlab.com/spudlyo/orgdemo2
करीब 7 साल पहले मैंने यह आज़माया था: https://nurtch.com/
idea में अपने-आप में कई खूबियाँ हैं, और JupyterCon Paris 2023 में भी इस पर related talk दिया था: https://www.youtube.com/watch?v=TUYY2kHrTzs
जब document के अंदर executable code होता है, तो लोग documents पर भी PR review workflow लागू करना चाहते हैं, और इसके लिए wiki edit करने की तुलना में team level पर ज्यादा investment चाहिए
AWS में रहते हुए हमारी team को ठीक इसी चीज़ की ज़रूरत थी
ऐसे बहुत सारे operations tasks होते हैं जिन्हें automate करना थोड़ा risky होता है, और यह ऐसे tasks को धीरे-धीरे repeatably automation में बदलने का रास्ता देता है
जिज्ञासा है कि आप AWS में कब थे
पिछले कुछ वर्षों में AWS में एक internal platform service बनाई गई, जो operational runbooks को code में बदलने और उन्हें safely auto-run करने में मदद करती है ताकि operational toil कम हो
Atuin Desktop भी कुछ मायनों में उस service जैसा है, लेकिन उस internal service में कहीं ज्यादा features थे
CloudWatch queries, AWS CLI commands जैसी चीज़ों को user input के साथ run करना, लेकिन सही credentials को safely लाने और inputs format करने की configuration का बोझ हटाना—कुछ ऐसा था
बाद में इसे GitHub से सीधे run करने के लिए फिर से बनाया, और GitHub wiki से user input के साथ Lambda function को 4 lines code में call करने का example यहाँ है: https://speedrun.nobackspacecrew.com/index.html#invoking-an-...
यह IAM integration वाला hosted notebook था
सोच रहा हूँ कि यह local Jupyter notebook से कैसे अलग है
.ipynbमें!या%से यह किया जा सकता है, है न?मैं सचमुच पूछ रहा हूँ, क्योंकि इस company या CLI product को अच्छी तरह नहीं जानता
pipenv/pyenv/conda/poetry/uv/dependencies.txt और “इस notebook को run करने के लिए Python upgrade करना पड़ेगा, आह… ठीक है” से शुरू होकर 2 हफ्ते बाद “उस upgrade ने पुराने Ansible को तोड़ दिया और अब मैं मुश्किल से चल रहे 15 servers fix नहीं कर पा रहा” तक पहुँचने वाला flow नरक जैसा है
मैं foundational automation में Python से दूर रहने की कोशिश करता हूँ
जिन Python projects से मेरा पाला पड़ता है, वे dependency या runtime issues के कारण साल में कम से कम एक बार टूटते हैं, और यही बात Ansible, build pipelines,
deploy.pyजैसी चीज़ों पर भी लागू होती हैJupyter notebooks एक विशाल dependency tree और requirements साथ ले आती हैं, इसलिए ऐसी critical और foundational automation में मैं उनका इस्तेमाल नहीं करूँगा
हाँ, मेरा काम मुझे जरूरत से ज्यादा codebases handle करवाता है, और पिछले दो महीनों में ही कम से कम 6 Python projects थे
किसी को Python 2.7 चाहिए, किसी को obsolete
lib-something.hका version चाहिए, कोई bleeding edge है, और कोई documented तो नहीं है लेकिन असल में बहुत strict है—“जब तक responsible developer की machine पर कुछ भी update न किया जाए, तब तक चलता है” जैसी हालतPuppet और Chef भी Ruby होने के कारण उतने ही खराब हैं और वही problems झेलते हैं, फर्क बस इतना है कि Ruby के पास दशकों से सिर्फ एक package management system रहा है
आमतौर पर Jupyter flexible scripting और operating system command support दोनों देता हुआ लगता है
!/%याos.system()से भी किया जा सकता हैयह https://runme.dev से बहुत मिलता-जुलता दिखता है
मुझे executable documents पसंद हैं, और लगता है कि अभी ये पर्याप्त मात्रा में नहीं हैं
दिलचस्प लग रहा है
हाल में Jupyter notebook alternative के तौर पर https://marimo.io/ इस्तेमाल करना शुरू किया है, उसमें कई improvements हैं और यह भी उसी दिशा की movement जैसा दिखता है
अगर local-first है, तो यह पहले से ही rot (सड़न) का निशाना है
अगर सब कुछ containers में नहीं चल रहा है तो ऐसा ही है, और अगर containers में चल रहा है तो local होना मायने नहीं रखता
अगर runbook रिकॉर्ड करनी है, तो बस runbook रिकॉर्ड कर दें
तरीके अनगिनत हैं: text files, Confluence documents, screen recordings, shell scripts वगैरह
लोग पहले से ही ऐसा नहीं कर रहे हैं, और UI ज़्यादा आकर्षक हो गया तो वे अचानक ज़्यादा करने लगेंगे, ऐसा नहीं होगा
निजी तौर पर, मैं system को X state जैसा बनाने के लिए पूरा दिन code या documents लिखना नहीं चाहता
मैं manually X state बनाना चाहता हूं, फिर किसी tool से state dump करना चाहता हूं, और बाद में उसी tool को फिर चलाकर वह state बनाना या enforce करना चाहता हूं
मैं computer को उस state तक पहुंचने का तरीका code में समझाना नहीं चाहता, और declarative configuration भी नहीं लिखना चाहता, जो बस अलग नाम वाला code है
खुद करना, snapshot लेना, और replay करना चाहता हूं
यह Bash shell commands को watch करने जैसी dependency के बिना कहीं भी, किसी भी system पर काम करना चाहिए
Dockerfile असल में इससे मिलता-जुलता है, लेकिन वह उस state तक पहुंचने के लिए गुज़रे steps को file में document करता है
https://linux.die.net/man/1/autoexpect
उस point पर बेहतर है कि पहले से कोई declarative description हो, जिसे X state तक पहुंचने के लिए ज़रूरी steps में automatically convert किया जा सके
package installed है या नहीं, file मौजूद है या नहीं या उसमें कोई खास content है या नहीं जैसे common tasks के लिए modules इस्तेमाल होते हैं; यह declarative और idempotent है
सोच रहा हूं कि Atuin CLI और sync server की तरह यह भी open source होगा या नहीं
क्या इसे productize किया जाने वाला है?
फिर भी announcement देखकर अच्छा लगा
मुझे ठीक से समझ नहीं आ रहा कि इसकी ज़रूरत क्यों है
क्या कोई समझा सकता है कि मैं क्या miss कर रहा हूं? simple shell script के बजाय इसे क्यों इस्तेमाल करूं?
आप ऐसी team में हैं जो कई targets संभालती है; उनमें से कुछ को आप बहुत अच्छी तरह जानते हैं और अक्सर touch करते हैं, लेकिन कुछ के बारे में बस हल्का-सा पता है कि वे exist करते हैं और उन्हें शायद ही कभी छूते हैं
बाद वाली category का X टूट जाता है
X को सच में जानने वाले सभी लोग vacation/dead/meeting में हैं
अच्छी बात यह है कि इस situation में क्या करना है, यह बताने वाला document मौजूद है
लेकिन वह document किसी तरह खराब information का चमत्कार दिखाता है: पुराना और गलत
यही वह problem है जिसे यह solve करना चाहता है
creator से थोड़ी बात करने पर लगा कि intent कुछ ऐसा बनाने का है जो Jupyter Notebooks और Ansible Tower के बीच का हो
documents, scripts और metrics को पास-पास रखकर यह समझना आसान हो कि क्या गलत है, उसे कैसे ठीक करना है, और fix ने असर किया या नहीं
[1] disclosure: मैं atuin Discord चलाने में मदद करता हूं
इसलिए “Runbooks That Run” है
कुछ लोगों को कोई खास workflow या tool flow पसंद होता है, इसलिए वे बस बना देते हैं
अगर यह पर्याप्त लोगों को fit बैठता है, तो marketable हो सकता है, वरना नहीं
personal project में मैं PHP deployment process इस्तेमाल करता हूं, बस क्योंकि मैं ऐसा करना चाहता हूं; यह मेरे अलग से कुछ किए बिना 60% काम संभाल लेता है
उसके लिए runbook tool में built-in task है और पूरे server deployment वाले उसी Git repository में है
मैं इसे किसी arbitrary जगह या shell script में नहीं रखना चाहता, जहां अलग command याद रखनी पड़े
programmers के लिए code, अगर complexity से बचकर simple functional style रखा जाए, तो मूल रूप से self-documenting हो जाता है
कभी-कभी केवल उन हिस्सों पर comment करना पड़ता है जो simple flow नहीं हैं, जैसे “MySQL user बनाना, password rotate करना, संबंधित services में नया user/password combination reflect करना, और VPN blocking fail होने की संभावना के लिए निकाले गए employee के credentials वाले पुराने user को हटाना”
dream tool यह है कि सभी tools terminal interface दें, ताकि दिमाग में मौजूद सारे context को समेटने वाली एक विशाल book बनाई जा सके
जैसे Jira, Datadog, GitHub आदि को एक ही screen पर लाना
कल्पना करें कि हर internal service के components वाला internal TUI framework हो, और उसे Lego की तरह जोड़कर personalized TUI dashboard बनाया जा सके
company में side project के तौर पर करने लायक लगता है, और बहुत बड़ा काम होगा, लेकिन interesting होगा
ideal world में हर service, tool और application कोई API दे जिसे मैं इस्तेमाल कर सकूं
उदाहरण के लिए, fridge का door बहुत देर तक खुला हो तो API polling या webhook से detect करें, और Roomba API इस्तेमाल करके उसे बंद करने भेज दें
क्यों नहीं? यह API की दुनिया है
लगता है development एक साल से रुकी हुई है, लेकिन idea लगभग वही है
https://wtfutil.com/