Podman vs Docker kwenye VPS: tofauti na utendaji

Tofauti halisi kati ya Podman na Docker

Podman na Docker huendesha images zilezile za OCI (Open Container Initiative) kwenye VPS, kwa hivyo chaguo si kuhusu ni programu ipi unayoweza kuendesha. Tofauti iko kwenye mfumo wa mchakato (process model). Docker huendesha daemon ya root inayomiliki kila container, na amri ya docker ni mteja mdogo anayeiomba daemon hiyo ifanye kazi. Podman haina daemon: podman run huanzisha container kama mchakato mwana (child process) wa chochote kilichoiita, chini ya mtumiaji wako asiye na upendeleo (unprivileged user).

Kila kitu kingine hutokana na ukweli huo mmoja. Kuanza kiotomatiki (auto-start) huwa ni kazi ya systemd badala ya daemon. Umiliki wa volume hupitia user namespace, kwa hivyo mmiliki unayemwona kwa ls -l kwenye host si mmiliki anayeonekana na container. Ports zilizo chini ya 1024 hukataa kufunguka (bind) hadi ubadilishe mpangilio wa kernel. CLI ya docker (command line interface) huendelea kufanya kazi kupitia wrapper, hadi pale ambapo kitu fulani kinahitaji Docker socket.

Hakuna daemon: nini hasa huendeshwa unapoanzisha container

Kwenye host ya Docker, pstree -a huonyesha dockerd kama root, containerd kando yake, na containerd-shim-runc-v2 moja kwa kila container inayofanya kazi. Programu yako ni mtoto wa shim hiyo, na shim hiyo ni mtoto wa PID 1. Hakuna kinachounganisha container na shell iliyoianzisha. Simamisha daemon na utapoteza control plane kwa kila container kwenye mashine hiyo, na kwa mpangilio chaguo-msingi wa live-restore ukiwa umezimwa, systemctl restart docker husimamisha container zako pia.

Podman haina mchakato unaolingana na huu. Anzisha container na utapata mchakato mmoja wa conmon (container monitor) unaoshikilia mchakato mkuu wa container, unaomilikiwa na mtumiaji aliyeendesha amri hiyo.

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 zinazoendeshwa kama mtumiaji wako wa login na si kama root, na curl inapaswa kuchapisha 200. Kwa sababu hakuna huduma kuu inayomiliki container, sudo apt upgrade podman haisimamishi chochote ambacho tayari kinafanya kazi, na monitor ya container moja ikipata hitilafu haiwezi kuathiri nyingine.

Kukosekana kwa daemon kuna gharama zake pia. Hakuna kinachoanzisha container zako baada ya reboot. --restart=always ya Docker ni ahadi ambayo daemon huitekeleza wakati wa boot, na Podman huibadilisha na systemd, ambayo ndiyo kazi ya sehemu ya quadlet hapa chini.

Socket ni nusu nyingine ya hadithi. /var/run/docker.sock ni endpoint ya API (application programming interface) inayomilikiwa na root, na mchakato wowote unaoweza kuandika humo unaweza kuanzisha container yenye upendeleo inayomount filesystem ya host. Kumwongeza mtumiaji kwenye kundi la docker humpa mtumiaji huyo root kupitia njia ya polepole, jambo ambalo linastahili kusomwa kando ya kupa kila akaunti ya huduma ufikiaji unaohitaji pekee. Podman haitoi socket yoyote isipokuwa ukiomba, na socket unayopata ni ya mtumiaji mmoja pekee kwenye /run/user/<uid>/podman/podman.sock.

Sakinisha Podman kwenye Ubuntu 24.04 na uthibitishe rootless inafanya kazi

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

Kifurushi cha uidmap kinatoa newuidmap na newgidmap. Hizi ni setuid helpers zinazoruhusu mtumiaji wa kawaida kudai safu ya subordinate IDs, na bila hizi, containers za rootless hazianzi. podman info inapaswa kuonyesha rootless: true.

Ubuntu 24.04 inakuja na Podman 4.9 na Debian 13 inakuja na Podman 5.x, iliyothibitishwa mnamo Agosti 2026. Tofauti hii ni muhimu, kwa sababu faili za quadlet zinahitaji toleo la 4.4 au jipya zaidi na faili za quadlet za .pod zinahitaji 5.0. Tekeleza podman --version kabla ya kunakili mfano kutoka kwenye nyaraka za upstream.

Kila mtumiaji wa rootless anahitaji safu ya subordinate ID:

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

Mtumiaji aliyeundwa kwa adduser kwenye Ubuntu hupata safu hiyo kiotomatiki. Mtumiaji aliyeundwa kwa useradd -M au kwa zana ya usanidi mara nyingi hapati, na hitilafu huonyesha hivyo:

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

Pangia safu, kisha uweke upya hifadhi ya mtumiaji huyo ili mapping mpya itumike:

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

Mshangao mwingine wa kwanza: Podman haichukulii Docker Hub kama chaguo-msingi. Jina fupi la image hutatuliwa dhidi ya unqualified-search-registries katika /etc/containers/registries.conf, na katika script isiyo na terminal iliyounganishwa, pull inashindwa na short-name resolution enforced but cannot prompt without a TTY. Andika jina kamili kila wakati. Tumia docker.io/library/nginx:1.27 badala ya nginx.

Faida halisi za rootless containers kwenye seva iliyokodiwa

Rootless container huendeshwa ndani ya user namespace, kipengele cha kernel kinachopatia mchakato ramani yake binafsi ya vitambulisho vya watumiaji (UID). Ndani ya namespace hiyo, superuser wa container ni UID 0. Nje yake, kwenye VPS yako, mchakato huo huo ni mtumiaji wako wa kawaida wa kuingia (login user). Root ndani ya container si root kwenye host.

Hiyo ndiyo faida yenyewe. Image inayosisitiza kuendeshwa kama root, programu ya wavuti yenye hitilafu ya remote code execution, au escape inayotegemea kuwa UID 0 kwa nje: yote hayo huishia kuwa na ruhusa za mtumiaji wako asiye na upendeleo badala ya zile za mashine nzima. Rootless haikukingi dhidi ya hitilafu za kernel, na haikulindi faili zako, kwa sababu mchakato uliotoroka huendeshwa kama wewe na unaweza kusoma chochote unachoweza kusoma.

Docker inaweza kuendeshwa kama rootless pia. dockerd-rootless-setuptool.sh install huweka daemon ya kila mtumiaji na hufanya kazi vizuri. Tofauti ni mwelekeo wa msingi (default). Kwa Podman, unapata rootless bila kuomba, kwa hivyo kosa lako la kwanza ni container inayoshindwa kufunga (bind) port 80, badala ya huduma iliyokuwa ikiendeshwa kimya kimya kama root kwa miaka miwili.

Kwa nini faili zangu za volume zinamilikiwa na UID 100999?

Hii inatokana na ule mfumo wa user namespace. UID 0 ya container inachorwa (map) kwenye UID ya host yako. UID 1 ya container inachorwa kwenye kitambulisho cha kwanza katika safu yako ya subuid, na kuendelea kupanda. Kwa safu inayoanzia 100000, UID 1000 ya container inatokea 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 inachapisha 1000. Orodha ya faili kwenye host inaonyesha mmiliki kama 100999, kwa sababu 100000 ukijumlisha 1000 ukitoa 1 unapata 100999. Hakuna kilichoharibika, na amri ya kawaida ya chown haitarekebisha tatizo hili, kwa sababu mtumiaji wako asiye na upendeleo (unprivileged user) hawezi kubadilisha umiliki wa faili nje ya namespace hiyo.

Kuna njia nne za kutatua hili:

• podman unshare chown 1000:1000 "$PWD/data" huendesha chown ndani ya user namespace ileile, ambapo namba hizo zina maana ileile inayotambulika na container.
• -v "$PWD/data:/data:U" inaiomba Podman ikurekebishie umiliki wa saraka (directory) ya chanzo. Itumie kwenye saraka mpya, siyo kwenye data unayoijali.
• --userns=keep-id inachora UID ya host yako kwenye UID ileile ndani ya container, ili faili mpya zinazotengenezwa ziwe na umiliki wako.
• Volume yenye jina kama -v appdata:/data inaepuka swali hili, kwa sababu Podman huitengeneza ndani ya hifadhi yako ikiwa na umiliki sahihi tayari.

Ikiwa umewahi kukumbana na hili kwenye Docker, ni tatizo lilelile katika ngazi ya juu zaidi. Vigezo vya PUID na PGID ambavyo images nyingi hutoa huweka UID inayotumiwa na mchakato ndani ya container, na chini ya Podman isiyo na root (rootless), UID hiyo inachorwa mara ya pili. PUID=1000 ndani ya container isiyo na root bado itaandika faili kwenye host zikiwa na umiliki wa 100999. Chagua namba hizo kwa kuzingatia mchoro huo wa pili, au hamisha data kwenye volume yenye jina na uache kuhangaika nayo.

Maelezo mengine mawili kuhusu mounts. Bendera za :z na :Z unazoziona kwenye mifano ya Fedora na RHEL ni chaguzi za kurelabel za SELinux, na kwa kuwa Ubuntu hutumia AppArmor, bendera hizo hazina kazi huko. Pia, Podman isiyo na root haiwezi ku-mount saraka ya host ambayo mtumiaji wako hawezi kuisoma; hili ni lengo la kiusalama badala ya kuwa hitilafu.

Kwa nini Podman isiyo na root inakataa kuchapisha port 80?

Kwa sababu kufunga (bind) port iliyo chini ya 1024 kunahitaji upendeleo (privilege) ambao mtumiaji wako hana. Ujumbe wa kosa unaonyesha suluhisho:

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

Kuna majibu mawili yanayofanya kazi. Punguza kizingiti kwa seva 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

Amri ya mwisho inapaswa kurudisha 80. Elewa vizuri kile ambacho mpangilio huo hufanya: kila mtumiaji kwenye mashine sasa anaweza kufunga port 80 na 443, si yule anayeendesha containers pekee. Kwenye VPS yenye msimamizi mmoja, hili ni jambo linalokubalika. Kwenye mashine inayotumiwa na akaunti za watu wengine, si jambo zuri. Jibu lingine ni kuchapisha kwenye port 8080 na kuweka reverse proxy mbele, ambapo ndipo unapotaka vyeti vitolewe na kusasishwa na certbot kwenye nginx hata hivyo.

Kuchapisha bila root pia hubadilisha kile ambacho programu yako huona. Podman 4.x hutumia slirp4netns pamoja na kishughulikiaji cha port cha rootlesskit kwa chaguo-msingi, na miunganisho iliyosambazwa hufika ikiwa na anwani ya chanzo iliyoandikwa upya, kwa hivyo access log hurekodi kila mgeni kama 10.0.2.100. Podman 5.0 ilibadilisha chaguo-msingi kuwa pasta, ambayo huhifadhi anwani halisi ya mteja. Kwenye 4.x, --network slirp4netns:port_handler=slirp4netns hurejesha anwani halisi ya chanzo kwa gharama fulani ya kasi ya mtandao (throughput).

Kuna mshangao mmoja mzuri hapa. Port iliyochapishwa bila root ni socket ya kawaida ya kusikiliza inayomilikiwa na mchakato wa kawaida, kwa hivyo sheria za firewall yako ya input hutumika kwake. Docker huchapisha ports kwa kuandika sheria za NAT (network address translation) pamoja na sheria zake za forwarding, ndiyo maana hasa port ya Docker iliyochapishwa hupuuza sheria ya ufw uliyofikiri inazuia. Podman inayotumia root hutumia mfumo sawa na hurithi mtego huo huo. Podman isiyo na root haifanyi hivyo.

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

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

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

Njia ya pili ni Docker Compose halisi inayowasiliana na API ya Podman inayooana na Docker 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 zinapaswa kuorodhesha kontena zilezile, kwa sababu kuna seti moja tu ya kontena hizo. Utatuzi wa majina (name resolution) hufanya kazi pia: backend ya mtandao ya kawaida ya Podman, netavark, huendesha aardvark-dns, kwa hivyo kontena zilizo kwenye mtandao uliotengenezwa na mtumiaji huonana kwa kutumia majina.

Kuna changamoto ndogo. Kitu chochote kinachoweka (mount) /var/run/docker.sock lazima kielekezwe kwenye socket ya Podman au kiondolewe. network_mode: host hufanya kazi kwa njia tofauti chini ya user namespace. depends_on pamoja na condition: service_healthy haitumiki kwa usawa katika matoleo ya podman-compose. restart: always haidumu baada ya reboot yenyewe, jambo ambalo sehemu inayofuata inalitatua. Compose inabaki kuwa njia nzuri ya kuelezea stack ya kontena nyingi katika faili moja, na chini ya Podman, inafanya kazi kama safu ya utafsiri. Kwa stack unayokusudia kuitumia kwa miaka mingi, ihamishie kwenye quadlets na udumishe abstraction moja badala ya mbili.

Pods: wazo ambalo Docker haina jibu kwalo

Pod ni kundi la containers zinazoshiriki network namespace moja. Podman huanzisha container ndogo ya infra ili kuweka namespace hiyo wazi, na wanachama wake kisha huwasiliana kupitia 127.0.0.1 bila kuhitaji network iliyosanidiwa na mtumiaji wala 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 ikiwa na containers tatu, ikijumuisha ile infra container. Sasa web container inafikia Redis kupitia 127.0.0.1:6379 badala ya app-cache:6379. Kanuni mbili zinatokana na namespace hii inayoshirikiwa: chapisha (publish) ports kwenye pod na si kwa mwanachama mmoja, na hakuna wanachama wawili wanaoweza kusikiliza (listen) kwenye port moja.

Huu ndio mfumo wa Kubernetes, na Podman inautumia kikamilifu. podman kube generate app > app.yaml huandika Kubernetes manifest kutoka kwa kile kinachoendelea (vifurushi vya zamani hutumia podman generate kube), na podman kube play app.yaml huunda upya kwenye host nyingine. Quadlet ina aina ya unit ya .kube inayoiendesha faili hiyo kama systemd service. Hii ni njia tofauti kabisa ya kupanga huduma, na ndiyo sababu kuu ya kuchagua Podman ikiwa unatarajia kutumia Kubernetes hapo baadaye.

Kuanza kiotomatiki bila daemon: vitengo vya Quadlet

Quadlet ni jenereta ya systemd. Inageuza faili fupi inayoelezea kontena kuwa huduma halisi ya systemd wakati wa boot. Faili huwekwa kwenye ~/.config/containers/systemd/ kwa mtumiaji asiye na 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 sehemu ndicho kinachounda volume:

[Volume]

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

Jina la huduma linatokana na jina la faili: caddy.container inakuwa caddy.service. Usiendeshe systemctl --user enable caddy. Vitengo vilivyozalishwa haviwezi kuwezeshwa (enabled), na systemd itajibu Failed to enable unit: Unit /run/user/1000/systemd/generator/caddy.service is transient or generated. Sehemu ya [Install] ndiyo inayoanzisha kontena wakati wa boot, na daemon-reload ndiyo inayozalisha upya kitengo baada ya kuhariri faili.

Sasa mpangilio unaowatatiza karibu watu wote:

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

Tarajia Linger=yes. Bila linger, systemd huvunja kikao chote cha mtumiaji wakati muunganisho wako wa mwisho wa SSH unapofungwa, kwa hivyo kila kontena lisilo na root husimama pamoja nacho na hakuna hata moja linalorudi wakati wa boot. Kontena zinazopotea unapo-log out daima husababishwa na hili.

Kwa sababu kontena ndiyo mchakato mkuu wa kitengo cha huduma cha kawaida, vidhibiti vya systemd vyenyewe hutumika moja kwa moja. MemoryMax= na CPUQuota= katika sehemu ya [Service] hufanya kazi sawa na vile ilivyo kwa huduma nyingine yoyote unayoidhibiti 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.

Masasisho yana utaratibu unaolingana. AutoUpdate=registry pamoja na systemctl --user enable --now podman-auto-update.timer hukagua registry kwa ajili ya image mpya zaidi kwenye tag ileile, huanzisha upya kitengo, na kurudi kwenye image ya awali ikiwa kontena jipya litashindwa kuanza. Endesha podman auto-update --dry-run kwanza ili kuona kile kitakachobadilika. Amri ya zamani ya podman generate systemd bado ipo na imepitwa na wakati, kwa hivyo andika quadlets kwa chochote kipya.

Mahali ambapo alias ya docker inafanya kazi, na mahali 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 amri huchapisha Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg. kwanza. Wrapper hiyo inashughulikia amri unazotumia kila siku: run, ps, logs, exec, build, pull, push, inspect, cp, volume, network.

Mambo yasiyohamishika ni machache, lakini ni muhimu. Swarm mode haina mbadala, kwa hivyo Swarm stack haina mahali pa kutua. Zana zinazowasiliana na Docker socket zinahitaji socket ya Podman iwe exported, na baadhi bado hutambua tofauti hiyo; Docker provider ya Traefik hufanya kazi ikielekezwa kwenye /run/user/<uid>/podman/podman.sock, wakati Watchtower haina nafasi kabisa, kwa sababu podman auto-update hufanya kazi hiyo. Hifadhi ni tofauti, kwa hivyo Podman haiwezi kuona images ulizokwisha pull kupitia Docker, na podman images kwenye seva yenye Docker nyingi huanza ikiwa tupu.

Uhamiaji wa stack inayofanya kazi, hatua kwa hatua

1. Unda au chagua mtumiaji asiye na upendeleo (unprivileged user) ambaye atamiliki containers, na uhakikishe ana masafa katika /etc/subuid.
2. Vuta upya (re-pull) kila kitu kilichotoka kwenye registry, kwa kutumia majina kamili (fully qualified names). Podman ina hifadhi yake ya image na haitasoma ya Docker.
3. Hamisha images zilizojengwa ndani ya seva 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 umiliki kwa podman unshare chown -R 1000:1000 <path>.
5. Tatua swali la port: chapisha (publish) 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, na uanzishe kila huduma.
7. Endesha sudo loginctl enable-linger <user>, anzisha upya (reboot) VPS, ingia tena na uhakikishe podman ps inaorodhesha kila huduma tena.

Injini hizi mbili hazishiriki chochote: hifadhi ya image ni tofauti na mitandao ni tofauti. Kwa hivyo unaweza kuendesha zote mbili wakati unahamia, na kitu pekee wanachoweza kugombea ni namba ya port ya host. Hamisha huduma moja, ifuatilie kwa siku moja, kisha hamisha inayofuata.

Podman dhidi ya Docker: ni ipi inafaa kwenye VPS yako?

Endelea kutumia Docker ikiwa stack yako iko kwenye faili za compose ambazo watu wengine pia wanazisimamia, au ikiwa unategemea zana zinazowasiliana na Docker socket. Utangamano na kile ambacho kila mtu mwingine anakiandika ni kipengele muhimu, na Docker ina utangamano huo zaidi. Timu ambayo laptops zao zote zinaendesha Docker pia hupata faida ya kweli kwa kuendesha engine hiyo hiyo kwenye production.

Hamia kwenye Podman ikiwa VPS yako inaendesha huduma chache unazozidhibiti kikamilifu, au ikiwa unataka kila programu iwe chini ya mtumiaji wake asiye na upendeleo (unprivileged user) bila kuwa na kundi la docker kwenye seva hata kidogo. Ulinganifu wa usambazaji (distribution alignment) pia ni muhimu: RHEL na mifumo inayotokana nayo husafirisha Podman kama engine inayoungwa mkono, kwa hivyo kwenye mifumo hiyo, Podman ndiyo njia yenye mshangao mdogo. Ikiwa tayari unasimamia kila kitu kingine kwa kutumia systemd units, quadlets zitaonekana kama kipande kilichokuwa kinakosekana badala ya kuwa zana mpya ya kujifunza.

Chaguo moja la kati linastahili kutajwa. Rootful Podman hufanya kazi kama Docker, huweka amri ya docker kupitia wrapper, na bado huondoa daemon inayofanya kazi kila wakati. Pia huacha sehemu ya rootless, ambayo ndiyo sehemu inayobadilisha msimamo wako wa kiusalama, kwa hivyo ichukulie kama kituo cha muda tu.

Ikiwa bado unajenga mwenyeji wako wa kwanza wa container, usanidi wa Docker na njia ya kuimarisha usalama kwenye VPS mpya ndiyo njia fupi zaidi, na hakuna maarifa hayo yatakayopotea. Images na volumes ni vitu vile vile chini ya engine zote mbili, kwa hivyo kuhama baadaye kutabadilisha tu jinsi huduma zako zinavyosimamiwa na si kitu kingine chochote.

FAQ

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

Kwa amri unazotumia, ni karibu sana. Kusakinisha podman-docker hukupa wrapper ya /usr/bin/docker, na run, ps, build, logs na exec hufanya kazi kwa njia ile ile. Hii si mbadala wa daemon. Swarm haina mlinganisho, zana zinazounganishwa na /var/run/docker.sock lazima zielekezwe kwenye socket ya Podman ya kila mtumiaji badala yake, na images zilizovutwa na Docker hubaki hazionekani kwa Podman kwa sababu zote mbili hutumia hifadhi tofauti.

Kwa nini containers zangu za rootless Podman husimama ninapojiondoa kwenye SSH?

Kwa sababu systemd husimamisha session ya mtumiaji, na kila huduma ya mtumiaji pamoja nayo, wakati login yako ya mwisho inapofungwa. Tekeleza sudo loginctl enable-linger <user>, kisha hakikisha kuwa loginctl show-user <user> --property=Linger inatoa Linger=yes. Linger huweka instance ya systemd ya mtumiaji huyo ikiendelea kufanya kazi bila session amilifu, jambo ambalo pia hufanya containers kuanza tena baada ya reboot.

Kwa nini faili kwenye volume yangu zinamilikiwa na UID 100999?

Rootless Podman hupanga UID 0 ya container kwenye mtumiaji wako wa host, kisha hupanga UID 1 na kuendelea kwenye safu yako ya subuid. Kwa safu inayoanzia 100000, UID 1000 ya container huwa 100999 kwenye host. Rekebisha hili ukiwa ndani ya namespace kwa kutumia podman unshare chown 1000:1000 /path/to/data, mount kwa kutumia flag ya :U wakati wa uendeshaji wa kwanza, au tumia --userns=keep-id ili UID za container zilingane na zako.

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

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

Je, rootless hufanya containers kuwa salama zaidi?

Huondoa hatari moja mahususi: mchakato unaotoroka kutoka kwenye container ya rootless hubaki na ruhusa za mtumiaji wako asiye na upendeleo badala ya zile za root. Hilo lina thamani, na ndiyo sababu kundi la docker lenye uwezo sawa na root halina mlinganisho chini ya rootless Podman. Hii haizuii udhaifu wa kernel, na haikulindi faili ambazo mtumiaji wako anaweza kuzisoma, kwa hivyo endelea na hatua nyingine za uimarishaji wa usalama ambazo ungefanya kwenye seva yoyote.