{{< 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 部署或红黑部署,这种技术用于减少部署期间的停机时间和风险。结合增量发布,您可以最大限度地减少因部署导致议题的影响。

使用这种技术时,有两个部署(“蓝”和“绿”,但可以使用任何命名)。除了增量发布期间,任何时候只有一个部署是实时的。

例如,您的蓝色部署可以在生产中活动,而绿色部署是用于测试的“实时”状态,但未部署到生产中。如果发现问题,绿色部署可以在不影响生产部署(当前为蓝色)的情况下更新。如果测试没有发现问题,您可以将生产切换到绿色部署,蓝色现在可用于测试下一个版本。

此过程减少了停机时间,因为无需关闭生产部署来切换到不同的部署。两个部署同时运行,可以随时切换。