How to set up autoscaling group so it's not recreated every time?

1,064 views
Skip to first unread message

David Foltin

unread,
Jun 2, 2016, 6:04:01 PM6/2/16
to Terraform
I'm trying to create a few autoscaling groups but every time I run apply they get recreated. I've followed advice from Hashicorp, I tried out doing ignore_changes on the name, but nothing seems to work.

How do I configure security groups so that apply's are idempotent?

Module config and plan after first apply from 0.6.16 here.

David Adams

unread,
Jun 2, 2016, 7:02:12 PM6/2/16
to terrafo...@googlegroups.com
Launch configurations are singletons and can't be updated in the AWS API. So terraform is wanting to destroy and re-create your launch configuration. In your ASG config you point the launch_configuration property to your launch configuration resource name, which is correct, and that property on the ASG can change. But you also point the ASG name to the launch configuration name. So since the launch configuration is going to be destroyed, terraform assumes the name will change. You can't change ASG names, so you would have to recreate it to get a new name.

So the probable solution would be to change the asg resource name property to something not dependent on the launch configuration resource.

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/terraform/issues
IRC: #terraform-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Terraform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to terraform-too...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/terraform-tool/f245f220-3c1a-4b87-9e38-69e4f84ddc09%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

David Foltin

unread,
Jun 3, 2016, 3:59:44 PM6/3/16
to Terraform
But I am not doing anything to change the launch configuration - if I do two applies in a row why would it want to change the launch configuration on the second apply? This configuration is also in use at Hashicorp except I'm adding ebs volumes.

David Adams

unread,
Jun 3, 2016, 5:30:17 PM6/3/16
to terrafo...@googlegroups.com
Well, your plan indicates it is wanting to recreate the launch config. And that is what's triggering the ASG destroy/create. If you remove the ASG name dependency on the Launch Config name, that will prevent the ASG from being fully recycled.

In re the launch configuration, I've not worked with those in Terraform, *but* as the comments in your tf code indicate that there's a bug with terraform getting confused over ebs_block_device, and mentioning ignore_changes. But the "ignore_changes" property is commented out under lifecycle just below. So it's not ignoring the changes:

  /* TF has trouble detecting state of ebs, hence ignore_changes. v0.6.16 */
  ebs_block_device {
    device_name = "${var.lc_ebs_block_device_name}"
    volume_size = "${var.lc_ebs_block_device_volume_size}"
    volume_type = "${var.lc_ebs_block_device_volume_type}"
  }

  lifecycle {
    create_before_destroy = true
    /*ignore_changes        = ["ebs_block_device"]*/
  }

So I guess you're hitting this bug because ignore_changes is commented out (though possibly you commented it out because there are still problems there--I've run into cases where ignore_changes doesn't save me from TF wanting to destroy something if the destruction is triggered by a graph dependency and not just the value of the string.).

David Foltin

unread,
Jun 3, 2016, 10:27:17 PM6/3/16
to Terraform
Yeah, if I undo ignore changes then tf just crashes saying the diffs don't match up.

David Foltin

unread,
Jun 10, 2016, 1:15:01 PM6/10/16
to Terraform
I was able to figure this out - turns out that I had set up ebs to replace to root device of the ami, which doesn't work. Instead I needed to use the root_block_device in the asg. Here's our config now:

resource "aws_launch_configuration" "mod" {
  name_prefix = "${var.tag_product}-${var.tag_env}-${var.tag_service}-${var.tag_component}-${var.lc_ami_timestamp}-"

  image_id             = "${var.lc_ami_id}"
  instance_type        = "${var.lc_instance_type}"
  iam_instance_profile = "${var.lc_iam_instance_profile}"
  key_name             = "${var.lc_key_name}"
  security_groups      = ["${var.lc_security_groups}"]

  user_data         = "${file(var.lc_user_data_path)}"
  enable_monitoring = false

  root_block_device {
    volume_size = "${var.lc_root_block_device_volume_size}"
    volume_type = "${var.lc_root_block_device_volume_type}"
  }

  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_autoscaling_group" "mod" {
  # This causes LCs and ASGs to stay in sync.

  availability_zones   = ["${split(",", var.asg_availability_zones)}"]
  vpc_zone_identifier  = ["${split(",", var.asg_subnets)}"]
  launch_configuration = "${aws_launch_configuration.mod.id}"
  min_size             = "${var.asg_min_size}"
  max_size             = "${var.asg_max_size}"

  termination_policies = ["${split(",", var.asg_termination_policies)}"]
  load_balancers       = ["${var.asg_elb_names}"]

  lifecycle {
    create_before_destroy = true
  }

  tag {
    key                 = "Name"
    value               = "${var.tag_product}-${var.tag_env}-${var.tag_service}-${var.tag_component}"
    propagate_at_launch = true
  }
}
Reply all
Reply to author
Forward
0 new messages