0

I am trying to see if this is possible. I will first you you a background of how the application currently runs.

The application is deployed to 4 separate nodes (using the 'all' config). 2 nodes on ServerA and 2 nodes on ServerB named node1, node2, node3, node4. The application is behind a web server running apache and mod_jk to redirect traffic. Assume that version 1.0.0 is currently deployed. I will be trying to deploy 1.0.1 which will only have a minor change.

The goal will be to take down node4, deploy version 1.0.1 to node4 (while node1-node3 are still up and running). They will be sharing the same database which in theory should be fine as long as our code doesn't require us to update anything in our database. The next step would be to direct traffic using apache + mod_jk to only load balance node1-node3. node4 will be accessed directly. node4 will be tested running version 1.0.1. Apache + mod_jk will be changed to serve node4. Version 1.0.1 will be deployed to node1-node3. All nodes should now be running version 1.0.1.

I know this is extremely high level and I am already facing problems (not to mention application specific problems).

I just want to know what are other ways of approaching this or JBoss specific problems that I can run into.

Should I be putting the hotdeploy node in a different cluster and have the rest join later?

Any suggestions would help. Thanks.

leeman24
  • 2,729
  • 3
  • 29
  • 42

1 Answers1

1

You can take advantage of your Apache with mod_jk in front, imagine you have in your configuration something like:

JkMount  /myapp/* workerApp
JkWorkersFile /etc/httpd/conf/workerApp.properties

Well instead of having a file named workerApp.properties use these 3 files:

  • workerApp-deploy1.properties
    • Will contain configuration to connect only to node 4
  • workerApp-deploy2.properties
    • Will contain configuration to connect only to nodes 1,2 and 3
  • workerApp-normal.properties
    • This will be your actual workers file

Now wokerApp.properties instead of being a file is a link, so on normal cirscunstances:

ln -s workerApp-normal.properties workerApp.properties

When you deploy a new version

rm -f workerApp.properties
ln -s workerApp-deploy2.properties workerApp.properties
reload apache

Now you can deploy on node4 the new version and all request will route through node1,2 and 3. When deploy on node 4 is ready:

rm -f workerApp.properties
ln -s workerApp-deploy1.properties workerApp.properties
reload apache

In this situation all clients will be router to node 4 and you can upgrade versions on other nodes. When you're done:

rm -f workerApp.properties
ln -s workerApp-normal.properties workerApp.properties
reload apache

And you get all request balanced between servers.

This have another advantage, for example you can define a VirtualHost like preflighttest.yourcompany.com using a different set of workers, so you can test your new version on node 4 before effectivily rolling it in production.

Hope it helps.

alphamikevictor
  • 595
  • 7
  • 17
  • Thank you for the detailed reply. I will definitely incorporate this to make the process cleaner for the person who running this process. I will likely use your tip to add a vhost. I was thinking the business users testing node4 would just access the app directly on the tomcat port but I like the idea of vhost better. Thanks. – leeman24 Mar 02 '15 at 16:42
  • Hey @alphamikevictor, I used the symlink method which will be quite easy to wrap in a script. Thanks again. – leeman24 Mar 06 '15 at 22:39