It’s only been a little over a month since Weave Ignite was announced to the world (others have talked about it as well - Techrepublic, TheNewStack, Kubernauts.io, TGI Kubernetes). Since then, the Ignite team has been on fire! Here’s an update on what’s been happening.
If you’re new to Weave Ignite, it’s an open source VM manager with a container UX and built-in GitOps management (check out the docs). It’s built on top of Firecracker which has proven to be able to run 4000 micro-VMs on the same host. Time to give it a go, right?
Since the initial announcement, 45 people contributed to the project on Github, 20 got commits merged in the repo. Thanks to every one of you:
@BenTheElder, @DieterReuter, @PatrickLang, @Strum355, @akshaychhajed, @alex-leonhardt, @alexeldeib, @alexellis, @andrelop, @andrewrynhard, @aojea, @arun-gupta, @asaintsever, @chanwit, @curx, @danielcb, @dholbach, @hbokh, @jiangpengcheng, @junaid18183, @karanparhar, @kim3z, @kobayashi, @liwei, @luxas, @najeal, @neith00, @paavan98pm, @patrobinson, @pditommaso, @praseodym, @prologic, @robertojrojas, @rugwirobaker, @saiyam1814, @seeekr, @sftim, @silenceshell, @srinathgs, @stealthybox, @taqtiqa-mark, @twelho, @tyhal, @vielmetti, @webwurst
Since then the team have got six releases out the door. Let’s go through the big changes one by one and why they matter:
- containerd is now the default runtime! This means that Ignite no longer depends on docker being present in the environment.
- Integrating with and using a container runtime is key to Ignite, which aims to connect and seamlessly collaborate with the container ecosystem.
- Using containerd however, we have a much smaller codebase which features higher performance, security, and extensibility.
- CNI becoming the default networking plugin; for greater extensibility and more capabilities.
- You can use e.g. Weave Net as the CNI implementation, or use the default, local bridge setup automatically.
- Support for Persistent Storage, ARM64, manifest directories, the improved v1alpha2 API, both declarative and imperative VM management.
- Read-write GitOps support, now status updates/changes (e.g. IP addresses) are pushed back to the repository.
- ignited was introduced to move Ignite towards a client-server model and improve VM lifecycle management.
- The Docker-like UX has been further improved, now also featuring ‘ignite exec’.
- More pre-built VM images (currently there are images based on Ubuntu, CentOS, Amazon Linux, Alpine and OpenSUSE + a kubeadm image).
- Lots of bug fixes, enhanced stability, more tests and better docs.
It’s impressive how such a young project got all of this together in such a short amount of time.
We also started a mailing list and regular community Ignite developer meetings. These happen Mondays at 15:00 UTC (what’s UTC?) and are meant to get people together who are generally interested in Ignite and want to learn more and potentially help out as well. Project maintainers Lucas Käldström and Dennis Marttinen are always very approachable, but here especially they made a point of introducing everyone to the goals behind Ignite, its roadmap and the current ongoing work.
Here’s what we covered so far:
- 1st meeting:
- Team introductions
- Demo of Ignite
- Roadmap overview
- Current work-in-progress
- 2nd meeting:
- What’s coming in v0.5.0?
- Roadmap for v0.6.0
- Integration with Kubernetes through Virtual Kubelet
- How to contribute to Ignite
- 3rd meeting:
- v0.5.0 and v0.5.1 released
- GitOps Toolkit is being split out - what is it for?
- Footloose integration - what is it about?
- Coming up: containerd support
- Discussion of application logging
- 4th meeting:
- containerd integration
- CNI integration
- The GitOps Toolkit
- Releasing v0.6.0
We are very excited to see the direction Ignite is taking, particularly because it contributes a lot to the ecosystem. How?
We realised that all of the GitOps functionality of Ignite would be useful to the rest of the world, so we split it out into the GitOps Toolkit. This will help you make any app “git-backed” - it’s a generic framework built upon
The team also built the new containerd integration, so that you don’t need Docker installed to run Ignite VMs. Why does Ignite require a container runtime to be present? Because Ignite integrates with the container world, so you can seamlessly run both VMs and containers next to each other. containerd is super lightweight, as is Firecracker, so pairing them with Ignite makes a lot of sense!
If the above sounds exciting to you and your project, please share the news and meet up with us on Monday. We look forward to seeing you there!
But that’s not all. This is just where we felt Ignite could make a difference. If you have your own ideas, own use-cases, issues or challenges, please let us know and become part of the team - even if it’s just by giving us feedback! If you’d like to get inspiration about what others are doing with Ignite, or add your own project, check out the awesome-ignite page.
If you are interested in helping out, that’s fantastic! The meeting should be interesting for you too. If you can’t wait, check out our contributors guide and check out our open issues too. If you are interested in writing docs, adding comments, testing, filing issues or getting your feet into the project, we’re all there and happy to help.
We’ll have more news on Ignite soon. But for today’s update we are signing off with a bitter-sweet announcement: Lucas and Dennis will now, from September, step down as project maintainers in order to embark on a new adventure: Aalto University in Helsinki! They have started something very remarkable and we could not be happier for them. Watch this space for more news.
If you’d like to join the journey, you can do so here: