Belajar Podman - Performance & Optimization

#Pendahuluan

Di episode 17 kalian mengikat container ke sistem operasi lewat systemd dan Quadlet: socket activation, auto-update, dan rollback. Episode 18 ini turun satu level dari siklus hidup layanan ke sesuatu yang menentukan biaya operasional container: performa dan efisiensi. Kita membahas dua domain besar — efisiensi image dan tuning storage — yang dampaknya terasa langsung pada waktu pull, waktu build, pemakaian disk, dan I/O saat runtime.

#Image Efficiency: Ukuran dan Cache Itu Bisa Dikendalikan

Image container adalah rantai layer. Semakin sedikit dan semakin kecil layer yang harus diunduh dan disimpan, semakin cepat pull dan semakin hemat disk. Ada empat teknik utama yang perlu kalian kenal.

#Layer Caching

Saat podman build berjalan, setiap instruksi di Containerfile menghasilkan layer baru. Layer yang tidak berubah di antara dua build tidak perlu dibangun ulang — hasilnya diambil dari cache. Prinsipnya sederhana: instruksi yang sering berubah diletakkan di akhir Containerfile, sedangkan bagian yang jarang berubah (seperti install dependency) diletakkan di awal:

FROM node:22
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
CMD ["npm", "start"]

Dengan urutan di atas, perubahan pada kode aplikasi (COPY . .) tidak memaksa dependency diinstall ulang karena layer npm ci masih cocok dengan cache. Sebaliknya, jika COPY . . diletakkan sebelum npm ci, setiap perubahan kode akan menghancurkan cache dan memicu install ulang yang mahal.

#Multi-Stage Builds

Image produksi tidak butuh toolchain build seperti compiler, SDK, atau package manager. Multi-stage build memisahkan tahap build dari tahap runtime, lalu menyalin hanya artefak yang dibutuhkan:

FROM golang:1.24 AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o server .
 
FROM gcr.io/distroless/base-debian12
COPY --from=builder /app/server /server
EXPOSE 8080
CMD ["/server"]

Tahap pertama menghasilkan binary, tahap kedua dimulai dari image kecil dan hanya mengambil binary lewat COPY --from=builder. Hasilnya image bisa menyusut dari ratusan megabyte menjadi puluhan megabyte — penghematan yang langsung terlihat pada pull pertama dan pemakaian disk.

#zstd:chunked Partial Pull

Image bisa dikompresi dengan format zstd:chunked, yang membagi image menjadi chunk-chunk kecil dengan indeks. Saat image diperbarui, hanya chunk yang berubah yang diunduh, bukan seluruh image. Inilah yang disebut partial pull, dan bisa diaktifkan saat build:

podman build --compression-format zstd:chunked -t myapp .

Keunggulan zstd:chunked terasa terutama di lingkungan CI/CD dan registri berisi image yang sering diperbarui. Perlu dicatat bahwa dukungan pull di sisi klien harus tersedia agar partial pull benar-benar terjadi; tanpa dukungan itu image tetap bisa ditarik secara penuh, hanya tidak se-efisien yang diharapkan.

#composefs (Roadmap)

composefs adalah layout storage berbasis filesystem yang sedang dikembangkan tim containers: image disimpan sebagai pohon file OCI yang bisa di-dedupe lintas container, memungkinkan berbagi data pada level filesystem dan verifikasi isi yang lebih kuat. Karena ini masih di jalur roadmap dan baru opt-in di versi terbaru, kalian belum perlu mengonfigurasinya sekarang — tetapi pantau perkembangannya, karena composefs berpotensi mengurangi duplikasi data dan mempercepat start container secara signifikan.

#Storage Tuning: Menjaga Disk Tetap Efisien

Container adalah konsumen disk yang rakus: image yang tidak terpakai, cache build yang basi, dan layer yang mengendap. Tiga area yang harus dikelola rutin adalah garbage collection, image pruning, dan optimasi I/O overlayfs.

#Garbage Collection

containers/storage memiliki mekanisme garbage collection otomatis untuk membuang layer yang tidak lagi direferensikan. Kalian tidak harus memicunya manual, tetapi penting memahami bahwa GC hanya bekerja pada data yang benar-benar tidak terpakai. Untuk memantau ruang yang dipakai:

podman system df
podman system df -v

Output podman system df menunjukkan ukuran image, container, volume, dan cache build. Angka yang membengkak di kolom cache adalah indikasi kuat bahwa sudah waktunya dibersihkan.

#Image Pruning

Pembersihan rutin adalah kebiasaan yang wajib di mesin produksi dan development. podman image prune menghapus image yang tidak memiliki container yang menggunakannya, sementara podman system prune mencakup lebih banyak hal:

podman image prune -a
podman system prune --all --volumes
podman rmi -f $(podman images -qf dangling=true)

Perhatikan perbedaannya: podman image prune -a menghapus semua image tanpa container, sedangkan podman system prune --all --volumes juga membersihkan container yang berhenti, cache build, dan volume yang tidak dipakai. Baris terakhir memanfaatkan podman images -qf untuk menghapus image dangling (yang kehilangan tag) sekaligus — namun berhati-hatilah, karena memaksa penghapusan image yang masih dibutuhkan bisa merusak container yang sedang berjalan.

#Optimasi I/O Overlayfs

Driver storage default Podman adalah overlayfs. Untuk workload dengan I/O berat, tuning pada mount options bisa mengurangi overhead metadata. Pengaturan umum diletakkan di [storage.options.overlay] pada storage.conf:

storage.conf - mountopt overlayfs

[storage]
driver = "overlay"
 
[storage.options.overlay]
mountopt = "nodev,metacopy=on"

metacopy=on mempercepat operasi seperti chmod dan chown pada layer yang besar karena metadata ditangani tanpa menyalin seluruh file. Pada lingkungan rootless dengan kernel yang lebih lama, fuse-overlayfs menjadi pilihan — sedikit lebih lambat dari overlayfs native, tetapi tetap lebih baik daripada mengekspos storage ke container sebagai volume yang menguras I/O. Pastikan juga kalian tidak membiarkan log dan cache menumpuk di dalam container, karena itu berarti menulis ulang ke layer writable yang mahal.

#Ringkasan Teknik Optimasi

Berikut peta ringkas yang bisa kalian gunakan sebagai acuan:

Prioritas terbaik biasanya dimulai dari multi-stage build dan layer caching karena keduanya memberikan penghematan paling besar dengan usaha paling kecil.

#Penutup

Pada episode 18 ini, kalian memahami cara mengendalikan biaya image lewat layer caching, multi-stage build, zstd:chunked, dan arah roadmap composefs; serta cara menjaga storage tetap efisien lewat garbage collection, image pruning, dan tuning I/O overlayfs.

Inti yang harus dibawa pulang:

• Urutan instruksi menentukan efisiensi build — letakkan instruksi yang jarang berubah paling awal agar cache tetap berguna.
• Multi-stage build adalah penghemat terbesar — image produksi seharusnya tidak membawa toolchain build.
• Pembersihan storage adalah kebiasaan — podman system prune rutin lebih baik daripada darurat.
• Pantau roadmap — zstd:chunked dan composefs adalah arah efisiensi Podman ke depan.

Di episode 19 berikutnya, kalian berpindah dari mesin Linux menuju mesin kalian sendiri: Podman Machine & Desktop — bagaimana menjalankan Podman di macOS dan Windows lewat virtual machine, memilih provider yang tepat, dan mengelola semuanya dari GUI Podman Desktop.