MicroVM-urile Firecracker pe înțeles: o mașină virtuală reală care pornește într-o fracțiune de secundă

Dacă ai citit ceva despre rularea în siguranță a codului generat de AI, ai văzut cuvântul microVM, de obicei lângă Firecracker. De regulă e explicat fie ca „o VM ușoară” (adevărat, inutil), fie cu o diagramă a interiorului kernelului. Iată versiunea de la mijloc.

Două opțiuni mai vechi și de ce nu se potrivește niciuna

Pornește de la cele două lucruri între care stă un microVM.

Un container e un grup de procese obișnuite de pe mașina ta, pe care kernelul a acceptat să le mintă. Namespaces le arată propriul sistem de fișiere, propria listă de procese și propria rețea; cgroups plafonează cât CPU și câtă memorie pot folosi. Pornește în milisecunde, pentru că nu se pornește nimic nou. Dar fiecare container de pe un host vorbește cu același kernel. Un bug de kernel accesibil din interiorul unui container e o cale de ieșire din toate.

O mașină virtuală își aduce propriul kernel. CPU-ul hostului, prin virtualizare hardware (KVM pe Linux), rulează oaspetele ca și cum ar avea propriul calculator. Granița e hypervisorul, care expune mult mai puțin decât sutele de apeluri de sistem ale unui kernel. Costul e greutatea. O VM clasică emulează un PC întreg: firmware, o magistrală PCI, controlere USB, o placă video, uneori o placă de sunet. Pornește trecând prin toate astea, durează de la secunde la minute, iar fiecare instanță cară zeci sau sute de megaocteți de overhead.

O analogie care ține destul de bine: containerele sunt apartamente în același bloc, cu fundația, țevile și cablurile comune. VM-urile sunt case separate. Casele sunt vecini mai siguri, dar nu construiești una pentru o vizită care durează 20 de secunde.

Ce elimină Firecracker

Firecracker e un monitor de mașini virtuale (programul care configurează și rulează o VM peste KVM), scris în Rust și publicat open-source în 2018. A fost construit pentru o singură treabă: rularea unui număr uriaș de sarcini de scurtă durată, care nu au încredere unele în altele, pe hardware comun. Ajunge acolo mai ales ștergând lucruri:

• Fără firmware, fără descoperirea hardware-ului. Kernelul e încărcat direct în memorie și pornit. Nimic nu caută dispozitive care nu există.
• Un model de dispozitive minuscul. O placă de rețea, un dispozitiv de blocuri, o consolă serială și încă câteva, toate virtio (dispozitive proiectate pentru mașini virtuale, nu imitații ale celor fizice). Fără USB, fără grafică, fără PCI.
• O bază de cod mică, sigură la memorie. Mai puțin cod care emulează dispozitive înseamnă mai puține locuri pentru un bug care îi permite oaspetelui să ajungă la host.
• O închisoare în jurul VMM-ului însuși. Fiecare proces Firecracker rulează într-un chroot, cu filtre seccomp care îi restricționează propriile apeluri de sistem și cu cgroups care îi limitează resursele. Dacă ceva ar ieși totuși din oaspete, ar ateriza într-o cușcă, nu pe host.

Cifrele publicate chiar de proiect sunt user space în doar 125 ms și sub 5 MiB de overhead de memorie per microVM. Sunt cifre de laborator, în cel mai bun caz; un sandbox real are nevoie și ca discul și rețeaua să fie configurate și ca un agent dinăuntru să fie gata să accepte comenzi, de aceea al nostru e gata în aproximativ o secundă. Asta e totuși destul de aproape de viteza unui container încât să poți crea câte unul pentru fiecare sarcină și să-l arunci după aceea.

Container vs microVM, în practică

Rândul care contează e al doilea. Cu un container, întrebarea „poate scăpa codul ăsta?” devine „există un bug accesibil oriunde în kernelul hostului?”. Cu un microVM, devine „există un bug în hypervisor sau în câteva dispozitive virtuale?”. A doua suprafață e mult mai mică și e cea pe care platformele cloud o apără deja pentru propriul hosting cu mai mulți clienți.

La ce renunți

Un microVM nu e un upgrade gratuit.

• Fără GPU-uri și fără afișaje. E pentru rularea codului, nu pentru desktopuri sau sarcini grafice.
• Mai puține dispozitive, mai puțină flexibilitate. Tot ce așteaptă hardware real sau o listă lungă de module de kernel nu se va simți acasă.
• Granițele au nevoie în continuare de politici. Un microVM cu ieșire deschisă poate trimite în continuare trafic pe care nu-l vrei; unul cu cheile tale API înăuntru le poate scurge în continuare. Izolarea protejează hostul de oaspete, nu secretele tale de codul căruia i le-ai dat.

Cum îl folosesc sandboxurile noastre

Fiecare sandbox EQVPS e un microVM Firecracker cu propriul kernel, de la 0,25 vCPU și 512 MB până la 8 vCPU și 16 GB. Vine cu Python 3.12, Node.js 22, bash, git și curl, are internet spre exterior și niciun port de intrare. Sandboxurile efemere sunt șterse când ai terminat; cele persistente își păstrează discul, iar punerea unuia pe pauză scrie starea microVM-ului pe disc, ca să nu coste nimic până la reluare. Starea sandboxurilor puse pe pauză se păstrează 14 zile. După asta, sandboxul e șters, iar id-ul lui returnează 410 sandbox_deleted.

Am ales microVM-urile în locul containerelor dintr-un singur motiv: codul care rulează într-un sandbox e, prin design, cod pe care nu l-a verificat nimeni. Rezultatul unui agent AI, pull requestul unui necunoscut, un benchmark cu o mie de programe scrise de un model. Pentru asta, un kernel propriu e granița pentru care merită să plătești. Detaliile a ce punem în jurul ei — tarife, cote, limita sincronă de 55 de secunde — sunt în documentația sandboxurilor.

Dacă vrei să compari mai în profunzime granița asta cu celelalte opțiuni, nivelurile de izolare pentru cod nesigur pune procesele, containerele, microVM-urile și VM-urile complete unele lângă altele. Iar dacă prețul la secundă e ce ți-a atras atenția, cum funcționează de fapt facturarea la secundă arată socoteala.