Belajar Podman - Konsep Dasar & Arsitektur Utama

#Pendahuluan

Episode 1 menjelaskan mengapa Podman ada: sebagai alternatif daemonless terhadap Docker. Episode 2 ini membuka kap mesinnya — bagaimana arsitektur daemonless benar-benar bekerja, siapa saja komponen ekosistemnya, dan mengapa standar OCI membuat semuanya saling terhubung. Setelah ini, kalian tidak lagi melihat Podman sebagai sekadar perintah, melainkan sebagai arsitektur.

#Daemonless dan Fork/Exec

Klaim utama Podman adalah tidak memakai daemon. Bagaimana caranya? Model yang dipakai disebut fork/exec.

Ketika kalian menjalankan perintah podman run, alurnya seperti ini:

1. Client podman melakukan serangkaian persiapan: membaca konfigurasi, menyiapkan storage, dan memuat image.
2. Proses client me-fork sebuah proses anak, yang kemudian mengeksekusi container runtime.
3. Runtime — bisa crun atau runc — menjalankan container sebagai child process langsung dari proses tersebut.
4. Proses conmon kecil mengawasi container, meneruskan log, dan menjaga agar container tidak menjadi proses zombie.

Karena tidak ada daemon sentral, setiap container adalah turunan langsung dari proses yang memintanya. Bandingkan dengan Docker yang harus berkomunikasi dengan daemon yang selalu berjalan:

#Dua Pilihan Runtime

Podman mendukung lebih dari satu runtime, dan keduanya adalah implementasi dari standar yang sama:

• crun — ditulis dalam C, cenderung lebih ringan dan cepat; ini default di banyak distro modern.
• runc — ditulis dalam Go, merupakan runtime yang juga dipakai Docker selama bertahun-tahun.

Perbedaan bahasa pemrograman tidak mengubah perilaku dari sisi kalian — keduanya menjalankan container sesuai standar yang sama. Yang penting adalah bahwa keduanya berjalan sebagai child process, bukan di bawah satu daemon.

Kalian bisa membuktikan model ini sendiri: jalankan container, lalu amati prosesnya dari host:

podman run -d --name web nginx:latest
ps -ef | grep conmon
ps -ef | grep nginx

Kalian akan melihat proses conmon dan proses nginx yang berjalan sebagai proses biasa di host — bukan di bawah satu proses daemon. Ini bukti paling nyata dari model fork/exec.

#Ekosistem Proyek Container

Podman hanyalah satu dari sekian proyek yang membentuk ekosistem container Red Hat. Masing-masing memegang peran spesifik:

Pembagian peran ini membuat setiap proyek fokus pada satu pekerjaan: Podman untuk operasi runtime, Buildah untuk membangun image, Skopeo untuk memindahkan image, dan CRI-O untuk mesin container Kubernetes.

#Hubungan Antar Proyek

Proyek-proyek ini tidak bekerja dalam silo. Contoh nyata kerja samanya:

• Buildah membangun, Podman menjalankan — image yang dibuat Buildah langsung dikonsumsi Podman tanpa konversi, karena keduanya berbagi format image yang sama.
• Skopeo memindahkan, Podman memakai — Skopeo bisa menyalin image antar registry dan bahkan antar format, lalu hasilnya di-pull oleh Podman.
• CRI-O di cluster, Podman di laptop — keduanya memakai runtime OCI yang sama, sehingga image yang berjalan di Podman juga berjalan di Kubernetes.

Alur kerja ini adalah alasan kalian sering melihat Podman, Buildah, dan Skopeo dipasang berdampingan di satu mesin. Di episode 4, kalian akan memakai Skopeo secara langsung.

#Storage dan Registri Config

Di balik layar, Podman membaca konfigurasi untuk menentukan di mana image disimpan dan dari mana image diambil. Storage diatur di containers/storage, sementara registri diatur lewat registries.conf:

registries.conf

[registries.search]
registries = ["docker.io", "quay.io"]
 
[registries.insecure]
registries = []

registries.search menentukan urutan registry yang dicari saat kalian memanggil image tanpa prefix penuh, seperti podman pull nginx. Bagian insecure berisi registry yang diizinkan memakai HTTP tanpa TLS — sebaiknya biarkan kosong di lingkungan produksi.

#OCI Compliance

Agar semua proyek ini bisa bekerja bersama, ada satu pengikat: standar dari OCI (Open Container Initiative). Ada dua spesifikasi inti yang relevan:

• Runtime spec — mendefinisikan bagaimana sebuah container dieksekusi: namespace, cgroups, mount, dan proses apa yang dijalankan. crun dan runc adalah implementasi dari spesifikasi ini.
• Image spec — mendefinisikan format image: bagaimana layer disusun, manifest, dan metadata. Image yang mematuhi standar ini bisa dijalankan oleh runtime mana pun yang juga mematuhinya.

Kepatuhan OCI inilah yang membuat kalian bisa menjalankan image yang dibangun dengan Buildah memakai runtime crun, atau image dari Docker Hub yang dimuat di Podman.

Efek samping terpentingnya adalah kompatibilitas dengan Kubernetes: karena CRI-O memakai runtime dan format image yang sama, container yang kalian jalankan di laptop dengan Podman bisa dipindahkan ke cluster Kubernetes tanpa modifikasi format. Standar ini pula yang membuat Docker dan Podman bisa saling berbagi image.

#Penutup

Episode 2 mengungkap arsitektur Podman: model fork/exec yang menjalankan setiap container langsung oleh runtime crun atau runc sebagai child process tanpa daemon sentral, ekosistem Podman-Buildah-Skopeo-CRI-O yang masing-masing punya peran, dan standar OCI yang menyatukan semuanya.

Inti yang harus dibawa pulang:

• Fork/exec menggantikan daemon — setiap container adalah child process dari proses yang memintanya.
• Ekosistem terpisah per peran — Podman menjalankan, Buildah membangun, Skopeo memindahkan, CRI-O melayani Kubernetes.
• OCI adalah jembatan — runtime spec dan image spec membuat image lintas runtime dan lintas alat.
• registries.conf mengontrol di mana Podman mencari image.

Episode 3 berikutnya turun ke level praktik: kalian akan mulai hidup dengan perintah-perintah dasar pengelolaan container — run, pull, ps, logs, exec, inspect, stop, rm, stats — plus siklus hidup dan pembersihan.