关于 hashi_vault 查找
此页面解释了 hashi_vault 查找插件的过去、现在和未来。
hashi_vault 查找是 Ansible 中最古老的 Vault 相关内容。它包含在 pre-collections Ansible（<2.10）中。因此，它是使用最广泛的 Vault 插件，也是大多数人最熟悉的插件。
目前，我们建议使用集合中较新的内容，并且我们相信 hashi_vault 的所有用例都已被较新的插件覆盖。要了解历史，请继续阅读本文档。如需迁移方面的帮助，hashi_vault 迁移指南 可为您提供帮助。
概要
简短的总结是
hashi_vault查找执行多项工作，并使用了一些我们希望更改但根深蒂固的模式。community.hashi_vault集合正在开发和发布新的插件和模块，这些插件和模块具有更紧密的范围，并且将为hashi_vault查找已使用的许多用例提供单独的覆盖。目前，没有计划弃用
hashi_vault查找，但它也不太可能接收到特定于该查找的新功能（会自动包含新身份验证方法等共享代码的改进）。随着集合中发布更多插件，我们将在此页面上添加具体的迁移指南以及示例。
长篇故事
hashi_vault 查找注意事项
由于 hashi_vault 查找插件的历史，它执行多项工作。它功能多样，但有时不直观。
hashi_vault 查找插件执行三个主要任务
身份验证，获取各种登录类型的参数，执行登录，并获取可用于对 Vault 进行额外调用的令牌。
一个通用的读取操作，它允许读取任何类型的 Vault 路径，而无需针对该类型的路径进行编写。
将看起来像
kv2响应的响应转换为类似于kv1的更简单的响应。
读取机密是最常见的用例，其中 Vault 内置的 kv（键/值）存储是迄今为止最常见的机密存储。大多数实现使用 v2 版本的 kv 存储。为了使读取 v2 kv 机密变得容易，查找插件假设您可能正在尝试读取 kv 机密，并尝试推断响应是否来自 kv2，因为版本 2 的响应包含元数据，并且机密值还额外包装在另一个结构中。查找插件试图使 kv2 响应看起来更像版本 1 的响应。
由于 kv 存储在每个机密中都有一个或多个键/值对，因此查找还支持其路径中的非标准后缀，该后缀可以通过 :keyname 语法访问属于一个特定键的值。虽然这对于提供一种访问单个机密值的紧凑方式很有用（不可否认，这是一个非常常见的用例），但它使实现复杂化，并导致不良习惯。
例如，人们通常看到使用多个具有相同路径但每个都有不同 :keyname 的查找调用来访问单个机密中的多个值，但这非常浪费，因为它会执行单独的登录和机密查找，所有这些都只为了返回相同的值，并且键解引用是在客户端完成的。此外，解引用可以直接在 Jinja 中完成，在那里可以更清楚地了解正在发生的事情，使用 .key 或 ['key'] 语法。
该插件的最后一个特质是它支持在其术语字符串中提供所有参数。这看起来很紧凑，但它极大地复杂化了插件选项的处理。在创建此查找时，许多其他查找允许在术语字符串中提供选项，但这后来被认为是一种反模式，并且已从核心插件中弃用/删除。
另一个缺点是，当提供多个术语字符串时（直接或通过 with_community.hashi_vault.hashi_vault 提供），这会阻止我们有效地重用身份验证令牌，因此，这种类型的用法会导致每个术语都需要新的登录。在较新的查找中，我们可以利用单个登录来执行多个操作。
所有这些考虑在上下文中都是有意义的，但这在某种程度上混淆了查找的目的
如果来自完全不同的端点的响应最终看起来像
kv2响应，它将返回意外的结果。如果你尝试直接给出
kv2密钥的路径，它将无法工作，除非你在路径中插入一个/data/组件，以便匹配API路径，而不是人们通常熟悉的路径。如果你想要
kv2响应返回的元数据，你无法获取它。除非你修改 URL，否则
kv2的其他功能（如密钥版本控制）也无法直接使用，这很容易出错且不直观。无法访问内部登录创建的令牌以重新使用它。
我们如何解决这些考虑因素
内置的身份验证支持将被保留，事实上，它已经被移动到集合中的共享实用程序中，以便所有插件和模块都可以共享该功能并保持一致的工作方式。这使得测试新的和现有的身份验证方法更容易，添加新的方法更容易（这些方法会自动成为所有现有内容的一部分），并且添加新内容也更容易，因为不需要重新实现身份验证。
此外，现在可以通过 community.hashi_vault.vault_login 模块 和 查找插件 直接执行登录并返回令牌，以便进行通用重用。
通用读取（非 kv 特定）仍然是重要的功能，因此我们有 community.hashi_vault.vault_read 模块 和 查找插件 来提供此功能，而无需尝试推断响应是否来自特定的后端。
由于从 kv 存储读取是迄今为止最常见的用例，因此我们为此提供了专门的内容
community.hashi_vault.vault_kv1_get模块community.hashi_vault.vault_kv2_get模块community.hashi_vault.vault_kv1_get查找community.hashi_vault.vault_kv2_get查找
通过 :keyname 语法进行的字典解引用将不会在其他内容中支持。这将在 Jinja 中通过以下方式实现：
点语法
.keyname查找语法
['keyname']在某些情况下使用专门的过滤器，例如
vault_login_token过滤器。
通过术语字符串传递参数将不会在其他查找中支持。核心开发人员不鼓励使用它，并且核心中已经采取措施删除仍然存在的此功能，但是为了向后兼容性，它将保留在 hashi_vault 插件中，并且因为它可能仍然在许多地方使用。
hashi_vault 查找的未来
目前没有计划弃用或删除 hashi_vault 插件。它可能会无限期地保留下来，以实现向后兼容性，并且由于许多功能已转移到共享代码中，因此几乎不需要维护即可保持其正常运行。如果情况发生变化，可能会重新考虑此决定。
话虽如此，我们将鼓励使用具有更严格范围功能的新内容，并有望在适当的时候收到更新和增强。
不太可能在 hashi_vault 查找中添加或接受新功能，除非是那些“免费”的功能，例如新的身份验证方法（这些方法不需要对插件本身进行代码更改）。