软件初创公司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
评论