Podman की खोज: Docker का एक अधिक सुरक्षित विकल्प

मूल लेख ↗ Hacker News चर्चा ↗

Podman Docker का एक लोकप्रिय विकल्प बन रहा है, मुख्यतः अपने security-first design के कारण: rootless कंटेनर, SELinux के साथ बेहतर एकीकरण, और कम intrusive networking जो Docker की कुछ firewall और VPN समस्याओं से बचता है। टिप्पणीकर्ता बताते हैं कि Podman अक्सर drop-in replacement की तरह काम कर सकता है और systemd तथा docker-compose/podman-compose जैसे tools के साथ अच्छी तरह चलता है, लेकिन tooling, UID/GID mappings, और platform issues, खासकर Apple Silicon पर, में कुछ खामियाँ बनी रहती हैं। कई लोग अभी भी Docker के ecosystem, documentation, और familiarity के कारण उसी पर टिके रहते हैं, और तर्क देते हैं कि अगर सही ढंग से configure किया जाए तो Docker rootless mode समान सुरक्षा चिंताओं को हल कर सकता है।

सुरक्षा मॉडल और rootless कंटेनर

  • कई लोगों के लिए Podman का “secure by default” मॉडल (rootless, user namespaces, कोई लंबे समय तक चलने वाला root daemon नहीं) Docker की तुलना में एक बड़ा लाभ माना जाता है।
  • Docker का डिफ़ॉल्ट रूप से root के रूप में चलना और docker समूह का उपयोग करना बहु-उपयोगकर्ता / प्रबंधित वातावरणों में एक गंभीर सुरक्षा जोखिम के रूप में आलोचना का विषय है।
  • कई टिप्पणियाँ नोट करती हैं कि Docker वास्तव में rootless mode और seccomp को डिफ़ॉल्ट रूप से सपोर्ट करता है, लेकिन यह out-of-the-box रास्ता नहीं है और इसे कम प्राथमिकता वाला माना जाता है।
  • कुछ लोग Podman-rootless बनाम Docker-as-root की तुलना को “अन्यायपूर्ण” मानते हैं; उनके अनुसार सही तुलना Docker-rootless बनाम Podman-rootless की है।

SELinux और labeling

  • Podman का SELinux नीतियों के प्रति पालन उत्पादन सुरक्षा के लिए सराहा जाता है, लेकिन इससे टकराव भी पैदा होता है (कंटेनर bind-mounted dirs तक पहुँच नहीं बना पाते)।
  • उपाय: containers.conf में labeling को disable करना, या volumes पर :z / :Z का उपयोग करके labels को स्वतः समायोजित करना।
  • SELinux पर राय “इसे सीखने में लगा एक घंटा वाजिब है” से लेकर “बेकार का trainwreck” तक फैली हुई है, हालांकि कुछ लोग ज़ोर देते हैं कि इसे disable करने के बजाय permissive में छोड़ना चाहिए।

नेटवर्किंग व्यवहार

  • Docker द्वारा iptables/nftables में किए जाने वाले बदलाव बार-बार परेशानी का कारण बताए जाते हैं: firewalls (UFW), VPNs, और KVM bridges के साथ टकराव।
  • Podman के बारे में कहा जाता है कि वह host networking और KVM के साथ “अच्छी तरह मेल” खाता है, हालांकि rootless networking पर kernel की सीमाएँ हैं।
  • forwarded ports में dynamic बदलाव की इच्छा जताई जाती है, लेकिन iptables/nftables की जटिलता को देखते हुए इसे तकनीकी रूप से कठिन बताया जाता है।

Systemd, Quadlet, और orchestration

  • शुरुआती Podman समर्थन podman generate systemd के लिए लोकप्रिय था; Quadlet की ओर बदलाव विवादास्पद है। कुछ लोगों को Quadlet अधिक साफ़-सुथरा लगता है; अन्य इसे अनावश्यक जटिलता मानते हैं और docker-compose या हाथ से लिखी गई units पर लौट जाते हैं।
  • podman-compose systemd units generate और register कर सकता है; कुछ इसे elegant मानते हैं, अन्य कहते हैं कि यह आसानी से खोजा नहीं जा पाता।
  • कई लोग homelabs और यहाँ तक कि छोटे production में भी docker-compose/podman-compose का उपयोग करते हैं; अन्य का तर्क है कि बड़े deployments को Kubernetes, Swarm, या Nomad की ओर बढ़ना चाहिए और वे एक सरल Podman-native “Swarm-like” orchestrator की इच्छा रखते हैं।

टूलिंग, compatibility, और developer workflow

  • Podman “अधिकांशतः” Docker का drop-in replacement है; लेकिन subtle CLI और behavioral differences scripts या compose setups को तोड़ सकते हैं, विशेषकर networking के आसपास।
  • Podman के साथ Docker tooling का उपयोग आमतौर पर एक Docker-compatible socket चलाने और DOCKER_HOST को उसी की ओर point करने से होता है; कुछ इसे trivial मानते हैं, जबकि कुछ इसे अनावश्यक friction कहते हैं।
  • Docker का ecosystem (compose files, docs, community) अभी भी अधिक mature और accessible माना जाता है, इसलिए कई संगठन developers के लिए Docker पर टिके रहते हैं, भले ही CI में Podman/Buildah का उपयोग करें।
  • NixOS उपयोगकर्ता compose2nix जैसे tools को highlight करते हैं जो compose files को native systemd/OCI configs में बदलते हैं।

प्लेटफ़ॉर्म-विशिष्ट अनुभव

  • Linux पर कई लोग दावा करते हैं कि यदि Podman उपलब्ध हो तो Docker उपयोग करने का “अब कोई कारण नहीं” है।
  • macOS (विशेषकर Apple Silicon) पर अनुभव मिश्रित हैं: कुछ लोग वर्षों तक बिना परेशानी उपयोग की रिपोर्ट करते हैं; अन्य गंभीर hangs या freezes का सामना करते हैं और Docker पर लौट जाते हैं। Podman Desktop कभी-कभी वहाँ काम करता है जहाँ CLI installs नहीं करते।
  • Windows पर Podman को Docker Desktop की तुलना में हल्का और कम intrusive माना जाता है, हालांकि इसमें कुछ IDE integrations नहीं हैं।

प्रेरणाएँ, राजनीति, और ecosystem संबंधी चिंताएँ

  • Podman में Red Hat के निवेश को Docker के साथ सहयोग करने के असफल प्रयासों और Docker की सुरक्षा, SELinux, systemd, तथा networking व्यवहार से असंतोष के परिणाम के रूप में देखा जाता है।
  • कुछ का तर्क है कि Podman का अस्तित्व, Linux बनाम proprietary OSes की तरह, Docker की शक्ति पर एक नियंत्रण के रूप में मूल्यवान है।
  • कौन-सी कंपनी अधिक भरोसेमंद है, इस पर बहस है; Red Hat/IBM बनाम Docker के बारे में राय अलग-अलग हैं, लेकिन Podman की पूरी तरह open प्रकृति को corporate दिशा बदलने पर एक safety net माना जाता है।

समस्याएँ और विकल्प

  • Podman के UID/GID mappings, ACLs, और labels नए उपयोगकर्ताओं को भ्रमित कर सकते हैं; शुरुआती adopters बताते हैं कि “यह बस काम नहीं करता था” और podman system migrate setups को बिगाड़ सकता था। बाद में शुरू करने वाले कुछ लोग इसे Docker से आसान पाते हैं।
  • कुछ workloads को आसानी से rootless mode में नहीं चलाया जा सकता (जैसे NFS mounts), जिससे उन environments में rootless Podman/Docker का मूल्य सीमित हो जाता है।
  • कुछ उपयोग मामलों के लिए कुछ लोग Docker और Podman दोनों से बचना पसंद करते हैं, bubblewrap या Buildah को सीधे उपयोग करते हैं और Dockerfiles को एक अनावश्यक DSL मानकर आलोचना करते हैं।