In this post I will setup autoscaling for the EC2 WordPress server I created previously. With autoscaling you can tell Amazon to launch or terminate instances based on a set of rules/ conditions. For example if a server has a certain CPU utilization for a certain period you can decide to instantiate an extra instance and put it behind the load balancer so you can spread the load over more machines.
To setup and configure the autoscaling you cannot use the Management Console as this doens’t support it. I will use the command-line interface to set up the autoscaling. To install the command-line tool take the following steps.
- First install the default EC2 API tools as described here
- Next download the autoscaling tool from here
- Unzip the zip file and copy the files in the ‘bin’ and ‘lib’ folders to the corresponding folders in the installation directory of the EC2 API tools.
- Add the environment variable ‘AWS_AUTO_SCALING_HOME’ and let it point to the installation directory of the EC2 API tool. I added the following line to my ‘.bash_profile’ file:
Don’t forget to reload the profile before you continue.
Now we can use the API tool to setup the autoscaling. Before we do that make sure the existing instances are removed from the load balancer and terminated. Now we can start to setup a Launch Configuration. We need the AMI name of our custom image. To get a list of all the AMI’s owned by me enter the command:
ec2-describe-images -o self
Note: If you don’t see the expected result it might be you are looking in the wrong region. To setup the default region to look in with the command-line tools add the following to you r.bash_profile:
One of the resulting lines looks like:
IMAGE ami-96d3dfe2 024658091597/Wordpress Image 024658091597 available private [marketplace: d9ctq8cuo1svb3v0n02ht2m1k] x86_64 machine aki-62695816 ebs paravirtual xen
Now I can create the Launch Config with my ami-id by executing the following command:
as-create-launch-config --image-id ami-96d3dfe2 --instance-type t1.micro -–key 4synergy_palma --group "Wordpress Web Tier" --launch-config wp-config --region eu-west-1
The parameters in this command are as follows:
- Image-id: The AMI name of my personal WordPress AMI
- Instance: Type The virtual hardware we want to run on. I am using t1.micro here
- Key: The keypair that you want to use
- Group: The security group
- Launch-config: The name of this configuration
- Region: The region where the autoscaling group is created. Also used to lookup the AMI (wether the EC2_URL is set or not)
With the launch-config created we can create the Autoscaling Group with the following command:
as-create-auto-scaling-group wp-as-group --availability-zones eu-west-1a, eu-west-1b --launch-configuration wp-config --load-balancers WPLoadBalancer --max-size 3 --min-size 2 --region eu-west-1 --show-xml
This should give a response like:
<CreateAutoScalingGroupResponse xmlns="http://autoscaling.amazonaws.com/doc/2011-01-01/"> <ResponseMetadata> <RequestId>7f8d7f70-573c-11e2-8113-3701f4cd9944</RequestId> </ResponseMetadata> </CreateAutoScalingGroupResponse>
That is it. After a few minutes you will receive mails from the SNS we set up when an instance was booted and you will see two instances in the EC2 Console:
And both instances are registered with our Load Balancer:
You can see the two instances are now running each in a different availability region to maximize the durability. Now if we destroy one of these instances a few moments later a new one will be instantiated. The next test would be to define rulesets and have a performance testing tool like JMeter to perform some load tests. Another interesting item to show is the use of CloudFormation but I save that for another post.