ignite

Ignite a Firecracker microVM

3,486

224

3,486

174

View on GitHub

Top Related Projects

firecracker

25,056

Secure and fast microVMs for serverless computing.

Kata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs. https://katacontainers.io/

containerd

17,086

An open and reliable container runtime

k3s

27,843

Lightweight Kubernetes

incus

2,453

Powerful system container and virtual machine manager

Quick Overview

Ignite is an open-source project by Weaveworks that provides a virtualization solution for running containerized, immutable VMs using Firecracker. It combines the speed and efficiency of containers with the security and isolation of VMs, making it ideal for running microVMs in Kubernetes environments.

Pros

Fast and lightweight: Ignite leverages Firecracker for quick VM startup times and low resource overhead
Container-like experience: Uses OCI images and provides a Docker-like CLI for managing VMs
Kubernetes integration: Can be used as a runtime for Kubernetes, enabling VM workloads in container orchestration
Improved isolation: Offers better security and resource isolation compared to traditional containers

Cons

Limited OS support: Primarily designed for Linux-based systems
Relatively new technology: May have fewer community resources and integrations compared to more established solutions
Requires specific hardware: Needs CPU virtualization support and is optimized for x86_64 architecture
Learning curve: Users familiar with traditional VMs or containers may need time to adapt to Ignite's concepts

Getting Started

To get started with Ignite, follow these steps:

Install Ignite on a Linux system with KVM support:

export VERSION=v0.10.0
curl -fLo ignite https://github.com/weaveworks/ignite/releases/download/${VERSION}/ignite-amd64
chmod +x ignite
sudo mv ignite /usr/local/bin

Run your first Ignite VM:

sudo ignite run weaveworks/ignite-ubuntu --name my-vm --cpus 2 --memory 1GB --size 6GB

Connect to the VM:

sudo ignite attach my-vm

Stop and remove the VM:

sudo ignite stop my-vm
sudo ignite rm my-vm

For more advanced usage and integration with Kubernetes, refer to the official Ignite documentation.

Competitor Comparisons

firecracker

25,056

Secure and fast microVMs for serverless computing.

Pros of Firecracker

Developed and battle-tested by Amazon for AWS Lambda and Fargate
Extremely lightweight and fast boot times (as low as 125ms)
Strong isolation and security features

Cons of Firecracker

Lower-level implementation, requiring more setup and configuration
Limited guest OS support (primarily Linux-based)
Steeper learning curve for newcomers to virtualization

Code Comparison

Ignite (using Docker-like syntax):

ignite run weaveworks/ignite-ubuntu \
    --name my-vm \
    --cpus 2 \
    --memory 2GB \
    --size 6GB

Firecracker (using API calls):

curl --unix-socket /tmp/firecracker.socket -i \
  -X PUT 'http://localhost/boot-source' \
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
      "kernel_image_path": "/path/to/kernel",
      "boot_args": "console=ttyS0 reboot=k panic=1 pci=off"
  }'

Ignite provides a more user-friendly, Docker-like experience, while Firecracker offers lower-level control but requires more detailed configuration. Ignite builds on top of Firecracker, adding easier management and integration with container workflows, making it more accessible for users familiar with container technologies.

kata-containers

5,451

Pros of Kata Containers

Provides stronger isolation and security by using lightweight VMs
Supports multiple architectures (x86_64, ARM, POWER, s390x)
Offers better compatibility with existing container ecosystems

Cons of Kata Containers

Higher resource overhead compared to Ignite
More complex setup and configuration process
Slower startup times due to VM initialization

Code Comparison

Kata Containers configuration example:

runtime:
  type: "kata"
  path: "/usr/bin/kata-runtime"
  runtimeArgs: ["--disable-guest-seccomp"]

Ignite configuration example:

apiVersion: ignite.weave.works/v1alpha4
kind: VM
metadata:
  name: my-vm
spec:
  image:
    oci: weaveworks/ignite-ubuntu

Both projects aim to provide lightweight virtualization solutions, but they take different approaches. Kata Containers focuses on creating lightweight VMs for each container, offering stronger isolation at the cost of higher resource usage. Ignite, on the other hand, uses Firecracker microVMs to create lightweight and fast VMs, sacrificing some isolation for better performance and resource efficiency.

The code examples show the different configuration styles: Kata Containers uses a runtime-based approach, while Ignite uses a Kubernetes-like declarative configuration.

containerd

17,086

An open and reliable container runtime

Pros of containerd

Widely adopted industry standard for container runtime
Extensive ecosystem and tooling support
Highly performant and scalable for large-scale deployments

Cons of containerd

Primarily focused on container management, not VM-like environments
Steeper learning curve for users new to container technologies
Requires additional components for full container orchestration

Code Comparison

containerd:

import (
    "github.com/containerd/containerd"
    "github.com/containerd/containerd/cio"
)

client, err := containerd.New("/run/containerd/containerd.sock")
container, err := client.NewContainer(ctx, "example")
task, err := container.NewTask(ctx, cio.NewCreator(cio.WithStdio))

Ignite:

import (
    "github.com/weaveworks/ignite/pkg/apis/ignite"
    "github.com/weaveworks/ignite/pkg/apis/ignite/validation"
)

vm := &ignite.VM{
    Spec: ignite.VMSpec{
        Image: &ignite.ImageSpec{OCI: "weaveworks/ignite-ubuntu"},
    },
}
err := validation.ValidateVM(vm).ToAggregate()

Summary

containerd is a widely-adopted, high-performance container runtime with extensive ecosystem support, while Ignite focuses on providing VM-like environments using container technologies. containerd excels in large-scale container deployments, whereas Ignite offers a more familiar VM-like experience for users transitioning from traditional virtualization.

k3s

27,843

Lightweight Kubernetes

Pros of k3s

Lightweight Kubernetes distribution, ideal for edge computing and IoT devices
Easy installation and minimal resource requirements
Active community and regular updates from Rancher Labs

Cons of k3s

Limited to running containers, unlike Ignite's support for VMs
May lack some advanced Kubernetes features found in full distributions

Code Comparison

k3s installation:

curl -sfL https://get.k3s.io | sh -

Ignite VM creation:

ignite run weaveworks/ignite-ubuntu \
    --name my-vm \
    --cpus 2 \
    --memory 1GB \
    --size 6GB

Key Differences

Ignite focuses on running Firecracker microVMs, while k3s is a lightweight Kubernetes distribution
k3s is more suitable for container orchestration, while Ignite is better for running isolated VMs
Ignite provides VM-like isolation with container-like convenience, whereas k3s offers a streamlined Kubernetes experience

Use Cases

k3s: Edge computing, IoT devices, resource-constrained environments requiring Kubernetes
Ignite: Serverless containers, isolated development environments, running untrusted workloads

Both projects aim to simplify deployment and management of containerized workloads, but they approach the problem from different angles. The choice between them depends on specific requirements and use cases.

incus

2,453

Powerful system container and virtual machine manager

Pros of Incus

Broader system container support, including traditional LXC containers and VMs
More mature project with a longer history and larger community
Supports multiple architectures and operating systems

Cons of Incus

Generally more complex to set up and manage compared to Ignite
May have higher resource overhead for some use cases
Less focused on Kubernetes integration

Code Comparison

Ignite (Firecracker VM creation):

ignite run weaveworks/ignite-ubuntu \
    --name my-vm \
    --cpus 2 \
    --memory 2GB \
    --size 6GB

Incus (LXD container creation):

lxc launch ubuntu:20.04 my-container

Both projects aim to provide lightweight virtualization solutions, but they have different focuses. Ignite is designed specifically for running Firecracker microVMs, making it well-suited for Kubernetes environments and serverless workloads. Incus (formerly LXD) offers a more versatile approach, supporting both system containers and VMs, making it a good choice for a wider range of use cases, including development environments and traditional hosting scenarios.

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Deprecated

This repository is no longer maintained. For a more up-to-date way to manage microVMs, please take a look at Flintlock.

Weave Ignite

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. Firecracker 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?

Read the announcement blog post here: https://www.weave.works/blog/fire-up-your-vms-with-weave-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 about 125 milliseconds (!) for you using a default 4.19 Linux kernel. If you want to use some other kernel, just specify the --kernel-image 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, similar to how Docker manages runC containers. Ignite runs VM from OCI images, spins VMs up/down at 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 their contents 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 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 a next level of momentum due to the easy onboarding path thanks to the 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 running system-level applications like the kubelet, which need 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 a VM 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.

Installing

Please check out the Releases Page.

How to install Ignite is covered in docs/installation.md or on Read the Docs.

Guidance on Cloud Providers' instances that can run Ignite is covered in docs/cloudprovider.md.

Getting Started

WARNING: In it's v0.X series, Ignite is in alpha, which means that it might change in backwards-incompatible ways.

Note: At the moment ignite and ignited need root privileges on the host to operate due to certain operations (e.g. mount). This will change in the future.

# Let's run the weaveworks/ignite-ubuntu OCI image as a VM
# Use 2 vCPUs and 1GB of RAM, enable automatic SSH access and name it my-vm
ignite run weaveworks/ignite-ubuntu \
    --cpus 2 \
    --memory 1GB \
    --ssh \
    --name my-vm

# List running VMs
ignite ps

# List Docker (OCI) and kernel images imported into Ignite
ignite images
ignite kernels

# Get the boot logs of the VM
ignite logs my-vm

# SSH into the VM
ignite ssh my-vm

# Inside the VM you can check that the kernel version is different, and the IP address came from the container
# Also the memory is limited to what you specify, as well as the vCPUs
> uname -a
> ip addr
> free -m
> cat /proc/cpuinfo

# Rebooting the VM tells Firecracker to shut it down
> reboot

# Cleanup
ignite rm my-vm

For a walkthrough of how to use Ignite, go to docs/usage.md.

Getting Started the GitOps way

Ignite is a âGitOps-firstâ project, GitOps is supported out of the box using the ignited gitops command. Previously this was integrated as ignite gitops, but this functionality has now moved to ignited, Ignite's upcoming daemon binary.

In Git you declaratively store the desired state of a set of VMs you want to manage. ignited gitops reconciles the state from Git, and applies the desired changes as state is updated in the repo. It also commits and pushes any local changes/additions to the managed VMs back to the repository.

This can then be automated, tracked for correctness, and managed at scale - just some of the benefits of GitOps.

The workflow is simply this:

Run ignited gitops [repo], where repo is an SSH url to your Git repo
Create a file with the VM specification, specifying how much vCPUs, RAM, disk, etc. youâd like for the VM
Run git push and see your VM start on the host

See it in action! (Note: The screencast is from an older version which differs somewhat)

For the complete guide, see docs/gitops.md.

Awesome Ignite

Want to see how awesome Ignite is?

Take a look at the awesome-ignite page!

Documentation

Please refer to the following documents powered by Read the Docs:

Frequently Asked Questions

See the FAQ.md document.

Architecture

docs/architecture.png

Want to know how Ignite really works under the hood? Check out this TGIK session from Joe Beda about it:

Base images and kernels

A base image is an OCI-compliant image containing some operating system (e.g. Ubuntu). You can follow normal docker build patterns for customizing your VM's rootfs.

A kernel image is an OCI-compliant image containing a /boot/vmlinux (an uncompressed kernel) executable (can be a symlink). You can also put supporting kernel modules in /lib/modules if needed. You can mix and match any kernel and any base image to create a VM.

As the upstream centos:7 and ubuntu:18.04 images from Docker Hub don't have all the utilities and packages you'd expect in a VM (e.g. an init system), we have packaged some reference base images and a sample kernel image to get started quickly.

You can use the following pre-built images with Ignite. They are built on the normal Docker Hub images, but add systemd, openssh, and similar utilities.

Base Images

Ubuntu 18.04 Dockerfile (weaveworks/ignite-ubuntu)
CentOS 7 Dockerfile (weaveworks/ignite-centos)
Amazon Linux 2 Dockerfile (weaveworks/ignite-amazonlinux)
The Firecracker Team's Alpine Image (weaveworks/ignite-alpine)

These prebuilt images can be given to ignite run directly.

Kernel Images

Default Kernel Image (weaveworks/ignite-kernel)
The Firecracker Team's Kernel (weaveworks/ignite-amazon-kernel)

Tutorials

Guide: Run a HA Kubernetes cluster with Ignite and kubeadm (weaveworks/ignite-kubeadm)
Guide: Run a set of Ignite VMs with Footloose

Contributing

Please see CONTRIBUTING.md and our Code Of Conduct.

Other interesting resources include:

Getting Help

If you have any questions about, feedback for or problems with ignite:

Invite yourself to the Weave Users Slack.
Ask a question on the #ignite slack channel.
File an issue.
Join weaveworks-ignite@googlegroups.com for calendar invites to calls and edit access to community documents.
Join our developer meetings.

Your feedback is always welcome!

Maintainers

Leigh Capili, @stealthybox
Chanwit Kaewkasi, @chanwit
Sunny, @darkowlzz

License

Apache 2.0

Top Related Projects

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot