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.
#!/bin/sh # echo Running Tomcat install Script TOMCAT_VERSION=apache-tomcat-7.0.33-blog # The FTP server holding the tomcat binaries SERVER=<your server name> TOMCAT_LOCATION=/Public/binaries/ SERVER_USER=<your FTP User Name> SERVER_PASSWORD=<your FTP password> CUT_DIRS=3 # The version control details SVN_USER=<your Subversion username> SVN_PASSWORD=<your Subversion Password> SVN_URL=https:<the URL to your subversion repository>/Tomcat/apache-tomcat-7.0.33/conf mkdir ../$TOMCAT_VERSION pwd echo changing directory cd ../vim $TOMCAT_VERSION pwd wget -r -nH -nc --cut-dirs=$CUT_DIRS ftp://$SERVER_USER:$SERVER_PASSWORD@$SERVER$TOMCAT_LOCATION$TOMCAT_VERSION echo .. echo The directory looks like this: ls echo .. echo Getting the config files from config.. svn --username=$SVN_USER --password=$SVN_PASSWORD co $SVN_URL bin/startup.sh # At this point handover to the application deploy 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.
Notes
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.
Reference: Super Fast Tomcat Installation using FTP and Version Control from our JCG partner Roger Hughes at the Captain Debug’s Blog blog.
using the above, don’t i still need to login via ssh?