AWS introduced autoscaling to make EC2 cluster scaling easier. We've seen users constantly make changes to their EC2s and put new policies into play. It’s important to update your Autoscaling group with the new instances so that it doesn’t ignore these machines. AMI updates keep the AutoScaling Groups aware of the changes in instances. When you add new code to your EC2 instance and you need to make sure your existing instances and new instances are both using it, you’ll need an AMI update. There are two means of achieving this.
Most people would prefer it if the AutoScaling Groups automate the update when a new AMI is launched. Currently, DevOps engineers spend time writing Lambda functions to achieve this.
Current steps include:
The Lambda function will handle instance termination and launch will update the AMI and patch it onto the ASG.
With automation becoming the forefront of cloud management, we’ve seen a number of users request this use case or template. Scripting just remains time-consuming, especially when dealing with repetitive tasks that contribute to operational governance.
Now, workflows can reproduce the result without the time constraints brought up when setting up the lambda function and automation document. Using a visual interface, you can perform the AMI creation, template launch, and autoscale update together - with a single workflow.
You can also integrate Jenkins and other CI/CD software with the workflows so you won’t have to write your automation scripts. Improve the customization capabilities with further integrations. You can update the AMIs based on the different integrations and then in turn update the autoscaling group afterward.
Let’s say you have a development pipeline and during your iterations, you add additional EC2 machines for higher CPU performance. With our workflow integrations, you can automatically update the autoscaling to include the new machines with new AMIs, keeping your development pipeline uninterrupted.
Process
The workflow replicates the entire process of updating your Autoscaling Groups, in a way it mimics human actions. The trigger runs every day to check for updated instances. The nodes, then launch the autoscaling template with the new AMI. The autoscaling group updates the new and existing instances with the new AMI. Afterward, the old EC2 instances are terminated.
Step 1: Trigger
Runs every day and launches based on the changes to the instances.
Step 2: Auto Scaling Group
Loads the autoscaling group.
Step 3: Filter
Filter out the updated instances by tag.
Step 4: Resources
Loads the instances of the auto-scaling group.
Step 5: Filter
Compares the instances of the trigger with the instances of the auto scaling group to determine which requires the creation of AMI.
Step 6: Create AMI
Step 7: Launch Template
Launches the template based on created image with the auto scaling group.
Step 8 : Update Auto Scaling Group.
Conclusion
Many other use cases can be translated similarly to our workflows. It’s a matter of combining the resources accurately. The building blocks that we’ve laid out with our platform can be used in any number of ways with zero coding. If you have a resource you wish to simplify, try to use our workflows to your advantage.