软件初创公司Weaveworks发布了开源项目Weave Ignite以庆祝成立五周年。该项目被称为“带有容器UX、受GitOps管理的虚拟机（VM）”。这个新颖的软件使用了Firecracker，Firecracker是支持AWS Lambda的AWS开源项目。InfoQ采访了项目背后的团队以了解更多信息。

在一篇关于Weave Ignite的博文中，Weaveworks的CEO Alexis Richardson解释了其工作原理。

通过吸收开发人员来自于容器的经验，Ignite使Firecracker变得易于使用。借助Ignite，我们可以选择希望作为VM运行、符合OCI标准的镜像（Docker镜像），然后，执行ignite run而不是docker run。无需使用特定于VM的工具来构建.vdi、.vmdk或.qcow2镜像，只需从任何我们所需的基础镜像进行docker构建，并添加我们偏爱的内容。

当我们利用ignite run来运行OCI镜像时，Firecracker使用默认的4.19 Linux内核，在c.125微秒启动一个新的VM 。

Richardson提出了一些用例，包括为测试或临时工作负载快速启动很多VM、同时启动完整堆栈和在轻量级VM中运行遗留应用程序。

亚马逊于去年11月发布了开源虚拟化技术Firecracker。记者Matt Asay对此评论道，Weaveworks在此以Ignite为例，展示了开源在理想情况下应该怎样做。

尽管该技术本身看起来超级酷，但是，其中还有一些非常棒的东西AWS并没有做。他们构建了Firecracker并把它开源，以便像@weaveworks的其他开发人员可以以此为基础构建自己的东西。开源实际上就是这么干的。

为了证明Weave Ignite可以用在任何地方，Walmart Labs的一位工程师写了一篇博文来演示如何让Ignite在谷歌云上工作。

为了了解更多关于Weave Ignite的细节，InfoQ联系了Weaveworks并采访了CEO Alexis Richardson和Ignite的创建者 Lucas Käldström。

InfoQ：Ignite是否创建了一个“真正的”VM，可以存储持久状态、托管它自己的容器等等？这个和用传统的虚拟机管理程序创建的VM看起来不一样吗？

Weaveworks：是的，Ignite创建了一个真正的VM。但是，和“传统的”VM略有不同，比如：

Firecracker是故意设计成的一个最小的KVM实现

我们使用来自OCI镜像（容器行业标准）的根文件系统，而不是使用像“.iso”文件这样的“可引导”磁盘以及像Packer这样的支持工具，它们产生特定于供应商的“.vdi”、“.vmdk”文件。

Ignite支持声明性配置，并通过GitOps运维

除此之外，请查看我们的FAQ.md

InfoQ：能否给不熟悉Firecracker的人做个介绍？

Weaveworks：Firecracker是Linux的最小虚拟化实现（使用KVM）。

Firecracker是为无服务器工作负载的新时代而打造，因此，它的设计针对安全和速度进行了优化。换句话说，Firecracker在给定Linux内核和硬盘的情况下启动并监控VM 。

来自https://firecracker-microvm.github.io/: Firecracker实现了虚拟机监控器（VMM），利用基于Linux内核的虚拟机（Kernel-based Virtual Machine，简称KVM）来创建和管理微虚拟机（microVM）。Firecracker采用简约设计。它不包含不必要的设备和游客功能，以减少每个微VM的内存占用和攻击范围。这可以提高安全性，缩短启动时间并提高硬件利用率。

InfoQ：如何吸收“容器开发人员经验”使Ignite比原始的Firecracker更容易使用？

Weaveworks：Ignite与Firecracker的关系，就像Docker跟OCI容器运行时实现的runC的关系一样。

与runC一样，Firecracker旨在作为低级组件。今天，如果我们运行一个容器，我们不会直接使用runC，而是使用更高级的工具，如Docker、containerd 或者Kubernetes。同样，除非我们是Linux内核或KVM开发人员，我们很可能难以找到如何有效正确使用Firecracker的方法。通过从容器中获得DX，并和像Docker和OCI镜像规范集成，Ignite给用户提供了运行VM就像运行容器一样的体验，这比要求用户创建虚拟块设备和以太网接口要简单几个数量级。

InfoQ：需要哪些组件才可以在我们的机器上使用Ignite？

Weaveworks：基本上Linux上的Docker即可，请参看说明。

具体来说：首先，在启用KVM的情况下运行Linux。这是基本要求，因为Firecracker是设计实现了KVM，只有Linux有这个功能。其次，安装一个容器运行时，用于和Ignite集成，像Docker（目前唯一支持的运行时，更多的会很快实现）。下载Ignite二进制文件。就这些！

InfoQ：GitOps是基础设施即代码的进化吗？您能否告诉我们一点关于GitOps是什么的知识吗？

Weaveworks：GitOps是一种自动化Kubernetes集群管理和应用程序交付的方法。很多人理解并使用一些GitOps概念，但是，很少有人能完全发挥它的作用。我们能对运营做到最深刻的改进就是完全意识到它。

在GitOps，我们通过不断观察运行时状态并用期望的状态（作为声明配置存储的）与之比较来管理整个实时系统。如果观察到的状态偏离了期望的状态，那么，我们使用如Kubernetes、Flux和Flagger的协调器把系统收敛回正确的状态，并且如果我们无法收敛，那么就发出警报。因此，我们可以直接从配置中配置和管理集群和应用程序，并且，根据策略，可以100%地自动进行配置和管理。借助Weave Ignite，现在我们也有了第一个可以从配置进行管理的VM技术，就跟Kubernetes一样。

Weave产品使用GitOps以创建集群，进行上下扩展、升级和修补，还管理一些D/R。我们可以做集群的自动化、管理大量集群、模板和配置。其次，我们可以用自动化的持续应用程序部署来替换部署脚本。我们可以执行渐进式交付，如金丝雀发布、带功能开头的A/B测试，以及控制策略。所有这些都适用任何CI工具、镜像注册表和Git存储库。

是的，GitOps是DevOps和IaC的进化，但是有重要的改进。有哪些改变？GitOps无疑把基于配置的管理最初设想发挥到了极致：

我们管理整个运行软件栈，包括应用程序、服务、网格、金丝雀发布，……和盒子，而不是供应已安装软件的“盒子”。

我们部署不可变容器和配置文件。CI和Dev从不直接触及运行时，它们通过不变性防火墙进行。

我们不断地检查系统是否偏移。我们有一个完整的描述来进行比较。

所有对运行系统的改变，无论有多么细小，都是由配置更改驱动的。

相反，我们不使用多个接口，即kubectl、ssh、UIs、CLIs或者像OpenShift这样的外观聚合。

GitOps必须使用Git+编排，不能是Git+CI脚本。我们不把CI脚本用于CD，因为这些会让我们处于不确定状态。我们手动或用基于CI的变化更新Git，但是，我们不让CI协调部署，因为只有Kubernetes和其他运行时协调器可以强制实现收敛性和原子性。

我们还用这种方式管理渐进式交付和功能开关，请点击这里参看YAML。

整个环境包括：非程序化的资源，即playbooks和控制面板。当我们更新应用程序时，也希望在单一版本控制机制下更新监控、警报和运维文档。

但是，我们不希望开发人员编写配置文件，我们使用高级编程语言（如Typescript）从代码安全地生成YAML，并为集群、管道和基于策略的运维行动管理模板。与基于CI的脚本模式不同，这个可以扩展。

InfoQ：您是否需要向Firecracker项目提交任何上游更改以让Ignite工作？

Weaveworks：不，不需要：）

InfoQ：您提出一些可能的用例，包括Weaveworks如何将其用于自己的集群管理产品。哪个开发人员用例对你最有吸引力？

Weavework：要选一个的话，是测试。想象一下，我们是否可以以零成本为k8s集群启动测试、CI和其他版本的开发。也就是说，在Ignite上快速启动安全的Kubernetes集群，让一些案例变得简单。可以参看我们的入门博文。我们只需要运行几次“ignite run”，然后在那些机器上用我们首选的Kubernetes安装程序安装Kubernetes，例如事实上的社区构建工具kubeadm（Weaveworks从一开始就一直以开源的方式开发它），还有供企业使用的Weaveworks Kubernetes平台。最终：整个GitOps数据中心能够使用现代云原生工具在任何地方运行。

原文链接：

Weaveworks Releases Ignite, AWS Firecracker-Powered Software for Running Containers as VMs

创作场景

InfoQ 专访 Weaveworks 项目团队：开源在理想情况下应该怎样做