Howto Update The Configuration Script AMI
If you followed the multi-part blog detailed here, you will have a highly scalable and fault-tolerant working infrastructure behind ELB and Autoscaling. How do you manage the Configuration Script AMI of the fleet of Instances deployed? For example, when you make changes to one web-tier instance, how do you reflect the changes across the fleet of instances being managed?
Below, let us discuss 2 methods (Manually and Automatically) that you can use to keep your infrastructure working smoothly and consistently.
Method 1: Manually Maintain a Configuration Script AMI
In this previous blog, you see that the Configuration script AMI was created from a prepared web-tier instance and that AMI was used to create the configuration script for autoscaling. Essentially, each time autoscaling calls an up-scale policy to increase the number of instances, the Configuration script AMI will be used to create the new instances that will join the existing instance pool. That is why there was an emphasis on making sure that the instances remain stateless while keeping all the states in a centralized location. In this way, there is no difference between the new and the old instances. The following are some of the states to be stored in a centralized location:
- All images (like thumbnails) to your website should be deployed to Amazon S3. This will not only make your site scalable, the images and hence your site might also load faster than storing them locally. For a WordPress blog, you can easily manage your S3 environment by installing this 2 plugins: Amazon Web Services and Amazon-s3-and-cloudfront. With the 2 plugins, after configuring WordPress with your AWS IAM keys you can move your entire WordPress media to S3.
- You should use RDS for the database so that when an instance starts, it gets its state from RDS so data is consistent with the rest of the instances.
In a typical WordPress site, the only thing stored locally are just the applications and their configuration files e.g Apache server, WordPress and its themes and plugins and any other application required. Each time you make changes to your instance’s configuration files or install any new plugins or install an application, it would be best to do the following 3 steps:
Step 1: Manually create a new Configuration script AMI as detailed here and replace previous image with new one just created. Note that once you delete the AMI and create a new one, you will get a new AMI ID. If this is a concern, then of course don’t use method 1 being discussed.
Step 2: Manually create a new Configuration script as detailed here, to include the new image you just created as you cannot modify a configuration script once created.
This is what AWS has to say regarding Configuration script:
A launch configuration is a template that an Auto Scaling group uses to launch EC2 instances. When you create a launch configuration, you specify information for the instances such as the ID of the Amazon Machine Image (AMI), the instance type, a key pair, one or more security groups, and a block device mapping. If you’ve launched an EC2 instance before, you specified the same information in order to launch the instance.
When you create an Auto Scaling group, you must specify a launch configuration. You can specify your launch configuration with multiple Auto Scaling groups. However, you can only specify one launch configuration for an Auto Scaling group at a time, and you can’t modify a launch configuration after you’ve created it. Therefore, if you want to change the launch configuration for your Auto Scaling group, you must create a launch configuration and then update your Auto Scaling group with the new launch configuration. When you change the launch configuration for your Auto Scaling group, any new instances are launched using the new configuration parameters, but existing instances are not affected.
Step 3: Kill all the other instances except the one you just modified and Austoscaling will spun new instances with the new image to maintain the required number of instances in your Autoscaling Group.
Method 2: Automate Configuration Script AMI with DevOps Tools
If you have a large number of instances behind ELB and Autoscaling, deleting all the existing instances each time you update the image may be tedious to manage. In this case, method 2 may be more suitable. Here, you want to ensure that you employ DevOps practices and DevOps tools such as configuration management tools. For example you may configure puppet or Ansible locally in an EC2 Instance and use that for managing your fleet of instances. In this method, you manage all the changes to your AMI in a designated master instance, controlled by puppet/Ansible and have all the other instances in the fleet connect to the master instance for update using a Puppet/Ansible agent. Whenever there is a change in the master instance, the changes will be pushed to all the instances in the fleet.
This method is neat as you don’t have to create a new Configuration script AMI each time you make changes as in method 1. Instead, you must ensure that you have your puppet/Ansible agent installed in your base AMI. Remember that for Puppet/Ansible, you will have to manage the infrastructure yourself but if you wanted to use Chef, you can use AWS OpsWorks which is the managed Chef service that AWS provides for you. It’s best to use some sort of DevOps tool when managing large number of instances on the AWS so this method ties in with AWS best practices.
In addition to using Configuration management tools discussed above, if you created your ELB+Autoscaling infrastructure with AWS Cloudformation, you could also made the changes using UpdatePolicy feature of the AWS::AutoScaling::AutoScalingGroup in Cloudformation. This will automatically manage the cycling of the instances whenever the cloud formation stack is updated.
Finally, a tool being used by so many reputable firms including AWS and Netflix, among others, is spinnaker. Am yet to explore this tool but it looks like it can handle the management of Instance updates, creation of new image and a new configuration script and connecting to Austocaling group automatically.
This blog is somehow related to this multi-part series tutorials. Here, the emphasis is on how to manage updates to the AMI and reflect changes across the fleet of instances whenever changes are made. This is important because changes to applications installed and their configuration files are always ongoing and this need to be reflected across all the fleet of EC2 instances managed by autoscaling. Both methods discussed above will work but for large deploymenst, method 2 might be preferred, especially if you have knowledge of using the configuration management tools such as Puppet/Chef/Ansibles.
Comment below if you have another way of managing/updating the image associated with Austocaling groups through the configuration script.