linux - Docker应用在线升级

Question

我是 docker 的新手，在设计涉及 docker 的简单实时升级解决方案时遇到了一些问题。目前，我正在使用基于 fork()/exec() 的应用程序实时升级模式:

• 旧服务器在请求时 fork() 一个 child 。
• 子服务器 exec() 新的可执行文件，加载新的数据/配置。
• 旧服务器将必要的信息(套接字、内存数据等)传递给子服务器，以便它接管服务。
• 旧服务器在 child 准备好后停止处理新请求(旧服务器不会 exit() ATM)。
• 如果升级成功，手动停止旧服务器(这可以延迟到下一次实时升级前不久)，否则停止子服务器并通知旧服务器重新开始处理请求。

如您所见，无论升级是否失败，这种实时升级策略通常不会导致停机。

我们的大部分服务都是无状态的或者状态非常简单，所以上面的模式很容易实现，而且非常可靠。

我的问题是如何在 docker 中实现上述模式(或类似的模式)？也许我走错了方向，我洗耳恭听。

Answer 1

由于您的服务已经是无状态的，并且您的服务也可以同时处理旧连接和新连接，因此在您的服务前面使用负载均衡器和某种滚动升级策略可能是最合适的。

一般而言，fork 方法不太适合 Docker 和容器背后的理念。 Docker 镜像和生成的容器应始终包含运行服务所需的一切。此外，如果另一个容器基于相同的图像启动，它应该始终启动完全相同的服务。

在基于 fork 的升级解决方案中，容器内的二进制文件/可执行文件会在初始启动后发生变化。这意味着如果出于某种原因您决定基于同一图像启动另一个容器，它将不会运行相同版本的服务。您当然可以在启动时自动升级到最新版本的图像中添加一些东西，但这会使部署复杂化。在我看来，这将违反 Docker 世界中太多成文和不成文的规则，我认为这是一种不好的做法。

我觉得普通的 Docker 不足以满足您的需求。我建议您研究更高级的容器编排解决方案，这些解决方案提供服务负载平衡和滚动更新等功能。当人们有这些更高级的需求时，我首先想到的总是 Kubernetes。

随着 Deployment 对象的引入，Kubernetes 在更新策略方面获得了很多权力。你应该通读Kubernetes Deployments .如果与适当的健康检查一起使用，Deployment 的滚动更新策略应该会为您提供所需的一切，包括失败部署的回滚。

Kubernetes 的缺点是需要增加设置和维护集群的工作量。但根据您的应用程序、基础设施和服务数量的大小，这可能是值得的。