DEV Community: Olatunde Babawale

Managing Rolling Updates in AWS Auto Scaling Groups with AWS CloudFormation Update Policy: Part 2

Olatunde Babawale — Thu, 13 Jul 2023 00:35:44 +0000

This is the concluding part of this blog post. Visit this post to see the foundational part.

In this post, we create a cloud infrastructure using two cross-linked CloudFormation stacks: the network stack deploys the networking infrastructure, while the servers stack deploys the servers which are managed by an Auto Scaling Group (ASG). The purpose of this post is to demonstrate the use of UpdatePolicy to guarantee a smooth roll out of changes to the CloudFormation Template.

We will walkthrough this in sections as outlined below:

Description of Files and Resources used.
Stack update behavior without an Update policy.
Stack update behavior with an Update policy
Clean up the AWS environment.

1. Description of Files and Resources used

The files and commands used can be found in this GitHub repo. The README.md file gives a full description.
- The resources created by the templates include:
- A Virtual Private Cloud (VPC) with four subnets in two availability zones (AZs)
- The subnets are a pair of Public and Private subnets.
- Two NAT Gateways
- A Load Balancer
- Auto Scaling Group
- Amazon Linux AMIs AWS Cloud9 is used as the IDE. See this post to learn how to set up a Cloud9 environment and learn some of its benefits.

The only difference between the two template files are:

Updating the UserData of the Launch Template to install cfn-signals and send signals.

WebAppLaunchTemplate:
    Type: AWS::EC2::LaunchTemplate
    Properties:
      LaunchTemplateName: !Sub ${AWS::StackName}-launch-template
      LaunchTemplateData:
          UserData:
            Fn::Base64: !Sub |
              #!/bin/bash -xe
              yum update -y
              yum upgrade -y
              yum install -y aws-cfn-bootstrap
              yum install -y httpd
              systemctl enable httpd
              systemctl start httpd
              echo "<html><head><title>Blog Post Demo Test Page</title></head><body><h1><center>"This is Version 2.0"</center></h1></body></html>"  > /var/www/html/index.html
              /opt/aws/bin/cfn-signal -e $? --stack ${AWS::StackName} --resource AppAutoScaleGroup --region ${AWS::Region}

Updating the ASG resource definition with an UpdatePolicy

  AppAutoScaleGroup: 
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      VPCZoneIdentifier:
      - Fn::ImportValue: 
          !Sub "${EnvironmentName}-PRIV-NETS"
      LaunchTemplate:
        LaunchTemplateId:
            Ref: WebAppLaunchTemplate
        Version: !GetAtt WebAppLaunchTemplate.LatestVersionNumber
      MinSize: '2'
      MaxSize: '4'
      DesiredCapacity: "2"
      TargetGroupARNs:
      - Ref: WebAppTargetGroup
    UpdatePolicy:
      AutoScalingRollingUpdate:
        MinInstancesInService: '1'
        MaxBatchSize: '1'
        PauseTime: PT12M5S
        WaitOnResourceSignals: true
        SuspendProcesses:
          - HealthCheck
          - ReplaceUnhealthy
          - AZRebalance
          - AlarmNotification
          - ScheduledActions

2. Stack update behavior without an Update policy

Next, we examine the behavior of a stack without a defined update policy.

Step 1: We create the network stack using the helper scripts from the Cloud9 terminal

./create.sh infra network-infra.yaml network-infra-params.json us-east-1

Wait for the operation to complete before proceeding to the next step.

Step 2: We create the servers stack

./create.sh servers servers-without-update-policy.yaml servers-params.json us-east-1

Wait for the operation to complete and assess the DNS of the load balancer under the outputs tab.

Open the link in a new tab to see the web page as shown below.

This shows Version 1.0 of our deployment.

Step 3: Change the version number in the UserData section of servers-without-update-policy.yaml

And update the stack with

./update.sh servers servers-without-update-policy.yaml servers-params.json us-east-1

Observe that the update does not initiate a stack update. This is because a change in the UserData section does not cause a stack to update. The UserData is run only once during creation.
The only way to force this update is to manually delete the instances in the Auto Scaling Group, thus forcing the ASG to pick up the new configuration and run the UserData again.

This may case a disruption and make the application unavailable as shown below.

New instances are created by the ASG and the service will become available once again.

3. Stack update behavior with an Update policy

Now, let's examine how an update policy impacts the same deployment.

    UpdatePolicy:
      AutoScalingRollingUpdate:
        MinInstancesInService: '1'
        MaxBatchSize: '1'
        PauseTime: PT12M5S
        WaitOnResourceSignals: true
        SuspendProcesses:
          - HealthCheck
          - ReplaceUnhealthy
          - AZRebalance
          - AlarmNotification
          - ScheduledActions

The SuspendProcesses parameter prevents other process from interfering with the update process. The other parameters have been explained in the first post.

Step 1: Delete the servers stack ./delete.sh servers us-east-1. Wait for completion before proceeding.

Step 2: Create a new servers stack using the servers-with-update-policy.yaml template file ./create.sh servers servers-with-update-policy.yaml servers-params.json us-east-1

Wait for completion and visit the web page using the DNS name of the load balancer.

Observe the Instance ID of the instances as shown here.

This shows Version 1.0 of our deployment.

Step 3: Change the version number in the UserData section of servers-with-update-policy.yaml to 2.0. And update the stack with ./update.sh servers servers-with-update-policy.yaml servers-params.json us-east-1

The images above show the update process of the servers stack. The "Status reason" column is worth noting. It shows:

A rolling update with a batch size of 1, and at least one instance in service during the update.
CloudFormation will wait 12 minutes and 5 secs to receive success signals from the instance before proceeding with the next batch update.

Step 4: Refreshing the page during the update shows switches between Version 1.0 and Version 2.0 until all the instances are replaced with Version 2.0.

The rolling update ensures that the application remains available the entire time as defined in the UpdatePolicy.

4. Clean up the AWS environment.

Finally, remember to clean up the AWS environment by first deleting the servers stack,

and then network stack once the previous stack is deleted.

In conclusion, taking control of the update behavior of your infrastructure using AWS CloudFormation is necessary to ensure a predictable and expected update process at all times.

Thank you for taking the time to read this blog post. If you find the article interesting, do like the article, and comment. Also connect with me on LinkedIn.

Managing Rolling Updates in AWS AutoScaling Groups with AWS CloudFormation Update Policy: Part 1

Olatunde Babawale — Thu, 13 Jul 2023 00:30:55 +0000

Synopsis:
A stack update, sometimes, initiates the desired change; other times, it doesn't.

Wouldn't it be nice to have a predetermined update behavior for the AWS Autoscaling Groups defined in your stacks?

This can be achieved with an UpdatePolicy defined on the AWS Auto Scaling Group in the CloudFormation template.

Read on, to learn more.

This tutorial is divided into two posts: this post focuses on the underlying theory and is suitable for beginners; the second post contains a walkthrough of the update process.

In this post, I highlight the following:

Why the need for an Update Policy?
What is a rolling update?
How to perform a rolling update on an ASG.

Why the need for an Update Policy?
To leverage the benefits provided by the cloud and ensure the agility, flexibility, and continuity of your business, you have implemented Infrastructure as Code (IaC). Thus, guaranteeing that you can document, deploy and update your cloud infrastructure at any time.

You have adopted AWS as your cloud provider and implemented Auto Scaling Groups (ASGs) to make your instances fault-tolerant.

AWS CloudFormation, as the native IaC tool on the AWS cloud, handles the deployment and update of your infrastructure as stacks define in a template.

By default, CloudFormation uses a rolling update deployment strategy whenever the changes to the template initiates a stack update. The problem, though, is that the stack update behavior is determined by the update behavior of the changed attribute of the resource. This behavior could be Update With No Interruption, Update with Some Interruption, and Replacement.

In other words, a change to the Launch Configuration or Launch Template of the Auto Scaling Group(ASG) may or may not take immediate effect. A deployment strategy ensures that we determine how and when the changes are made.

One such strategy is a rolling deployment.

What is a Rolling Update?
A rolling update allows you to update your ASG instances in batches: gradually replacing a certain number of instances at a time while ensuring that the desired capacity of the group is maintained.

In other words, a rolling update keeps some instances (with the previous configuration) online, and gradually rolls out replacement instances with the latest configuration. This guarantees that the application remains available during the entire process.

How to perform a rolling update on an ASG.
To perform a rolling update on an Auto Scaling group using CloudFormation, you can use the UpdatePolicy attribute in the ASG resource.

Here's an example CloudFormation template snippet that demonstrates the rolling update configuration:

Resources:
  MyASG:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      # Define your ASG properties here

      UpdatePolicy:
        AutoScalingRollingUpdate:
          MinInstancesInService: 1
          MaxBatchSize: 2
          PauseTime: PT5M
          WaitOnResourceSignals: true

In this example, the UpdatePolicy attribute is set to AutoScalingRollingUpdate, which enables the rolling update behavior. The following parameters are specified:

MinInstancesInService: Specifies the minimum number of instances that must remain in service during the update process. In this case, we have set it to 1, so there will always be at least one instance running during the update.
MaxBatchSize: Specifies the maximum number of instances that can be updated simultaneously. In this case, we have set it to 2, meaning that up to two instances can be replaced at a time.
PauseTime: Specifies the time to pause between updating each batch of instances. In this example, it's set to 5 minutes (PT5M).
WaitOnResourceSignals: Specifies whether the update process waits for signals from the instances before proceeding to the next batch. If set to true, CloudFormation waits for the instances to signal success before updating the next batch.

By configuring the UpdatePolicy in this way, CloudFormation will perform a rolling update on the Auto Scaling group when changes are made to the ASG resource definition in the CloudFormation stack. This ensures that the update process is smooth and that the desired capacity of the ASG is maintained throughout the update.

Important note about the WaitOnResourceSignals attribute:

It helps to guarantee that the update proceeds only after the new instances have successfully installed and configured the requisite applications.

cfn-signal is required to send signals from the instances to CloudFormation.

To wrap up, a smooth update of your Auto Scaling Groups can be guaranteed by specifying an UpdatePolicy in the ASG resource definition and by setting the WaitOnResourceSignals attribute to true.

Thank you for taking the time to read this blog post. If you find the article interesting, do like the article and connect with me on LinkedIn.

Getting started with AWS Cloud9

Olatunde Babawale — Mon, 23 Jan 2023 21:43:26 +0000

How do you maintain agility across several development projects with varied environment setup requirements? How do you learn and get hands-on with a new tool when you cannot install tools locally on your machine, either because you lack admin rights, the workstation cannot handle the added workload, or you simply don't want to?

Do you want to easily create and destroy environments as needed in minutes? AWS Cloud9 provides the solution to these challenges.

AWS Cloud9 is a powerful, cloud-based integrated development environment (IDE) that makes it easy for developers to write, run, and debug code in a web browser. With Cloud9, you can easily set up a development environment for your project, no matter what programming language you are using.

In this blog post, I'll walk you through the steps to get started with AWS Cloud9.

Step 1: Create an AWS account
The first step to getting started with Cloud9 is to create an AWS account. If you already have an AWS account, you can skip this step. If not, you can sign up for a free account on the AWS website. Follow this how-to guide to get started.

Step 2: Create an environment
Once you have an AWS account, log in to the AWS Management Console and navigate to the Cloud9 service page. Click the "Create environment" button to create a new environment for your project. Give your environment a name and choose the settings that best suit your needs. You may create a new EC2 instance or use an existing one.

The instance type determines the capacity of the underlying EC2 instance in terms of vCPU and RAM. Select from the recommended list or access the list of additional instance types.
The Platform dictates the OS installed on the EC2 instance. There is also a default timeout of 30 minutes that helps to minimize the cost of running the EC2 instance.

For the Network settings, you may select the AWS System Manager (SSM) option or the Secure Shell (SSH) option to assess the instance. SSH requires inbound ports, while SSM does not.

AWS handles automatic creation of the IAM roles and instance profile required based on your chosen configuration.
Click on Create, and you have a rich IDE created for you in minutes.

Step 3: Do your thing: AKA Start coding
Once your environment is created, you'll be taken to the IDE. Here, you can start writing code, running commands, and using the various tools provided by Cloud9. The IDE includes features such as code completion, debugging, and collaboration tools. You can also use the terminal in the IDE to run commands and interact with the underlying EC2 instance.

Step 4: Invite collaborators
Cloud9 also allows you to invite other members to join your environment and collaborate with them. To invite someone to your environment, go to the "Share" button in the top right corner of the IDE and enter or create the IAM user(s) you wish to invite, and set permissions for the users.

Step 5: Terminate environment
Once you are done with your development, you can stop your environment to save cost, and relaunch as needed. In any case, AWS hibernates the EC2 instance if idle for the selected timeout. Finally, terminate the environment.

To wrap up, even though the AWS console may change, this blogpost captures the general overview of getting up and running with AWS Cloud9: easily set up a cloud-based IDE development environment for your project, no matter what programming language you're using, and stop or terminate the environment whenever you please.

Thank you for taking the time to read this blog post. If you find the article interesting, do like the article and connect with me on LinkedIn.