Belajar Podman - Sejarah, Latar Belakang & Mengapa Membutuhkan Podman
Menelusuri asal-usul Podman dari Red Hat: fondasi libpod dan containers, kedudukannya sebagai alternatif daemonless terhadap Docker, perkembangan dari versi 4 hingga 6.0, serta masalah keamanan, rootless, pods, dan kompatibilitas CLI yang diselesaikannya.
#Pendahuluan
Di episode 0 kalian sudah menyiapkan environment Podman di Linux atau macOS dan menjalankan podman --version untuk pertama kali. Sekarang saatnya bertanya: dari mana alat ini berasal, dan mengapa kalian harus peduli? Episode 1 ini menceritakan sejarah dan latar belakang Podman, lalu memetakan masalah-masalah yang ingin diselesaikannya.
Dengan memahami alasan lahirnya Podman, kalian akan lebih mudah menebak desain setiap perintah yang akan dipelajari di episode-episode berikutnya. Sebagian besar keputusan desain Podman adalah jawaban langsung atas satu masalah yang ada di Docker.
Perhatikan pola ini selama membaca seri — hampir setiap fitur Podman selalu bisa dikembalikan ke satu masalah konkret yang ingin dipecahkan.
#Sejarah Singkat Podman
Podman lahir dari Red Hat, di atas fondasi dua proyek lain: libpod yang merupakan pustaka inti untuk mengelola container dan pods, serta containers/common yang berisi konfigurasi bersama seperti registri dan storage. Gabungan keduanya melahirkan Podman sebagai container engine yang utuh.
Munculnya Podman awalnya adalah respons terhadap Docker. Docker mempopulerkan container, tetapi desainnya memakai daemon sentral yang berjalan sebagai root. Podman hadir sebagai alternatif daemonless: setiap container ditangani langsung tanpa proses daemon yang mengawasi semua container sekaligus.
Perkembangan Podman bisa dirangkum dalam tabel berikut:
| Versi | Tahun | Poin Penting |
|---|---|---|
| Podman 4 | 2022 | Kematangan fitur pods dan networking |
| Podman 5 | 2024-2025 | Penyempurnaan networking dan tooling |
| Podman 6.0 | Juni 2026 | Rilis besar terbaru dengan pengembangan lanjutan |
Selain itu, proyek Podman sedang dalam proses menuju CNCF incubation — status pengakuan sebagai proyek cloud-native yang dikelola komunitas. Ini menandakan Podman bukan eksperimen sesaat, melainkan proyek dengan ekosistem dan dukungan yang terus tumbuh.
#Ekosistem di Sekitar Podman
Podman tidak dibangun sendirian. Ia tumbuh di tengah ekosistem proyek container Red Hat yang dikembangkan secara terbuka dan terkoordinasi. Fondasinya berupa pustaka bersama:
- libpod — pustaka yang menjadi otak Podman dalam mengelola container dan pods.
- containers/common — konfigurasi dan utilitas bersama, termasuk pengaturan registri dan storage.
Karena fondasi ini terbuka dan dipakai bersama, alat-alat lain seperti Buildah dan Skopeo berbicara dalam format yang sama. Akibatnya, kalian bisa mencampur perintah dari proyek yang berbeda tanpa khawatir ketidakcocokan format — sesuatu yang akan dibuktikan langsung di episode 2.
#Masalah yang Diselesaikan
Kehadiran Podman menjawab empat masalah utama yang melekat pada desain Docker.
#Tanpa Daemon: Lebih Aman dan Ringan
Docker memakai arsitektur client-server: daemon berjalan terus-menerus, dan setiap perintah klien berkomunikasi dengannya. Podman menghilangkan lapisan itu.
| Aspek | Docker | Podman |
|---|---|---|
| Arsitektur | Client-server dengan daemon sentral | Daemonless, fork/exec langsung |
| Pengguna | Daemon berjalan sebagai root | Rootless by default |
| Siklus hidup daemon | Container bergantung pada daemon | Container berjalan tanpa daemon |
| Permukaan serangan | Daemon root jadi target utama | Tidak ada daemon yang menunggu serangan |
Tanpa daemon, tidak ada proses sentral yang selalu berjalan sebagai root — sehingga permukaan serangan lebih kecil dan footprint lebih ringan. Model fork/exec ini akan dibedah lebih dalam di episode 2.
#Rootless by Default
Di Docker, operasi container umumnya membutuhkan hak akses root karena daemon berjalan sebagai root. Podman membalikkan asumsi ini: pengguna biasa bisa menjalankan container tanpa sudo, berkat user namespace remapping. Kalian akan mempelajari mekanismenya di episode 5.
#Pods ala Kubernetes
Podman meminjam konsep pod dari Kubernetes: sekelompok container yang berbagi network namespace dan resource. Ini menjembatani mentalitas pengembang yang biasa menulis deployment Kubernetes dengan alat yang sama di laptop mereka. Konsep pod akan dijelaskan di episode 6.
#CLI Drop-in Docker-compatible
Perintah Podman sengaja dibuat semirip mungkin dengan Docker:
docker run -d -p 8080:80 nginx:latest
podman run -d -p 8080:80 nginx:latestBahkan kalian bisa membuat alias agar kebiasaan mengetik docker tetap bekerja:
alias docker=podmanDengan kompatibilitas ini, siapa pun yang sudah terbiasa dengan Docker bisa langsung produktif dengan Podman tanpa belajar dari nol.
Note
podman run -d -p 8080:80 nginx:latest akan dipakai sebagai contoh berulang di seri ini. Biasakan membacanya: -d menjalankan di background, -p memetakan port host ke port container, dan nginx:latest adalah nama image.
#Rangkuman Masalah dan Solusi
Agar mudah diingat, berikut peta dari masalah ke jawaban Podman:
| Masalah pada Docker | Jawaban Podman |
|---|---|
| Daemon root yang selalu berjalan | Daemonless, fork/exec |
| Butuh sudo untuk menjalankan container | Rootless by default |
| Mentalitas container tunggal | Pods ala Kubernetes |
| CLI proprietary | Drop-in Docker-compatible |
Ketika kalian menemui pertanyaan "kenapa perintah ini dirancang begini", coba kembalikan ke tabel di atas — hampir selalu ada satu masalah Docker yang sedang dijawab.
Tip
Jika kalian datang dari Docker, jangan buang kebiasaan lama — bawa saja. alias docker=podman di ~/.bashrc membuat transisi terasa mulus, sementara kalian menyerap konsep daemonless sedikit demi sedikit.
#Penutup
Episode 1 menutup pertanyaan "mengapa Podman": lahir dari Red Hat di atas libpod dan containers/common sebagai jawaban daemonless terhadap Docker, berkembang dari Podman 4 ke 6.0, melaju menuju CNCF incubation, dan menyelesaikan masalah daemon berjalan sebagai root, kebutuhan sudo, mentalitas pods, serta kompatibilitas CLI.
Inti yang harus dibawa pulang:
- Daemonless adalah pembeda utama — tanpa daemon sentral berarti lebih aman dan lebih ringan.
- Rootless by default — pengguna biasa menjalankan container tanpa sudo.
- Pods ala Kubernetes — Podman menjembatani laptop ke cluster.
podman run -d -p 8080:80 nginx:latestadalah baris yang akan kalian kenal baik.
Episode 2 berikutnya membongkar arsitektur di balik klaim daemonless: bagaimana setiap container dijalankan langsung oleh runtime sebagai child process, siapa saja anggota ekosistemnya, dan mengapa kepatuhan terhadap standar OCI membuat semua ini saling kompatibel.