了解 lifecycle_rules 和 ignore_changes
Understanding lifecycle_rules and ignore_changes
我将尝试提供一些背景知识，我们正在通过 Terraform 和 GitLab CI/CD 管道部署 Grafana 实例。
第一次管道 运行 实例加载完美，我们可以在网络浏览器中访问 grafana UI。但是，如果我们随后重新 运行 管道进行更改，当我们再次尝试在网络浏览器中访问 grafana UI 时，我们将收到 HTTP 500 错误，每个 'even' 数字 运行（2、4、6、8 等）会导致此问题，但 'odd' 数字 运行 工作正常。
我发现解决方法是将 ignore_changes 块添加到 ASG，忽略对 load_balancers 和 target_group_arns 的更改 - 按照 Terraform 的建议（https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/autoscaling_group)
但是我很难理解此更改的实际含义，为什么这可以解决问题？我有一个 Google 试图找到一些解释，但我不能说我理解我读过的任何内容。
任何人都可以帮助解释将这些生命周期规则添加到 ASG 的实际作用吗？
ignore_changes 导致 terraform 在仅忽略属性更改时不考虑需要更新的资源，并且在实际执行更新时不考虑属性更改。典型的情况是与自动缩放相关的任何事情：
- 您使用 Terraform 部署服务并指定您需要 2 个实例
- 自动缩放负责升级到 X 个实例
- 下一次部署会出现并再次降级到 2 个实例 - 不理想！
这就是为什么您从字面上告诉 Terraform 忽略与某些属性相关的更改（例如 desired_count），这样 Terraform 就不会回滚在实际应用程序生命周期中发生的某些缩放更改。
另一个示例是：如果您有一个指定了 KMS SSE 的存储桶，然后使用 terraform 将一个对象上传到该存储桶中，但没有为该对象指定 KMS 密钥，那么该对象将继承该存储桶的 KMS 密钥。但是在 terraform 代码中，您没有指定密钥，这意味着在下一次部署期间，terraform 将尝试更改/删除对象上的加密。这就是为什么在这种情况下我们经常为 kms_key_id 设置 ignore_changes。
如果您想弄清楚为什么在您的情况下需要/推荐 ignore_changes，我建议您查看 terraform 在没有 ignore_changes 的情况下生成的计划。尝试了解哪些 属性 发生了变化，并尝试推断这些属性指向哪些资源，以及为什么它们的变化可能是预期的/意外的。我对 autoscaling_group 不够熟悉，无法推理。
我将尝试提供一些背景知识，我们正在通过 Terraform 和 GitLab CI/CD 管道部署 Grafana 实例。
第一次管道 运行 实例加载完美，我们可以在网络浏览器中访问 grafana UI。但是，如果我们随后重新 运行 管道进行更改，当我们再次尝试在网络浏览器中访问 grafana UI 时，我们将收到 HTTP 500 错误，每个 'even' 数字 运行（2、4、6、8 等）会导致此问题，但 'odd' 数字 运行 工作正常。
我发现解决方法是将 ignore_changes 块添加到 ASG，忽略对 load_balancers 和 target_group_arns 的更改 - 按照 Terraform 的建议（https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/autoscaling_group)
但是我很难理解此更改的实际含义，为什么这可以解决问题？我有一个 Google 试图找到一些解释，但我不能说我理解我读过的任何内容。
任何人都可以帮助解释将这些生命周期规则添加到 ASG 的实际作用吗？
ignore_changes 导致 terraform 在仅忽略属性更改时不考虑需要更新的资源，并且在实际执行更新时不考虑属性更改。典型的情况是与自动缩放相关的任何事情：
- 您使用 Terraform 部署服务并指定您需要 2 个实例
- 自动缩放负责升级到 X 个实例
- 下一次部署会出现并再次降级到 2 个实例 - 不理想！
这就是为什么您从字面上告诉 Terraform 忽略与某些属性相关的更改（例如 desired_count），这样 Terraform 就不会回滚在实际应用程序生命周期中发生的某些缩放更改。
另一个示例是：如果您有一个指定了 KMS SSE 的存储桶，然后使用 terraform 将一个对象上传到该存储桶中，但没有为该对象指定 KMS 密钥，那么该对象将继承该存储桶的 KMS 密钥。但是在 terraform 代码中，您没有指定密钥，这意味着在下一次部署期间，terraform 将尝试更改/删除对象上的加密。这就是为什么在这种情况下我们经常为 kms_key_id 设置 ignore_changes。
如果您想弄清楚为什么在您的情况下需要/推荐 ignore_changes，我建议您查看 terraform 在没有 ignore_changes 的情况下生成的计划。尝试了解哪些 属性 发生了变化，并尝试推断这些属性指向哪些资源，以及为什么它们的变化可能是预期的/意外的。我对 autoscaling_group 不够熟悉，无法推理。