Firecracker nedir ve tüm Agent altyapısı şirketleri neden bu teknolojiyle ilgileniyor?

Her gün AWS Lambda trilyonlarca fonksiyon çağrısı çalıştırıyor. AWS Fargate milyonlarca konlarca konteyner planlıyor. Bunların her biri, kendi çekirdeğine sahip, saniyenin çok küçük bir bölümünde başlatılan tam bir sanal makinedir.

Nasıl mı? Yaklaşık 50.000 satır Rust koduyla yazılmış Firecracker sayesinde. Firecracker, sektörün nihayet kaynak kabul etmesiyle var oldu: Kaynak kullanımını kontrol eden bir Linux konteyn konteyneri, hiçbir zaman bir güvenlik sınırı olarak tasarlanmamıştı.

İzolasyon sorunu

Laptopunuzdaki her Docker konteyneri, bir palto altındaki üç Linux çekirdek özelliğidir:

• Namespace'ler gözbağıdır. İçindeki bir süreç, sistemin özel bir özel görünümünü alır: kendi PID listesi, ağ yığını, bağlama tablosu, ana bilgisayar adı ve kullanıcı kimlikleri. Konteynerin içindeki PID 1, ana bilgisayardaki rastgele bir PID'dir; konteyner konteyner diğer diğer süreçleri göremez bile.
• cgroup'lar bütçelerdir. Kontrol grupları, çekirdeğin muhasebe ve hız sınırlama katmanıdır. Bir süreç ağacının ne kadar CPU, bellek, disk G/Ç ve ağ bant genişliği tüketmesine izin verildiğini sınırlarlar.
• seccomp + yetenekler izin listeleridir. Yetenekler, root'un yetkilerini ~40 ayrı ayrıcalığa böler (düşük portları bağlama, çekirdek modülleri yülyükleme, dosya sistemi bağlme vb.), böylece yalnızca ihtiyacınız olanları verebilirsiniz. seccomp, süreç başına, sürecin yapmasına izin verilen sistem çağrılarını (kullanıcı alanının çekirdeğe tek API'si) belirleyen bir filtredir.

Bunu Docker kurulu olmadan da kendiniz kanıtlayabilirsiniz:

Docker'ın yaptığı diğer her şey (görüntü katmanları, kayıt defterleri, DNS) bunun üzerine kurulu orkestrasyondur.

Tüm bu koruma, yaklaşık 30 milyon satır kod içeren ve 400'den fazla sistem çağrısı sunan tek bir Linux çekirdeğinden geçer. Ana bilgisayardaki her konteyner aynı çekirdeği çağırır. Bu sistem çağrılarından herhangi birindeki tek bir hata, o makinedeki tüm kiracılar için oyunun sonu demektir.

Tam sanal makineler izolasyonu kaba kuvvetle çözer: her VM kendi çekirdeğine sahiptir.

Modern CPU'lar, konuk talimatlarını gerçek silikon üzerinde çalıştıran bir "konuk modu"na sahiptir. Ana bilgisayar yalnızca konuk ayrıcalıklı bir şey yaptığında (gerçek donanıma dokunma, hata verme, kesintiye uğrama) devreye girer. Bir hypervisor, bu anlara aracılık yapan ince katmandır.

Linux, hypervisor'ını /dev/kvm'de sunulan KVM adlı bir çekirdek modülü olarak gönderir. Donanım sanallaştırma uzantılarına (Intel'de vmx, AMD'de svm) dayanır:

Tam VM'lerin sorunu yavaş ve şişman olmalarıdır. Klasik bir QEMU VM, tamamen hayali bir bilgisayarı (BIOS, PCI veriyolu, IDE denetleyicisi, VGA kartı, PS/2 klavye) öykünür çünkü 1998'deki bir işletim sistemi buna karşı başlamayı beklerdi. Görüntü yüzlerce megabayttır. Önyükleme saniyeler alır. İş yükünüz başlamadan önce bellek kullanımı yüzlerce MiB'dir. 40ms yaşayan bir web isteği için, makineyi başlatmak için bunun 40 kat daha fazla zaman harcarsınız.

Yani şu ikilem arasında sıkışıp kalırsınız:

• Konteynerler: 50ms önyükleme, 5 MiB ek yük, paylaşılan çekirdek saldırı yüzeyi.
• VM'ler: 5+ saniye önyükleme, 300+ MiB ek yük, donanım izolasyonu.

Güvenilmeyen çok kiracılı kod çalıştıran herkes (AWS ve mevcut tüm AI kum havuzu satıcıları) bu takasın her iki tarafına da aynı anda ihtiyaç duyar.

MikroVM'lere giriş

Bir VMM (Sanal Makine Monitörü), hypervisor'ı yönlendiren kullanıcı alanı sürecidir: konuk belleğini ayarlar, sanal aygıtları takar ve KVM'ye konuk kodunu çalıştırmaya başlamasını söyler.

Bir mikroVM, 1998 bilgisayarının silindiği bir VMM'dir: BIOS yok, PCI veriyolu yok, VGA yok, USB yok, ACPI yok (gerçek bir masaüstünün önyükleme yaptığı eski donanımların hiçbiri ve 40ms'lik bir fonksiyon çağrısı için bunların hiçbiri önemli değildir). Geriye kalan: KVM, bir seri konsol ve bir avuç virtio aygıtı (ağ, blok, vsock).

virtio, "Bir VM'de çalıştığımı biliyorum" standart aygıt arayüzüdür. Konuk, gerçek bir Intel e1000 kartı veya IDE denetleyicisi kullanıyormuş gibi yapmak yerine, hafif sanal NIC'ler ve diskler (virtio-net, virtio-block) aracılığıyla hypervisor ile işbirliği yapar. Bu işbirliği ve yukarıdaki tüm eksik eski donanım, mikroVM'lerin hızlı önyüklenmesinin en büyük nedenidir.

Sonuç:

• VMM başlatılmasından konuk kullanıcı alanının init çalıştırmasına kadar ~125ms önyükleme.
• VM başına <5 MiB VMM bellek ek yükü (konuk iş yükü kendisi için herhangi bir şey ayırmadan önce ana bilgisayarın VM başına ödediği defter tutma belleği).
• Tek bir ana bilgisayılda 150 VM/saniye oluşturma hızı.
• Çıplak metale kıyasla ~%2–8 çalışma zamanı performans kaybı.

Tam bir VM ile aynı donanım seviyesinde izolasyon, bir konteyner ile aynı büyüklük sıklık.

Firecracker, aslında /dev/kvm ile konuşan ve mikroVM'yi başlatan VMM sürecidir. Bu yazının geri kalanı, bu yığının uçtan uca işleyişidir.

Firecracker

Kasım 2018'de AWS, re:Invent'te Firecracker'ı açık kaynak olarak yayınladı. O sırada Lambda'yı üretimde çalıştırıyordu; import pandas'ınızı milisaniye bazında faturalandırılacak kadar hızlı soğuk başlatan şey buydu. 2020'de ekip, mimariyi NSDI '20'de yayınladı.

Mimari

Google'ın crosvm'inden çatallanmış, Rust ile yeniden yazılmış ve kodun yarısından fazlası kaldırılmıştır. Her Firecracker süreci, tam olarak üç iş parçacığı türüne sahip (docs/design.md belgelenmiştir) tek bir mikroVM'dir:

• API iş parçacığı sipariş masasıdır. Bir Unix soketine (bir TCP portu değil, diskte bir dosya olarak yaşayan yalnızca yerel soket) bağlı bir REST sunucusu. Önyüklemeden önce yapılandırmayı ve sonrasında sınırlı eylemleri kabul eder.
• VMM iş parçacığı donanım atölyesidir. Konuğun görebildiği her aygıt gibi davranır. Konuk, bir NIC kaydı olduğunu düşündüğü yere dokunduğunda, CPU konuğu duraklatır, VMM dokunuşu işler ("konuk TX kuyruğunu tekmeledi, boşalt") ve devam eder. Mekanizma: Konuk sihirli adresleri okur/yazar; CPU bunları ana bilgisayara aktarır.[^mmio]
• vCPU iş parçacıkları koşuculardır. Konuk CPU başına bir tane, her biri sıkı bir döngüde: ilginç bir şey olana kadar (aygıt dürtmesi, kesinti, durma) konuğu çalıştırmasını iste, işle, döngüye devam et.

Birbirleriyle Rust kanalları (işlem içi, iş parçacıkları arasında kilitsiz mesaj kuyrukları) aracılığıyla iletişim kurarlar. Konuk tam olarak dört aygıt görür.

<payload-block payload-block id="blk_1" type="upload" />

Dört aygıt

• virtio-net, VM'nin NIC'idir, 1998 öykünmesi yok. Konuk paketleri bir virtqueue'e (paylaşılan bellekteki halka tampon) yazar; VMM bunları ana bilgisayar tarafındaki bir TAP aygıtı (çekirdeğin bir dosya olarak sunduğu sanal Ethernet arayüz) aracılığıyla boşaltır ve io_uring veya epoll tarafından yönlendirilir, böylece VMM iş parçacığı bloke olmaz.
• virtio-block, VM'nin diskidir, yalnızca ana bilgisayarda dosya G/Ç'si. Konuk sektör isteklerini bir virtqueue'e koyar; VMM, bir ana bilgisayar dosyasına karşı düz pread/pwrite yayınlar. IDE yok, AHCI yok, SCSI yok.
• virtio-vsock, VM'nin ana bilgisayarla olan dahili iletişim aracıdır. Bir IP/port çifti yerine (bağlam kimliği, port) demetiyle adreslenir, böylece konuk aracısı, konuk IP'si olmadan ve taklit edilecek kabloda hiçbir şey olmadan eve (günlükler, sağlık ping'ları, anlık görüntü meta verileri) telefon edebilir.
• 8250 seri UART, önyükleme konsoludur. Sabit bir adreste öykünülen küçük bir eski seri yongası. virtio gelmeden önce erken önyükleme günlükleri ve çökme dökümleri için kullanılır. Ucuz, evrensel, asla gitmeyecek.

Bir mikroVM'yi uçtan uca başlatma

API, tüm kontrol düzlemidir: yapılandırma kanalı, veri düzleminden (konuk kodunu çalını çalıştıran vCPU iş parçacıkları) kasıtlı olarak ayrı tutulur. İkiliği bir Unix soketine işaret ederek başlatırsınız:

Ardından içine yapılandırma PUT'u yaparsınız:

Dört HTTP çağrısı. Kontrol düzleminin tamamı bu.

Güvenlik soğanı

Tek bir KVM sınırı zaten güçlüdür. Firecracker etrafına iki katman daha sarar.

Jailer, bir kum havuzu oluşturucudur. Tek işi, VMM'yi daha çalıştırmadan önce kutuya koymaktır. Bir chroot (bir süreci tek bir dizin alt ağacına kilitleyen ve bu dizini dosya sisteminin köküymüş gibi gösteren bir Linux özelliği; süreç onun üzerindeki hiçbir şeyi adlandıramaz) oluşturur, ana bilgisayarın diğer süreçlerini görememesi için yeni bir PID namespace'ine girer, ayrıcalıksız bir uid/gid'ye geçer, cgroup CPU/bellek sınırları uygular ve ancak o zaman Firecracker ikili dosyasını bu hapishanenin içinde çalıştırır:

Artık VMM sürecinin kendisinin, ayrılmış bir chroot dışında hiçbir dosya sistemi, ana bilgisayardaki diğer süreçlere dair hiçbir görüşü ve hiçbir root yeteneği yoktur. Konuktan ana bilgisayara bir kaçış virtio veya KVM aracılığıyla gerçekleşse bile, saldırgan cgroup sınırları olan bu chroot'a düşer.

Seccomp, iş parçacık başına bir sistem çağrısı izin listesidir. Listede olmayan herhangi bir şey, çekirdeğin sistem çağrısı işleyicisine ulaşmadan öldürülür (veya EPERM döndürür). Firecracker üç seviye gönderir:

1. Seviye 0: Kapalı. Üretimde kullanmayın.
2. Seviye 1: Sistem çağrısı numarasına göre izin listesi.
3. Seviye 2: Ayrıca argüman değerlerini de kısıtlar (örneğin ioctl sorunsuz, ancak yalnızca KVM_RUN komutuyla). Varsayılan ve önerilen.

Her iş parçacığı mümkün olan en küçük yüzeyi alır: API iş parçacığı ioctl(KVM_RUN) gerektirmez; vCPU iş parçacıkları socket() gerektirmez. Bir kuralın basitleştirilmiş görünümü:

Bir saldırganın ana bilgisayara ulaşması için her katmanın her katmanı bağımsız olarak başarısız olmalıdır.

Anlık Görüntüler: Lambda SnapStart'in arkasındaki hile kodu

Çalışan bir mikroVM'nin Anlık Görüntüsünü alın. Farklı bir ana bilgisayarda, yepyeni bir VMM sürecinde milisaniyeler içinde geri yükleyin. Çekirdek önyüklemeyi, init'i, JIT ısınmasını atlayın.

Çalışan VM'yi dondurur ve bellek + aygıt durumunu diske dökümsünüz:

Bir anlık görüntü, ısınma sonrası durumu yakalar, böylece geri yüklenen VM hayatının başında değil, ortasında uyanır.

AWS Lambda SnapStart tam olarak bunu yapar: bir Java Lambda'yı bir kez başlat, mikroVM'nin anlık görüntüsünü al ve bu anlık görüntüyü sonraki her soğuk başlangıçta geri yükle (duyuru). JVM soğuk başlangıçları aniden 8+ saniyeden saniyenin altına düşer.

Nasıl bir araya geliyorlar

gVisor farklı bir tasarımdır: Go ile yazılmış bir kullanıcı alanı çekirdeği, normal bir süreç olarak çalışan Linux syscall arayüzünün yeniden uygulanması. Konuğun syscall'ları ana bilgisayar çekirdeği yerine gVisor'a çarpar ve gVisor neyi (varsa) aşağı akışa iletmeye karar verir. Bir mikroVM'den daha hızlı başlar, sıcak yolda %10–30 syscall ek yükü ve farklı bir güven sınırı.

Firecracker, "kendi çekirdeğim, ancak PCI BIOS yok" kutusunda yer alır: donanım izolasyonu, küçük aygıt modeli ve milisaniyelerde önyükleme.

Aracınızı seçin:

Bunu kim kullanıyor

MikroVM'lerin üzerinde olmayan sunucusuz platformları listelemek neredeyse daha hızlı.

Firecracker üretimde:

• AWS Lambda ve AWS Fargate: orijinal kullanım durumu. Her Lambda çağrısı bir Firecracker mikroVM'sine düşer; Fargate görevleri, içinde ince bir konteyner çal zamanı bulunan Firecracker VM'leridir.
• [Fly.io Machines](https://fly.io/docs/machines/): her fly makine çalıştırması, küresel olarak dağıtılmış, saniyenin altında soğuk başlangıçlar ve kalıcı disklere sahip bir Firecracker mikroVM'sidir.
• Son on sekiz ayda kullandığınız neredeyse her AI aracı kod yürütme kum havuzu bir Firecracker mikroVM'sinde yaşar.

Bir kum havuzu API'sinin şekli, bu noktada tüm satıcılarda kabaca aynıdır:

Yaklaşık dört satır kodla: bir Firecracker mikroVM'si başlar, bir çekirdek başlatılır, konuğun içindeki bir aracı süreci komutunuzu vsock üzerinden alır, çalıştırır, sonuçları geri akışlar ve VM ölür.

Aracı Çağı: tüm bunlar neden şimdi önemli

Bir yıl önce, "AI kum havuzu nedir?" niş bir soruydu. Bir LLM kod ürettiyse, muhtemelen herhangi bir makinede çalıştırmak %100 güvenli değildi, bu yüzden onu geçici bir kum havuzunda çalıştırırdınız.

Bugün her ciddi AI ürünü bir aracı gönderiyor. Kum havuzları da iyileşti, ancak aracıların şekli değişti ve eski çalışma zamanı yanıtları yeni şekle uymuyor.

Süreç içi aracılar ve ana bilgisayar seviyesi aracılar

AI aracılarının ilk turu, uygulamanızın içinde yaşıyordu. Bir kütüphane içe aktardınız, bir döngü kurdunuz ve mevcut arka uçunuzda çalıştırdınız:

Her çağrı, bir modele HTTP gidiş-dönüşüydü. Her araç çağr. Her araç çağrısı, kendi sürecinizde bir fonksiyondu. "Kum havuzu" kendi sunucunuzdu. Bu, Vercel AI SDK, LangChain, OpenAI Agents SDK dünyasıdır. Harika çalışır ve bugün hala üretim aracılarının büyük bir kısmını gönderir.

İkinci tur farklıdır. Claude Code, Codex ve OpenCode, ana bilgisayar seviyesi aracılardır: bir makineyi devralan ikili dosyalar, sizin içinizde yaşayan kütüphaneler değil. Gerçek bir kabuk, bir paket yöneticisi ve yazılabilir bir disk beklerler. Claude Code'a bir görev verdiğünüzde şöyle bir şey çalıştırır:

Bu bir shell/bash. Gerçek bir dosya sistemi, gerçek bir fork/exec, bir paket yöneticisi, yazabileceğiniz bir disk, ulaşabileceğiniz bir ağ gerektirir. Bunların hiçbiri bir sohbet tamamlama araç şeması olarak ifade edilemez ve hiçbiri diğer kiracılarla paylaşılan çekirdekli bir konteynerde çalıştırmak için güvenli değildir.

Laboratuvarlar, modellerini doğrudan bu koşum takımları (modelin etrafındaki iskele) üzerinde eğitim sonrası yapıyor: kabuk, dosya düzenleyici, test çalıştırıcı, aracı döngüsünün kendisi. Bu, "model + üzerinde eğitildiği koşum takımı" ile "model + kendin yap iskelesi" arasındaki farkın her çeyrek büyüdüğü anlamına gelir.

Aracının az önce icat ettiği güvenilmeyen kodu çalıştıran, aracı başına tam bir Linux makinesi, Firecracker'ın tam olarak için inşa edildiği iş yük. Yukarıdaki yakınsama bir kaza değildi.

Aracıların hesaplama ve koşum takımı ayrımı etrafında daha fazla deney yapıldığını görmeye başmeye başlıyoruz. Anthropic'in Managed Agents'i bunun bir örneğidir; burada aracı koşum takımı, kum havuzunun yan içinde değil, yanında çalıştırılır.

Bazı şirketler, aracılara daha iyi arama ve depolama sağlamak için tam barındırılan dosya sistemleri bile oluşturuyor (Archil ve Mesa gibi).

Aracılar geliştikçe ve zamanla değiştikçe, Firecracker üzerine inşa edilmiş çok daha ilginç altyapı teklifleri olacak.

Aracı altyapı platformlarına gerçekte ne için ödeme yapıyorsunuz

Genel "isteğe bağlı kod çalıştırma" kum havuzları artık bir metadır. Altyapı tamamen açık kaynaktır. MikroVM katmanı, Apache 2.0 altında mevcut olan Firecracker veya Cloud Hypervisor'dür. Konteynerden rootfs'e dönüşüm, 200 satırlık bir Go betiğidir. Yetenekli mühendisler bir hafta sonu içinde çalışan bir kum havuzu platformu kurabilir.

VM'ye bağlı olan şey için ödeme yaparsınız. Çıplak mikroVM, masadaki minimumdur.

İlginç ürün yüzeyi:

• Gözlemlenebilirlik bir hata ayıklama yardımcı değil, ürünün kendisidir. Aracının yaptığı her şey (stdout, syscall'lar, dosya yazmaları, ağ istekleri) tek bir soketten ana bilgisayar tarafındaki bir toplayıcıya akar. Aracı oluşturucular, en iyi ürünleri oluşturmak için tam oturum tekrarına ve eylem başına yapay öğelere ihtiyaç duyar.
• Sırlar kabloda aracılık edilir, asla konuğa verilmez. Konuk yalnızca yer tutucu ortam değişkenlerini görür; kum havuzunun içinde echo $SECRET yer tutucuyu döndürür. Ana bilgisayar tarafındaki bir çıkış vekili (her giden paket onu geçmek zorundadır), gerçek kimlik bilgisini ana bilgisayar tarafındaki TAP'de (konuğun göremediği veya adresleyemediği VM'nin sanal NIC'inin çekirdeğe ait ucu) açık bir izin listesine karşı, oturum başına bir denetim iziyle değiştirir. Aracı, beş saniye önce oluşturduğu rastgele kodu çalıştırıyor olabilir ve yine sahip olmadığı bir kimlik bilgisini sızdıramaz.
• Kimlik, aracının içinde değil, ana bilgisayarda imzalanır. Giden istekler, paket köprüyü terk etmeden önce ana bilgisayar tarafından basılmış kriptografik bir oturum başına kimlik taşıyabilir (HTTP Mesaj İmzaları + Ed25519 üzerine inşa edilmiş Web Bot Auth imzaları dahil). İmza anahtarı asla mikroVM'ye girmez.
• Diğer hesaplama, çalışma zamanıyla aynı mikroVM'de paketlenir. Browserbase, her aracı çalışma zamanını aynı ana bilgisayardaki, genellikle aynı mikroVM'deki bir tarayıcıyla 1:1 eşleştirir. Aracı süreci ile Chromium arasındaki fiziksel mesafe fiilen sıfırdır: CDP komutları (Chrome'u programlı olarak sürmek için kullanılan JSON üzerinden WebSocket tel biçimi olan Chrome Geliştirici Araçları Protokolü) bir ağ hizmetleri arasında değil, bir Unix soketi üzerinden gider, bu nedenle eylem gecikmesi tek haneli milisaniyelerdir. Ekran kayıtlarına ulaşmak için genel interneti geçmek zorunda değildir.

Ve tüm bunları Docker'ın üzerine temiz bir şekilde dikemezsiniz. Dikişler orada değil. Bizim iddiamız, aracı çalışma zamanı pazarının ham hesaplama ile değil, en iyi gözlemlenebilirlik, sırlar, kimlik, ortaklıklar ve birlikte konumlandırılmış hesaplamanın tek bir ürün yüzeyinde birleştirilmesiyle kazanılacağı yönünde.

İzlemeye değer çalışma zamanı alternatifleri

• [Bubblewrap](https://github.com/containers/bubblewrap): ayrıcalıksız kullanıcı ad alanı kum havuzu. Root olmayan bir kullanıcı, sudo olmadan, Flatpak'in masaüstü uygulamalarını sınırlamak için kullandığı aynı çekirdek ilkellerini kullanarak bir kum havuzu başlatabilir. Bir VM'den daha hafifadır, yine de ana bilgisayar çekirdeğini paylaşır, bu nedenle gerçekten güvenilmeyen koda karşı mikroVM'lerin yerini tutmaz. Ancak bir mikroVM'nin içinde çalıştırmak için harika bir iç içe izolasyon katmanı veya kendi ana bilgisayarınızda güvenilir sayılabilecek kod için iyi bir seçimdir.
• [V8 isolates](https://blog.cloudflare.com/cloud-computing-without-containers/): Cloudflare Workers modeli. Her isolate, kendi yığınına sahip ayrı bir JS yürütme bağlamıdır ve tümü, potansiyel olarak binlerce diğer kiracıyla tek bir V8 sürecini paylaşır. Başlangıç ~5ms'dir, bir mikroVM'den iki kat daha hızlıdır. Güven sınırı, V8'in kendi kum havuzudur; tarihsel olarak iyi dayanmıştır, ancak bir hypervisor'unkinden çok daha ince bir çizgidir. Diğer yakalama: yalnızca Node benzeri lezzetinde anlambilim alırsınız. fork yok, exec yok, yerel modül yok, simüle edilmiş dosya sistemleri. Saf JS aracı kodu için yıkıcı; pip install numpy yapmanız gerekiyorsa işe yaramaz.
• [gVisor](https://gvisor.dev/): Google'ın Go ile yazılmış kullanıcı alanı çekirdeği. İç içe sanallaştırma olmadan güçlü izolasyon (çoğu bulut sağlayıcısının varsayılan olarak devre dışı bıraktığı başka bir VM'nin içinde çalışan bir konuk VM; gVisor buna ihtiyaç duymaz, bu nedenle GKE'de kutudan çıktığı gibi çalışır). Syscall ağırlıklı iş yüklerinde ~%10–30 öder. Donanım sanallaştırması mevcut olmadığında sağlam bir orta yol.
• WASM kum havuzları ([wasmtime](https://wasmtime.dev/), [wasmer](https://wasmer.io/)): belirleyici, küçük, hızlı, ancak ekosistem sığdır. WASI (WASM için standart syscall API'si) olgunlaşıyor. Henüz "bu rastgele Python/Node ikili dosyasını çalıştır" için hazır bir hedef değil.

Güvenilmeyen genel amaçlı kod için inşa ediyorsanız: Firecracker (veya Cloud Hypervisor, benzer bir VMM/virtio tasarımı). Bilinen JS iş yükleri için inşa ediyorsanız: V8 isolates. Diğer her şey, uzmanlaşmış bir soruya uzmanlaşmış bir yanıttır.

Daha büyük resim

Firecracker, bilgisayar bilimindeki en eski fikirlerden birini, birini, bir sanal makineyi aldı ve onu ucuz hale getirmek için yeterince yeterince sildi. Donanım tarafından uygulanan izolasyonun, yeterince hızlı hale getirebilirseniz buna değeceğine dair bir iddiadır.

Bu iddia her zaman sunucusuz için karşılığını verecekti. Değişen şey, "güvenilmeyen çok kiracılı kod" iş yükünün "korumak istemediğim bir web fonksiyonu"ndan "prod'a dokunabilecek rastgele komutlar üreten bir aracı"ya dönüşmesidir. Çevre genişledi ve paylaşılan çekirdek kaçışlarına karşı tolerans "kabul edilebilir risk"ten "gönderilemez"e dönüştü.

Ve oldu. Bu, /dev/kvm ile konuşan, 50.000 satır uzunluğunda bir Rust ikili dosyasıdır.

Konteynerler yazılımı paketler. MikroVM'ler onu izole eder. Gelecek on yılın ilginç mühendisliği, kutunun etrafına sardığınız her şeydir.

→ Kyle

Bu blog yazısı, X makalelerinde görünmeyen etkileşimli bileşenler ve animasyonlar içerir. Bu sürümü görmek isterseniz, burada: https://www.browserbase.com/blog/what-is-firecracker.