ज़्यादा सुरक्षित Docker विकल्प ‘Podman’ की पड़ताल

 (betterstack.com)
6 पॉइंट द्वारा GN⁺ 2024-01-14 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Podman Docker जैसा कंटेनर चलाने का अनुभव देता है, लेकिन daemon के बिना काम करता है, इसलिए security और audit trail के लिहाज़ से अलग पहचान रखता है
  • Docker, Docker daemon-केंद्रित client-server आर्किटेक्चर का उपयोग करता है, जबकि Podman user session में सीधे कंटेनर बनाता है, इसलिए किस user ने चलाया इसकी ट्रैकिंग ज़्यादा स्पष्ट होती है
  • OCI standard का पालन करने के कारण यह Docker Hub की hello-world, caddy, wordpress, mysql:5.7 जैसी images चला सकता है, और कई मामलों में docker कमांड को podman से बदलकर इस्तेमाल किया जा सकता है
  • short image names में Docker की तरह Docker Hub को अपने-आप default नहीं माना जाता, इसलिए पूरा image name, alias, या unqualified-search-registries सेटिंग में से एक चाहिए
  • multi-container configuration को Podman Compose, pods, और Kubernetes manifest से संभाला जा सकता है, लेकिन Docker Swarm जैसी built-in production orchestration इसमें नहीं है, इसलिए Kubernetes जैसे external system का उपयोग करना पड़ता है

Podman और Docker जहाँ अलग होते हैं

  • Podman एक open source container engine है, जिसका लक्ष्य Docker के मुकाबले ज़्यादा सुरक्षित और हल्का विकल्प देना है
  • यह लगातार background में चलने वाले daemon के बिना containers चलाता है, और इसकी संरचना ऐसी है कि user खुद containers को सीधे manage करता है
  • इसकी default security दिशा rootless containers, user namespaces, और kernel capabilities के अधिक सावधानीपूर्ण उपयोग पर केंद्रित है
  • Docker images और command structure के साथ इसकी compatibility काफ़ी अच्छी है, इसलिए Docker का विकल्प खोज रहे developers और system administrators के लिए यह एक व्यावहारिक विकल्प बनता है

आर्किटेक्चर और audit trail

  • Docker client-server model का उपयोग करता है, और container run request Docker client से Docker daemon तक भेजी जाती है
    • container process, user session के child process नहीं बल्कि Docker daemon के child process बनते हैं
    • जब Linux Audit system auditd container process events को detect करता है, तो audit user ID असली user ID की जगह unset के रूप में दिख सकती है
    • इस संरचना में किसी malicious activity को किसी खास user से जोड़ना मुश्किल हो जाता है
  • Podman daemonless architecture का उपयोग करता है
    • हर container सीधे user login session के माध्यम से बनाया जाता है
    • container process data, user information को बनाए रखता है
    • auditd यह सटीक रूप से detect और record कर सकता है कि किस user ID ने किसी खास container process को शुरू किया
  • image के अनुसार Podman का container startup time, Docker से अधिकतम 50% तक तेज़ हो सकता है

container lifecycle management

  • Podman में daemon नहीं होता, इसलिए container lifecycle management का तरीका Docker से अलग है
  • Linux पर यह काफ़ी हद तक Systemd पर निर्भर करता है
    • --restart always flag से तय किए गए containers की restart policy लागू करने के लिए यह podman-restart नाम की systemd service का उपयोग करता है
    • यह service system reboot के बाद तय containers को अपने-आप फिर से शुरू कर देती है
  • यह running container से Systemd service files बनाने का command भी देता है
    • container को systemd management के तहत रखने से start, stop, और monitoring आसान हो जाती है
  • Docker ऐसे काम daemon के भीतर संभालता है

orchestration के विकल्प

  • local development में Docker users आमतौर पर Docker Compose से multi-container applications को define और manage करते हैं
  • Podman, Compose files को default रूप से support नहीं करता, लेकिन Podman Compose को compatible विकल्प के रूप में देता है
    • यह आम तौर पर मौजूदा docker-compose.yml files के साथ काम करता है
    • Docker Compose से परिचित users अपनी existing Compose files का उपयोग जारी रख सकते हैं
  • Podman के native तरीके में pods का उपयोग किया जा सकता है
    • यह Kubernetes से लिया गया concept है
    • इससे कई containers को एक unit की तरह manage किया जा सकता है
  • production deployment में Podman के पास Docker Swarm जैसा built-in orchestration tool नहीं है
    • ऐसे में Kubernetes जैसे external orchestration systems विकल्प बनते हैं
    • Kubernetes, Podman के साथ integrate हो सकता है, लेकिन सही तरह से काम कराने के लिए अतिरिक्त configuration और setup की ज़रूरत पड़ सकती है

default security

  • container security में बड़ा जोखिम तब होता है जब container escape की वजह से host system compromise हो जाए
  • Podman को Docker की तुलना में ज़्यादा मजबूत default security settings देने के लिए डिज़ाइन किया गया है
    • rootless containers
    • user namespaces
    • seccomp profiles
  • Docker में भी rootless containers, user namespaces, और seccomp profiles का उपयोग किया जा सकता है, लेकिन वे default रूप से enabled नहीं होते और अक्सर अतिरिक्त setup की ज़रूरत होती है
  • Podman की default configuration, isolated user namespace के अंदर rootless containers चलाती है, जिससे संभावित escape का असर सीमित होता है
  • Docker की default configuration container processes को root के रूप में चलाती है, इसलिए escape होने पर जोखिम ज़्यादा होता है
  • capability defaults भी अलग हैं
    • Podman default रूप से 11 capabilities के साथ container शुरू करता है
    • Docker ज़्यादा permissive default के साथ 14 capabilities का उपयोग करता है
  • दोनों tools को मजबूत security configuration के साथ सेट किया जा सकता है, लेकिन Podman में उस स्तर तक पहुँचना आम तौर पर कम मेहनत मांगता है

feature comparison में दिखने वाले मुख्य अंतर

  • Podman daemonless architecture और Systemd integration को support करता है
  • यह containers को pods में group कर सकता है और Kubernetes YAML भी संभाल सकता है
  • Docker, Docker Swarm को support करता है, जबकि Podman नहीं करता
  • इसके अलावा अधिकतर features में दोनों को मोटे तौर पर बराबर माना जा सकता है

installation और runtime environment

  • Podman, Docker की तरह प्रमुख operating systems पर चल सकता है
    • macOS
    • Windows
    • प्रमुख Linux distributions
  • महत्वपूर्ण अंतर यह है कि Linux पर यह native रूप से चलता है, लेकिन Windows और macOS पर virtual machine की ज़रूरत होती है
  • उदाहरण Debian-आधारित Linux distributions जैसे Ubuntu, Mint, और Debian को मानकर दिए गए हैं
  • latest Podman install करने के लिए अपेक्षाकृत नया distribution चाहिए
    • लेख लिखे जाने के समय latest major Podman version 4.x था
    • Ubuntu 22.04 LTS, Podman 3.x पर अटका हुआ है
    • उदाहरण Ubuntu 23.10 के आधार पर हैं
  • installation के बाद example output podman version 4.3.1 दिखाता है, और यह पुष्टि करता है कि local machine पर podman command चलाई जा सकती है

Docker images चलाना और OCI compatibility

  • Podman, Docker ecosystem tools से बनी hello-world image चला सकता है
  • यह compatibility इसलिए संभव है क्योंकि Docker और Podman दोनों OCI(Open Container Initiative) standards का पालन करते हैं
    • OCI image format specification और runtime specification को define करता है
    • इससे अलग-अलग container runtimes के बीच interoperability संभव होती है
  • Docker Hub की ज़्यादातर Docker images और containers, Podman में इस्तेमाल किए जा सकते हैं
  • आप मौजूदा workloads को बिना बदलाव Podman पर ले जा सकते हैं या Docker Hub की image library का उपयोग कर सकते हैं
  • hello-world output में “Hello from Docker!” दिखे, तब भी असल में execution Podman ही कर रहा होता है
    • Docker client या Docker daemon execution process में शामिल नहीं होते

short image names को संभालने का तरीका

  • Docker में अगर पूरा image name न दिया जाए तो docker.io यानी Docker Hub को default registry माना जाता है
  • Podman short names के उपयोग को प्रोत्साहित नहीं करता और default registry अपने-आप नहीं मानता
  • hello-world के लिए shortnames.conf में alias मौजूद है, इसलिए यह docker.io/library/hello-world के रूप में resolve हो जाता है
  • caddy जैसी ऐसी image को short name से चलाने पर, जिसका alias नहीं है, यह error आती है
    • Error: short-name "caddy" did not resolve to an alias and no unqualified-search registries are defined in "/etc/containers/registries.conf"
  • इसे ठीक करने के तीन तरीके हैं
    • पूरा image name इस्तेमाल करें, जैसे docker.io/library/caddy
    • registries.conf में [aliases] section जोड़कर "caddy"="docker.io/caddy" जैसा alias define करें
    • unqualified-search-registries=["docker.io"] सेट करें ताकि short names को Docker Hub में खोजा जा सके
  • user-specific settings को $HOME/.config/containers/registries.conf में रखा जा सकता है
    • यह file /etc/containers/registries.conf से higher priority रखती है
    • इसे root permission के बिना configure किया जा सकता है, इसलिए यह rootless approach के साथ बेहतर मेल खाती है
  • अगर Podman को Docker replacement की तरह इस्तेमाल करना है, तो लंबे समय में alias की तुलना में unqualified-search-registries setting ज़्यादा सुविधाजनक होती है

private registries का उपयोग

  • Podman, Docker की तरह private registries का उपयोग कर सकता है
  • Docker Hub account का उपयोग करने वाला example इस flow का पालन करता है
    • Docker Hub में access token बनाना
    • description को Podman tutorial और permissions को Read & Write पर सेट करना
    • private repository बनाना
    • podman login docker.io से login करना
  • अगर docker.io, registries.conf में पहला unqualified-search-registries entry है तो इसे छोड़ा जा सकता है, लेकिन registry को explicitly बताना बेहतर practice है
  • अगर registry न दी जाए, तो podman login यह error देकर fail हो जाता है
    • Error: no registries found in registries.conf, a registry must be provided
  • login के बाद hello-world image को private repository में push किया जा सकता है, फिर local public image हटाकर private repository image से container चलाया जा सकता है
  • valid login credentials न होने पर private image pull करते समय access denied और authentication required errors मिलती हैं
  • private registry उपयोग में मुख्य दृश्य अंतर बस इतना है कि docker की जगह podman लिखा जाता है, और Podman व्यापक रूप से उपयोग होने वाली private registries के साथ काम कर सकता है

Podman Compose से multi-container चलाना

  • जब कई containers को एक unit की तरह चलाना हो, Podman कई विकल्प देता है
    • Podman Compose
    • pods
    • Kubernetes manifests
  • उदाहरण Podman Compose का उपयोग करके WordPress और MySQL चलाता है
  • Podman Compose एक community-driven tool है, जो Compose specification को implement करता है और Podman के साथ integrate होता है
  • यह Python 3 पर निर्भर करता है, और उदाहरण में इसे pipx से install किया गया है
    • example installation output podman-compose 1.0.6 दिखाता है
    • उपयोग किया गया Podman version 4.3.1 है
  • अगर pipx, $HOME/.local/bin में install होता है, तो संभव है कि वह path $PATH में न हो
    • pipx ensurepath से path जोड़ा जा सकता है
    • उसके बाद नया terminal खोलना या shell config file को फिर से load करना होगा

WordPress और MySQL example

  • example में .env file में database user, password, और name define किए जाते हैं, और docker-compose.yml से WordPress और MySQL services configure की जाती हैं
  • podman-compose up -d चलाने पर Podman Compose, docker-compose.yml को parse करता है
  • wordpress service को process करते समय
    • ज़रूरी external volume खोजा जाता है और न मिलने पर बनाया जाता है
    • उपयुक्त network खोजा जाता है और न मिलने पर बनाया जाता है
    • wordpress container चलाया जाता है
    • अगर local image मौजूद न हो, तो configured docker.io registry से wordpress:latest pull किया जाता है
  • db service को process करते समय
    • podman-tutorial_db volume बनाया जाता है
    • मौजूदा network की पुष्टि की जाती है
    • mysql:5.7 container चलाया जाता है
    • अगर local image मौजूद न हो, तो Docker Hub से pull किया जाता है
  • run होने के बाद localhost:8080 पर WordPress installation page देखा जा सकता है
  • podman ps output में wordpress और db containers running दिखते हैं
    • wordpress के लिए port mapping 0.0.0.0:8080->80/tcp होती है
    • db, mysql:5.7 image से चल रहा होता है
  • image list में docker.io/library/wordpress:latest और docker.io/library/mysql:5.7 दिखते हैं
  • network list में default podman network और Podman Compose द्वारा बनाया गया podman-tutorial_default network दिखता है
    • podman-tutorial_default, docker-compose.yml में define containers को उसी system के दूसरे containers से अलग रखने के लिए बनाया जाता है
  • volume list में podman-tutorial_db और podman-tutorial_wordpress दिखते हैं
  • podman-compose down containers को stop और remove करता है, लेकिन network और volumes बने रहते हैं
    • volume हटाने के लिए podman volume rm का उपयोग करें
    • network हटाने के लिए podman network rm का उपयोग करें
  • commands लगभग Docker और Docker Compose जैसी ही हैं, बस docker और docker-compose की जगह podman और podman-compose लिखना होता है

किसे चुनें

  • Podman, container workloads चलाने के लिए Docker का एक व्यावहारिक विकल्प है
  • यह Docker के अधिकतर काम कर सकता है, और इसका फ़ायदा है कि इसे background daemon की ज़रूरत नहीं होती
  • यह कुछ ऐसे features भी देता है जो Docker में नहीं हैं
    • Kubernetes manifest files के साथ काम करना
    • individual containers को pods में organize करना
  • अगर आपको ज़्यादा हल्का और सुरक्षित container management solution चाहिए, तो Podman बेहतर विकल्प हो सकता है
  • अगर आपकी प्राथमिकता मजबूत ecosystem और व्यापक community support है, तो Docker ज़्यादा उपयुक्त हो सकता है
  • आगे और जानने के लिए Podman आधिकारिक वेबसाइट, documentation, और community देखी जा सकती है

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

1 टिप्पणियां

 
GN⁺ 2024-01-14
Hacker News की राय

  • मुझे वह समय अच्छा लगता था जब Podman systemd unit files को support करता था। क्योंकि सिर्फ containers ही नहीं, पूरे pod को भी systemd से auto-start और auto-update किया जा सकता था
    लेकिन उन्होंने वह feature हटा दिया और Quadlet को push करना शुरू कर दिया। single container को unit file से किया जा सकता है, लेकिन pod के लिए Kubernetes cluster definition इस्तेमाल करनी पड़ती है
    ऊपर से Docker के उलट, containers SELinux definitions का पालन करते हैं, इसलिए mapped directories तक access न हो पाने की वजह से कई बार परेशान हुआ
    आखिर Podman चाहता क्या है, समझ नहीं आता। Kubernetes इस्तेमाल करें? logical paths map न करें और सब कुछ dedicated directories में बनाएं?

    • हमारा infrastructure पहले से docker-compose.yml में define था, फिर पता चला कि podman-compose में systemd units generate करने का एक कम documented feature है
      यह feature अब deprecated Podman feature इस्तेमाल नहीं करता, बल्कि unit files सीधे लिखता है, और व्यक्तिगत रूप से मुझे यह पुराने Podman तरीके से कहीं ज्यादा smooth लगा
      feature enable करने के लिए $ podman-compose systemd -a create-unit है, और systemd unit register करने के लिए $ podman-compose systemd -a register, $ systemctl --user enable --now "podman-compose@$PROJECT_NAME" इस्तेमाल करते हैं
      updates $ podman-compose pull के बाद $ systemctl --user restart "podman-compose@$PROJECT_NAME" से handle होते हैं। $PROJECT_NAME आम तौर पर directory का नाम होता है
      अगर देखना चाहें, तो feature का source code यहां है: https://github.com/containers/podman-compose/blob/f6dbce3618...
      मैं अभी भी podman 4.3.1 इस्तेमाल कर रहा हूं, लेकिन बाद के versions में इस तरीके के बंद होने की कोई वजह नहीं दिखती
    • “Docker के उलट, containers SELinux definitions का पालन करते हैं” — यह तो उल्टा Docker का bug है। अगर system SELinux के लिए configured नहीं है, तो इसे बंद कर देना चाहिए
      और podman-generate-systemd जो systemd files बनाता था, वे आखिरकार "podman start containername" चलाने जितनी ही चीज थीं, इसलिए उन्हें खुद लिखना भी आसान है। हालांकि docker-compose जैसी चीजों के उलट, container लगभग black box जैसा होता है
      Quadlet का फायदा यह है कि container definition .container file में declared होती है। पहले podman run command line को हाथ से systemd unit में लिखना पड़ता था; उस लिहाज से Quadlet बड़ा improvement है और docker-compose का विकल्प भी बन सकता है। बेशक इसके अपने pros और cons हैं
    • लंबे समय से fan हूं, लेकिन इस हिस्से से सहमत हूं
      हर बार जब podman generate systemd [...] चलाने की कोशिश करता हूं, तो याद आ जाता है कि यह transition हुआ था
      यह अक्सर नहीं झेलना पड़ता, क्योंकि मैंने इसे ठीक-ठाक तरीके से handle करने वाला अपना Ansible role बना रखा है
      फिर भी Podman के direction खो देने जैसा strong feeling आता है। जब unit file maintenance और relationship design वाली दिशा पहले ही अपना ली है, तो generator इस्तेमाल करने दें। Quadlet हो या यह कि वह बेहतर है—मुझे फर्क नहीं पड़ता
    • अगर SELinux से deal नहीं करना चाहते, तो containers.conf में यह जोड़ दें: [containers] label=false
      अगर Podman का default security level पसंद नहीं है, तो आम तौर पर उसे बंद करने का तरीका होता है
    • हाल ही में NixOS पर shift हुआ, और NixOS containers सहित हर चीज का आधार systemd को मानता है
      यह model बहुत intuitive था, लेकिन Docker Compose पर लागू करने के लिए काफी manual migration चाहिए था
      इसलिए मैंने एक tool बनाया, जो Compose file को NixOS configuration में convert करके उसे native तरीके से interpret और manage करने देता है: https://github.com/aksiksi/compose2nix

  • Podman को Docker से ज्यादा prefer करने की निर्णायक वजह के तौर पर एक फायदा शायद ही कभी बताया जाता है: Docker network settings बिगाड़ देता है
    Docker और KVM virtual machines को bridge के साथ साथ-साथ चलाने की कोशिश करना nightmare है, जबकि Podman default settings के साथ भी कहीं बेहतर fit बैठता है
    VPN भी Docker की वजह से टूटे हैं या Docker को तोड़ चुके हैं। Podman की networking internally कैसे काम करती है, यह मुझे ठीक से नहीं पता, लेकिन कम से कम यह ऐसा design लगता है जो दूसरे कामों में बाधा न डाले। Docker के बारे में मैं यह बिल्कुल नहीं कह सकता

    • मेरे हिसाब से Buildah असली core feature है। यह Docker के साथ भी अच्छी तरह काम कर सकता है, लेकिन Podman वाले tool family के ज्यादा करीब है
      Dockerfile मुझे पूरा कचरा लगता है। existing languages काफी हैं; मुझे “बोर developer” द्वारा DSL या programming language फिर से बनाने से सच में चिढ़ है। खासकर YAML हो तो और भी, हालांकि इस case में ऐसा नहीं है, लेकिन Dockerfile एक बढ़िया example है कि ऐसी चीजें बंद क्यों होनी चाहिए
      bud के बिना Buildah देखें तो वजह साफ दिखती है। use case थोड़ा भी standard path से हटे, तो किसी irritating, अधकच्चे DSL के बजाय Bash, Fish या जो चाहें, इस्तेमाल कर सकते हैं
      ऐसे खराब फैसले पूरे Docker ecosystem में फैले हैं। DCS और उसका हमेशा अधूरा alternative भी उदाहरण हैं। Cosign जैसे established signing protocol इस्तेमाल करने के बजाय, वे एक complex system बनाना चाहते थे जिसे automate करना मुश्किल है और खासकर key rotation मुश्किल है
    • Podman free है। Docker भी free है, लेकिन Docker Desktop के बिना Docker install करना झंझट वाला है
    • मैं अभी भी Docker और KVM virtual machines को bridge के साथ चला रहा हूं, और बिना किसी nightmare के सब ठीक काम करता है। थोड़ा अजीब है

  • अच्छा है कि Podman ज्यादा widely used हो रहा है। बहुत सारे tools यह मानकर बनाए गए हैं कि user sudo docker group add करेगा, इसलिए वे ऐसे security-conscious Docker setup में टूट जाते हैं जहां root access यूं ही नहीं दी जाती

    • serverless और containers जैसा cutting-edge future आखिरकार root के रूप में हर तरह की चीजें चलाने की बुनियाद पर बना है, यह बात हमेशा मजेदार लगती है

  • प्रमाणित RHEL इंजीनियर के तौर पर Podman को मैं कई सालों से इस्तेमाल कर रहा हूँ
    सच कहूँ तो निजी container उपयोग के लिए यह मुझे काफी पसंद है। लेकिन काम पर हम developers को अभी भी Docker ही देते हैं। अब तक developers को docker compose जैसी सरलता वाला कुछ देने का तरीका नहीं था
    container images बनाते समय CI pipelines में buildah भी इस्तेमाल करते हैं, लेकिन developer end-user के नजरिए से docker compose अभी भी हावी है

  • https://www.techrepublic.com/article/how-to-fix-the-docker-a...
    इस समस्या की वजह से मैं लगभग फँस ही गया था

    • Docker default settings और installation भर से ही iptables में बदलाव कर देता है। खासकर जब नई nftables इस्तेमाल करना चाहें, तो यह हमेशा सिरदर्द रहा है
    • Docker के असुरक्षित default choices की वजह से, एक निजी self-hosted GitHub project container में cryptocurrency miner घुस आया, जिसे VPN-only इस्तेमाल के लिए बताया गया था। अब भी चिढ़ होती है
    • networking issues की बात करें तो, nested configuration में network devices के लिए memory कम पड़ जाने की एक बड़ी समस्या थी, जिसके लिए system restart करना पड़ा। वह न होता तो यह एक शानदार lxc alternative होता, अफसोस

  • Red Hat Docker का विकल्प बनाने में निवेश क्यों कर रहा है, यह अभी पूरी तरह समझ नहीं आता, लेकिन नतीजा मुझे सचमुच पसंद है
    Podman Docker के लगभग सारे काम करता है, साथ ही इसमें pod जैसी अतिरिक्त सुविधाएँ हैं, या कई मामलों में तरीका ही बेहतर है, जैसे daemon-less कंटेनर बनाने की प्रक्रिया
    आम डेवलपर के लिए सबसे बड़ी समस्या शायद Docker compose होगी, लेकिन अगर आप सरल compose file इस्तेमाल करते हैं, तो Docker compose spec के साथ compatible रहने की कोशिश करने वाली podman-compose script मौजूद है
    docker-compose के backend के रूप में Podman इस्तेमाल करने का तरीका भी है [1]. कुल मिलाकर 2024 में Linux machine पर Docker इस्तेमाल करने की कोई वजह नहीं दिखती। macOS या Windows पर Podman कैसा है, यह ठीक से नहीं जानता
    [1] https://www.redhat.com/sysadmin/podman-docker-compose

    • Red Hat ने मूल रूप से Docker के साथ मिलकर पहले सामने आई कई समस्याएँ, जैसे कुछ use cases में systemd compatibility की दिक्कत, ठीक करने की कोशिश की थी, लेकिन खास सफलता नहीं मिली
      इसमें यह भी जोड़ दें कि Docker में पहले भी और अब भी security issues असामान्य रूप से ज्यादा हैं, और Docker-style containers और images डेवलपर्स के बीच बेहद व्यापक रूप से इस्तेमाल होते हैं, तो RHEL की value और approach से ज्यादा मेल खाने वाला अपना implementation बनाना लगभग मजबूरी था
      उदाहरण के लिए Docker rootless चल सकता है, फिर भी अभी तक इसे default के रूप में इस्तेमाल नहीं करता। hardened environments में docker user group भी, और बिना group के चलाने का तरीका भी, सुरक्षा के लिहाज से कई use cases में स्वीकार करना मुश्किल है
      शुरुआती Docker unprivileged containers को कम-से-कम isolation देने में भी बहुत सुस्त था, और समस्या पता चलने के बाद भी उसे ठीक करने में काफी समय लगा। firewall और network rules, तथा SELinux के साथ interaction का तरीका भी काफी problematic है। security को गंभीरता से लेने वाले dedicated Linux system admins वाली कंपनियों में Docker ban असामान्य नहीं है, इसकी यही वजह है
    • मैं Windows पर Podman इस्तेमाल कर रहा हूँ। Windows पर Docker अंतहीन झुंझलाहट और निराशा की श्रृंखला था
      शुरुआत से ही सभी docs आक्रामक रूप से user-friendly न लगने वाले GUI install की ओर धकेलते हैं। boot पर भारी processes चलाता है, किसी वजह से cloud account signup मांगता है, और फिर यह भी टोकता है कि कथित open-source product को काम में इस्तेमाल नहीं करना चाहिए
      “सिर्फ command-line Docker” install करने वाला unsupported विकल्प बेवजह complex था, और आखिरी बार जब कोशिश की थी तो अधिकांश WSL VMs default state में उसे support भी नहीं करती थीं
      इसके उलट Podman में winget install podman ही काफी है और वह परेशान नहीं करता। container चलाना हो तभी Podman VM start करता हूँ, और जरूरत न होने पर system पहले जैसा चलता रहता है
      compose file से कुछ चलाना हो तो podman-compose है। अजीब configurations शायद न संभाल पाए, लेकिन मेरे use case में यह अच्छा चला
      Podman जो ठीक से नहीं कर पाता, वह बस VS Code integration जैसा है, लेकिन Windows पर Docker को चुपचाप सही चलाने की मेहनत VS Code के कुछ shortcuts खोने से कहीं ज्यादा परेशान करती है, इसलिए यह समस्या नहीं है
      Windows पर containers के default solution के रूप में Podman की सलाह दूँगा। Docker इस्तेमाल करने की वजह बस यह हो सकती है कि कंपनी उसका खर्च दे रही हो, या complex compose setup हो; और ऐसे मामले में शायद Kubernetes पर जाने लायक हो
    • Red Hat के निवेश की वजह यह है कि Docker Linux में काम होने के तरीके से बहुत ज्यादा कटा हुआ है
      यह system को तोड़ने वाले काम करता है, rootless के साथ सालों तक जूझता रहा, और vendor lock-in को भी नज़रअंदाज़ नहीं किया जा सकता
      Podman open है, standards का पालन करता है, और Kubernetes के साथ भी अच्छी तरह fit बैठता है। आसान container market में पहले आ जाने की वजह से ही डेवलपर्स ने Docker पर बेहिसाब मेहनत लगा दी
    • उम्मीद है कि “Linux पर Docker इस्तेमाल करने की कोई वजह नहीं” वाला नजरिया बहुमत की राय न बन जाए। Docker RedHat/IBM नहीं है
      अगर Docker गायब हो जाता है, तो RedHat अपने enterprise agenda को और मजबूत हाथ से आगे बढ़ा सकेगा
      Podman के फायदे भी हैं, लेकिन RedHat द्वारा Docker की हर चीज को replace करने की कोशिश में कुछ हिस्से अच्छे से execute नहीं हुए
      container space में RedHat के approach का इतिहास देखें तो ऐसे कई projects पर समय और मेहनत बर्बाद हुई जिनमें वह contribute करके सुधार कर सकता था
      RedHat ऐसी कंपनी नहीं है जिसका agenda customers के लिए सही काम करना हो, इसलिए बड़े picture में आप क्या चाहते हैं, इस पर सोचना चाहिए
    • मैं macOS पर Podman इस्तेमाल कर रहा हूँ। कुल मिलाकर अनुभव Docker से बेहतर रहा, खासकर पुराने macOS versions के support में
      macOS के लिए Podman की एकमात्र बड़ी कमी यह है कि containers से host network इस्तेमाल नहीं कर सकते। लेकिन containers से host network इस्तेमाल करना चाहने के मामले दुर्लभ हैं
      हालांकि अगर आप container के अंदर network-related experiments करते हुए host जैसा ही hostname और IP address बनाए रखना चाहते हैं, तो इसे ध्यान में रखना चाहिए। फिर भी मैं इस limitation को workaround करके इस्तेमाल कर रहा हूँ

  • security-first approach और decisions अच्छे लगते हैं। default configuration से ही सुरक्षित होना, और docker compose के साथ भी काम करना, मुझे पसंद है
    हालांकि अगर Podman काफी popular हो गया, तो सोचता हूँ कि क्या कभी commands और yml format में अपनी अलग राह पकड़ेगा। अभी यह Docker और Docker compose file format पर निर्भर tool जैसा दिखता है
    काश Podman में Swarm का कोई विकल्प होता। अभी orchestration की कमी के कारण Kubernetes को crutch की तरह इस्तेमाल किया जा रहा है, ऐसा लगता है
    security पर अच्छी तरह सोचने वाली team शायद छोटे scale पर containers को reasonable और simple तरीके से चलाने का तरीका बना सकती है, बिना default से ही unsafe Kubernetes को PhD की तरह गहराई से खंगाले। साथ ही Docker compose format के साथ compatibility भी बनाए रखी जा सकती है

  • मैं मानता/मानती हूँ कि rootless containers और अलग-थलग namespaces अहम security features हैं। लेकिन यह Docker rootless से भी संभव है और जटिल नहीं है। बस वैसे configure करना होता है
    उपलब्ध सभी current best practices लागू करके Mastodon को docker rootless के साथ set up करने पर मैंने एक लेख लिखा था [1]
    Docker इस्तेमाल करते रहने का फायदा यह है कि उसकी accessibility बेहतर है। community और blogs ज्यादा हैं, docker compose configurations व्यापक रूप से मिलते हैं, और आसपास इसे इस्तेमाल करना जानने वाले लोग भी ज्यादा हैं
    अंत में Podman और Docker दोनों host के isolated namespace में processes चलाते हैं
    [1]: https://du.nkel.dev/blog/2023-12-12_mastodon-docker-rootless...

  • कोई गलतफहमी न हो। Podman शानदार है और आजकल मैं Docker की जगह वही इस्तेमाल करता/करती हूँ, लेकिन शुरुआत में इसे Docker का सरल replacement समझकर इस्तेमाल करना शुरू किया और UID/GID mapping, SELinux policies, missing DNS settings वगैरह से काफी झटका लगा
    समस्याएं ठीक करने के लिए system migrate चलाया तो कई बार पूरी configuration बिगड़ गई। security ACLs, ID mapping और labels से जुड़ा इसका अपना अलग तंत्र है
    home folder के अंदर chmod -R चलाएं तो शायद सभी containers बंद हो सकते हैं
    नतीजे से संतुष्ट हूँ, लेकिन यह Docker जैसी “बस चल पड़ने वाली” solution से काफी दूर था। जब से मैंने इस्तेमाल शुरू किया है, तब से शायद यह काफी बेहतर हुआ होगा

    • मैंने इस साल से इस्तेमाल शुरू किया, मकसद कई development environments को isolate करना और npm को पूरी dev machine तक आसानी से access करने से रोकना था
      मेरे हिसाब से यह Docker से आसान था। ऊपर बताई गई स्थिति की तुलना में लगता है अब सुधार हुआ है

  • बड़े परिप्रेक्ष्य में देखें तो Podman पुराने Linux जैसा जरूरी लगता है
    भले ही इसे बहुत कम लोग इस्तेमाल करें, इसकी मौजूदगी ही उससे कहीं बड़े proprietary software भाई-बंधुओं को भयानक चीजें करने से रोकती है
    यहां “पुराने Linux” कहने का मतलब यह नहीं कि Linux कम महत्वपूर्ण हो गया है, बल्कि इसलिए कि अब यह और भी ज्यादा जरूरी और central हो गया है

    • अगर “कहीं बड़े proprietary software भाई-बंधुओं” से मतलब Docker है, तो यह थोड़ा ironic है। क्योंकि RedHat और IBM भी open source क्षेत्र में कई खराब चीजें करते हैं