14

Here's what I have in AWS:

  • Application ELB
  • Auto Scaling Group with 2 instances in different regions (Windows IIS servers)
  • Launch Config pointing to AMI_A
  • all associated back end stuff configured (VPC, subnets, security groups, ect)

Everything works. However, when I need to make an update or change to the servers, I am currently manually creating a new AMI_B, creating a new LaunchConfig using AMI_B, updating the AutoScalingGroup to use the new LaunchConfig, increasing min number of instances to 4, waiting for them to become available, then decreasing the number back to 2 to kill off the old instances.

I'd really love to automate this process. Amazon gave me some links to CLI stuff, and I'm able to script the AMI creation, create the LaunchConfig, and update the AutoScalingGroup...but I don't see an easy way to script spinning up the new instances.

After some searching, I found some CloudFormation templates that look like they'd do what I want, but most do more, and it's a bit confusing to me.

Should I be exploring CloudFormation? Is there a simple guide I can follow to get started? Or should I stay with the scripting I have started?

PS - sorry if this is a repeated question. Things change frequently at AWS, so sometimes the older responses may not be the current best answers.

sureshot007
  • 181
  • 1
  • 1
  • 7

3 Answers3

8

You have a number of options to automate the process of updating the instances in an Auto Scaling Group to a new or updated Launch Configuration:

CloudFormation

If you do want to use CloudFormation to manage updates to your Auto Scaling Group's instances, refer to the UpdatePolicy attribute of the AWS::AutoScaling::AutoScalingGroup Resource for documentation, and the "What are some recommended best practices for performing Auto Scaling group rolling updates?" page in the AWS Knowledge Center for more advice.

If you'd also like to script the creation/update of your AMI within a CloudFormation resource, see my answer to the question, "Create AMI image as part of a cloudformation stack".

Note, however, that CloudFormation is not a simple tool- it's a complex, relatively low-level service for orchestrating AWS resources, and migrating your existing scripts to it will likely take some time investment due to its steep learning curve.

Elastic Beanstalk

If simplicity is most important, then I'd suggest you evaluate Elastic Beanstalk, which also supports both rolling and immutable updates during deployments, in a more fully managed, console-oriented, platform-as-a-service environment. Refer to my answer to the question, "What is the difference between Elastic Beanstalk and CloudFormation for a .NET project?" for further comparisons between CloudFormation and Elastic Beanstalk.

CodeDeploy

If you want a solution for updating instances in an auto-scaling group that you can plug into existing scripts, AWS CodeDeploy might be worth looking into. You install an agent on your instances, then trigger deployments through the API/CLI/Console and it manages deploying application updates to your fleet of instances. See Deploy an Application to an Auto Scaling Group Using AWS CodeDeploy for a complete tutorial. While CodeDeploy supports 'in-place' deployments and 'blue-green' deployments (see Working With Deployments for details), I think this service assumes an approach of swapping out S3-hosted application packages onto a static base AMI rather than replacing AMIs on each deployment. So it might not be the best fit for your AMI-swapping use case, but perhaps worth looking into anyway.

wjordan
  • 19,770
  • 3
  • 85
  • 98
1

You want a custom Termination policy on the Auto Scaling Group.

OldestLaunchConfiguration. Auto Scaling terminates instances that have the oldest launch configuration. This policy is useful when you're updating a group and phasing out the instances from a previous configuration.

To customize a termination policy using the console

  1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
  2. On the navigation pane, choose Auto Scaling Groups.

  3. Select the Auto Scaling group.

  4. For Actions, choose Edit.

  5. On the Details tab, locate Termination Policies. Choose one or more termination policies. If you choose multiple policies, list them in the order that you would like them to apply. If you use the Default policy, make it the last one in the list.

  6. Choose Save.

On the CLI 

 aws autoscaling update-auto-scaling-group --auto-scaling-group-name my-asg --termination-policies "OldestLaunchConfiguration"

https://docs.aws.amazon.com/autoscaling/latest/userguide/as-instance-termination.html

strongjz
  • 4,271
  • 1
  • 17
  • 27
  • 1
    Termination policy is applied at the time of scale-in event so this is not solving the problem. – dsumsky Jul 13 '17 at 15:49
  • When scale in it should destroy the instances with the oldest launch config, if you set the custom termination policy. – strongjz Jul 13 '17 at 15:51
0

We use Ansible's ec2_asg module for that purpose. There are replace_all_instances and replace_batch_size settings for that purpose. Per documentation:

In a rolling fashion, replace all instances that used the old launch configuration with one from the new launch configuration. It increases the ASG size by C(replace_batch_size), waits for the new instances to be up and running. After that, it terminates a batch of old instances, waits for the replacements, and repeats, until all old instances are replaced. Once that's done the ASG size is reduced back to the expected size.

If you provide target_group_arns, module will check for health of instances in target groups before going to next batch.

Edit: in order to maintain desired number of instances, we first set min to desired.

vvucetic
  • 479
  • 7
  • 15