Enterprise Apache Tomcat Admin Solutions
If you're reading this article, you're probably already sold on Apache Tomcat as your web application server solution. Lightweight, powerful, secure, and above all, open-source - Tomcat is easy to love. In fact, it's so easy to love that many administrators of large-scale enterprise architectures who might have gone with legacy stack-based solutions in the past are replacing them with light, flexible Tomcat architectures.
It's in these kind of situations where we run into administration problems. Enterprise-level infrastructures require enterprise-level monitoring and Tomcat configuration power, and this is where the flexible, lightweight, no-bloat approach that makes Tomcat so appealing to developers becomes an issue for administrators. In other words, it is not uncommon for some tension to develop between Tomcat's lightweight build and the needs of enterprise organizations.
It's not that Tomcat can't handle the job - far from it. Tomcat is still one of the best choices around for a wide variety of situations. However, in order to offer this high level of flexibility, some out-of-the-box functionality needs to be sacrificed.
In the end, this is a good thing, because once you've gotten an administrative solution working, you won't be stuck using (or paying for) hard-coded tools that aren't quite what you need. But when you're sitting at your desk with no solution and no time, the gap between you and this administrative promised land can look a little daunting.
This is a simple guide to help you get a head start on leaving your administrative problems behind. First, we'll take a look at the basic administration tools included with Tomcat. Next, we'll explore some other administrative options, including custom JMX systems and scripting. Lastly, we'll take a look at agent layer solutions such as Tcat, a powerful, lightweight, web-based administration tool, built on Tomcat, that provides deep administrative functionality right out of the box.
Before looking elsewhere for administrative options, let's take a look at the tooling bundled with every Tomcat installation.
In Tomcat 6.x and higher, the only graphical administrative tool provided is the Manager web application. This tool is primarily for quickly altering the deployment of a web application without restarting its entire container, but also provides some additional information about the server internals. You can use this tool in one (or more) of 3 ways:
1. URI Command Access - the Manager can receive commands in URI format and return parseable responses. This feature exposes Manager's functionality for custom administrative scripting; the output is designed to be easily read by a program, not by a human. Manager also includes a lightweight servlet called JMXProxy, which can be enabled if you want to set internal Tomcat settings using JMX queries and commands formatted as URI strings for integration into your other scripts.
2. HTML Console Access - a locally accessible web console that allows control over deployment and termination of web applications, information about various JVM and OS values.
3. ANT Automation - one quite powerful and handy way to use Manager is as a neat bundle of task definitions for Ant automation, a trick that can turn Manager into a useful gap-filler in your administrative toolkit.
For an easy-to-understand guide to enabling and configuring the Manager application, and more in-depth information on how to implement all three of these use scenarios, pay a visit to our Tomcat Manager guide.
The Tomcat Admin Web app
Tomcat versions 4.1.x through Tomcat 5.5 also included a GUI console called Tomcat Administration Tool, or "admintool," which allowed (rather poorly implemented) web-based editing of some of Tomcat's XML configuration files.
As of Tomcat 6.x, this tool is no longer supported. There was talk of Tomcat 7 including a re-factored version of the tool early in the development process, but the project has since been abandoned. For this and other reasons (destructive editing, discarding of XML spacing and comments, and unnecessarily verbose output, to name a few), this guide will not cover usage or configuration of this tool.
Custom-Built Administrative Solutions
As you can see, Tomcat's out-of-the-box administrative functionality is quite limited, and it's no wonder that most administrators find it necessary to implement some kind of supplementary solution. One way this problem is commonly tackled is by creating custom toolkits of scripts and monitoring tools. Here's a look at two popular methods of implementing this kind of system, and the pros and cons of taking this approach.
JMX stands for Java Management Extensions, a flexible Java technology that allows for remote administration of various resources, referred to as Managed Beans, or MBeans, through an agent layer called MBeanserver.
A user sends either a Get or Set query to the agent layer, which passes it to the appropriate MBean, receives the response, and relays it back to the user, allowing for non-invasive auditing and setting of internal values.
In the context of Tomcat administration, the entire Catalina class can be managed as a single MBean, as can any applications you expose to JMX. This includes everything from changing internal settings to returning usage metrics, all the way up to actually initializing a server restart.
There's a lot of power here, and also a lot of flexibility - it's theoretically possible to use a custom JMX implementation to handle almost all of your administration. There are cases where developers have created custom JMX structures capable of handling tasks as complicated as cluster shutdown and restart.
However, just as is the case with Tomcat, all this power means a lot of work to get it working in a useful way. It's easy to get JMX talking to Tomcat and start editing internal values with a client such as JConsole, but anything more complex, such as filtering the information or automating administrative tasks, will have to be custom-built, which begs the question: isn't this the issue that was giving you an administrative headache to begin with?
A few other rough patches you should keep in mind while exploring a JMX-based administrative solution are that there isn't much precedent for high-security JMX infrastructures in an enterprise environment, and that you still won't be able to remotely start your servers without some additional legwork, since JMX runs on top of the JVM.
We're not saying you should entirely discount JMX by any means - on the contrary, understanding this technology is incredibly useful from an administrative standpoint. It's a question of time, stability, and ultimately, suitability to an Enterprise Tomcat environment.
For detailed information on getting JMX up and running on Apache Tomcat, and some example use cases, check out our Tomcat JMX guide.
One of the most common ways that administrators handle the problem of Tomcat Administration is by simply setting up SSH keys for all their servers and writing scripts in a language like Groovy or Python to handle common tasks such as server shutdown.
The main appeal of this approach is that it doesn't require too much planning or preparation to get some basic functionality up and running right away. This can look very appealing to an administrator of a quickly expanding architecture who finds themselves backed into a corner.
The corollary, of course, is that any system that isn't well-planned out is not going to scale, and for enterprise environments, this isn't acceptable. Most administrators who find their architecture expanding to 15 servers or more will end up paying for distributed command utilities such as Puppet to keep their administrative structure functional. Scripting also lacks the "loose" architecture that makes a technology like JMX such a great complement to the flexibility of a Tomcat infrastructure.
On top of this, they'll still need to write and maintain all of their administrative scripts, which represents hours of work every time a new need comes up or something breaks, and lots of documentation to write if they ever want to be able to explain to their manager exactly what assurance exists that the network won't fall over under an unexpected spike.
Despite its shortcomings, scripting is still a very powerful, fast way to implement a needed administrative function, and as long as you stay honest with yourself about the overall elegance and efficiency of your total solution, there's nothing wrong with basing a part of your administrative system on scripts.
Custom Administrative Solutions - Summing It Up
So now you have a good introduction to some common ways that other users handle the problem of Tomcat administration. As we've seen, there are a number of powerful options you can use to implement a tailor-made administrative solution, if you have the time and resources to do the work of planning and building on your own.
For the final section of this article, we'll take a look at another option designed to keep the positives of all these solutions and do away with all the negatives: MuleSoft's Tcat Server, a reliable, lightweight, agent-layer administrative solution built on Tomcat.
Tcat - Your Enterprise Tomcat Administrative Solution
MuleSoft Tcat makes Enterprise Tomcat administration simple right out of the box.
Running in front of your existing Tomcat infrastructure, Tcat delivers all the enterprise-level administrative power you could ever need, including:
- advanced deployment tools with rollback capabilities
- deep diagnostics
- configuration management - save a configuration profile and apply it to new servers with one click
- reliable restarts
- API integration into your existing processes
- comprehensive support and documentation
Starting with 100% Apache Tomcat, with zero modifications to core binaries, Tcat packs all of this power into an easy-to-use web-based console.
We don't just want you to trust us on all of this; we want you to see the power for yourself. Stop stressing and start administrating. Download Tcat today!