如何使用容器

时间:2017-03-20 12:33:58

标签: kubernetes updating docker-swarm jsessionid sticky-session

我试图找出如何根据JSESSIONID cookie提供具有长期交互式用户会话的webapp的零停机滚动更新,该会话应该是粘性的。

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

我很难找到关于如何:

的好答案
  1. 确保新会话转到最新版本的应用
  2. 虽然现有的会话仍由任何版本的服务提供
  3. 启动的应用程序
  4. 在所有会话之后正确清理旧版本 封闭
  5. 更多信息:

    • 请求链接到基于JSESSIONID cookie的会话
    • 会话可能会持续数天,但我可以在24小时的时间范围内从应用内终止它们(向用户发送通知"再次注销/登录,因为有新版本或者它们是否则在下午12点自动退出"例如)
    • 当然,对于每个版本的应用程序,都有多个容器已经以负载均衡的方式运行
    • 我不介意容器总数的增长,例如,如果每个旧版本的容器都仍在运行,因为它们仍将主持1个会话,而大多数用户已经在新版本的应用

    所以,我对所需流程的看法是这样的:

    1. 张贴新版本的应用
    2. 让所有新连接(没有JSESSIONID cookie设置的连接)转到应用程序的新版本
    3. 旧版应用程序的容器不提供会话服务 再取出容器/....
    4. 正如我所提到的,我正在研究Kubernetes和Docker Swarm,但对其他建议持开放态度,但最终解决方案应该能够在云平台上运行(目前使用Azure,但可能会使用Google或Amazon云)在将来)

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

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

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

      那么,举一个例子: - 我在上午9点启动了应用程序旧版本的新会话A. - 上午10点推出新版本。 - 我继续使用会话A,托管在运行旧版本的容器上。 - 中午我去吃午饭然后退出 - 因为我是连接到运行旧版本的容器的最后一个会话,所以容器现在将被销毁 - 下午1点我回来,重新登录,我得到了新版本的应用程序

      有道理吗?

1 个答案:

答案 0 :(得分:0)

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

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