如何在AWS EC2实例上扩展Tomcat？

Question

There are a number of questions on auto scaling. But none of it talks about scaling out the software stack installed on these servers. AWS Auto Scaling only scales out the resources. Not the software on it. In my case I am looking forward to scale out the Tomcat Server (and Apache HTTPD Server) installed on the first instance to be part of the new instance that AWS Scaling Service creates.

I followed the regular process to establish scaling for my application on Amazon Web Services EC2 instances.

1. Created a Snapshot from the existing instance with the exact configurations of the running instance - Success
2. Created an AMI from the above snapshot - Success
3. Created an auto scaling group and launch configuration - Success
4. Scaling Policy is to create a new instance upon CPU >= 65% for 2 times. - Success

The above procedure only creates a new instance but it does not copy the Software Stack present on the image.

How do I accomplish auto scaling in such a way that when AWS auto scaling happens, Tomcat server part of the AMI is also copied and started up in the new scaled out instance.

Do I definitely have to use Puppet/Chef or any such tools to achieve this? Or is there an option in AWS using Command Line?

Please note that Elastic Load Balancer automatically adds the new instance on to it as per the launch configurations but it shows 'Out of Service' since there is no Apache server installed on the new scaled up instance.

Answer 1

You create AMIs directly from EC2 instances, not from snapshots. Snapshots are for EBS volumes. Check that you created your AMI correctly from a running EC2 instance on which you have Apache/Tomcat installed and running (and configured to autostart on reboot).

No, you do not have to use Puppet/Chef or any other CM tool. You can do what you want in a couple of ways:

1. The simplest way is to create an AMI from your running EC2 instance and then configure your Auto Scaling Group to launch new instances from that AMI based on some metric.
2. Use a base AMI without Apache/Tomcat or your software and then bootstrap new instances at launch time to download and configure everything needed.

The disadvantage of #1 is that your AMIs will get out of date quickly. The disadvantage of #2 is that your instances will taken longer to come into service. I would recommend a combination of #1 and #2, specifically that you capture a new AMI every few months and that becomes your base AMI for launching and you update the instance at launch time via userdata init script.