VPS वर Podman आणि Docker मध्ये नेमका फरक काय?

Podman आणि Docker मध्ये प्रत्यक्षात काय फरक आहे

Podman आणि Docker VPS वर समान OCI (open container initiative) images चालवतात. त्यामुळे कोणते software चालवता येईल, हा निवडीचा मुद्दा नाही. फरक process model मध्ये आहे. Docker प्रत्येक container च्या मालकीचा root daemon चालवतो. docker command हा त्या daemon ला काम करण्याची विनंती करणारा छोटा client आहे. Podman मध्ये daemon नसतो. podman run command container सुरू करते आणि ज्याने ती command चालवली आहे, त्याच्या child process म्हणून container चालतो. तो तुमच्या स्वतःच्या unprivileged user अंतर्गत चालतो.

या एका वस्तुस्थितीमुळे इतर सर्व फरक निर्माण होतात. Auto-start ची जबाबदारी daemon ऐवजी systemd ची असते. Volume ownership user namespace मधून जाते. त्यामुळे host वर ls -l ने दिसणारा owner हा container ला दिसणारा owner नसतो. 1024 पेक्षा कमी port bind करण्यास नकार दिला जातो. त्यासाठी kernel setting बदलावी लागते. docker CLI (command line interface) wrapper मार्फत कार्यरत राहते. मात्र एखाद्या घटकाला Docker socket आवश्यक असेल, तेथे ही सुसंगतता संपते.

डेमन नाही: कंटेनर सुरू केल्यावर प्रत्यक्षात काय चालते

Docker host वर, pstree -a हे dockerd root म्हणून, त्याच्या बाजूला containerd आणि चालू असलेल्या प्रत्येक कंटेनरसाठी एक containerd-shim-runc-v2 दाखवते. तुमचा application त्या shim चा child असतो आणि shim हा PID 1 चा child असतो. कंटेनर सुरू करणाऱ्या shell शी कोणताही संबंध जोडला जात नाही. डेमन थांबवल्यास त्या host वरील सर्व कंटेनरचे control plane गमावता. तसेच, default live-restore setting बंद असल्यास systemctl restart docker तुमचे कंटेनरही restart करते.

Podman मध्ये यासमकक्ष process नसतो. कंटेनर सुरू केल्यावर एक conmon (container monitor) process मिळतो. हा process कंटेनरचा मुख्य process धरून ठेवतो आणि command चालवणाऱ्या user च्या मालकीचा असतो.

podman run -d --name web -p 8080:80 docker.io/library/caddy:2
ps -o user,pid,ppid,args -C conmon
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080

ps ने login user म्हणून, root म्हणून नव्हे, चालणारा conmon दाखवला पाहिजे. तसेच curl ने 200 प्रिंट केले पाहिजे. कोणतीही केंद्रीय service कंटेनरची मालकी घेत नसल्यामुळे, आधीपासून चालू असलेल्या कोणत्याही गोष्टीला sudo apt upgrade podman थांबवत नाही. एका कंटेनरचा monitor crash झाल्यास इतर कंटेनरही त्याच्यासोबत थांबत नाहीत.

डेमन नसल्यामुळे काही अडचणही निर्माण होते. reboot नंतर तुमचे कंटेनर सुरू करणारे काहीही नसते. Docker चे --restart=always हे daemon boot वेळी पाळत असलेले वचन आहे. Podman त्याऐवजी systemd वापरते. खालील quadlet विभाग याच कारणासाठी आहे.

Socket हा या विषयाचा दुसरा भाग आहे. /var/run/docker.sock हा root च्या मालकीचा API (application programming interface) endpoint आहे. त्यावर write करू शकणारी कोणतीही process host filesystem mount करणारा privileged container सुरू करू शकते. एखाद्या user ला docker group मध्ये जोडल्यास त्या user ला root access मिळतो, फक्त अधिक अप्रत्यक्ष मार्गाने. हा मुद्दा प्रत्येक service account ला आवश्यक तेवढाच access देणे यासोबत वाचणे उपयुक्त ठरेल. तुम्ही मागणी केल्याशिवाय Podman कोणताही socket expose करत नाही. मिळणारा socket /run/user/<uid>/podman/podman.sock वरील एका user च्या मालकीचा असतो.

Ubuntu 24.04 वर Podman install करा आणि rootless खरोखर कार्यरत असल्याची खात्री करा

sudo apt update
sudo apt install -y podman uidmap
podman --version
podman info | grep -i rootless

uidmap पॅकेज newuidmap आणि newgidmap उपलब्ध करून देते. हे setuid helpers आहेत. त्यांच्यामुळे सामान्य वापरकर्त्याला subordinate IDs ची श्रेणी वापरता येते. हे helpers नसतील, तर rootless containers सुरू होत नाहीत. podman info ने rootless: true प्रदर्शित केले पाहिजे.

ऑगस्ट 2026 मध्ये तपासल्याप्रमाणे, Ubuntu 24.04 मध्ये Podman 4.9 आणि Debian 13 मध्ये Podman 5.x उपलब्ध आहे. हा फरक महत्त्वाचा आहे. कारण quadlet files साठी 4.4 किंवा त्यानंतरची आवृत्ती आवश्यक आहे, तर .pod quadlet files साठी 5.0 आवश्यक आहे. Upstream documentation मधील उदाहरण copy करण्यापूर्वी podman --version चालवा.

प्रत्येक rootless वापरकर्त्याला subordinate ID range आवश्यक असते:

grep "$USER" /etc/subuid /etc/subgid

Ubuntu वर adduser ने तयार केलेल्या वापरकर्त्याला range आपोआप मिळते. useradd -M ने किंवा configuration tool वापरून तयार केलेल्या वापरकर्त्याला ती अनेकदा मिळत नाही. त्यावेळी error असा दिसतो:

Error: cannot find UID/GID for user deploy: no subuid ranges found for user "deploy" in /etc/subuid - check rootless mode in man pages.

Range assign करा. त्यानंतर नवीन mapping वापरली जाईल यासाठी त्या वापरकर्त्याचे storage reset करा:

sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 deploy
podman system migrate

पहिल्यांदा वापरताना आणखी एक अनपेक्षित बाब येते: Podman Docker Hub गृहीत धरत नाही. Short image name चे resolution /etc/containers/registries.conf मधील unqualified-search-registries विरुद्ध केले जाते. Terminal जोडलेले नसलेल्या script मध्ये pull short-name resolution enforced but cannot prompt without a TTY मुळे अयशस्वी होते. प्रत्येक वेळी पूर्ण नाव लिहा. nginx ऐवजी docker.io/library/nginx:1.27 वापरा.

भाड्याने घेतलेल्या सर्व्हरवर rootless containers मुळे प्रत्यक्षात काय मिळते

rootless container user namespace मध्ये चालतो. ही kernel ची सुविधा process साठी user IDs चा स्वतंत्र नकाशा तयार करते. Namespace च्या आत container मधील superuser हा UID (user ID) 0 असतो. Namespace च्या बाहेर, तुमच्या VPS वर, तोच process तुमचा सामान्य login user असतो. Container मधील root म्हणजे host वरील root नाही.

यातून मिळणारा प्रत्यक्ष फायदा एवढाच आहे. Root म्हणून चालणे आवश्यक मानणारी image, remote code execution bug असलेले web application किंवा बाहेरच्या स्तरावर UID 0 असण्यावर अवलंबून असलेला escape — या सर्व परिस्थितींमध्ये process ला मशीनचे permissions मिळत नाहीत; त्याऐवजी तुमच्या unprivileged user चे permissions मिळतात. मात्र rootless मुळे kernel मधील bugs पासून संरक्षण मिळत नाही. तसेच तुमच्या स्वतःच्या files चे संरक्षणही होत नाही, कारण escape झालेला process तुमच्या user म्हणून चालतो आणि तुम्हाला वाचता येणाऱ्या कोणत्याही file वाचू शकतो.

Docker देखील rootless पद्धतीने चालवता येतो. dockerd-rootless-setuptool.sh install प्रत्येक user साठी daemon सेट करते आणि ती चांगली कार्य करते. फरक default कोणत्या दिशेने आहे यात आहे. Podman मध्ये rootless पद्धत विचारणा न करता मिळते. त्यामुळे तुमचा पहिला failure port 80 bind करू न शकणारा container असतो; दोन वर्षे शांतपणे root म्हणून चालणारी service नसते.

माझ्या volume मधील फाइल्स UID 100999 च्या मालकीच्या का आहेत?

हे त्याच user namespace मुळे होते. Container मधील UID 0 तुमच्या host UID शी मॅप होतो. Container मधील UID 1 तुमच्या subuid range मधील पहिल्या ID शी मॅप होतो आणि त्यानंतर संख्या क्रमाने वाढत जाते. Range 100000 पासून सुरू होत असल्यास, container मधील UID 1000 host वर 100999 म्हणून दिसतो.

mkdir -p "$PWD/data"
podman run --rm --user 1000 -v "$PWD/data:/data" docker.io/library/alpine:3 sh -c 'id -u; touch /data/f'
ls -ln "$PWD/data"

Container 1000 दाखवतो. Host वरील listing मध्ये मालक 100999 दिसतो, कारण 100000 अधिक 1000 वजा 1 म्हणजे 100999. काहीही बिघडलेले नाही. साधा chown हे दुरुस्त करणार नाही, कारण तुमचा unprivileged user namespace च्या बाहेर फाइलची मालकी बदलू शकत नाही.

यातून बाहेर पडण्याचे चार मार्ग आहेत:

• podman unshare chown 1000:1000 "$PWD/data" त्याच user namespace मध्ये chown चालवतो. त्यामुळे संख्यांचा अर्थ container साठी अपेक्षित तोच राहतो.
• -v "$PWD/data:/data:U" Podman ला source directory ची मालकी तुमच्यासाठी दुरुस्त करण्यास सांगतो. हा पर्याय नव्या directory वर वापरा; महत्त्वाचा डेटा असलेल्या directory वर वापरू नका.
• --userns=keep-id तुमचा host UID container मधील त्याच UID शी मॅप करतो. त्यामुळे नव्या फाइल्स तुमच्या मालकीच्या होतात.
• -v appdata:/data सारखा named volume हा प्रश्न टाळतो, कारण Podman तो तुमच्या स्वतःच्या storage मध्ये तयार करतो आणि त्याची मालकी आधीपासून योग्य ठेवतो.

Docker मध्ये तुम्हाला ही समस्या आली असेल, तर हीच समस्या आणखी एका स्तरावर आहे. अनेक images मध्ये उपलब्ध असलेले PUID आणि PGID variables container मधील process कोणता UID वापरेल ते ठरवतात. Rootless Podman मध्ये तो UID पुन्हा एकदा मॅप केला जातो. Rootless container मधील PUID=1000 तरीही host वर 100999 च्या मालकीच्या फाइल्स लिहितो. हे दुसरे mapping लक्षात घेऊन संख्या निवडा किंवा डेटा named volume मध्ये हलवा आणि या समस्येचा विचार करणे थांबवा.

Mounts बाबत आणखी दोन नोंदी. Fedora आणि RHEL उदाहरणांमध्ये दिसणारे :z आणि :Z flags हे SELinux relabel पर्याय आहेत. Ubuntu मध्ये AppArmor वापरले जाते, त्यामुळे तेथे हे flags काहीही करत नाहीत. Rootless Podman तुमचा user वाचू शकत नसलेली host directory mount करू शकत नाही. हे दोष नसून अपेक्षित सुरक्षा वर्तन आहे.

rootless Podman ने port 80 प्रकाशित करण्यास नकार का दिला?

1024 पेक्षा कमी port ला bind करण्यासाठी तुमच्या user कडे नसलेला privilege आवश्यक असतो. Error मध्ये उपाय स्पष्टपणे दिलेला असतो:

Error: rootlessport cannot expose privileged port 80, you can add 'net.ipv4.ip_unprivileged_port_start=80' to /etc/sysctl.conf (currently 1024), or choose a larger port number (>= 1024): listen tcp 0.0.0.0:80: bind: permission denied

दोन्हीपैकी कोणताही एक उपाय वापरता येतो. संपूर्ण host साठी threshold कमी करा:

echo 'net.ipv4.ip_unprivileged_port_start=80' | sudo tee /etc/sysctl.d/99-podman.conf
sudo sysctl --system
sysctl net.ipv4.ip_unprivileged_port_start

शेवटच्या command ने 80 परत echo केले पाहिजे. ही setting नेमके काय करते हे स्पष्टपणे समजा: आता मशीनवरील प्रत्येक user 80 आणि 443 वर bind करू शकतो; केवळ containers चालवणारा userच नाही. Single-admin VPS वर हा स्वीकारार्ह तडजोडीचा पर्याय आहे. इतर लोकांची accounts असलेल्या server वर तो योग्य नाही. दुसरा उपाय म्हणजे 8080 वर publish करणे आणि समोर reverse proxy ठेवणे. Certbot on Nginx कडून certificates जारी आणि renew करायचे असल्यास हाच योग्य पर्याय आहे.

Rootless publishing मुळे तुमच्या application ला दिसणारी माहितीही बदलते. Podman 4.x मध्ये rootlesskit port handler सह slirp4netns हे default असते. Forward केलेल्या connections मध्ये source address बदललेला असतो. त्यामुळे access log मध्ये प्रत्येक visitor 10.0.2.100 म्हणून नोंदवला जातो. Podman 5.0 ने default बदलून pasta केले. यामुळे वास्तविक client address कायम राहतो. 4.x मध्ये --network slirp4netns:port_handler=slirp4netns वापरल्यास true source address पुन्हा मिळतो; मात्र throughput काही प्रमाणात कमी होतो.

यातील एक चांगली बाब अशी आहे की rootless published port हा normal process च्या मालकीचा सामान्य listening socket असतो. त्यामुळे तुमच्या firewall चे input rules त्यावर लागू होतात. Docker ports publish करताना NAT (network address translation) rules आणि स्वतःचे forwarding accepts लिहितो. म्हणूनच तुम्हाला block करणारा ufw rule असूनही published Docker port त्याकडे दुर्लक्ष करतो. Rootful Podman देखील अशाच plumbing चा वापर करतो आणि त्याच समस्येला बळी पडतो. Rootless मध्ये ही समस्या येत नाही.

Podman अंतर्गत माझ्या Docker Compose फाइल्स अजूनही कार्य करतील का?

बहुतेक वेळा, दोन वेगळ्या मार्गांनी. पहिला मार्ग म्हणजे podman-compose. ही स्वतंत्र अंमलबजावणी समान फाइल वाचते आणि Podman CLI वापरते:

sudo apt install -y podman-compose
podman-compose up -d
podman ps

दुसरा मार्ग म्हणजे वास्तविक Docker Compose वापरणे आणि प्रति-वापरकर्ता socket द्वारे Podman च्या Docker-सुसंगत API शी संवाद साधणे:

systemctl --user enable --now podman.socket
export DOCKER_HOST="unix:///run/user/$(id -u)/podman/podman.sock"
docker compose up -d
podman ps

docker compose ps आणि podman ps यांनी समान containers दाखवले पाहिजेत, कारण containers चा एकच संच असतो. नावाचे resolution देखील कार्य करते: Podman चे default network backend, netavark, aardvark-dns चालवते. त्यामुळे user-defined network वरील containers एकमेकांना नावाने शोधू शकतात.

काही मर्यादा प्रत्यक्षात आहेत. /var/run/docker.sock mount करणाऱ्या कोणत्याही घटकाला Podman socket कडे निर्देशित करावे लागते किंवा तो काढून टाकावा लागतो. User namespace अंतर्गत network_mode: host चे वर्तन वेगळे असते. condition: service_healthy सह depends_on ला podman-compose च्या वेगवेगळ्या versions मध्ये असमान support आहे. restart: always स्वतःहून reboot नंतर सुरू राहत नाही; पुढील section मध्ये त्याचे निराकरण केले आहे. एका फाइलमध्ये multi-container stack वर्णन करण्यासाठी Compose अजूनही उपयुक्त आहे, आणि Podman अंतर्गत ते translation layer म्हणून कार्य करते. अनेक वर्षे चालू ठेवायच्या stack साठी तिचे quadlets मध्ये रूपांतर करा आणि दोन abstraction ऐवजी एकच abstraction maintain करा.

पॉड: Docker कडे याचे उत्तर नाही

पॉड म्हणजे एकाच network namespace सामायिक करणाऱ्या containers चा समूह. Podman हा namespace सुरू ठेवण्यासाठी एक लहान infra container सुरू करतो. त्यानंतर सदस्य user-defined network किंवा service discovery शिवाय 127.0.0.1 वर एकमेकांशी संपर्क साधतात.

podman pod create --name app -p 8080:80
podman run -d --pod app --name app-cache docker.io/library/redis:7
podman run -d --pod app --name app-web docker.io/library/nginx:1.27
podman pod ps
podman ps --pod

podman pod ps ने infra container धरून तीन containers असलेला पॉड Running दाखवला पाहिजे. आता web container Redis शी 127.0.0.1:6379 वर संपर्क साधतो, app-cache:6379 वर नाही. सामायिक namespace मधून दोन नियम लागू होतात: ports पॉडवर publish करा, सदस्यावर कधीही करू नका; तसेच कोणतेही दोन सदस्य एकाच port वर listening करू शकत नाहीत.

ही Kubernetes ची पद्धत आहे आणि Podman तिचा पूर्ण वापर करतो. चालू असलेल्या घटकांमधून podman kube generate app > app.yaml Kubernetes manifest तयार करते. जुन्या packages मध्ये याचे नाव podman generate kube असे लिहिलेले आढळते. podman kube play app.yaml तो manifest दुसऱ्या host वर पुन्हा तयार करते. Quadlet मध्ये .kube unit type आहे, जो अशी file systemd service म्हणून चालवतो. Services समूहबद्ध करण्याची ही खरोखर वेगळी पद्धत आहे. Kubernetes तुमच्या भविष्यातील योजनांमध्ये कुठेही असल्यास Podman निवडण्याचे हे सर्वात ठोस कारण आहे.

डेमनशिवाय स्वयंचलित प्रारंभ: quadlet units

Quadlet हा systemd generator आहे. कंटेनरचे वर्णन करणारी छोटी फाइल तो boot वेळी वास्तविक systemd service मध्ये रूपांतरित करतो. Rootless user साठी फाइल्स ~/.config/containers/systemd/ मध्ये, तर root साठी /etc/containers/systemd/ मध्ये ठेवा.

~/.config/containers/systemd/caddy.container:

[Unit]
Description=Caddy web server
After=network-online.target

[Container]
Image=docker.io/library/caddy:2
ContainerName=caddy
PublishPort=8080:80
Volume=caddy-data.volume:/data
Environment=TZ=UTC
AutoUpdate=registry

[Service]
Restart=always
MemoryMax=512M

[Install]
WantedBy=default.target

~/.config/containers/systemd/caddy-data.volume जवळजवळ रिकामे असू शकते, कारण section header मुळेच volume तयार होतो:

[Volume]

systemctl --user daemon-reload
systemctl --user start caddy
systemctl --user status caddy
journalctl --user -u caddy -n 50

Service चे नाव filename वरून येते: caddy.container चे रूपांतर caddy.service मध्ये होते. systemctl --user enable caddy चालवू नका. Generated units enable करता येत नाहीत आणि systemd Failed to enable unit: Unit /run/user/1000/systemd/generator/caddy.service is transient or generated. असे उत्तर देते. [Install] section मुळे boot वेळी container सुरू होतो, तर daemon-reload तुम्ही फाइल संपादित केल्यानंतर unit पुन्हा तयार करतो.

आता जवळजवळ सर्वांनाच अडचणीत आणणारी setting पाहू:

sudo loginctl enable-linger deploy
loginctl show-user deploy --property=Linger

Linger=yes अशी अपेक्षा ठेवा. Linger नसल्यास, तुमचे शेवटचे SSH connection बंद झाल्यावर systemd संपूर्ण user session बंद करते. त्यामुळे सर्व rootless containers देखील थांबतात आणि boot वेळी त्यांपैकी एकही पुन्हा सुरू होत नाही. तुम्ही logout केल्यावर containers नाहीसे होत असतील, तर हेच नेहमी कारण असते.

Container हा सामान्य service unit मधील मुख्य process असल्याने systemd ची स्वतःची controls थेट लागू होतात. [Service] section मधील MemoryMax= आणि CPUQuota= यांचे वर्तन systemd द्वारे नियंत्रित केलेल्या इतर कोणत्याही service प्रमाणेच असते. यासाठी cgroup v2 (control group version 2) आवश्यक आहे. Ubuntu मध्ये 22.04 पासून ते default म्हणून वापरले जाते. podman info | grep -i cgroup वापरून याची पुष्टी करा.

Updates साठी यास अनुरूप mechanism उपलब्ध आहे. AutoUpdate=registry आणि systemctl --user enable --now podman-auto-update.timer एकत्र वापरल्यास त्याच tag साठी registry मध्ये नवीन image आहे का ते तपासले जाते, unit पुन्हा सुरू केला जातो आणि नवीन container सुरू होण्यात अपयशी ठरल्यास मागील image वर rollback केले जाते. कोणते बदल होतील हे आधी पाहण्यासाठी podman auto-update --dry-run चालवा. जुना podman generate systemd command अजूनही उपलब्ध आहे, परंतु तो deprecated आहे. त्यामुळे नवीन कामांसाठी quadlets लिहा.

docker alias कुठे लागू होतो आणि कुठे लागू होत नाही

sudo apt install -y podman-docker
sudo touch /etc/containers/nodocker
docker ps

podman-docker एक /usr/bin/docker wrapper install करतो. हा wrapper Podman ला call करतो. nodocker file नसल्यास, प्रत्येक call आधी Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg. प्रिंट करतो. हा wrapper तुम्ही दिवसभर वापरत असलेल्या commands साठी लागू होतो: run, ps, logs, exec, build, pull, push, inspect, cp, volume, network.

जे लागू होत नाही त्याची यादी लहान आहे, पण महत्त्वाची आहे. Swarm mode ला समतुल्य पर्याय नाही. त्यामुळे Swarm stack चालवण्यासाठी Podman मध्ये स्थान नाही. Docker socket शी संवाद साधणाऱ्या tools साठी Podman socket export करावा लागतो. तरीही काही tools मधील फरक लक्षात येतो. Traefik चा Docker provider /run/user/<uid>/podman/podman.sock कडे निर्देश केल्यास कार्य करतो. Watchtower साठी मात्र कोणतीही जागा नाही, कारण ते काम podman auto-update करतो. Storage स्वतंत्र असल्यामुळे Docker ने आधी pull केलेल्या images Podman ला दिसत नाहीत. तसेच व्यस्त Docker host वरील podman images सुरुवातीला रिकामा असतो.

चालू stack टप्प्याटप्प्याने स्थलांतरित करणे

1. containers चे मालक असणारा unprivileged user तयार करा किंवा निवडा आणि /etc/subuid मध्ये त्याच्यासाठी range आहे याची खात्री करा.
2. registry मधून आलेल्या सर्व गोष्टी fully qualified names वापरून पुन्हा pull करा. Podman चे स्वतःचे image store असते; ते Docker चे image store वाचत नाही.
3. स्थानिक पातळीवर तयार केलेल्या images docker save app:1.4 | podman load वापरून स्थलांतरित करा.
4. Docker container थांबवा, प्रत्येक volume मधील सामग्री /var/lib/docker/volumes/<name>/_data मधून बाहेर copy करा आणि नंतर podman unshare chown -R 1000:1000 <path> वापरून ownership दुरुस्त करा.
5. पोर्टचा निर्णय घ्या: reverse proxy मागे 1024 पेक्षा मोठा पोर्ट publish करा किंवा net.ipv4.ip_unprivileged_port_start सेट करा.
6. प्रत्येक container साठी एक quadlet file लिहा, systemctl --user daemon-reload चालवा आणि प्रत्येक service सुरू करा.
7. sudo loginctl enable-linger <user> चालवा, VPS reboot करा, पुन्हा log in करा आणि podman ps मध्ये प्रत्येक service पुन्हा सूचीबद्ध आहे का ते तपासा.

दोन्ही engines मध्ये काहीही सामायिक नसते: image storage आणि networks स्वतंत्र असतात. त्यामुळे migration सुरू असताना दोन्ही engines चालू ठेवता येतात. त्यांच्यात संघर्ष होऊ शकतो तो फक्त host port number वर. एक service स्थलांतरित करा, तिचे एक दिवस निरीक्षण करा आणि नंतर पुढील service स्थलांतरित करा.

Podman विरुद्ध Docker: तुमच्या VPS वर यापैकी कोणते असावे?

तुमचा stack इतर लोकही maintain करत असलेल्या compose files मध्ये असेल किंवा Docker socket शी संवाद साधणाऱ्या tooling वर तुम्ही अवलंबून असाल, तर Docker वापरत राहा. इतर सर्वजण जे लिहितात त्यांच्याशी compatibility असणे हे प्रत्यक्षात एक महत्त्वाचे feature आहे आणि Docker मध्ये ते अधिक आहे. ज्या टीमच्या laptops वर Docker चालतो, त्या टीमला production मध्येही तेच engine चालवल्याचा ठोस लाभ मिळतो.

तुमच्या VPS वर तुम्ही end to end नियंत्रित करत असलेल्या काही services चालत असतील किंवा प्रत्येक application स्वतंत्र unprivileged user अंतर्गत चालवायचे असेल आणि system वर docker group अजिबात ठेवायचा नसेल, तर Podman कडे वळा. Distribution शी सुसंगतताही महत्त्वाची आहे: RHEL आणि त्याच्या rebuilds मध्ये समर्थित engine म्हणून Podman उपलब्ध करून दिले जाते. त्यामुळे त्या systems वर कमी अनपेक्षित अडचणींचा मार्ग Podman हा आहे. इतर सर्व गोष्टी तुम्ही systemd units ने supervise करत असाल, तर quadlets हे शिकायचे नवे tool न वाटता राहिलेला भाग मिळाल्यासारखे वाटतील.

एका मधल्या पर्यायाचा उल्लेख करणे योग्य ठरेल. Rootful Podman Docker प्रमाणेच काम करते, wrapper द्वारे docker command उपलब्ध ठेवते आणि सतत चालणाऱ्या daemon ची गरज दूर करते. मात्र यात rootless भाग नसतो. तुमच्या security position मध्ये बदल घडवणारा हा मुख्य भाग आहे. त्यामुळे Rootful Podman कडे संक्रमणातील एक टप्पा म्हणून पाहा.

तुम्ही अजून तुमचा पहिला container host तयार करत असाल, तर नवीन VPS वरील Docker setup आणि hardening चा मार्ग अधिक थोडक्यात पूर्ण होतो. त्या मार्गातून मिळालेले ज्ञान वाया जाणार नाही. दोन्ही engines अंतर्गत images आणि volumes हीच objects असतात. त्यामुळे नंतरचे migration तुमच्या services कशा supervise केल्या जातात यात बदल करते; इतर बहुतांश गोष्टी तशाच राहतात.

FAQ

Podman हे Docker चे drop-in replacement आहे का?

तुम्ही टाइप करत असलेल्या commands च्या दृष्टीने ते जवळपास तसेच आहे. podman-docker स्थापित केल्यावर /usr/bin/docker wrapper मिळतो आणि run, ps, build, logs आणि exec त्याच प्रकारे कार्य करतात. मात्र, ते daemon चे replacement नाही. Swarm साठी समतुल्य पर्याय नाही. /var/run/docker.sock शी जोडणाऱ्या tools ना त्याऐवजी प्रति-वापरकर्ता Podman socket कडे निर्देशित करावे लागते. तसेच Docker ने pull केलेल्या images Podman ला दिसत नाहीत, कारण दोन्ही स्वतंत्र storage ठेवतात.

SSH मधून logout केल्यावर माझे rootless Podman containers का थांबतात?

तुमचे शेवटचे login बंद झाल्यावर systemd user session आणि त्यासोबतची प्रत्येक user service थांबवते. sudo loginctl enable-linger <user> चालवा. त्यानंतर loginctl show-user <user> --property=Linger चा output Linger=yes आहे का ते तपासा. Linger मुळे सक्रिय session नसतानाही त्या user चे systemd instance चालू राहते. त्यामुळे reboot नंतर containers पुन्हा सुरू होतात.

माझ्या volume मधील files ची मालकी UID 100999 कडे का आहे?

Rootless Podman container मधील UID 0 ला तुमच्या host user शी map करते. त्यानंतर container मधील UID 1 आणि त्यापुढील UID तुमच्या subuid range वर map होतात. 100000 पासून सुरू होणाऱ्या range मध्ये container UID 1000 हा host वर 100999 होतो. podman unshare chown 1000:1000 /path/to/data वापरून namespace च्या आतून ते दुरुस्त करा. पहिल्या run वेळी mount साठी :U flag वापरा. किंवा --userns=keep-id वापरा, ज्यामुळे container UIDs तुमच्या स्वतःच्या UID शी जुळतात.

Podman सोबत docker-compose.yml वापरणे सुरू ठेवता येईल का?

होय, दोन पद्धती आहेत. podman-compose ही file वाचते आणि Podman CLI थेट चालवते. किंवा systemctl --user enable --now podman.socket वापरून compatibility socket enable करा, DOCKER_HOST=unix:///run/user/$(id -u)/podman/podman.sock सेट करा आणि त्यावर खरे docker compose चालवा. network_mode: host बाबत, Docker socket mount करणाऱ्या services बाबत आणि restart: always बाबत अडचणी अपेक्षित आहेत. reboot नंतर टिकून राहण्यासाठी त्याला quadlet unit आणि linger आवश्यक असतात.

Rootless मुळे containers खरोखर अधिक सुरक्षित होतात का?

यामुळे एक विशिष्ट धोका कमी होतो: rootless container मधून बाहेर पडणाऱ्या process कडे root चे permissions नसतात; त्याऐवजी तुमच्या unprivileged user चे permissions असतात. हा फरक महत्त्वाचा आहे. म्हणूनच root-समान docker group ला rootless Podman मध्ये समतुल्य पर्याय नाही. मात्र, यामुळे kernel vulnerabilities थांबत नाहीत. तसेच तुमचा स्वतःचा user वाचू शकतो अशा files चे संरक्षण होत नाही. त्यामुळे कोणत्याही server वर कराल ते इतर hardening उपाय येथेही सुरू ठेवा.