isoga - Fotolia
Use AWS Firecracker to build micro VMs for containerized apps
Firecracker has many of the benefits of containers and VMs, without some of their limitations. Here are a few things to know if you plan to use this technology at your organization.
The Micro VM has emerged as a virtualization alternative for enterprises that want the best of both worlds from traditional VMs and containers. With Firecracker, AWS is the latest vendor to pounce on this trend.
Micro VMs create virtual entities that are small, easily created in large volumes and resource-efficient like containers, yet provide the isolation and other security capabilities found in full VMs. Firecracker started as AWS' core internal virtualization vehicle for services such as AWS Lambda and AWS Fargate. But in November 2018, AWS officially open sourced Firecracker as a project that can be used to support serverless behaviors for enterprise projects.
Firecracker and other micro VMs are designed to accommodate modern development practices, such as microservices, that can be hindered through the use of VMs or containers alone. For example, VMs offer full isolation and support complete workloads, but can be resource-heavy and slow to spin up. Containers demand far fewer resources and can be created or destroyed quickly, but they lack the isolation and OS independence that full VMs provide.
Firecracker in perspective
AWS built Firecracker as a more secure multi-tenant alternative to containers. Firecracker uses a virtual machine monitor (VMM) -- a hypervisor -- based on KVM to create fully isolated VMs. Firecracker is often placed into the same category as other machine emulators and virtualization platforms such as QEMU.
Each micro VM that runs under Firecracker uses about 5 MB of memory for overhead, though it could easily provision 128 MB, 256 MB or more to each micro VM. Since they are small and use relatively few resources, Firecracker can create micro VMs on bare-metal systems in roughly 125 milliseconds -- with faster speeds expected over time. It is theoretically possible to deploy thousands of micro VMs on a single server, and the fast startup performance makes them well-suited for transient or short-lived workloads. This should allow Firecracker to compete with container technologies.
Administrators use a RESTful API to manage Firecracker and provision vCPU, memory, network and storage resources. The RESTful API can also start or stop micro VMs, configure metadata between the host and guest operating systems, and set up logging. Administrators can also use the API to set limits on the storage and network resources used by micro VMs, which prevents one or more micro VMs from monopolizing the system's I/O and impairing the performance of other micro VMs.
Firecracker's VMs are minimalist by design. All nonessential devices and functions have been eliminated, which reduces the memory requirements and potential attack vectors for each micro VM. AWS also wrote Firecracker in Rust, which should help protect execution threads and stop common vulnerabilities such as buffer overrun errors. In addition, the Firecracker process is "jailed" to limit access and employ only a small number of system calls.
It's also well-tested and validated for security because AWS already uses it internally for several high-volume services.
What users need for Firecracker
Users can run Firecracker on AWS bare-metal instances, as well as other on-premises bare-metal servers, laptops and other hardware.
Firecracker's prerequisites are generally light. Firecracker supports Linux x86_64 hosts running kernel version 4.14 or later. However, users can also deploy Firecracker on AWS with an i3.metal instance with Ubuntu 18.04 or later. Firecracker will also require read/write access to KVM, which users must first enable in the Linux kernel and configure through a Linux sudo command line.
Next, users can obtain the latest Firecracker binaries from GitHub. Since the Firecracker binaries have no other library dependencies, users can run Firecracker directly on the x86_64 Linux machine. Organizations that choose to compile or modify the Firecracker code base can clone the source code from the GitHub repository.
How to get Firecracker started
The actual use of Firecracker is slightly more involved. Once the Firecracker binaries are available, users will need an uncompressed Linux kernel binary to serve as the guest operating system, as well as an ext4 file system image to serve as the root file system. AWS has downloadable binaries of a kernel and root file system for testing purposes.
Firecracker is suited for production environments, as long as it's run inside an execution jail using a jailer binary, such as Firecracker Jailer v0.14.0. An execution jail provides the micro VM with greater security and protection from malicious attacks. You won't need an execution jail for testing and evaluation purposes.
Users will need to open one shell prompt to start and run Firecracker and a second to write to its API. Both shells will need to run in the same directory as the Firecracker binary. Use the second shell to set the guest OS kernel and guest root file system. Now, start the guest machine. Users will now need to return to the first shell and log in to the guest machine at the prompt that appears.
By default, the guest micro VM will have one vCPU and 128 MB of memory, though users can customize resource allocation through the API before starting the instance.
Micro VMs cannot be restarted. If a reboot command is issued inside the guest machine, Firecracker will shut down the micro VM. In this way, micro VMs can be well-suited to applications and services designed for immutable infrastructures.
The road forward
The Firecracker project is still in early development, but the open source community has already started to build additional features and capabilities. The current Firecracker roadmap in GitHub includes a range of new features, such as support for nested virtualization and more storage encryption. The hope is to add a greater level of automation to Firecracker using Chef-like recipes, and add support for AMD and ARM chips, Kubernetes, Docker, Kata containers and more.
It's not clear when, or even if, every roadmap feature will appear in the actual Firecracker platform. But such ambitious goals underscore the enthusiasm of the open source community and the potential for Firecracker to take its place among VMs and containers in the enterprise virtualization arsenal.
