Configuring servers is tedious work if you operate a cluster of more than a few machines (if you're a regular reader, you've heard about it). I've created a simple deployment framework that helps with building deployment packages based on central configuration templates. It is ant-based, so people from the Java world should have no problem to adjust it to their needs. Read on to find out how it works.
The Server Deployment Framework (SDF)
Based on a server template, a bit of configuration and your application, this little framework creates a self-contained deployment package ready for installation. The package contains both the server itself and the application, so you always start from a clean slate. There's no cruft left between installations.
With SDF, there's a separation of responsibilities between developers and admins. Developers provide the application in a .war file. The .war file has no environment-specific configuration. Admins are responsible for configuring the application for the target environment. The general ideas is that the same application artifact that is handed to the QA department is also installed on the production systems.
This is how it works:
- Create a server template in the src directory. Replace important configuration values with wildcards. Rename all files containing wildcards to filename.in (think autoconf).
- Place your web applications in the base directory's webapps directory.
- Create/edit the environment configuration in the conf directory, ie. ENV-NAME.properties.
- Run ant package -Dapp.environment=ENV-NAME.
- You'll find your pre-configured deployment package in the target directory.
Repeat steps 2-5 any time you want to make a new release.
The Bundled Tomcat
A few words on the bundled Tomcat instance: It is for illustration only and hasn't been configured for production use. There are a couple of interesting ideas though.
All ports settings have a @PORT_PREFIX@ wildcard. That way you can run multiple Tomcat instances on one host by changing the prefix parameter. This is useful for rollouts: You can start up and check the new revision while the old one is still running. Using loadbalancer settings, you can switch over to the new application and later shut down the old revision.
In conf/context.xml, an example context parameter has been set. This is a simple way of passing environment-specific parameters to your application without having to change anything inside the .war file.
As a general rule, it's a good idea to run just one web application per Tomcat instance. This way, it's easier to figure out which application is misbehaving. In large operations with high performance requirements, this is the normal case anyway. When you follow the single application rule, you can as well turn off hot deployment.
Since applications tend to crash sometimes (OutOfMemory exceptions happen to the best of us), it makes sense to restart the server automatically without admin intervention. One easy solution to do this is to run Tomcat inside a JavaServiceWrapper that makes sure your JVM is in a healthy state. Remote restarts and easy JMX access are helpful additional features.