Java tips, observations, bugs and problems from the world of Spring, Weblogic, Oracle, MySQL and many other technologies...

Wednesday, 2 January 2013

Super Fast Tomcat Installation using FTP and Version Control

When talking about Continuous Delivery one of the tests that both Martin Fowler and Jez Humble often mention is their "flame thrower" test. It goes something like this: Jez will say "How long would it take you to get up and running if Martin and I went into your machine rooms armed with flame throwers and axes and started attacking your servers"?

The answer, of course, should be: "oh about an hour - right after we've put the fire out, swept up the mess, found some new servers, plugged them in and contacted our top flight lawyers so that we can sue you for criminal damage". Most of the time this isn't the case as deployment is all too often a manual process, with the guy doing the installation simply following a list of instructions written in a Word document. And what is a list of instructions? A computer program. Now, hands up everyone who likes writing Word documents. Okay, now hands up everyone who likes writing code... In your imagination, you should see a room full of people voting for writing code, so why is it that when there are opportunities for writing deployment scripts do we prefer (or get lumbered with) writing Word documents? It must be more fun, productive and cost effective to write scripts that do our deployment for us in seconds rather than writing Word documents and then do every deployment ourselves.

Assuming that your machine room has been trashed, then Let's consider what you need to get up and running again. For a start, you'll need a machine with a few common things setup. I'm simplifying here; however, you'll probably need:

some user accounts.

a pinch of networking (knowledge of where your DNS is etc)

the correct version of Java

a Subversion (or other version control) client

tomcat (or other server)

some configuration files

your WAR file

Now, this should be as simple as getting hold of a basic drive image or virtual machine and turning it on, letting it boot up and running a deployment script.

If you've ever read Jez Humble and David Farley book Continuous Delivery you'll know that one of the major points they make is that, when setting up your deployment process, you should store your configuration files in your version control system. This to me sounds like one of those really obvious and useful ideas that you only do when someone else points it out to you. This is usually taken to mean your application's configuration files, but should also refer to your server's configuration files.

The other thing you'll notice about Continuous Delivery is that although it's full of good ideas, it's intentionally short on practical coding examples1. If you read my blog you may recall that I've mentioned updating most of my tomcat's config files at one point or another; for example adding datasource details or an SSL configuration. With this in mind, the rest of this blog takes Jez's and David's sound ideas and demonstrates creating a simple install script for my tomcat server.

If you download your candidate version of tomcat and expand the tar/zip file, you'll notice that if has a conf directory, so the first thing to do is to add this directory to version control and delete it from the expanded tomcat binaries. You can now check the conf files out and modify them, adding SSL, an admin user, a MySQL data source or whatever you like. Don't forget to check them in again.

The next thing to do is to put the remaining binaries directories on a FTP server2 in an accessible safe place.

What you now have is a basic setup with all the files held in two convenient places These can now be recombined to create a functioning server.

The big idea here is that although combining these two parts can easily be done manually, the best approach is to do it automatically using a simple script.

In my script you'll see that all I do is to use three simple commands. Firstly I use wget to copy the files from my FTP server to the new server location. The second command is the svn co command, which checks out my tomcat config files and the final command simply starts the server. The rest of the script is all variables, comments and padding.

Now, I'm guessing that one of the reasons that we write so many Word documents is for traceability, so the final trick is to let your script be the documentation by also storing it in version control.

So, there you have it, a simple way of creating tomcat server installations in seconds. Obviously the next step would be for the server install script to handover to another script that installs your web app(s) on the server, but more on that later.

1I guess that the main reason why there are no concrete examples is that there is no fixed structure, such as the Maven directory structure, for creating servers or deploying code as each organisation is different. Is this a good thing? Probably not, perhaps there should be a move to create a "standard server" to match the "standard" way we lay code out.2This could also be a file server, SFTP or web server and the tomcat binaries could be zipped or unzipped.

5 comments:

Or just use http://puppetlabs.com/, it makes this sort of thing pretty trivial.

The great thing about puppet over this is that puppet is declarative so if you upgrade your puppet definitions all the clients are updated automatically (clients poll), so if you decide to add a new bit of software - no problem. If you then change your mind and want to remove that bit of software - no problem.

Colin, Thanks for the comment. I quite agree that there are much better ways of deploying a server than using a shell script and I've only heard good things about puppet - so I'll be looking into it. In the blog I really wanted to emphasise the fact that manually creating servers is inefficient and that server config files should be in version control and treated like source files.

GT, most things are easier than writing shell scripts, and between you and me I really don't like them very much. The idea behind using the shell script was to demonstrate the simplest and most rudimentary method of making life easier for yourself.