问题标签 [blue-green-deployment]

我正在 AWS 上开发 CI/CD 管道。对于给定的信息，我必须使用 GitLab 作为存储库，并使用蓝/绿部署作为 ECS Fargate 的部署方法。我想使用 CodeDeploy（在 Cloudformation 的模板中预设）并通过每次提交推送到 GitLab 来触发它。我无法在我所在的地区使用 CodePipeline，因此使用 CodePipeline 对我不起作用。

我已经阅读了很多与 ECS fargate 和 B/G 部署相关的文档和网页。但似乎没有多少信息可以提供帮助。有没有人有相关经验？

我正在使用具有扩展合同数据库模式的蓝绿色部署策略。为了在我的数据库部署模式上实现这一点，我设置了属性BlockOnPossibleDataLoss=true因为在展开阶段我可以修改我的数据库而无需对旧版本进行任何中断更改。

我有一个不再需要的专栏，所以我按照以下步骤操作：

1. 我已更改此列以允许空值
2. 然后我的新记录不再填充此列
3. 我运行了一个脚本，将此列的 null 设置为所有表记录

现在我需要删除此列，但即使该列的所有记录都具有 NULL 值，我也不能因为我收到此错误：

检测到行。架构更新正在终止，因为可能会发生数据丢失。

即使使用BlockOnPossibleDataLoss=true如何删除此列？

在部署新功能时，我试图完全了解生产中的新数据（例如注册的新用户）会发生什么。当我将新代码推送到存储库时，蓝绿色部署脚本会创建生产的新克隆，从存储库中提取新代码。然后我需要一些时间来测试一切是否按预期工作。如果一切正常，我将完成部署，新实例将被生产替换。问题是我在测试时添加到生产环境中的数据（新用户、内容等）会发生什么情况？此数据将被传输/克隆到新实例？如果是 - 如何？

我们使用 terraform 来管理我们的 AWS 资源，并拥有将服务从一个负载均衡器更改为两个负载均衡器的代码。

但是，terraform 希望在重新创建服务之前将其销毁。AWS cli 文档指出了原因 - API 只能在服务创建期间修改 LB，而不能在更新时修改。

• 创建服务
• 更新服务

看来我们需要一个蓝/绿部署，一个 LB 和两个 LB 服务同时存在于同一个集群上。我希望我们需要在此更改之前创建多个任务集和其余的蓝/绿方法（无论如何我们都计划这样做，只是现在没有）

有没有人有这个场景的一个很好的例子，或者知道除了完全蓝/绿部署之外的任何其他方法？

我将两个不同版本的应用程序部署到两个 eks 集群，蓝色和绿色。我打算使用 route53 加权路由策略在蓝色和绿色之间切换。一旦我以蓝色和绿色部署应用程序，蓝色和绿色 eks 集群中的微服务会立即读取和更新数据库。我们一次只能有一个应用程序访问数据库。怎么做？

作为自动化测试的一部分，我想在 Custom Headers 的帮助下将我的 Testcafe 测试指向一个 Test Prod 服务器（绿色）。

如何在启动以执行测试作为参数时将自定义标头传递给 chrome 实例。

尝试过 chrome:userProfile 但每个版本的标题都会更改。

需要一种通用的方式来传递自定义标头。

注意：Testcafe 脚本更改不可取。

背景：

我有一个现有的蓝/绿架构设置，它使用两个负载均衡器（蓝/绿），并基于 Route53 配置进行交换。这些负载均衡器中的每组应用程序都有自己独特的蓝/绿目标组，以及自己的安全组（蓝/绿共享）。

由于各种原因，我正在考虑更改此设置以使用单个负载均衡器，但只需交换目标组。

我正在使用 CDK 来执行此操作。我正在为这个负载均衡器中的新实例重新使用现有的安全组。当我部署 CloudFormation 时，它确认我想要修改安全组以允许来自新负载均衡器的入口。说得通; 是的，我愿意。

这是添加的结果 cloudformation 的片段AWS::EC2::SecurityGroupIngress。

sg-XXXXXCDK 的参数在哪里sg-YYYYYY，而 ALB 的 SG 也在此特定 CloudFormation 之外进行管理。SG 本身不是此 Cloudformation 的一部分。

因此，通过 CDK 的“部署”可能会更改 CloudFormation 模板以交换负载均衡器正在使用的蓝/绿目标组。我正在使用测试侦听器端口（8443）。因此，无论哪个目标群体是“次要的”，都会被连接到那个听众。如果我完全关闭一侧，那么我将 prod 和 test listener (443/8443) 都映射到同一个（活动）目标组。这种模仿 ECS 蓝/绿部署的情况。但是，就我而言，我正在使用 EC2 实例/AMI 执行此操作。

问题

当我拆除这个云层时，它正确地撤消了AWS::EC2::SecurityGroupIngress添加。然而，它似乎也AWS::EC2::SecurityGroupIngress从当前的蓝/绿负载均衡器中删除了现有规则，这使得这些应用程序在蓝/绿 ALB 中无法访问/不健康，因为它们无法在端口 80 上获得成功的健康检查。

我可以在 CloudTrail 中知道发生了一个RevokeSecurityGroupIngres事件。但是，它运行蓝色/绿色 ALB 之一，而不是/附加到新的/单个 ALB。

这是该事件的净化版本：

问题

是否有什么我做错了导致拆除删除与 CloudFormation 无关的入口规则？

有没有人见过这个？

考虑到这种情况：

1. 代表蓝色集群的 Auto-Scaling Group (ASG) 正在负载均衡器后面运行 Web 应用程序
2. 另一个代表绿色集群的 ASG 部署了新版本的 Web 应用程序，连接到同一个负载均衡器。但是因为这个绿色集群还没有准备好，它会返回 HTTP 503（暂时不可用）。由于 503 返回码，负载均衡器将继续将所有流量路由到蓝色环境并忽略绿色环境。
3. 绿色集群将自动将数据迁移到新版本（由应用程序代码本身完成）。
4. 迁移完成后，绿色集群会告诉蓝色集群返回 503 并开始返回 HTTP 200。
5. 负载均衡器现在应该开始将流量路由到绿色集群。

是否可以将 AWS 设置为在同一个负载均衡器后面有两个 ASG（代表蓝色和绿色），以便在 ASG 上运行的应用程序可以使用 HTTP 代码来控制哪个集群（蓝色或绿色）正在接收流量，但是没有 ASG 杀戮机器？

我知道 CodeDeploy 可以在这里提供帮助，但我正在寻找一种与供应商无关的解决方案，该解决方案适用于 AWS、Azure 和任何传统（本地）负载均衡器。

我正在研究 DevOps 解决方案，并尝试在 kubernetes 上自动化蓝绿部署解决方案。但是，我们面临的问题是，在移除虚拟服务时，istio 应用路由规则太慢，并且需要很长时间才能生效。我们试图等待 60 秒来等待规则更新并销毁旧的 pod。我们没有想法说6​​0s就足以完成路线变更，如果超过60s就会有停机时间才能生效。想获得一些关于如何检查路线（仅限绿色路线）是否正确更新的建议？以及如何让 istio 应用执行得更快？谢谢。

这是应用虚拟服务的 yaml 文件：

我有两个 CloudFront 分配 A 和 B。

将 CNAME 分配给分发 A（blue.domain.com 和 domain.com）并创建了适当的 SSL 证书。在 Route53 中，我可以为分发分配别名（例如 domain.com -> blue.domain.com）

关于aws 文档，我无法将相同的 CNAME 分配给分布 B（green.domain.com 和domain.com），因为 CNAME domain.com已分配给分布 A。

我打算使用 Route53 在蓝/绿分布之间切换流量。例如 domain.com 指向 blue.domain.com 然后让 domain.com 指向 green.domain.com

所以这种方法行不通。我又找到了一个：

• 将 Route53 更新为预期的 CloudFront 分配
• 从蓝色中删除 CNAME
• 将 CNAME 添加到绿色

但这会导致发行版 A 和 B 都停机，并且需要几个手动步骤。

有没有不同的方法来实现蓝/绿切换？