0

We're deploying an app to several Jelastic Tomcat environments using Maven on a TeamCity build server. This works well and has done so for quite some time.

Now, we want to move closer to zero-downtime deploy and would like to find a simple way to minimize or eliminate down-time. Tomcat's Parallel Deploy functionality seems like a good fit.

However, it seems like the Jelastic Maven plug-in doesn't handle parallel deploys or non-standard (i.e. <artifact-name>##<artifact-version>.war) archive names. The tomcat-maven-plugin doesn't play well with our Nginx proxy/load balancer claiming that the request (a PUT) is too big. 100 MB shouldn't be an issue, right...? :)

When I try to deploy using Postman I also get an error saying that the context / is already used. Exactly, that's why I want a parallel deployment...

I've tried it all locally and it works like a charm but remote is another issue, has anybody been successful in this kind of setup or am I missing something?

Improve this question

2 Answers 2

Reset to default
1

You are right, Jelastic Maven does not support parallel deployment in Tomcat at the moment. The feature request was added to the enhancements list. As an alternative option for now, you can deploy a war archive via direct SSH connect to a container. Or you can play with swap domain - create a new environment, deployment a new version to this new env, test it and if everything is ok swap domain between old and new envs.

In addition to that, we are going to release Traffic Distributor - a specific module for zero-downtime deployment of complex apps. It's some kind of load balancer that allows to reroute portion of traffic or all of it between environments by drag-and-drop or API call. It's coming to public in a month.

Improve this answer
1
  • 1
    We ended up using Apache Cargo and Tomcat's own manager interface. Works like a charm and new contexts are spun up and down as expected. Traffic Distributor sounds promising!
    – method
    May 4, 2016 at 14:06
0

There is also another alternative for if you're using a public IP address on your load balancer (recommended).

In this case you can create a completely new/separate environment with the same topology, deploy your updated code there, and then after testing move the public IP from the old load balancer to the new one. It is very fast (just a few dropped packets).

This workflow works very well for blue-green deployment.

Improve this answer
1
  • We do use load balancing and thought about this solution. However, we want to use this feature also for more dynamic environments (STAGE and TEST), that rules this out.
    – method
    May 4, 2016 at 14:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .