Belajar Firecracker - Setup & Instalasi

#Pendahuluan

Di episode 2 kita memahami arsitektur Firecracker: satu proses satu microVM, device virtio, API Unix socket, dan jailer. Sekarang saatnya membuktikan bahwa teori itu benar-benar jalan. Episode 3 adalah panggung pertama yang sesungguhnya: instalasi Firecracker dari nol, verifikasi lingkungan, dan menjalankan firecracker --api-sock untuk pertama kalinya.

Mengapa episode ini penting? Karena sebagian besar kegagalan di episode-episode berikutnya berakar di sini: versi binary yang tidak cocok, KVM yang tidak aktif, rootfs yang salah format, atau path yang salah. Instalasi yang benar dan terverifikasi akan menghemat puluhan jam debugging di kemudian hari.

#Instalasi Binary Firecracker

#Mengunduh Release v1.16.x

Seluruh praktik di series ini memakai v1.16.x (rilis stabil terbaru; v1.16.1 dirilis 2 Juli 2026). Unduh arsip yang sesuai arsitektur host:

ARCH="x86_64" # ganti aarch64 untuk host Arm
VERSION="v1.16.1"
wget "https://github.com/firecracker-microvm/firecracker/releases/download/${VERSION}/firecracker-${VERSION}-${ARCH}.tgz"
tar -xzf "firecracker-${VERSION}-${ARCH}.tgz"
sudo cp "release-${VERSION}-${ARCH}/firecracker-${VERSION}" /usr/local/bin/firecracker
sudo cp "release-${VERSION}-${ARCH}/jailer-${VERSION}" /usr/local/bin/jailer

Arsip release memuat dua binary: firecracker dan jailer. Keduanya static-linked — tidak ada dependency runtime — jadi cukup copy dan langsung bisa dipakai di host mana pun. Verifikasi:

firecracker --version
jailer --version

Output harus menyebut Firecracker v1.16.1 — perhatikan nomor versi ini karena CVE yang diperbaiki di rilis ini akan kita bahas di episode 14 dan 17.

#Verifikasi KVM dan cgroup

Firecracker menolak berjalan tanpa KVM. Cek ulang, karena ini penyebab kegagalan nomor satu:

ls -l /dev/kvm
sudo kvm-ok
stat -fc %T /sys/fs/cgroup/

Pastikan /dev/kvm ada, kvm-ok mencetak KVM acceleration can be used, dan cgroup memakai cgroup2fs. Jika cgroup v1, jailer dan rate limiter tetap bisa dipakai, tapi episode 19 tentang scaling akan jauh lebih nyaman di cgroup v2.

#Menyiapkan Kernel dan Rootfs

Firecracker tidak boot dari ISO atau firmware; ia memuat kernel biner langsung ke memori. Untuk percobaan pertama kita butuh kernel yang dikonfigurasi ringan (tanpa console VGA, tanpa device yang tidak perlu) dan rootfs ext4 minimal.

Unduh kernel siap pakai dari repositori asset resmi Firecracker, lalu buat rootfs kosong:

mkdir -p ~/fc-demo && cd ~/fc-demo
wget https://s3.amazonaws.com/spec.ccfc.min/img/quickstart_guide/x86_64/kernels/vmlinux.bin
dd if=/dev/zero of=rootfs.ext4 bs=1M count=512
mkfs.ext4 rootfs.ext4

Rootfs yang benar-benar bisa di-boot (berisi init dan tooling minimal) kita bangun di episode 8. Untuk episode ini, cukup pastikan kedua file ada — vmlinux.bin adalah kernel, rootfs.ext4 adalah filesystem ext4 kosong.

#Menjalankan Firecracker untuk Pertama Kali

#Mode API

Mode default Firecracker mengekspos API di Unix socket dan menunggu konfigurasi dikirim lewat curl:

firecracker --api-sock /tmp/firecracker.sock

Proses ini berjalan di foreground dan menunggu permintaan API. Di terminal lain, cek bahwa socket sudah ada dan API merespons:

curl --unix-socket /tmp/firecracker.sock http://localhost/  -i

Respons 200 OK dengan body Firecracker API berarti control plane sudah hidup. Pada tahap ini microVM belum boot — API masih menunggu PUT /boot-source, PUT /machine-config, dan seterusnya. Kita lakukan itu di episode 4.

#Mode --no-api

Firecracker juga punya mode tanpa API yang jauh lebih sederhana. Dengan --no-api, semua konfigurasi dilewatkan sebagai command-line options dan VM langsung boot begitu proses dijalankan:

firecracker --no-api \
  --kernel ~/fc-demo/vmlinux.bin \
  --root-drive ~/fc-demo/rootfs.ext4 \
  --vcpu-count 1 \
  --mem-size-mib 256 \
  --boot-args "console=ttyS0 reboot=k panic=1 pci=off"

Perhatikan perbedaannya: tidak ada socket, tidak ada JSON, tidak ada InstanceStart — Firecracker langsung mengeksekusi. Mode ini cocok untuk eksperimen cepat atau boot otomatis di startup, tapi tidak cocok untuk produksi yang butuh kontrol dan audit atas konfigurasi. Di episode 4 kita akan memakai mode API secara penuh, karena di sanalah seluruh kekuatan Firecracker berada.

#Perbandingan Mode: API vs --no-api

Mode --no-api pada dasarnya adalah API yang "dipadatkan" ke argumen proses. Untuk memahami Firecracker secara utuh — termasuk snapshot, MMDS, dan observability — mode API adalah jalur utamanya.

#Common Pitfalls di Instalasi

Beberapa kesalahan yang paling sering terjadi:

• Kernel compressed: memakai vmlinuz alih-alih vmlinux → Firecracker gagal memuat kernel.
• Rootfs salah format: file image bukan ext4 atau tidak ada init → guest hang di boot.
• Path relatif: API PUT /boot-source memakai path di host. Di mode non-jailer, pakai path absolut (/home/user/fc-demo/vmlinux.bin), karena working directory Firecracker menentukan resolusi path.
• KVM tidak aktif: berjalan di VM tanpa nested virtualization → Error: KVM not available.
• Socket bentrok: menjalankan dua Firecracker memakai --api-sock yang sama → socket sudah dipakai. Setiap microVM butuh socket unik.

Jika muncul error KVM, debug dengan urutan: ls -l /dev/kvm → kvm-ok → grep -cE 'vmx|svm' /proc/cpuinfo. Satu dari tiga ini yang bermasalah.

#Penutup

Inti yang harus dibawa pulang:

• Binary static firecracker + jailer v1.16.x, cukup copy tanpa dependency.
• KVM wajib aktif; verifikasi dengan /dev/kvm dan kvm-ok.
• Kernel harus uncompressed (vmlinux.bin), rootfs ext4 dengan init.
• Mode API (--api-sock) memberi kontrol penuh; mode --no-api untuk boot cepat.
• curl --unix-socket /tmp/firecracker.sock adalah gerbang menuju seluruh kontrol microVM.

Di episode 4 selanjutnya kita akan memakai mode API untuk pertama kalinya secara serius: API Management — Boot & Machine Config — mengirim PUT /boot-source untuk kernel, PUT /machine-config untuk vCPU dan memori, PUT /drives untuk block device, lalu InstanceStart dan menyaksikan microVM pertama kalian boot lewat serial console. Di sinilah kalian mulai merasakan kekuatan Firecracker secara nyata.