蓝绿色部署是一种释放管理策略,它通过运行两个相同的生产环境来减少停机时间和风险 — — 一个是目前服务流量(蓝色)和一个闲置(绿色). 当新版应用程序准备好后,它被部署到不活动环境中,经过彻底测试,然后换上流量。 这种方法消除了维护窗口的需求,可以立即回滚,并且提供了新旧代码之间的清洁分离。 最初由马丁·福勒和杰兹·汉布利所普及的蓝绿色部署已经成为现代DevOps做法的基石,特别是在与强大的CI/CD管道配对时。

蓝绿色部署为何重要

传统的部署方法——如滚动更新或金丝雀释放——仍然使用户在过渡期间面临部分故障或退化的性能,蓝绿色部署通过在新环境得到核实之前保持旧环境的充分运作来解决这个问题,这使各小组有信心频繁部署,甚至部署到对任务至关重要的系统。

  • 零下架时间部署: 应用程序无法使用时没有时间窗口.
  • 即时回滚:[ 如果出现问题,则在秒内恢复到旧环境的流量.
  • 生产中孤立测试:[ 在现实世界条件下验证新版本,而不影响用户.
  • 简化数据库迁移:可以用谨慎的系统化版本和后向兼容处理.
  • 改进的团队速度:[开发者可以更频繁地释放,而恐惧度更低.

将蓝绿色部署与CI/CD管道相结合

碳化氢化物/碳化物管道使建造、试验和部署阶段自动化。当与蓝绿色结合时,管道就成为环境转换的管弦。典型的流量是这样的:

  1. 构建和测试: 代码会触发构建。单元测试、集成测试和管道中运行的安全扫描。
  2. 部署到不活动环境: 管道将文物部署到目前不服务交通的环境(如绿色,如果蓝色是活动环境).
  3. 烟雾和验收试验:[] 自动试验在新环境下运行,以验证功能,性能,和数据的一致性.
  4. Switch 流量:]负载平衡器或DNS记录更新,将所有用户流量都引导到新环境.
  5. 部署后验证:[] 健康检查和监测持续一个冷却期.
  6. 清除(可选): 旧环境要么作为回滚目标保存,要么在冷却期后被摧毁.

设置两个相同的环境

环境均等至关重要。 蓝绿色环境在硬件、配置、网络地形和数据方面必须完全相同, 应用程序版本除外。 使用Terraform、 Cloud Formation 或 Pulumi 等基础设施作为代码( IaC) 工具, 从同一模板中提供两种环境。 数据库复制应设置, 使两个环境共享相同的数据集( 或有一个允许安全改变计划的迁移策略 ) 。

数据库的考虑

国家服务——特别是数据库——复杂的蓝绿色部署。

  • 背向兼容的迁移:[ 应用既与新旧代码同时有效的更改(例如,添加列但不要丢弃).
  • 复制和读取复制:[将两个环境都指向同一个数据库,但确保只从活动环境进行写作.
  • chema-per-environment: 将每个环境的数据库隔离,用迁移工具处理同步.

飞威或利基巴基等工具可以管理对蓝绿色流动安全的递增迁移.

自动换乘交通

流量交换可以在负载平衡器(Layer 7), DNS(Layer 4/7) 或路由器级别上执行。 对于云内部署,例如AWS ALB, Google 云载平衡器, 或Kubernetes Service+ Ingress等服务, 使这一操作简单易行。 CI/CD 管道应通过 API 调用或配置更新触发开关。 主要考虑:

  • 健康检查:负载平衡器必须验证新环境健康后才能接受流量.
  • 高强度排水: 旧环境在被取出旋转前,应完成飞行请求.
  • 持续会话: 如果您的应用程序使用粘度会话, 请确保开关不会中断用户上下文。 请考虑外部会话存储( Redis, Memcached) 。

简化使用CI/CD的蓝绿色工具

各种CI/CD平台和部署工具都对蓝绿色战略有本土支持。

带有Ansible或Spinnaker的詹金斯语Name

Jenkins 高度灵活。 您可以定义管道步骤, 使用 Ansible 播放器来更新负载平衡器配置, 或者使用 Spinnaker 的内置红/黑策略。 Spinnaker 甚至在切换前提供可视化的 UI 供手动批准 。

GitLab 带有自动 DevOps 的 CI

GitLab Auto DevOps 包括一个内置的“蓝绿色部署”阶段,部署到Kubernetes时,它创建了两个部署(蓝绿色)和一个翻转“主动选择”标签的服务。 GitLab 的文档[ 提供了一步步的引导。

GitHub 动作, 带有 AWS 代码部署

AWS 代码Deplob 本地支持蓝绿色部署. GitHub Action 工作流程可以将代码推向 S3 桶,然后触发代码Deplob 应用程序修订。部署组自动提供新实例,检查健康,并进行换行流量。 AWS 文档解释设置 。

库伯涅的阿尔戈推出

Argo Rollouts提供包括蓝绿色在内的高级部署策略,它与入侵控制器集成,并服务 meshes实现交通自动转移. Rollbacks是可声明的,可以根据度量标准自动触发. 更多关于Argo Rollouts.

生产-分级部署的最佳做法

实施蓝绿色不仅仅是切换服务器。为了避免常见的陷阱,遵循这些最佳做法:

自动化所有

人工步骤引入错误,从建筑物到转换流量的整个管道应自动化,使用版本控制的管道定义(例如`Jenkinsfile ' 、`.gitlab-ci.yml ' 、工作流程YAMLs),并确保每次部署时自动进行测试。

使用特性标记

将蓝绿色与特性旗合并, 以解析发布时的部署。 您可以部署包含隐藏的新特性的代码, 并让它们通过旗帜管理工具( LaunchDarkly, PostHog, Unleash) 逐步实现。 如果一个特性失败, 则无需将整个环境向后滚动 。

实施综合测试

烟雾测试应该验证基本的HTTP响应,数据库连接,以及关键的用户行程. 使用合成监测工具(如Checkly,Datadog合成器)在切换前对不活动环境进行浏览器测试. 包含负载测试以捕捉性能回归.

连续监测

切换后, 监视应用程序的度量, 误差率, 空闲度, 以及商业 KPI 。 如果突破异常阈值, 使用提醒( PagerDuty, Opsgenie) 来触发自动回滚。 例如, 如果 5xxx 错误增加50%, 将流量恢复到旧环境 。

国家组成部分计划

文件上传、用户会话和任务队列需要小心处理。使用外部共享存储(S3、EFS)和分布式缓存(Redis、Memcached),两种环境都可以访问。对于队列,请确保消息不会在切换过程中丢失。

定义一个冷却期

切换流量后, 保持旧环境运行一段时间( 如30分钟) , 如果发现微妙的bug, 可以快速回滚。 之后, 您可以将其卸载以节省成本 。

挑战与如何战胜它们

数据库Schema迁移

最大的挑战是处理打破后向兼容性的数据库更改。

  • 只使用添加剂迁移(添加列,而不是丢弃).
  • 删除旧列的单独后切换移位 。
  • 在新应用版本之前部署数据库更改,确保旧代码仍然可以运行.

费用

运行两个相同的生产环境,使基础设施成本翻一番。 缓解:在测试时对不活动环境使用较小的例,或者使用容器来分享基本资源。云自动缩放也可以减少浪费。

会话和缓存温暖上移

当流量交换时,缓存是冷的。在切换前模拟典型用户请求,预温新环境。Gatling或k6等工具可以产生现实的负载。

网络配置

防火墙规则、 DNS 记录和 SSL 证书必须在不同的环境中相同。 使用 IaC 来保证一致性。 如果使用基于 DNS 的切换, 请记录传播时间( TTL ) 。

实例:电子商务平台

每周需要使用新功能, 而非停机时间。

  • ALB背后有两个AWS自动缩放组(蓝色,绿色).
  • 提供相同基础设施的地面。
  • GitLab CI管道:构建,测试,部署到绿色,运行Playwright烟雾测试,然后触发ALB目标组切换.
  • 重复用于各环境共享的会话 。
  • 数据库迁移:向后兼容,与飞威相配.
  • 如果错误率大于 1, 则在前5分钟自动回滚 。

结果:部署频率从每月增加至每周,6个月里零次停机事件。

结论

蓝绿色部署与现代的CI/CD管道相结合,提供了安全而频繁地发布软件的有力途径。它消除了故障时间,使迅速回滚,并让工程师有信心推动变化。虽然存在数据库迁移和基础设施成本等挑战,但可以通过精心规划和正确的工具加以管理。通过将整个过程自动化,从环境提供到交通转换,小组可以实现持续提供,风险最小。从小开始,用一个服务来证明概念,从那里扩大规模。蓝绿色部署的投资在减少事件反应时间和改善用户经验方面是有好处的。