Podman v6.0.0 जारी

 (blog.podman.io)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Podman v6.0.0 एक major release है जो container management के अनुभव को और बेहतर बनाती है, और इसमें core infrastructure modernization के साथ security और usability सुधार भी शामिल हैं
  • Networking, slirp4netns·iptables-केंद्रित संरचना से Netavark·Pasta·nftables-आधारित दिशा में जा रही है, जिससे maintenance का बोझ कम होगा और आगे के feature विस्तार की तैयारी होगी
  • Experimental feature Pesto rootless port forwarding custom network के rootless containers में सही source IP preservation को support करता है
  • Podman Machine कई VM providers के साथ usability को बेहतर बनाती है, और podman machine os update के जरिए VM environment को up-to-date रखा जा सकता है
  • Quadlet, configuration file handling, Docker API compatibility, और command output को भी बेहतर बनाया गया है, जिससे multi-user management और Docker से migration आसान हो जाता है

Podman v6.0.0 में क्या बदला है

  • नया release GitHub release page पर देखा जा सकता है, और जल्द ही package managers के जरिए भी उपलब्ध होगा

  • Networking modernization

    • slirp4netns और iptables से Netavark, Pasta, और nftables की ओर बदलाव किया गया है
    • यह सुव्यवस्थित networking stack maintenance को सरल बनाती है और भविष्य के features जोड़ने की नींव तैयार करती है
    • Experimental support Pesto rootless port forwarding के जरिए custom network के rootless containers में सही source IP preservation संभव है

  • Podman Machine improvements

    • कई VM providers को अधिक सहज तरीके से संभालने के लिए usability में सुधार किया गया है
    • podman machine os update कमांड से VM environment को नवीनतम स्थिति में रखा जा सकता है
    • इससे जुड़े अतिरिक्त सुधारों पर आगे अलग लेख में अधिक विस्तार से चर्चा की जाएगी

  • Quadlet expansion

    • REST API support जोड़ा गया है
    • संबंधित files की tracking बेहतर की गई है, जिससे management आसान होता है
    • .volume unit functionality का विस्तार किया गया है
    • deployment packaging को आसान बनाने के लिए अतिरिक्त search paths शामिल किए गए हैं

Configuration और Docker compatibility

  • Configuration file handling बदली गई है, जिससे multi-user environments को manage करने वाले administrators इसे अधिक सहज और भरोसेमंद तरीके से इस्तेमाल कर सकते हैं
  • Docker compatibility भी बेहतर हुई है
    • Docker API support को update किया गया है
    • Command output को सुधारा गया है, जिससे Docker से Podman पर migration आसान हो जाता है
  • पूरी बदलाव सूची Podman v6.0.0 release notes में दी गई है

संबंधित पढ़ाई

2 टिप्पणियां

 
click 3 시간 전

मैं सोच रहा हूँ कि जब podman compose इस्तेमाल लायक हो जाएगा तब उस पर शिफ्ट करूँगा, लेकिन समझ नहीं आता कि आखिर यह कब इस्तेमाल लायक बनेगा।
आजकल docker run से सीधे चलाना मेरे हिसाब से सिर्फ temporary containers या test runs के लिए रह गया है, ऐसे में compose support का अच्छा न होना एक बड़ी कमजोरी है।
अगर लंबी-चौड़ी configuration और पक्का management चाहिए, तो बस k8s इस्तेमाल करना बेहतर है।
2026 के इस दौर में docker या podman की खूबी यही है कि k8s की कई resource definitions के बिना, एक आसान yml config file में किसी एक app द्वारा इस्तेमाल होने वाला पूरा stack define किया जा सकता है।
अगर k8s compatibility को ही आगे रखना है, तो local पर चलने वाले हल्के k8s implementations जैसे k3s, minikube, microk8s इस्तेमाल करना कहीं बेहतर है।
मुझे नहीं लगता कि rootless यहाँ समस्या है।
 
GN⁺ 4 시간 전
Hacker News की राय

  • समझ नहीं आता कि Docker अब भी Podman से इतना ज़्यादा लोकप्रिय क्यों है। implementation के हिसाब से देखें तो Podman साफ़ तौर पर बेहतर है, और नया networking feature भी स्वागतयोग्य सुधार है

    • मुख्य वजह शायद यह है कि deployment थोड़ा ज़्यादा झंझट वाला है और अलग-अलग steps ज़्यादा बिखरे हुए हैं। खासकर अगर rootless जाना हो तो और भी, और सच कहें तो वैसा ही करना चाहिए
      जो लोग Linux-first नहीं हैं, जैसे app containerization सीख रहा कोई शुरुआती developer, उसके लिए systemd unit files या kubelet settings संभालना, dedicated local service account बनाना, और linger enable करना याद रखना—Docker install करके docker compose file बनाने और “start” दबाने की तुलना में काफ़ी intimidating है
      समझ आता है कि उन्होंने यह approach क्यों चुनी, लेकिन यह काफ़ी भद्दा और user-friendly नहीं लगता
    • fuse-overlayfs Docker के overlayfs setup की तुलना में साफ़ तौर पर धीमा था। शायद इसे reconfigure करने का कोई तरीका हो, लेकिन हाल में चेक नहीं किया
      Zig से ghostty build करते समय Podman में कोई अस्पष्ट “unknown file” error आया था, और बाद में पता चला कि fuse-overlayfs कुछ attributes support नहीं करता था जिन्हें वह check करने की कोशिश कर रहा था
      हर बार migrate करने की कोशिश में ऐसी random छोटी-छोटी समस्याएं अटकाती रहती हैं। simple use cases के लिए इस्तेमाल कर रहा हूं
    • आख़िरी बार जब देखा था, podman compose बस ऊपर-ऊपर से docker compose जैसा था। inotify जैसी चीज़ें भी Podman side पर random तरीके से अक्सर टूटती लगती हैं
      Podman recommend करना चाहता हूं, लेकिन docker compose compatibility अच्छी नहीं है और volumes में inotify न हो तो developer experience बहुत problematic हो जाता है
    • एक वजह शायद ज़्यादा मजबूत brand name भी है। macOS पर Docker Desktop ज़्यादा intuitive था। हालांकि हाल में उसमें errors बहुत frequent हो गए हैं, और file mounts या network rules cleanup random तरीके से fail हो जाते हैं या अचानक बहुत slow हो जाते हैं, जिससे VM restart करनी पड़ती है
      macOS पर Podman काफ़ी कम polished लगता है, और OrbStack कहीं बेहतर option है
      Linux पर ही Podman इस्तेमाल करता हूं और वहां यह बहुत fast है। फिर भी लगता है कि ज्यादातर features systemd के साथ जुड़कर Kubernetes को replace करने की दिशा में बने हैं, जबकि असल docker compose support unstable है और TUI/UX भी original से पीछे है
    • छोटी-छोटी वजहों से Podman छोड़ दिया। एक यह था कि इसने Docker से अलग तरीके से SELinux handle करने का फैसला किया, इसलिए default CentOS system पर SELinux security labels बदलने पड़ते थे। यह अपनाने लायक नहीं था
      दूसरी समस्या Docker के साथ छोटी-छोटी differences थीं, इतनी कि packaged Docker compose वैसा ही काम नहीं करता था। Docker पर switch करते ही सब चल जाता है और दिन का काम जारी रख सकते हैं; उसे debug करने में समय नहीं लगाना चाहता था

  • Docker Desktop के फिर से random तरीके से बहुत ज़्यादा memory खाने के बाद Podman पर switch किया, और यह सचमुच install करने के बाद बस docker-compose.yml की तरफ point करने जितना आसान था
    कोई change बिल्कुल नहीं चाहिए था, और अब daemon को लगातार चलाए रखने की भी जरूरत नहीं है। शानदार software है

    • Docker Desktop से colima बेहतर था, और colima से Orbstack बेहतर था। फिर https://smolmachines.com's smolvm microVM मिला
    • Docker की AI वाली बकवास की वजह से आखिरकार हद पार हो गई और Podman पर switch करने की कोशिश की, लेकिन कुछ compatibility issues मिले। कुछ महीने पहले की बात है, इसलिए details याद नहीं हैं
      फिर Rancher Desktop try किया, और नाम बार-बार भूल जाने के अलावा यह बस ठीक से काम करता था। जिसे चाहिए, उसके लिए एक और simple option है

  • मुझे Quadlet सचमुच बहुत पसंद है। कई सालों तक Hetzner, Ansible, SystemD, RockyLinux के साथ rootless containers बिना समस्या host किए, और उस setup को template repository के रूप में निकाल लिया
    [1] https://github.com/Mati365/hetzner-podman-bunjs-deploy

    • home server को k3s से quadlet पर बदलने के बाद power usage 8% घट गया

  • Docker से Podman पर शिफ्ट करने का अनुभव कैसा रहा, यह जानना चाहता हूं
    homelab/automation सेटअप में compose files बहुत हैं, इसलिए सबसे बड़ी चिंता वही है

    • करीब 15 महीने पहले Docker से Podman पर शिफ्ट हुआ था, और वापस जाने का कोई इरादा नहीं है। निजी तौर पर quadlet, यानी systemd integration, मुझे वाकई बहुत पसंद है; इससे सामान्य systemd services हों या containers, चल रही services के समूहों को monitor करना कहीं आसान हो जाता है
      rootless execution भी बहुत intuitive है, और Podman बहुत fast है। निजी तौर पर मुझे docker compose की ज्यादा कमी महसूस नहीं होती, लेकिन समझता हूं कि docker compose की गैर-मौजूदगी दूसरों के लिए deal-breaker हो सकती है। Podman का compose plugin कभी इस्तेमाल नहीं किया
    • homelab में एक बहुत बड़ी docker compose file को podman quadlet में बदला। याद पड़ता है कि शुरू के कुछ services migrate करते समय compose file की तुलना में quadlet docs और examples ज्यादा नहीं थे, इसलिए थोड़ा समय लगा, लेकिन उसके बाद यह बहुत आसान था। जोरदार सिफारिश करूंगा
      इकलौती समस्या validation है। quadlet files validate करने के लिए कोई सुविधाजनक built-in command नहीं है, और systemd भी generation failure की warning नहीं देता। पहले --dry-run चलाना पड़ता है, या पूरी command का कोई ठीक-ठाक alias बनाना पड़ता है, नहीं तो journal में errors देखने पड़ते हैं
    • कुछ साल पहले, 5.0 से पहले शिफ्ट किया था और फिर पीछे मुड़कर नहीं देखा। compose files के लिए quadlet इस्तेमाल करने पर विचार किया जा सकता है
      तेज conversion के लिए podman-compose सीधे इस्तेमाल कर सकते हैं, या docker compose को Podman socket की ओर point करने के लिए configure कर सकते हैं[0]
      compose files को native quadlet में बदलने वाला podlet[1] भी है। simple या medium complexity वाली compose files को यह ज्यादातर अपने-आप ठीक से handle कर देता है और वे तुरंत चल जाती हैं। इसे library के रूप में बनाकर दूसरे tools को compose files को transparent तरीके से quadlet में convert कराने की भी चर्चा है, इसलिए आगे ऐसे और tools आने की उम्मीद है
      अगर systemd unit files से थोड़ी भी familiarity है, तो खुद Quadlet files लिखना भी मुश्किल नहीं है। ज्यादातर docker run या podman run arguments का quadlet में सीधा mapping होता है, इसलिए YAML के बजाय INI format की आदत हो जाए तो compose file देखकर equivalent quadlet बनाना आसान है
      [0] https://www.redhat.com/en/blog/podman-docker-compose
      [1] https://github.com/containers/podlet
    • 1–2 साल पहले सब कुछ rootless Podman पर शिफ्ट कर दिया था। कुछ containers में पुराने data पढ़ते समय permission issues आए, वजह यह थी कि वे अलग UID से चल रहे थे
      असल में जो समस्या आई, बस यही थी; root-privileged Docker से rootless Docker पर शिफ्ट करने पर भी यही समस्या आती। बिल्कुल पछतावा नहीं है और कभी वापस नहीं जाऊंगा
    • Podman के लिए उतनी ही कृतज्ञता महसूस होती है जितनी git के लिए
      Podman mature और logical लगा। अगर किसी का container su permissions पर निर्भर करता है, तो मैं Podman को नहीं, उस व्यक्ति को दोष दूंगा

  • Podman में जो बात नापसंद है, वह यह कि यह Docker-compatible होने का दिखावा करता है, लेकिन बाद में काट खाने वाले छोटे-छोटे फर्क मौजूद हैं। Docker-based project के users Podman से चलाने की कोशिश करते हैं और आखिर में project के पास आकर शिकायत करते हैं

    • ज्यादातर फर्क socket API, logical behavior या command-line differences से नहीं आए। वे मुख्यतः इस बात से पैदा हुए कि Docker मानकर चलता है कि वह root privileges के साथ चलता है, जबकि Podman by default ऐसा नहीं करता
      इसलिए Podman/Docker incompatibility ठीक करना ज्यादातर उस assumption को handle करना है। जैसे Podman command में कुछ flags जोड़कर container और host के बीच user namespace mapping का तरीका बदलना
    • Mac और Linux पर Podman तीन साल से इस्तेमाल कर रहा हूं, और अफसोस कि यह समस्या हमेशा सच रही है। मैं root cause तक धैर्य से पहुंचकर bug file करने को तैयार हूं, लेकिन बहुत लोगों को यह बस टूटा हुआ लगेगा
      सबसे हाल में Netavark का published ports पर broadcast traffic receive करने वाला behavior Docker से मेल नहीं खा रहा था
    • सही है। इसी वजह से कई साल तक Podman अपनाने से हिचकता रहा। अब लगता है कि इसमें smart ideas हैं, और अगर आप RHEL इस्तेमाल करते हैं तो यह obvious choice है, लेकिन यह बात ज्यादा ईमानदारी से बतानी चाहिए कि इसे अपनाने में adaptation लगेगा
      खासकर जब root-privileged Docker से rootless Podman पर जा रहे हों

  • जानना चाहता हूं कि आजकल Podman कैसा है। macOS पर मैं OrbStack इस्तेमाल कर रहा हूं और यह काफी तेज लगता है। अगर macOS 27 WSL जैसी microVM-based, ज्यादा native और बेहतर performance वाली Linux containers capability जोड़ दे, तो landscape कैसे बदलेगा पता नहीं

    • macOS के बारे में ठीक से नहीं जानता, लेकिन Linux पर मेरे use case में यह seamless fit है। एक बात ध्यान देने की है कि Podman Compose default provider के रूप में docker-compose इस्तेमाल करता है
      podman-compose provider मैंने इस्तेमाल नहीं किया है, और इसका नाम Podman Compose से confusingly थोड़ा अलग है। Podman Compose, docker-compose या podman-compose के ऊपर की higher-level abstraction है। जरूरत हो तो Podman से भी Docker engine के जरिए containers चला सकते हैं
    • मेरा भी यही सवाल और यही situation है। MacOS पर इस्तेमाल किया था, लेकिन पहली ही problem समझने के लिए Redhat forums में काफी अंदर तक जाना पड़ा। OrbStack पर स्विच करना obvious choice था, लेकिन features के लिहाज से clear trade-offs हैं

  • Quadlet और rootless containers, Docker से Podman पर शिफ्ट करने की दो बड़ी वजहें हैं

    • rootless ही कुछ साल पहले Podman पर शिफ्ट होने की वजह था। यह सच में smooth है, और अब अस्पष्ट permission issues या service errors की चिंता नहीं करनी पड़ती

  • Podman अच्छा है, लेकिन वह grey text color क्यों है समझ नहीं आता। दिखने में खराब है और contrast ratio 4.96:1 होने से पढ़ना मुश्किल है, WCAG AAA level तक भी नहीं पहुंचता

  • home server को करीब 2 साल से podman + quadlets पर चला रहा हूं, और release notes में कुछ काम की चीजें दिखीं
    podman quadlet list v5.6.0 में जोड़ा गया था, और quadlet व उसके containers को list करता है
    podman system migrate --migrate-db v5.8.0 में जोड़ा गया flag है। पहले bolt DB deprecation warning देखी थी, लेकिन sqlite पर migrate करने का tool नहीं था; अब है। या फिर podman 6.0.0 पर upgrade करेंगे तो यह automatically handle हो जाएगा

  • Docker नहीं बल्कि CRI runtime के लिए image build करने में Podman इस्तेमाल करने का अनुभव कैसा रहा, यह जानना चाहता हूँ
    अगर Podman से image build करें, तो क्या वह cri-o, Docker और अन्य runtimes पर चल पाएगी?
    docker build के लिए sudo चाहिए होता है, जिससे agent-based workflow में झंझट बढ़ जाता है; इसलिए सोच रहा हूँ कि rootless Podman से image build करूँ या नहीं