Podman v6.0.0 dirilis

• Podman v6.0.0 adalah rilis mayor yang memoles pengalaman pengelolaan container, sekaligus mencakup modernisasi infrastruktur inti serta peningkatan keamanan dan kegunaan
• Networking bergeser dari fokus pada slirp4netns dan iptables ke basis Netavark, Pasta, dan nftables, mengurangi beban pemeliharaan dan menyiapkan perluasan fitur berikutnya
• Fitur eksperimental Pesto rootless port forwarding mendukung pelestarian source IP yang benar pada container rootless di jaringan kustom
• Podman Machine meningkatkan kegunaan untuk berbagai penyedia VM, dan memungkinkan lingkungan VM tetap mutakhir dengan podman machine os update
• Quadlet, pemrosesan file konfigurasi, kompatibilitas Docker API, dan output perintah juga dipoles, sehingga pengelolaan multi-pengguna dan migrasi dari Docker menjadi lebih mudah

---

Yang berubah di Podman v6.0.0

• Rilis terbaru dapat dilihat di halaman rilis GitHub, dan akan segera didistribusikan juga melalui package manager

• Modernisasi networking

  • Beralih dari slirp4netns dan iptables ke Netavark, Pasta, dan nftables
  • Stack networking yang dirapikan menyederhanakan pemeliharaan dan menjadi fondasi untuk penambahan fitur di masa depan
  • Dukungan eksperimental Pesto rootless port forwarding memungkinkan pelestarian source IP yang benar pada container rootless di jaringan kustom

• Peningkatan Podman Machine

  • Kegunaan ditingkatkan agar berbagai penyedia VM dapat ditangani dengan lebih mulus
  • Perintah podman machine os update memungkinkan lingkungan VM tetap mutakhir
  • Peningkatan tambahan terkait akan dibahas lebih detail dalam tulisan terpisah di masa mendatang

• Perluasan Quadlet

  • Dukungan REST API ditambahkan
  • Pelacakan file terkait ditingkatkan sehingga pengelolaan menjadi lebih mudah
  • Fitur unit .volume diperluas
  • Jalur pencarian tambahan untuk memudahkan packaging distribusi disertakan

Konfigurasi dan kompatibilitas Docker

• Pemrosesan file konfigurasi berubah sehingga administrator yang mengelola lingkungan multi-pengguna dapat menggunakannya dengan lebih mulus dan andal
  • Detailnya dapat dilihat di Podman 6 configuration file changes
• Kompatibilitas Docker juga ditingkatkan
  • Dukungan Docker API diperbarui
  • Output perintah dipoles sehingga migrasi dari Docker ke Podman menjadi lebih mudah
• Daftar perubahan lengkap dirangkum dalam Podman v6.0.0 release notes

[click]

Saya berniat pindah kalau podman compose sudah layak dipakai, tapi entah kapan itu akan benar-benar layak dipakai.
Menurut saya belakangan ini menjalankan langsung dengan docker run hanya untuk container sementara atau eksekusi pengujian, jadi dukungan compose yang kurang baik adalah kelemahan besar.
Kalau butuh konfigurasi yang panjang dan manajemen yang pasti, lebih baik pakai k8s saja.
Di era modern tahun 2026, daya tarik docker atau podman adalah bisa mendefinisikan seluruh stack yang dipakai satu aplikasi dengan satu file konfigurasi yml yang sederhana, tanpa berbagai definisi resource k8s.
Kalau mau mengedepankan kompatibilitas k8s, jauh lebih baik memakai implementasi k8s ringan yang berjalan lokal seperti k3s, minikube, atau microk8s.
Menurut saya rootless bukan masalahnya.

[GN⁺]

Opini Hacker News

• Saya tidak mengerti mengapa Docker masih jauh lebih populer daripada Podman. Dari sisi implementasi saja, Podman jelas lebih baik, dan fitur jaringan baru ini juga merupakan peningkatan yang menyenangkan

  • Alasan utamanya mungkin karena distribusinya sedikit lebih merepotkan dan ada lebih banyak langkah yang terpisah-pisah. Terutama jika ingin memakai rootless, dan sebenarnya memang seharusnya begitu
    Bagi orang yang tidak mengutamakan Linux, misalnya developer pemula yang sedang belajar melakukan kontainerisasi aplikasi, harus berurusan dengan file unit systemd atau konfigurasi kubelet, membuat akun layanan lokal khusus, dan mengingat untuk mengaktifkan linger terasa jauh lebih mengintimidasi daripada menginstal Docker, membuat file docker compose, lalu menekan “start”
    Saya mengerti mengapa pendekatan ini dipilih, tetapi rasanya cukup kaku dan tidak ramah
  • fuse-overlayfs terasa jelas lebih lambat daripada konfigurasi overlayfs milik Docker. Mungkin ada cara untuk mengonfigurasinya ulang, tetapi belakangan ini saya belum mengeceknya
    Seingat saya, saat membangun ghostty dengan Zig, prosesnya gagal di Podman dengan error “unknown file” yang tidak jelas, dan ternyata penyebabnya adalah fuse-overlayfs tidak mendukung beberapa atribut yang hendak diperiksa
    Setiap kali mencoba beralih, masalah-masalah kecil acak seperti ini terus menghambat. Saya memakainya untuk penggunaan sederhana
  • Terakhir kali saya cek, podman compose hanya mirip secara tampilan dengan docker compose. Hal seperti inotify juga tampaknya cukup sering rusak secara acak di Podman
    Saya ingin merekomendasikan Podman, tetapi kompatibilitas docker compose yang buruk dan hilangnya inotify pada volume membuat pengalaman developer terlalu bermasalah
  • Nama merek yang lebih kuat juga tampaknya menjadi alasan. Di macOS, Docker Desktop terasa lebih intuitif. Namun belakangan ini error-nya menjadi sangat sering, dan pembersihan aturan file mount atau jaringan gagal secara acak, atau tiba-tiba menjadi sangat lambat sehingga VM harus direstart
    Podman di macOS terasa jauh kurang dipoles, dan OrbStack adalah pilihan yang jauh lebih baik
    Saya hanya memakai Podman di Linux, dan di sana sangat cepat. Meski begitu, sebagian besar fiturnya tampak lebih diarahkan untuk menggantikan Kubernetes melalui integrasi dengan systemd, sementara dukungan docker compose justru tidak stabil dan TUI/UX-nya juga tertinggal dari aslinya
  • Saya menyerah memakai Podman karena alasan-alasan kecil. Salah satunya adalah Podman memilih menangani SELinux secara berbeda dari Docker, sehingga pada sistem CentOS standar perlu mengubah label keamanan SELinux. Itu tidak bisa diterima
    Masalah lain adalah perbedaan-perbedaan kecil dengan Docker, sampai-sampai Docker compose yang sudah dipaketkan tidak berjalan apa adanya. Kalau beralih ke Docker, semuanya langsung berjalan dan saya bisa melanjutkan pekerjaan hari itu; saya tidak mau menghabiskan waktu untuk men-debug hal itu

• Setelah Docker Desktop lagi-lagi mulai memakan memori sangat besar secara acak, saya beralih ke Podman, dan benar-benar semudah menginstalnya lalu menunjuk ke docker-compose.yml
  Tidak perlu perubahan sama sekali, dan sekarang tidak perlu terus menjalankan daemon. Perangkat lunak yang hebat

  • colima lebih baik daripada Docker Desktop, dan Orbstack lebih baik daripada colima. Lalu saya menemukan microVM smolvm dari https://smolmachines.com's
  • Karena omong kosong AI dari Docker akhirnya melewati batas, saya mencoba beralih ke Podman, tetapi menemui beberapa masalah kompatibilitas. Itu beberapa bulan lalu, jadi saya tidak ingat detailnya
    Jadi saya mencoba Rancher Desktop, dan selain saya terus lupa namanya, itu berjalan dengan baik. Ini opsi sederhana lain bagi yang membutuhkan

• Saya sangat menyukai Quadlet. Selama beberapa tahun saya meng-host container rootless dengan Hetzner, Ansible, SystemD, dan RockyLinux tanpa masalah, lalu mengekstrak konfigurasi itu menjadi repositori template
  [1] https://github.com/Mati365/hetzner-podman-bunjs-deploy

  • Setelah mengganti home server dari k3s ke quadlet, penggunaan daya turun 8%

• Saya penasaran dengan pengalaman orang yang pindah dari Docker ke Podman
  Di homelab/konfigurasi otomatisasi saya ada banyak file compose, jadi itu yang paling saya khawatirkan

  • Saya pindah dari Docker ke Podman sekitar 15 bulan lalu, dan tidak berniat kembali lagi. Secara pribadi quadlet, yaitu integrasi systemd, benar-benar bagus, dan membuat pemantauan kumpulan layanan yang sedang berjalan—baik layanan systemd biasa maupun container—jauh lebih mudah
    Eksekusi rootless juga sangat intuitif, dan Podman sangat cepat. Secara pribadi saya tidak terlalu merindukan docker compose, tetapi saya paham ketiadaan docker compose bisa jadi masalah fatal bagi orang lain. Saya belum pernah mencoba plugin compose milik Podman
  • Di homelab, saya mengubah file docker compose yang besar menjadi podman quadlet. Seingat saya, saat memindahkan beberapa layanan pertama, butuh waktu karena dokumentasi dan contoh quadlet tidak sebanyak file compose, tetapi setelah itu sangat mudah. Sangat direkomendasikan
    Satu-satunya masalah adalah validasi. Tidak ada perintah bawaan yang praktis untuk memvalidasi file quadlet, dan systemd juga tidak memberi peringatan jika pembuatan gagal. Anda harus menjalankan --dry-run dulu, membuat alias yang sesuai untuk seluruh perintah, atau memeriksa error di journal
  • Saya pindah beberapa tahun lalu, sebelum 5.0, dan tidak pernah menoleh ke belakang. Untuk file compose, quadlet layak dipertimbangkan
    Untuk konversi cepat, Anda bisa langsung memakai podman-compose, atau mengatur docker compose agar mengarah ke socket Podman[0]
    Ada juga podlet[1] yang mengubah file compose menjadi quadlet native. Untuk file compose yang sederhana atau dengan kompleksitas menengah, sebagian besar ditangani dengan baik secara otomatis dan langsung berjalan. Ada juga pembicaraan untuk menjadikannya dalam bentuk library agar tool lain dapat mengonversi file compose ke quadlet secara transparan, jadi saya berharap akan ada lebih banyak tool serupa ke depannya
    Jika Anda sedikit saja familier dengan file unit systemd, menulis file Quadlet sendiri juga tidak sulit. Sebagian besar argumen docker run atau podman run punya padanan langsung di quadlet, jadi setelah terbiasa dengan format INI alih-alih YAML, mudah untuk melihat file compose dan membuat quadlet yang ekuivalen
    [0] https://www.redhat.com/en/blog/podman-docker-compose
    [1] https://github.com/containers/podlet
  • Sekitar 1–2 tahun lalu saya memindahkan semuanya ke Podman rootless. Beberapa container mengalami masalah izin saat membaca data lama, karena dijalankan dengan UID yang berbeda
    Itu saja masalah yang benar-benar saya alami, dan masalah yang sama kemungkinan juga akan muncul jika pindah dari Docker dengan hak root ke Docker rootless. Sama sekali tidak menyesal dan tidak akan pernah kembali
  • Saya merasa berterima kasih kepada Podman sebesar rasa terima kasih saya kepada git
    Podman matang dan masuk akal. Jika container seseorang bergantung pada hak su, saya menyalahkan orang itu, bukan Podman

• Hal yang tidak saya sukai dari Podman adalah ia berpura-pura kompatibel dengan Docker, tetapi ada perbedaan-perbedaan kecil yang kemudian akan menggigit. Pengguna proyek berbasis Docker mencoba menjalankannya dengan Podman, lalu akhirnya datang ke proyek tersebut untuk mengeluh

  • Sebagian besar perbedaannya bukan berasal dari API socket, perilaku logis, atau perbedaan command line. Masalahnya terutama muncul karena Docker berasumsi bahwa ia dijalankan dengan hak root, sedangkan Podman secara default tidak begitu
    Jadi memperbaiki inkompatibilitas Podman/Docker umumnya berarti menangani asumsi itu. Caranya misalnya menambahkan beberapa flag ke perintah Podman untuk mengubah cara pemetaan namespace pengguna antara container dan host
  • Saya sudah memakai Podman di Mac dan Linux selama 3 tahun, dan sayangnya masalah ini selalu benar. Saya bersedia menelusuri akar penyebabnya dengan gigih dan melaporkan bug, tetapi bagi banyak orang itu hanya akan terlihat seperti rusak
    Yang terbaru, perilaku Netavark dalam menerima traffic broadcast pada port yang dipublikasikan tidak cocok dengan Docker
  • Benar. Karena ini, saya jadi enggan memakai Podman selama beberapa tahun. Sekarang saya melihatnya punya ide yang cerdas, dan jika memakai RHEL itu pilihan yang jelas, tetapi mereka perlu lebih jujur bahwa perlu adaptasi
    Terutama jika pindah dari Docker dengan hak root ke Podman rootless

• Saya penasaran bagaimana Podman sekarang. Di macOS saya memakai OrbStack dan rasanya jauh lebih cepat. Kalau macOS 27 menambahkan container Linux berbasis microVM yang lebih native dan berperforma baik, mirip WSL, entah bagaimana peta persaingannya nanti

  • Saya tidak begitu tahu soal macOS, tetapi di Linux ia cocok dengan mulus untuk kebutuhan saya. Satu hal yang perlu diperhatikan adalah Podman Compose memakai docker-compose sebagai provider default
    Saya belum mencoba provider podman-compose, dan namanya sedikit membingungkan karena mirip dengan Podman Compose. Podman Compose adalah abstraksi tingkat atas di atas docker-compose atau podman-compose. Jika perlu, dengan Podman Anda juga bisa menjalankan container melalui engine Docker
  • Pertanyaan yang sama dan situasi yang sama. Saya mencobanya di MacOS, dan untuk memahami masalah pertama yang saya temui, saya harus masuk jauh ke forum Redhat. Beralih ke OrbStack adalah pilihan yang jelas, tetapi ada trade-off yang jelas dari sisi fitur

• Quadlet dan container rootless adalah dua alasan besar untuk pindah dari Docker ke Podman

  • Rootless adalah alasan saya pindah ke Podman beberapa tahun lalu. Benar-benar mulus, dan sekarang saya tidak perlu khawatir soal masalah izin atau error layanan yang samar

• Podman bagus, tetapi saya tidak mengerti kenapa warna teks abu-abu itu seperti itu. Tampilannya kurang bagus, sulit dibaca karena rasio kontras 4,96:1, dan bahkan tidak mencapai level WCAG AAA

• Saya menjalankan server rumah dengan podman + quadlets selama sekitar 2 tahun, dan melihat beberapa hal yang layak diperhatikan di catatan rilis
  podman quadlet list ditambahkan di v5.6.0, dan menampilkan daftar quadlet beserta containernya
  podman system migrate --migrate-db adalah flag yang ditambahkan di v5.8.0. Dulu saya melihat peringatan penghentian dukungan bolt DB, tetapi belum ada tool untuk migrasi ke sqlite; sekarang sudah ada. Atau kalau naik ke podman 6.0.0, itu akan ditangani otomatis

• Saya penasaran dengan pengalaman menggunakan Podman untuk membangun image bagi runtime CRI, bukan Docker
  Jika membangun image dengan Podman, apakah image itu bisa dijalankan di cri-o, Docker, dan berbagai runtime lainnya?
  Karena docker build membutuhkan sudo sehingga merepotkan dalam alur kerja berbasis agen, saya sedang mempertimbangkan untuk membangun image dengan Podman rootless