Understanding lifecycle_rules and ignore_changes

user_14712487 0
Viewed 1102

I'll try to give some background, we're deploying a Grafana instance via Terraform and GitLab CI/CD Pipelines.

The first time the pipeline runs the instance loads perfectly and we can access the grafana UI in a web browser. HOWEVER, if we then re-run the pipeline with changes, we will get a HTTP 500 error when trying to hit the grafana UI in a web browser again, every 'even' number run (2, 4, 6, 8, etc.) will cause this issue but the 'odd' number runs work fine.

I've found the fix to be to add ignore_changes block to the ASG, ignore changes to the load_balancers and target_group_arns - as is recommended by Terraform (https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/autoscaling_group)

However I'm struggling to understand what the implications of this change actually are, why does this fix the issue? I've had a Google to try and find some explanation but I can't say I understand any that I've read.

Could anyone help explain what adding these lifecycle rules to the ASG actually do?

autoscaling terraform devops amazon-web-services
1 Answers

The ignore_changes causes terraform to not consider a resource to require an update if only ignored properties changes and not consider the attribute change when actually performing an update. Typical case for this is anything related to autoscaling:

  • you deploy the services using terraform and specify that you want 2 instances
  • autoscaling takes care of upscaling to X instances
  • next deployment would come along and downgrade to 2 instances again - not ideal!

That is why you literally tell terraform to ignore the changes related to some attributes (e.g. desired_count) such that terraform does not roll back some scaling changes that happened during the actual application lifecycle.

Another example is: if you have a bucket specifying KMS SSE and then upload an object into that bucket using terraform but do not specify a KMS key for that object then the object will inherit the KMS key of the bucket. But in the terraform code you did not specify the key meaning that during the next deployment terraform would try to change / remove the encryption on the object. That is why we often have ignore_changes for the kms_key_id set up in that case.

If you want to figure out why the ignore_changes is required / recommended in your situation I would advise you to look at the plan that terraform generates without the ignore_changes in place. Try to understand which property changes and try to reason what resources those properties point to and why a change in them might be expected / unexpected. I am not familiar enough with the autoscaling_group to reason about it.

user_24428040
Related