Firecracker-microVM'er på almindeligt dansk: en rigtig VM, der starter på en brøkdel af et sekund

Hvis du har læst noget om at køre AI-genereret kode sikkert, er du stødt på ordet microVM, som regel ved siden af Firecracker. Det forklares enten som „en letvægts-VM“ (sandt, men ikke til megen hjælp) eller med et diagram over kernens indvolde. Her er versionen midt imellem.

To ældre muligheder, og hvorfor ingen af dem passer

Start med de to ting, en microVM ligger imellem.

En container er en gruppe almindelige processer på din maskine, som kernen har indvilliget i at lyve for. Namespaces viser dem deres eget filsystem, deres egen procesliste og deres eget netværk; cgroups begrænser, hvor meget CPU og hukommelse de må bruge. Den starter på millisekunder, fordi intet nyt startes op. Men alle containere på en vært taler med den samme kerne. En kernefejl, der kan nås fra én container, er en vej ud af dem alle.

En virtuel maskine har sin egen kerne. Værtens CPU kører gæsten via hardwarevirtualisering (KVM på Linux), som om den havde sin egen computer. Grænsen er hypervisoren, som eksponerer langt mindre end en kernes hundredvis af systemkald. Prisen er vægt. En klassisk VM emulerer en hel pc: firmware, en PCI-bus, USB-controllere, et grafikkort, nogle gange et lydkort. Den starter gennem alt det, tager sekunder til minutter, og hver instans bærer på titals eller hundredvis af megabyte overhead.

En analogi, der holder rimelig godt: containere er lejligheder i samme bygning, med fælles fundament, rør og ledninger. VM'er er separate huse. Huse er sikrere naboer, men ingen bygger et til et besøg, der varer 20 sekunder.

Hvad Firecracker fjerner

Firecracker er en virtual machine monitor (programmet, der sætter en VM op og kører den oven på KVM), skrevet i Rust og udgivet som open source i 2018. Den blev bygget til ét job: at køre enorme mængder kortlivede arbejdsbyrder, der ikke stoler på hinanden, på delt hardware. Den når dertil mest ved at fjerne ting:

• Ingen firmware, ingen hardwaregenkendelse. Kernen indlæses direkte i hukommelsen og startes. Ingen leder efter enheder, der ikke findes.
• En bitte enhedsmodel. Et netværkskort, en blokenhed, en seriel konsol og et par stykker til, alle virtio (enheder designet til virtuelle maskiner frem for efterligninger af fysiske). Ingen USB, ingen grafik, ingen PCI.
• En lille, hukommelsessikker kodebase. Mindre kode, der emulerer enheder, betyder færre steder for en fejl, der lader gæsten nå værten.
• Et bur om selve VMM'en. Hver Firecracker-proces kører i en chroot med seccomp-filtre på sine egne systemkald og cgroups på sine ressourcer. Hvis noget brød ud af gæsten, ville det lande i et bur, ikke på værten.

Projektets egne offentliggjorte tal er brugerrum på helt ned til 125 ms og under 5 MiB hukommelsesoverhead pr. microVM. Det er bedste laboratorieværdier; en rigtig sandbox skal også have disk og netværk sat op og en agent indeni, der er klar til at modtage kommandoer, og derfor er vores klar på cirka et sekund. Det er stadig tæt nok på containerhastighed til at oprette én pr. opgave og smide den væk bagefter.

Container over for microVM i praksis

Rækken, der betyder noget, er den anden. Med en container bliver spørgsmålet „kan denne kode slippe ud?“ til „er der en fejl, der kan nås, et sted i værtens kerne?“. Med en microVM bliver det til „er der en fejl i hypervisoren eller i en håndfuld virtuelle enheder?“. Den anden flade er meget mindre, og det er den, som cloudplatforme allerede forsvarer for deres egen multi-tenant-hosting.

Hvad du giver afkald på

En microVM er ikke en gratis opgradering.

• Ingen GPU'er og ingen skærme. Den er til at køre kode, ikke til skriveborde eller grafik.
• Færre enheder, mindre fleksibilitet. Alt, der forventer rigtig hardware eller en lang liste kernemoduler, vil ikke føle sig hjemme.
• Grænser kræver stadig regler. En microVM med åben udgående trafik kan stadig sende trafik, du ikke vil have; en med dine API-nøgler indeni kan stadig lække dem. Isolation beskytter værten mod gæsten, ikke dine hemmeligheder mod den kode, du gav dem til.

Sådan bruger vores sandboxe den

Hver EQVPS-sandbox er én Firecracker-microVM med egen kerne, fra 0.25 vCPU og 512 MB op til 8 vCPU og 16 GB. Den har Python 3.12, Node.js 22, bash, git og curl, udgående internet og ingen indgående porte. Midlertidige sandboxe slettes, når du er færdig; persistente beholder deres disk, og at sætte en på pause skriver et snapshot af microVM'en til disken, så den ikke koster noget, før den genoptages. Snapshots af sandboxes på pause gemmes i 14 dage. Derefter slettes sandboxen, og dens id svarer 410 sandbox_deleted.

Vi valgte microVM'er frem for containere af én grund: Koden, der kører i en sandbox, er per definition kode, som ingen har gennemgået. Output fra en AI-agent, en fremmeds pull request, et benchmark med tusind programmer skrevet af en model. Til det er en egen kerne den grænse, der er værd at betale for. Detaljerne i det, vi har bygget omkring den — tariffer, kvoter, grænsen på 55 sekunder for synkrone kommandoer — står i sandbox-dokumentationen.

Vil du sammenligne denne grænse mere indgående med de andre muligheder, stiller isolationsniveauer for upålidelig kode processer, containere, microVM'er og fulde VM'er side om side. Og hvis det var sekundprisen, der fangede din interesse, viser hvordan afregning pr. sekund faktisk fungerer regnestykket.