À AWS re: Invent 2018, qui se déroule ces jours-ci à Las Vegas,
l' annonce de
Firecracker , une nouvelle technologie de virtualisation open source basée sur Linux KVM, a
eu lieu . Les auteurs promettent qu'avec cela, "en une fraction de seconde, vous pouvez exécuter des machines micro-virtuelles légères (microVM) dans un environnement non virtualisé, en obtenant les avantages des machines virtuelles traditionnelles - sous la forme de la sécurité et de l'isolement des charges de travail et des conteneurs - sous la forme d'une utilisation efficace des ressources".
Contexte
Firecracker est développé par des employés d'Amazon Web Services qui ont pour objectif d'améliorer la consommation des ressources et la durée de vie globale des utilisateurs de services tels que AWS Lambda (lancé en 2014 et aujourd'hui nous permet de dire que le modèle sans serveur
continuera d' exister) et AWS Fargate (apparu il y a un an )
Le projet était basé sur le développement Open Source de Google,
crosvm de Chromium OS, qui est écrit en Rust et est responsable du lancement des systèmes d'exploitation avec la virtualisation des appareils (mais sans émuler du vrai matériel). Par conséquent, le code de Firecracker est également écrit
en langage Rust , et ses auteurs promettent de retourner leurs corrections à la base de code du projet parent, bien que les projets eux-mêmes aient divergé considérablement dans leur objectif.
La première version publique de Firecracker -
0.1.0 - a eu lieu en mars de cette année, et la dernière
version la plus récente -
0.11.0 - il y a quelques jours à peine. J'ai commencé à écrire cet article peu de temps après l'annonce sur Internet de Firecracker, lorsque le projet comptait 76 étoiles sur GitHub, et au moment de la publication, ce chiffre dépassait les 500.
Caractéristiques du pétard
Le composant principal de Firecracker est le moniteur de machine virtuelle (VMM), qui utilise Linux KVM pour créer et exécuter les soi-disant microVM. Les auteurs appellent leur produit «une alternative basée sur le cloud à QEMU» [utilisé par Kata Containers], «destiné uniquement au lancement sûr et efficace des conteneurs».
Et voici un exemple d'un système hôte qui exécute les microVM mentionnés:
Les développeurs s'efforcent de minimaliser, en n'incluant dans le produit que le plus nécessaire et en garantissant ainsi des coûts de mémoire minimaux, tout en réduisant le potentiel de vulnérabilités potentielles. Dans Firecracker,
seuls 4 appareils sont émulés: virtio-net, virtio-block, console série et un clavier avec 1 bouton utilisé pour arrêter le fonctionnement de microVM. En tant que systèmes d'exploitation hôte et invité, les systèmes d'exploitation basés sur la
version 4.14 du noyau Linux ( sortie à partir de novembre de l'année dernière) et plus sont actuellement pris en charge, et les plans actuels des développeurs sont de prendre en charge les deux dernières branches stables du noyau Linux. En termes de matériel, seuls les processeurs Intel sont pris en charge jusqu'à présent, mais AMD et ARM sont à l'ordre du jour.
Firecracker lui-même se compose d'un seul processus VMM, qui au démarrage rend l'API de point de terminaison (RESTful) disponible sur la machine hôte. L'API elle-même est
décrite au format OpenAPI et, en particulier, vous permet de démarrer microVM avec les paramètres spécifiés (image du noyau, système de fichiers racine, arguments de démarrage) et de l'arrêter, de configurer des machines virtuelles (nombre de vCPU, RAM, modèle pour CPU), ajouter à les interfaces réseau, les disques (présentés comme des périphériques blocs, des modes lecture-écriture et lecture seule sont disponibles), configurent le système pour les journaux et les mesures.
Les principaux avantages de Firecracker sont la sécurité (concentration sur l'informatique multi-locataire, plusieurs niveaux d'isolement), les hautes performances (la microVM peut être lancée
en 125 ms , et les auteurs promettent d'améliorer ce chiffre l'année prochaine), une surcharge minimale (chaque microVM consomme environ 5 mégaoctets mémoire). Ce qui ajoute du poids au projet - il a déjà été testé "au combat" et fournit le travail d'un certain nombre de services AWS (y compris les Lambda et Fargate mentionnés).
Détails de sécurité
Parmi les principales caractéristiques de Firecracker, axées sur la garantie d'un haut niveau de sécurité, les suivantes sont mentionnées:
- Modèle invité simple (pour tous les invités, seul le minimum est fourni - voir ci-dessus environ 4 appareils).
- Isoler le processus Firecracker avec cgroups et seccomp BPF, ainsi qu'un ensemble limité d'appels système autorisés.
- Liaison statique du processus Firecracker pour le démarrer indépendamment de l'environnement hôte.
Démo de pétard
Le blog AWS a
montré comment vous pouvez essayer les microVM en action. Pour ce faire, il suffit de créer une instance i3.metal et d'y télécharger 3 fichiers (fichier exécutable du
firecracker , image FS racine, noyau Linux):
Après cela - définissez les droits nécessaires sur / dev / kvm:
$ sudo setfacl -mu:${USER}:rw /dev/kvm
Définissez la configuration de la première machine invitée:
$ curl --unix-socket /tmp/firecracker.sock -i \ -X PUT "http://localhost/machine-config" \ -H "accept: application/json" \ -H "Content-Type: application/json" \ -d "{ \"vcpu_count\": 1, \"mem_size_mib\": 512 }"
... puis le cœur pour elle:
$ curl --unix-socket /tmp/firecracker.sock -i \ -X PUT "http://localhost/boot-source" \ -H "accept: application/json" \ -H "Content-Type: application/json" \ -d "{ \"kernel_image_path\": \"./hello-vmlinux.bin\", \"boot_args\": \"console=ttyS0 reboot=k panic=1 pci=off\" }"
... et root FS:
$ curl --unix-socket /tmp/firecracker.sock -i \ -X PUT "http://localhost/drives/rootfs" \ -H "accept: application/json" \ -H "Content-Type: application/json" \ -d "{ \"drive_id\": \"rootfs\", \"path_on_host\": \"./hello-rootfs.ext4\", \"is_root_device\": true, \"is_read_only\": false }"
Reste à lancer réellement l'invité:
Résultat:
Qu'en est-il des autres projets de conteneurs?
Bien que les auteurs de Firecracker promettent son «intégration avec des runtimes de conteneurs populaires», c'est ce qu'ils
répondent lorsqu'on leur demande si le projet peut être utilisé avec des conteneurs Kubernetes, Docker ou Kata:
«Pas encore. Nous développons Firecracker en tant que projet Open Source car il offre une approche très différente de la sécurité dans le lancement de conteneurs. Nous espérons que d'autres communautés créant des technologies Open Source pour les conteneurs le trouveront utile. «Nous nous efforçons de garantir que Firecracker s'intègre de manière transparente dans l'écosystème des conteneurs - dans le but d'une intégration transparente à l'avenir, offrant plus d'options pour isoler les charges de travail des conteneurs.»
PS
Lisez aussi dans notre blog: