MicroVM Firecracker w prostych słowach: prawdziwa maszyna wirtualna, która startuje w ułamku sekundy

Jeśli czytałeś cokolwiek o bezpiecznym uruchamianiu kodu wygenerowanego przez AI, widziałeś słowo microVM, zwykle obok Firecracker. Tłumaczy się je albo jako „lekką VM” (prawda, ale mało pomocna), albo diagramem wnętrzności jądra. Oto wersja pośrodku.

Dwie starsze opcje i dlaczego żadna nie pasuje

Zacznijmy od dwóch rzeczy, między którymi stoi microVM.

Kontener to grupa zwykłych procesów na twojej maszynie, które jądro zgodziło się okłamywać. Namespaces pokazują im własny system plików, listę procesów i sieć; cgroups ograniczają, ile CPU i pamięci mogą zużyć. Startuje w milisekundach, bo nic nowego nie jest uruchamiane. Ale wszystkie kontenery na hoście rozmawiają z tym samym jądrem. Błąd jądra osiągalny z jednego kontenera to wyjście ze wszystkich.

Maszyna wirtualna przynosi własne jądro. Procesor hosta, dzięki wirtualizacji sprzętowej (KVM w Linuksie), wykonuje gościa tak, jakby miał własny komputer. Granicą jest hipernadzorca, który udostępnia znacznie mniej niż setki wywołań systemowych jądra. Ceną jest waga. Klasyczna VM emuluje cały PC: firmware, magistralę PCI, kontrolery USB, kartę graficzną, czasem kartę dźwiękową. Uruchamia się przez to wszystko, trwa to od sekund do minut, a każda instancja niesie dziesiątki lub setki megabajtów narzutu.

Analogia, która dość dobrze się trzyma: kontenery to mieszkania w jednym budynku, ze wspólnymi fundamentami, rurami i instalacją elektryczną. VM to osobne domy. Domy są bezpieczniejszymi sąsiadami, ale nikt nie buduje domu na wizytę trwającą 20 sekund.

Co wyrzuca Firecracker

Firecracker to monitor maszyn wirtualnych (program, który przygotowuje i uruchamia VM na KVM) napisany w Rust i udostępniony jako open source w 2018 roku. Powstał do jednego zadania: uruchamiania ogromnej liczby krótkotrwałych, nieufających sobie obciążeń na współdzielonym sprzęcie. Osiąga to głównie przez usuwanie:

• Bez firmware'u i wykrywania sprzętu. Jądro jest ładowane bezpośrednio do pamięci i uruchamiane. Nikt nie szuka urządzeń, których nie ma.
• Malutki model urządzeń. Karta sieciowa, urządzenie blokowe, konsola szeregowa i kilka innych, wszystkie virtio (urządzenia zaprojektowane dla maszyn wirtualnych, a nie imitacje fizycznych). Bez USB, grafiki i PCI.
• Mała, bezpieczna pamięciowo baza kodu. Mniej kodu emulującego urządzenia to mniej miejsc na błąd, przez który gość sięgnie do hosta.
• Klatka wokół samego VMM. Każdy proces Firecrackera działa w chroot, z filtrami seccomp na własne wywołania systemowe i cgroups na zasoby. Gdyby coś wyrwało się z gościa, trafiłoby do klatki, a nie na hosta.

Liczby publikowane przez sam projekt: przestrzeń użytkownika już po 125 ms i poniżej 5 MiB narzutu pamięci na microVM. To najlepsze wyniki laboratoryjne; prawdziwy sandbox musi jeszcze przygotować dysk i sieć oraz poczekać na agenta w środku gotowego przyjmować polecenia, dlatego nasz jest gotowy w około sekundę. To wciąż na tyle blisko szybkości kontenera, że można tworzyć jeden na zadanie i potem go wyrzucać.

Kontener a microVM w praktyce

Ważny jest drugi wiersz. W kontenerze pytanie „czy ten kod może uciec?” zamienia się w „czy gdzieś w jądrze hosta jest osiągalny błąd?”. W microVM — w „czy jest błąd w hipernadzorcy albo w garstce wirtualnych urządzeń?”. Druga powierzchnia jest znacznie mniejsza i to właśnie ją platformy chmurowe i tak bronią we własnym hostingu wielodzierżawnym.

Z czego rezygnujesz

MicroVM to nie darmowe ulepszenie.

• Bez GPU i ekranów. Służy do uruchamiania kodu, nie do pulpitów ani grafiki.
• Mniej urządzeń, mniej elastyczności. Wszystko, co oczekuje prawdziwego sprzętu albo długiej listy modułów jądra, nie poczuje się jak w domu.
• Granice nadal wymagają zasad. MicroVM z otwartym ruchem wychodzącym wciąż może wysyłać ruch, którego nie chcesz; z twoimi kluczami API w środku wciąż może je ujawnić. Izolacja chroni hosta przed gościem, a nie twoje sekrety przed kodem, któremu je oddałeś.

Jak używają jej nasze sandboxy

Każdy sandbox EQVPS to jedna microVM Firecracker z własnym jądrem, od 0.25 vCPU i 512 MB do 8 vCPU i 16 GB. Ma Pythona 3.12, Node.js 22, bash, git i curl, dostęp do internetu wychodzącego i żadnych portów przychodzących. Sandboxy efemeryczne są usuwane, gdy skończysz; persistent zachowują dysk, a wstrzymanie zapisuje snapshot microVM na dysk, więc nic nie kosztuje aż do wznowienia. Snapshoty wstrzymanych sandboxów są trzymane 14 dni. Potem sandbox jest usuwany, a jego id odpowiada 410 sandbox_deleted.

Wybraliśmy microVM zamiast kontenerów z jednego powodu: kod w sandboxie to z definicji kod, którego nikt nie sprawdził. Wynik agenta AI, pull request nieznajomego, benchmark z tysiąca programów napisanych przez model. Do tego własne jądro to granica, za którą warto zapłacić. Szczegóły tego, co zbudowaliśmy wokół — taryfy, limity, 55-sekundowy limit polecenia synchronicznego — są w dokumentacji sandboxów.

Jeśli chcesz dokładniej porównać tę granicę z innymi opcjami, w poziomach izolacji dla niezaufanego kodu procesy, kontenery, microVM i pełne VM stoją obok siebie. A jeśli uwagę przyciągnęła cena za sekundę, jak naprawdę działa rozliczanie za sekundę pokazuje rachunki.