亚马逊AWS官方博客
Firecracker 开源更新 – 2019 年 5 月
距离我们在 re:Invent 大会上推出 Firecracker 已经有六个月了，我们非常荣幸受到了开源社区的热情欢迎。在这六个月里，我们已经将来自 30 多位外部贡献者的 87 篇提交内容合并到 Firecracker 主分支（约占在该时间段内所有提交内容的 24%）。这些贡献领域涵盖范围极广，包括设备模型半虚拟化规范的合规性、不需要 1 GiB 大页内存的情况下支持 CPU 和内存模型改进，以及文档、API 规范、测试和错误修复方面的改进。另外，开源用户提交了十几个错误报告，我们也收到了一些 RFC 的社区反馈。GitHub 上的 Firecracker 存储库现在有 450 多个 GitHub 分支，Firecracker Slack 上的用户有 900 多人。我们也很高兴地看到，有许多其他致力于开发容器/无服务器计算空间的开源团队已经在他们的项目中集成了 Firecracker，其中包括 Kata Containers、UniK 和 OSv。另外，Intel 在最近推出的“Cloud Hypervisor”中利用了 rust-vmm、Firecracker 和 crosvm 的代码。
在本篇博文中，我们将报告 Firecracker 存储库目前的情形，以及我们为接下来几个月规划的里程碑，最重要的是，获取您对未来规划项目的见解。
目前的工作
2019 年至今，我们所开展的工作涉及的领域包括纵深防御、易用性、AMD 和 Arm CPU 支持以及 vsock。为了在高密度、多租户的情况下改进隔离效果，我们增加了动态调整速率限制器的选项，增加了用于衡量访客欺骗 MAC 地址的指标，并将 Firecracker 默认设置为最严格的安全计算模式级别。为使用 Firecracker 的工程师提供了诸多实用改进，具体方面包括 API 文档、更多开发工具以及错误/崩溃信息更清晰。随着 Firecracker 0.16.0 的推出，我们发布了 alpha AMD 支持（我们仍然需要启动并运行自动化测试），ARM 也进展顺利。我们还花时间考虑了在 Firecracker 中支持 vsock 的正确方法（我们收到了来自开源社区的大量反馈，在此表示感谢！），现在正在进行实现。
2019 年展望
继续提高 Firecracker 的安全性，我们希望将模糊测试应用于设备模型，并在特定的使用案例中支持块设备加密作为额外的隔离层。我们将继续对我们的持续集成系统进行迭代，使测试运行更加细化，使添加新平台更加容易，并提高生成测试报告的清晰度。我们还想知道 GitHub 版本（包括代码和二进制文件）是否适合现有使用者。我们是否应该维护像 Snap 包这样的项目？ 我们是否还应该关注其他软件分发形式？
接下来，我们要找到支持推理加速的办法。虽然 GPU 直通和超订无服务器计算工作负载在技术上不能很好地混合在一起，但是在函数或基于容器的微服务中加速推理计算似乎是一个很自然的使用案例。我们很乐意听到您对这方面的反馈意见。
最后，正如我们希望有一天成为版本控制革命先锋一样，一旦我们实现了 AMD 和 Arm CPU 支持、vsock 和 CI，并确定了 API 稳定的方法，我们将宣布推出 Firecracker v1。
您的想法和使用案例！
90-95% 的 AWS 路线图由客户驱动。我们目前正在制定 2020 年规划，因此我们渴望获得开源社区中每个人的提议。因此，请将您的想法、请求和使用案例添加到此 2020 年路线图 RFC，告诉我们您希望 Firecracker 实现的功能。当然，我们已经考虑到了现有功能请求，但我们还是很欢迎您提出更多建议！ 我们鼓励每个人大胆想象，同时我们会确保最终的路线图符合我们的使命，即保障容器和函数工作负载的安全、多租户和最小开销。
下一篇博文
我们会推出更多与本博文类似的博文，敬请关注。我们的下一篇博文将讨论我们的原则，探讨 rust-vmm 与 Firecracker 未来的关系，并提出我们为 2020 年设定的路线图。