Podman dhidi ya Docker kwenye VPS: Tofauti Halisi

Tofauti halisi kati ya Podman na Docker

Podman na Docker huendesha images zilezile za OCI (open container initiative) kwenye VPS, kwa hiyo uchaguzi hauhusu programu unazoweza kuendesha. Tofauti iko kwenye model ya michakato. Docker huendesha daemon yenye root inayomiliki kila container, na command ya docker ni client ndogo inayoiomba daemon hiyo ifanye kazi. Podman haina daemon: podman run huanzisha container kama child process ya mchakato wowote ulioiita, chini ya user wako mwenyewe asiye na privileged access.

Kila kitu kingine hutokana na ukweli huo mmoja. Auto-start huwa jukumu la systemd badala ya daemon. Umiliki wa volume hupitishwa kupitia user namespace, kwa hiyo owner unayemwona kwa ls -l kwenye host si owner anayeonekana ndani ya container. Ports zilizo chini ya 1024 hukataa ku-bind hadi ubadilishe setting ya kernel. CLI ya docker (command line interface) huendelea kufanya kazi kupitia wrapper, hadi pale kitu kinapotaka Docker socket.

Hakuna daemon: kinachoendeshwa hasa unapoanzisha container

Kwenye Docker host, pstree -a huonyesha dockerd ikiwa root, containerd kando yake, na containerd-shim-runc-v2 moja kwa kila container inayoendesha. Programu yako ni child ya shim hiyo, na shim ni child ya PID 1. Hakuna kinachounganisha container na shell iliyoianzisha. Ukisimamisha daemon, unapoteza control plane ya kila container kwenye host hiyo. Kwa mipangilio chaguo-msingi ya live-restore ikiwa imezimwa, systemctl restart docker pia huanzisha tena containers zako.

Podman haina process yenye kazi sawia. Unapoanzisha container, unapata process moja ya conmon (container monitor) inayoshikilia process kuu ya container. Process hiyo inamilikiwa na user aliyeendesha 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

ps inapaswa kuorodhesha conmon ikiwa inaendeshwa na login user yako, si root. curl inapaswa kuchapisha 200. Kwa kuwa hakuna service kuu inayomiliki container, sudo apt upgrade podman haisimamishi kitu ambacho tayari kinaendesha. Pia, monitor ya container moja ikicrash, haiwezi kuangusha containers nyingine.

Kutokuwepo kwa daemon kuna gharama pia. Hakuna kinachoanzisha containers zako baada ya reboot. --restart=always ya Docker ni ahadi ambayo daemon hutimiza wakati wa boot. Podman hubadilisha utaratibu huo kwa systemd. Hilo ndilo linaloshughulikiwa na sehemu ya quadlet hapa chini.

Socket ni nusu nyingine ya maelezo haya. /var/run/docker.sock ni endpoint ya API (application programming interface) inayomilikiwa na root. Process yoyote inayoweza kuiandikia inaweza kuanzisha container yenye privileges inayomount filesystem ya host. Kumwongeza user kwenye group ya docker humpa user huyo root kupitia njia isiyo ya moja kwa moja. Ni vizuri kulinganisha jambo hilo na kuipa kila service account access inayohitaji pekee. Podman haifichui socket isipokuwa uiombe. Socket unayopata huwa ya user mmoja kwenye /run/user/<uid>/podman/podman.sock.

Sakinisha Podman kwenye Ubuntu 24.04 na uthibitishe kuwa rootless inafanya kazi kweli

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

Kifurushi cha uidmap hutoa newuidmap na newgidmap. Hizi ni wasaidizi wa setuid wanaomruhusu mtumiaji wa kawaida kudai anuwai ya vitambulisho vya ziada. Bila wasaidizi hawa, containers za rootless hazianzi. podman info inapaswa kuchapisha rootless: true.

Ubuntu 24.04 hutoa Podman 4.9, na Debian 13 hutoa Podman 5.x, kulingana na ukaguzi uliofanywa Agosti 2026. Tofauti hii ni muhimu kwa sababu faili za quadlet zinahitaji 4.4 au mpya zaidi, na faili za .pod quadlet zinahitaji 5.0. Endesha podman --version kabla ya kunakili mfano kutoka kwenye nyaraka za upstream.

Kila mtumiaji wa rootless anahitaji anuwai ya vitambulisho vya ziada:

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

Mtumiaji aliyeundwa na adduser kwenye Ubuntu hupata anuwai hiyo kiotomatiki. Mtumiaji aliyeundwa na useradd -M au na zana ya usanidi mara nyingi haipati. Hitilafu huonyesha hali hiyo:

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

Weka anuwai, kisha weka upya storage ya mtumiaji huyo ili utumiaji wa mapping mpya:

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

Kuna jambo lingine la kushangaza wakati wa matumizi ya kwanza: Podman haichukulii Docker Hub kuwa registry chaguo-msingi. Jina fupi la image hutatuliwa dhidi ya unqualified-search-registries katika /etc/containers/registries.conf. Katika script isiyo na terminal iliyounganishwa, pull hushindwa kwa short-name resolution enforced but cannot prompt without a TTY. Andika jina kamili kila mara. Tumia docker.io/library/nginx:1.27 badala ya nginx.

Faida halisi za rootless containers kwenye seva ya kukodishwa

Rootless container huendesha ndani ya user namespace, kipengele cha kernel kinachopa process ramani yake binafsi ya user IDs. Ndani ya namespace hiyo, superuser wa container ni UID (user ID) 0. Nje yake, kwenye VPS yako, process hiyo ni login user wako wa kawaida. Root ndani ya container si root kwenye host.

Huo ndio ukubwa halisi wa faida. Image inayosisitiza kuendesha kama root, web application yenye hitilafu ya remote code execution, au escape inayotegemea kuwa UID 0 nje ya namespace: hali hizo zote huishia kuwa na permissions za user wako asiye na privileges badala ya permissions za mashine. Rootless haikulindi dhidi ya hitilafu za kernel, wala hailindi files zako mwenyewe, kwa sababu process iliyotoka kwenye isolation inaendesha kama wewe na inaweza kusoma chochote unachoweza kusoma. Unit inayotengwa ni muhimu angalau kwa kiwango sawa na UID mapping. Hili linaonekana kwa urahisi zaidi katika FreeBSD jail, inayofunga userland nzima unayosimamia kama mashine ndogo badala ya layered image inayopakuliwa kutoka kwenye registry.

Docker inaweza pia kuendesha rootless. dockerd-rootless-setuptool.sh install huweka daemon ya kila user, na hufanya kazi vizuri. Tofauti ni mwelekeo wa default. Ukiwa na Podman, rootless unapata bila kuomba, hivyo failure yako ya kwanza huwa container isiyoweza kufunga port 80, badala ya service iliyokuwa ikiendesha kwa utulivu kama root kwa miaka miwili.

Kwa nini faili za volume yangu zinamilikiwa na UID 100999?

Hii inatokana na user namespace hiyo hiyo. Container UID 0 huwekwa kwenye host UID yako. Container UID 1 huwekwa kwenye ID ya kwanza katika range yako ya subuid, kisha huendelea kuhesabu kutoka hapo. Kwa range inayoanza kwenye 100000, container UID 1000 huonekana kwenye host kama 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 huchapisha 1000. Orodha ya host huonyesha owner 100999, kwa sababu 100000 pamoja na 1000 ukitoa 1 ni 100999. Hakuna kitu kilichoharibika, na chown ya kawaida haitarekebisha hili, kwa sababu user wako asiye na privileges hawezi kubadili ownership ya faili nje ya namespace.

Njia nne za kutatua:

• podman unshare chown 1000:1000 "$PWD/data" huendesha chown ndani ya user namespace hiyo hiyo, ambako namba hizo zina maana inayolingana na container.
• -v "$PWD/data:/data:U" huiomba Podman irekebishe ownership ya source directory kwa ajili yako. Itumie kwenye directory mpya, si kwenye data muhimu kwako.
• --userns=keep-id huweka host UID yako kwenye UID hiyo hiyo ndani ya container, kwa hiyo faili mpya zitamilikiwa na wewe.
• Volume yenye jina, kama -v appdata:/data, huepuka swali hili, kwa sababu Podman huiunda ndani ya storage yako yenyewe ikiwa na ownership sahihi.

Ikiwa umewahi kukabiliana na hili katika Docker, ni tatizo hilohilo katika layer moja ya ziada. Variables za PUID na PGID ambazo images nyingi hutoa huweka UID inayotumiwa na process ndani ya container, na katika rootless Podman UID hiyo huwekwa kwenye mapping mara ya pili. PUID=1000 ndani ya rootless container bado huandika faili za host zinazomilikiwa na 100999. Chagua namba ukizingatia mapping hiyo ya pili, au hamishia data kwenye volume yenye jina na uache kulifikiria.

Kuna maelezo mengine mawili kuhusu mounts. Flags za :z na :Z unazoona katika mifano ya Fedora na RHEL ni chaguo za SELinux relabel, na Ubuntu hutumia AppArmor, kwa hiyo flags hizo hazifanyi chochote huko. Rootless Podman pia haiwezi ku-mount host directory ambayo user wako hawezi kuisoma; hiyo ndiyo tabia inayotarajiwa, si hitilafu.

Kwa nini rootless Podman inakataa kuchapisha port 80?

Kwa sababu kuunganisha port iliyo chini ya 1024 kunahitaji privilege ambayo user yako hana. Error inaeleza marekebisho:

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

Majibu mawili yanafanya kazi. Punguza threshold kwa host nzima:

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 ya mwisho inapaswa kuonyesha 80. Elewa wazi kazi ya setting hiyo: kila user kwenye mashine sasa anaweza kuunganisha 80 na 443, si yule anayesimamia containers pekee. Kwenye VPS inayosimamiwa na admin mmoja, hili ni badilishano linalokubalika. Kwenye mashine yenye accounts za watu wengine, halikubaliki. Jibu lingine ni kuchapisha kwenye 8080 na kuweka reverse proxy mbele yake. Hapo ndipo unapotaka certificates zitolewe na zifanyiwe renewal na certbot kwenye nginx hata hivyo.

Rootless publishing pia hubadilisha kile application yako inaona. Podman 4.x hutumia slirp4netns pamoja na rootlesskit port handler kwa default. Connections zinazo-forwardiwa hufika zikiwa na source address iliyobadilishwa. Kwa hiyo, access log hurekodi kila mgeni kama 10.0.2.100. Podman 5.0 ilibadilisha default kuwa pasta, ambayo huhifadhi client address halisi. Kwenye 4.x, --network slirp4netns:port_handler=slirp4netns hurejesha source address halisi, lakini hupunguza throughput kwa kiwango fulani.

Kuna jambo moja zuri la kushangaza hapa. Port iliyochapishwa na rootless ni listening socket ya kawaida inayomilikiwa na process ya kawaida. Kwa hiyo, input rules za firewall yako huitumia. Docker huchapisha ports kwa kuandika NAT (network address translation) rules pamoja na forwarding accepts zake. Hii ndiyo sababu port ya Docker iliyochapishwa hupuuza ufw rule uliyodhani inauzuia. Rootful Podman hutumia plumbing inayofanana na hurithi mtego huo. Rootless haifanyi hivyo.

Je, faili zangu za Docker Compose bado zinafanya kazi chini ya Podman?

Kwa kiasi kikubwa, kupitia njia mbili tofauti. Ya kwanza ni podman-compose, utekelezaji tofauti unaosoma faili hiyo hiyo na kuendesha CLI ya Podman:

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

Ya pili ni Docker Compose halisi inayowasiliana na API ya Docker inayooana na Podman kupitia socket ya kila mtumiaji:

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 na podman ps vinapaswa kuorodhesha containers zilezile, kwa sababu kuna seti moja tu ya containers. Utatuzi wa majina pia hufanya kazi: backend ya mtandao ya kawaida ya Podman, netavark, huendesha aardvark-dns, kwa hiyo containers zilizo kwenye mtandao uliobainishwa na mtumiaji hupata nyingine kwa majina.

Kuna mipaka halisi. Kila kitu kinachomount /var/run/docker.sock lazima kielekezwe kwenye socket ya Podman au kiondolewe. network_mode: host hufanya kazi kwa njia tofauti ndani ya user namespace. depends_on pamoja na condition: service_healthy inaungwa mkono kwa viwango tofauti katika matoleo ya podman-compose. restart: always haiendelei kufanya kazi baada ya reboot bila usanidi wa ziada, ambao sehemu inayofuata inarekebisha. Compose bado ni njia nzuri ya kueleza stack yenye containers nyingi katika faili moja, na chini ya Podman hufanya kazi kama safu ya utafsiri. Kwa stack unayokusudia kuitunza kwa miaka mingi, ibadilishe kuwa quadlets na udumishe abstraction moja badala ya mbili.

Pods: dhana ambayo Docker haina jibu lake

Pod ni kikundi cha containers zinazoshiriki network namespace moja. Podman huanzisha container ndogo ya infra ili kuweka namespace hiyo ikiwa wazi, kisha wanachama hufikiana kupitia 127.0.0.1 bila network iliyobainishwa na mtumiaji na bila 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

podman pod ps inapaswa kuonyesha pod Running yenye containers tatu, ukihesabu infra container. Sasa web container hufikia Redis kupitia 127.0.0.1:6379 badala ya app-cache:6379. Sheria mbili zinafuata kutokana na namespace inayoshirikiwa: publish ports kwenye pod, si kwenye member, na hakuna members wawili wanaoweza kusikiliza port moja.

Huu ndio muundo wa Kubernetes, na Podman umejengwa kuutumia. podman kube generate app > app.yaml huandika Kubernetes manifest kutokana na kinachoendelea (packages za zamani huiandika kama podman generate kube), na podman kube play app.yaml huunda upya muundo huo kwenye host nyingine. Quadlet ina aina ya unit ya .kube inayotumia file hiyo kama service ya systemd. Hii ni njia tofauti kabisa ya kupanga services, na ndiyo sababu kuu ya kuchagua Podman ikiwa Kubernetes iko kwenye mipango yako ya baadaye.

Kujiwasha bila daemon: units za quadlet

Quadlet ni generator ya systemd. Hubadilisha faili fupi inayoeleza container kuwa service halisi ya systemd wakati wa kuwasha mfumo. Faili huwekwa katika ~/.config/containers/systemd/ kwa mtumiaji asiye root, au /etc/containers/systemd/ kwa 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

~/.config/containers/systemd/caddy-data.volume inaweza kuwa tupu karibu kabisa, kwa sababu kichwa cha section ndicho kinachounda volume:

[Volume]

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

Jina la service hutokana na jina la faili: caddy.container huwa caddy.service. Usikimbize systemctl --user enable caddy. Units zinazozalishwa haziwezi kuwezeshwa, na systemd hujibu Failed to enable unit: Unit /run/user/1000/systemd/generator/caddy.service is transient or generated.. Section ya [Install] ndiyo huanzisha container wakati wa kuwasha mfumo, na daemon-reload ndiyo huzalisha upya unit baada ya kuhariri faili.

Sasa kuna setting inayowachanganya karibu wote:

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

Tarajia Linger=yes. Bila linger, systemd hufunga session nzima ya mtumiaji muunganisho wako wa mwisho wa SSH unapofungwa. Kwa hiyo, kila container isiyo ya root husimama pamoja nayo, na hakuna inayorudi wakati wa kuwasha mfumo. Containers zinazotoweka unapotoka kwenye mfumo daima husababishwa na hili.

Kwa kuwa container ndiyo process kuu ya unit ya kawaida ya service, vidhibiti vya systemd hutumika moja kwa moja. MemoryMax= na CPUQuota= katika section ya [Service] hufanya kazi sawa kabisa na zinavyofanya kwa service nyingine yoyote unayowekea mipaka kwa systemd. Hii inahitaji cgroup v2 (control group version 2), ambayo Ubuntu imekuwa ikitumia kwa chaguo-msingi tangu 22.04. Thibitisha kwa podman info | grep -i cgroup.

Updates zina utaratibu unaolingana. AutoUpdate=registry pamoja na systemctl --user enable --now podman-auto-update.timer hukagua registry ili kuona kama kuna image mpya zaidi yenye tag hiyo hiyo, huanzisha upya unit, na kurudisha image ya awali ikiwa container mpya itashindwa kuanza. Kimbiza podman auto-update --dry-run kwanza ili kuona mabadiliko ambayo ingefanya. Amri ya zamani ya podman generate systemd bado ipo lakini imepitwa na wakati, kwa hiyo andika quadlets kwa kila kitu kipya.

Pale ambapo alias ya docker hufanya kazi, na pale ambapo haifanyi kazi

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

podman-docker husakinisha wrapper ya /usr/bin/docker inayoiita Podman. Bila faili ya nodocker, kila wito huanza kwa kuchapisha Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.. Wrapper hii inashughulikia amri unazoandika kila siku: run, ps, logs, exec, build, pull, push, inspect, cp, volume, network.

Kuna orodha fupi zaidi ya mambo ambayo hayahamishwi, na tofauti zake ni kubwa zaidi. Swarm mode haina mbadala, kwa hiyo Swarm stack haina mahali pa kuendeshwa. Zana zinazowasiliana na Docker socket zinahitaji Podman socket itolewe, na baadhi yake bado hutambua tofauti hiyo; Docker provider ya Traefik hufanya kazi inapoelekezwa kwenye /run/user/<uid>/podman/podman.sock, lakini Watchtower haina matumizi hapa, kwa sababu podman auto-update hushughulikia kazi hiyo. Hifadhi ni tofauti, kwa hiyo Podman haiwezi kuona images ambazo tayari ulivuta kwa Docker, na podman images kwenye Docker host yenye shughuli nyingi huanza ikiwa tupu.

Kuhamisha stack inayoendesha, hatua kwa hatua

1. Unda au chagua mtumiaji asiye na privileged access ambaye atamiliki containers, kisha uthibitishe kuwa ana range katika /etc/subuid.
2. Vuta tena kila kitu kilichotoka kwenye registry, ukitumia majina yaliyokamilika kikamilifu. Podman ina image store yake na haitasoma ya Docker.
3. Hamisha images zilizojengwa ndani ya mfumo kwa kutumia docker save app:1.4 | podman load.
4. Simamisha Docker container, nakili yaliyomo kwenye kila volume kutoka /var/lib/docker/volumes/<name>/_data, kisha rekebisha ownership kwa podman unshare chown -R 1000:1000 <path>.
5. Amua kuhusu port: publish port iliyo juu ya 1024 nyuma ya reverse proxy, au weka net.ipv4.ip_unprivileged_port_start.
6. Andika faili moja ya quadlet kwa kila container, endesha systemctl --user daemon-reload, kisha uanzishe kila service.
7. Endesha sudo loginctl enable-linger <user>, reboot VPS, ingia tena, kisha hakikisha podman ps inaorodhesha kila service tena.

Engines hizi mbili hazishirikiani chochote: zina image storage na networks tofauti. Kwa hiyo, unaweza kuziendesha zote mbili wakati wa uhamishaji. Kitu pekee kinachoweza kusababisha mgongano ni nambari ya host port. Hamisha service moja, ifuatilie kwa siku moja, kisha hamisha inayofuata.

Podman dhidi ya Docker: ipi inafaa kwenye VPS yako?

Endelea kutumia Docker ikiwa stack yako iko kwenye compose files ambazo watu wengine pia wanazisimamia, au ikiwa unategemea tooling inayowasiliana na Docker socket. Ulinganifu na vitu ambavyo kila mtu mwingine anaandika ni faida halisi, na Docker ina ulinganifu huo kwa kiwango kikubwa zaidi. Timu ambayo laptops zake zote zinaendesha Docker pia hupata faida ya moja kwa moja kwa kutumia engine hiyo hiyo kwenye production.

Badilisha kwenda Podman ikiwa VPS inaendesha huduma chache unazozidhibiti kutoka mwanzo hadi mwisho, au ikiwa unataka kila programu iwe chini ya unprivileged user wake bila docker group yoyote kwenye host. Ulinganifu na distribution pia ni muhimu: RHEL na rebuilds zake husambaza Podman kama engine inayotumika rasmi, kwa hiyo kwenye mifumo hiyo Podman ndiyo njia yenye mshangao mchache. Ikiwa bado unataka Docker kwenye host hizo, njia ya dnf kwenye Rocky Linux na AlmaLinux huanza kwa kuondoa podman-docker wrapper ambayo tayari inamiliki docker command huko. Ikiwa tayari unasimamia kila kitu kingine kwa systemd units, quadlets zitaonekana kama kipande kilichokosekana kinachowasili, badala ya tool mpya ya kujifunza.

Kuna chaguo moja la kati linalostahili kutajwa. Rootful Podman hufanya kazi kwa namna inayofanana sana na Docker, huhifadhi docker command kupitia wrapper, na bado huondoa daemon inayoendesha muda wote. Pia huacha kutumia rootless, ambayo ndiyo sehemu inayobadilisha hali yako ya usalama, kwa hiyo ichukulie kama hatua ya mpito.

Ikiwa bado unajenga container host yako ya kwanza, njia ya kusanidi na kuimarisha Docker kwenye VPS mpya ndiyo njia fupi zaidi, na maarifa hayo hayatapotea. Images na volumes ni objects zilezile kwenye engines zote mbili, kwa hiyo uhamishaji wa baadaye hubadilisha jinsi huduma zako zinavyosimamiwa, na karibu kila kitu kingine hubaki vilevile.

FAQ

Je, Podman ni mbadala wa moja kwa moja wa Docker?

Kwa amri unazoandika, karibu hivyo. Kusakinisha podman-docker hukupa wrapper ya /usr/bin/docker, na run, ps, build, logs na exec hufanya kazi kwa njia ileile. Si mbadala wa daemon. Swarm haina mbadala unaolingana, zana zinazounganishwa na /var/run/docker.sock lazima zielekezwe kwenye socket ya Podman ya kila mtumiaji badala yake, na images zilizovutwa na Docker hazionekani kwa Podman kwa sababu programu hizi mbili hutumia storage tofauti.

Kwa nini containers zangu za Podman zisizo za root husimama ninapotoka kwenye SSH?

Kwa sababu systemd husimamisha session ya mtumiaji, pamoja na kila service ya mtumiaji, login yako ya mwisho inapofungwa. Tekeleza sudo loginctl enable-linger <user>, kisha hakikisha kuwa loginctl show-user <user> --property=Linger inachapisha Linger=yes. Linger huweka instance ya systemd ya mtumiaji huyo ikiendelea bila session inayotumika. Hilo pia ndilo hufanya containers zianze tena baada ya reboot.

Kwa nini files zilizo kwenye volume yangu zinamilikiwa na UID 100999?

Podman isiyo ya root huweka container UID 0 kwenye mtumiaji wako wa host, kisha huweka container UID 1 na zinazoifuata kwenye subuid range yako. Kwa range inayoanza kwenye 100000, container UID 1000 huwa 100999 kwenye host. Isahihishe kutoka ndani ya namespace kwa podman unshare chown 1000:1000 /path/to/data, fanya mount kwa kutumia flag ya :U wakati wa run ya kwanza, au tumia --userns=keep-id ili container UIDs zilingane na zako.

Je, ninaweza kuendelea kutumia docker-compose.yml na Podman?

Ndiyo, kwa njia mbili. podman-compose husoma file hiyo na kuendesha Podman CLI moja kwa moja. Au wezesha socket ya compatibility kwa systemctl --user enable --now podman.socket, weka DOCKER_HOST=unix:///run/user/$(id -u)/podman/podman.sock, kisha endesha docker compose halisi dhidi yake. Tarajia changamoto kwenye network_mode: host, kwenye services zinazomount Docker socket, na kwenye restart: always, ambayo inahitaji quadlet unit na linger ili iendelee baada ya reboot.

Je, kutotumia root kwa kweli hufanya containers ziwe salama zaidi?

Huondoa hatari moja maalum: process inayotoka kwenye container isiyo ya root hubaki na permissions za mtumiaji wako asiye na privileged access badala ya permissions za root. Hilo ni muhimu, na ndiyo sababu group ya docker yenye uwezo sawa na root haina counterpart chini ya Podman isiyo ya root. Hakuwezi kuzuia vulnerabilities za kernel, wala hakulindi files ambazo mtumiaji wako mwenyewe anaweza kusoma. Kwa hiyo, endelea kutumia hardening nyingine unayofanya kwenye server yoyote.