我正在 Azure DevOps 中重新创建我们非常复杂的部署过程。目前，我们的实时环境由负载均衡器后面的 4 个虚拟机组成。

我考虑的策略是一种蓝绿部署，只是我每次都将在一半(2) 的虚拟机上工作。
这不像滚动部署，因为不会有 2 个版本同时运行。

一旦我完成前半部分的部署并确保它已启动并运行，我将连接它并立即断开另一半的连接以将新版本也部署到它。

因为不幸的是，IP 是硬编码的，所以我现在不能按照本书（在新版本中部署一组完整的独立虚拟机）做蓝绿。仅在部署时使用 2 个虚拟机，实时环境就可以了。

我的问题是如何在 Azure DevOps 中为这种解决方案配置发布管道（我使用 GUI 版本，而不是 YAML）？（这些是阶段）

DbConversionDev > FirstHalfDev > SecondHalfDev > DbConversionQA > FirstHalfQA > SecondHalfQA > DbConversionProd > FirstHalfProd > SecondHalfProd

也许数据库转换阶段可以并行。

它看起来很复杂，很难维护。有什么建议么？提前致谢 ：）

我需要帮助才能实现蓝绿部署。

我的桶里有什么——

1. 一个托管在 ElasticBeanStalk 上的蓝色环境。
2. 在 ElasticBeanStalk 上托管的一个绿色环境。
3. 两个环境都是由 CF-Template 创建的。两者都有自己的 ELB。

我在找什么——

1. 我需要将流量从蓝色切换到绿色。
2. 首先，我需要知道哪个环境当前处于活动状态，以便我可以将我的应用程序部署计划到下一个环境。
3. 一旦我知道我当前的环境（在这种情况下为蓝色），我将我的应用程序部署到绿色环境，现在这个环境已准备好接受流量。
4. 我需要将 25% 的流量迁移到 Green 并进行健康检查，如果健康检查没问题，我将再添加 25% 的流量并进行健康检查等等。
5. 在任何时候，如果健康检查失败，我应该能够将整个流量路由回蓝色环境。

我需要在我的 CI-CD 作业中实施此解决方案。我的 CI 工作是创建我的包并将其部署到 S3。我的 CD 工作是配置基础架构 (ElasticBeanStalk) 并将包上传到新创建的环境。

我正在执行 AWS Blue/Green 部署以测试基本的 apache 服务器，并且由于 CodeDeploy 经历了 B/G 部署的 4 个步骤，它停留在第 3 步，即将流量路由到替换实例大约半小时。即使花费了很长时间并重试了几次，我也无法弄清楚出了什么问题。我不知道我的设置是否正确。这是我的 B/G 部署设置。

1. 创建了一个orginalautoscalinggroup以两个实例命名的自动缩放组。
2. 创建了两个目标组，一个用于原始环境，第二个用于替换环境，即originaltargetgroup& replacementtargetgroup。
3. 附加originaltargetgroup成为 的一部分originalautoscalinggroup。
4. 即创建了一个应用程序负载均衡器apploadbalancer并将其附加到originaltargetgroup
5. 现在apploadbalancer附有originaltargetgroup哪个附有originalautoscalinggroup。

我的 Codedeploy B/G 配置如下所示。

1. 部署类型：B/G
2. 环境配置：自动复制 Amazon EC2 Auto Scaling 组
3. Amazon EC2 自动扩展组：originalautoscalinggroup
4. 流量重新路由：立即重新路由流量
5. 终止策略：终止部署组中的原始实例
6. 部署配置：CodeDeployDefault.AllAtOnce
7. 应用程序负载均衡器。
8. 目标组：originaltargetgroup

我认为我无法附加正确的负载均衡器或目标组。请帮忙。

图片1

图片2

我正在尝试在 ECS 上进行 BlueGreen 部署。当我在 ECS 集群上手动部署时，我的服务运行良好，并且通过了所有运行状况检查。但是，每当我在 ECS 上的同一服务上进行蓝绿部署时，它都会卡在安装阶段，直到超时。

超时后，我收到此错误“在等待替换任务集变得健康时部署超时。此超时时间为 60 分钟。” 我不知道现在该怎么办。

我已经应用了所有内容，测试了负载均衡器、目标组和 ecr，当我手动部署服务和测试时，它们似乎都运行良好。请找到我的 terraform 代码并帮助我解决这个问题。如果您需要更多详细信息，请告诉我。

ECS 集群

Fargate ECS 服务

代码管道

代码部署

appSpec.yml

任务定义

我正在尝试在 ECS 上进行蓝绿部署。我不确定为什么我的任务没有被代码部署替换，以及为什么它显示此错误“在等待替换任务集变得健康时部署超时。此超时时间为 60 分钟。”

虽然我的替换任务很健康。我附上了我的截图显示所有。请任何人都可以告诉我是什么导致了这个问题。

事件（编辑添加事件）

我们公司的网站很快将托管在 Azure 的应用服务中。该网站与同样托管在 Azure 中的 API 层进行通信，并链接到我们的内部系统和数据库。这个级别的架构此时无法更改，并且有相当多的背景历史等。

我们正在考虑在 Azure 的应用服务中使用部署槽实现始终在部署上。API 层将针对每个部署进行非破坏性更改，部署 API 将是任何版本的第一部分，随后是网站。

我们的环境之间有明确的分离，并且在生产部署开始之前，将在 Dev、Test 和 Pre-Prod 环境中对发布进行测试。总体而言，整个过程相当简单，直到涉及实施后 (PI) 测试，目前这在我们公司是强制性的。

我们需要能够在客户使用该站点之前测试生产部署。目前，我们将站点切换到维护模式，除非它是从选定的 IP 地址列表中访问的。我们现在需要在新版本的站点上执行 PI 测试，同时客户继续使用旧版本的站点。我不确定实现这一目标的最佳方法。

我确实有一个想法是有一个子域直接链接到网站 _staging 部署槽绕过部署槽设置。反过来，这里的一些逻辑可以直接进入 API _staging 部署槽。这将提供在单击“交换”按钮以交换部署槽之前发布实施更改的选项。

我知道整个过程并不理想，但目前无法更改。请问有人对上述内容有任何想法或其他建议吗？

我们有一个使用 React（和 nginx）构建的 Web 界面和一个 Rest API（带有 json 模式验证）。它们位于不同的存储库中。我们的集群是私有的 openshift (3.11)

我们希望实现零停机部署。让我们假设：

1. 我们有 10 个用于 Web 的 pod 和 20 个用于 Rest API 的 pod。
2. 我们想将 WEB 和 API 从 1.0.0 升级到 2.0.0
3. 新版WEB只支持新版API
4. 每个 repo（WEB 和 API）都有自己的 helm chart（如果需要并且推荐，我们可以创建一个额外的存储库，其中包含一个部署 web 和 api 的 helm chart）

我们应该使用哪种部署策略？（蓝/绿、金丝雀、a/b？）

我们如何配置新的 WEB pod 以访问 API 的唯一新服务：

• WEB 1.0.0 --> API 1.0.0
• WEB 2.0.0 --> API 2.0.0

我们如何在零停机的情况下执行升级？

非常重要的是，在升级过程中，WEB 的新版本应该只打新版本的 API，而已经部署的 pods（1.0.0）应该继续打旧版本的 API。

我想创建一个 CodePipeline，它从 CodeCommit 源构建容器映像，然后以蓝/绿方式将新映像部署到我的 ECS 服务（EC2 启动类型）。

• 源阶段是 CodeCommit，它已经包含 appspec.json
  以及 taskdef.json
• 构建阶段正在构建新容器并成功将其推送到 ECR，文件 imagedefinition.json 是此步骤创建的 BuildArtifact，包含容器和最近创建的镜像，其标签对应于 CodeCommit 提交 ID。
• 部署阶段由动作“Amazon ECS (Blue/Green)”组成，使用 SourceArtifact 和 BuildArtifact 作为 InputArtifacts，从 SourceArtifact 中获取 appspec 和 taskdef 以及从 BuildArtifact 中获取图像描述，最终在 Blue/ 中部署新容器绿色方式。

问题在于 BuildArtifact 中的图像定义。管道在部署阶段失败并出现错误：

"" Invalid action configuration 尝试从工件读取图像工件文件时出现异常：BuildArtifact。“”

如何正确配置“Amazon ECS（蓝/绿）”部署阶段，以便它可以使用最近创建的映像并部署它....通过替换 taskdef.json 中的占位符 IMAGE_NAME ？

任何提示高度赞赏：D

我一直在尝试kubernetes使用nginx-ingress. 我创建了几个并发 http 请求来访问我的应用程序的 v1 版本。与此同时，我将路由器切换为指向我的应用程序的 v2 版本。正如预期的那样，v2 版本在交换后为请求提供服务，但让我好奇的是所有请求都成功了。在我进行交换时，很可能在 v1 中有一些正在进行的请求。为什么这样的请求没有失败？

我也通过在我的服务中引入一些延迟来尝试相同的方法，以便请求需要更长的时间来处理。仍然没有一个请求失败。

使用私有域在 Pivotal Cloud Foundry 中处理蓝/绿部署的最佳方法是什么。我们的基础设施已经设置了共享域，我们希望转向私有域，因为它为我们提供了在多个空间和组织中使用相同域名的灵活性。

下面是如果域是共享的但私有域失败的情况。

私有域：test.private.com Space A：蓝色申请路线：https ://test.private.com/V1/test/ 绿色申请路线：https ://test.private.com/V1/test/

PCF 不允许我们在同一空间中创建具有相同域 + 路径的路由以利用蓝/绿部署模型。

有没有办法可以解决这个问题？