pyinfra — एजेंट-रहित इंफ्रास्ट्रक्चर ऑटोमेशन, शुद्ध Python में

• सर्वर ऑटोमेशन कार्यों को Python कोड में लिखकर SSH के जरिए समानांतर रूप से चलाया जाता है, और बिना एजेंट के कमांड्स को idempotent तरीके से निष्पादित किया जाता है
• pyinfra दावा करता है कि वही workload पर यह Ansible से 6 गुना तेज है, और gevent व SSH-आधारित concurrent execution का उपयोग करता है
• --dry विकल्प से लागू करने से पहले हर host के बदलावों का diff देखा जा सकता है, और वास्तविक execution में परिणाम parallel streaming के रूप में लौटते हैं
• target hosts पर केवल shell और SSH चाहिए; कोई daemon, state file या control plane नहीं है
• YAML में control flow एन्कोड करने के बजाय Python के loops और conditionals को ज्यों का त्यों इस्तेमाल करने वाली code-centric configuration पर ज़ोर दिया गया है

---

मुख्य फ़ीचर और execution flow

• हज़ारों सर्वरों का ऑटोमेशन

  • pyinfra एक Python-native, agentless ऑटोमेशन टूल है जो SSH के जरिए commands चलाता है
  • command execution में concurrency, idempotency और speed पर ज़ोर है, और वही workload पर Ansible से 6 गुना तेज होने का दावा किया गया है
  • installation command $ uv tool install pyinfra है
  • बताए गए बेसिक गुण MIT license, Python 3.10+, no agents, zero config हैं

• deployment code उदाहरण

  • apt, files, systemd operations को Python कोड में import करके package installation, template deployment और service reload किया जाता है
  • उदाहरण कोड nginx और certbot packages install करता है, और templates/nginx.conf.j2 को /etc/nginx/sites-enabled/api पर deploy करता है
  • आख़िरी चरण में systemd.service("nginx", reloaded=True) से nginx service reload की जाती है

  from pyinfra.operations import apt, files, systemd
  
  apt.packages(
      packages=["nginx", "certbot"],
      update=True,
  )
  
  files.template(
      src="templates/nginx.conf.j2",
      dest="/etc/nginx/sites-enabled/api",
  )
  
  systemd.service("nginx", reloaded=True)
  

• inventory और execution results

  • inventory उदाहरण में web-01.prod से web-23.prod तक के web hosts और db-01.prod, db-02.prod database hosts शामिल हैं
  • $ pyinfra inventory.py deploy.py --limit web कमांड केवल web targets तक execution को सीमित करती है
  • execution output inventory loading, concurrent fact gathering, deploy.py execution और summary के क्रम में आगे बढ़ता है
  • उदाहरण summary में 23 hosts सफल, 18 बदले गए, 0 failures, कुल 2.1 सेकंड दर्ज हैं

• बदलाव लागू करने से पहले जाँच

  • --dry pyinfra द्वारा किए जाने वाले सभी कार्यों का host-wise diff पहले दिखाता है
  • वास्तविक execution में results समानांतर रूप से stream होते हैं, और हर host के change count व execution time दिखते हैं
  • उदाहरण execution में 24 hosts में से 18 बदले गए, 6 बिना बदलाव, 0 failures, कुल 2.1 सेकंड दर्ज हैं

विशेषताएँ, Ansible तुलना, सिद्धांत

• pyinfra चुनने के छह कारण

  • Just Python: YAML और Jinja-in-YAML के बिना असली control flow Python में लिखा जाता है
  • Concurrent SSH: gevent और SSH के आधार पर concurrent execution, और वही workload पर Ansible से 6 गुना तेज
  • Diff before apply: --dry से सभी बदलाव पहले देखे जा सकते हैं, और idempotent operations दोबारा चलाने पर no-op बन जाते हैं
  • 0 agents: hosts पर सिर्फ shell और SSH चाहिए; कोई daemon, state file या control plane नहीं
  • Scale-ready: 1 host से 10,000 hosts तक काम करता है, और parallel execution व real-time streaming output को support करता है
  • Hackable: 10 लाइनों में custom operation बनाया जा सकता है, और shell से संवाद करने वाले docker, lxc, k8s से जोड़ा जा सकता है

• Ansible और pyinfra कोड तुलना

  • Ansible उदाहरण playbook.yml की 16 लाइनों में nginx installation, template rendering और handler-आधारित service reload को दिखाता है
  • pyinfra उदाहरण deploy.py की 8 लाइनों में वही flow Python कोड में लिखता है
  • pyinfra उदाहरण में files.template के result का cfg.will_change सच होने पर ही systemd.service("nginx", reloaded=True) चलाया जाता है

  from pyinfra.operations import apt, files, systemd
  
  apt.packages(["nginx"], update=True)
  
  cfg = files.template(
      src="nginx.conf.j2",
      dest="/etc/nginx/sites-enabled/api",
  )
  if cfg.will_change:
      systemd.service("nginx", reloaded=True)
  

• घोषणापत्र

  • Code > config: loop को loop की तरह ही रखा जाता है; control flow को YAML में एन्कोड नहीं किया जाता
  • Show, then do: पहले diff दिखाया जाता है, फिर लागू किया जाता है ताकि अनपेक्षित बदलावों से बचा जा सके
  • Stay out of the way: एजेंट, state file और control plane के बिना सीधे SSH से execution होता है
  • Read like english: operations apt.packages, files.template, systemd.service की तरह noun-verb रूप में पढ़े जाते हैं

• शुरुआत के कमांड

  • installation command $ uv tool install pyinfra है
  • 5 मिनट की quickstart पढ़कर पहला host deploy करने का मार्गदर्शन दिया गया है

[GN⁺]

Lobste.rs की राय

• pyinfra को देखकर लगता है कि Ansible मूल रूप से ऐसा ही होना चाहिए था। टेम्पलेट मिले हुए YAML पर control flow चढ़ाने के बजाय, automation सीधे Python में लिखा जा सकता है
  Ansible के साथ लंबे समय तक काम करने के बाद यह ताज़गीभरा लगा, और मैं ऐसा भी नहीं था कि Ansible से खास नफ़रत करता था

  • सही मायने में यह Python में लिखा Ansible कम, और Python को shell में बदलने वाले interpreter के ज़्यादा करीब लगता है, और उसकी अपनी समस्याएँ हैं
    बेहतर होगा कि target server पर भी Python इस्तेमाल करने वाला hybrid तरीका हो। इससे files अपडेट करते समय quote hell कम होगा, और sed की regex सीमाओं जैसी चीज़ों से भी बचा जा सकेगा

• मुझे pyinfra पसंद है और अच्छा लगेगा अगर इसका इस्तेमाल ज़्यादा व्यापक हो
  जिन कंपनियों में मैंने अब तक काम किया है, वहाँ Terraform साथ में हो या न हो, Ansible हर जगह था, और कहीं भी लोग बिना अनुभव वाले टूल के लिए मौजूदा automation को पूरी तरह दोबारा लिखने को तैयार नहीं थे
  pyinfra में SysOps को Python आना चाहिए, लेकिन मेरी राय में SysOps को कम-से-कम एक scripting language तो आनी ही चाहिए। खासकर Ansible में भी अगर modules Python में लिखे जाएँ तो YAML की अव्यवस्था काफ़ी कम हो सकती है, लेकिन कम-से-कम फ्रांस में यह आम सोच नहीं लगती

  • मैंने Ansible बहुत इस्तेमाल किया है, और सच कहूँ तो यह मूल रूप से script language होने का नाटक करने वाली चीज़ है
    शायद यह इतना बड़ा विवाद का विषय भी नहीं है

• होमलैब में Ansible इस्तेमाल करते-करते मैं धीरे-धीरे उससे परेशान हो गया। YAML config भयानक थी, हर चीज़ hack जैसी लगती थी, और performance भी दुखद थी। सिर्फ कुछ shell commands चलाने के लिए server पर python3 चाहिए, यह बात भी समझ नहीं आई
  Google AI Mode की वजह से मुझे pyinfra के बारे में पता चला, और लगभग एक महीने के इस्तेमाल में यह कहीं ज़्यादा ताज़गीभरा लगा। इसके फायदे हैं कि यह Ansible से काफ़ी तेज़ है, loops और conditions Python में लिखे जा सकते हैं, roles और nested directories की ज़रूरत नहीं, और server पर सिर्फ shell होना काफी है। रन से पहले यह current state के आधार पर plan बनाता है, और अगर -y न दें तो confirmation भी माँगता है
  कमियाँ यह हैं कि इसके default tasks, Ansible modules की तुलना में बहुत छोटे subset हैं, code जल्दी spaghetti बन सकता है, और if 'web_server' in hosts.groups जैसा तरीका भी बहुत अच्छा नहीं लगता। शायद operation(..., filter_group='web_server') बेहतर हो
  सबसे बुरी बात यह है कि custom connector लिखना बहुत ही तकलीफ़देह है। लगता है pyinfra-specific entry point वाला pyproject.toml चाहिए, और uv इस्तेमाल करने पर भी in-house connector development किसी दुःस्वप्न जैसा लगता है। यह बस project के अंदर की एक सामान्य Python file के रूप में बनाया जा सकना चाहिए

• मैं कुछ दिनों से pyinfra को होमलैब deployment tool के रूप में आज़मा रहा हूँ, और Ansible की तुलना में अब तक जो चीज़ सबसे ज़्यादा पसंद आई है, वह Python syntax नहीं बल्कि speed है
  Ansible हमेशा असहनीय रूप से धीमा लगा

  • यह क्षेत्र दिलचस्प है। मैं भी एक deployment tool बना रहा हूँ, और अपने मुख्य काम में उसे वास्तविक deployments के लिए इस्तेमाल कर रहा हूँ
    ज़्यादातर जगहों पर Ansible और Salt के उपयोग को बदल देना चाहता हूँ

• infrastructure as code का पूरा चक्र घूमकर वापस आना दिलचस्प है। पहले scripts से YAML पर गए, फिर वापस ज़्यादा परिष्कृत scripts पर लौट आए
  हर approach की अपनी सही जगह होती है, और Ansible user के नज़रिए से pyinfra काफ़ी अच्छा लगता है

  • हम लगातार configuration complexity clock के इर्द-गिर्द घूमते रहते हैं

• Ansible अपनाने की सबसे बड़ी वजह dry-run और diff mode थी। इससे भरोसा रहता था कि यह कोई अनपेक्षित काम नहीं करेगा
  लेकिन pyinfra CLI में ऐसा option दिखता नहीं है। हो सकता है मैं चूक गया हूँ क्योंकि alphabetically sorted सभी options वाला कोई reference document मुझे नहीं मिला

  • —dry flag है, और pyinfra की पहली screen पर ही दिख जाता है

• जिन्हें रुचि हो, उनके लिए इसी तरह का मेरा 14 साल पुराना project भी है: https://github.com/sebastien/cuisine/tree/main
  यह agentless है, सिर्फ SSH इस्तेमाल करता है, और core management features के ऊपर Python-जैसा API देता है, लेकिन dry mode सपोर्ट नहीं करता

• हम OpenStack में resources provision करने के लिए Ansible इस्तेमाल करते हैं, और बाकी सब pyinfra से संभालते हैं, और पिछले कुछ सालों में यह काफ़ी अच्छा चला है
  सबसे बड़ी कमी यह है that community छोटी है, इसलिए अक्सर समाधान खुद लिखने पड़ते हैं। उदाहरण के लिए deployment के लिए ज़रूरी shared secrets को हम keyring + privy के साथ disk पर रखते हैं, और OpenStack compute inventory को hosts data में बदलने के लिए कुछ lines का code खुद लिखते हैं