时间戳

首页 > 解决方案 > 了解生命周期规则和忽略变化

amazon-web-services - 了解生命周期规则和忽略变化

问题描述

我将尝试提供一些背景信息，我们正在通过 Terraform 和 GitLab CI/CD Pipelines 部署一个 Grafana 实例。

管道第一次运行实例加载完美，我们可以在 Web 浏览器中访问 grafana UI。但是，如果我们随后重新运行带有更改的管道，当尝试再次在 Web 浏览器中点击 grafana UI 时，我们将收到 HTTP 500 错误，每个“偶数”数字都会运行（2、4、6、8 等）。 ) 将导致此问题，但“奇数”数字运行正常。

我发现解决方法是向ignore_changesASG 添加块，忽略对load_balancers和的更改target_group_arns- 正如 Terraform 所建议的那样（https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/autoscaling_group )

但是我很难理解这种变化的实际含义是什么，为什么这能解决这个问题？我有一个谷歌试图找到一些解释，但我不能说我理解我读过的任何内容。

谁能帮助解释将这些生命周期规则添加到 ASG 的实际作用？

标签： amazon-web-servicesterraformdevopsautoscaling

解决方案

如果仅忽略属性更改并且在实际执行更新时不考虑属性更改，ignore_changes则导致 terraform 不考虑资源需要更新。典型情况是与自动缩放相关的任何事情：

  • 您使用 terraform 部署服务并指定需要 2 个实例
  • 自动缩放负责升级到 X 个实例
  • 下一次部署将出现并再次降级到 2 个实例 - 不理想！

这就是为什么您从字面上告诉 terraform 忽略与某些属性（例如desired_count）相关的更改，以便 terraform 不会回滚在实际应用程序生命周期中发生的某些缩放更改。

另一个例子是：如果您有一个指定 KMS SSE 的存储桶，然后使用 terraform 将一个对象上传到该存储桶，但没有为该对象指定 KMS 密钥，则该对象将继承该存储桶的 KMS 密钥。但是在 terraform 代码中，您没有指定密钥，这意味着在下一次部署期间，terraform 将尝试更改/删除对象上的加密。这就是为什么我们经常在这种情况下ignore_changes进行kms_key_id设置。

如果您想弄清楚为什么ignore_changes在您的情况下需要/建议使用，我建议您查看 terraform 在没有ignore_changes就地情况下生成的计划。尝试了解哪些属性发生了变化，并尝试推断这些属性指向哪些资源，以及为什么它们的更改可能是预期/意外的。autoscaling_group我对它的推理不够熟悉。

推荐阅读