The normal thing to do here is to use Terraform's lifecycle management to force it to create new resources before destroying the old ones.
In this case you might set your launch configuration and autoscaling group up something like this:
resource "aws_launch_configuration" "as_conf" {
name_prefix = "terraform-lc-example-"
image_id = "${var.ami_id}"
instance_type = "t1.micro"
lifecycle {
create_before_destroy = true
}
}
resource "aws_autoscaling_group" "bar" {
name = "terraform-asg-example-${aws_launch_configuration.as_conf.name}"
launch_configuration = "${aws_launch_configuration.as_conf.name}"
lifecycle {
create_before_destroy = true
}
}
Then if you change the ami_id
variable to use another AMI Terraform will realise it has to change the launch configuration and so create a new one before destroying the old one. The new name generated by the new LC is then interpolated in the ASG name forcing a new ASG to be rebuilt.
As you are using create_before_destroy
Terraform will create the new LC and ASG and wait for the new ASG to reach the desired capacity (which can be configured with health checks) before destroying the old ASG and then the old LC.
This will flip all the instances in the ASG at once. So if you had a minimum capacity of 2 in the ASG then this will create 2 more instances and as soon as both of those pass health checks then the 2 older instances will be destroyed. In the event you are using an ELB with the ASG then it will join the 2 new instances to the ELB so, temporarily, you will have all 4 instances in service before then destroying the older 2.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…