19

I have a web application setup with a load balancer and auto scaling group to manage scaling. The source code is in a git repository so I don't have to update the images when the code changes, but occasionally the environment changes so we create a new image. Then that image needs to be cycled into the auto scaling group.

Is there a way to cycle the images automatically? Right now I schedule a scale up and scale down action which gets rid of the old instances.

  • 2
    It is probably more efficient if, after you create your new launch config and update your autoscaling group, you mark each instance as unhealthy (e.g. using as-set-instance-health), so that autoscaling simply replaces it with a new instance. – cyberx86 Apr 30 '12 at 20:10
10

I'd like to suggest "AWS-HA-Release" to do this - the way AWS-HA-Release works:

  1. If the current autoscaling group and ELB report 5 instances that are healthy,
  2. AWS-HA-Release brings a new instance into production and waits for the ELB to identify it as healthy (bring the total number of healthy instances to 6)
  3. Removes an old instance (total down to 5)
  4. Brings another instance into service (total to 6)
  5. Removes an old instance (total down to 5)
  6. and so on until all instances have been replaced

In this case, you can ship new code or new AMI versions without downtime and have the benefit of entirely new instances. The AWS-HA-Release tool is available at https://github.com/colinbjohnson/aws-missing-tools.

7

The easier way is to increase number of minimum instances in Auto-Scaling Group (ASG) to double of your current count, wait when all of them are started and then change that minimum number of instances down to what it was. ELB will kill older instances and will leave newer instances with code. To achieve that Termination policy should be set to 'OldestInstance' to work as intended. Default termination policy may have unwanted side effects.

You can look at AWS CLI parameters and examples here: http://docs.aws.amazon.com/cli/latest/reference/autoscaling/update-auto-scaling-group.html

  • Cheers, this is a super convenient, hassle-free method. – Elad Nava Dec 20 '17 at 3:45
  • This will not always work, per the AWS docs, even when selecting a custom termination policy the ASG will keep the AZ's balanced before applying the termination policy. So just doubling and halving the size can leave you with a couple old instances. This is especially likely when using an ASG with multiple instance types and purchase options, since the ASG will keep the AZ's balanced AND the market option (spot vs on demand) balanced before applying the 'OldestInstance' policy: docs.aws.amazon.com/autoscaling/ec2/userguide/… – Shahad Apr 9 at 22:46
6

the way i manage this scenario is to use the UpdatePolicy feature of the AWS::AutoScaling::AutoScalingGroup object in cloud formation. when the cloud formation stack is updated it will manage the cycling of the instances.

some references. http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-group.html http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-updatepolicy.html

  • Thanks a tonne @graeme. I had no idea Cloudformation offered this functionality. – AJB Aug 27 '15 at 7:52
  • Exactly what I was looking for. We deploy our stacks via Jenkins as changes through the AWS console are locked down. – Greg Biles Jan 9 at 23:49
3

Also have a look at the Netflix Asgard tool that is now open source. Not only can it set up Auto Scaling Groups, it can also perform rolling releases of new AMI images for a group of instances.

  • You mean "Netflix Asgard" – user99751 Nov 17 '12 at 15:08
  • 3
    Netflix Asgard is now deprecated, it is replaced with Netflix Spinnaker – dlaidlaw Jun 14 '17 at 14:21
0

There's not actually a really good way of doing it to be honest. The best way I found to do it is to put a version in the ASG name. Any time I update the AMI I create a new ASG + Launch Config with the new version so it does not conflict with the other group. Then I terminate all the instances in the old group.

If a more fault tolerant deployment is required I recommend adding another step by involving the creation of a new loadbalancer as well. This allows you to have both ASG isolated from each other. It also allows you to have a "Staging" area to test your changes one last time before updating. Then when you're ready to switch you update the DNS records and terminate all the instances in the old group.

0

As I posted here (similar question, just with Terraform), it isn't built into ASG in any way, except if you use cloudformation. I struggled with it as well, so ended up writing a "roller" that watches multiple ASG, checks their state and updates. Always happy to take feedback. http://github.com/deitch/aws-asg-roller

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy