• 构建和部署变量
• 数据库变量
• 作业跳过变量
• 配置应用程序密钥变量
  • Kubernetes 密钥
• 更新应用程序密钥
• 配置副本变量
  • 自定义副本变量
• 测试和生产环境的部署策略
• 金丝雀环境的部署策略
• 生产环境的增量发布
  • 示例增量发布配置
• 生产环境的定时增量发布

使用 CI/CD 变量来设置自动 DevOps 域名，提供自定义 Helm chart 或扩展您的应用程序。

构建和部署变量

使用这些变量来自定义和部署您的构建。

数据库变量

{{< alert type=”warning” >}}

从 极狐GitLab 16.0 开始，POSTGRES_ENABLED 不再默认设置。

{{< /alert >}}

使用这些变量将 CI/CD 与 PostgreSQL 数据库集成。

作业跳过变量

使用这些变量来跳过特定类型的 CI/CD 作业。当被跳过时，CI/CD 作业不会被创建或运行。

配置应用程序密钥变量

某些已部署的应用程序需要访问密钥变量。自动 DevOps 检测以 K8S_SECRET_ 开头的 CI/CD 变量，并将它们作为环境变量提供给已部署的应用程序。

前提条件：

• 变量值必须是单行。

要配置密钥变量：

1. 在左侧边栏，选择 搜索或前往 并找到您的项目。
2. 选择 设置 > CI/CD。
3. 展开 变量。
4. 创建一个以 K8S_SECRET_ 前缀开头的 CI/CD 变量。例如，您可以创建一个名为 K8S_SECRET_RAILS_MASTER_KEY 的变量。
5. 运行一个自动 DevOps 流水线，可以通过手动创建新的流水线或推送代码更改到极狐GitLab。

Kubernetes 密钥

自动 DevOps 流水线使用您的应用程序密钥变量来填充 Kubernetes 密钥。此密钥是每个环境唯一的。在部署您的应用程序时，密钥作为环境变量加载到运行应用程序的容器中。例如，如果您创建了一个名为 K8S_SECRET_RAILS_MASTER_KEY 的密钥，您的 Kubernetes 密钥可能看起来像这样：

$ kubectl get secret production-secret -n minimal-ruby-app-54 -o yaml

apiVersion: v1
data:
  RAILS_MASTER_KEY: MTIzNC10ZXN0
kind: Secret
metadata:
  creationTimestamp: 2018-12-20T01:48:26Z
  name: production-secret
  namespace: minimal-ruby-app-54
  resourceVersion: "429422"
  selfLink: /api/v1/namespaces/minimal-ruby-app-54/secrets/production-secret
  uid: 57ac2bfd-03f9-11e9-b812-42010a9400e4
type: Opaque

更新应用程序密钥

环境变量在 Kubernetes pod 中通常是不可变的。如果您更新了应用程序密钥，然后手动创建了一个新的流水线，正在运行的应用程序不会接收到更新后的密钥。

要更新应用程序密钥，可以选择：

• 推送代码更新到极狐GitLab，强制 Kubernetes 部署重新创建 pod。
• 手动删除正在运行的 pod，导致 Kubernetes 创建新的 pod 并更新密钥。

由于自动 DevOps 脚本环境的限制，不支持具有多行值的变量。

配置副本变量

当您想要扩展部署时，添加副本变量：

1. 添加副本变量作为项目 CI/CD 变量。

2. 要扩展您的应用程序，请重新部署它。

   {{< alert type=”warning” >}}

   不要直接使用 Kubernetes 扩展您的应用程序。Helm 可能无法检测到更改，而后续使用自动 DevOps 的部署可能会撤销您的更改。

   {{< /alert >}}

自定义副本变量

您可以创建格式为 <TRACK>_<ENV>_REPLICAS 的自定义副本变量：

• <TRACK> 是在 Helm Chart 应用定义中设置的 track Kubernetes 标签 的全大写值。如果未设置 track，则从自定义变量中省略 <TRACK>。
• <ENV> 是在 .gitlab-ci.yml 中设置的部署作业的全大写环境名称。

例如，如果环境是 qa 且轨迹是 foo，请创建一个名为 FOO_QA_REPLICAS 的环境变量：

QA testing:
  stage: deploy
  environment:
    name: qa
  script:
    - deploy foo

应用程序的 Helm chart 中必须定义轨迹 foo。例如：

replicaCount: 1
image:
  repository: gitlab.example.com/group/project
  tag: stable
  pullPolicy: Always
  secrets:
    - name: gitlab-registry
application:
  track: foo
  tier: web
service:
  enabled: true
  name: web
  type: ClusterIP
  url: http://my.host.com/
  externalPort: 5000
  internalPort: 5000

测试和生产环境的部署策略

自动 DevOps 通常使用持续部署，并在默认分支上运行新的流水线时自动推送到 production 环境。要手动部署到生产环境，您可以使用 STAGING_ENABLED CI/CD 变量。

如果您设置 STAGING_ENABLED，极狐GitLab 会自动将应用程序部署到 staging 环境。当您准备好部署到生产环境时，极狐GitLab 会创建一个 production_manual 作业。

您还可以在项目设置中启用手动部署。

金丝雀环境的部署策略

{{< details >}}

• 等级：专业版，旗舰版
• 提供：JihuLab.com，私有化部署

{{< /details >}}

您可以在将任何更改部署到生产之前使用 金丝雀环境。

如果您设置 CANARY_ENABLED，极狐GitLab 会创建两个手动作业：

• canary - 将应用程序部署到金丝雀环境。
• production_manual - 将应用程序部署到生产环境。

生产环境的增量发布

{{< details >}}

• 等级：专业版，旗舰版
• 提供：JihuLab.com，私有化部署

{{< /details >}}

使用增量发布来持续部署您的应用程序，从仅几个 pod 开始。您可以手动增加 pod 的数量。

您可以在项目设置中启用手动部署，或者通过设置 INCREMENTAL_ROLLOUT_MODE 为 manual。

如果您将 INCREMENTAL_ROLLOUT_MODE 设置为 manual，极狐GitLab 会创建四个手动作业：

1. rollout 10%
2. rollout 25%
3. rollout 50%
4. rollout 100%

百分比基于 REPLICAS CI/CD 变量，并定义用于部署的 pod 数量。例如，如果值为 10 并且您运行 10% rollout 作业，您的应用程序将仅部署到一个 pod。

您可以按任意顺序运行 rollout 作业。要缩减规模，请重新运行较低百分比的作业。

在您运行 rollout 100% 作业后，您无法缩减规模，必须回滚您的部署。

示例增量发布配置

没有 INCREMENTAL_ROLLOUT_MODE 且没有 STAGING_ENABLED：

没有 INCREMENTAL_ROLLOUT_MODE 且有 STAGING_ENABLED：

设置 INCREMENTAL_ROLLOUT_MODE 为 manual 且没有 STAGING_ENABLED：

设置 INCREMENTAL_ROLLOUT_MODE 为 manual 且有 STAGING_ENABLED：

生产环境的定时增量发布

{{< details >}}

• 等级：专业版，旗舰版
• 提供：JihuLab.com, 私有化部署

{{< /details >}}

使用定时增量发布来持续部署您的应用程序，从仅几个 pod 开始。

您可以在项目设置中启用定时增量部署，或者通过设置 INCREMENTAL_ROLLOUT_MODE CI/CD 变量为 timed。

如果您将 INCREMENTAL_ROLLOUT_MODE 设置为 timed，极狐GitLab 会创建四个作业：

1. timed rollout 10%
2. timed rollout 25%
3. timed rollout 50%
4. timed rollout 100%

每个作业之间有五分钟的延迟。