Running Tomcat 7 on EC2

Installing Apache Tomcat 7 on a virtual machine within the Amazon EC2 cloud turned out to be a fairly trivial task. Using the micro instance created in a previous post, I issued the following commands on the Ubuntu command line to install the service:

sudo apt-get install update
sudo apt-get install tomcat7
sudo apt-get install tomcat7-docs
sudo apt-get install tomcat7-examples

In order to bind tomcat to listen on privileged port 80, the following steps were taken:

sudo nano /etc/tomcat7/server.xml
change instances of 8080 to 80, and save file
sudo nano /etc/default/tomcat7
change #AUTHBIND no to #AUTHBIND yes, and save file
sudo service tomcat7 stop
sudo service tomcat7 start

Finally, the Amazon EC2 security group was modified to allow access to port 80.  After these steps, bringing up a browser and accessing http://amazon-dynamic-server-name/docs successfully brought up the Tomcat 7 documentation.

I'm not sure why I was surprised, but I did discover that restarting an EC2 instance resulted in the instance obtaining a new DNS name and IP address.  The next time I work on a server, I need to remember to assign an Elastic IP address to the micro instance (in order to be able to save a PUTTY connection in my profile).

Creating an Environment Script for EC2 tools

With a basic understanding of Amazon EC2 under my belt, I continued with my workstation build-out by creating an environment script for the EC2 command line tools.  Nothing to Earth shattering here; the majority of time involved was mostly just researching variables that needed to be set.

@echo off
set EC2_HOME=C:\Users\chris\Dev\apps\ec2-api-tools-1-6-7-2
set EC2_PRIVATE_KEY=C:\Users\chris\Dev\bin\identity\pk-xxxx.pem
set EC2_CERT=C:\Users\chris\Dev\bin\identity\cert-xxxx.pem
REM default to avoid using --region parameter everywhere from command line
set EC2_URL=https://ec2.us-east-1.amazonaws.com
set PATH=.\;%EC2_HOME%\bin;%PATH%
echo ** ENVIRONMENT SET FOR AMAZON EC2 1.6.7.2

Java settings are not required because I have those covered in another script.  The script was entered, saved in my local dev\bin directory, and worked without issue.

Launching Amazon EC2 Instances

Before continuing with development, I tested out my new Amazon AWS account by launching both a Linux and Windows micro instance.  From start to finish, each took about 10-15 minutes (including the launch wizard, waiting for the instance to spin up, logging in, and finally termination).  Amazon has instructions posted online, but the wizard is fairly idiot-proof.  The only thought process involved is in connecting to the instance, and even that has been made fairly simple.

The Linux micro instance was the first to get launched.  Starting from the Amazon console, I switched into the EC2 dashboard.  It wasn't until I was over half way through the process that I realized I was defaulting to the US West (Oregon) region; I'll need to make note of that for the future (the instance responsiveness was fine even though I'm sitting on the opposite coast).  The Amazon provided documentation was adequate to get up and running.  I stepped through the New Instance wizard, and selected an Ubuntu distribution:

I accepted the defaults, with the following exceptions:

For this one I did keep the defaults, however, making a note to visit the URL above to figure out what this instance tagging is used/good for.

For the firewall configuration, I created a new rule to allow SSH only (this canned group should be ready for re-use next time).

After completing the wizard, the new Linux server started up in about 5-10 minutes:

I right-clicked the instance and attempted the Connect option.  This worked as well as could be expected for a terminal window run through a browser.  It was functional, but just no substitute for PUTTY.  The only catch to connecting through PUTTY is to remember to populate your security keys (which I had previously converted to *.ppk format) within SSH | Auth.  Once PUTTY connected, I used the username "ubuntu" and logged in without issue (or password, keys are clearly working).

Finally I exited the PUTTY session and terminated the instance.  From the same right-click menu in EC2:

choose terminate and wait until the console reflects the destruction of the instance.  I'm not entirely sure of the full scope of differences between terminate and stop, although did find this documentation that I'll need to go through at a later date.

The Windows 2008R2 micro instance performed just as smoothly.  The official amazon documentation was again comprehensive for a beginner, and the only significant difference in the startup wizard (vice Linux) was specifying 3389/RDP as the firewall configuration setting.

Logging in was indeed different, using Remote Desktop vice PUTTY.  The process begins with right-clicking the instance and retrieving the password:

and then decrypting the password with the *.pem key pair.  With an administrator username and password now in hand, I logged in using the standard Remote Desktop Connection tool which ships with Windows 8.  I completed this test by terminating the Windows instance.

I did not perform a shutdown from within Windows before terminating (because as I understand it, terminating effectively destroys the instance, so who cares if it shuts down cleanly), but will need to revisit that in the future as instances are created that I care about.

As a final step, I used the Amazon console and jumped to the Account Activity report, just to verify that all the compute time was included in the free trial (and I didn't launch the wrong instances).

Overall, things could not have been easier.  Now all I need to do is come up with a sample application to build and deploy, just to exercise the environment a little more thoroughly.

Creating Amazon AWS Security Credentials

Before continuing with a development environment setup, a set of security credentials were first created using the Amazon AWS Console.  From the user menu in the toolbar, select the Security Credentials option.

There are options for generating various types of identity credentials:

Not really knowing what I will need first (and ignoring the basic security tenet of only generating what you need when you need it), I generated credentials in all three categories, and saved them off to a safe place.  Finally, I used the PUTTYGEN tool to convert the Key Pair into something that will work with the PUTTY suite of tools.  Its a fairly simple matter to import the *.pem file you created and convert it to a PUTTY-friendly *.ppk file (also saved off to a safe place).

Now equipped with an account and a plethora of security credentials, I think I have the bare minimum requirements in place for moving forward.

Creating a new Amazon AWS Account

Continuing along with my journey into the cloud, I spent 10 minutes creating a new Amazon AWS account.  I started with a link for Try Cloud Computing Free and pressed the easy button:

If you've ever created an account, well anywhere, this process should be fairly old hat.  Even though you are signing up for a free trial account, you do need to provide a credit card (in case you go over the free limits).  There was one additional step which was unusual: confirming your phone number.  Amazon generates a one-time PIN and calls your number from an automated system to verify you - after punching in the PIN, you continue on your merry way:

A few minutes later I received the "all done" email:

and my account setup was complete.  A quick trip to Amazon AWS and I logged in to the account console without issue:

Now that I have an account and EC2 tools installed locally, my next steps will be getting a local build environment up and running.  To be continued...

Downloading the Amazon EC2 Tools

We at Spare Time Notebook have been sleeping on this cloud thing for far too long; not ignoring it per se, just, well, not really needing it.  With the cost of hardware dropping through the floor as of late, its hard to let go of old habits (just buy another box) and embrace the new world.

Those lazy habits end today, as I delve into Amazon's EC2 offering.  I'll be documenting my progress/lessons learned as I go, and since time is tight, will be posting my education in pieces.

Today's effort is about as basic as possible - getting the tools loaded on my development workstation (who knows, maybe someday the math will work and my local workstation will be retired, and instead live in the cloud, only to be spawned when needed).  After a query to the friendly neighborhood google, I had an official link for Setting Up the Amazon EC2 Command Line Interface Tools.  This set of directions had a link to the latest download distribution (currently 1.6.7.2):

The download is fairly small (14meg), and was unzipped into my tools directory like any other java distribution:

I'll spend some time researching the task of building an appropriate command line environment and establishing proper credentials to the Amazon infrastructure and post again after I know what I should be doing.

How to modify MAX_ALLOWED_PACKET in MySQL

While working with BLOB/CLOB fields in MySQL, it won't take long to encounter the following issue during a DML statement:

Packets larger than max_allowed_packet are not allowed.

Using the following command:

SHOW VARIABLES LIKE ‘max_allowed_packet’;

You can see that the networking parameter MAX_ALLOWED_PACKET defaults to 1048576 (1MB).  Since a 1MB BLOB file is fairly paltry, the parameter must be updated to a more reasonable value.  Logged in as root (or similarly admin'ed user), issue the following command to modify the parameter:

SET GLOBAL max_allowed_packet = 16 * 1024 * 1024;

GLOBAL refers to the sessions which are effected by the call; meaning that all sessions will now honor the new 16MB limit.  However, there is a catch.  At this point, the change is not persistent (see notes that this is not a bug).  A recycle of the service will reset the value back to the original 1MB setting.

To permanently change the value, the my.ini configuration file must be altered;  mileage may vary on the location of said file (install location, OS, etc., etc.), but in my case, the file lives in C:\Users\chris\Development\mysql\my.ini.  Find the mysqld section, and add a line for the setting:

[mysqld]
# ADDED BY CHRIS ON 20 APRIL 2013
max_allowed_packet=16M

Save the file and restart the MySQL service.  The value should now be permanent.