Setting up Tomcat on shared drive for clustered environment

Question

We have a production environment with externally load-balanced Tomcat servers running on multiple servers, serving HTTP requests and maintaining stick sessions.

Due to lack of complete build and deployment process (unfortunately I don't see that's happening anywhere in near future !), there is an Ops team, which is responsible for copying JSPs / Classes / static resources / Properties files or even changing struts-config.xml (sometimes web.xml !) manually. We don't build WARs !!

Since it's manual intensive work, a human error creates lot of problems because the same steps have to be executed on multiple environments (on a deployment day, it could be around 10 machines atleast), and that makes debugging even complicated.

I do understand we are far from ideal production environment (for that matter even practical production env.) but I was just brainstorming and thought what if we can install (copy) Tomcat on high-speed SAN and mount it as a shared drive on each server so that atleast the changes will go to all nodes simulatenously.

Please let me know your thoughts and espcially criticism in this approach.

Thanks.

Answer 1

While it is possible to share some of the directories in a Tomcat deployment (see this question), it's not safe to share the ones you're wanting to share, and while it might work out if you take care to localize the ./work and ./temp directories, you're asking for hard-to-troubleshoot problems if you try it, not to mention introducing a single-point-of-failure to your infrastructure.

As a dev/ops person myself, I'm lucky enough to work very closely with my developers and I've come up with automated deployments for a number of very complicated and messy apps. My advice in that area is that if you can get your team to buy into the goal of automating your deployment, just to start small and automate a little bit more each iteration, as your dev team and your ops team get used to the process and work out the kinks.

For my recommendation on your exact problem here, if it will be possible to mount a single shared drive on your production machines, the best solution is probably going to be to maintain a canonical image of your tomcat setup on the shared drive, and then write some (could be dead-simple) scripts to update all or part of the deployed tomcats on each app server when changes are made. This would make it easier to roll out changes gradually (if you do that), abort changes that aren't working out, and verify that everything is in sync on all the app servers.

If your devs could get write access to that shared drive, you could even help the ops guys by taking away the error-prone editing process from them and just needing to ask them to deploy particular files or directories. Once you've gotten that infrastructure and process in place, then you could start automating things: the devs could write the automation scripts and save them on the shared drive for the ops folks to run, and build from there.

Answer 2

I'm not into tomcat, but maybe I can share what I'm doing for similar task:

1. Just prepare folder with all the updates (like I may have seed12/etc/apache2/apache2.conf and seed12/var/www/index.php) - only the files that you update, placed in the corresponding folders, always starting from root.

2. Then make simple script that does scp -r to every machine. You can add to the script some ssh commands to restart your services if required.

An extra advantage is that it's somewhat self-documenting - just keep those "seed" folders and thus have log of all the changes.

As for criticism (you asked !) to your approach - it adds unnecessary point of failure into your otherwise redundant setup.

Answer 3

You don't want to do this, it could migrate everything at once, logging would be complicated and rollbacks would get messy. Use the murder gem to dist this out.