Auto Scaling Group launch config changes

Question

I wonder if there is a simple way or best practices on how to ensure all instances within an AutoScaling group have been launched with the current launch-configuration of that AutoScaling group.

To give an example, imagine an auto-scaling group called www-asg with 4 desired instances running webservers behind an ELB. I want to change the AMI or the userdata used to start instances of this auto-scaling group. So I create a new launch configuration www-cfg-v2 and update www-asg to use that.

# create new launch config
as-create-launch-config www-cfg-v2 \
    --image-id 'ami-xxxxxxxx' --instance-type m1.small \
    --group web,asg-www --user-data "..."

# update my asg to use new config
as-update-auto-scaling-group www-asg --launch-configuration www-cfg-v2

By now all 4 running instances still use the old launch configuration. I wonder if there is a simple way of replacing all running instances with new instances to enforce the new configuration, but always ensure that the minimum of instances is kept running.

My current way of achieving this is as follows..

1. save list of current running instances for given autoscaling group
2. temporarily increase the number of desired instances +1
3. wait for the new instance to be available

4. terminate one instance from the list via

   as-terminate-instance-in-auto-scaling-group i-XXXX \
       --no-decrement-desired-capacity --force
   

5. wait for the replacement instance to be available

6. if more than 1 instance is left repeat with 4.

7. terminate last instance from the list via

   as-terminate-instance-in-auto-scaling-group i-XXXX \
       --decrement-desired-capacity --force
   

8. done, all instances should now run with same launch config

I have mostly automated this procedure but I feel there must be some better way of achieving the same goal. Anyone knows a better more efficient way?

mathias

Also posted this question in the official AWS EC2 Forum.

Answer 1

Old question I know but I thought I would share my approach.

I change the launch config for an ASG, I then launch the same number of instances as are currently in the ASG, as they become available (automated testing) they are attached to the ASG. once the machines have been added our deployment system updates our varnish loadbalancer(s) to use the new instances and the old instances are terminated.

All of the above is automated and a full site scale switch takes about 5 minutes depending on the launch time.

incase you are wondering, we use SNS to handle updating varnish when instances are added or removed or in the case of our loadbalancers scaling (which almost never happens) the deployment system will update our route53 config instead.

I think that pretty much covers everything

Answer 2

This isn't a lot different, but you could:

1. create the new LC
2. create a new ASG using the new LC
3. scale down the old ASG
4. delete the old asg and LC

I do deployments this way, and it's in my experience to roll from one ASG to another, rather than having to jump back and forth. But as I noted, it's not a huge difference.

It might be worth looking at: https://github.com/Netflix/asgard , which is a Netflix OSS tool for managing autoscaling groups. I ended up not using it, but it's pretty interesting nonetheless.