Les microVM Firecracker expliquées simplement : une vraie VM qui démarre en une fraction de seconde

Si vous avez lu quoi que ce soit sur l'exécution sûre de code généré par IA, vous avez croisé le mot microVM, généralement à côté de Firecracker. On l'explique soit comme « une VM légère » (vrai, peu utile), soit avec un schéma des entrailles du noyau. Voici la version intermédiaire.

Deux options plus anciennes, et pourquoi aucune ne convient

Commençons par les deux choses entre lesquelles se place une microVM.

Un conteneur est un groupe de processus ordinaires sur votre machine auxquels le noyau a accepté de mentir. Les namespaces leur montrent leur propre système de fichiers, leur liste de processus et leur réseau ; les cgroups plafonnent le CPU et la mémoire qu'ils peuvent utiliser. Il démarre en millisecondes parce que rien de neuf n'est amorcé. Mais tous les conteneurs d'un hôte parlent au même noyau. Un bug du noyau accessible depuis un conteneur est une sortie pour tous.

Une machine virtuelle apporte son propre noyau. Le processeur de l'hôte, via la virtualisation matérielle (KVM sous Linux), exécute l'invité comme s'il avait son propre ordinateur. La frontière est l'hyperviseur, qui expose bien moins que les centaines d'appels système d'un noyau. Le prix, c'est le poids. Une VM classique émule un PC entier : micrologiciel, bus PCI, contrôleurs USB, carte graphique, parfois carte son. Elle démarre à travers tout cela, met des secondes voire des minutes, et chaque instance traîne des dizaines ou des centaines de mégaoctets de surcoût.

Une analogie qui tient assez bien : les conteneurs sont des appartements dans un même immeuble, partageant fondations, tuyaux et câblage. Les VM sont des maisons séparées. Les maisons font de meilleurs voisins, mais on n'en construit pas une pour une visite de 20 secondes.

Ce que Firecracker supprime

Firecracker est un moniteur de machines virtuelles (le programme qui prépare et exécute une VM au-dessus de KVM) écrit en Rust et publié en open source en 2018. Il a été conçu pour une seule tâche : faire tourner un très grand nombre de charges éphémères qui ne se font pas confiance sur du matériel partagé. Il y parvient surtout en supprimant :

• Pas de micrologiciel, pas de détection du matériel. Le noyau est chargé directement en mémoire et démarré. Personne ne cherche des périphériques qui n'existent pas.
• Un modèle de périphériques minuscule. Une carte réseau, un périphérique bloc, une console série et quelques autres, tous virtio (des périphériques pensés pour les machines virtuelles plutôt que des imitations de périphériques physiques). Ni USB, ni graphique, ni PCI.
• Une petite base de code sûre en mémoire. Moins de code qui émule des périphériques, c'est moins d'endroits pour un bug permettant à l'invité d'atteindre l'hôte.
• Une cage autour du VMM lui-même. Chaque processus Firecracker tourne dans un chroot, avec des filtres seccomp sur ses propres appels système et des cgroups sur ses ressources. Si quelque chose s'échappait de l'invité, il atterrirait dans une cage, pas sur l'hôte.

Les chiffres publiés par le projet lui-même : l'espace utilisateur en à peine 125 ms et moins de 5 Mio de surcoût mémoire par microVM. Ce sont des valeurs de laboratoire au mieux ; une vraie sandbox doit aussi préparer son disque et son réseau et attendre un agent interne prêt à recevoir des commandes, c'est pourquoi la nôtre est prête en une seconde environ. C'est encore assez proche de la vitesse d'un conteneur pour en créer une par tâche et la jeter ensuite.

Conteneur et microVM en pratique

La ligne qui compte est la deuxième. Avec un conteneur, la question « ce code peut-il s'échapper ? » devient « y a-t-il un bug accessible quelque part dans le noyau de l'hôte ? ». Avec une microVM, elle devient « y a-t-il un bug dans l'hyperviseur ou dans une poignée de périphériques virtuels ? ». La seconde surface est bien plus petite, et c'est celle que les plateformes cloud défendent déjà pour leur propre hébergement multi-locataire.

Ce que vous cédez

Une microVM n'est pas une amélioration gratuite.

• Pas de GPU ni d'affichage. Elle sert à exécuter du code, pas à des bureaux ou au graphisme.
• Moins de périphériques, moins de souplesse. Tout ce qui attend du vrai matériel ou une longue liste de modules noyau ne s'y sentira pas chez lui.
• Les frontières exigent quand même des règles. Une microVM au trafic sortant ouvert peut toujours envoyer du trafic indésirable ; une microVM contenant vos clés d'API peut toujours les divulguer. L'isolation protège l'hôte de l'invité, pas vos secrets du code auquel vous les avez confiés.

Comment nos sandboxes l'utilisent

Chaque sandbox EQVPS est une microVM Firecracker avec son propre noyau, de 0.25 vCPU et 512 MB jusqu'à 8 vCPU et 16 GB. Elle fournit Python 3.12, Node.js 22, bash, git et curl, dispose d'Internet en sortie et d'aucun port entrant. Les sandboxes éphémères sont supprimées quand vous avez fini ; les persistantes conservent leur disque, et la mise en pause écrit un instantané de la microVM sur disque, si bien qu'elle ne coûte rien jusqu'à sa reprise. Les instantanés en pause sont conservés 14 jours. Ensuite la sandbox est supprimée et son id répond 410 sandbox_deleted.

Nous avons choisi les microVM plutôt que les conteneurs pour une seule raison : le code qui tourne dans une sandbox est, par définition, du code que personne n'a relu. La sortie d'un agent IA, la pull request d'un inconnu, un benchmark de mille programmes écrits par un modèle. Pour cela, un noyau à soi est la frontière qui vaut son prix. Ce que nous avons construit autour — tarifs, quotas, limite de 55 secondes pour les commandes synchrones — est détaillé dans la documentation des sandboxes.

Pour comparer cette frontière plus en détail aux autres options, les niveaux d'isolation pour le code non fiable mettent côte à côte processus, conteneurs, microVM et VM complètes. Et si c'est le prix à la seconde qui vous intrigue, comment fonctionne vraiment la facturation à la seconde détaille les calculs.