问题标签 [blue-green-deployment]

I am trying implement the following setup

At any time only one of the redis instances should serve the incoming requests.

Going by the documentation, it seems that you can disable a server dynamically and HA would stop directing the traffic to the disabled server. While this worked for new client connections, existing client connections are still served content from the disabled server. But if I kill the redis instance, even the existing client connections are redirected to the other instance.

Is it possible to achieve this behavior without killing the instance?

Heres my HA config:

我想以零停机时间部署 hybris 构建。我们的技术架构包括两个前端服务器、两个后端服务器、两个主/从 solr 集群，但只有一个数据库服务器（MS SQL 2012）。新的构建可能需要执行补丁来更改数据库架构。

是否有可能在单个数据库环境中实现这一目标？

如果需要两个数据库（蓝色和绿色），那么在 hybris 的情况下数据库复制的最佳实践是什么？

我有一个 Jenkinsfile 有这个顺序的路径（假设绿色环境只绑定到生产）：

Build-->Deploy-to-QA-->Deploy-To-Preprod-->Deploy-To-BLUE-Production-->绑定到蓝色环境到负载均衡器-->取消绑定绿色环境-->部署到绿色- -> 绑定绿色--> 解除绑定蓝色

如果我们过于乐观，这个命令似乎很好，因为在某些情况下，绿色环境可能存在问题，管理员用户可以手动绑定蓝色环境，或者两者可以绑定到生产环境中。

因此，我编写了一个脚本，对 LB 进行 API 调用并获取绑定的服务组。

但是我不知道如何通过获取 api 的结果来重定向管道。

如果端点返回蓝色已绑定，则应从绿色开始部署，如果端点返回绿色已绑定信息，则在我的情况下应从蓝色环境开始部署。

但据我所知，我无法将阶段包装在 Jenkinsfile 的函数中。

CloudFoundry 文档是否有理由推荐以下蓝绿部署步骤（我们在 Pivotal CloudFoundry）：

1. 推送 GoodApp_new
2. 将 GoodApp 路由添加到 GoodApp_new（它们之间的负载平衡）
3. 从 GoodApp 中删除 GoodApp 路由
4. 从 GoodApp_new 中删除 GoodApp_new 路由
5. 删除 GoodApp
6. 常见的后续步骤：将 GoodApp_new 重命名为 GoodApp

当以下步骤看起来等效时？

1. 将 GoodApp 重命名为 GoodApp_old（路由保持不变）
2. 推送名为GoodApp的新版本（有效负载均衡，由于app名称正确，默认路由正确）
3. 删除 GoodApp_old

也许在推送期间添加所有正确的路线并不常见？

重命名文档中未包含的应用程序可能会产生无法预料的副作用？我们的 APM 设置已经处理了多个应用程序名称在几秒钟内浮动，这将是相关的。

我们已经为使用 Terraform 的项目设置了基础设施，包括代码部署、ALB 和自动缩放组。到目前为止，我们正在进行就地部署。但现在我们正在尝试切换到蓝/绿部署。由于 CodeDeploy 蓝/绿部署会在成功部署时替换整个自动缩放组，因此 Terraform 状态文件中的旧自动缩放组状态将变得陈旧，并且不会反映 CodeDeploy 服务添加的新自动缩放组。有什么已知的方法可以克服这个问题吗？

我们希望能够部署我们的 Spark 作业，这样在部署期间处理数据时不会出现任何停机时间（目前大约有 2-3 分钟的窗口）。在我看来，最简单的方法是模拟“蓝/绿部署”理念，即启动新版本的 Spark 作业，让它预热，然后关闭旧作业。但是，使用结构化流和检查点，我们不能这样做，因为新的 Spark 作业看到最新的检查点文件已经存在（来自旧作业）。我在下面附上了一个示例错误。有人对潜在的解决方法有任何想法吗？

我考虑将现有的检查点目录复制到另一个检查点目录以用于新创建的作业 - 虽然这应该作为一种解决方法（一些数据可能会被重新处理，但我们的数据库应该重复数据删除），这看起来超级hacky，我宁愿不追求。

目标：为使用 Kafka 的特定 spring-boot 服务组织蓝/绿部署。（我对如何在 REST 或 DB 层解决 B/G 不感兴趣，所以假设这部分 B/G 已经在LB上完成）

我想要：同时在 docker swarm 集群中运行两个服务实例。但其中之一必须处于睡眠模式，即不产生和消费任何消息。

最大的问题：为我的服务设置 scale = 2 并不是什么大问题。但是在这种情况下，每个服务实例都将使用事件并处理它们。这会导致灾难。所以我需要简单透明的机制来关闭所有服务的生产者和消费者并用特定的偏移量恢复它们

我正在寻找如何实现这一目标的示例或建议。

当前的想法：将当前偏移存储在zookeeper中并编写自定义层来汇集这些配置并基于此管理消费者和生产者。但是，我相信存在一些更好和更简单的方式/框架。

有一些技术可以确保新更改不会破坏系统，例如上面提到的蓝绿或金丝雀部署。两者都意味着部分应用更改（仅更改基础架构的一部分，或与旧版本并行运行新版本）。

但是，如果数据结构发生任何重大变化，我不知道如何保持数据一致性（假设您对 GDPR 进行了更改——很可能是这样，对吧？）。

即使在基于 NoSQL 的解决方案上，它也可能会导致问题（正如我想象的那样）。我试图寻找解决方案，但这个问题只是被广泛提及，但很少得到解决。

如何引入这些技术并保持数据一致性？在实际应用中是如何正常实现的？

我有一个使用 RTM api 的 slackbot，它目前是通过 AWS ECS 部署的。每当我想更新机器人时，都会有一个新任务出现，并且有一个 10-20 秒的窗口，旧机器人仍在关闭，而新机器人启动，所以现在会有两个机器人创建重复的操作。

有没有办法在这种情况下进行“蓝绿”部署。ALB - ECS“蓝绿”在我的情况下不起作用，因为机器人正在读取来自 RTM 的输入而不是接收流量。

任何帮助/建议将不胜感激。谢谢！

我们有一个启用了 DevOps 交付管道的 NodeJS Cloud Foundry 应用程序。我们正在尝试更新我们的部署脚本，以允许我们在不停机的情况下部署应用程序更新。我们现在有一个大部分工作的脚本（见下文）。

但是，我们意识到在部署期间，我们的应用程序将启动两次。我们需要在脚本中进行哪些更改，以便只发生一个服务器初始化？这是脚本：