Nedir bu MikroVM’ler? Firecracker ile MikroVM Dünyasına Giriş

Firecracker Logo

Bu makale yapay zeka kullanılarak “YAZILMAMIŞTIR”. Sohbet tadında okuyabilirsiniz.

Sizlere bugün Amazon tarafından geliştirilen ve (Lambda) serverless-function sistemine iskelet oluşturmuş bir mikro-vm teknolojisi olan “Firecracker” ürününü bir demo ile anlatacağım. Makale iki kısımdan oluşmaktadır. Birinci kısımda Linux işletim sisteminin ne olduğunu ve teknik temel konuları anlatacağım. İkinci kısımda ise direkt olarak Firecracker Demo ile test edeceğiz. Dilerseniz direkt olarak demoya geçebilirsiniz.

Bütün teknik konulara ve kavramsal işlere inmeden önce şu basit iki cümleyi söylemek istiyorum.

1. Linux’ta her şey dosyadır. Linux işletim sistemindeki bütün operasyonlar aslında dosya sisteminde karşılıkları tutularak yaşam döngüsü yönetilir. Mesela siz bir python kodu yazıp “python main.py” diyerek çalıştırdığınızda aslında linux işletim sistemine bir “exec” çağrısı yapar ve “/proc” klasörü altında size bir process_id verilerek sizin iş-parçacağınız ile alakalı bilgiler o numara üzerinden işletim sistemi tarafından değerlendirilir.
2. Mükemmel çalışan bilgisayar diye bir şey yoktur. Ama sistemin daima hizmet verebilir olması için çalışan muhteşem insanlar vardır.

Yaklaşık 5 yıl önce (2021) yılında Docker ve Containerization kavramları bulut bilişim sektöründe “de-facto” standart olarak yavaş yavaş yerini almaya başladı. Docker ve Container’lar ile bir işletim sistemi üzerinde “**chroot sayesinde — File System manipulasyonu” ve “[container-cni](https://www.cni.dev/)** sayesinde — Network ” kısımları bir makine üzerinde yeni sanal-isimler verilerek aynı makine üzerinde birbirinden farklı küçük izole iş-parçacıkları çalıştırılabilir hale geldi. Bu işlemin en güzel yanı siz tek bir işletim sistemi üzerinde birbirinden farklı sürümde bulunan uygulamaları birbirinden hem disk hem de network yapıları farklı olacak şekilde ayarlayabilecek ve sanki bir bilgisayarım var ama bu bilgisayar üzerinde çok hafif 3 adet daha bilgisayar var gibi çalışabiliyor olmasını sağladı. Hatta bu minimallik milisaniyeler cinsinde olduğu için keyfi olarak bir bilgisayar (container) öldürüp diğerini milisaniyeler cinsinde ayağa kaldırabiliyor olduk. Tabii ki bu sanallaştırma denilen şey aslında işletim sistemini yazan yazılımcıların işletim sistemi üzerinde farklı kapılar oluşturulabilmesini ve yönetimini yeni geliştiricilere sağlayabildiği “iptables, virt-io, user-namespaces” gibi araçları geliştiricilerin hizmetine sunduğu için bu yazılımlar çalışabilir oldu.

Bilgisayarlar aslında nasıl çalışır? (vmlinux, rootfs, initrd)

Bilgisayarlar aslında en dıştan bakınca ilk başta güç düğmesine basıldığından itibaren yaşam döngüsünde gracefully-shutdown (sıkıntısız-kapatılma) anına kadar daima ayakta kalmaya çalışan ve kendi üzerinde sonsuz sayıda uygulamaya çalıştırılabilmesi için ev sahipliği yapabilecek şekilde sistem çağrıları (syscall) barındıran genellikle C tabanlı (Linux) uygulamalardır. Eğer Linux özelinde konuşur isek Linux işletim sistemi Linus Torvalds tarafından C ile yazılmış bir “vmlinux.bin” dosyasıdır. Aslında bir linux bilgisayarlarda yapılan ilk iş güç düğmesine basılınca bilgisayar “/boot” klasörü içerisinde bulunan ve direkt olarak assembly tarafından okunabilecek ve günümüz modern x86 mimarileri CPU’larında çalışabilecek OP_CODE’ları bilen derlenmiş linux-çekirdeği olan “vmlinux.bin” dosyasını memory yükler ve CPU üzerinde çalıştırmaya (vmlinux.bin yaklaşık ~15 ile ~21MB boyutlarındadır) başlar. Daha sonrasında Linux kerneli dosya okuma-yazma için bir dosya sistemi arar (biz bu dosya sistemine kök-dosya dizini veya rootfs deriz). Kernel eğer ilk ayağa kalkarken dosya sistemi tanımlaması yapılmış ise direkt olarak o tanımlanan rootfs objesini taramaya başlar ve başlangıç ve bitiş adresleri arasında dosya sistemini kernel değişkenlerine “rootfs-mount” yapar. Böylece siz bir dosya okuma ve yazma isteği yaptığınızda aslında Kernel bütün diske erişimi olduğu ve yönetim onda olduğu için disk’te gerçek adreslerine bu verileri yazar. Linux’ta her şey bir dosya demiştik. Ayrıca Linux Kernel’i ayağa kalkarken dosya sisteminde genellikle ilk olarak o dosya sisteminde ilk tanımlamaların bulunduğu `/sbin/init`` adındaki dosyayı çalıştırır. Bu “/sbin/init” dosyası genellikle Debian tabanlı işletim sistemlerinde “systemd” adındaki işletim sisteminde servisleri start-restart-stop edebileceğiniz arayüzleri veren ve bunları ortak bir hat üzerinden (dbus) yöneten “systemd” servisini olarak çalıştırır.

[1] /boot klasörü ve içerisindeki “vmlinuz”, “config-6.8.0.51-generic” ve “initrd.img” dosyaları

Yukarıda [1] numaralı resimde “/boot” klasörü ve içerisindeki dosyalar görünmektedir. Burada yaklaşık 15MB boyutunda “vmlinuz-6.8.0–51” adında Linux C Kernel’inin 6.8.0 versiyonundaki derlenmiş ve sıkıştırılmış kernel dosyası bulunmaktadır. ayrıca yine aynı isimde “config-6.8.0–51” diye o kernel çalışmaya başlarken yüklediği config bilgilerinin bulunduğu değişkenler dosyası da bulunmaktadır. Son olarak ise kernel dosyası ve configler CPU yüklendikten sonra bu yüklenen kernel’in ilk olarak yükleyip çalıştıracağı “initrd.img” ismindeki kernel’in anlayabileceği ve ilk işletim sisteminin “initialize” etmesi için (mount /proc, /sys, /dev ) tanımlamalarının bulunduğu dosya vardır. Yani işletim sistemi kapatılıp tekrar açıldığında aslında bu üç dosyadaki değeri CPU üzerine yükleyip sonra işletim sistemi çalışabiliyor hale gelmektedir. Bu demek oluyor ki eğer siz bu dosyayı değiştirirseniz bilgisayara yeniden başlatma (reboot) yaptığınızda bilgisayar ayağa kalkmama problem ile karşılaşabilirsiniz 😅.

[2] ps aux çıktısı (çalışan sistem çıktısı)

Yukarıdaki resimde [2] “ps aux” dediğimiz görev-yöneticisi-listele komutunun çıktısını görmektesiniz. Aslında işletim sistemi güç verilip ilk olarak ayağa kalktığında genellikle “/sbin/init” dosyasını çalıştırmaktadır (boot_args ile init değiştirebilirsiniz hatta kendiniz de yazabilirsiniz ancak varsayılanda /sbin/init). Burada önemli olan nokta Linux kernel ilk çalıştırdığı uygulamayı “root” kullanıcı adında bir user ile ve “Process ID=1” olacak şekilde çalıştırmaktadır. Yani Linux işletim sisteminde Root’un her şeyi yapabilmesinin sebebi bilgisayarın ilk “init” komutunu çalıştıran user varlığının kendisi olması sebebiyledir. Ayrıca artık daha sonra ortaya çıkacak olan iş-parçacıkları(process) ne olursa olsun “1” sayısından daha yüksek bir değer alacağı için aslında bütün çalışan uygulamalar “root” kullanıcısı tarafından oluşturulmuş ilk çağrıdan sonra “fork” edilmiş uygulamalar olacaktır. Bu kısım aslında bundan sonraki bütün yetki problemlerinin temel sebebi olarak karşınıza çıkacaktır. (Linux’ta bahsedilen ve en çok korkulan root-user-privileged konusu ve root user’ın yüksek yetkiye sahip olması konusunu işte buradan gelmektedir.)

Son olarak değinmek istediğim şey de işletim sistemleri (debian tabanlı dağıtımlarda) “systemd” aracı ile aslında bütün çalıştırılan sistem ve servisleri ağaç yapısında saklamakta ve yönetmektedir. Aşağıdaki resimde [3] ben “systemctl status” diye komut çalıştırarak ubuntu üzerinde o andaki çalışan uygulamalar zincirini görüntüledim.

[3] “systemctl status” çıktısı

Yukarıdaki resimde [3] yine ilk çalıştırılan ve bütün her şeyin başı olan “/init.scope” diye “systemd” ilk kök noktasını görmektesiniz. daha sonrasında ise Debian ve “systemd” temelli işletim sistemlerinde “system.slice” diye işletim sisteminin uygulamalarının isimlerini görmektesiniz. Mesela benim bilgisayarımda “Docker” ve “Containerd” yüklüydü. O servislerin isimlerini de ağaçta alt kısımlarda görebiliyorsunuz. Hatta benim “[2159] systemctl status” diye çalıştırdığım komutu resmin en altındaki kısımdan 2159 process_id ile çalıştırıldığını görebilirsiniz. Bu şekilde aslında uygulamalar işletim sisteminin üzerinde yönetilebilen araçlar bütünü olarak yer almaktadır.

Günümüz işletim sistemleri bütün bu üç dosyanın otomatik kurulum ve sıkıştırılmış hallerini “.iso” dosyaları olarak kendi sitelerinde vermekte ve sizlerden bu dosyaları bilgisayarınıza kurup initial-setup olarak tanımlamaları kurulum sihirbazları aracılığıyla yaptıktan sonra bir daha sormamaktadır.

Bütün buraya kadar anlattığım kısım bilgisayarın alsında nasıl ayağa kalktığı ve ayağa kalktıktan sonra nasıl hizmet verdiği konularıydı. Bu gördüğünüz ayağa kalkma ve çalışabilir hale gelme konusu VM ve gerçek makineler için sizin günlük hayatınızda deneyimleyebildiğiniz gibi 30–40 saniye süren bir boot işlemidir.

Docker ve Kubernetes aslında ne yapıyor?

Günümüz Bulut dünyasında işletim sistemleri üzerinde Docker ve Kubernetes gibi Container mimarisi kullanan dağıtım çözümleri çoğaldı. Container teknolojileri temelde bir bilgisayar üzerinde aynı işletim sistemi üzerinde çalışan uygulamaların dosya sistemlerini overlayfs oluşturup (chroot yardımıyla) çalışan uygulamanın o sanal dosya sisteminin kök dosya dizini gibi okumasına zorlayarak ve network işlemleri için host makine üzerindeki bilgileri iptables adındaki tabloya yeni değer girip çoğullayarak birden fazla network oluşturup yönetmesi ile sanki bir bilgisayar üzerinde aslında aynı makinede olmasına rağmen hem ip’si hem de dosya sistemi farklı olduğu için sanki birden fazla makine varmış gibi çalışmasını sağlayan sistemler olarak yer aldı.

Bu teknoloji ile isterseniz bir uygulama kaldırıp python3.14 çalıştırırken yine aynı bilgisayar üzerinde ama farklı dosya sistemini kök dizini olarak aldığı için diğerlerinden izoleymiş gibi olan ikinci bir python3.10 uygulamasını kaldırabiliyor olduk. Bu dosyaları paketleme bütün ekosistemde büyük bir paket dağıtımı kolaylığına yol açtı ve “hub.docker.com” üzerinde görebileceğiniz milyonlarca araç (kafka, redis vs.), ve veritabanının (postgres, mongo, couchbase) bütün sistemler kolayca her bilgisayarda paketlenmiş ve tek satır kod ile çalıştırılabilir hale geldi.

VM vs Container

Günümüzde sanallaştırma VM’ler ve Container’lar olarak ikiye ayrılıyor. Bu iki sanallaştırma teknolojisinin birbirinden farkı hafiflik ve izolasyon seviyesinin birbirinden farklı olması sebebiyle oluyor. VM’ler bir makineyi fiziksel CPU ve fiziksel disk (genelde disk-partition ile) bölüp bilgisayar çalışma zamanında sadece o makine için özel kernel ve disk üzerinde de başı ve sonu belli disk parçası arasında okumaya başlar. Her VM’in kendi boot işlemi ile birlikte kendine özel Kernel çalıştırılır. Böylece aynı donanımda çalışan iki adet VM donanım seviyesinde (attach edilmediği müddetçe) birbirininden veri okuyamaz. VM’lerin en büyük pozitif yönü hem kernel’leri farklı hem de disk offset’leri farklı olduğu için gerçek izolasyon sağlamalarıdır.

Container teknolojilerinde ise sanallaştırma, aslında tek bir host makine üzerinde bir master-daemon-process (Bkz. Docker Daemon) ayağa kaldırılıp daha sonrasında bütün network ve disk sanallaştırmasının bu daemon ajanı vasıtası ile aynı işletim sistemi üzerinde yönetilmesiyle sağlanır. Yani aslında diskte tek bir OS (işletim sistemi) ve tek kerneli vardır. Çalışan uygulamalar o işletim sistemi üzerinde Linux sihirleri sayesinde manipüle edilmiş dosya sistemi ve network tanımlamalarını gören birer uygulama yığınlarıdır. Burada önemli olan nokta bütün işlemler tek bir işletim sistemi üzerinde yapıldığı için uygulamaların dosya sistemleri farklı olsa da o uygulamaları “execute” eden Kernel aynı işletim sisteminde olduğu için aslında ortaktır. Container’ların en pozitif yönü çok hafif olmasıdır. VM’ler ~30–45sn ayağa kalkarken; Container’lar ~100 milisaniyeler cinsinde çalışmaya başlayabilmektedir.

Container’lar da bu kernel’in ortak olması izolasyon için en büyük problemdir. Çünkü eğer herhangi bir uygulama kernel tarafında bir bug tetikler ise diğer bütün çalışan container’lar da bu durumdan etkilenecektir. Bu problem için sektörde gVisord, nestybox-sysbox gibi çözümler çıkmıştır. Ancak VM izolasyonunun yerini tutmamaktadırlar. VM’lerde ise her kernel kendi harici kernel_vmlinux.bin ve rootfs sahip olduğu için eğer VM içerisinde bir hata meydana gelirse bu durum sadece kendi disk offsetleri arasındaki ve kendi alanını okuyan kerneli etkileyecektir. Bu sebeple Diğer VM’lere etki söz konusu değildir. Ama yine tekrar edeyim. Container’larda aslında sanallaştırma tek bir host üzerindeki disk içerisinde sanki başka dosya sistemleri de varmış gibi “overlay-fs” olduğu ve o host makine üzerindeki kernel sırasıyla container’ları schedule ettiği için eğer container’lardan birisinde kernel seviyesi bir bug veya panic olursa bu durum host makinedeki kernel tarafından yönetilmesi beklendiği için diğer container’lar da bu durumdan etkilenebilmektedir.

KVM (Kernel Virtual Machine)

Yukarıda VM ve Container’ları anlatınca hemen şunu dediğinizi duyar gibiyim:

• Madem container’ların ana problemi tek kernel üzerinde çalışmaları olarak karşımıza çıkıyor. Nasıl ki aynı işletim sisteminde aynı anda müzik dinlerken aynı anda kod yazabildiğimiz (process-scheduler) gibi bir yapı var o zaman CPU üzerinde geliştirme yaparak kerneller için de bir scheduler ve context-switch için bir API yazamaz mıyız?

Evet doğru yoldasınız ama bunu yapmak için iki adet gereksinim var. Birincisi sizin donanımınızın kernel sanallaştırması için o CPU mimarisini üreten şirketin “Nested Virtualization” API desteği sağlıyor olabilmesi lazım (Bkz. Intel VT-x/AMD SVM) . Çünkü işletim sisteminde process değişimi zaten kernel yüklü iken güncel thread üzerinde sadece yeni bir bellek adresini okumaya başlayıp onu execute etmeye karşılık gelirken; kernel değişimlerinde kernel için CPU mimarisinde (x64, arm64) context-switch (CPU-registry-states, memory-map değerleri vs.) yapılması gerekmektedir. Bunu o donanımı yazan kişilerin API desteği verdiği müddetçe yapabileceğiniz aşikardır.

İkinci olarak ise siz eğer bir CPU üzerinde birbirinden farklı versiyonlarda kernel çalıştırmak istiyorsanız aslında donanım desteğini kullanarak bunu size hizmet olarak verecek edecek bir manager ihtiyacınız olacaktır. Linux işletim sistemini Linus Torvalds ve ekibi yazmıştır. Yani eğer Linux üzerinde Linux kernelini yine Linux API’leri ile context-switch yazılacaksa bu özelliğin Linux Kernel geliştiricileri tarafından yazılması ve ekosisteme sunulması gerekmektedir. Bu söylediğim geliştirme zaten Şubat 2007 tarihinde Linux Kernel 2.6.20 versiyonu ile “Kernel Virtual Machine” olarak devreye alındı. Aslında KVM diye duyduğumuz teknoloji bayadır sektörde olan bir geliştirmedir. Ancak son yıllarda container sistemlerinin ve büyük şirketlerin artan iş yükü için çözüm aradığı auto-provision clusters (openstack), isolated-kubernetes-workloads (kubernetes-katacontainers) gibi senaryolarda popülerlik kazanarak sektörde yeniden gündeme gelmiştir.

Firecracker — KVM gücüyle MicroVM’ler

Firecracker ürünü Amazon tarafından 2018 Kasım tarihinde “Secure and fast microVMs for serverless computing” sloganı ile ortaya çıkmıştır. Aslında KVM API’lerini kullanarak minimal boyutlu bir araç olmayı hedeflemektedir. Cloud Edge senaryoları için özelleşmiş hızlı-boot (~200 milisaniye) ve minimal-rootfs (vm-snapshot ve hot-reload) desteklemesi ile kısa süreli workload uygulamalarında (serverless functions Bkz. AWS Lambda) çok performanslı ve kullanışlı bir araç olarak yer almaktadır.

Aslında Amazon bu ürünü kendi “Lambda — Serverless Functions” altyapısı için geliştirmiştir. Kullanım senaryosu olarak çok minimal ve tek amaç için geliştiriciler tarafından yazılmış cloud-serverless-function’ları dünya üzerindeki bütün edge region’lar üzerinde çok hızlı boot edilip ayağa kalkan ve çok sağlam izolasyon ile güvenli runtime-execution sağlaması amacıyla geliştirmiştir. Günümüzde kendi altyapısını da firecracker ürününü kullanarak inşaa etmiştir.

Firecracker basit anlamıyla üzerinde bulunduğu işletim sistemi üzerinde KVM API’lerini kullanarak donanım kaynağı üzerinde çok hafif-vm oluşturma üzerine hizmet veren CLI Tool uygulamasıdır.

Şimdi sizlerle Firecracker uygulamasını KVM-enabled bir sanal ortamda test ederek ne demek istediğimizi bir demo ile gösterelim.

DEMO: Firecracker ile İlk MikroVM Uygulamasını Çalıştıralım.

KVM ve Nested Virtualization günümüzde çoğu servis sağlayıcısında kapalı olarak gelmektedir. Güncel olarak eğitim amacıyla KVM veren tek site **“play-with-docker”** sitesi olarak karşıma çıktı. Bu sebeple aşağıdaki demoyu bu siteye gidip hands-on lab ortamını çalıştırarak deneyebilirsiniz.

Bazen play-with-docker ile senaryo oluştururklen “out-of-capacity” hatası alabilirsiniz. 5 dakika aralıklarla tekrar deneyiniz.

1. https://labs.play-with-docker.com/ sitesine gidelim ve kendimize yeni bir oturum oturum başlatıp sol açılan menüde “Add New Instance” ile bir makine oluşturarak terminal ekranına erişelim.

Play With Docker sizlere KVM aktifleştirilmiş Alpine Linux makinesi vermektedir. Bu sebeple aşağıdaki işletim sistemi paket kurulumları Alpine Linux özelinde olacaktır.

2. Firecracker Github sayfasına gidip en güncel release versiyonunu bulup direkt olarak Rust ile yazılmış binary dosyasının bulunduğu gzip dosyasını makineye kuralım. (2026/01 için stabil release: v1.13.1)

# install firecracker
curl -LO https://github.com/firecracker-microvm/firecracker/releases/download/v1.13.1/firecracker-v1.13.1-x86_64.tgz
tar -xvf firecracker-v1.13.1-x86_64.tgz
mv release-v1.13.1-x86_64/firecracker-v1.13.1-x86_64 /usr/bin/firecracker

3. Firecracker VM ayağa kaldırırken iki adet argüman ister. Birincisi Linux işletim sistemi çekirdeği “vmlinux.bin”, ikincisi ise bu kernel’in okuyacağı dosya düzeninin bulunduğu disk “rootfs.ext4” dosyasıdır. Bizler bu demoda Amazon’un resmi dokümanında yer alan bu iki dosyayı indireceğiz. Önce çalışma dizini oluşturuyoruz ve dosyaları indiriyoruz.

# root klasörü içinde app diye bir klasör oluşturup dosyaları oraya indirelim.
mkdir /root/app
cd /root/app

# Alpine Linux vmlinux.bin, rootfs.ext4 dosyalarını indirelim
curl -fsSL -o "vmlinux.bin" "https://s3.amazonaws.com/spec.ccfc.min/ci-artifacts/kernels/x86_64/vmlinux-4.14.bin"
curl -fsSL -o "rootfs.ext4" "https://s3.amazonaws.com/spec.ccfc.min/img/alpine_demo/fsfiles/xenial.rootfs.ext4"

4. Dosyalar indirdikten sonra artık Firecracker Daemon çalıştırmaya hazırız. Firecracker ile VM ayağa kalktığında terminal ekranı “escape” işlemini kapatmaktadır. Bu sebeple “tmux” kurarak birden fazla terminal ile demomuzu tamamlayacağız.

# tmux ve vim kuruyoruz.
apk add tmux wget sudo vim

# tmux diye çalıştırıp tmux geçiş yapıyoruz.
tmux

# CTRL + B tuşuna basıp ardından C tuşuna basarak yeni terminal oluşturuyoruz.
# TERMINAL - 1

# Aynı şekilde ikinci terminali de oluşturuyoruz.
# TERMINAL - 2

# Terminaller arasında 
# İleri gitmek için: CTRL + B tuşuna basıp ardından N tuşuna basmak (Next)
# Geri gitmek için: CTRL + B tuşuna basıp ardından P tuşuna basmak (Previous) 

Şimdi iki adet terminal oluşturacağız. Birinci terminal Firecracker Daemon çalıştıracağız. İkinci terminalde ise Firecracker ile VM create-start-stop işlemlerini yöneteceğiz.

5. Artık Firecracker çalıştırabiliriz.

# TERMINAL - 1
# Host makine üzerinde firecracker yönetmesi için socket oluşturuyoruz.
export API="/tmp/firecracker.socket"

# eğer geçmişten bu dosya var ise siliyoruz.
sudo rm -f "$API"

# firecracker daemon başlatıyoruz
sudo firecracker --api-sock "$API"

Bu işlem sonunda firecracker dinlediğini belirten çıktıyı verecektir. Artık ikinci terminale geçip VM için parametreleri firecracker’a istek atarak tek tek girebiliriz.

# TERMINAL 2
# firecracker ajanına VM bilgielrini tek tek giriyoruz.
export API="/tmp/firecracker.socket"

# CMD-1: VM limitlerini giriyoruz
curl -sS -X PUT --unix-socket "$API" \
  -d '{ "vcpu_count": 1, "mem_size_mib": 256, "smt": false }' \
  http://localhost/machine-config

# CMD-2: VM için kernel dosyasını ve bu kerneli yüklerkenki argümanlarını söylüyoruz.
curl -sS -X PUT --unix-socket "$API" \
  -d '{ "kernel_image_path": "/root/app/vmlinux.bin", "boot_args": "console=ttyS0 reboot=k panic=1 pci=off root=/dev/vda rw" }' \
  http://localhost/boot-source

# CMD-3:
# VM için ext4 formatında dosya düzeneği alanını attach ediyoruz. 
# Böylece yaptğı işlemler disk üzerinde bu dosyanın içerisindeki alanlara yazılacak
curl -sS -X PUT --unix-socket "$API" \
  -d '{ "drive_id": "rootfs", "path_on_host": "/root/app/rootfs.ext4", "is_root_device": true, "is_read_only": false }' \
  http://localhost/drives/rootfs

Bu tanımlamalardan sonra VM ayağa kalkmaya hazır. Firecracker Daemon için hadi bu bilgiler ile “VM güç ver” tuşuna bas diye çağrı yaparak ayağa kalkmasını sağlıyoruz.

# TERMINAL 2
export API="/tmp/firecracker.socket"

# VM ayağa kalk sinyalini gönderiyoruz.
sudo curl -sS -X PUT --unix-socket "$API" \
  -d '{ "action_type": "InstanceStart" }' \
  http://localhost/actions

Terminal-2 ekranından bu çağrıyı yaptıktan sonra Terminal-1 ekranına geçiş yaparsanız (Bkz. Video [4]) VM’in direkt olarak çalışmaya başladığını ve boot olduğunu görebilirsiniz. Terminal-1 boot işleminden sonra direkt olarak sizi serial console aktaracak ve login için username ve password isteyecektir. username: “root” password: “root” diyerek ilerleyebilirsiniz.

[4] Sol terminal-1: firecracker-daemon dinliyor. Sağ terminal-2: çağrı yaparak firecracker harekete geçiriyor.

Tebrikler 🚀 🔥 Nur topu gibi bir VM ayağa kaldırdınız. Şimdi Terminal-1 ekranında dilediğiniz Linux komutunu çalıştırarak test edebilirsiniz. (Videoda iki terminalde yukarıdaki bütün komutları çalıştırıp soldaki terminalde vm ayağa kalkmasını görmektesiniz. Dilerseniz videoyu yeni sekmede açıp yakınlaştırabilirsiniz.)

Yukarı videodaki [4] gibi başarılı bir şekilde VM ayağa kaldırıp Terminal-1 ekranında Biraz kurcalayınca şunu farkedeceksiniz. Linux ile bütün komutları terminal ekranında çalıştırabilirken netowrk ile alakalı curl google.comdediğinizde herhangi bir yanıt alamayacaksınız. Çünkü biz VM ayağa kaldırdık ama VM tamamıyla kernel ve dosya sistemi host makine’den farklı olduğu için ona gelecek trafik (ingress) ve VM üzerinden dış dünyaya çıkacak trafik (egress) için network tanımlamalarını henüz yapmadık. Bu sebeple VM henüz dış dünya ile iletişime geçemeyecektir.

[5]. Terminal-2'de ps aux derseniz aslında VM’in kendisini bir host makinesinde bir process’e karşılık geldiğini ama kendi içinde bir dünya olduğunu görebilirsiniz.

Ek Bilgi: Ana makine üzerinde yukarıdaki ekran-görüntüsü [5] gibi “ps aux” çalıştırdığınız zaman firecracker daemon çıktısını görebilmektesiniz. Yani aslında yeni oluşturduğumuz VM; host makine üzerinde bir adet firecracker process’ine denk gelmektedir. Firecracker host makine üzerinde Nested Virtualization sayesinde KVM ile konuşarak host makine üzerinde o makineden bağımsız bir dosya sistemi ve kerneli çalıştıran process halinde servis etmektedir. Ancak eğer terminal-1 ekranına girer bakarsanız orada ise tamamen kendi bağımsız bir systemd ve process döngüsü bulunduran bir alpine-linux işletim sistemi göreceksinizdir.

6. Terminal-1 ekranında VM ile işimizi bitirdikten sonra Terminal-2 ekranında host makine üzerindeyken VM için kapatma sinyalini aşağıdaki gibi gönderebiliriz.

# TERMINAL 2
export API="/tmp/firecracker.socket"

# kapatma sinyalini gönder.
sudo curl -sS -X PUT --unix-socket "$API" \
  -d '{ "action_type": "SendCtrlAltDel" }' \
  http://localhost/actions

Firecracker’ın asıl amacı gördüğünüz gibi çok kısa sürede boot edilmiş makine oluşturma ve kısa sürede delete edilme üzerine kurulmuştur. Bu sebeple cloud function ve micro-vm ekosisteminde çokça kullanılmaktadır. (Bkz. Kata Containers, AWS Lambda vs.)

Tebrikler 🙌, Bu yazımda micro-vm kavramını uygulamalı olarak gösterip ve demoyu tamamlayarak sizlere aktarmayı amaçladım . Gelecek yazımda curl google.com komutunu VM üzerinde çalıştırabilmemiz için artık ileri seviye konular olan “Networking” ve “Tap Network” gibi konulara gireceğiz.

Yeni yazılarda görüşmek üzere…

—

Alper R. YAZGAN

x.com/alperreha