Ceph Calamari 开源

scuttlemonkey

今天，Red Hat 将兑现收购承诺中的一项我最喜欢的承诺：我们将开源 Calamari，Ceph 的管理平台。Calamari 最初作为 Inktank Ceph Enterprise 随附的专有仪表板提供，它为您的集群提供了非常棒的可视化功能，并且长期目标是成为一个可以配置和分析 Ceph 集群的万能管理系统。我们很高兴能够与社区分享这项工作，并增加不同团队致力于 Ceph 管理 GUI 的优势。现在，让我们进入细节！

[caption width="800" align="alignnone"] 图片来源：Flickr[/caption]

Calamari 由什么组成？

Calamari 由两个部分组成（现在 Ceph Github 项目中的两个独立仓库）

  1. 后端 -- Calamari 后端使用 Python 2.6+ 编写，使用 Saltstack、ZeroRPC、gevent、Django、django-rest-framework、graphite（以及我可能忘记的几个其他组件），并实例化一个新的 REST API，用于与其他系统的集成。这是一个重要的区别，因为 Calamari 的早期版本是基于 Ceph REST API 的。新的 Calamari REST API 旨在更加全面，并且应该成为希望与 Ceph 集群交互的新开发工作的基础。

  2. 前端 -- Calamari 前端是一个 Web 浏览器 UI，主要使用 Javascript 实现，它使用 Calamari REST API。

运行 Calamari 相对简单，可以通过遵循源代码中的 README.rst 来完成。基本思想是在您的集群机器上运行一个代理，收集数据，然后由主 Web 代理定期轮询。我们认为它非常出色。

许可

关于许可，我们决定对前端使用 MIT 许可证，对后端工作使用 LGPL2+ 许可证。我们真正想要的是尽可能接近 Ceph 许可证的意图，同时与各自的开发社区保持一致（MIT 适用于 javascript UI 代码），同时仍然允许引用专有代码的插件。人们可能会以多种方式将这项仪表板工作集成到其他现有的管理工具和监控套件中，因此我们不想限制社区可能想要做的任何集成工作。我们希望许可部分保持相对轻量级，以便社区可以专注于制作一个很棒的 GUI 并使用它来创建出色的集群。

这对现有的 Inktank Ceph Enterprise 客户意味着什么？

最终，这并没有太大变化，除了您现在将拥有一个管理界面，它受益于更多开发人员的工作（以及测试）。Calamari 产品作为 Inktank Ceph Enterprise 的上游组件开发，就像 Ceph 本身一样。商业 Inktank 产品仍然将提供经过认证和支持的二进制文件。

如何开始参与 Calamari 的开发？

我们推进这项工作的原因是，我们希望尽快将其交付到我们的社区手中。因此，您可以像参与 Ceph 代码库的其余部分一样立即开始开发。下面我包含了一个简短的常见问题解答和 John Spray（Inktank Calamari 开发人员之一）提供的一些贡献指南，这些指南应该可以回答您的一些问题，但您始终可以在 IRC、邮件列表（请注意新的 ceph-calamari 列表）或在我们的 wiki 上作为 开发蓝图提出讨论。

有关 Calamari 和 Inktank Ceph Enterprise 的“大图景”想法的更多详细信息，请查看 Neil Levine 在 inktank.com 上的 博客文章。如果您仍然有疑问，可以随时直接联系我 (@scuttlemonkey 或 patrick at inktank)。我期待我们新的 GUI 开发人员大军！

scuttlemonkey 结束

常见问题解答

问 Calamari 和 ceph-deploy 之间的关系是什么？ 答 Calamari 不包含部署功能，但我们预计从长远来看，Calamari 将拥有部署工具的钩子，包括 ceph-deploy 以及 Puppet、Chef、Juju 等其他工具。

问 Calamari 的 REST API 与 Ceph REST API 之间的关系是什么？ 答 Ceph REST API 是一个低级接口，其中每个 URL 直接映射到与 `ceph` CLI 工具等效的命令。Calamari REST API 提供了一个更高级的接口，API 消费者可以使用惯用的 GET/POST/PATCH 操作来操作对象，而无需了解底层的 Ceph 命令。Calamari REST API 还包含与管理服务器以及纯 Ceph 功能相关的函数。它们之间的主要区别是，Ceph REST API 需要对 Ceph 内部结构有深入的了解，而 Calamari REST API 会生成解释后的数据，并设计用于在其之上构建许多应用程序。

问 如果我不是 UI 开发人员，我仍然可以参与 Calamari 的开发吗？ 答 当然：我们欢迎在后端实现功能或提出如何扩展 API 的建议，以便稍后在 UI 中公开。即使您无法使用代码实现，我们也欢迎 UX/UI 方面的帮助，例如图形设计。

问 为什么使用 SaltStack 而不是 [Ansible|Chef|Puppet]？ 答 Saltstack 被选择是因为它易于与 python 应用程序集成，并且具有安全、轻量级的消息总线。

问 Calamari 服务器的系统要求是什么？ 答 这取决于正在管理的 Ceph 集群的大小。Calamari 服务器旨在非常节约地使用系统资源，尤其是 I/O。Calamari 服务器上的主要 I/O 消耗者通常是 graphite，而不是 Calamari 本身。

问 我可以使用 Calamari 后端将 Ceph 与我自己的用户界面集成吗？ 答 是的：这是 Calamari REST API 的主要目标之一。

问 我应该如何发送 Calamari 的补丁？ 答 请使用 github pull requests，遵循与 ceph 相同的提交消息指南

贡献指南

  • 通过 REST API 清晰地公开功能：使用适当的 HTTP 动词和 JSON 文档语法，包括适当的 400/304 响应代码验证。
  • 远程且可能长时间运行的操作实现为 UserRequest 子类，而不是直接从 REST API 处理程序调用。
  • 避免对不需要持久性的内容进行持久化，并异步进行持久化。我们希望避免操作因数据库 I/O 而阻塞，而这些操作可以立即返回并在后台持久化，并且我们不想将大量监控数据写入数据库，只是为了让 REST API 代码轮询它：将当前状态保存在内存中，并通过 ZeroRPC 将其暴露给 REST API 层。
  • 设计您的代码以优雅地处理数千个 OSD 和数百万个 PG。例如，我们不会通过 Calamari 服务器传递完整的 PG 数据，而是将其减少为在从 mon 收集时进行的摘要。
  • 从 REST API 层直接调用外部世界，如果这有意义的话：例如，当我们获取日志的末尾、读取 graphite 统计信息或管理 Salt 身份验证密钥时，这些操作将直接从 REST API 到相关的外部参与者进行，而没有中间的 ZeroRPC 跳跃。
  • 不要害怕创建新的服务（后端上的进程，公开 ZeroRPC 接口）：如果您正在实现一项重要的新功能，则可能适合在后端创建一个新服务来处理它。请记住，多个服务可以订阅来自 salt 的相同消息，并且 REST API 层可以调用尽可能多的不同的 ZeroRPC 接口来满足请求。创建服务很容易，因为您可以将其添加到 supervisord 配置中：无需进行打包更改。
  • 遵循 doc/development/coding_style.rst 中的编码指南
  • 运行测试（至少是单元测试）后再发送 pull request。
  • 为您的新功能编写测试：隔离功能的单元测试，例如 REST API 验证或辅助函数，以及端到端功能的集成测试（即顶级测试/）。