Am trying to figure out how to provide zero-downtime rolling updates of a webapp that has long-lived interactive user sessions that should be sticky, based on a JSESSIONID cookie.

For this (and other) reasons I'm looking at container technology, like say Docker Swarm or Kubernetes.

I am having difficulties finding a good answer on how to:

1. Make sure new sessions go to the latest version of the app
2. While existing sessions remain being served by whichever version of the app they were initiated on
3. Properly clean up the old version once all sessions to/on it were closed

Some more info:

• Requests are linked to a session based on a JSESSIONID cookie
• Sessions could potentially live for days, but am able to terminate them from within the app within say a 24hr timeframe (Sending the user a notification to "logout/login again as there is a new version or that they are otherwise automatically logged out at 12pm" for example)
• Of course for each version of the app there are multiple containers already running in load-balanced fashion
• I don't mind the number of total containers growing, for example if each of the old versions containers are all still up and running because they would all still host 1 session, while the majority of the users are already on the new version of the app

So, my idea of the required flow is something along these lines:

1. Put up the new version of the app
2. let all new connections (the ones w/o the JSESSIONID cookie set) go to the new version of the app once
3. a container of the old version of the app is not serving sessions anymore, remove the container/....

As I mentioned, I'm looking into Kubernetes amd Docker Swarm, but open for other suggestions, but the end solution should be able to run on cloud platforms (currently using Azure, but Google or Amazon clouds might be used in the future)

Any pointers/tips/suggestions or ideas appreciated

Paul

EDIT: In answer to @Tarun question and general clarification: yes, I want no downtime. The way I envision this is that the containers hosting the old version will keep running to serve all existing sessions. Once all sessions on the old servers have ended, the old server is removed.

The new containers are only going to serve new sessions for users that startup the app after the rollout of the new version has started.

So, to give an example: - I launch a new session A of the old version of the app at 9am - At 10am a new version is rolled out. - I continue to use session A with remains hosted on a container running the old version. - at noon I go for lunch and log out - as I was the last session connected to the container running the old version, the container will now be destroyed - at 1pm I come back, log back in and I get the new version of the app

Makes sense?