{{< details >}}
- Tier: 基础版,专业版,旗舰版
- Offering: JihuLab.com, 私有化部署
{{< /details >}}
当对应用进行更改时,可以仅将生产变更发布到 Kubernetes pods 的一部分作为风险缓解策略。通过逐步发布生产变更,可以监控错误率或性能下降,如果没有问题,所有 pods 都可以更新。
极狐GitLab 支持使用增量发布手动触发和定时发布到 Kubernetes 生产系统。在使用手动发布时,每一批 pods 的发布是手动触发的,而在定时发布中,发布是在默认暂停 5 分钟后以批次进行。定时发布也可以在暂停期结束前手动触发。
手动和定时发布自动包含在由 自动 DevOps 控制的项目中,但它们也可以通过极狐GitLab CI/CD 在 .gitlab-ci.yml
配置文件中进行配置。
手动触发的发布可以通过持续交付来实现,而定时发布不需要干预,可以成为您持续部署策略的一部分。您也可以将两者结合,以便应用自动部署,除非您需要手动干预。
手动发布
可以通过 .gitlab-ci.yml
手动配置极狐GitLab 进行增量发布。手动配置允许更好地控制此功能。增量发布的步骤取决于为部署定义的 pods 数量,这些 pods 在创建 Kubernetes 集群时进行配置。
例如,如果您的应用有 10 个 pods,并运行 10% 发布作业,则应用的新实例部署到一个 pod,而其余 pods 显示应用的先前实例。
首先我们 将模板定义为手动:
.manual_rollout_template: &manual_rollout_template
<<: *rollout_template
stage: production
when: manual
然后我们定义每个步骤的发布量:
rollout 10%:
<<: *manual_rollout_template
variables:
ROLLOUT_PERCENTAGE: 10
作业构建完成后,选择作业名称旁边的 运行 ({{< icon name=”play” >}}) 来发布每个阶段的 pods。您也可以通过运行较低百分比的作业来回滚。一旦达到 100%,您不能使用此方法回滚。要回滚部署,请参见 重试或回滚部署。
定时发布
定时发布的行为与手动发布相同,只是每个作业在部署前都有定义的延迟时间(以分钟为单位)。选择作业会显示倒计时。
可以将此功能与手动增量发布结合使用,以便作业在倒计时后自动部署。
首先我们将模板定义为定时:
.timed_rollout_template: &timed_rollout_template
<<: *rollout_template
when: delayed
start_in: 1 minutes
我们可以使用 start_in
键定义延迟时间:
start_in: 1 minutes
然后我们定义每个步骤的发布量:
timed rollout 30%:
<<: *timed_rollout_template
stage: timed rollout 30%
variables:
ROLLOUT_PERCENTAGE: 30
蓝绿部署
{{< alert type=”note” >}}
团队可以利用 Ingress 注释并 设置流量权重 作为蓝绿部署策略的替代方法。
{{< /alert >}}
有时也称为 A/B 部署或红黑部署,这种技术用于减少部署期间的停机时间和风险。结合增量发布,您可以最大限度地减少因部署导致议题的影响。
使用这种技术时,有两个部署(“蓝”和“绿”,但可以使用任何命名)。除了增量发布期间,任何时候只有一个部署是实时的。
例如,您的蓝色部署可以在生产中活动,而绿色部署是用于测试的“实时”状态,但未部署到生产中。如果发现问题,绿色部署可以在不影响生产部署(当前为蓝色)的情况下更新。如果测试没有发现问题,您可以将生产切换到绿色部署,蓝色现在可用于测试下一个版本。
此过程减少了停机时间,因为无需关闭生产部署来切换到不同的部署。两个部署同时运行,可以随时切换。