重构 OSA 库存

日期:

2018-04-12 22:00

标签:

osa, inventory

当前的库存随着复杂性的增长，自 icehouse 首次实现以来，仅有机地增长。鉴于 Ansible 已经发生了很大变化，并且添加了早期版本中不可用的功能，现在是时候退一步，看看如何重新设计它以减少技术债务并使其更易于维护。

问题描述

当前的 OpenStack-Ansible 库存提供以下功能

  • 将主机分配到组

  • 生成组结构

  • 分配主机变量

  • 生成容器 inventory_hostnames

  • 基于 cidr_networks、保留 IP 和已分配 IP 分配和跟踪容器 IP。

所有这些功能都包含在一个单独的动态库存脚本中，因为在创建时，ansible cli 调用中一次只允许一个库存。

OSA 提供的动态库存是 OpenStack-Ansible 功能的核心，但核心维护者和新贡献者都不太了解它。

因此，库存在代码和内存使用方面（部署方式的变化、添加新组、添加边缘情况）都得到了有机增长，并且没有进行太多维护来减少其范围或技术债务。

目前，由于缺乏测试和代码的复杂性，在不造成隐藏破坏的情况下很难进行操作，而这些破坏通常几个月后才会被发现。对这段遗留代码添加测试是不现实的。

因此，问题可以总结为以下几点

  • 库存需要清除不必要的组和分配，但很难有效地清除，而不造成隐藏破坏。

  • 我们必须在 openstack-ansible 中保留未积极维护的代码

  • 我们必须执行未积极审计的代码，而从技术上讲，可以避免执行代码，对最终用户几乎没有限制。

  • 在 Newton、Ocata 和 Pike 开发周期中尝试了验证回归的测试 - 但这并没有增加代码的复杂性，也没有提高可靠性。

提议的变更

现在我们使用的是 Ansible 2.4，我们可以

  • 堆叠库存，因此，如果需要，我们可以将库存拆分为较小的库存

  • 导入和转换库存为更易读的格式。

我建议使用静态文件来存储库存。这样人们更容易编辑和审查库存。它更容易操作，并且不需要我们的代码来运行或编辑它。

主机变量、组变量和库存结构将是静态文件，并简化到最低限度。

以下是简化（主机变量和库存）的两个示例

  • 对我来说，跟踪正确的 IP 分配是 CMDB/IPAM 的范围。我们不应该在那里重新发明轮子。相反，应该将它从库存中分离出来。人们应该

    • 使用旧库存以保持相同的功能，但我们添加了一个警告，说明该代码已被弃用

    • 在静态文件中提供他们自己的 IP 地址

    • 提供他们自己的动态库存脚本或使用查找来从他们的 IPAM 获取数据。

    通过将 IP 的生成范围排除在库存之外，我们可以进一步简化动态库存。

  • 对我来说，像 haproxy、haproxy_all、haproxy_hosts 或 haproxy_containers 这样的组都令人困惑。有些组可以互换使用，这导致了错误。组的激增仅仅是由于我们的库存造成的。这些都可以通过更改 playbook 和 role 合并到一个组中。这不仅限于 haproxy，这种组减少模式应该扩展到我们所有的库存。

因此，首先我们需要保持相同的配置样式 (conf.d/env.d/openstack_user_config)。生成的 json 将通过脚本生成和清理静态文件。

该脚本将是部署和升级过程的一部分。

稍后，我们可以重新思考 conf.d/env.d/openstack_user_config，或者保持不变但完全更改底层的代码。这不会有问题，因为可以在侧面完成，作为不同的库存系统。在此过程中，我们将记录库存的输入和输出，然后可以用于构建测试用例。

备选方案

无需操作

Playbook/Role 影响

删除对旧库存数据的引用，例如旧组。更好地使用查找或 ansible_facts 来减少主机变量的数量。

升级影响

因为我们的库存状态已经很糟糕，所以我们已经在错误的组中拥有主机。

升级需要运行该工具将组迁移到 playbook 中呈现的新组。

安全影响

最终运送更少的代码，我们将略微提高我们的安全性。

性能影响

  • 从动态文件到静态文件，格式相同，不会改变性能

  • 从静态 json 到静态 yaml 可能会或可能不会通过减少内存使用来提高部署性能。这完全取决于库存。大型库存更有可能通过切换到 yaml 来降低相同的输入性能。

  • 清理库存对性能有积极影响。

最终用户影响

最终用户不会注意到任何变化。

部署者影响

部署者将拥有不同的用户配置来处理（静态文件）

希望对于现有的 openstack-ansible 用户或经验丰富的 ansible 用户来说，这并不难理解。

开发人员影响

对 role 或 playbook 的开发没有变化。

与此同时，我们正在消除技术债务，同时通过添加这些新工具增加新的技术债务。

希望这些工具更容易理解、阅读、审查并拥有更多的测试，这将总体上降低项目的风险。

依赖项

无

实现

负责人

主要负责人

evrardjp

其他贡献者

目前没有。

工作项

使用静态文件并非没有缺点：如果我们“只是使用”由用户创建的静态库存，我们将失去一些关键功能，例如动态主机名生成、动态 IP 分配。

因此，我提出以下路径

  1. 我们列出成功 ansible 部署所需的组，并在参考指南中记录这些组。

    积极的改进

    • 对于不想使用我们库存的部署者，我们现在将拥有一个“明确”的合同，说明他们应该如何使用自己的库存组来运行 openstack-ansible

    缺点

    • 所有组的变化都需要适当的文档记录

    • 这不足以使用你自己的库存

  2. 现在保留 conf.d/env.d 和动态库存脚本。我们使用它来生成一个在云的生命周期内保持静态的 json，或者直到手动重新生成。env.d/conf.d/openstack_user_config.yml 用作此“一次性”运行动态库存的输入。

    为了确保部署者不会误解“静态”json 文件或将其与当前的 openstack_inventory.json 混淆，我们应该将当前文件移动到“缓存”文件夹，并将“静态”库存生成到 inventory 文件夹中。

    积极的改进

    • 没有隐藏的故障，库存的生成成为部署的一部分。我们可以轻松添加健康检查。

    • 我们的代码只运行一次，在生成期间。因此，我们不会受到同时运行多个 ansible 或其他副作用的问题影响。

    • 我们免费保留容器名称生成、提供程序网络和 IP 分配。

    缺点

    • 编辑静态文件将与 conf.d/env.d 不同步，但这已经发生在手动更改 openstack_inventory.json 时。

    • inventory_manage 脚本变得无用

  3. 我们提供默认子映射：我们在 openstack-ansible repo 中创建一个易于阅读的 .ini 文件来创建 x_all 组。

    积极的改进

    • 我们所有的用户都拥有自己的库存，不必创建完全相同的代码来执行子组映射。分享是关怀。

    • 我们可能会携带很多空组，也许人们不需要它们。

    • 该映射可以用来部分替代步骤 1 的文档，并在 playbook 和 role 中清理组后完全替代步骤 1 的文档。

  4. 我们将主机变量导出到用户空间库存文件夹中的静态文件。

    积极的改进

    • 拥有静态 yaml 文件可以轻松查看重复项以及可以移动到组变量的内容

    缺点

    • 部署者需要维护更多的静态文件。如果我们更改主机变量，我们可以更改库存，它将应用到所有地方。不再这样了。

  5. 我们编写一个工具来操作库存 json。默认情况下，该工具将

    • 丢弃参考指南中未列出的所有组

    • 丢弃 json 中不再需要的 _all 组，因为它们将不再需要（在之前的步骤中处理）

    • 丢弃所有主机变量（在之前的步骤中处理）

    • 丢弃可以从事实/主机变量生成的组，例如 all_containers（使用 group_by 可以提供相同的结果）。

    积极的改进

    • 库存将更轻，因此需要更少的内存来运行。它也会运行得更快，需要更少的计算能力。

    缺点

    • 所有组的变化都需要修改该工具，因此需要良好的设计才能使其易于更改。

  6. 我们记录预期的和必需的主机/组变量列表。

  7. 我们使用/提供一个操作变量文件（yaml）的工具，或通过发布说明来删除库存中不再重要的所有不必要的组和主机变量。

  8. 我们记录如何将清理后的库存导出到新的 YAML 文件。

  9. 此时，生成 conf.d、env.d 和 openstack_user_config 变得完全可选：我们知道构建中需要什么，并要求部署者提供他们自己的组/主机映射。

    此时是可选的，因为

    1. 主机分配到组可以通过用户使用简单的 .ini/.yaml 文件 + 文档完成

    2. 标准组结构默认提供

    3. 我们记录了主机变量列表，因此用户可以提供它们

    4. 使用 inventory_hostnames 生成容器可以通过用户完成。它只是一个系列的主机变量：ansible_host、container_name、container_tech、physical_host。它甚至可以使用 add_hosts 和基于新变量（例如 container_names，主机的属性）的循环来完成。

    5. 基于 cidr_networks、保留 IP 和已分配 IP 分配和跟踪容器 IP 也是主机变量。部署者负责为他们的容器提供 IP。例如，lxc_container_create role 基于 lxc_container_networks_combined 创建 IP、网络和接口配置，该变量通过组合默认 lxc_container_networks 与库存的一部分“container_networks”变量来获取库存中的信息。注意：这部分以后可以通过查找来替换。通过使用查找，我们可以简化库存，完全删除其容器网络的主机变量。

  10. 我们提供一个脚本来运行所有这些操作，但也允许逐步编辑和操作。

  11. 我们提供一个新工具来基于我们从用户那里学到的知识生成一种新型库存，它不一定使用 openstack_user_config、conf.d 或 env.d。但我们有足够的时间来更好地完成它，因为预期的库存与我们过去所做的库存不同。

  12. 我们推出旧库存。

测试

所有工作项将在集成网关中分别进行测试。

文档影响

大型。库存需要进行重构，以解释为使用他们自己的库存的人和将使用我们的生成工具的人的期望。在最后一步，如果提供了另一个工具，它也需要记录。

每个步骤都需要修改参考和可能的操作指南。

参考资料

无