Part 1 2 3 4

Tomcat on EC2

A couple of us recently attended a great seminar put on by the folks at SpringSource. They discussed some great strategies for large scale deployment of TC in a sensible and extensible fashion into productions environments. The approach works as well in our dev sandboxes as it does in production, so I’ll be following some of the best practices learned from the folks who know it best.

What do I have and what do I need?

Depending on the AMI you chose, Tomcat may or may not be installed. Some distributions come with TC installed already.
I suggest that you don’t rely on the distribution version of TC since it may be one that has been modified by the creators of the distribution. Better to just go to the source and get the latest and greatest.

One great thing about using TC is that you just download the version of your choice, unzip/untar it, and you’re essentially off to the races.

Preparation

Similarly, many disty’s come with Java installed and they again can be specific to the disty. I always like to make sure we have the latest Sun Java installed. Feel free to use the version of your choice but your mileage may vary. I’m going to be using the Sun Java6 JDK

Over to the terminal window and do:

apt-get install sun-java6-jdk

It will take a while for all this and the dependencies to all load.  When it’s complete, you can verify the install by doing:

java –version

Download TC

Let’s go to http://tomcat.apache.org There’s plenty of reading there regarding which version does what which we can leave as an exercise. Let’s grab Tomcat 6.x from the left hand side of the page under Downloads. Scroll down the next page and we have some choices:

If you hover over the tar.gz link, you’ll see the path in your browser:

Cool. So back over to our terminal window on our EC2 machine.

We’ll do a wget command to get this version:

wget http://www.devlib.org/apache/tomcat/tomcat-6/v6.0.18/bin/apache-tomcat-6.0.18.tar.gz

When it’s completed:

Install TC

Now that you’ve downloaded it, let’s move it to someplace more permanent and untar it.

I’m using /usr/local/tomcat but you can use the location of your choice. One of the beauties of TC is that it has no requirements regarding where you install it and almost no requirements about where you store the various folders within as we’ll learn later.

mv apache-tomcat-6.0.14.tar.gz /usr/local/tomcat
tar xvzf apache-tomcat-6.0.14.tar.gz

We’ve now downloaded TC and installed it to a permanent location.  Before we go any further, let’s examine what we have and what it all means.

Read the rest of this entry »

Tweet This Post

Part 1 2 3 4

Tomcat Directories and How It Launches

Let’s pop into the tomcat directory and see what we have.

We’ll try to understand what’s in each of the directories listed

/bin
This directory is never used during runtime. It’s sole purpose is to store scripts and boostrap libs.  This directory contains the startup and stop scripts used to launch and kill TC as well as all the scripts it they call

/conf
This directory contains server level versions of the following files:

• context.xml
  • In TC, a context is an application deployed in TC
• tomcat-users.xml
  • Provides access control to applications running on the server
• server.xml
  • Provides all the connectors, ports, engines, virtual hosts configured in the server
• web.xml
  • Following the J2EE spec, this is the config file for the web applications defined at the top server level. It essentially tells the servlet engine what servlets map to which URIs, maps filters, security settings, etc.
• logging.properties
  • Allows you define the logging levels within the server although you’ll probably want to set this up on a per application basis. TC now uses the java.util.logging package for logging instead of the previous log4j as the former was found to be a source of memory leaks on hot swaps
• context.xml
  • A place to provide <Context> snippets. Usually, each application will contain one of these in the META-INF folder so you can control context settings at the application level
• catalina.policy
  • The JVM uses this for security decisions and only if you invoke TC with the –security option
• catalina.properties file
  • • A regular Java properties file sued to set class loader paths, security package lists, and some tunable parameters. One useful feature of it is the ability to set properties that can be referenced in other files.
      EG: # Some Setting
      some.setting=1234
      And in another file such as server.xml
      <Connector port=”${some.setting}”

NOTE: another great feature of TC is that all of these files can exist on a per application basis as well.

/lib
Contains the jars necessary to launch TC. The bootstrap process looks in CATALINA_HOME/lib directory for these jars

/logs
Well, you can only imagine!

/temp
This directory is used by the JVM for temporary files. (java.io.tmpdir)

/work
This is a server level working directory for web applications

/webapps
This is where you place your applications that run within TC.

Understanding the TC Launch Procedure

Typical startup procedure for TC on EC2 machine goes something like this (assuming you’re using bash)

./usr/local/tomcat/bin/startup.sh

By default, this should launch TC on the machine at port 8080. But before you run off and do this, let’s examine the sequence of events that take place when you run this command, the actions that are performed during this launch, and ways to simplify your life in the process.

• startup.sh
  The sole purpose of this file is to locate and call catalina.sh with the start option.
• catalina.sh
  Well, this file does quite a bit. But, the important parts are
  • Invokes the setclasspath.sh script
  • Invokes the setenv.sh script if it exists
  • Launches the JVM (if the JVM is located)
• setclasspath.sh
  TC is a Java application. In order to run, it needs Java installed on the system. This script if responsible for finding the JVM and making sure it’s on the classpath to run and setting up some variables for use by the JVM. The JVM is found by examining the system classpath for the JAVA_HOME variable.  Many tutorials on this subject will tell you make sure you set the JAVA_HOME var in your ~/.bashrc file or even in the startup.sh script. Although these are acceptable, they aren’t the most extensible and flexible approach to use. Which leads us to……
• setenv.sh
  The catalina.sh script looks to see if there’s a setenv.sh file in CATALINA_BASE/bin. If it’s there, it’s executed prior to launching the JVM. This is the perfect place to put all of your environment settings specific to a TC instance.
  Further along, we’ll examine how to set up TC instances in a way that allows you to control and isolate your deployments. The setenv.sh file is a great place to store things like your JAVA_HOME variable. This allows you to switch between, let’s say, 1.5 and 1.6 and if you find there are issues in the latter, you simple switch back as needed.

  The setenv.sh file doesn’t exist in the basic install. Simple create one and put all of your environment setting export lines in it. When it’s time to upgrade TC, simply copy it over. Quite slick!

Tweet This Post

Part 1 2 3 4

Putting it All Together

So, based on the brilliant approach presented by Filip Hanik at SpringSource, let’s build a directory layout and a script or two that will make deployment, management, version control, and resource management intuitive.
An interesting aspect to Filip’s presentation was that he proposed having a TC instance per application. This allows for isolation of your applications in a way that doesn’t allow performance or memory issues of one application to affect other applications. This does present more management overhead and certainly once things are clearly stable, they could be deployed in a combined environment but it was an approach I hadn’t thought of.

The directory structure

• /usr/local/tomcat/apache-tomcat-6.0.18/
  This will be the basic TC install for a given version. The run script will be referencing this
• /usr/local/tomcat/run.sh
  The key to it all. This script will take a start|stop|run input as well as instance number(1 or 2 or etc.)
• /usr/local/tomcat/shared/
  This folder will contain shared instance data if you do not provide it at the instance level. So if you want to provide a specific server.xml for a given instance, place it in
  instance/conf/server.xml, otherwise, the one in shared/ will be used.
• /usr/local/tomcat/instance_1/
• /usr/local/tomcat/instance_2/
  …
• /usr/local/tomcat/instance_n/
  These are specific TC instances.

Let’s examine some differences between instances

Instance_1 is running on port 8080 using jdk1.5 and has a connection timeout of 20 seconds and sets the JVM heap to 512m max and 192k per thread.

/usr/local/tomcat/instance_1/bin/setenv.sh
JAVA_HOME=”/usr/local/java/jdk1.5”
CATALINA_HOME=”/usr/local/apache_tomcat-6.0.18”
CATALINA_BASE=”/usr/local/tomcat/instance_1”
CATALINA_OPTS=”-Xmx512m –Xss192k”

/conf/catalina.properties
http.port=8080

/conf/server.xml
<Connector port=”${http.port}”
protocol=”HTTP/1.1”
connectionTimeout=”20000”  />

Instance_3 is running on port 8081 and is using jdk1.5 and has a connection timeout of 60 seconds

/usr/local/tomcat/instance_3/bin/setenv.sh
JAVA_HOME=”/usr/local/java/jdk1.6”
CATALINA_HOME=”/usr/local/apache_tomcat-6.0.18”
CATALINA_BASE=”/usr/local/tomcat/instance_3”

/conf/catalina.properties
http.port=8081

/conf/server.xml
<Connector port=”${http.port}”
protocol=”HTTP/1.1”
connectionTImeout=”60000”  />

You can hopefully see the beauty and the benefits of an approach like this. You can isolate instances, JVMs, applications, configurations. Or, you can share various pieces and isolate others.

If the Tomcat Seminar by SpringSource is coming to your town, it’s a great presentation for short money.

Tweet This Post

Part 1 2 3 4

Making Sure You Can Access Everything…all the time

So, we’ve come pretty far. We’ve learned what pieces were needed to install TC on our EC2 server. We’ve learned some sensible steps in configuring your deployment environment so that you can run multiple instances of TC in a sensible manner.

All we have left to do is make sure we can access TC via the web and ensure that the server comes back up after a re-boot (if so desired).

Making TC Accessible to the Outside World

Log into your EC2 management console and select the specific instance you have installed TC to. Note the Security Groups that have access to this instance. In order for the world to have access to your instance of TC, you need to enable the port you plan to run it on. In this case, we’ll enable it for the default group.

Navigate to the Security Groups in the console and select the security grouop you want to enable the port for. In this case, we’ll be enabling port 8080 for the default group.

In the Connection Method column, select Custom.

In the Protocol column, select tcp.

In the From Port and To Port columns, enter 8080.

In the Source (IP or Group) column, enter 0.0.0.0/0. This will make it available to the world.

Click the Save button.

Congratulations, you’re console should now be available at http://<url to your instance>:8080.

Getting TC to Survive a Reboot

Linux installs support a mechanism for restarting services via /etc/init.d. In order to create a startup script so that TC survives a reboot and comes back up, use your favorite editor and create a similar file

vi /etc/init.d/tomcat
Paste in the following:
# Tomcat auto-start
#
# description: Auto-starts tomcat
# processname: tomcat
# pidfile: /var/run/tomcat.pid
case $1 in
start)
# uncomment and supply the correct instance for default start
# we’ll only support start for this script
# sh /usr/local/tomcat/run.sh start  <instance number>
;;
stop)
# No need to support this since we’ll use the run.sh stop <instance>
;;
restart)
# Ditto above
;;
esac
exit 0
Make sure the script is executable by:
chmod 755 /etc/init.d/tomcat
And finally, link the script to the startup folders with a symbolic link:
ln –s /etc/init.d/tomcat /etc/rc1.d/K99tomcat
ln –s /etc/init.d/tomcat /etc/rc2.d/S99tomcat

Tweet This Post