改进 tripleoclient 中 ansible 调用记录

Launchpad蓝图

https://blueprints.launchpad.net/tripleo/+spec/ansible-logging-tripleoclient

问题描述

目前,在部署或 day-2 操作(如升级、更新、扩展)期间显示的 ansible playbook 记录要么过于冗长,要么不够详细。

此外,由于我们正在转向 Undercloud 上的临时服务(例如,参见 ephemeral heat),获取有关状态、内容和相关信息变得不太直观。适当的记录,以及相关的 CLI,可以真正改善这种情况并提供更好的用户体验。

解决方案的要求

不增加新服务

我们已经在尝试从 Undercloud 中删除一些东西,例如 Mistral,因此不应该添加新服务。

不增加部署和 day-2 操作的时间

该解决方案不得增加部署、更新、升级、扩展和任何其他 day-2 操作所需的时间。它对操作员来说必须是 100% 透明的。

使用现有工具

就像我们不想拥有新服务一样,我们也不想再次重复造轮子,并且必须检查已经庞大的现有解决方案目录。

KISS

保持简单和愚蠢是关键要素 - 代码必须易于理解和维护。

提议的变更

介绍

在处理 验证框架 时,很大一部分是关于记录。在那里,我们找到了一种获取实际的可计算输出并将其存储在定义的位置的方法,从而可以提供一个友好的界面来列出和显示验证运行。

这严重依赖于带有特定库的 ansible 回调插件,这些库在 python-validations-libs 包中提供。

由于该方法是模块化的,因此这些库可以很容易地在其他项目中重用。

此外,python-tripleoclient 已经依赖于 python-validations-libs(通过对 validations-common 的依赖),这意味着我们已经拥有所需的组件。

这个想法

由于我们已经拥有系统中存在的必要代码(由新的 python-validations-libs 包提供),我们可以修改 ansible-runner 的配置方式,以注入一个回调,并以两种方式获取所需的输出:在 shell 中(直接反馈给操作员)和在专用文件中。

由于回调并不便宜(但希望也不昂贵),因此必须进行适当的 PoC,以收集有关 CPU、RAM 和时间的数据。请参阅性能影响部分。

直接反馈

直接反馈将告诉操作员当前正在执行的任务,以及任务结束时,是成功还是失败。

使用回调可能会提供“适合人类”的输出。

文件记录

在这里,我们必须定义多件事情,并考虑到我们正在运行多个 playbook,并多次调用 ansible-runner。

文件位置

如今,大多数(如果不是全部)与部署相关的文件都位于用户的主目录中(例如,~/overcloud-deploy//)。因此,将日志放在相同的位置或该位置的子目录中似乎是合理的。

保持此位置还可以解决潜在的访问权限问题,因为标准主目录具有 0700 模式,防止其他用户访问其内容。

我们甚至可以更进一步,并强制执行 0600 模式,以确保安全。

请记住,日志可能包含敏感数据,尤其是在使用额外的调试时。

文件格式约定

为了使日志易于自动化工具使用,并且由于我们已经大量依赖 JSON,因此日志输出应格式化为 JSON。这将允许添加一些新的 CLI 命令,例如“history list”、“history show”等。

此外,JSON 被日志服务(如 ElasticSearch)广泛了解,因此将其发送到中央日志服务非常容易和方便。

虽然 JSON 很好,但它很可能会阻止操作员直接读取 - 但如果有一个可用的 CLI,我们可能会得到类似于我们在 验证框架 中所拥有的东西(参见 这个例子)。我们甚至可以考虑一个允许从 JSON 转换为操作员可能需要的任何格式的 CLI,包括但不限于 XML、纯文本或 JUnit(Jenkins)。

应该有一个新的参数允许在“plain”和“json”之间切换格式 - 默认值仍有待讨论,但提供此参数将确保操作员可以对默认格式做任何想做的事情。一种共识似乎表明“默认 plain”。

文件名约定

如前所述,我们正在操作期间运行多个 playbook,并且我们还需要某种历史记录。

为了做到这一点,获得名称的最简单方法是将时间和 playbook 名称连接起来,例如

  • timestamp-playbookname.json

使用 systemd/journald 代替文件

有人可能希望使用 systemd/journald 代替纯文件。虽然这听起来很有吸引力,但存在多个潜在问题

  1. 敏感数据将显示在系统的 journald 中,任何其他用户都可以访问

  2. Journald 有速率限制和阈值,这意味着我们可能会达到这些限制,从而丢失日志,或者阻止其他服务使用 journald 进行自己的记录

  3. 虽然我们可以配置日志服务(rsyslog、syslog-ng 等)以将特定内容输出到特定文件,但我们将面临访问权限问题。

因此,我们不应该使用 journald。

它是否满足要求?

  • 不增加新服务:是 - 它只是 CLI 中的一个更改,不需要新的依赖项(tripleoclient 已经依赖于 validations-common,后者依赖于 validations-libs)

  • 不增加操作时间:这必须通过适当的 PoC 和指标收集/比较来证明。

  • 现有工具:是

  • 积极维护:到目前为止,是 - 预计会扩展到 TripleO 之外

  • KISS:是,基于 validations-libs 和简单的 Ansible 回调

替代方案

ARA

ARA Records Ansible 提供了一些我们在验证框架记录中实现的功能,但它缺少一些想要的功能,例如

  • tripleoclient 中的 CLI 集成

  • 第三方服务独立性

  • 纯文件记录,以便使用 SOSReport 或其他工具来抓取它们

ARA 需要一个 DB 后端 - 我们可以将结果注入到现有的 galera DB 中,但这可能会在部署期间发生并发访问时造成一些问题。使用 sqlite 也是一个选项,但这意味着新的软件包、新的文件位置来保存、二进制格式等等。

它还需要一个 Web 服务器才能显示报告,这意味着另一个 httpd 配置,以及需要在 Undercloud 上访问它的需要。

此外,ARA 作为一个完整的服务,需要部署它、配置它和维护它 - 并且在每次操作之前确保它正在运行,以确保它获得日志。

默认情况下,ARA 不会影响实际的 playbook 输出,而此规范的目标主要是关于它:为操作员提供简洁的反馈,同时将日志保存在磁盘上,以文件形式保存,并能够通过 CLI 直接与它们交互。

最终,ARA 可能是一个解决方案,但它需要更多的工作才能集成,并且由于 Triple UI 已被弃用,因此没有实际方法将其集成到现有的 UI 工具中。

它是否满足要求?

  • 不增加新服务:否,由于“REST API”方面。必须有一个服务来响应 API 调用

  • 不增加操作时间:可能,取决于 ARA 如何管理输入队列。由于它也使用回调,因此我们必须考虑它可能使用的资源。

  • 现有工具:是

  • 积极维护:是

  • KISS:是,但它增加了新的依赖项(DB 后端、Web 服务器、ARA 服务等)

关于“新依赖项”的说明:虽然 ARA 可以在 没有服务的情况下 启动,但根据文档页面上可以阅读到的信息说明,这似乎仅用于开发目的。

Good for small scale usage but inefficient and contains a lot of small files
at a large scale.

因此,我们不应该使用 ARA。

建议路线图

在 Xena 中

  • 确保我们在 validations-libs 中拥有所有 ABI 功能,以便设置所需的/想要的参数以进行不同的日志位置和文件命名

  • 开始使用 ansible-runner 调用,以便使用 validations-libs 功能调整回调,以获取直接反馈以及正确位置的格式化文件

安全影响

由于我们将把完整的 ansible 输出存储在磁盘上,因此我们必须确保日志位置访问权限对任何不想要的用户的访问权限已关闭。如前所述,目录模式和所有权必须设置为只有需要的用户才能访问其内容(root + stack 用户)

一旦解决了这个问题,就不应再有其他安全影响 - 进一步来说,它甚至会比现在更安全,因为 tripleoclient 中 ansible 的当前启动方式会将“ansible.log”文件放在操作员的主目录中,而没有任何特定的权限。

升级影响

除了确保日志位置存在之外,没有其他重大升级影响。必须更新文档以指向日志位置,以及 CLI 中的一些消息。

最终用户影响

对最终用户有两个影响

  • CLI 输出将被重做,以便提供有用的信息(参见直接反馈)

  • 日志位置会稍微更改 ansible 部分(参见文件记录)

性能影响

预计影响有限 - 但必须进行适当的 PoC 和指标收集,以评估实际更改。

必须进行多次部署,使用不同的 Overcloud 设计,以查看实际影响以及节点数量。

部署者影响

与最终用户影响相同:CLI 输出将更改,日志位置将更新。

开发人员影响

默认情况下启用回调,但开发人员可能希望禁用它。文档应反映这一点。最终没有实际影响。

实现

贡献者

  • Cédric Jeanneret

  • Mathieu Bultel

工作项

  • 修改 validations-libs 以提供所需的接口(不应该真正需要,这些库已经模块化并且应该公开所需的接口和参数)

  • 在 tripleo-ansible 中创建一个新的回调

  • 确保使用正确的权限创建日志目录

  • 更新 ansible-runner 调用以默认启用回调

  • 确保 tripleoclient 在将日志写入正确位置时定期输出状态更新

  • 更新/创建有关新的日志位置和管理的信息文档