Podman vs Docker di VPS: Apa Perbedaan Sebenarnya?

Perbedaan sebenarnya antara Podman dan Docker

Podman dan Docker menjalankan image OCI (open container initiative) yang sama pada VPS, sehingga pilihannya bukan tentang perangkat lunak yang dapat Anda jalankan. Perbedaannya terletak pada model proses. Docker menjalankan daemon root yang mengelola setiap container, sedangkan perintah docker adalah client kecil yang meminta daemon tersebut melakukan pekerjaan. Podman tidak memiliki daemon: podman run memulai container sebagai proses anak dari apa pun yang memanggilnya, menggunakan unprivileged user Anda sendiri.

Hal lain mengikuti fakta tersebut. Auto-start menjadi tugas systemd, bukan daemon. Kepemilikan volume melewati user namespace, sehingga owner yang Anda lihat dengan ls -l pada host bukan owner yang dilihat container. Port di bawah 1024 menolak bind sampai Anda mengubah pengaturan kernel. CLI (command line interface) docker tetap berfungsi melalui wrapper, hingga ada komponen yang membutuhkan Docker socket.

Tidak ada daemon: proses yang sebenarnya berjalan saat Anda memulai container

Pada host Docker, pstree -a menampilkan dockerd sebagai root, containerd di sebelahnya, dan satu containerd-shim-runc-v2 untuk setiap container yang sedang berjalan. Aplikasi Anda merupakan child dari shim tersebut, sedangkan shim merupakan child dari PID 1. Tidak ada yang menghubungkan container dengan shell yang memulainya. Jika daemon dihentikan, Anda kehilangan control plane untuk semua container pada host tersebut. Jika pengaturan default live-restore dinonaktifkan, systemctl restart docker juga memulai ulang container Anda.

Podman tidak memiliki proses yang setara. Saat Anda memulai container, satu proses conmon (container monitor) akan berjalan dan menampung proses utama container. Proses ini dimiliki oleh user yang menjalankan perintah.

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 seharusnya menampilkan conmon yang berjalan sebagai user login Anda, bukan sebagai root, dan curl seharusnya menampilkan 200. Karena tidak ada service pusat yang memiliki container tersebut, sudo apt upgrade podman tidak menghentikan apa pun yang sedang berjalan. Jika monitor salah satu container mengalami crash, container lain tidak ikut terhenti.

Tidak adanya daemon juga memiliki konsekuensi. Tidak ada yang memulai container Anda setelah reboot. --restart=always milik Docker adalah janji yang dipenuhi daemon saat boot. Podman menggantinya dengan systemd, yang menjadi tujuan bagian quadlet di bawah ini.

Socket adalah bagian lain dari penjelasan ini. /var/run/docker.sock merupakan endpoint API (application programming interface) milik root. Setiap proses yang dapat menulis ke socket tersebut dapat memulai container berprivilege yang me-mount filesystem host. Menambahkan user ke grup docker memberikan hak root kepada user tersebut melalui jalur yang lebih tidak langsung. Hal ini perlu dibaca bersama memberikan setiap akun service hanya akses yang dibutuhkannya. Podman tidak mengekspos socket kecuali Anda memintanya. Socket yang dibuat hanya dimiliki oleh satu user pada /run/user/<uid>/podman/podman.sock.

Instal Podman di Ubuntu 24.04 dan pastikan mode rootless benar-benar digunakan

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

Paket uidmap menyediakan newuidmap dan newgidmap. Keduanya adalah helper setuid yang memungkinkan pengguna biasa menggunakan rentang ID subordinate. Tanpa helper tersebut, container rootless tidak dapat dijalankan. podman info seharusnya menampilkan rootless: true.

Ubuntu 24.04 menyediakan Podman 4.9, sedangkan Debian 13 menyediakan Podman 5.x, berdasarkan pemeriksaan pada Agustus 2026. Perbedaan ini penting karena file quadlet memerlukan versi 4.4 atau yang lebih baru, sedangkan file quadlet .pod memerlukan versi 5.0. Jalankan podman --version sebelum menyalin contoh dari dokumentasi upstream.

Setiap pengguna rootless memerlukan rentang ID subordinate:

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

Pengguna yang dibuat dengan adduser di Ubuntu mendapatkan rentang tersebut secara otomatis. Pengguna yang dibuat dengan useradd -M atau melalui alat konfigurasi sering kali tidak mendapatkannya, dan kegagalannya ditampilkan sebagai 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.

Tetapkan rentang, lalu reset storage pengguna tersebut agar pemetaan baru digunakan:

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

Ada satu kejutan lain saat pertama kali digunakan: Podman tidak menganggap Docker Hub sebagai registry default. Nama image singkat akan dicari di unqualified-search-registries dalam /etc/containers/registries.conf. Dalam script tanpa terminal terpasang, proses pull gagal dengan short-name resolution enforced but cannot prompt without a TTY. Selalu tulis nama lengkap. Gunakan docker.io/library/nginx:1.27, bukan nginx.

Hal yang sebenarnya Anda dapatkan dari container rootless di server sewaan

Container rootless berjalan di dalam user namespace, yaitu fitur kernel yang memberikan proses peta ID pengguna privat. Di dalam namespace tersebut, superuser container adalah UID (user ID) 0. Di luar namespace, pada VPS Anda, proses yang sama berjalan sebagai pengguna login biasa Anda. root di dalam container bukan root pada host.

Itulah manfaat sebenarnya. Image yang mengharuskan proses berjalan sebagai root, aplikasi web dengan bug remote code execution, atau escape yang bergantung pada UID 0 di luar namespace, semuanya hanya memperoleh permission pengguna Anda yang tidak memiliki hak istimewa, bukan permission mesin. Rootless tidak melindungi Anda dari bug kernel. Rootless juga tidak melindungi file milik Anda sendiri, karena proses yang keluar dari container berjalan sebagai Anda dan dapat membaca semua hal yang dapat Anda baca. Unit yang diisolasi setidaknya sama pentingnya dengan pemetaan UID. Hal ini lebih mudah dilihat pada FreeBSD jail, yang membungkus seluruh userland yang Anda kelola seperti mesin kecil daripada pada image berlapis yang diambil dari registry.

Docker juga dapat berjalan secara rootless. dockerd-rootless-setuptool.sh install menyiapkan daemon per pengguna dan bekerja dengan baik. Perbedaannya terletak pada default yang digunakan. Dengan Podman, Anda mendapatkan rootless tanpa perlu memintanya. Karena itu, kegagalan pertama Anda adalah container yang tidak dapat melakukan bind ke port 80, bukan service yang berjalan diam-diam sebagai root selama dua tahun.

Mengapa file volume saya dimiliki oleh UID 100999?

Penyebabnya adalah user namespace yang sama. UID 0 di container dipetakan ke UID Anda di host. UID 1 di container dipetakan ke ID pertama dalam rentang subuid Anda, lalu nilainya bertambah secara berurutan. Dengan rentang yang dimulai dari 100000, UID 1000 di container menjadi 100999 di host.

mkdir -p "$PWD/data"
podman run --rm --user 1000 -v "$PWD/data:/data" docker.io/library/alpine:3 sh -c 'id -u; touch /data/f'
ls -ln "$PWD/data"

Container menampilkan 1000. Daftar pada host menampilkan pemilik 100999, karena 100000 ditambah 1000 dikurangi 1 adalah 100999. Tidak ada yang rusak, dan chown biasa tidak akan memperbaikinya karena user tanpa hak istimewa tidak dapat mengubah kepemilikan file di luar namespace sama sekali.

Ada empat cara untuk mengatasinya:

• podman unshare chown 1000:1000 "$PWD/data" menjalankan chown di dalam user namespace yang sama, sehingga angka tersebut memiliki arti yang sesuai bagi container.
• -v "$PWD/data:/data:U" meminta Podman memperbaiki kepemilikan direktori sumber untuk Anda. Gunakan pada direktori baru, bukan pada data yang penting.
• --userns=keep-id memetakan UID host Anda ke UID yang sama di dalam container, sehingga file baru menjadi milik Anda.
• Named volume seperti -v appdata:/data menghindari masalah ini karena Podman membuatnya di dalam storage Anda sendiri dengan kepemilikan yang sudah benar.

Jika Anda pernah mengalami masalah ini di Docker, masalahnya sama, tetapi terjadi satu lapisan di atas. Variabel PUID dan PGID yang disediakan banyak image menetapkan UID yang digunakan proses di dalam container, lalu pada rootless Podman UID tersebut dipetakan sekali lagi. PUID=1000 di dalam container rootless tetap menulis file host yang dimiliki oleh 100999. Tentukan angkanya dengan mempertimbangkan pemetaan kedua tersebut, atau pindahkan data ke named volume agar Anda tidak perlu memikirkannya lagi.

Ada dua catatan tambahan tentang mount. Flag :z dan :Z yang terlihat dalam contoh Fedora dan RHEL adalah opsi pelabelan ulang SELinux, sedangkan Ubuntu menggunakan AppArmor, sehingga flag tersebut tidak melakukan apa pun di sana. Rootless Podman juga tidak dapat me-mount direktori host yang tidak dapat dibaca oleh user Anda. Itu adalah perilaku yang diharapkan, bukan kesalahan.

Mengapa Podman rootless menolak memublikasikan port 80?

Karena binding ke port di bawah 1024 memerlukan hak istimewa yang tidak dimiliki oleh user Anda. Error tersebut menyebutkan perbaikannya:

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

Ada dua solusi yang dapat digunakan. Turunkan threshold untuk seluruh host:

echo 'net.ipv4.ip_unprivileged_port_start=80' | sudo tee /etc/sysctl.d/99-podman.conf
sudo sysctl --system
sysctl net.ipv4.ip_unprivileged_port_start

Perintah terakhir harus menampilkan 80. Pahami dampak pengaturan tersebut: setiap user pada mesin kini dapat melakukan binding ke port 80 dan 443, bukan hanya user yang menjalankan container. Pada VPS dengan satu administrator, ini merupakan kompromi yang dapat diterima. Pada server yang juga memiliki akun milik pengguna lain, cara ini tidak sesuai. Solusi lainnya adalah memublikasikan port 8080 dan menempatkan reverse proxy di depannya. Konfigurasi tersebut juga diperlukan untuk sertifikat yang diterbitkan dan diperbarui oleh certbot pada nginx.

Publikasi rootless juga mengubah informasi yang dilihat aplikasi Anda. Podman 4.x menggunakan slirp4netns dengan port handler rootlesskit secara default. Koneksi yang diteruskan tiba dengan alamat sumber yang telah ditulis ulang, sehingga access log mencatat setiap pengunjung sebagai 10.0.2.100. Podman 5.0 mengubah default menjadi pasta, yang mempertahankan alamat client sebenarnya. Pada 4.x, --network slirp4netns:port_handler=slirp4netns mengembalikan alamat sumber sebenarnya dengan mengorbankan sebagian throughput.

Ada satu hal positif yang perlu diketahui. Port yang dipublikasikan secara rootless adalah listening socket biasa yang dimiliki oleh proses normal. Karena itu, aturan input firewall Anda tetap berlaku. Docker memublikasikan port dengan menulis aturan NAT (network address translation) serta aturan accept forwarding miliknya sendiri. Inilah alasan port Docker yang dipublikasikan mengabaikan aturan ufw yang Anda kira akan memblokirnya. Podman rootful menggunakan mekanisme serupa dan memiliki jebakan yang sama. Rootless tidak.

Apakah file Docker Compose saya tetap berfungsi di Podman?

Sebagian besar tetap berfungsi melalui dua cara. Cara pertama adalah podman-compose, implementasi terpisah yang membaca file yang sama dan menjalankan Podman CLI:

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

Cara kedua adalah Docker Compose yang sebenarnya, yang berkomunikasi dengan API Docker-compatible milik Podman melalui socket per 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 seharusnya menampilkan container yang sama karena hanya ada satu kumpulan container. Resolusi nama juga berfungsi. Backend jaringan default Podman, netavark, menjalankan aardvark-dns, sehingga container pada jaringan yang ditentukan pengguna dapat menemukan satu sama lain berdasarkan nama.

Namun, terdapat beberapa batasan. Apa pun yang me-mount /var/run/docker.sock harus diarahkan ke socket Podman atau dihapus. network_mode: host berperilaku berbeda dalam user namespace. Dukungan depends_on dengan condition: service_healthy tidak konsisten di berbagai versi podman-compose. restart: always tidak bertahan setelah reboot dengan sendirinya; bagian berikutnya memperbaikinya. Compose tetap merupakan cara yang baik untuk mendeskripsikan stack multi-container dalam satu file, dan di Podman berfungsi sebagai lapisan penerjemahan. Untuk stack yang akan dipertahankan selama bertahun-tahun, konversikan ke quadlet dan kelola satu abstraksi, bukan dua.

Pod: konsep yang tidak dimiliki Docker

Pod adalah sekelompok container yang berbagi satu network namespace. Podman memulai container infra kecil untuk menjaga namespace tersebut tetap tersedia, kemudian semua anggotanya saling terhubung melalui 127.0.0.1 tanpa network yang ditentukan pengguna dan tanpa 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 akan menampilkan pod Running dengan tiga container, termasuk container infra. Kini container web terhubung ke Redis melalui 127.0.0.1:6379, bukan melalui app-cache:6379. Ada dua aturan yang berlaku karena namespace digunakan bersama: publish port pada pod, bukan pada anggotanya, dan tidak boleh ada dua anggota yang listen pada port yang sama.

Ini adalah model Kubernetes, dan Podman mengadopsinya secara penuh. podman kube generate app > app.yaml menulis manifest Kubernetes berdasarkan kondisi yang sedang berjalan (pada package versi lama, perintah ini ditulis sebagai podman generate kube), sedangkan podman kube play app.yaml membuatnya kembali pada host lain. Quadlet memiliki tipe unit .kube yang menjalankan file tersebut sebagai service systemd. Ini adalah cara yang benar-benar berbeda untuk mengelompokkan service, dan menjadi alasan terkuat untuk memilih Podman jika Kubernetes mungkin digunakan di masa mendatang.

Pembuatan otomatis tanpa daemon: unit quadlet

Quadlet adalah generator systemd. Quadlet mengubah file singkat yang menjelaskan container menjadi service systemd nyata saat boot. File tersebut ditempatkan di ~/.config/containers/systemd/ untuk user rootless, atau di /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 dapat hampir kosong karena header bagian tersebut yang membuat volume:

[Volume]

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

Nama service berasal dari nama file: caddy.container menjadi caddy.service. Jangan jalankan systemctl --user enable caddy. Unit yang dibuat tidak dapat diaktifkan, dan systemd akan menjawab Failed to enable unit: Unit /run/user/1000/systemd/generator/caddy.service is transient or generated. Bagian [Install] yang menjalankan container saat boot, sedangkan daemon-reload membuat ulang unit setelah Anda mengedit file.

Sekarang, pengaturan yang sering terlewatkan:

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

Hasil yang diharapkan adalah Linger=yes. Tanpa linger, systemd menghentikan seluruh sesi user saat koneksi SSH terakhir ditutup. Akibatnya, semua container rootless ikut berhenti dan tidak ada yang berjalan kembali saat boot. Container yang hilang saat Anda logout selalu disebabkan oleh hal ini.

Karena container merupakan proses utama dari unit service biasa, kontrol bawaan systemd berlaku secara langsung. MemoryMax= dan CPUQuota= pada bagian [Service] berfungsi sama seperti pada service lain yang Anda batasi dengan systemd. Fitur ini memerlukan cgroup v2 (control group version 2), yang digunakan Ubuntu secara default sejak 22.04. Konfirmasikan dengan podman info | grep -i cgroup.

Pembaruan memiliki mekanisme yang sesuai. AutoUpdate=registry bersama systemctl --user enable --now podman-auto-update.timer memeriksa registry untuk image yang lebih baru pada tag yang sama, me-restart unit, lalu melakukan rollback ke image sebelumnya jika container baru gagal dijalankan. Jalankan podman auto-update --dry-run terlebih dahulu untuk melihat perubahan yang akan dilakukan. Perintah podman generate systemd yang lebih lama masih tersedia dan sudah deprecated, jadi gunakan quadlet untuk semua konfigurasi baru.

Di mana alias docker berlaku, dan di mana alias tersebut tidak berlaku

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

podman-docker memasang wrapper /usr/bin/docker yang memanggil Podman. Tanpa file nodocker, setiap pemanggilan terlebih dahulu menampilkan Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg. Wrapper ini mencakup perintah yang paling sering Anda gunakan: run, ps, logs, exec, build, pull, push, inspect, cp, volume, network.

Hal yang tidak terbawa memiliki daftar yang lebih singkat dan lebih tegas. Swarm mode tidak memiliki padanan, sehingga stack Swarm tidak memiliki tempat untuk dijalankan. Tool yang berkomunikasi dengan Docker socket memerlukan Podman socket yang diekspor, dan sebagian tool tetap mendeteksi perbedaannya; Docker provider milik Traefik berfungsi jika diarahkan ke /run/user/<uid>/podman/podman.sock, sedangkan Watchtower sama sekali tidak memiliki padanan karena podman auto-update menjalankan fungsi tersebut. Penyimpanannya terpisah, sehingga Podman tidak dapat melihat image yang sudah Anda pull dengan Docker, dan podman images pada Docker host yang sibuk akan kosong saat pertama kali digunakan.

Migrasikan stack yang sedang berjalan, langkah demi langkah

1. Buat atau pilih pengguna tanpa hak istimewa yang akan memiliki container, lalu pastikan pengguna tersebut memiliki range di /etc/subuid.
2. Tarik ulang semua image yang berasal dari registry menggunakan nama yang sepenuhnya memenuhi syarat. Podman memiliki penyimpanan image sendiri dan tidak akan membaca penyimpanan Docker.
3. Pindahkan image yang dibuat secara lokal menggunakan docker save app:1.4 | podman load.
4. Hentikan container Docker, salin isi setiap volume dari /var/lib/docker/volumes/<name>/_data, lalu perbaiki kepemilikannya menggunakan podman unshare chown -R 1000:1000 <path>.
5. Tentukan konfigurasi port: publikasikan port di atas 1024 di belakang reverse proxy, atau atur net.ipv4.ip_unprivileged_port_start.
6. Tulis satu file quadlet untuk setiap container, jalankan systemctl --user daemon-reload, lalu start setiap service.
7. Jalankan sudo loginctl enable-linger <user>, reboot VPS, login kembali, lalu periksa apakah podman ps mencantumkan semua service lagi.

Kedua engine tidak berbagi apa pun: penyimpanan image dan network-nya terpisah. Karena itu, Anda dapat menjalankan keduanya selama proses migrasi. Satu-satunya hal yang dapat diperebutkan adalah nomor port pada host. Pindahkan satu service, pantau selama satu hari, lalu pindahkan service berikutnya.

Podman vs Docker: mana yang tepat untuk VPS Anda?

Tetap gunakan Docker jika stack Anda berada dalam file compose yang juga dikelola oleh orang lain, atau jika Anda bergantung pada tooling yang berkomunikasi dengan Docker socket. Kompatibilitas dengan konfigurasi yang digunakan banyak orang merupakan fitur nyata, dan Docker unggul dalam hal ini. Tim yang seluruh laptopnya menjalankan Docker juga memperoleh manfaat nyata dengan menjalankan engine yang sama di production.

Beralih ke Podman jika VPS menjalankan beberapa service yang Anda kendalikan sepenuhnya, atau jika Anda ingin setiap aplikasi berjalan di bawah user unprivileged masing-masing tanpa grup docker sama sekali pada sistem. Kesesuaian dengan distribusi juga penting: RHEL dan turunannya merilis Podman sebagai engine yang didukung. Karena itu, pada sistem tersebut Podman merupakan pilihan dengan lebih sedikit kejutan. Jika Anda tetap menginginkan Docker pada host tersebut, jalur dnf di Rocky Linux dan AlmaLinux dimulai dengan menghapus wrapper podman-docker yang saat ini memiliki docker command di sana. Jika Anda sudah mengelola semua hal lain dengan unit systemd, quadlet akan terasa seperti bagian yang selama ini hilang, bukan tool baru yang harus dipelajari.

Satu opsi di tengah perlu disebutkan. Podman rootful berperilaku mirip Docker, mempertahankan docker command melalui wrapper, dan tetap menghilangkan daemon yang selalu berjalan. Namun, opsi ini menghilangkan aspek rootless, yaitu bagian yang mengubah posisi keamanan Anda. Karena itu, anggap opsi ini sebagai tahap sementara.

Jika Anda masih membangun host container pertama, jalur penyiapan dan hardening Docker pada VPS baru merupakan pilihan yang lebih singkat, dan pengetahuan tersebut tetap berguna. Image dan volume merupakan objek yang sama pada kedua engine. Jadi, perpindahan nantinya hanya mengubah cara service Anda dikelola dan hampir tidak mengubah hal lainnya.

FAQ

Apakah Podman merupakan pengganti langsung Docker?

Untuk perintah yang Anda ketik, hampir sama. Menginstal podman-docker menyediakan wrapper /usr/bin/docker, dan run, ps, build, logs, serta exec berperilaku sama. Namun, Podman bukan pengganti daemon. Swarm tidak memiliki padanan, alat yang terhubung ke /var/run/docker.sock harus diarahkan ke socket Podman per pengguna, dan image yang di-pull oleh Docker tetap tidak terlihat oleh Podman karena keduanya menggunakan penyimpanan terpisah.

Mengapa container Podman rootless saya berhenti saat saya logout dari SSH?

Karena systemd menghentikan sesi pengguna beserta semua user service saat login terakhir Anda ditutup. Jalankan sudo loginctl enable-linger <user>, lalu pastikan loginctl show-user <user> --property=Linger menampilkan Linger=yes. Linger membuat instance systemd pengguna tersebut tetap berjalan tanpa sesi aktif. Hal ini juga membuat container berjalan kembali setelah reboot.

Mengapa file dalam volume saya dimiliki oleh UID 100999?

Podman rootless memetakan UID container 0 ke pengguna host Anda, lalu memetakan UID container 1 dan seterusnya ke rentang subuid Anda. Dengan rentang yang dimulai dari 100000, UID container 1000 menjadi 100999 pada host. Perbaiki dari dalam namespace dengan podman unshare chown 1000:1000 /path/to/data, lakukan mount menggunakan flag :U saat pertama kali dijalankan, atau gunakan --userns=keep-id agar UID container sesuai dengan UID Anda sendiri.

Apakah saya dapat tetap menggunakan docker-compose.yml dengan Podman?

Ya, ada dua cara. podman-compose membaca file tersebut dan langsung mengendalikan CLI Podman. Atau, aktifkan socket kompatibilitas dengan systemctl --user enable --now podman.socket, tetapkan DOCKER_HOST=unix:///run/user/$(id -u)/podman/podman.sock, lalu jalankan docker compose yang sebenarnya untuk mengaksesnya. Anda mungkin mengalami kendala pada network_mode: host, pada service yang melakukan mount socket Docker, serta pada restart: always, yang memerlukan unit quadlet dan linger agar tetap berjalan setelah reboot.

Apakah rootless benar-benar membuat container lebih aman?

Rootless menghilangkan satu risiko tertentu: proses yang keluar dari container rootless hanya memiliki izin pengguna Anda yang tidak memiliki hak istimewa, bukan izin root. Hal ini tetap bermanfaat. Karena itu, grup docker yang setara dengan root tidak memiliki padanan pada Podman rootless. Rootless tidak menghentikan kerentanan kernel dan tidak melindungi file yang dapat dibaca oleh pengguna Anda sendiri. Oleh sebab itu, tetap lakukan hardening lain yang akan Anda terapkan pada server mana pun.