Deploying Multiple Tomcat's 6.0 Minimally
Often, there are times on a server you may want to install multiple applications, but you may want to update one of the applications without bringing down the others, so you need to run multiple instances. Not surprisingly, you can do this without having multiple instances of the binaries lying around. This can make it potentially "easier" (to update your tomcat, assuming there aren't any hangups with regards to dependencies/oddities on a version of tomcat.
Setting up multiple tomcats on a single server is pretty straightforward:
First, the base installation of tomcat should only need the following:
+tomcat (home)
|__bin
|__lib - contains server libraries, can be used for shared libraries
Everything else is a customizable piece of tomcat:
+tomcat (base_dir)
|___work - the deployed version of your application
|___temp - for whatever tomcat needs to do on the fly
|__ webapp - your web applications
|___log - the logs for your server
|___conf - configs for the server.
* - not all tomcats seem to have this folder
If you've created the above folder structure somewhere outside of the original tomcat installation, you are pretty much ready to go. Just set a CATALINA_BASE environment variable and you're ready to roll.
Catalina.out troubles
Catalina.out is the catch-all files for console output. (All those who have used System.out.println are familiar with it)
One thing I find a bit annoying about the catalina startup script is that it does not provide a way to change the default name of this file. There's a dozen environment variables, but none to change the console output filename. You can do this yourself by simply searching for catalina.out in your catalina.sh script and replcing it with an environment variable choice.
The other gotcha about this file is that there are no restrictions on it's output length, and it can eat your disk space up complete if you're not careful. A couple of ways to deal with it:
- Setup a cron job to roll it over, compress it, or to delete it daily/weekly
- Symbolic link to /dev/null :) -- naturally, assumes you have no interest in the console output
Customizing logging
Previously, I had talked some about customizing logging. Tomcat doesn't do Log4j, but uses a logging system called JULI. It's configuration files are a little bit different, but you should be able to pare it down without trouble.
Removing Unnecessary Parts
Under the work and webapps directory there's a series of applications that come with tomcat: (examples, manager, host-manager, docs) You can easily get rid of examples and docs, but manager and host-manager are up to you. They can be used by things like Maven to help deploy applications, so you may want to consider keeping them around.
References
- http://lifeofhumanvirus.blogspot.com/2007/03/manually-deploying-new-tomcat-web.html
- http://tomcat.apache.org/tomcat-5.5-doc/logging.html
- http://brondsema.net/blog/index.php/2006/05/25/tomcat_juli_logging_properties
