How do you handle rolling upgrades?

[Bas Gooren <ba...@iswd.nl>]

Hi All,

TL;DR: How/where do you host your wicket apps so you can deploy a new
version while users are actively using the old/current version? In
particular: when the new version cannot read the sessions of the old
version due to page changes.

We’re investigating how we can eliminate downtime in some of our apps while
we deploy a new version.

Most of the stuff we’ve built in the past could handle 30 sec downtime
without much issue (e.g. outside office hours).

However, we would like to be able to deploy more often; Perhaps even move
towards continuous deployment.

Currently, using wicket, this seems problematic due to two reasons:

   - Wicket’s sessions (http session and in particular wicket’s filestore)
   require affinity
   - Session incompatibility: new version of app usually cannot deserialize
   old sessions; If we simply take the old version offline, users will need to
   start with a fresh session

Since we would like to do deploys without service interruption for active
users, I imagine something like session draining on the “old” version after
the “new” version goes online.
Haproxy has support for this: launch new version and route new users to it,
put old one in maintenance mode and take it offline when all sessions for
it have expired (or after predetermined timeout, e.g. 30 minutes).

Most cloud providers (e.g. heroku, jelastic) don’t handle this gracefully
for as far as I can tell. While they do handle rolling upgrades, they
assume statelessness or otherwise transferable statefulness (new version
can read state of old version).

Tomcat has support for parallel deployments ([1]), but I’m not a big fan of
running multiple apps in a single JVM.

Since we don’t build things that will require massive horizontal
scalability, powerful virtual servers have always worked great for us.

That means we’ll probably need to put a reverse proxy in between our
frontend (apache for SSL termination) and app server (tomcat) to handle
routing.
But of course, before we build something like that on top of haproxy (or
other…) I’d like to make sure we’re not reinventing the wheel.

I’m curious how other users of wicket handle this: how do you handle active
user sessions (with state) when rolling out a new version of your app?

I’d be grateful for any insights and experiences from other wicketeers!

http://tomcat.apache.org/tomcat-8.5-doc/config/context.html#Parallel_deployment


Met vriendelijke groet,
Kind regards,

Bas Gooren

Re: How do you handle rolling upgrades?

[Martin Makundi <ma...@koodaripalvelut.com>]

Also if you shut down sessions, you need a grace period which lengthens the
update time.

2017-07-26 16:05 GMT+03:00 Bas Gooren <ba...@iswd.nl>:

> Hi All,
>
> TL;DR: How/where do you host your wicket apps so you can deploy a new
> version while users are actively using the old/current version? In
> particular: when the new version cannot read the sessions of the old
> version due to page changes.
>
> We’re investigating how we can eliminate downtime in some of our apps while
> we deploy a new version.
>
> Most of the stuff we’ve built in the past could handle 30 sec downtime
> without much issue (e.g. outside office hours).
>
> However, we would like to be able to deploy more often; Perhaps even move
> towards continuous deployment.
>
> Currently, using wicket, this seems problematic due to two reasons:
>
>    - Wicket’s sessions (http session and in particular wicket’s filestore)
>    require affinity
>    - Session incompatibility: new version of app usually cannot deserialize
>    old sessions; If we simply take the old version offline, users will
> need to
>    start with a fresh session
>
> Since we would like to do deploys without service interruption for active
> users, I imagine something like session draining on the “old” version after
> the “new” version goes online.
> Haproxy has support for this: launch new version and route new users to it,
> put old one in maintenance mode and take it offline when all sessions for
> it have expired (or after predetermined timeout, e.g. 30 minutes).
>
> Most cloud providers (e.g. heroku, jelastic) don’t handle this gracefully
> for as far as I can tell. While they do handle rolling upgrades, they
> assume statelessness or otherwise transferable statefulness (new version
> can read state of old version).
>
> Tomcat has support for parallel deployments ([1]), but I’m not a big fan of
> running multiple apps in a single JVM.
>
> Since we don’t build things that will require massive horizontal
> scalability, powerful virtual servers have always worked great for us.
>
> That means we’ll probably need to put a reverse proxy in between our
> frontend (apache for SSL termination) and app server (tomcat) to handle
> routing.
> But of course, before we build something like that on top of haproxy (or
> other…) I’d like to make sure we’re not reinventing the wheel.
>
> I’m curious how other users of wicket handle this: how do you handle active
> user sessions (with state) when rolling out a new version of your app?
>
> I’d be grateful for any insights and experiences from other wicketeers!
>
> http://tomcat.apache.org/tomcat-8.5-doc/config/context.
> html#Parallel_deployment
>
>
> Met vriendelijke groet,
> Kind regards,
>
> Bas Gooren
>