全球资源在 Terraform 提供程序中的优化映射方法

从现在开始，努力学习吧！本文《全球资源在 Terraform 提供程序中的优化映射方法》主要讲解了等等相关知识点，我会在golang学习网中持续更新相关的系列文章，欢迎大家关注并积极留言建议。下面就先一起来看一下本篇正文内容吧，希望能帮到你！

我正在为一个软件编写一个 terraform 提供程序，该软件具有大量特定于实例的全局配置（大约 300 个）。当您使用提供程序时，您可以定义端点和凭据，然后在此实例中进行操作。我正在努力决定如何准确地管理此配置。它不是创建或销毁的资源，因此我不确定创建 global_config 资源是否是最好的方法。由于所有值在系统设置期间已经被初始化并且只能被覆盖；配置不能被破坏；您不能拥有两个以上的配置资源。由于您应该能够覆盖所有条目，因此它也不能是数据源。

到目前为止，我还没有找到任何相关文档（甚至类似的示例），所以如果有人可以向我指出任何相关内容，或者建议如何最好地实现这一目标，我将非常感激。谢谢。

正确答案

Terraform 的提供者模型主要是为 Terraform 本身可以创建或销毁的对象而设计的。没有内置支持自动“采用”现有对象来接受 Terraform 的管理，因为 Terraform 通常假设每个对象都由一个声明的资源实例管理，而 Terraform 旨在通过成为创建者来保留这一假设对象。

但是，在其他系统中存在一些此类“单例”对象的现有示例，该对象是隐式创建的，但可以更改其设置。研究的关键示例是 AWS 中默认 VPC 及其默认公有子网的资源类型。

目前有两种广泛的方法可以在 Terraform 中表示这种情况，这两种方法都不是完美的，因此每种方法都有一些优点和缺点需要考虑：

• 强制 terraform import：您可以构建资源类型，以便其“创建”操作总是立即失败告诉用户导入现有对象，然后实现“导入” “允许用户使用 terraform import 命令将现有对象显式绑定到 Terraform 资源实例的操作。

  这是两个选项中更明确的一个，因为它要求用户有意声明现有对象应由此 Terraform 配置管理，就像用户通常采取该操作的方式一样在地形中。这意味着用户仍处于控制之中，并且可以（正如他们在导入时必须始终执行的那样）小心将该对象导入到一个 Terraform 配置中的一个资源实例中，从而保留 Terraform 的唯一性假设。

  但是，它还向使用此资源类型的任何 Terraform 配置添加了强制的额外设置步骤。该额外步骤不太适合 typical automation around Terraform，因此通常需要在团队正常工作流程之外以特殊方式执行该步骤。

• 将“创建”视为“采用”：由于提供者预期为资源类型实现的操作只是一种约定，因此不存在任何技术性 原因是您的“创建”操作不能仅验证配置的对象是否存在并返回成功而不创建任何内容。我在这里称其为“采用”，以表示 Terraform 将假设该现有对象现在处于声称创建它的任何资源实例的排他管理之下，但“采用”实际上并不是 Terraform 工作流程的正式部分。

  这样做的优点是可以很好地融入现有的 Terraform 工作流程，不需要操作员执行任何不寻常的额外步骤。

  但是，这也意味着更容易意外地将同一对象采用到两个不同的资源实例中，无论是在相同的配置中还是在单独的配置中。这样做的后果将根据对象所代表的内容而有所不同，但至少它可能会导致不同的资源实例彼此“争斗”，不断地在每个新的 Terraform 运行中撤消彼此的工作，从而永远不会收敛到稳定的期望值状态。

其中第二个是两者中更方便的一个，因此现有提供商通常选择的一个，只要不正确的多重采用的后果只是非-聚合系统：这种情况令人困惑，有点烦人，但通常也不是超级有害。

第一个是两者中更安全的一个，因为它可以防止意外的多重采用问题。如果两个配置争夺控制单个对象可能会产生更严重的后果，例如一个配置通过以对其他用例无效的方式更改其设置来破坏另一个配置，那么这可能是合适的.

本篇关于《全球资源在 Terraform 提供程序中的优化映射方法》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！