关于 hashi_vault 查找
此页面解释了 hashi_vault 查找插件 的过去、现在和未来。
hashi_vault 查找是 Ansible 中最早的与 Vault 相关的内容。它包含在预集合 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'] 语法。
该插件的最后一个特性是它支持在 term 字符串中提供其所有参数。这看起来很紧凑，但它大大复杂化了插件选项的处理。在该查找创建时，许多其他查找允许在 term 字符串中提供选项，但此后它被认为是一种反模式，并且已从核心插件中弃用/删除。
另一个缺点是，当提供多个术语字符串（直接提供或通过 with_community.hashi_vault.hashi_vault 提供）时，它会阻止我们有效地重用身份验证令牌，因此，这种用法会导致每个术语都进行新的登录。在新版本的查找中，我们可以利用单次登录执行多个操作。
所有这些考虑在上下文中都是有意义的，但这在某种程度上混淆了查找的目的
如果来自完全不同端点的响应看起来像
kv2响应，它将返回意外的结果。如果您尝试直接给出
kv2密钥的路径，它将无法工作，除非您在路径中插入一个/data/组件，以便与API 路径匹配，而不是人们通常熟悉的路径。如果您想要随
kv2响应一起返回的元数据，则无法获取。kv2的其他功能（如密钥版本控制）不能直接使用，除非您修改 URL，这容易出错且不直观。无法访问内部登录创建的令牌以便重用它。
我们如何解决这些考虑事项
内置的身份验证支持将保留，事实上，它已移动到集合中的共享实用程序中，以便所有插件和模块都可以共享该功能并保持一致地工作。这使得测试新的和现有的身份验证方法更容易，添加新的方法也更容易（这些方法会自动成为所有现有内容的一部分），并且添加新内容也更容易，因为不需要重新实现身份验证。
此外，现在可以通过 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 查找中添加或接受新功能（这些功能无需更改插件本身的代码）。