<< Low Fett | Home | Arme sollen sich Zubrot durch Rattenjagd verdienen? >>

Tomcat Deployment Checklist

what to do when deploying a new tomcat installation

For years I've been working with tomcat, developing, setting up preproduction and production servers and monitoring them. Some of the habits seem worth publishing - even to provide a checklist for myself.

This is the reason for me to provide a simple checklist and some reasoning here in order to just refer to this article. If you are not (currently) interested in tomcat deployment you wouldn't want to read it (now) - otherwise, please comment if I forgot something or if some details are missing.

Basic Installation

I'm usually deploying tomcat on linux machines, therefor windows users have to change *.sh file names to *.bat and change directory separators as necessary.

As Java is finally well supported by the linux distros, I'm tending to more and more go with the OS-inherent Java-installation instead of installing it myself.

For historical reasons I'm always running with the latest version from http://tomcat.apache.org/ and take care of the updates myself. I don't like the way the linux distros that I've used distribute tomcat all over the file system. For me this makes it hard to identify where to look for when I need to change anything, but it also causes the following first configuration step:

Configuration

Never run tomcat as root

The first important step for me is to identify a user account that tomcat should run as. I frequently need tomcat-served content to be available on port 80, but resist running tomcat as root. I know that it is possible (at least through some extra packages or e.g. in Solaris) to grant non-root applications to bind to port 80, but I usually setup Apache to run on port 80 and use mod_jk for serving tomcat content.

Make some directories writeable by the tomcat user

As tomcat is not running as root, the next step is to make sure that the process can write to all files and directories that it needs to write to. These are the directories webapp, logs, work and temp. Some tomcat applications like to be able to write to conf (e.g. conf/tomcat-users.xml or conf/Catalina/localhost/webappname.xml). If you really need this feature (e.g. if tomcat updates these files , make the files writeable to the tomcat user also, otherwise they should be just readable. Remember to apply this recursively, e.g. chown -R tomcat:tomcat temp logs webapps work; chmod -R u+w temp logs webapps work. (see a later section for the need to access these directories in production environment)

Setup tomcats runtime parameters (e.g. memory)

The next step is to prepare tomcats runtime parameters. Numerous forum posts tell you to customize tomcats startup script to set the environment variable JAVA_OPTS. You shouldn't do that to your startup script, but set this value in another file that's easily to move to an upgraded tomcat, bin/setenv.sh. This file does not exist in the standard download. But once you create it, it's read during the startup process. There you may set all options you need, e.g. the maximum memory tomcat shall be allowed to allocate. On Windows, if you need tomcat running as a service in the background, you'll need the help of tomcat6w.exe to set the parameters you'd set in this file on Linux. If you run it as console process, setenv.bat will also do the work.

#!/bin/sh
# adjust these values to your applications requirements
export JAVA_OPTS="-Xmx1024M -XX:MaxPermSize=256M"
export JAVA_HOME=/path/to/java/if/you/need/to/set/it
# add any other environment entry or command you need for your applications

Windows-users may use this file if tomcat is started from the command line. When tomcat is run as a service, you should use bin/tomcat6w.exe for service settings.

Decide about Auto-Deployment

With Auto-Deployment you'll have to decide what you like. I remember the tomcat folks discouraging auto-deployment for applications in production environments. More often than not I've used auto-deployment even on production systems, mostly because they were low traffic low impact sites where one tomcat hosted multiple applications that needed to be upgraded every now and then. You may configure this in conf/server.xml. Look for the parameter autoDeploy to the Host element. (Disabling autodeploy will result in less write permissions for some directories configured earlier).

Deploy your application(s)

Setup the application(s) you need by either configuring them in conf/server.xml (discouraged), conf/Catalina/localhost/webappname.xml (if your server.xml Engine and Host are named Catalina and localhost) etc. If you need additional libraries in tomcats common/lib or server/lib directory (or as of tomcat 6 the lib directory), do so by linking them into this directory. This makes them stand out from the files that tomcat places there and upgrades are a lot easier. Make sure that the user account tomcat runs as has read access to the files. (This section applies for database drivers etc., whatever your applications need)

My preferred method of deployment is to place the webapplication in a directory other than tomcats webapps and referring to this directory in the context definition file like this example for conf/Catalina/localhost/myApplication.xml:

<Context path="/myApplication" docBase="/path/to/my/application" ......>
... more configuration for the application ...
</Context>

Setup mod_jk

Configure Apaches mod_jk to connect to tomcat. The configuration of this module currently is beyond the scope of this post. There are numerous examples available on the web.

Optionally setup a firewall

If you are running tomcat on an internet server without a dedicated firewall (e.g. a "root server" as they are called in Germany) it's a good idea to run a local firewall that blocks internet access to tomcat. The only client you want tomcat to answer to is your local Apaches mod_jk. That means port 80 is served by Apache (and should be available through your firewall). Tomcats standard ports, e.g. 8080 and 8009, should not be accessible from the internet.

Prepare tomcat to start automatically after reboot

Last, make sure that tomcat is started automatically in the runlevel that your computer starts (if you need it to). Place a file like this in your /etc/init.d/..... directory:

# Tomcat auto-start
#
# description: Auto-starts tomcat
# processname: tomcat

export JAVA_HOME=/usr/lib/jvm/java-6-sun
cd /opt/tomcat
chown -R tomcat webapps conf temp logs work

case $1 in
start)
sudo -u tomcat /opt/tomcat/bin/startup.sh
;;
stop)
sudo -u tomcat /opt/tomcat/bin/shutdown.sh
;;
restart)
sudo -u tomcat /opt/tomcat/bin/shutdown.sh
sudo -u tomcat /opt/tomcat/bin/startup.sh
;;
esac
exit 0

With this file you may start tomcat automatically immediately after a reboot (see your distro documentation how to configure this). Voila, that's the basic setup.

Monitor your installation & optional steps

Now "all" you have to do is monitor your installation and fine tune if necessary. Some options for tuning you server configuration (but definitely incomplete) as well as other topics you might want to consider:

  • number of concurrently accepted connections (either by apache or tomcat)
  • number of concurrently maintained database connections
  • encryption (https) (because I use mod_jk, I'm leaving the encryption task to Apache, Tomcat and Apache are usually communicating in cleartext.
  • I'm usually not installing tomcats manager or admin application - I'm fine editing all config files manually. You might consider one of these applications. Choose your password wisely and/or limit access to known IP addresses through https connections!
  • log file rotation, log levels (beware of those gigabytes...)
  • software updates (subscribe to mailing lists of all the software you use - preferably security oriented lists)
  • Backup your installation. Frequently.

You're done

Have fun and let me know if I forgot something or got it wrong...




Kommentar hinzufügen Trackback senden