En AWS re: Invent 2018, que se está llevando a cabo estos días en Las Vegas, se realizó
el anuncio de
Firecracker , una nueva tecnología de virtualización de código abierto basada en Linux KVM. Los autores prometen que con él, "en una fracción de segundo, puede ejecutar máquinas micro-virtuales livianas (microVM) en un entorno no virtualizado, obteniendo las ventajas de las máquinas virtuales tradicionales, en forma de seguridad y aislamiento de cargas de trabajo y contenedores, en forma de uso eficiente de los recursos".
Antecedentes
Firecracker está siendo desarrollado por empleados de Amazon Web Services que se propusieron mejorar el consumo de recursos y la vida general de los usuarios de servicios como AWS Lambda (lanzado en 2014 y hoy nos permite decir que el modelo sin servidor seguirá existiendo) y AWS Fargate (apareció hace un año )
El proyecto se basó en el desarrollo de código abierto de Google,
crosvm de Chromium OS, que está escrito en Rust y es responsable de lanzar sistemas operativos con virtualización de dispositivos (pero sin emular hardware real). Por lo tanto, el código de Firecracker también está escrito
en el lenguaje Rust , y sus autores prometen devolver sus correcciones a la base del código del proyecto principal, aunque los proyectos en sí mismos han diferido mucho en su propósito.
El primer lanzamiento público de Firecracker -
0.1.0 - tuvo lugar en marzo de este año, y el último último
lanzamiento -
0.11.0 - hace solo unos días. Comencé a escribir este artículo poco después del anuncio en Internet de Firecracker, cuando el proyecto tenía 76 estrellas en GitHub, y en el momento de la publicación, esta cifra superaba las 500.
Características del petardo
El componente principal de Firecracker es el monitor de máquina virtual (VMM), que utiliza Linux KVM para crear y ejecutar los llamados microVM. Los autores llaman a su producto "una alternativa basada en la nube a QEMU" [utilizada por Kata Containers], "destinada únicamente para el lanzamiento seguro y eficiente de contenedores".
Y aquí hay un ejemplo de un sistema host que ejecuta los microVM mencionados:
Los desarrolladores luchan por el minimalismo, incluyendo en el producto solo lo más necesario y, por lo tanto, asegurando costos mínimos de memoria y, al mismo tiempo, reduciendo el potencial de posibles vulnerabilidades. En Firecracker,
solo se emulan
4 dispositivos : virtio-net, virtio-block, consola serie y un teclado con 1 botón para detener el funcionamiento de microVM. Como los sistemas operativos host e invitados, los sistemas operativos basados en el
kernel de Linux versión 4.14 ( lanzamiento de noviembre del año pasado) y superior son actualmente compatibles, y los planes actuales de los desarrolladores son admitir las dos últimas ramas estables del kernel de Linux. En términos de hardware, hasta ahora solo se admiten procesadores Intel, pero AMD y ARM están en la agenda.
Firecracker en sí consiste en un solo proceso VMM, que al inicio hace que la API de punto final (RESTful) esté disponible en la máquina host. La API en sí se
describe en el formato OpenAPI y, en particular, le permite iniciar microVM con los parámetros especificados (imagen del núcleo, sistema de archivos raíz, argumentos de arranque) y detenerlo, configurar máquinas virtuales (número de vCPU, RAM, plantilla para CPU), agregar a Las interfaces de red, los discos (presentados como dispositivos de bloque, los modos de lectura-escritura y solo lectura están disponibles), configuran el sistema para registros y métricas.
Las principales ventajas de Firecracker son la seguridad (enfoque en la computación multiinquilino, varios niveles de aislamiento), alto rendimiento (se puede lanzar microVM
en 125 ms , y los autores prometen mejorar esta cifra el próximo año), sobrecarga mínima (cada microVM consume alrededor de 5 megabytes memoria). Lo que agrega peso al proyecto: ya se ha probado "en batalla" y proporciona el trabajo de varios servicios de AWS (incluidos los mencionados Lambda y Fargate).
Detalles de seguridad
Entre las principales características de Firecracker, centradas en garantizar un alto nivel de seguridad, se mencionan las siguientes:
- Modelo de invitado simple (para todos los invitados, solo se proporciona el mínimo, ver arriba sobre 4 dispositivos).
- Aislar el proceso de Firecracker con cgroups y seccomp BPF, así como un conjunto limitado de llamadas permitidas al sistema.
- Enlace estático del proceso de Firecracker para iniciarlo de forma aislada del entorno host.
Demo de petardo
El blog de AWS
mostró cómo puedes probar los microVM en acción. Para hacer esto, simplemente cree una instancia de i3.metal y cargue 3 archivos (archivo ejecutable de
firecracker , imagen raíz de FS, kernel de Linux):
Después de eso, establezca los derechos necesarios para / dev / kvm:
$ sudo setfacl -mu:${USER}:rw /dev/kvm
Establecer la configuración para la primera máquina invitada:
$ 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 }"
... entonces el núcleo para ella:
$ 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\" }"
... y 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 }"
Queda por lanzar el invitado:
Resultado:
¿Qué pasa con otros proyectos de contenedores?
Aunque los autores de Firecracker prometen que se "integrará con tiempos de ejecución de contenedores populares", esto es lo que
responden cuando se les pregunta si el proyecto se puede usar con contenedores Kubernetes, Docker o Kata:
“Todavía no. Estamos desarrollando Firecracker como un proyecto de código abierto porque ofrece un enfoque de seguridad significativamente diferente en el lanzamiento de contenedores. Esperamos que otras comunidades que crean tecnologías de código abierto para contenedores lo encuentren útil. "Estamos trabajando para garantizar que Firecracker se integre sin problemas en el ecosistema de contenedores, con el objetivo de una integración perfecta en el futuro, proporcionando más opciones para aislar las cargas de trabajo de contenedores".
PS
Lea también en nuestro blog: