Clever Geek Handbook

How do I scale Tomcat on an AWS EC2 instance?

A number of questions arise about automatic scaling. But none of this is about the scaling of the software stack installed on these servers. AWS autoscaling only scales resources. Not software on it. In my case, I expect the Tomcat Server (and Apache HTTPD Server) installed on the first instance to be part of the new instance being created by the AWS Scaling Service.

I followed a regular process to set up scaling for my application on EC2 Amazon Web Services instances.

  • Created a snapshot from an existing instance with the exact configurations of the running instance - Success
  • Created an AMI from the above snapshot - Success
  • Created auto scaling group and launch config - Success
  • Scaling policy - create a new instance with CPU> = 65% 2 times. - Success

The above procedure only creates a new instance, it does not copy the software stack present in the image.

How to autoscale so that when AWS autoscales, the Tomcat AMI backend is also copied and run in the new extended instance.

Do I have to use Puppet / Chef or any such tools to achieve this? Or is there an option in AWS using the command line?

Note that the Elastic Load Balancer automatically adds a new instance to it according to the launch configurations, but shows "Out of Service" because Apache is not installed on the new scaled up instance.

+3


source to share


1 answer


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

No, you don't need to use Puppet / Chef or any other CM tool. You can do what you want in several ways:



  • The easiest way is to create an AMI from your EC2 launch and then configure your autoscale group to launch new instances from the AMI based on some metric.
  • Use the base AMI without Apache / Tomcat or your software, then load new instances at startup to load and configure everything you need.

Disadvantage # 1 is that your AMIs get tired quickly. Disadvantage # 2 is that your instances will take longer to get into production. I would recommend a mix of # 1 and # 2, in particular that you grab a new AMI every few months and this will become your base AMI to start up and you update the instance at startup via a custom init script.

+4


source






More articles:


All Articles