如何减少刷新 Terraform 状态的时间？答案

【问题标题】：How to reduce the time it takes to refresh Terraform's state?如何减少刷新 Terraform 状态的时间？
【发布时间】：2018-12-22 12:51:33
【问题描述】：

我工作的公司的大部分 AWS 基础设施都是使用 Terraform 描述和管理的。

我们有多种不同的服务，包括容器化后端和 CDN 化前端。

从 Route53 域和命名空间到 ELB、ECS 和 CloudFront，有很多事情要做。

现在发生的一个问题是，主要是因为 Route53 DNS，检查、刷新和验证 terraform 状态需要很长时间。

这就是我们要解决的问题：

如何大幅减少刷新/检查 tf 状态所需的时间？

将其移至单独的存储库显然不是一个好主意，因为这会使所有与 Route53 相关的变量都无法访问，或者可能已经过时。

【问题讨论】：

您的所有 Terraform 配置是否都在一个地方？最佳实践表明，您应该将事物拆分为仅需要同时应用的组，以最小化爆炸半径，在不破坏状态的情况下更容易进行并发更改，并减少 Terraform 刷新和构建依赖关系图。
多少资源（在计划的输出中量化为每行 1 个资源）以及计划需要多少时间？示例：我有 250 多个资源，其中 20 多个是 route53 的东西 - 制定计划需要
@ydaetskcoR 我们有一个描述整个公司基础设施的存储库。有不同的 .tf 文件可以根据对我们有意义的内容来组织资源。但它们仍然是“一次性”阅读的。
@Shorn 我必须将我的数据与您的数据进行比较，感谢您提供。尽管我们拥有的 Route53 资源的数量至少比这多一个数量级。
单个 repo 很好，但通常您只会将 .tf 文件放在同一目录中，如果它们需要同时应用。然后，您应该按照 Stackoverflow 上其他 Terraform 项目结构问题中提到的方式拆分您的目录结构

标签： dns terraform amazon-route53 infrastructure terraform-provider-aws

【解决方案1】：

我来这里是因为我正在研究一个类似的问题。似乎 TF 在图行走方面很糟糕，所以你的东西越相互关联，它的表现就越差。我有一个 2300 资源的毛线球。这需要 49 分钟才能在具有足够内存和处理器的机器上以 10 的并行度运行而不会出现峰值。三分之一用于刷新状态，这可能无法减少，因为它受 AWS CLI 调用的约束。但是在状态刷新之前花费的第三个和之后的第三个似乎主要是 TF 在图表中玩弄的（基于日志）。

我发现一些讨论似乎表明您的代码结构可能会显着影响计划时间，特别是for_each 的使用（链接#1 和#2）。由于我的代码库大量使用了这个，我发现这很有趣。 YMMV ;)

【讨论】：

哦，显然，如果您可以通过拆分堆栈来减小堆栈的大小，您应该会看到规划时间的超线性减少，但我猜来这里的人已经尝试过； )

【解决方案2】：

您应该将状态分解为具有合理逻辑区别的组件子状态，例如“前端”、“缓存”或任何对贵公司如何组织和分类基础架构有意义的东西。

在使变量可访问方面，您可以将其他状态声明为数据源并从中提取（假设它们具有您感兴趣的值的有效输出）。

【讨论】：