maven deploy to tomcat cluster (multiple) in one line

Question

We're trying to have maven deploy to many multiple servers that form our cluster in just one line.

This solution works just fine except that we need to run it repeatedly (1 time per server installation) and our goal is to do it after our integration server (jenkins) buils a successful artifact. And having a matrix feature is not really an option at this time. Why build again the project per server if we just need to deploy it? (plus the time spend doing this)

We've been experimenting using maven profiles (one per server and trying to activated them all at once, or one big profile with all server on it) but no luck with that option, the tomcat-maven-plugin does not work that way.

Jenkins seems to have a deploy plugin that's based on cargo, but only handles one server at a time

Is there a way to accomplish this? Either using maven-tomcat-plugin? Or Jenkins/Hudson plugin?

Any other ideas from you experts about how to deploy the war to the cluster after a successful build? (I'm trying to avoid a shell script, just becuase of portability issues)

Answer 1

If you need it to happen with only one line, I suggest executing a CMD, Ant, bash, etc. script as the "one-line" and make that script do more than one thing.

For instance, if you used Ant... Your one line could be something like this: ant DeployToCluster. And your build.xml file could have the target DeployToCluster which may include many steps. Think of it like refactoring out a method of code which does many things. The code which invokes your method becomes a one-liner.

You won't likely find a single command to do what you are after, unless it is just executing an existing script which someone else has written that does what you want.

Either way, it is usually a good idea to be able to deploy code to individual servers at a time. This lets you keep your app/service up at all times because you are only affecting one node at a time while the others can continue running. It also has the advantage that if something goes horribly wrong, you can just not re-enable the one node in the cluster and diagnose the one server's problem, as opposed to taking out your entire cluster with a bad deploy. The deploy strategy steps our script follows is:

1. Disable monitoring of single node
2. Pull that node out of cluster
3. Deploy new code to it
4. Verify node is operating properly with new code
5. Put node back into cluster
6. Re-enable monitoring for that node
7. Repeat steps for every other node

If anything goes wrong at any step, we always have a working environment for our users.