No AWS re:Invent 2018, a Amazon anunciou o lançamento do Firecracker, uma tecnologia de virtualização open source que foi criada especificamente para "criar e gerenciar contêineres seguros e multilocatários, e serviços baseados em funções". O Firecracker é um fork do Virtual Machine Monitor (crosvm) do Chromium OS, uma VMM de código aberto escrita em Rust, com tecnologia usada por trás dos serviços AWS Fargate e AWS Lambda da Amazon.
De acordo com o blog AWS Open Source, o Firecracker é uma nova tecnologia de virtualização que permite aos engenheiros implantar micro máquinas virtuais ou "microVMs". Da mesma maneira que projetos de VM leves existentes, como o Kata Containers e o gVisor, as microVMs do Firecracker visam combinar as propriedades de segurança e isolamento de carga de trabalho das VMs tradicionais com a velocidade e a eficiência de recursos habilitadas pelos contêineres. De acordo com Jeff Barr, chief evangelist da AWS, a popularidade crescente das ofertas "sem servidor" da AWS foi a motivação para criar o Firecracker:
[Ao iniciar o AWS Lambda,] usamos instâncias do EC2 por cliente para fornecer segurança e isolamento sólidos entre clientes. Com o crescimento do Lambda, vimos a necessidade da tecnologia fornecer um ambiente de tempo de execução altamente seguro, flexível e eficiente para serviços como o Lambda e o Fargate. Usando nossa experiência na criação de instâncias isoladas do EC2 com a tecnologia de virtualização de hardware, iniciamos um esforço para criar uma VMM que fosse adaptada para integrar-se aos ecossistemas de contêineres.
Em essência, o Firecracker é um monitor de máquina virtual (VMM) que usa a Máquina Virtual baseada em Kernel do Linux (KVM). O Firecracker tem um design minimalista, excluindo dispositivos desnecessários e com funcionalidade voltada para convidados para reduzir o espaço ocupado pela memória e a área de superfície de ataque de segurança de cada microVM. Existem apenas quatro dispositivos emulados: virtio-net, virtio-block, um console serial e um controlador de teclado de um botão usado apenas para parar o microVM. A AWS afirma que isso, junto com um processo simplificado de carregamento do kernel, permite um tempo de inicialização abaixo de 125 ms.
O repositório GitHub do projeto contém documentos detalhados de decisão de projeto que discutem as principais opções arquitetônicas. Por exemplo, cada processo do Firecracker encapsula uma e apenas uma microVM, e esse processo executa os seguintes encadeamentos: API, VMM e vCPU (s). Um documento de especificação declara garantias de tempo de execução que quantificam a promessa do Firecracker de permitir a "execução mínima de sobrecarga de cargas de trabalho sem contêiner e sem servidor". Essas especificações são impostas por testes de integração que são executados para cada mesclagem de PR e ramificação principal, e são executadas em uma instância bare metal I3.metal com hyperthreading desativado.
Uma API de controle RESTful é fornecida para o Firecracker (especificado no formato OpenAPI), que lida com a limitação de taxa de recursos para microVMs e também fornece um serviço de metadados microVM para permitir o compartilhamento de dados de configuração entre o host e o convidado. O encadeamento da API é totalmente responsável pelo servidor da API do Firecracker e pelo plano de controle associado. Esse encadeamento nunca está no caminho rápido da máquina virtual.
A thread da VMM expõe o "modelo de máquina, o modelo de dispositivo legado mínimo, o serviço de metadados da microVM (MMDS) e o dispositivo VirtIO emulado Net and Block devices, completo com limitação de taxa de E/S". Há um ou mais encadeamentos de vCPU (um por núcleo de CPU convidado) e esses encadeamentos são criados via KVM e executam o loop principal KVM_RUN. Eles executam E/S síncronas e operações de E/S mapeadas em memória em modelos de dispositivos.
(Imagem tirada do repositório Firecracker GitHub)
O Firecracker é executado em hosts Linux com kernels 4.14 ou mais recentes e com sistemas operacionais convidados Linux, e atualmente suporta CPUs Intel, com suporte planejado para AMD e Arm. O Firecracker também será integrado a tempos de execução populares de contêineres e há uma implementação protótipo de firecracker-containerd no GitHub. Inicialmente, este projeto permite o lançamento de um contêiner por microVM. Há também um problema em aberto para o suporte do Firecracker dentro da estrutura de agendamento Nomad da HashiCorp.
O roadmap do firecracker-containerd indica que o projeto se destina a ser um "componente drop-in que pode executar uma variedade de aplicativos em contêiner" e, portanto, o plano de curto prazo inclui trabalhar para suportar padrões de contêineres como o Open Container Initiative (OCI) e CNI (Container Networking Interface). A conclusão deste projeto permitiria a execução de cargas de trabalho do Firecracker dentro da popular estrutura de orquestração de contêineres Kubernetes.
Do ponto de vista da segurança, todos os encadeamentos vCPU do Firecracker são considerados como executando código mal-intencionado assim que foram iniciados e, consequentemente, "esses encadeamentos maliciosos precisam ser contidos". A contenção é implementada ao aninhar várias "zonas de confiança", que são incrementadas de "menos confiáveis ou menos seguras (encadeamentos vCPU convidados)" para "mais confiável ou mais seguro (host)". Na produção, o Firecracker deve ser iniciado apenas por meio do jailer binary (o binário do Firecracker pode ser executado diretamente no momento, mas esse recurso será removido em uma versão futura).
O binário do jailer do Firecracker configura recursos do sistema que exigem permissões elevadas (por exemplo, cgroup, chroot), descarta privilégios e, em seguida, exec() s no binário Firecracker, que é executado como um processo não privilegiado. Passado esse ponto, o Firecracker só pode acessar recursos aos quais um terceiro privilegiado concede acesso, por exemplo, copiando um arquivo para o chroot ou passando um descritor de arquivo. Os filtros Seccomp são usados para limitar ainda mais as chamadas de sistema que o Firecracker pode usar.
De acordo com Arun Gupta, principal open source technologist da AWS, e Linda Lian, gerente sênior de marketing de produto da AWS, o Firecracker incentiva contribuições de clientes e da comunidade de desenvolvedores. O Firecracker é licenciado sob a licença Apache, versão 2.0. As seções do código Crosvm são licenciadas sob uma licença BSD-3-Clause. Qualquer contribuição é bem-vinda desde que se alinhe com seu "contrato".
Joe Beda, fundador e CTO da Heptio (recentemente adquirido pela VMware), observou em um tópico do Twitter relacionado que, embora exista uma lista de mantenedores do projeto, ele atualmente lista a equipe da Amazon que está trabalhando no projeto, e "não parece que há espaço para mantenedores externos ". Beda também observou a falta de um contrato de licença de contribuinte (CLA) ou certificado de origem do desenvolvedor (DCO):
Uma coisa que falta no Firecracker é o DCO ou o CLA. Isso é muito surpreendente! Uma delas é típica ao aceitar contribuições externas. Espero ver isso corrigido o mais rápido possível assim que os PRs externos começarem a chegar. Será interessante ver o que selecionarão.
Gupta respondeu agradecendo Beda pelo feedback e declarou que "vamos ativamente ouvir a comunidade e os clientes ativamente e evoluir!"
O GitHub do Firecracker contém um guia de introdução detalhado. A equipe do Katacoda também forneceu um tutorial interativo de introdução para desenvolvedores que não desejam instalar nada localmente.
Detalhes adicionais sobre o Firecracker podem ser encontrados no site do projeto, através do repositório Firecracker no GitHub, ou através do grupo no Slack.