मैंने Docker से Podman पर स्विच क्यों किया

• Docker की background daemon (dockerd) संरचना की वजह से security vulnerabilities और resource consumption से जुड़ी समस्याओं की लगातार आलोचना होती रही है
• Podman daemon-less architecture अपनाता है, इसलिए containers user permissions के तहत सीधे चलते हैं, जिससे attack surface कम होता है और stability बेहतर होती है
• Systemd integration, Kubernetes-friendly design, और Buildah/Skopeo जैसे Unix philosophy-आधारित अलग-अलग tools के support से operations efficiency बढ़ती है
• Docker CLI के साथ high compatibility होने की वजह से, सिर्फ alias docker=podman से भी ज़्यादातर existing workflows वैसे ही काम करते हैं
• वास्तविक production environments में भी security और resource management आसान हो जाते हैं, और नए projects के लिए Podman ज़्यादा व्यावहारिक और future-oriented विकल्प बन रहा है

---

Docker की सीमाएँ और security issues

• Docker की संरचना ऐसी है कि dockerd daemon हमेशा root permissions के साथ चलता है
  • अगर daemon में vulnerability मिल जाए, तो पूरा host risk में आ सकता है
• प्रमुख security issue cases
  • 2019: runC container escape (CVE-2019-5736)
  • 2022: Linux Dirty Pipe vulnerability, cgroups v1 escape
  • 2024: runC “Leaky Vessels”, BuildKit vulnerability
  • 2024: Docker API exposure के जरिए cryptojacking campaign
• ऐसे incidents बार-बार होने से daemon-based structure के मूलभूत जोखिम सामने आए

Podman की daemon-less संरचना

• Podman background daemon का उपयोग नहीं करता
  • podman run चलाने पर container command चलाने वाले process का direct child process बनकर चलता है
  • rootless mode में चलने के कारण, container के अंदर root permissions भी host पर केवल सामान्य user permissions के बराबर होते हैं
• फायदे
  • security मज़बूत: container escape होने पर damage scope कम
  • stability बेहतर: एक container बंद हो जाए तो दूसरे containers प्रभावित नहीं होते
  • resource efficiency: अनावश्यक daemon हमेशा active नहीं रहता, इसलिए memory usage कम होता है

Podman की अलग पहचान वाली features

• Systemd integration
  • podman generate systemd से systemd unit files अपने-आप generate किए जा सकते हैं
  • standard systemctl commands से services manage की जा सकती हैं
• Kubernetes friendliness
  • Pod concept built-in होने से multi-container apps विकसित करना आसान होता है
  • podman generate kube से सीधे Kubernetes YAML generate किया जा सकता है
• Unix philosophy
  • Podman container execution पर focus करता है, image build के लिए Buildah, और registry management के लिए Skopeo का उपयोग होता है
  • ज़रूरत के मुताबिक optimized tools इस्तेमाल किए जा सकते हैं

migration process और compatibility

• Docker से Podman में migration लगभग बिना downtime के हो सकता है
  • CLI compatible है, इसलिए docker की जगह podman वैसे ही इस्तेमाल किया जा सकता है
  • मौजूदा Dockerfile भी वैसे ही काम करते हैं
• अंतर
  • rootless mode में 1024 से नीचे के ports bind नहीं किए जा सकते → reverse proxy recommended
  • volume permissions को manage करना पड़ता है
  • Docker socket पर निर्भर tools, Podman के Docker API compatibility mode का उपयोग कर सकते हैं

व्यावहारिक उपयोग और फायदे

• production environment में Podman इस्तेमाल करने के बाद
  • security audit का बोझ कम हुआ, rootless security default रूप में लागू हुई
  • resource usage pattern ज़्यादा सरल और predictable हो गया
• Docker अभी भी लोकप्रिय है, लेकिन नए projects या जहाँ technology choice की flexibility हो, वहाँ Podman ज़्यादा उपयुक्त है
  • Linux management system के साथ प्राकृतिक integration
  • Kubernetes-oriented architecture
  • ज़्यादा सुरक्षित और व्यावहारिक container runtime environment

FastAPI migration guide का सार

• मौजूदा Dockerfile को वैसे ही इस्तेमाल किया जा सकता है
• podman build, podman run से आसानी से replace किया जा सकता है
• podman generate systemd से systemd service register की जा सकती है
• Pods का उपयोग करके DB जैसे multi-service environments को support किया जा सकता है
• Docker Compose workflow के लिए podman-compose या kompose conversion का उपयोग किया जा सकता है

[shortstories]

यहाँ लिखा है कि बिना downtime के migration संभव है, लेकिन असली production environment में काफ़ी अजीब चीज़ें दिखीं। उदाहरण के लिए, mac environment में default setting के साथ zstd compression इस्तेमाल होने की वजह से built image registry को काफ़ी ज़्यादा भर देती है वगैरह..

[codemasterkimc]

Docker और podman दोनों....

securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL

securityContext:
runAsNonRoot: true
runAsUser: UID

[koxel]

असल में Docker compatibility अच्छी नहीं है, इसलिए usability भी बहुत अच्छी नहीं लगती...
rootless सोचकर Podman पर गया था, फिर वापस Docker पर लौट आया।
जैसा दूसरे लोग कह रहे हैं, अगर Kubernetes के साथ इस्तेमाल करना है तो बस containerd इस्तेमाल कर लो।

[click]

अगर Docker compose ठीक से काम नहीं करता और Kubernetes compatibility ही इसका फायदा है, तो यह सवाल आता है कि फिर सीधे Kubernetes ही क्यों न इस्तेमाल करें।
मैंने भी इसे आज़माने की कोशिश की थी, लेकिन यह एक बार में चल नहीं पाया और 1024 से कम port mapping भी सीधे नहीं कर सका, इसलिए मैं बस k3s और image build के लिए nerdctl के combination का इस्तेमाल करता हूँ।

[ndrgrd]

कभी न कभी इसे बदलने का मन तो था, लेकिन जब पहले कोशिश की थी, तब डेवलपर्स के कहने के उलट बहुत सारे docker compose प्रोजेक्ट ठीक से काम ही नहीं कर रहे थे...

[afewgoodman]

Docker network को support नहीं करता न.

[devsepnine]

मुझे पता है कि Docker की तरह यह network फीचर्स भी सपोर्ट करता है.
क्या अभी भी कुछ चीजें हैं जो ठीक से काम नहीं करतीं?

[GN⁺]

Hacker News राय

• 2001/2002 में मुझे WiFi hotspot box बनाना था। उस समय मैं OpenBSD का प्रशंसक था, और Python-आधारित डिस्ट्रीब्यूशन को जितना हो सके हल्का रखना चाहता था। अनावश्यक file copy और dependency समस्याओं से बचना चाहता था, इसलिए मैंने chroot और jail कॉन्सेप्ट चुना। मेरा deployment code jail environment के बाहर software चलाता था, और ptrace से process द्वारा खोली गई files को मॉनिटर करता था। इस output से dependency list निकालकर उसे package किया। नतीजतन deployment छोटा रहा, immutability बनी रही, और security भी बेहतर हुई। जब Docker आया तो मुझे वही पुराना तरीका याद आया, और सोचा कि क्या Docker container की file usage मॉनिटर करके distribution को छोटा करने वाला कोई ऐसा ही tool है
  • मैंने अब तक का सबसे अच्छा CI/CD pipeline Django freelance deployment में इस्तेमाल किया था। git post receive hook से हर git push पर static files build करना और httpd restart अपने-आप हो जाता था। बस git push live master करो और deployment हो जाता था। मैंने Docker बहुत इस्तेमाल किया है, लेकिन यही सबसे आसान deployment था। Docker के फायदे समझता हूँ, लेकिन Ubuntu या OpenBSD पर HTTP setup करना इतना मुश्किल नहीं है। सवाल यह है कि क्या Docker की reproducibility वाकई उतनी management overhead के लायक है
  • Google search के पहले result में 22k stars वाला slimtoolkit/slim है
  • OpenWrt environment में ujail नाम का एक tool है, जिसमें ELF executable देने पर वह ज़रूरी library dependencies parse करके tmpfs पर केवल आवश्यक files को read-only mount कर देता है
    संबंधित code link
• Podman मेरे लिए सच में शानदार अनुभव रहा है। Docker इस्तेमाल करना मुझे कठिन और traps से भरा लगा, जबकि Podman बिल्कुल पीछे नहीं है। सबसे बढ़कर, जिस कंपनी में मैं हूँ वहाँ licensing की चिंता भी नहीं करनी पड़ती। पूरी तरह win-win है
  • जानना चाहता हूँ कि क्या कंपनी में licensing सचमुच चिंता का विषय था। Docker Desktop की paid licensing policy वाजिब है। 250 से कम कर्मचारी या 10 million dollar से कम revenue हो तो यह मुफ़्त है। भले ही license cost सालाना $90 हो, अमेरिकी developer salary के हिसाब से यह lunch के पैसे से भी कम है। ऊपर से हर OS पर official supported tool भी मिलता है
  • असल में कंपनी को licensing की ज़्यादा चिंता करने की ज़रूरत नहीं है। Docker Engine पूरी तरह open source है, इसलिए मुफ़्त है। केवल Docker Desktop को enterprise में इस्तेमाल करने पर अलग license चाहिए। लेकिन ज़्यादातर features Docker Engine में ही मिल जाते हैं
  • Podman, Docker से कहीं बेहतर है। user/group permissions या root process security issues की चिंता नहीं रहती। daemon को data भेजने की भी ज़रूरत नहीं पड़ती
  • कुछ PCs पर Podman का Windows uninstaller सभी components को ठीक से हटाता नहीं, इसलिए दोबारा चलाने पर errors आते हैं। manually services हटाने पर भी समस्या बनी रहती है। यह काफ़ी बार चिढ़ पैदा करने वाली बात है
• मुझे Podman बहुत पसंद है, लेकिन यह हर container में हमेशा सही नहीं चलता। उदाहरण के लिए gitlab जैसे बड़े containers Docker के जटिल इतिहास और quirks पर निर्भर करते हैं, इसलिए Podman में अक्सर errors आते हैं। मेरी अपनी बनाई images ज़्यादातर Podman पर ठीक चलती हैं। problem वाले containers के लिए मैं incus VM चलाकर उसके अंदर उन्हें चलाने का workaround करता हूँ। Podman और Docker दोनों में GPU access का तरीका एकसमान नहीं है, जो असुविधाजनक है। इसके बावजूद मुझे Podman थोड़ा बेहतर लगता है। खासकर rootless इसकी बड़ी ताकत है
  • मेरा अनुमान है कि ज़्यादातर समस्याएँ उन images की वजह से होती हैं जो PID 1 को root के रूप में शुरू करती हैं। Podman default रूप से rootless है, इसलिए ऐसी समस्याएँ आती हैं। अगर Docker के बिना root-based images भी चलानी हैं, तो Podman को rootful और rootless mode में अलग-अलग रखकर --connection flag से मनचाहा environment चुन सकते हैं। ज़रूरत हो तो Podman अपने-आप VM भी बना सकता है (lima का उपयोग करके)। Podman Desktop में Docker compatibility layer भी है, जो compatibility issues कम करती है
  • मेरा मानना है कि कुछ containers का Podman में न चलना ही शायद इस blog post की प्रेरणा रहा होगा। अगर user base काफ़ी बड़ा हो जाए, तो publish करने से पहले Podman environment भी जाँचना आम प्रथा बन जाएगी
  • हम GitLab server और runner दोनों Podman पर चला रहे हैं। व्यक्तिगत रूप से मैं runner को k8s में ले जाना चाहूँगा, लेकिन अभी Traefik के साथ यह ठीक चल रहा है
  • मैं buildx से जुड़ी बहुत-सी features इस्तेमाल करता हूँ, और ऊपर-ऊपर से लगता है कि Podman में भी यह होता है, लेकिन असल में ठीक से काम नहीं करता
• Ubuntu पर podman support सबसे बड़ी समस्या है। Ubuntu का default podman version इतना पुराना है कि उसे सीधे इस्तेमाल नहीं किया जा सकता। मैं podman v5 इस्तेमाल करता हूँ, GitHub Actions में v3 है, और मेरे सहकर्मी docker इस्तेमाल करते हैं। आखिरकार मुझे scripts ऐसी बनानी पड़ती हैं जो पुराने podman, नए podman और docker—तीनों पर चलें, और इससे जटिलता बढ़ जाती है
  • कोई भरोसेमंद .deb build repository नहीं है। official .deb नहीं है, और जो मिले भी वे या तो पुराने हैं या कह रहे हैं कि आगे update नहीं होंगे। तब सवाल उठता है कि Podman installation आसान क्यों नहीं करता। मुझे लगता है RedHat competitor के software support पर development resources खर्च नहीं करना चाहता। स्वाभाविक है, लेकिन RedHat ecosystem के बाहर यह second-class citizen जैसा लगता है
  • मेरे हिसाब से यही सबसे बड़ी समस्या है। Docker के मुकाबले कम पहचान भी एक मुद्दा है, लेकिन version mismatch ही Podman को niche बनाए रखने का बड़ा कारण है। Ubuntu जैसी distros अक्सर पुराना software देती हैं, और इसे maintainers को संभालना चाहिए, लेकिन Podman पक्ष से इस पर ज़्यादा सक्रियता नहीं दिखती। इसी वजह से मैंने अपने home server में latest Podman के लिए RedHat family पर switch किया
  • official upstream .deb लगातार उपलब्ध न होना ही Podman को अंदरूनी तौर पर अपनाने से रोकता है। Docker का official .deb repo अच्छी तरह maintain होता है, इसलिए वह ईर्ष्या पैदा करता है
  • Ubuntu/Debian को मैं इस्तेमाल नहीं करता, उसका एक कारण updates का बहुत धीमा होना है। flatpak से इस्तेमाल किया जा सकता है, लेकिन ऐसे software default रूप से उपलब्ध होने चाहिए
  • Podman open source है, इसलिए Ubuntu जैसी जगहें इसे खुद package और update कर सकती हैं। RedHat सीधे competitor software की packaging भी संभाले, यह अपेक्षा भी समझ से बाहर नहीं है
• हाल ही में कंपनी के काम की वजह से Podman setup का अनुभव हुआ, और यह मेरे सबसे बुरे अनुभवों में से एक था। rootless Podman + SELinux + container के अंदर सामान्य user का combination सचमुच नरक है
  • सच कहें तो अगर उलझना हो तो किसी भी चीज़ में उलझ सकते हैं, लेकिन व्यवहार में ज़्यादातर चीज़ें ठीक चलती हैं। SELinux-enabled RHEL10 machines पर nginx reverse proxy के पीछे rootless containers में कई services (Forgejo, runner, uptime-kuma आदि) अच्छी तरह चला रहा हूँ
  • मुझे rootless का फायदा कभी महसूस नहीं हुआ। अगर machine एक ही security domain में है, तो root के रूप में चलाना ठीक है, और अगर ऐसा नहीं है तो असली isolated environment (जैसे Firecracker/Kata VM आदि) इस्तेमाल करना चाहिए। rootless में मेहनत ज़्यादा और लाभ संदिग्ध लगता है
  • मैंने भी कंपनी में यही स्थिति झेली है, लेकिन Podman के अपने तरीके (docs देखें) से हल करने पर यह उपयोगी बन जाता है। मुख्य बात है कि हाल के version के docs देखें
  • मैं Fedora पर 7 साल से ज़्यादा समय से सिर्फ podman इस्तेमाल कर रहा हूँ
  • हमारे संगठन ने Docker से Podman पर पूरा migration किया, और बीच में कुछ दिक्कतें आईं, लेकिन SysDev टीम की क्षमता से वे आराम से सुलझ गईं
• जब Docker Compose workflow बहुत जटिल हो जाए, तो सीधे Kubernetes YAML में बदलने की बात कही जाती है, लेकिन मेरे अनुभव में K8s YAML, docker compose से कहीं अधिक जटिल है। और हर कोई Kubernetes इस्तेमाल नहीं करता
  • मेरी राय उलट है। K8s YAML की complexity docker compose जैसी ही, या कभी-कभी उससे आसान भी हो सकती है। बस यह बहुत verbose होता है। 100-line compose, 20 YAML files (हर एक 50 lines) में टूट सकता है। अच्छा हो अगर kubectl में simple/complex YAML के बीच बदलने के लिए कोई sugar feature हो
  • docker compose को k8s yaml में बदलने के लिए LLM को layer की तरह इस्तेमाल करें तो यह बहुत अच्छा काम करता है। वैसे podman में भी k8s yaml generate करने की सुविधा है, इसलिए migration स्वाभाविक हो सकता है
  • मुझे compose file बनानी नहीं आती, लेकिन k8s yaml बना सकता हूँ। इसलिए compose ही मुझे ज़्यादा "complex" लगता है
• लेख में उल्लेख किया गया podman generate systemd command अब deprecated है। इसके बदले Podman Quadlets है, जो systemd unit files के भीतर परिभाषित docker-compose.yaml जैसी शैली है
  • Compose/orchestration को systemd को सौंपना तार्किक है। docker जैसी client-server संरचना नहीं, बल्कि यह वास्तविक user process है, इसलिए यह साफ़ तौर पर उपयुक्त विकल्प है
  • समस्या यह है कि documentation लगभग नहीं के बराबर है
• multi-UID containers को एक ही host user से map करना मुश्किल है। मूल रूप से container के भीतर root, host के चलाने वाले user से map होता है, लेकिन हाल में कई apps container के भीतर non-root users (जैसे www-data, user 1000 आदि) इस्तेमाल करने लगे हैं। इन्हें host पर subordinate IDs से map किया जाता है, और तब volume mapping में file ownership अनाथ जैसी दिखती है, जिससे भारी भ्रम होता है। काश कोई आसान option होता जो सभी UIDs को एक ही user से map कर दे, लेकिन मौजूदा options (crun का uidmap, userns) ठीक से काम नहीं करते। subordinate ID mapping की उपयोगिता पर संदेह है
  • अगर मेरी समझ सही है, तो यह Linux namespaces की सीमा है। Docker, Podman जैसे tools को ऐसी mapping support करने के लिए Linux support चाहिए। 1:1 UID mapping ज़रूरी होने का कारण यह है कि अगर container के user 1000 और 0 एक ही host user से map हो जाएँ, तो file ownership information गड़बड़ा जाती है
  • idmapped mounts पर विचार करना उपयोगी हो सकता है। यह केवल file system remapping support करता है, kernel calls के लिए समाधान नहीं देता
  • अच्छा होता अगर container के अंदर चीज़ें बस "खुद के रूप में" चल सकतीं, और logs में ownership भी वैसी ही दिखती
  • ignore_chown_errors option इस्तेमाल करने पर root को user ID से map करते समय बिना अतिरिक्त mapping के सरलता से लागू किया जा सकता है
• मैंने कई बार Podman migration की कोशिश की, लेकिन कई मोर्चों पर असफल रहा। पहला, मेरे छोटे VPS पर podman की performance docker से बहुत खराब थी (विवरण छोड़ रहा हूँ)। दूसरा, development ecosystem पूरी तरह साथ नहीं देता। कई tools Docker socket पर निर्भर करते हैं, लेकिन podman में permissions या API compatibility के कारण वे ठीक नहीं चलते। podman पूरी तरह drop-in replacement नहीं है
  • rootless podman में धीमा network, slirp4netns की वजह से हो सकता है। pasta एक तेज़ तरीका है। Docker default रूप से privileged daemon से networking setup करता है, इसलिए अगर podman को root user के रूप में चलाएँ, तो performance में फ़र्क नहीं होना चाहिए
  • podman और quadlet में SELinux permission errors लगातार सिरदर्द बने रहते हैं। जहाँ तक संभव हो, host-wide privileged pod बनाकर ज़रूरी /dev ही mount करना और बहुत सीमित programs को isolated network में expose करना ज़्यादा आसान पड़ता है
  • दिलचस्प बात यह है कि मेरे resource-constrained systems पर podman, docker से performance और resource usage दोनों में कहीं बेहतर रहा। शायद यह crun और runc के अंतर की वजह से है। और podman daemonless होने के कारण हल्का भी है
• Docker और Podman दोनों छोड़कर FreeBSD Jails पर चला गया
  • अधिक जानकारी और management tools यहाँ,
    यहाँ,
    यहाँ,
    यहाँ देखे जा सकते हैं
  • क्या FreeBSD jail के भीतर MS SQL Server या हज़ारों docker containers तुरंत चला सकते हैं? FreeBSD चुनने की बड़ी कीमत है (जैसे compatibility constraints)। यही वजह है कि jails mainstream नहीं हो पाए
  • setup सच में बहुत ज़्यादा है, और सोच रहा हूँ कि क्या FreeBSD में containerd जैसी कोई चीज़ है
  • FreeBSD jails distribution-specific feature हैं
  • Linux host पर VM चलाने और FreeBSD jail में असल अंतर क्या है?