Belajar Firecracker - Integrasi Container: firecracker-containerd

#Pendahuluan

Sejauh ini kita mengelola microVM dengan API mentah: curl ke Unix socket, JSON, boot, snapshot. Episode 11 membawa Firecracker ke dunia yang lebih ramah: container. Dengan firecracker-containerd, kalian tetap menulis nerdctl run atau ctr run seperti biasa — tapi di belakang layar, setiap container dijalankan dalam microVM Firecracker yang terisolasi penuh.

Mengapa episode ini penting? Container adalah format distribusi software yang sudah mapan, dan hampir semua tim lebih nyaman mengelola image daripada kernel dan rootfs. firecracker-containerd menyatukan dua dunia: ergonomi container (pull image, registry, OCI) dengan keamanan microVM (isolasi hardware). Ini juga menjadi fondasi pola "sandbox per user/job" yang kita bahas di episode 12 dan 18.

#Apa itu firecracker-containerd

firecracker-containerd adalah runtime containerd yang menambahkan dukungan microVM Firecracker ke containerd. Bedanya dengan containerd biasa:

• Containerd biasa → menjalankan container sebagai proses di namespace host.
• firecracker-containerd → menjalankan container di dalam microVM, di mana microVM-nya sendiri yang dikelola sebagai container.

Hasilnya, dari sudut pandang developer, tetap pull + run. Dari sudut pandang keamanan, tiap container mendapat isolasi setara hardware — bukan sekadar namespace Linux.

Karena containerd mengikuti spesifikasi OCI Runtime (runtime class containerd-firecracker), tooling seperti nerdctl, ctr, atau Kubernetes (dengan runtime class) bisa memakainya tanpa perubahan besar. Inilah pola yang membuat microVM bisa hadir di ekosistem container yang sudah ada.

#Komponen Utama

#Runtime: firecracker-containerd runtime

Komponen inti yang mengimplementasikan interface OCI. Ia yang mengatur: membuat microVM, menjalankan proses di dalamnya, dan menjaga korespondensi antara container dan microVM. Runtime inilah yang menerjemahkan request OCI (Create, Start, Kill) menjadi operasi Firecracker — boot, put snapshot, resume, dan sebagainya.

#Snapshotter overlay

Container image adalah lapisan (layer). firecracker-containerd memakai snapshotter untuk menyusun lapisan-lapisan itu menjadi rootfs microVM yang bisa di-boot. Polanya:

• Layer image ditaruh sebagai filesystem overlay di host.
• Rootfs microVM disusun dari lapisan-lapisan ini (sering memakai overlayfs).
• Guest mem-boot dari hasil susunan itu, lalu menjalankan proses container.

Snapshotter memutuskan bagaimana image container menjadi filesystem guest — inilah bagian yang paling berbeda dari containerd biasa dan paling sensitif terhadap performa boot.

#Alur Kerja: Pull → Unpack → Run

#1. Pull Image

Seperti biasa, tarik image dari registry:

sudo nerdctl --namespace=fc pull docker.io/library/alpine:latest

#2. Unpack dan Susun Rootfs

Snapshotter meletakkan layer-layernya ke disk, lalu membangun rootfs microVM:

sudo nerdctl --namespace=fc create --runtime io.containerd.firecracker.v1 fc-alpine

Pada tahap ini, layer image dipindahkan menjadi filesystem yang bisa di-boot sebagai disk guest. Detail yang perlu dipahami: tiap container mendapat microVM sendiri — tidak ada container yang berbagi microVM, karena itulah poin isolasinya.

#3. Jalankan Container dalam MicroVM

Saat start, runtime membangun microVM: jailer untuk isolasi, kernel + rootfs dari image, TAP dan bridge untuk jaringan:

sudo nerdctl --namespace=fc start fc-alpine
sudo nerdctl --namespace=fc exec fc-alpine uname -a

Output uname -a di dalam guest akan menampilkan kernel guest — berbeda dari kernel host — bukti bahwa proses berjalan di dalam VM, bukan di namespace host. Ini cara cepat memverifikasi isolasi benar-benar terjadi.

#Network dan Registry Access

Container microVM butuh jaringan dan akses registry. firecracker-containerd membangun:

• TAP per microVM di host.
• Bridge yang menghubungkan semua TAP dengan jaringan luar.
• DNS dan route di dalam guest, dikonfigurasi saat boot microVM (lewat mekanisme serupa MMDS / metadata guest).

Guest mengakses registry lewat bridge yang sama — pull image di dalam microVM (untuk image yang tidak dibundle saat create) atau lewat proxy yang sudah disiapkan host. Untuk produksi, image biasanya sudah tersedia di host (pola bundled), sehingga guest tidak perlu akses registry eksternal saat runtime — lebih cepat dan lebih aman.

#Keuntungan dan Batasan

Keuntungan memakai firecracker-containerd:

• Ergonomi container penuh: pull/run/exec seperti biasa, image OCI standar.
• Isolasi hardware per container: escape dari container tidak berarti akses host.
• Ekosistem: bekerja dengan nerdctl, Kubernetes (runtime class), dan tooling OCI lain.

Batasan yang jujur:

• Overhead per container: satu microVM per container — untuk workload micro, ini mahal dibanding container biasa.
• Boot tetap butuh waktu: meski cepat, boot microVM tidak pernah secepat fork proses.
• Kompatibilitas image: image yang butuh device khusus atau mount aneh bisa bermasalah di microVM.
• Proyek masih berkembang: API dan tooling berubah; pin versi dan uji sebelum naik produksi.

#Common Pitfalls

• Image butuh systemd: image dengan init systemd yang lengkap mem-boot lebih lambat di microVM; prefer image single-process.
• Lupa runtime class: nerdctl run tanpa --runtime memakai runtime default (namespace host) — pastikan --runtime io.containerd.firecracker.v1.
• Network namespace per VM: TAP harus berada di network namespace yang benar; salah namespace = guest tanpa jaringan.
• Bundled image stale: image yang di-bundle saat create tidak ter-update otomatis; siklus build harus menyegarkannya.
• Overcommit memori: tiap microVM menyimpan overhead (< 5 MiB) plus memori guest; perhitungkan di kapasitas host.

#Penutup

Inti yang harus dibawa pulang:

• firecracker-containerd menjalankan container OCI di dalam microVM Firecracker.
• Komponen inti: runtime OCI (containerd-firecracker) + snapshotter overlay.
• Alur: pull image → unpack → susun rootfs → start microVM per container.
• TAP + bridge menghubungkan microVM; image bisa bundled (offline) atau via proxy.
• Satu microVM per container = isolasi kuat dengan biaya overhead yang jujur.

Di episode 12 selanjutnya kita akan memperbesar skala: Orchestrator — firectl, Flintlock & MicroVMs — memakai firectl sebagai CLI sederhana untuk launch Firecracker, Flintlock dari liquidmetal untuk mengelola banyak microVM sebagai service, serta integrasi Kubernetes via containerd dan runtime class microvm untuk pola sandbox per user/job.