Upgrade same deployment on different Server Groups in Domain Mode (rolling application upgrade scenario, Wildfly 8.2):

[kim_zeevaarders]

Hello everybody,

We are planning to go live with the wildfly platform very soon (8.2), but have encountered a little problem concerning (re)deployment of the same EAR to different server groups.

According to this link https://docs.jboss.org/author/display/WFLY8/Core+management+concepts (Juli 2011) a rolling application upgrade scenario concerning the same WAR on different server-groups (which is exactly what we are looking for) should be possible:

Different server groups can also run the same profile and have the same deployments; for example to support rolling application upgrade scenarios where a complete service outage is avoided by first upgrading the application on one server group and then upgrading a second server group.

However, when trying to implement this scenario over CLI we run into CLI-errors because the deployed WAR is "shared" between server groups.

The only way we succeeded thus far is to deploy the war with different names on both server groups (2 deployments in fact of the same physical EAR)

We are looking for the following scenario (automated deployment build-server) :

1. disable load balance server-group-1
2. CLI: deploy new WAR to only server-group-1 (server-group-2 should keep running with old WAR)
3. CLI: restart server-group-1
4. enable load balancer server-group-1
5. disable load balancer server-group-2
6. CLI:deploy same WAR to only server-group-2 (server-group-1 should keep running with new WAR)
7. CLI:restart server-group-2
8. enable load balancer server-group-2

Such a scenario would ensure availability of the service due to the fact that the deployment is done in turns. At any point in time at least one node is available...

If anybody can enlighten me how to implement steps 2 and 6  using the CLI without errors, or give any insight in feasible alternatives this would be of great help to us!

NB. For load balancing we are using mod_jk 2.40.

Thanks in advance!

Regards,

Kim

[syokanov]

We use this method with a war file but it should work with an ear.

We deploy our war to the domain with the build number in the name. This allows us to have two versions of the same application in the repository at the same time.

Here is an example of how we would upgrade from build 108 to build 109. This is part of a shell script but I have pulled out the relevant CLI commands.

Both server groups are initially running webapp-108.war with runtime name webapp.war.

First, deploy the new war disabled:

jboss-cli.sh --connect --command="deploy /tmp/webapp.war --name=webapp-109.war --runtime-name=webapp.war --disabled"

Then, stop group 1, add and deploy the new war. Group 2 continues running build 108:

jboss-cli.sh --connect --command="/server-group=job-group-1:stop-servers(blocking=true)"
jboss-cli.sh --connect --command="/server-group=job-group-1/deployment=webapp-109.war:add"
jboss-cli.sh --connect --command="/server-group=job-group-1/deployment=webapp-109.war:deploy"
jboss-cli.sh --connect --command="/server-group=job-group-1/deployment=webapp-108.war:undeploy"
jboss-cli.sh --connect --command="/server-group=job-group-1/deployment=webapp-108.war:remove"
jboss-cli.sh --connect --command="/server-group=job-group-1:start-servers(blocking=true)"

Once group 1 is running, do the same with group 2:

jboss-cli.sh --connect --command="/server-group=job-group-2:stop-servers(blocking=true)"
jboss-cli.sh --connect --command="/server-group=job-group-2/deployment=webapp-109.war:add"
jboss-cli.sh --connect --command="/server-group=job-group-2/deployment=webapp-109.war:deploy"
jboss-cli.sh --connect --command="/server-group=job-group-2/deployment=webapp-108.war:undeploy"
jboss-cli.sh --connect --command="/server-group=job-group-2/deployment=webapp-108.war:remove"
jboss-cli.sh --connect --command="/server-group=job-group-2:start-servers(blocking=true)"

Finally, remove the old war from the repository:

jboss-cli.sh --connect --command="undeploy webapp-108.war"

I hope this helps.