我试图找出如何根据JSESSIONID cookie提供具有长期交互式用户会话的webapp的零停机滚动更新,该会话应该是粘性的。
出于这个(和其他)原因,我正在研究容器技术,比如Docker Swarm或Kubernetes。
我很难找到关于如何:
的好答案更多信息:
所以,我对所需流程的看法是这样的:
正如我所提到的,我正在研究Kubernetes和Docker Swarm,但对其他建议持开放态度,但最终解决方案应该能够在云平台上运行(目前使用Azure,但可能会使用Google或Amazon云)在将来)
任何指针/提示/建议或想法赞赏
保
编辑: 回答@Tarun问题和一般澄清:是的,我不想停机。我设想的方式是托管旧版本的容器将继续运行以服务所有现有会话。旧服务器上的所有会话结束后,旧服务器将被删除。
新容器只会为新版本推出后启动应用的用户提供新会话。
那么,举一个例子: - 我在上午9点启动了应用程序旧版本的新会话A. - 上午10点推出新版本。 - 我继续使用会话A,托管在运行旧版本的容器上。 - 中午我去吃午饭然后退出 - 因为我是连接到运行旧版本的容器的最后一个会话,所以容器现在将被销毁 - 下午1点我回来,重新登录,我得到了新版本的应用程序
有道理吗?
答案 0 :(得分:0)
您的工作量可能不适合Kubernetes /容器及其当前架构。我可以解决这个问题的最好方法是将状态移动到PV / PVC并将PV迁移到新容器,以便新容器可以具有旧会话的状态,现在如何将该会话的调用迁移到正确的节点我不知道如何有效地做到这一点。
理想情况下,您会将数据/缓存层与服务分离为redis,然后哪个节点为请求提供服务并不重要。