Weave Ignite is an open source Virtual Machine (VM) manager with a container UX and built-in GitOps management.
Weave Ignite is an open source Virtual Machine (VM) manager with a container UX and built-in GitOps management.
- Combines Firecracker MicroVMs with Docker / OCI images to unify containers and VMs.
- Works in a GitOps fashion and can manage VMs declaratively and automatically like Kubernetes and Terraform.
Ignite is fast and secure because of Firecracker. This is an open source KVM implementation from AWS that is optimised for high security, isolation, speed and low resource consumption. AWS uses it as the foundation for their serverless offerings (AWS Lambda and Fargate) that need to load nearly instantly while also keeping users isolated (multitenancy). Firecracker has proven to be able to run 4000 micro-VMs on the same host!
What is Ignite?
Ignite makes Firecracker easy to use by adopting its developer experience from containers. With Ignite, you pick an OCI-compliant image (Docker image) that you want to run as a VM, and then just execute ignite run instead of docker run. There's no need to use VM-specific tools to build .vdi, .vmdk, or .qcow2 images, just do a docker build from any base image you want (e.g. ubuntu:18.04 from Docker Hub), and add your preferred contents.
When you run your OCI image using ignite run, Firecracker will boot a new VM in c.125 milliseconds (!) for you, using a default 4.19 linux kernel. If you want to use some other kernel, just specify the --kernel flag, pointing to another OCI image containing a kernel at /boot/vmlinux, and optionally your preferred modules. Next, the kernel executes /sbin/init in the VM, and it all starts up. After this, Ignite connects the VMs to any CNI network, integrating with e.g. Weave Net.
Ignite is a declarative Firecracker microVM administration tool, like Docker manages runC containers. Ignite runs VM from OCI images, spins VMs up/down in lightning speed, and can manage fleets of VMs efficiently using GitOps.
The idea is that Ignite makes Firecracker VMs look like Docker containers. Now we can deploy and manage full-blown VM systems just like e.g. Kubernetes workloads. The images used are OCI/Docker images, but instead of running them as containers, it executes as a real VM with a dedicated kernel and /sbin/init as PID 1.
Networking is set up automatically, the VM gets the same IP as any docker container on the host would.
And Firecracker is fast! Building and starting VMs takes just some fraction of a second, or at most some seconds. With Ignite you can get started with Firecracker in no time!
Use-cases
With Ignite, Firecracker is now much more accessible for end users, which means the ecosystem can achieve the next level of momentum due to the easy onboarding path thanks to a docker-like UX.
Although Firecracker was designed with serverless workloads in mind, it can equally well boot a normal Linux OS, like Ubuntu, Debian or CentOS, running an init system like systemd.
Having a super-fast way of spinning up a new VM, with a kernel of choice, running an init system like systemd allows to run system-level applications like the kubelet, which needs to "own" the full system.
Example use-cases:
- Set up many secure VMs lightning fast. It's great for testing, CI and ephemeral workloads
- Launch and manage entire "app ready" stacks from Git because Ignite supports GitOps!
- Run even legacy or special apps in lightweight VMs (eg for multi-tenancy, or using weird/edge kernels)
And - potentially - we can run a cloud of VMs 'anywhere' using Kubernetes for orchestration, Ignite for virtualization, GitOps for management, and supporting cloud native tools and APIs.
Scope
Ignite is different from Kata Containers or gVisor. They don't let you run real VMs, but only wrap a container in new layer providing some kind of security boundary (or sandbox).
Ignite on the other hand lets you run a full-blown VM, easily and super-fast, but with the familiar container UX. This means you can "move down one layer" and start managing your fleet of VMs powering e.g. a Kubernetes cluster, but still package your VMs like containers.
