Perbezaan Podman vs Docker di VPS: Panduan Lengkap

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 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 disalurkan melalui ruang nama pengguna (user namespace), 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 (antaramuka baris perintah) docker terus berfungsi melalui pembungkus (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 control plane bagi setiap kontena pada mesin tersebut, dan dengan tetapan lalai live-restore dimatikan, systemctl restart docker juga akan 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. Kerana tiada perkhidmatan pusat yang memiliki kontena tersebut, sudo apt upgrade podman tidak menghentikan apa-apa yang sedang 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 merupakan 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 merupakan titik akhir API (application programming interface) yang dimiliki oleh root, dan mana-mana proses yang boleh menulis kepadanya boleh memulakan kontena berkeistimewaan yang melekapkan (mount) 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 adalah pembantu setuid yang membolehkan pengguna biasa menuntut julat ID bawahan, dan tanpanya kontena rootless tidak akan bermula. podman info sepatutnya memaparkan rootless: true.

Ubuntu 24.04 membekalkan Podman 4.9 dan Debian 13 membekalkan Podman 5.x, disemak pada Ogos 2026. Perbezaan 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 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 rootless pada pelayan sewaan

Kontena rootless berjalan di dalam user namespace, iaitu ciri kernel yang memberikan proses pemetaan ID pengguna (UID) peribadinya sendiri. Di dalam namespace tersebut, superuser kontena adalah UID 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 memerlukan kebenaran untuk berjalan sebagai root, aplikasi web dengan pepijat 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 keseluruhan mesin. Apa yang tidak dilakukan oleh rootless 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.

Docker juga boleh berjalan secara rootless. dockerd-rootless-setuptool.sh install menyediakan daemon bagi setiap pengguna dan ia berfungsi dengan baik. Perbezaannya terletak pada hala tuju lalai. Dengan Podman, anda mendapat rootless tanpa perlu memintanya, jadi kegagalan pertama anda hanyalah kontena yang tidak dapat 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 tambah 1000 tolak 1 ialah 100999. Tiada apa-apa yang rosak, dan 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 kepada kontena.
• -v "$PWD/data:/data:U" meminta Podman membetulkan pemilikan direktori sumber untuk anda. Gunakannya pada direktori baharu, bukan pada data yang penting kepada 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 persoalan 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 lebih tinggi. 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 berhenti memikirkannya.

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 tujuan keselamatannya, bukannya satu 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

Arahan 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 menampung akaun orang lain, ia tidak selamat. Jawapan lain adalah dengan menerbitkan pada port 8080 dan meletakkan reverse proxy di hadapan, yang mana ia adalah lokasi yang anda mahukan untuk sijil yang 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 access log merekodkan setiap pelawat sebagai 10.0.2.100. Podman 5.0 menukar lalai kepada pasta, yang mengekalkan alamat klien yang sebenar. Pada 4.x, --network slirp4netns:port_handler=slirp4netns memulihkan alamat sumber yang 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 peraturan penerimaan forwarding miliknya sendiri, itulah sebabnya port Docker yang diterbitkan mengabaikan peraturan ufw yang anda sangka telah menyekatnya. Podman dengan root menggunakan sistem yang serupa dan mewarisi perangkap yang sama. Podman tanpa root tidak melakukannya.

Adakah fail Docker Compose saya masih berfungsi di bawah Podman?

Kebanyakannya ya, melalui dua kaedah berbeza. Kaedah 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

Kaedah kedua ialah menggunakan 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 sahaja. Resolusi nama juga berfungsi: backend rangkaian lalai Podman, iaitu netavark, menjalankan aardvark-dns, jadi kontena dalam rangkaian yang ditentukan pengguna boleh mencari antara satu sama lain melalui nama.

Terdapat beberapa batasan yang nyata. 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 network yang ditakrifkan pengguna atau 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 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 pada port yang sama.

Ini merupakan model Kubernetes, dan Podman menggunapakai model ini. podman kube generate app > app.yaml menulis manifest Kubernetes daripada 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 tersebut sebagai servis systemd. Ini merupakan cara yang benar-benar berbeza untuk mengumpulkan servis, dan ia adalah 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 diaktifkan, 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 kebanyakan orang:

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

Jangkakan Linger=yes. Tanpa linger, systemd akan menutup 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 ialah proses utama bagi unit servis biasa, kawalan systemd sendiri terpakai secara terus. MemoryMax= dan CPUQuota= dalam seksyen [Service] berfungsi sama seperti mana-mana servis lain yang anda kawal 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 berserta 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 perkara yang akan diubah. Perintah podman generate systemd yang lebih lama masih wujud dan telah ditamatkan penggunaannya, jadi tulis quadlet untuk sebarang perkara baharu.

Tempat alias docker berfungsi dan tempat 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.

Perkara yang tidak dibawa bersama adalah senarai yang lebih pendek dan lebih khusus. Mod Swarm tidak mempunyai setara, jadi stack Swarm tidak mempunyai tempat untuk dilaksanakan. Alat yang berkomunikasi dengan soket Docker memerlukan soket Podman dieksport, dan sesetengah alat masih mengesan perbezaannya; penyedia Docker bagi Traefik berfungsi apabila dihalakan ke /run/user/<uid>/podman/podman.sock, manakala Watchtower tidak mempunyai tempat 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.

Penghijrahan stack yang sedang berjalan, langkah demi langkah

1. Cipta atau pilih pengguna tanpa keistimewaan (unprivileged user) yang akan memiliki kontena tersebut, dan sahkan 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 lokal 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 melebihi 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 penghijrahan, 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 peralatan yang berinteraksi dengan Docker socket. Keserasian dengan apa yang ditulis oleh orang lain merupakan ciri yang nyata, dan Docker mempunyai lebih banyak kelebihan tersebut. Pasukan yang kesemua komputer ribanya menjalankan Docker juga mendapat manfaat konkrit daripada menjalankan enjin yang sama dalam pengeluaran (production).

Beralih kepada Podman jika VPS anda menjalankan beberapa servis yang anda kawal sepenuhnya dari hujung ke hujung, atau jika anda mahukan setiap aplikasi di bawah pengguna tanpa keistimewaan (unprivileged user) sendiri tanpa sebarang kumpulan docker pada pelayan tersebut. Penjajaran pengedaran (distribution alignment) juga penting: RHEL dan binaan semulanya membekalkan Podman sebagai enjin yang disokong, jadi pada sistem tersebut, Podman adalah laluan yang kurang memberikan kejutan. Jika anda sudah menyelia segala-galanya dengan unit systemd, quadlets akan terasa seperti kepingan yang hilang telah ditemui dan bukannya alat baharu untuk dipelajari.

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

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 perpindahan pada masa hadapan hanya mengubah cara servis anda diselia dan tidak banyak perkara lain.

FAQ

Adakah Podman pengganti terus untuk Docker?

Bagi arahan yang anda taip, ia hampir sama. Memasang podman-docker memberikan anda pembungkus /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 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 daripada 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 bahawa loginctl show-user <user> --property=Linger mencetak Linger=yes. Linger memastikan instance systemd pengguna itu terus berjalan tanpa sesi aktif, yang juga merupakan sebab kontena bermula semula selepas but semula.

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 julat subuid anda. Dengan julat bermula pada 100000, UID 1000 kontena menjadi 100999 pada hos. Betulkan ia dari dalam namespace dengan podman unshare chown 1000:1000 /path/to/data, lekapkan dengan flag :U pada pelaksanaan pertama, atau gunakan --userns=keep-id supaya UID kontena sepadan dengan UID anda sendiri.

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

Ya, dalam dua cara. podman-compose membaca fail tersebut dan memacu 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 memegang keizinan pengguna tanpa keistimewaan anda dan bukannya root. Ini berbaloi untuk dimiliki, dan itulah sebabnya kumpulan docker yang setara dengan root tidak mempunyai padanan di bawah Podman rootless. Ia tidak menghentikan kerentanan kernel, dan ia tidak melindungi fail yang boleh dibaca oleh pengguna anda sendiri, jadi kekalkan langkah pengukuhan lain yang anda akan lakukan pada mana-mana pelayan.