Podman vs Docker di VPS: Apa Perbezaan Sebenarnya?

Apakah perbezaan sebenar antara Podman dan Docker

Podman dan Docker menjalankan imej OCI (open container initiative) yang sama pada VPS, jadi pilihan ini bukan tentang perisian mana yang boleh anda jalankan. Perbezaannya terletak pada model proses. Docker menjalankan daemon root yang memiliki setiap kontena, dan arahan docker hanyalah klien kecil yang meminta daemon tersebut melakukan kerja. Podman tidak mempunyai daemon: podman run memulakan kontena sebagai proses anak kepada apa sahaja yang memanggilnya, di bawah pengguna tanpa keistimewaan anda sendiri.

Segala perkara lain berpunca daripada fakta tersebut. Auto-start menjadi tugas systemd dan bukannya tugas daemon. Pemilikan volum melalui namespace pengguna, jadi pemilik yang anda lihat dengan ls -l pada hos bukanlah pemilik yang dilihat oleh kontena. Port di bawah 1024 enggan terikat (bind) sehingga anda menukar tetapan kernel. CLI (command line interface) docker terus berfungsi melalui wrapper, sehingga ke tahap di mana sesuatu memerlukan soket Docker.

Tiada daemon: apa yang sebenarnya berjalan apabila anda memulakan kontena

Pada hos Docker, pstree -a menunjukkan dockerd sebagai root, containerd di sebelahnya, dan satu containerd-shim-runc-v2 bagi setiap kontena yang sedang berjalan. Aplikasi anda merupakan anak kepada shim tersebut, dan shim itu pula adalah anak kepada PID 1. Tiada apa-apa yang menghubungkan kontena dengan shell yang memulakannya. Hentikan daemon dan anda akan kehilangan satah kawalan untuk setiap kontena pada mesin tersebut, dan dengan tetapan lalai live-restore dimatikan, systemctl restart docker turut memulakan semula kontena anda.

Podman tidak mempunyai proses yang setara. Mulakan kontena dan anda akan mendapat satu proses conmon (pemantau kontena) yang memegang proses utama kontena, dimiliki oleh pengguna yang menjalankan arahan tersebut.

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 sepatutnya menyenaraikan conmon yang berjalan sebagai pengguna log masuk anda dan bukan sebagai root, dan curl sepatutnya mencetak 200. Oleh kerana tiada perkhidmatan pusat yang memiliki kontena tersebut, sudo apt upgrade podman tidak menghentikan apa-apa yang sudah berjalan, dan kegagalan pemantau satu kontena tidak akan menjejaskan kontena yang lain.

Ketiadaan daemon juga membawa kesan. Tiada apa-apa yang memulakan kontena anda selepas but semula. --restart=always Docker adalah janji yang ditepati oleh daemon semasa but, dan Podman menggantikannya dengan systemd, iaitu tujuan bahagian quadlet di bawah.

Soket adalah separuh lagi daripada cerita ini. /var/run/docker.sock ialah titik akhir API (antara muka pengaturcaraan aplikasi) yang dimiliki oleh root, dan mana-mana proses yang boleh menulis kepadanya boleh memulakan kontena berkeistimewaan yang melekapkan sistem fail hos. Menambah pengguna ke dalam kumpulan docker memberikan pengguna tersebut akses root melalui laluan yang lebih perlahan, yang wajar dibaca di samping memberikan setiap akaun perkhidmatan hanya akses yang diperlukan. Podman tidak mendedahkan sebarang soket melainkan anda memintanya, dan soket yang anda peroleh adalah milik pengguna tunggal di /run/user/<uid>/podman/podman.sock.

Memasang Podman pada Ubuntu 24.04 dan mengesahkan mod rootless

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

Pakej uidmap menyediakan newuidmap dan newgidmap. Ini merupakan pembantu setuid yang membolehkan pengguna biasa menuntut julat ID bawahan, dan tanpanya kontena rootless tidak akan bermula. podman info sepatutnya mencetak rootless: true.

Ubuntu 24.04 membekalkan Podman 4.9 dan Debian 13 membekalkan Podman 5.x, disemak pada Ogos 2026. Jurang ini penting, kerana fail quadlet memerlukan versi 4.4 atau lebih baharu dan fail quadlet .pod memerlukan versi 5.0. Jalankan podman --version sebelum anda menyalin contoh daripada dokumentasi hulu (upstream).

Setiap pengguna rootless memerlukan julat ID bawahan:

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

Pengguna yang dicipta oleh adduser pada Ubuntu mendapat julat secara automatik. Pengguna yang dicipta oleh useradd -M atau oleh alat konfigurasi selalunya tidak mendapat julat tersebut, dan kegagalan akan dinyatakan seperti berikut:

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

Berikan julat, kemudian tetapkan semula storan pengguna tersebut supaya pemetaan baharu digunakan:

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

Satu lagi kejutan pada penggunaan pertama: Podman tidak menganggap Docker Hub sebagai lalai. Nama imej yang pendek akan diselesaikan terhadap unqualified-search-registries dalam /etc/containers/registries.conf, dan dalam skrip tanpa terminal yang dilampirkan, proses pull akan gagal dengan short-name resolution enforced but cannot prompt without a TTY. Tulis nama penuh setiap kali. Gunakan docker.io/library/nginx:1.27 berbanding nginx.

Apa yang sebenarnya anda peroleh daripada kontena tanpa root pada pelayan sewaan

Kontena tanpa root (rootless) berjalan di dalam namespace pengguna, iaitu ciri kernel yang memberikan proses pemetaan ID pengguna peribadinya sendiri. Di dalam namespace tersebut, superuser kontena adalah UID (ID pengguna) 0. Di luar namespace, pada VPS anda, proses yang sama hanyalah pengguna log masuk biasa anda. Root di dalam kontena bukanlah root pada hos.

Itulah tahap sebenar kelebihan yang diperoleh. Imej yang berkeras untuk berjalan sebagai root, aplikasi web dengan pepijat pelaksanaan kod jauh (remote code execution), atau pelarian (escape) yang bergantung kepada status UID 0 di luar: kesemuanya akhirnya hanya memegang kebenaran pengguna tanpa keistimewaan anda dan bukannya kebenaran mesin tersebut. Apa yang tidak dilakukan oleh mod tanpa root adalah melindungi anda daripada pepijat kernel, dan ia tidak melindungi fail anda sendiri, kerana proses yang terlepas itu berjalan sebagai anda dan boleh membaca apa sahaja yang anda boleh baca. Unit yang diasingkan adalah sama penting dengan pemetaan UID, yang lebih mudah dilihat dalam FreeBSD jail, yang membungkus keseluruhan userland yang anda tadbir seperti sebuah mesin kecil berbanding imej berlapis yang ditarik daripada registry.

Docker juga boleh berjalan tanpa root. dockerd-rootless-setuptool.sh install menyediakan daemon bagi setiap pengguna dan ia berfungsi dengan baik. Perbezaannya adalah pada hala tuju lalai. Dengan Podman, anda mendapat mod tanpa root tanpa perlu memintanya, jadi kegagalan pertama anda ialah kontena yang tidak boleh mengikat port 80, bukannya servis yang berjalan secara senyap sebagai root selama dua tahun.

Mengapa fail volum saya dimiliki oleh UID 100999?

Ini disebabkan oleh namespace pengguna yang sama. UID 0 dalam kontena dipetakan kepada UID hos anda. UID 1 dalam kontena dipetakan kepada ID pertama dalam julat subuid anda, dan ia dikira bermula dari situ. Dengan julat yang bermula pada 100000, UID 1000 dalam kontena akan muncul pada hos sebagai 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"

Kontena mencetak 1000. Penyenaraian pada hos mencetak pemilik 100999, kerana 100000 ditambah 1000 tolak 1 ialah 100999. Tiada apa-apa yang rosak, dan arahan chown biasa tidak akan membetulkannya, kerana pengguna tanpa keistimewaan (unprivileged) anda tidak boleh menukar pemilikan fail di luar namespace tersebut.

Empat cara penyelesaian:

• podman unshare chown 1000:1000 "$PWD/data" menjalankan chown di dalam namespace pengguna yang sama, di mana nombor tersebut membawa maksud yang sama seperti di dalam kontena.
• -v "$PWD/data:/data:U" meminta Podman membetulkan pemilikan direktori sumber untuk anda. Gunakannya pada direktori baharu, bukan pada data yang penting bagi anda.
• --userns=keep-id memetakan UID hos anda kepada UID yang sama di dalam kontena, supaya fail baharu yang dihasilkan dimiliki oleh anda.
• Volum bernama seperti -v appdata:/data mengelakkan isu ini, kerana Podman menciptanya di dalam storan anda sendiri dengan pemilikan yang sudah betul.

Jika anda pernah menghadapi masalah ini dalam Docker, ia adalah masalah yang sama pada lapisan yang berbeza. Pemboleh ubah PUID dan PGID yang didedahkan oleh banyak imej menetapkan UID yang digunakan oleh proses di dalam kontena, dan di bawah Podman tanpa root (rootless), UID tersebut kemudiannya dipetakan buat kali kedua. PUID=1000 di dalam kontena tanpa root masih menulis fail hos yang dimiliki oleh 100999. Pilih nombor dengan mengambil kira pemetaan kedua tersebut, atau pindahkan data ke dalam volum bernama dan abaikan isu ini.

Dua nota tambahan mengenai mount. Flag :z dan :Z yang anda lihat dalam contoh Fedora dan RHEL adalah pilihan pelabelan semula SELinux, dan Ubuntu menggunakan AppArmor, jadi ia tidak berfungsi di sana. Podman tanpa root juga tidak boleh melakukan mount pada direktori hos yang tidak boleh dibaca oleh pengguna anda; ini adalah ciri keselamatan, bukannya ralat.

Mengapa Podman tanpa root (rootless) enggan menerbitkan port 80?

Kerana mengikat port di bawah 1024 memerlukan keistimewaan yang tidak dimiliki oleh pengguna anda. Ralat tersebut menyatakan cara penyelesaiannya:

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

Terdapat dua jawapan yang berkesan. Rendahkan ambang untuk keseluruhan hos:

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

Perintah terakhir sepatutnya memaparkan 80 sebagai output. Fahami dengan jelas fungsi tetapan tersebut: setiap pengguna pada mesin kini boleh mengikat port 80 dan 443, bukan hanya pengguna yang menjalankan kontena. Pada VPS dengan pentadbir tunggal, ini adalah pertukaran yang boleh diterima. Pada mesin yang menempatkan akaun orang lain, ia tidak digalakkan. Jawapan lain adalah dengan menerbitkan pada port 8080 dan meletakkan reverse proxy di hadapan, yang mana ia adalah tempat yang anda mahukan untuk sijil dikeluarkan dan diperbaharui oleh certbot pada nginx walau bagaimanapun.

Penerbitan tanpa root juga mengubah apa yang dilihat oleh aplikasi anda. Podman 4.x menggunakan slirp4netns dengan pengendali port rootlesskit secara lalai, dan sambungan yang diteruskan tiba dengan alamat sumber yang ditulis semula, jadi log akses merekodkan setiap pelawat sebagai 10.0.2.100. Podman 5.0 menukar lalai kepada pasta, yang mengekalkan alamat klien sebenar. Pada 4.x, --network slirp4netns:port_handler=slirp4netns memulihkan alamat sumber sebenar dengan sedikit kos pada throughput.

Terdapat satu kejutan yang baik di sini. Port yang diterbitkan tanpa root adalah soket pendengar biasa yang dimiliki oleh proses biasa, jadi peraturan input firewall anda terpakai kepadanya. Docker menerbitkan port dengan menulis peraturan NAT (network address translation) serta penerimaan forwarding miliknya sendiri, itulah sebabnya port Docker yang diterbitkan mengabaikan peraturan ufw yang anda sangka menyekatnya. Podman dengan root menggunakan sistem yang serupa dan mewarisi perangkap yang sama. Mod tanpa root tidak melakukannya.

Adakah fail Docker Compose saya masih berfungsi di bawah Podman?

Kebanyakannya ya, melalui dua laluan berbeza. Laluan pertama ialah podman-compose, iaitu satu implementasi berasingan yang membaca fail yang sama dan menggerakkan CLI Podman:

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

Laluan kedua ialah Docker Compose sebenar yang berhubung dengan API Podman yang serasi dengan Docker melalui soket bagi setiap pengguna:

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 dan podman ps sepatutnya menyenaraikan kontena yang sama, kerana hanya terdapat satu set kontena. Resolusi nama juga berfungsi: backend rangkaian lalai Podman, iaitu netavark, menjalankan aardvark-dns, jadi kontena dalam rangkaian yang ditakrifkan pengguna boleh menemui satu sama lain melalui nama.

Terdapat beberapa batasan. Sebarang perkara yang melekapkan /var/run/docker.sock perlu dihalakan ke soket Podman atau dibuang. network_mode: host berkelakuan berbeza di bawah ruang nama pengguna (user namespace). depends_on dengan condition: service_healthy disokong secara tidak sekata merentas versi podman-compose. restart: always tidak bertahan selepas but semula secara sendirinya, yang akan diselesaikan dalam bahagian seterusnya. Compose kekal sebagai cara yang baik untuk menerangkan timbunan berbilang kontena dalam satu fail, dan di bawah Podman, ia berfungsi sebagai lapisan terjemahan. Bagi timbunan yang anda ingin kekalkan selama bertahun-tahun, tukarkannya kepada quadlets dan selenggara satu abstraksi sahaja dan bukannya dua.

Pod: konsep yang tidak dimiliki oleh Docker

Pod ialah sekumpulan kontena yang berkongsi satu network namespace. Podman memulakan kontena infra yang kecil untuk memastikan namespace tersebut kekal terbuka, dan ahli-ahlinya kemudian boleh berhubung antara satu sama lain melalui 127.0.0.1 tanpa memerlukan rangkaian yang ditakrifkan pengguna atau penemuan servis (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 sepatutnya memaparkan pod Running dengan tiga kontena, termasuk kontena infra. Kontena web kini boleh mencapai Redis pada 127.0.0.1:6379 dan bukannya pada app-cache:6379. Dua peraturan terhasil daripada namespace yang dikongsi ini: terbitkan port pada pod dan bukannya pada ahli, dan tiada dua ahli boleh mendengar (listen) pada port yang sama.

Ini merupakan model Kubernetes, dan Podman menggunakannya. podman kube generate app > app.yaml menulis manifest Kubernetes berdasarkan apa yang sedang berjalan (pakej lama menggunakan ejaan podman generate kube), dan podman kube play app.yaml mencipta semula manifest tersebut pada hos lain. Quadlet mempunyai jenis unit .kube yang menjalankan fail sedemikian sebagai servis systemd. Ini merupakan cara yang benar-benar berbeza untuk mengumpulkan servis, dan ia merupakan sebab paling kukuh untuk memilih Podman jika Kubernetes ada dalam perancangan masa depan anda.

Auto-start tanpa daemon: unit quadlet

Quadlet ialah penjana systemd. Ia menukarkan fail ringkas yang menerangkan kontena menjadi servis systemd sebenar semasa but. Fail diletakkan dalam ~/.config/containers/systemd/ untuk pengguna rootless, atau /etc/containers/systemd/ untuk 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 boleh dibiarkan hampir kosong, kerana pengepala seksyen itulah yang mencipta volum:

[Volume]

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

Nama servis diambil daripada nama fail: caddy.container menjadi caddy.service. Jangan jalankan systemctl --user enable caddy. Unit yang dijana tidak boleh didayakan, dan systemd akan membalas Failed to enable unit: Unit /run/user/1000/systemd/generator/caddy.service is transient or generated.. Seksyen [Install] ialah perkara yang memulakan kontena semasa but, dan daemon-reload ialah perkara yang menjana semula unit selepas anda menyunting fail tersebut.

Sekarang, tetapan yang sering terlepas pandang oleh pengguna:

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

Jangkakan Linger=yes. Tanpa linger, systemd akan menamatkan keseluruhan sesi pengguna apabila sambungan SSH terakhir anda ditutup, jadi setiap kontena rootless akan berhenti bersamanya dan tiada satu pun yang akan kembali semasa but. Kontena yang hilang apabila anda log keluar sentiasa berpunca daripada perkara ini.

Oleh sebab kontena merupakan proses utama bagi unit servis biasa, kawalan systemd sendiri terpakai secara langsung. MemoryMax= dan CPUQuota= dalam seksyen [Service] berfungsi sama seperti mana-mana servis lain yang anda hadkan dengan systemd. Ini memerlukan cgroup v2 (control group versi 2), yang telah digunakan oleh Ubuntu secara lalai sejak 22.04. Sahkan dengan podman info | grep -i cgroup.

Kemas kini mempunyai mekanisme padanan. AutoUpdate=registry ditambah systemctl --user enable --now podman-auto-update.timer menyemak registry untuk imej yang lebih baharu pada tag yang sama, memulakan semula unit, dan membuat rollback kepada imej sebelumnya jika kontena baharu gagal bermula. Jalankan podman auto-update --dry-run terlebih dahulu untuk melihat perubahan yang akan berlaku. Perintah podman generate systemd yang lebih lama masih wujud dan telah ditamatkan (deprecated), jadi tulis quadlet untuk sebarang perkara baharu.

Di mana alias docker berfungsi, dan di mana ia tidak berfungsi

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

podman-docker memasang pembungkus /usr/bin/docker yang memanggil Podman. Tanpa fail nodocker, setiap panggilan akan mencetak Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg. terlebih dahulu. Pembungkus ini meliputi arahan yang anda taip sepanjang hari: run, ps, logs, exec, build, pull, push, inspect, cp, volume, network.

Apa yang tidak dibawa bersama adalah senarai yang lebih pendek, dan lebih kritikal. Mod Swarm tidak mempunyai setara, jadi stack Swarm tidak mempunyai tempat untuk dijalankan. Alatan yang berkomunikasi dengan soket Docker memerlukan soket Podman dieksport, dan sesetengahnya masih dapat mengesan perbezaan tersebut; penyedia Docker bagi Traefik berfungsi apabila dihalakan ke /run/user/<uid>/podman/podman.sock, manakala Watchtower tidak mempunyai fungsi langsung, kerana podman auto-update melakukan tugas tersebut. Storan adalah berasingan, jadi Podman tidak dapat melihat imej yang telah anda tarik menggunakan Docker, dan podman images pada hos Docker yang sibuk akan bermula dalam keadaan kosong.

Migrasi tindanan (stack) yang sedang berjalan, langkah demi langkah

1. Cipta atau pilih pengguna tanpa keistimewaan (unprivileged user) yang akan memiliki kontena tersebut, dan sahkan bahawa pengguna itu mempunyai julat dalam /etc/subuid.
2. Tarik semula (re-pull) sebarang imej yang datang daripada registry, menggunakan nama yang lengkap (fully qualified names). Podman mempunyai storan imejnya sendiri dan tidak akan membaca storan Docker.
3. Pindahkan imej yang dibina secara tempatan menggunakan docker save app:1.4 | podman load.
4. Hentikan kontena Docker, salin kandungan setiap volum keluar daripada /var/lib/docker/volumes/<name>/_data, kemudian betulkan pemilikan (ownership) dengan podman unshare chown -R 1000:1000 <path>.
5. Selesaikan isu port: terbitkan port di atas 1024 di belakang reverse proxy, atau tetapkan net.ipv4.ip_unprivileged_port_start.
6. Tulis satu fail quadlet bagi setiap kontena, jalankan systemctl --user daemon-reload, dan mulakan setiap servis.
7. Jalankan sudo loginctl enable-linger <user>, but semula VPS, log masuk semula dan periksa sama ada podman ps menyenaraikan setiap servis sekali lagi.

Kedua-dua enjin ini tidak berkongsi apa-apa: storan imej dan rangkaian adalah berasingan. Oleh itu, anda boleh menjalankan kedua-duanya semasa proses migrasi, dan satu-satunya perkara yang boleh menyebabkan konflik adalah nombor port hos. Pindahkan satu servis, pantau selama sehari, kemudian pindahkan servis seterusnya.

Podman lawan Docker: yang mana satu sesuai untuk VPS anda?

Kekal dengan Docker jika stack anda berada dalam fail compose yang turut diselenggara oleh orang lain, atau jika anda bergantung pada alatan yang berinteraksi dengan socket Docker. Keserasian dengan apa yang ditulis oleh orang lain merupakan ciri yang nyata, dan Docker mempunyai lebih banyak keserasian tersebut. Pasukan yang kesemua komputer ribanya menjalankan Docker juga mendapat manfaat konkrit daripada menjalankan enjin yang sama dalam pengeluaran.

Beralih kepada Podman jika VPS anda menjalankan segelintir servis yang anda kawal sepenuhnya, atau jika anda mahukan setiap aplikasi di bawah pengguna tanpa keistimewaan (unprivileged) sendiri tanpa sebarang kumpulan docker pada pelayan tersebut. Penjajaran pengedaran juga penting: RHEL dan binaan semulanya menyertakan Podman sebagai enjin yang disokong, jadi pada sistem tersebut, Podman adalah laluan yang kurang memberikan kejutan. Jika anda tetap mahukan Docker pada salah satu hos tersebut, laluan dnf pada Rocky Linux dan AlmaLinux bermula dengan membuang wrapper podman-docker yang sudah pun menguasai arahan docker di sana. Jika anda sudah menyelia segala-galanya dengan unit systemd, quadlets akan terasa seperti kepingan yang hilang telah ditemui, bukannya alatan baharu untuk dipelajari.

Satu pilihan pertengahan yang wajar disebut. Podman rootful berkelakuan hampir sama seperti Docker, mengekalkan arahan docker melalui wrapper, dan masih membuang daemon yang sentiasa berjalan. Ia juga melepaskan aspek tanpa root (rootless), iaitu bahagian yang mengubah kedudukan keselamatan anda, jadi anggap ia sebagai persinggahan sahaja.

Jika anda masih membina hos kontena pertama anda, laluan penyediaan dan pengukuhan Docker pada VPS baharu adalah jalan yang lebih singkat, dan tiada pengetahuan tersebut akan menjadi sia-sia. Imej dan volum adalah objek yang sama di bawah kedua-dua enjin, jadi peralihan pada masa hadapan hanya akan mengubah cara servis anda diselia dan tidak banyak perkara lain.

FAQ

Adakah Podman pengganti terus (drop-in replacement) untuk Docker?

Bagi arahan yang anda taip, ia hampir sama. Memasang podman-docker memberikan anda wrapper /usr/bin/docker, dan run, ps, build, logs serta exec berfungsi dengan cara yang sama. Ia bukan pengganti untuk daemon. Swarm tidak mempunyai setara, alatan yang bersambung ke /var/run/docker.sock mesti dihalakan ke soket Podman bagi setiap pengguna, dan imej yang ditarik oleh Docker kekal tidak kelihatan kepada Podman kerana kedua-duanya menyimpan storan secara berasingan.

Mengapa kontena Podman rootless saya berhenti apabila saya log keluar dari SSH?

Kerana systemd menghentikan sesi pengguna, dan setiap servis pengguna bersamanya, apabila log masuk terakhir anda ditutup. Jalankan sudo loginctl enable-linger <user>, kemudian semak sama ada loginctl show-user <user> --property=Linger memaparkan Linger=yes. Linger memastikan instance systemd pengguna tersebut terus berjalan tanpa sesi aktif, yang juga merupakan sebab kontena bermula semula selepas but semula (reboot).

Mengapa fail dalam volum saya dimiliki oleh UID 100999?

Podman rootless memetakan UID 0 kontena kepada pengguna hos anda, kemudian memetakan UID 1 kontena dan seterusnya ke dalam julat subuid anda. Dengan julat bermula pada 100000, UID 1000 kontena menjadi 100999 pada hos. Betulkannya dari dalam namespace dengan podman unshare chown 1000:1000 /path/to/data, lekapkan (mount) dengan flag :U pada larian pertama, atau gunakan --userns=keep-id supaya UID kontena sepadan dengan UID anda sendiri.

Bolehkah saya terus menggunakan docker-compose.yml dengan Podman?

Ya, melalui dua cara. podman-compose membaca fail tersebut dan menggerakkan CLI Podman secara terus. Atau aktifkan soket keserasian dengan systemctl --user enable --now podman.socket, tetapkan DOCKER_HOST=unix:///run/user/$(id -u)/podman/podman.sock, dan jalankan docker compose sebenar terhadapnya. Jangkakan sedikit masalah pada network_mode: host, pada servis yang melekapkan soket Docker, dan pada restart: always, yang memerlukan unit quadlet dan linger untuk bertahan selepas but semula.

Adakah rootless benar-benar menjadikan kontena lebih selamat?

Ia menghapuskan satu risiko khusus: proses yang terkeluar daripada kontena rootless hanya memegang keizinan pengguna tanpa keistimewaan (unprivileged) anda, bukannya keizinan root. Ini adalah sesuatu yang berbaloi, dan itulah sebabnya kumpulan docker yang setara dengan root tidak mempunyai padanan di bawah Podman rootless. Ia tidak menghalang kerentanan kernel, dan ia tidak melindungi fail yang boleh dibaca oleh pengguna anda sendiri, jadi teruskan langkah pengukuhan (hardening) lain yang anda akan lakukan pada mana-mana pelayan.