5

我试图弄清楚如何根据 JSESSIONID cookie 提供具有长期交互用户会话的 web 应用程序的零停机滚动更新，这些会话应该是粘性的。

出于这个（和其他）原因，我正在研究容器技术，比如 Docker Swarm 或 Kubernetes。

我很难找到关于如何：

  1. 确保新会话转到最新版本的应用程序
  2. 虽然现有会话仍由它们启动的任何版本的应用程序提供服务
  3. 关闭旧版本的所有会话后，正确清理旧版本

更多信息：

  • 请求链接到基于 JSESSIONID cookie 的会话
  • 会话可能会持续数天，但可以在 24 小时内从应用程序中终止它们（向用户发送通知以“再次注销/登录，因为有新版本或它们会在下午 12 点自动注销“ 例如）
  • 当然，对于每个版本的应用程序，已经有多个容器以负载平衡的方式运行
  • 我不介意容器总数的增长，例如，如果每个旧版本的容器都仍在运行，因为它们仍然会托管 1 个会话，而大多数用户已经在使用新版本的应用程序

所以，我对所需流程的想法是这样的：

  1. 安装新版本的应用程序
  2. 让所有新连接（没有设置 JSESSIONID cookie 的连接）转到新版本的应用程序一次
  3. 旧版本应用程序的容器不再提供会话，删除容器/....

正如我所提到的，我正在研究 Kubernetes 和 Docker Swarm，但对其他建议持开放态度，但最终解决方案应该能够在云平台上运行（目前使用 Azure，但未来可能会使用谷歌或亚马逊云）

任何指示/提示/建议或想法表示赞赏

保罗

编辑：回答@Tarun 问题和一般说明：是的，我不想停机。我设想的方式是托管旧版本的容器将继续运行以服务所有现有会话。旧服务器上的所有会话结束后，旧服务器将被删除。

新容器只会为在新版本推出后启动应用程序的用户提供新会话。

因此，举个例子： - 我在上午 9 点启动旧版本应用程序的新会话 A - 上午 10 点推出新版本。- 我继续使用会话 A，其仍然托管在运行旧版本的容器上。- 中午我去吃午饭并注销 - 因为我是连接到运行旧版本的容器的最后一个会话，容器现在将被销毁 - 下午 1 点我回来，重新登录并获得新版本的应用程序

说得通？

4

1 回答 1

0

您的工作负载可能不适合 Kubernetes/容器及其当前架构。我能想出解决这个问题的最好方法是将状态移动到 PV/PVC 并将 PV 迁移到新容器，以便新容器可以具有旧会话的状态，现在如何将该会话的调用迁移到正确的节点我不确定如何有效地做到这一点。

理想情况下，您会将您的数据/缓存层与您的服务分离成类似 redis 的东西，然后哪个节点为请求提供服务并不重要。

于 2017-04-05T23:39:45.130 回答