Alasan Saya Beralih dari Docker ke Podman

 (codesmash.dev)
14 poin oleh GN⁺ 2025-09-06 | 8 komentar | Bagikan ke WhatsApp
  • Docker telah lama dikritik karena masalah kerentanan keamanan dan konsumsi sumber daya akibat arsitektur daemon latar belakang (dockerd)
  • Podman mengadopsi arsitektur tanpa daemon, sehingga container berjalan langsung dengan izin pengguna, mengurangi attack surface dan meningkatkan stabilitas
  • Dukungan integrasi Systemd, desain yang ramah Kubernetes, serta alat terpisah berbasis filosofi Unix seperti Buildah/Skopeo meningkatkan efisiensi operasional
  • Tetap sangat kompatibel dengan Docker CLI, sehingga sebagian besar workflow lama tetap berjalan hanya dengan alias docker=podman
  • Bahkan di lingkungan produksi nyata, keamanan dan manajemen sumber daya menjadi lebih sederhana, dan untuk proyek baru Podman menjadi pilihan yang lebih masuk akal dan berorientasi masa depan

Keterbatasan Docker dan masalah keamanan

  • Docker memiliki arsitektur di mana daemon dockerd selalu berjalan dengan hak akses root
    • Jika kerentanan pada daemon ditemukan, seluruh host bisa terekspos pada risiko
  • Contoh kasus isu keamanan utama
    • 2019: container escape runC (CVE-2019-5736)
    • 2022: kerentanan Linux Dirty Pipe, escape cgroups v1
    • 2024: runC “Leaky Vessels”, kerentanan BuildKit
    • 2024: kampanye cryptojacking melalui paparan Docker API
  • Peristiwa semacam ini yang terus berulang menunjukkan risiko mendasar dari arsitektur berbasis daemon

Arsitektur daemonless Podman

  • Podman tidak menggunakan daemon latar belakang
    • Saat podman run dijalankan, container bekerja sebagai proses anak langsung dari eksekutor perintah
    • Karena berjalan dalam mode rootless, bahkan hak akses root di dalam container di host hanya setara dengan hak akses pengguna biasa
  • Keunggulan
    • Keamanan meningkat: cakupan dampak saat terjadi container escape berkurang
    • Stabilitas terjaga: jika satu container mati, container lain tidak terdampak
    • Efisiensi sumber daya: penggunaan memori menurun karena tidak ada daemon yang terus aktif tanpa perlu

Fitur pembeda Podman

  • Integrasi Systemd
    • Dapat membuat file unit systemd secara otomatis dengan podman generate systemd
    • Layanan dapat dikelola dengan perintah standar systemctl
  • Ramah Kubernetes
    • Konsep Pod sudah terintegrasi secara bawaan sehingga memudahkan pengembangan aplikasi multi-container
    • Dapat langsung membuat Kubernetes YAML dengan podman generate kube
  • Filosofi Unix
    • Podman fokus pada eksekusi container, sementara build image menggunakan Buildah, dan pengelolaan registry menggunakan Skopeo
    • Memungkinkan penggunaan alat yang dioptimalkan sesuai tujuan

Proses migrasi dan kompatibilitas

  • Peralihan dari Docker ke Podman hampir tanpa gangguan
    • CLI kompatibel sehingga podman dapat digunakan langsung sebagai pengganti docker
    • Dockerfile yang sudah ada juga tetap berfungsi
  • Perbedaannya
    • Dalam mode rootless, binding ke port di bawah 1024 tidak memungkinkan → disarankan memakai reverse proxy
    • Perlu pengelolaan izin volume
    • Alat yang bergantung pada Docker socket dapat menggunakan mode kompatibilitas Docker API milik Podman

Penerapan praktis dan manfaatnya

  • Setelah menggunakan Podman di lingkungan operasional
    • Beban pemeriksaan keamanan berkurang, dengan keamanan rootless diterapkan secara default
    • Pola penggunaan sumber daya menjadi lebih sederhana dan mudah diprediksi
  • Docker masih populer, tetapi untuk proyek baru atau ketika ada kebebasan memilih teknologi, Podman lebih cocok
    • Integrasi alami dengan sistem manajemen Linux
    • Arsitektur yang berorientasi Kubernetes
    • Menyediakan lingkungan eksekusi container yang lebih aman dan rasional

Ringkasan panduan migrasi FastAPI

  • Dockerfile yang ada tetap bisa digunakan
  • Cukup ganti dengan podman build, podman run
  • Daftarkan sebagai layanan systemd dengan podman generate systemd
  • Gunakan Pod untuk mendukung lingkungan multi-layanan seperti DB
  • Workflow Docker Compose dapat ditangani dengan podman-compose atau konversi kompose

Bacaan terkait

8 komentar

 
shortstories 2025-09-09

Di sini tertulis bahwa peralihan tanpa downtime itu memungkinkan, tetapi di lingkungan operasional nyata ternyata ada banyak hal aneh. Misalnya, di lingkungan mac, karena konfigurasi bawaan memakai kompresi zstd, image yang dibangun jadi cukup banyak membebani registry, dan semacamnya..
 
codemasterkimc 2025-09-08

Docker maupun podman semuanya....

securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL

securityContext:
runAsNonRoot: true
runAsUser: UID
 
koxel 2025-09-08

Sebenarnya kompatibilitas dengan Docker tidak terlalu baik, jadi kegunaannya juga tidak begitu bagus...
Saya sempat pindah ke Podman karena mempertimbangkan rootless, lalu akhirnya kembali lagi ke Docker.
Seperti kata orang lain, kalau mau pakai untuk Kubernetes ya sekalian saja pakai containerd.
 
click 2025-09-08

Saya jadi bertanya-tanya, kalau Docker compose tidak berjalan dengan baik dan keunggulannya adalah kompatibilitas Kubernetes yang bagus, bukankah lebih baik langsung pakai Kubernetes saja?
Saya juga sempat ingin mencobanya, tetapi karena tidak bisa langsung berjalan sekaligus dan juga tidak bisa melakukan pemetaan port di bawah 1024 secara langsung, akhirnya saya memakai kombinasi k3s dan nerdctl untuk build image.
 
ndrgrd 2025-09-07

Saya memang sudah lama ingin beralih, tetapi ketika mencobanya sebelumnya, berbeda dari yang sering dikatakan para developer, terlalu banyak proyek docker compose yang tidak berjalan dengan semestinya...
 
afewgoodman 2025-09-07

Dukungan untuk Docker network memang tidak ada.
 
devsepnine 2025-09-07

Setahu saya, seperti Docker, ini juga mendukung fitur jaringan
Apakah masih ada hal yang belum benar-benar berfungsi?
 
GN⁺ 2025-09-06
Komentar Hacker News
  • Pada 2001/2002 saya harus membangun kotak hotspot WiFi. Saat itu saya penggemar OpenBSD, dan ingin membuat distribusi berbasis Python seringan mungkin. Saya memilih konsep chroot dan jail agar bisa menghindari penyalinan file yang tidak perlu dan masalah dependensi. Kode deployment saya menjalankan perangkat lunak di luar lingkungan jail, lalu memantau file yang dibuka proses dengan ptrace. Dari output itu saya mengekstrak daftar dependensi dan memaketkannya. Hasilnya, deployment menjadi kecil, immutable, dan lebih aman. Ketika Docker muncul, saya teringat pendekatan lama itu, dan saya penasaran apakah ada alat serupa yang memantau riwayat penggunaan file kontainer Docker untuk mengecilkan distribusi
    • Pipeline CI/CD terbaik yang pernah saya pakai adalah deployment freelance Django. Saya mengotomatiskan build file statis dan restart httpd pada setiap git push dengan git post receive hook. Tinggal git push live master lalu ter-deploy. Saya sudah banyak memakai Docker, tapi ini adalah deployment termudah. Saya paham kelebihan Docker, tetapi menyiapkan HTTP di Ubuntu atau OpenBSD juga tidak terlalu sulit. Saya ragu apakah reproduksibilitas khas Docker benar-benar sepadan dengan overhead pengelolaan tambahan itu
    • Hasil pertama di Google adalah slimtoolkit/slim dengan 22k bintang
    • Di lingkungan OpenWrt ada alat bernama ujail, yang jika diberi executable ELF akan mem-parsing dependensi library yang dibutuhkan lalu me-mount hanya file penting secara read-only ke tmpfs
      Tautan kode terkait
  • Podman benar-benar pengalaman yang luar biasa bagi saya. Saya merasa memakai Docker itu sulit dan penuh jebakan, sedangkan Podman sama sekali tidak tertinggal. Yang terpenting, perusahaan tempat saya bekerja tidak perlu khawatir soal lisensi. Benar-benar win-win
    • Saya penasaran apakah lisensi memang jadi kekhawatiran di perusahaan. Kebijakan lisensi berbayar Docker Desktop masuk akal. Gratis untuk perusahaan dengan kurang dari 250 karyawan atau pendapatan di bawah 10 juta dolar. Bahkan jika biaya lisensinya $90 per tahun, dibanding gaji developer di AS itu bahkan tidak sampai setara harga makan siang. Lagi pula, Anda mendapat alat resmi yang didukung di semua OS
    • Sebenarnya perusahaan tidak perlu terlalu khawatir soal lisensi. Docker Engine sepenuhnya open source jadi gratis. Hanya Docker Desktop yang butuh lisensi terpisah untuk penggunaan perusahaan. Namun sebagian besar fiturnya tetap bisa dipakai di Docker Engine
    • Podman jauh lebih baik daripada Docker. Tidak perlu khawatir soal penanganan izin user/group atau masalah keamanan proses root. Juga tidak perlu mengirim data ke daemon
    • Di beberapa PC, uninstaller Windows untuk Podman tidak menghapus semua komponen dengan benar, sehingga muncul error saat dijalankan lagi. Bahkan setelah menghapus service secara manual, masalahnya tetap ada. Cukup sering bikin kesal
  • Saya sangat menyukai Podman, tetapi tidak selalu bekerja baik di semua kontainer. Misalnya, kontainer besar seperti gitlab sering error di podman karena bergantung pada sejarah kompleks dan keanehan Docker. Menurut saya, image buatan sendiri umumnya berjalan baik di podman. Untuk kontainer bermasalah, saya menyiasatinya dengan menyalakan VM incus lalu menjalankannya di dalam sana. Cara akses GPU di Podman dan Docker juga sama-sama tidak konsisten sehingga merepotkan. Meski begitu, saya tetap merasa podman sedikit lebih baik. Terutama karena rootless adalah keunggulan besar
    • Saya menduga sebagian besar masalah berasal dari image yang memulai PID 1 sebagai root. Podman secara default rootless, jadi masalah seperti ini bisa muncul. Jika ingin tetap memakai image berbasis root tanpa Docker, Anda bisa memisahkan Podman mode rootful dan rootless lalu memakai flag --connection untuk memilih lingkungan yang diinginkan. Jika perlu, Podman juga bisa membuat VM otomatis untuk Anda (menggunakan lima). Podman Desktop juga punya lapisan kompatibilitas Docker untuk mengurangi masalah kompatibilitas
    • Fakta bahwa beberapa kontainer tidak berjalan di podman itulah yang kemungkinan menjadi motivasi tulisan blog itu. Jika basis penggunanya cukup besar, kebiasaan memeriksa lingkungan podman sebelum publikasi akan mulai terbentuk
    • Kami menjalankan server dan runner GitLab sepenuhnya di podman. Secara pribadi saya berharap runner dipindahkan ke k8s, tetapi saat ini semuanya berjalan baik dengan Traefik
    • Saya banyak memakai fitur terkait buildx, dan meskipun kelihatannya podman juga mendukung, kenyataannya tidak benar-benar berjalan baik
  • Dukungan podman di Ubuntu adalah masalah terbesarnya. Versi podman bawaan Ubuntu terlalu tua sehingga tidak bisa langsung dipakai. Saya memakai podman v5, GitHub Actions memakai v3, rekan kerja saya memakai docker. Akhirnya muncul kompleksitas karena saya harus membuat skrip yang berjalan di podman lama, podman terbaru, dan docker sekaligus
    • Tidak ada repositori distribusi build .deb yang bisa diandalkan. Tidak ada .deb resmi, dan semua yang saya temukan sudah tua atau disebut tidak akan diperbarui lagi. Jadi muncul pertanyaan: kenapa Podman tidak membuat instalasi lebih mudah? Menurut saya, karena RedHat tidak ingin menghabiskan sumber daya pengembangan untuk mendukung produk pesaing. Wajar saja, tetapi di luar ekosistem RedHat rasanya seperti diperlakukan sebagai warga kelas dua
    • Menurut saya ini masalah terbesar. Rendahnya pengenalan dibanding Docker memang masalah, tetapi mismatch versi jauh lebih besar dalam membuat Podman tetap jadi niche. Distro seperti Ubuntu sering menyediakan perangkat lunak lama, dan ini memang harus diselesaikan oleh para maintainer, tetapi pihak Podman sendiri tampaknya tidak terlalu aktif dalam hal itu. Karena ini, saya bahkan mengganti homeserver saya ke keluarga Red Hat hanya agar bisa memakai Podman terbaru
    • Tidak tersedianya .deb upstream resmi secara konsisten membuat kami tidak bisa memakai Podman secara internal. Saya iri karena Docker punya repo .deb resmi yang dikelola dengan baik
    • Ini salah satu alasan saya tidak memakai Ubuntu/Debian: update-nya terlalu lambat. Mungkin bisa dipakai lewat flatpak, tetapi software seperti ini sebaiknya tersedia secara default
    • Karena Podman itu open source, tempat seperti Ubuntu bisa memaketkan dan memperbaruinya sendiri. Saya juga paham kalau RedHat enggan sampai harus mendukung pemaketan software pesaing secara langsung
  • Baru-baru ini saya mengalami setup Podman karena pekerjaan kantor, dan itu salah satu pengalaman terburuk saya. Kombinasi rootless Podman + SELinux + user biasa di dalam kontainer benar-benar neraka
    • Sebenarnya kalau mau bikin susah, apa pun bisa jadi susah, tetapi dalam praktiknya kebanyakan berjalan baik. Saya menjalankan beberapa service (Forgejo, runner, uptime-kuma, dll.) sebagai kontainer rootless di belakang reverse proxy nginx pada mesin RHEL10 dengan SELinux aktif, dan semuanya bekerja dengan baik
    • Saya tidak pernah sekali pun merasakan manfaat rootless. Jika mesin itu satu domain keamanan, ya sudah jalankan saja sebagai root, dan kalau bukan, seharusnya pakai lingkungan yang benar-benar terisolasi seperti VM Firecracker/Kata. Rootless terasa merepotkan tanpa manfaat yang jelas
    • Saya juga mengalami situasi yang sama di kantor, tetapi kalau diselesaikan dengan cara khas podman itu sendiri (lihat docs), masih cukup layak dipakai. Kuncinya adalah melihat dokumentasi untuk versi terbaru
    • Saya sudah memakai podman saja di Fedora selama lebih dari 7 tahun
    • Organisasi kami melakukan migrasi penuh dari Docker ke Podman, dan meskipun sempat ada gangguan di tengah jalan, kemampuan tim SysDev membuat semuanya terselesaikan dengan cukup mulus
  • Ada yang bilang kalau workflow Docker Compose terlalu rumit, langsung saja ubah ke Kubernetes YAML, tetapi menurut pengalaman saya YAML K8s jauh lebih rumit daripada docker compose. Dan tidak semua orang memakai Kubernetes
    • Pendapat saya justru kebalikan. YAML K8s kompleksitasnya mirip dengan docker compose, bahkan kadang lebih sederhana. Hanya saja sangat verbose. Compose 100 baris bisa terpecah menjadi 20 file YAML masing-masing 50 baris. Akan bagus kalau kubectl punya semacam sugar untuk saling mengubah YAML sederhana/kompleks
    • Saat mengubah docker compose menjadi k8s yaml, memakai LLM sebagai layer bekerja sangat baik. Sebagai referensi, podman juga punya fitur membuat k8s yaml, jadi transisinya bisa alami
    • Saya tidak tahu cara membuat file compose, tetapi saya bisa membuat k8s yaml. Jadi compose justru terasa lebih "rumit" bagi saya
  • Perintah podman generate systemd yang disebut di artikel sekarang sudah deprecated. Alternatifnya adalah Podman Quadlets, yang mirip docker-compose.yaml tetapi didefinisikan di dalam file unit systemd
    • Menyerahkan compose/orchestration ke systemd memang logis. Karena bukan struktur client-server seperti docker, melainkan benar-benar proses user, itu pilihan yang jelas masuk akal
    • Masalahnya adalah hampir tidak ada dokumentasi
  • Sulit memetakan kontainer multi-UID ke satu user host. Secara default, root di dalam kontainer dipetakan ke user yang menjalankannya di host, tetapi belakangan banyak aplikasi mulai memakai user non-root di dalam kontainer (misalnya www-data, user 1000, dll.). Mereka dipetakan ke ID sekunder di host, dan ini membuat kepemilikan file pada volume mapping menjadi yatim sehingga sangat membingungkan. Saya merasa kurang adanya opsi sederhana untuk memetakan semua UID ke satu user, dan opsi yang ada (uidmap crun, userns) tidak bekerja dengan baik. Saya ragu soal efektivitas pemetaan ID sekunder ini
    • Kalau pemahaman saya benar, ini adalah batasan namespace Linux. Agar alat seperti Docker atau Podman mendukung pemetaan seperti ini, Linux sendiri harus mendukungnya. Alasan pemetaan UID 1:1 itu penting adalah karena kalau user 1000 dan 0 di dalam kontainer dipetakan ke user host yang sama, informasi pemilik file jadi kacau
    • Mungkin layak mempertimbangkan idmapped mount. Itu hanya mendukung remapping file system, dan tidak menyelesaikan panggilan kernel
    • Akan bagus kalau ada cara agar di dalam kontainer semuanya tetap berjalan sebagai "dirinya sendiri". Dengan begitu kepemilikan juga tercatat apa adanya di log
    • Jika memakai opsi ignore_chown_errors, Anda bisa memetakan root ke user ID dengan sederhana tanpa pemetaan tambahan apa pun
  • Saya sudah beberapa kali mencoba migrasi ke Podman, tetapi gagal di banyak titik. Pertama, performa podman di VPS kecil saya jauh lebih buruk daripada docker (detailnya saya lewati). Kedua, ekosistem pengembang belum sepenuhnya mengikuti. Banyak alat bergantung pada socket Docker, tetapi podman sering tidak bekerja baik karena masalah izin atau perbedaan kompatibilitas API. podman bukan pengganti drop-in yang sempurna
    • Jaringan lambat saat memakai rootless podman mungkin disebabkan oleh slirp4netns. pasta adalah pendekatan yang lebih cepat. Docker secara default menyiapkan jaringan lewat daemon berprivileg, jadi jika Anda memakai podman sebagai root, seharusnya tidak ada perbedaan performa
    • Error izin SELinux di podman dan quadlet terus menjadi sumber masalah. Sebisa mungkin, lebih mudah membuat pod host dengan izin penuh, me-mount hanya /dev yang diperlukan, lalu mengekspos program yang sangat terbatas pada jaringan yang terisolasi
    • Menariknya, di sistem saya yang kekurangan resource, podman jauh lebih unggul daripada docker dalam performa dan penggunaan resource. Sepertinya ini karena perbedaan crun dan runc. Selain itu, podman juga lebih ringan karena tidak punya daemon
  • Saya meninggalkan Docker dan Podman lalu beralih ke FreeBSD Jails
    • Informasi lebih lanjut dan alat pengelolaannya bisa dilihat di sini,
      di sini,
      di sini,
      dan di sini
    • Apakah Anda bisa langsung menjalankan MS SQL Server atau ribuan kontainer docker di dalam FreeBSD jail? Memilih FreeBSD menuntut harga yang besar untuk dibayar, seperti keterbatasan kompatibilitas. Itulah alasan jails tidak bisa menjadi arus utama
    • Setup-nya benar-benar banyak; saya penasaran apakah di FreeBSD juga ada sesuatu seperti containerd
    • FreeBSD jails adalah fitur yang sangat spesifik distro
    • Saya penasaran apa bedanya menjalankan VM di host Linux dengan FreeBSD jail