需要帮助了解 Terraform 状态管理

Question

当谈到 Terraform 的工作原理时，这更像是一组概念性的东西。

1) 这是一个场景。假设我创建了一个在 AWS 中创建几台机器的简单计划。初始化，应用，它构建基础设施并创建本地状态文件。对代码满意，我将其推送到github。我的问题是我是否也应该推高状态文件？如果没有状态文件，任何拉下代码并尝试再次构建实例的人都不会拥有状态，所以我假设 terraform 尝试构建一组新机器。但是，状态文件感觉像是残留数据，因此应该被 gitignored。

2) 相同的场景，但假设该计划包含一个实现 S3 后端的设置文件。是否存在相同的问题，或者计划的任何运行是否尊重 S3 后端的状态？

3) 现在，假设我希望这个计划作为一个更大的计划中的模块运行，该计划部署整个环境并将其状态文件存储在 S3 中。该模块已经运行，因此已经存在机器。将模块作为更大模块的一部分运行与 (1) 的行为相同，因为它使用总体计划的状态文件，还是使用其现有的 s3 状态文件？

4) 后端设置是否应该作为一个独立的模块来实现？我的想法是，如果有人试图运行 terraform destroy，他们不会破坏后端，只会破坏基础设施。

总的来说，我对 Terraform 的企业工作流程感到很困惑。

Answer 1

我会根据我对 Terraform 的经验来尝试回答：

1) 使用 Terraform 执行任何操作都需要更新的 Terraform 状态。 It is a requirement of the technology。您可以通过文件共享或 git 共享此状态（不推荐，如果有人忘记进行 git pull 会出现问题，并且该状态包含应保护的敏感数据）。如果standard backends，最好使用一个。正如您所说，如果在没有更新状态的情况下执行 terraform，它将重新创建整个基础架构。

2) 实际上，问题是使用 S3（或任何其他）后端解决的。借助后端，Terraform 负责在执行任何操作之前拉取远程状态。

3) 不，如果您更改计划，则必须手动更新状态。您可以使用terraform refresh 或terraform import 将现有基础设施导入状态。

4) 每个 terraform 计划必须有一个后端，不可能在模块中配置后端。模块旨在导出和共享，因此它必须与后端无关。后端不受 terraform 管理（您应该在开始使用 terraform 之前创建它），因此无论如何它都不会被破坏。如果您希望防止任何其他资源被破坏，您可以使用功能prevent_destroy。

Terraform 有一些团队应该熟悉的警告，其中之一是改变计划的结构意味着需要额外的工作来协调现有基础设施与状态。

无论如何，使用远程后端，团队在同一个计划中一起工作不会有任何问题。