Podman vs Docker sa VPS: Ano ang Tunay na Pagkakaiba

Ano talaga ang pagkakaiba ng Podman at Docker

Parehong nagpapatakbo ang Podman at Docker ng mga OCI (open container initiative) image sa isang VPS, kaya hindi ang software na maaari mong patakbuhin ang batayan ng pagpili. Ang pagkakaiba ay nasa process model. Nagpapatakbo ang Docker ng root daemon na nagmamay-ari ng bawat 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.

Lahat ng iba pa ay resulta ng iisang katotohanang ito. Nagiging trabaho ng systemd ang auto-start sa halip na ng daemon. Dumadaan ang volume ownership 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 nagbo-bind ang mga port na mas mababa sa 1024 hangga't hindi mo binabago ang kernel setting. Patuloy na gumagana ang docker CLI (command line interface) sa pamamagitan ng isang wrapper, hanggang sa may bahagi na mangailangan ng Docker socket.

Walang daemon: ano talaga ang tumatakbo kapag nagsimula 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 iyong application, at child naman ng PID 1 ang shim. Walang nagkokonekta sa container sa shell na nagsimula rito. Kapag itinigil mo ang daemon, mawawala ang control plane para sa lahat ng container sa host. Kapag naka-off ang default na setting na live-restore, ire-restart din ng systemctl restart docker ang iyong mga container.

Walang katumbas na process ang Podman. Kapag nagsimula ka ng container, makakakuha ka ng isang conmon (container monitor) process na humahawak sa main process ng container. 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 at hindi bilang root. Dapat naman mag-print ang curl ng 200. Dahil walang central service na nagmamay-ari sa container, walang itinitigil ang sudo apt upgrade podman sa mga tumatakbo na. Kung mag-crash ang monitor ng isang container, hindi nito isinasama sa pag-crash ang iba pang container.

May kapalit din ang kawalan ng daemon. Walang awtomatikong magsisimula sa iyong mga container pagkatapos ng reboot. Ang --restart=always ng Docker ay isang pangakong tinutupad ng daemon sa boot. Sa Podman, systemd ang kapalit nito. Iyan ang gamit ng quadlet section sa ibaba.

Ang socket ang kabilang bahagi ng usapin. Ang /var/run/docker.sock ay isang root-owned API (application programming interface) endpoint. Anumang process na maaaring sumulat dito ay maaaring magsimula ng privileged container na nagmo-mount sa filesystem ng host. Kapag nagdagdag ka ng user sa group na docker, binibigyan mo ang user na iyon ng root access sa mas hindi direktang paraan. Basahin ito kasabay ng pagbibigay sa bawat service account ng access na kailangan lamang nito. Walang ine-expose na socket ang Podman maliban kung hihilingin mo ito. At ang socket na makukuha mo ay pagmamay-ari ng iisang user sa /run/user/<uid>/podman/podman.sock.

Mag-install ng Podman sa Ubuntu 24.04 at kumpirmahing totoong 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 isang ordinaryong user na gumamit ng range ng subordinate ID. Kung wala ang mga ito, hindi nagsisimula ang rootless container. Dapat mag-print ang podman info ng rootless: true.

Kasama sa Ubuntu 24.04 ang Podman 4.9, at kasama sa Debian 13 ang Podman 5.x, batay sa pagsusuri noong August 2026. Mahalaga ang pagkakaibang ito dahil nangangailangan ang quadlet file ng 4.4 o mas bago, at nangangailangan ang .pod quadlet file ng 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 nakakakuha ng range ang user na ginawa ng adduser sa Ubuntu. Kadalasang walang range ang user na ginawa ng useradd -M o ng configuration tool, at ipinapakita ito ng 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.

Magtalaga ng range, pagkatapos ay i-reset ang storage ng user 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 paggamit: hindi awtomatikong ipinapalagay ng Podman ang Docker Hub. Nireresolba ang maikling image name gamit ang unqualified-search-registries sa /etc/containers/registries.conf, at kapag walang nakakabit na terminal sa isang 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 napapala mo sa rootless containers sa isang inuupahang server

Tumatakbo ang rootless container sa loob ng user namespace, isang feature ng kernel na nagbibigay sa isang process ng sarili nitong pribadong mapping 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 ang ordinaryong login user mo. Ang root sa container ay hindi root sa host.

Iyan ang tunay na saklaw ng benepisyo. Kung may image na nangangailangang tumakbo bilang root, may web application na may remote code execution bug, o may escape na nakadepende sa pagiging UID 0 sa labas, ang mga iyon ay magkakaroon lamang ng permissions ng unprivileged user mo sa halip na ng buong machine. Hindi ka pinoprotektahan ng rootless laban sa mga bug sa kernel. Hindi rin nito pinoprotektahan ang sarili mong files, dahil ang nakatakas na process ay tumatakbo bilang ikaw at maaaring magbasa ng anumang nababasa mo.

Maaari ring tumakbo ang Docker nang rootless. Ang dockerd-rootless-setuptool.sh install ang nagse-set up ng daemon para sa bawat user, at mahusay itong gumagana. Ang kaibahan ay kung ano ang default. Sa Podman, rootless agad ang gamit nang hindi mo kailangang humiling nito. Kaya ang una mong problema 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 mga volume file ko?

Dahil iyon sa parehong user namespace. Ang container UID 0 ay mina-map sa host UID mo. Ang container UID 1 ay mina-map sa unang ID sa subuid range mo, at pataas ang bilang mula roon. Kapag nagsisimula sa 100000 ang range, 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"

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

May apat na paraan para malutas ito:

• Pinapatakbo 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 awtomatikong itama ang ownership ng source directory. Gamitin ito sa bagong directory, hindi sa data na mahalaga sa iyo.
• Mina-map ng --userns=keep-id ang host UID mo 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 mong storage at tama na agad ang ownership.

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

Dalawa pang paalala tungkol sa mounts. Ang mga flag na :z at :Z na nakikita sa mga halimbawa para sa Fedora at RHEL ay mga SELinux relabel option, at AppArmor naman ang ginagamit ng Ubuntu, kaya wala itong ginagawa roon. Hindi rin maaaring mag-mount ang rootless Podman ng host directory na hindi mabasa ng user mo. Ito ay sadyang security restriction, hindi error.

Bakit tumatanggi ang rootless Podman na i-publish ang port 80?

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 sagot. 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 mag-echo ang huling command ng 80. Linawin kung ano ang ginagawa ng setting na ito: maaari nang mag-bind ang bawat user sa machine sa 80 at 443, hindi lamang ang user na nagpapatakbo ng mga container. Sa isang VPS na iisang administrator lamang ang gumagamit, katanggap-tanggap ang trade-off na ito. Sa isang server na may account ng ibang tao, hindi ito katanggap-tanggap. Ang isa pang sagot ay i-publish ang serbisyo sa 8080 at maglagay ng reverse proxy sa harap nito. Doon mo rin gustong magpa-issue at magpa-renew ng certificates gamit ang certbot sa nginx.

Binabago rin ng rootless publishing ang nakikita ng iyong application. Ginagamit ng Podman 4.x ang slirp4netns bilang default kasama ng 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, ngunit may kapalit itong kaunting pagbaba sa throughput.

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

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

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

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

Ang pangalawa ay ang mismong 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 mga container 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 isang 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 pagkilos ng network_mode: host sa ilalim ng user namespace. Hindi pantay ang suporta sa depends_on na may condition: service_healthy sa iba't ibang bersyon ng podman-compose. Hindi awtomatikong nagpapatuloy ang restart: always pagkatapos ng reboot; aayusin ito ng susunod na seksyon. Nananatiling mahusay na paraan ang Compose upang 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 i-maintain ang isang abstraction sa halip na dalawa.

Mga Pod: ang konseptong walang katumbas sa Docker

Ang pod ay grupo ng mga container na nagbabahagi ng iisang network namespace. Nagsisimula ang Podman ng maliit na infra container upang manatiling bukas ang namespace na iyon, at maaabot ng mga member ang isa’t isa sa 127.0.0.1 nang walang user-defined network at walang kinakailangang 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 na 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 rule ang sinusunod dahil sa shared namespace: mag-publish ng ports sa pod at hindi sa member, at hindi maaaring makinig ang dalawang member sa iisang port.

Ito ang Kubernetes model, at sadyang ginagamit 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 nire-recreate ito 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 paggrupo ng mga serbisyo, at ito ang pinakamalakas na dahilan para piliin ang Podman kung bahagi ng mga plano mo ang Kubernetes.

Auto-start nang walang daemon: quadlet units

Ang Quadlet ay isang systemd generator. Ginagawa nitong totoong systemd service sa boot ang isang maikling file na naglalarawan ng 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

Ang service name ay nagmumula sa filename: ang caddy.container ay nagiging caddy.service. Huwag patakbuhin ang systemctl --user enable caddy. Hindi maaaring i-enable ang generated units, at ang sagot ng systemd ay Failed to enable unit: Unit /run/user/1000/systemd/generator/caddy.service is transient or generated.. Ang [Install] section ang nagsisimula sa container sa boot, at ang daemon-reload ang nagre-regenerate ng unit pagkatapos mong i-edit ang file.

Ngayon, ang setting na halos lahat ay nakakaligtaan:

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

Asahan ang Linger=yes. Kapag walang linger, tinatanggal ng systemd ang buong user session kapag nagsara ang huli mong SSH connection. Dahil dito, tumitigil ang lahat ng rootless container at wala sa mga ito ang bumabalik sa boot. Ang mga container na nawawala kapag nag-logout ka ay laging dahil dito.

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

May katumbas na mechanism para sa updates. Sinusuri 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 nagro-roll back sa dating image kung hindi magsimulang maayos ang bagong container. Patakbuhin muna ang podman auto-update --dry-run para makita kung ano ang babaguhin nito. Umiiral pa rin ang mas lumang command na podman generate systemd at deprecated na ito, kaya quadlets ang gamitin para sa mga 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

podman-docker ang nag-i-install ng /usr/bin/docker wrapper na tumatawag sa Podman. Kung wala ang nodocker file, 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 karaniwan mong tina-type: 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 paglalagyan ang isang Swarm stack. Kailangang i-export ang Podman socket para sa mga tool na kumokonekta sa Docker socket, at may ilan pa ring nakakakita ng pagkakaiba; gumagana ang Docker provider ng Traefik kapag itinuro sa /run/user/<uid>/podman/podman.sock, samantalang wala nang paggagamitan ang Watchtower dahil podman auto-update ang gumagawa ng tungkuling iyon. Magkahiwalay ang storage, kaya hindi makikita ng Podman ang mga image na dati mo nang hinila gamit ang Docker, at nagsisimula sa walang laman ang podman images sa isang Docker host na maraming aktibidad.

Paglipat ng tumatakbong stack, sunod-sunod na hakbang

1. Gumawa o pumili ng unprivileged user na magiging owner ng mga container, at kumpirmahing may range ito sa /etc/subuid.
2. I-pull muli ang anumang nagmula sa registry gamit ang fully qualified names. May sarili nitong image store ang Podman at hindi nito mababasa ang image store ng Docker.
3. Ilipat ang mga locally built image gamit ang docker save app:1.4 | podman load.
4. Ihinto ang Docker container, kopyahin palabas 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 port: mag-publish ng port na lampas 1024 sa likod ng reverse proxy, o i-set ang net.ipv4.ip_unprivileged_port_start.
6. Sumulat ng tig-isang 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-log in muli, at tingnan kung inililista muli ng podman ps ang lahat ng service.

Walang pinaghahatian ang dalawang engine: magkahiwalay ang image storage at network ng mga ito. Kaya maaari mong patakbuhin ang dalawa habang naglilipat, at host port number lamang ang posibleng pag-agawan nila. Ilipat ang isang service, i-monitor ito nang isang araw, saka ilipat ang kasunod.

Podman kumpara sa Docker: alin ang dapat gamitin sa iyong VPS?

Manatili sa Docker kung ang stack mo ay nasa compose files na pinapanatili rin ng ibang tao, o kung umaasa ka sa tooling na kumokonekta sa Docker socket. Tunay na feature ang compatibility sa isinusulat 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 service lang ang tumatakbo sa VPS at ikaw ang kumokontrol sa mga ito mula simula hanggang wakas, o kung gusto mong patakbuhin ang bawat application sa sarili nitong unprivileged user nang walang docker group sa server. Mahalaga rin ang pagkakatugma sa distribution: inilalabas ng RHEL at ng mga rebuild nito ang Podman bilang supported engine, kaya sa mga system na iyon, Podman ang landas na may mas kaunting hindi inaasahang problema. Kung minamanage mo na ang lahat ng iba pang service gamit ang systemd units, magmumukhang kulang na bahagi na sa wakas ay dumating ang quadlets, sa halip na isang bagong tool na kailangan mong pag-aralan.

Mahalagang banggitin ang isang middle option. 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 mo ito bilang pansamantalang hakbang.

Kung ginagawa mo pa lang ang una mong container host, mas maikli ang landas na setup at hardening ng Docker sa bagong VPS, at hindi masasayang ang kaalamang iyon. Pareho ang images at volumes sa dalawang engine, kaya kapag lumipat ka sa hinaharap, magbabago kung paano minamanage ang mga service mo at kakaunti lamang ang iba pang magbabago.

FAQ

Ang Podman ba ay direktang pamalit sa Docker?

Para sa mga command na tina-type mo, halos ganoon. Kapag ini-install ang podman-docker, nagbibigay ito ng /usr/bin/docker wrapper, at pareho ang pagkilos ng run, ps, build, logs at exec. Hindi ito pamalit sa 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 ni-pull ng Docker dahil magkahiwalay ang storage ng dalawang ito.

Bakit humihinto ang aking rootless Podman container kapag nagla-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 nagpi-print ang loginctl show-user <user> --property=Linger ng Linger=yes. Pinananatili ng linger na tumatakbo ang systemd instance ng user na iyon kahit walang aktibong session. Dahil dito, awtomatikong nagsisimulang muli ang mga container pagkatapos ng reboot.

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

Minamapa ng rootless Podman ang container UID 0 sa host user mo, pagkatapos ay minamapa ang container UID 1 pataas sa iyong subuid range. Kung nagsisimula sa 100000 ang range, nagiging 100999 sa host ang container UID 1000. Itama ito mula sa loob ng namespace gamit ang podman unshare chown 1000:1000 /path/to/data, gamitin ang :U flag kapag unang nag-run, o gamitin ang --userns=keep-id upang tumugma ang mga 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 aktuwal na docker compose laban dito. Magkaroon ng 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.

Mas secure ba talaga ang mga container kapag rootless?

Inaalis nito ang isang partikular na panganib: kapag nakatakas ang isang proseso mula sa rootless container, mga permission ng iyong unprivileged user ang hawak nito sa halip na permission ng root. Mahalaga ito, kaya walang katumbas sa rootless Podman ang root-equivalent na grupong docker. Hindi nito pinipigilan ang mga kernel vulnerability at hindi nito pinoprotektahan ang mga file na mababasa ng sarili mong user. Kaya panatilihin ang iba pang hardening na gagawin mo sa anumang server.