Podman vs Docker sa VPS: Ano ang Tunay na Pagkakaiba

Ano ang aktuwal na pinagkaiba ng Podman at Docker

Parehong nagpapatakbo ang Podman at Docker ng mga OCI (open container initiative) image sa isang VPS, kaya hindi ang pagpili kung aling software ang maaari mong patakbuhin ang pangunahing isyu. Ang pinagkaiba ay nasa process model. Nagpapatakbo ang Docker ng root daemon na nagmamay-ari ng lahat ng container, at ang docker command ay isang maliit na client na humihiling sa daemon na gawin ang trabaho. Walang daemon ang Podman: sinisimulan ng podman run ang container bilang child process ng anumang tumawag dito, gamit ang sarili mong unprivileged user.

Ang lahat ng iba pang pagkakaiba ay nagmumula sa isang katotohanang ito. Ang auto-start ay nagiging tungkulin ng systemd sa halip na ng daemon. Dumadaan ang ownership ng volume sa isang user namespace, kaya hindi pareho ang owner na nakikita mo gamit ang ls -l sa host at ang owner na nakikita ng container. Hindi makakapag-bind ang mga port na mas mababa sa 1024 hangga't hindi mo binabago ang isang kernel setting. Patuloy na gumagana ang docker CLI (command line interface) sa pamamagitan ng isang wrapper, hanggang sa may kailangang gumamit ng Docker socket.

Walang daemon: ano talaga ang tumatakbo kapag nag-start ka ng container

Sa isang Docker host, ipinapakita ng pstree -a ang dockerd bilang root, ang containerd sa tabi nito, at isang containerd-shim-runc-v2 para sa bawat tumatakbong container. Child ng shim na iyon ang application mo, at child naman ng PID 1 ang shim. Walang nagkokonekta sa container sa shell na nag-start dito. Kapag itinigil mo ang daemon, mawawala sa iyo ang control plane ng lahat ng container sa server. Kapag naka-off ang default na setting na live-restore, ire-restart din ng systemctl restart docker ang mga container mo.

Walang katumbas na process ang Podman. Kapag nag-start ka ng container, isang conmon (container monitor) process ang makukuha mo. Hawak nito ang main process ng container, at pagmamay-ari ito ng user na nagpatakbo ng command.

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

Dapat ilista ng ps ang conmon na tumatakbo bilang iyong login user, hindi bilang root. Dapat ding i-print ng curl ang 200. Dahil walang central service na nagmamay-ari sa container, walang ihihinto ang sudo apt upgrade podman sa mga tumatakbo na. Kung mag-crash ang monitor ng isang container, hindi nito isasama sa paghinto ang iba pang container.

May kapalit din ang kawalan ng daemon. Walang mag-start ng mga container mo pagkatapos ng reboot. Ang --restart=always ng Docker ay isang garantiya na tinutupad ng daemon sa boot. Sa Podman, systemd ang kapalit nito. Para rito ang quadlet section sa ibaba.

Ang socket ang isa pang bahagi ng usapin. Ang /var/run/docker.sock ay isang root-owned API (application programming interface) endpoint. Anumang process na may kakayahang magsulat dito ay maaaring mag-start ng privileged container na nagmo-mount sa filesystem ng host. Kapag nagdagdag ka ng user sa docker group, binibigyan mo ang user na iyon ng root access sa mas hindi direktang paraan. Mainam itong basahin kasabay ng pagbibigay sa bawat service account ng access na kailangan lamang nito. Walang socket na inilalantad ang Podman maliban kung hihilingin mo ito. Ang socket na makukuha mo ay pagmamay-ari ng isang user sa /run/user/<uid>/podman/podman.sock.

Mag-install ng Podman sa Ubuntu 24.04 at tiyaking tunay na rootless

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

Ang package na uidmap ay nagbibigay ng newuidmap at newgidmap. Ito ang mga setuid helper na nagpapahintulot sa ordinaryong user na gumamit ng isang range ng subordinate ID. Kung wala ang mga ito, hindi nagsisimula ang rootless container. Dapat mag-print ang podman info ng rootless: true.

Ang Ubuntu 24.04 ay naglalabas ng Podman 4.9, at ang Debian 13 ay naglalabas ng Podman 5.x, ayon sa pagsusuri noong August 2026. Mahalaga ang pagkakaibang ito dahil kailangan ng quadlet file ang 4.4 o mas bago, habang kailangan ng .pod quadlet file ang 5.0. Patakbuhin ang podman --version bago kumopya ng halimbawa mula sa upstream documentation.

Kailangan ng bawat rootless user ng subordinate ID range:

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

Awtomatikong nakakatanggap ng range ang user na ginawa gamit ang adduser sa Ubuntu. Kadalasan, walang range ang user na ginawa gamit ang useradd -M o ng isang configuration tool. Ganito ipinapakita ng error ang problema:

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

Magtalaga ng range, pagkatapos ay i-reset ang storage ng user na iyon para magamit ang bagong mapping:

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

May isa pang karaniwang sorpresa sa unang pagtakbo: hindi awtomatikong ginagamit ng Podman ang Docker Hub. Nire-resolve ang maikling image name laban sa unqualified-search-registries sa /etc/containers/registries.conf, at kapag walang nakakabit na terminal sa script, nabibigo ang pull na may short-name resolution enforced but cannot prompt without a TTY. Isulat palagi ang buong pangalan. Gamitin ang docker.io/library/nginx:1.27 sa halip na nginx.

Ano talaga ang pakinabang ng rootless containers sa rented server

Tumatakbo ang rootless container sa loob ng user namespace, isang feature ng kernel na nagbibigay sa isang process ng sarili nitong pribadong mapa ng user IDs. Sa loob ng namespace, ang superuser ng container ay UID (user ID) 0. Sa labas nito, sa iyong VPS, ang parehong process ay iyong ordinaryong login user. Ang root sa container ay hindi root sa host.

Iyan ang tunay na saklaw ng benepisyo. Kung kailangan ng isang image na tumakbo bilang root, may remote code execution bug ang isang web application, o may escape na nakadepende sa pagiging UID 0 sa labas ng namespace, mapupunta ang mga ito sa permissions ng iyong unprivileged user sa halip na sa permissions ng machine. Hindi ka pinoprotektahan ng rootless laban sa mga bug sa kernel. Hindi rin nito pinoprotektahan ang sarili mong mga file, dahil ang naka-escape na process ay tumatakbo bilang ikaw at mababasa nito ang anumang nababasa mo. Mahalaga ang unit na naka-isolate, hindi lamang ang UID mapping. Mas madaling makita ito sa katabing halimbawa ng FreeBSD jail, na nagbabalot sa isang buong userland na pinamamahalaan mo gaya ng isang maliit na machine kaysa sa isang layered image na kinukuha mula sa registry.

Maaari ring patakbuhin ang Docker bilang rootless. dockerd-rootless-setuptool.sh install Nagtatakda ito ng per-user daemon at maayos itong gumagana. Ang kaibahan ay kung saan nakatuon ang default. Sa Podman, rootless agad ang gamit nang hindi mo kailangang humiling nito. Kaya ang una mong failure ay isang container na hindi makapag-bind sa port 80, sa halip na isang service na tahimik na tumakbo bilang root sa loob ng dalawang taon.

Bakit pagmamay-ari ng UID 100999 ang aking mga volume file?

Dahil ito sa parehong user namespace. Ang container UID 0 ay naka-map sa iyong host UID. Ang container UID 1 ay naka-map sa unang ID sa iyong subuid range, at pataas ang bilang mula roon. Kung nagsisimula ang range sa 100000, ang container UID 1000 ay nagiging 100999 sa host.

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"

Nagpi-print ang container ng 1000. Nagpi-print ang host listing ng owner na 100999, dahil ang 100000 plus 1000 minus 1 ay 100999. Walang sira, at hindi ito maaayos ng karaniwang chown, dahil hindi maaaring baguhin ng iyong unprivileged user ang file ownership sa labas ng namespace.

May apat na paraan para malutas ito:

• Isinasagawa ng podman unshare chown 1000:1000 "$PWD/data" ang chown sa loob ng parehong user namespace, kung saan ang mga numero ay may kahulugang ginagamit ng container.
• Hinihiling ng -v "$PWD/data:/data:U" sa Podman na itama ang ownership ng source directory para sa iyo. Gamitin ito sa bagong directory, hindi sa data na mahalaga sa iyo.
• Iina-map ng --userns=keep-id ang iyong host UID sa parehong UID sa loob ng container, kaya ang mga bagong file ay pagmamay-ari mo.
• Iniiwasan ng named volume gaya ng -v appdata:/data ang isyung ito, dahil ginagawa ito ng Podman sa sarili nitong storage na tama na ang ownership.

Kung naranasan mo na ito sa Docker, pareho itong problema pero nasa isang layer pataas. Ang mga PUID at PGID variable na inilalantad ng maraming image ang nagtatakda sa UID na ginagamit ng proseso sa loob ng container, at sa rootless Podman, mina-map muli ang UID na iyon. Ang PUID=1000 sa loob ng rootless container ay sumusulat pa rin ng mga host file na pagmamay-ari ng 100999. Isaalang-alang ang ikalawang mapping kapag pumipili ng mga numero, o ilipat ang data sa named volume para hindi mo na kailangang isipin ito.

May dalawa pang dapat tandaan tungkol sa mounts. Ang :z at :Z flags na makikita sa mga halimbawa para sa Fedora at RHEL ay mga SELinux relabel option, at AppArmor ang ginagamit ng Ubuntu, kaya wala itong ginagawa roon. Hindi rin maaaring mag-mount ang Rootless Podman ng host directory na hindi mabasa ng iyong user. Ito ang inaasahang behavior, hindi isang error.

Bakit tumatangging mag-publish ng port 80 ang rootless Podman?

Dahil kailangan ng pag-bind sa port na mas mababa sa 1024 ng privilege na wala sa iyong user. Tinutukoy ng error ang dapat ayusin:

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

May dalawang gumaganang paraan. Ibaba ang threshold para sa buong host:

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

Dapat i-echo ng huling command ang 80. Malinaw dapat kung ano ang ginagawa ng setting na ito: maaari nang mag-bind ang bawat user sa machine sa 80 at 443, hindi lang ang user na nagpapatakbo ng mga container. Sa isang VPS na iisang administrator lang ang gumagamit, katanggap-tanggap ang trade-off na ito. Sa isang server na may mga account ng ibang tao, hindi ito angkop. Ang isa pang paraan ay mag-publish sa 8080 at maglagay ng reverse proxy sa unahan. Doon mo rin gustong mag-issue at mag-renew ng certificates gamit ang certbot sa nginx.

Binabago rin ng rootless publishing ang nakikita ng application. Gumagamit ang Podman 4.x ng slirp4netns bilang default kasama ang rootlesskit port handler. Dumarating ang mga forwarded connection na may binagong source address, kaya itinatala ng access log ang bawat visitor bilang 10.0.2.100. Binago ng Podman 5.0 ang default sa pasta, na nagpapanatili ng tunay na client address. Sa 4.x, ibinabalik ng --network slirp4netns:port_handler=slirp4netns ang tunay na source address kapalit ng kaunting pagbaba sa throughput.

May isang magandang resulta rito. Ang rootless published port ay ordinaryong listening socket na pagmamay-ari ng normal na process, kaya nalalapat dito ang input rules ng firewall. Nagpa-publish ang Docker ng mga port sa pamamagitan ng pagsusulat ng NAT (network address translation) rules at sarili nitong forwarding accepts. Ito mismo ang dahilan kung bakit binabalewala ng published Docker port ang ufw rule na inaakala mong humaharang dito. Gumagamit ng katulad na plumbing ang rootful Podman, kaya mayroon din itong parehong trap. Hindi ito nangyayari sa rootless.

Gumagana pa ba ang aking Docker Compose files sa ilalim ng Podman?

Kadalasan, sa dalawang magkaibang paraan. Ang una ay podman-compose, isang hiwalay na implementation na bumabasa sa parehong file at gumagamit ng Podman CLI:

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

Ang ikalawa ay ang aktuwal na Docker Compose na kumokonekta sa Docker-compatible API ng Podman sa pamamagitan ng per-user socket:

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

Dapat ilista ng docker compose ps at podman ps ang parehong containers, dahil iisa lamang ang set ng mga ito. Gumagana rin ang name resolution: ang default network backend ng Podman na netavark ay nagpapatakbo ng aardvark-dns, kaya nahahanap ng mga container sa user-defined network ang isa't isa gamit ang pangalan.

May ilang aktuwal na limitasyon. Anumang nagmo-mount ng /var/run/docker.sock ay kailangang ituro sa Podman socket o alisin. Iba ang pag-uugali ng network_mode: host sa ilalim ng user namespace. Hindi pantay ang suporta sa depends_on kasama ang condition: service_healthy sa iba't ibang bersyon ng podman-compose. Hindi kusang nagpapatuloy ang restart: always pagkatapos ng reboot; inaayos ito ng susunod na seksyon. Nananatiling mahusay ang Compose para ilarawan ang isang multi-container stack sa iisang file, at sa ilalim ng Podman, nagsisilbi itong translation layer. Para sa stack na balak mong panatilihin nang maraming taon, i-convert ito sa quadlets at mag-maintain ng iisang abstraction sa halip na dalawa.

Mga pod: ang ideyang walang katumbas ang Docker

Ang pod ay pangkat ng mga container na may iisang network namespace. Nagsisimula ang Podman ng maliit na infra container upang manatiling bukas ang namespace na iyon. Pagkatapos, naaabot ng mga miyembro ang isa’t isa sa 127.0.0.1 nang walang user-defined network at walang service discovery.

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

Dapat ipakita ng podman pod ps ang pod Running na may tatlong container, kasama ang infra container. Maaabot na ngayon ng web container ang Redis sa 127.0.0.1:6379 sa halip na sa app-cache:6379. Dalawang panuntunan ang nagmumula sa shared namespace: mag-publish ng mga port sa pod at hindi sa miyembro, at hindi maaaring makinig ang dalawang miyembro sa iisang port.

Ito ang Kubernetes model, at sinusuportahan ito ng Podman. Gumagawa ang podman kube generate app > app.yaml ng Kubernetes manifest mula sa kasalukuyang tumatakbo (sa mas lumang package, podman generate kube ang tawag dito), at ginagawa itong muli ng podman kube play app.yaml sa ibang host. May .kube unit type ang Quadlet na nagpapatakbo ng ganitong file bilang systemd service. Tunay itong ibang paraan ng pagpapangkat ng mga serbisyo, at ito ang pinakamalakas na dahilan para piliin ang Podman kung posibleng gamitin mo ang Kubernetes sa hinaharap.

Awtomatikong pagsisimula nang walang daemon: quadlet units

Ang Quadlet ay isang systemd generator. Ginagawa nitong tunay na systemd service sa oras ng boot ang maikling file na naglalarawan sa isang container. Ilagay ang mga file sa ~/.config/containers/systemd/ para sa rootless user, o sa /etc/containers/systemd/ para sa root.

~/.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

Maaaring halos walang laman ang ~/.config/containers/systemd/caddy-data.volume, dahil ang section header ang lumilikha ng volume:

[Volume]

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

Mula sa filename nagmumula ang pangalan ng service: nagiging caddy.service ang caddy.container. Huwag patakbuhin ang systemctl --user enable caddy. Hindi maaaring i-enable ang mga generated unit, at ibinabalik ng systemd ang Failed to enable unit: Unit /run/user/1000/systemd/generator/caddy.service is transient or generated.. Ang [Install] section ang nagsisimula sa container sa oras ng boot, at ang daemon-reload ang muling nagge-generate ng unit kapag in-edit mo ang file.

Ngayon, ang setting na kadalasang nakaliligtaan ng halos lahat:

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

Asahan ang Linger=yes. Kapag walang linger, winawasak ng systemd ang buong user session kapag isinara ang huli mong SSH connection. Dahil dito, humihinto ang lahat ng rootless container at hindi na muling nagsisimula ang mga ito sa oras ng boot. Ang mga container na nawawala kapag nag-log out ka ay palaging dahil dito.

Dahil ang container ang pangunahing process ng ordinaryong service unit, direktang nalalapat ang mga control ng systemd. Ang MemoryMax= at CPUQuota= sa [Service] section ay gumagana nang eksakto tulad ng sa anumang ibang service na kino-control mo gamit ang systemd. Kailangan nito ang cgroup v2 (control group version 2), na default nang ginagamit ng Ubuntu mula pa noong 22.04. Kumpirmahin gamit ang podman info | grep -i cgroup.

May katumbas na mekanismo para sa updates. Tinitingnan ng AutoUpdate=registry kasama ng systemctl --user enable --now podman-auto-update.timer ang registry para sa mas bagong image na may parehong tag, nire-restart ang unit, at ibinabalik sa dating image kung hindi magsisimulang maayos ang bagong container. Patakbuhin muna ang podman auto-update --dry-run upang makita kung ano ang babaguhin nito. Umiiral pa rin ang mas lumang command na podman generate systemd at deprecated na ito, kaya quadlet ang gamitin para sa anumang bagong configuration.

Kung saan gumagana ang docker alias, at kung saan hindi

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

Nag-i-install ang podman-docker ng /usr/bin/docker wrapper na tumatawag sa Podman. Kung wala ang file na nodocker, unang nagpi-print ang bawat tawag ng Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.. Sinasaklaw ng wrapper ang mga command na madalas mong gamitin: run, ps, logs, exec, build, pull, push, inspect, cp, volume, network.

Mas maikli at mas malinaw ang listahan ng mga hindi naililipat. Walang katumbas ang Swarm mode, kaya walang mapaglalagyan ang Swarm stack. Kailangang i-export ang Podman socket para sa mga tool na kumokonekta sa Docker socket, at napapansin pa rin ng ilan ang pagkakaiba; gumagana ang Docker provider ng Traefik kapag itinuro sa /run/user/<uid>/podman/podman.sock, samantalang walang katumbas ang Watchtower dahil ginagawa na iyon ng podman auto-update. Magkahiwalay ang storage, kaya hindi nakikita ng Podman ang mga image na dati mo nang na-pull gamit ang Docker, at walang laman sa simula ang podman images sa isang abalang Docker host.

Hakbang-hakbang na paglipat ng tumatakbong stack

1. Gumawa o pumili ng unprivileged user na magiging owner ng mga container, at tiyaking mayroon itong range sa /etc/subuid.
2. I-pull muli ang anumang nagmula sa registry gamit ang fully qualified names. May sarili itong image store ang Podman at hindi nito mababasa ang image store ng Docker.
3. Ilipat ang mga image na lokal na binuo gamit ang docker save app:1.4 | podman load.
4. Ihinto ang Docker container, kopyahin ang laman ng bawat volume mula sa /var/lib/docker/volumes/<name>/_data, pagkatapos ay ayusin ang ownership gamit ang podman unshare chown -R 1000:1000 <path>.
5. Ayusin ang usapin sa port: mag-publish sa port na lampas 1024 sa likod ng reverse proxy, o itakda ang net.ipv4.ip_unprivileged_port_start.
6. Sumulat ng tig-iisang quadlet file para sa bawat container, patakbuhin ang systemctl --user daemon-reload, at simulan ang bawat service.
7. Patakbuhin ang sudo loginctl enable-linger <user>, i-reboot ang VPS, mag-login muli, at tingnan kung inililista ulit ng podman ps ang lahat ng service.

Walang pinagsasaluhang anuman ang dalawang engine: magkahiwalay ang image storage at networks ng mga ito. Kaya maaari mong patakbuhin ang dalawa habang isinasagawa ang migration, at host port number lamang ang maaaring pag-awayan ng mga ito. Ilipat ang isang service, i-monitor ito nang isang araw, pagkatapos ay ilipat ang kasunod.

Podman kumpara sa Docker: alin ang para sa iyong VPS?

Manatili sa Docker kung ang stack mo ay nasa compose files na mina-maintain din ng ibang tao, o kung umaasa ka sa tooling na kumokonekta sa Docker socket. Mahalagang feature ang compatibility sa format na ginagamit ng iba, at mas malawak ito sa Docker. Kung Docker ang ginagamit sa lahat ng laptop ng team, may konkretong pakinabang din ang paggamit ng parehong engine sa production.

Lumipat sa Podman kung iilang serbisyo lamang ang tumatakbo sa VPS at ikaw ang kumokontrol sa mga ito mula simula hanggang dulo, o kung gusto mong patakbuhin ang bawat application sa sarili nitong unprivileged user nang walang docker group sa host. Mahalaga rin ang alignment sa distribution: kasama ang Podman sa mga supported engine na nire-release ng RHEL at ng mga rebuild nito. Kaya sa mga system na iyon, mas kaunti ang sorpresa kapag Podman ang ginagamit. Kung gusto mo pa ring gumamit ng Docker sa isa sa mga host na iyon, magsisimula ang dnf route sa Rocky Linux at AlmaLinux sa pag-alis ng podman-docker wrapper na kasalukuyang nagmamay-ari ng docker command doon. Kung systemd units ang ginagamit mo sa pag-supervise ng lahat ng iba pang serbisyo, magiging pamilyar ang quadlets. Para itong nawawalang bahagi na idinagdag, hindi isang bagong tool na kailangan mong aralin.

May isang intermediate na opsyon na dapat banggitin. Ang rootful Podman ay kumikilos nang halos katulad ng Docker, pinananatili ang docker command sa pamamagitan ng wrapper, at inaalis pa rin ang daemon na palaging tumatakbo. Isinusuko rin nito ang rootless na bahagi, na siyang nagbabago sa security position mo, kaya ituring ito bilang pansamantalang hakbang lamang.

Kung binubuo mo pa lang ang una mong container host, mas maikli ang daan sa Docker setup at hardening sa isang bagong VPS, at hindi masasayang ang kaalamang makukuha mo rito. Pareho ang images at volumes bilang mga object sa dalawang engine, kaya kapag lumipat ka sa ibang engine, magbabago ang paraan ng pag-supervise sa mga serbisyo mo at halos wala nang iba.

FAQ

Ang Podman ba ay direktang kapalit ng Docker?

Para sa mga command na tina-type mo, halos ganoon. Kapag nag-install ka ng podman-docker, nagbibigay ito ng /usr/bin/docker wrapper, at pareho ang paggana ng run, ps, build, logs at exec. Hindi ito kapalit ng daemon. Walang katumbas ang Swarm, kailangang ituro sa per-user Podman socket ang mga tool na kumokonekta sa /var/run/docker.sock, at mananatiling hindi nakikita ng Podman ang mga image na hinila ng Docker dahil magkahiwalay ang storage ng dalawang ito.

Bakit humihinto ang aking rootless Podman container kapag nag-log out ako sa SSH?

Dahil pinahihinto ng systemd ang user session, pati ang lahat ng user service nito, kapag nagsara ang huli mong login. Patakbuhin ang sudo loginctl enable-linger <user>, pagkatapos ay tiyaking ang inilalabas ng loginctl show-user <user> --property=Linger ay Linger=yes. Pinananatili ng linger na tumatakbo ang systemd instance ng user na iyon kahit walang aktibong session. Ito rin ang dahilan kung bakit muling nagsisimula ang mga container pagkatapos ng reboot.

Bakit pagmamay-ari ng UID 100999 ang mga file sa aking volume?

Minamapa ng rootless Podman ang container UID 0 sa iyong host user, pagkatapos ay minamapa ang container UID 1 pataas sa iyong subuid range. Kapag nagsisimula ang range sa 100000, nagiging 100999 sa host ang container UID 1000. Ayusin ito mula sa loob ng namespace gamit ang podman unshare chown 1000:1000 /path/to/data, i-mount gamit ang :U flag sa unang run, o gamitin ang --userns=keep-id upang tumugma ang container UID sa sarili mong UID.

Maaari ko bang ipagpatuloy ang paggamit ng docker-compose.yml sa Podman?

Oo, sa dalawang paraan. Binabasa ng podman-compose ang file at direktang ginagamit ang Podman CLI. Maaari mo ring i-enable ang compatibility socket gamit ang systemctl --user enable --now podman.socket, itakda ang DOCKER_HOST=unix:///run/user/$(id -u)/podman/podman.sock, at patakbuhin ang totoong docker compose laban dito. Asahan ang mga limitasyon sa network_mode: host, sa mga service na nagmo-mount ng Docker socket, at sa restart: always, na nangangailangan ng quadlet unit at linger upang manatiling tumatakbo pagkatapos ng reboot.

Talaga bang ginagawang mas secure ng rootless ang mga container?

Inaalis nito ang isang partikular na panganib: kapag nakatakas ang isang process mula sa rootless container, ang permissions na hawak nito ay sa iyong unprivileged user at hindi sa root. Mahalaga ito, at ito ang dahilan kung bakit walang katumbas sa rootless Podman ang root-equivalent na docker group. Hindi nito pinipigilan ang mga kernel vulnerability at hindi nito pinoprotektahan ang mga file na mababasa ng sarili mong user. Kaya ipagpatuloy ang iba pang hardening na gagawin mo sa anumang server.