210.md

# Customizing Auto DevOps

> 原文：[https://docs.gitlab.com/ee/topics/autodevops/customize.html](https://docs.gitlab.com/ee/topics/autodevops/customize.html)

*   [Custom buildpacks](#custom-buildpacks)
    *   [Multiple buildpacks](#multiple-buildpacks)
*   [Custom `Dockerfile`](#custom-dockerfile)
*   [Passing arguments to `docker build`](#passing-arguments-to-docker-build)
*   [Forward CI variables to the build environment](#forward-ci-variables-to-the-build-environment)
*   [Custom Helm Chart](#custom-helm-chart)
*   [Customize values for Helm Chart](#customize-values-for-helm-chart)
*   [Custom Helm chart per environment](#custom-helm-chart-per-environment)
*   [Customizing `.gitlab-ci.yml`](#customizing-gitlab-ciyml)
*   [Customizing the Kubernetes namespace](#customizing-the-kubernetes-namespace)
*   [Using components of Auto DevOps](#using-components-of-auto-devops)
*   [PostgreSQL database support](#postgresql-database-support)
    *   [Upgrading PostgresSQL](#upgrading-postgressql)
    *   [Using external PostgreSQL database providers](#using-external-postgresql-database-providers)
*   [Environment variables](#environment-variables)
    *   [Build and deployment](#build-and-deployment)
    *   [Database](#database)
    *   [Disable jobs](#disable-jobs)
    *   [Application secret variables](#application-secret-variables)
    *   [Advanced replica variables setup](#advanced-replica-variables-setup)
    *   [Deploy policy for staging and production environments](#deploy-policy-for-staging-and-production-environments)
    *   [Deploy policy for canary environments](#deploy-policy-for-canary-environments-premium)
    *   [Incremental rollout to production](#incremental-rollout-to-production-premium)
    *   [Timed incremental rollout to production](#timed-incremental-rollout-to-production-premium)
*   [Auto DevOps banner](#auto-devops-banner)

# Customizing Auto DevOps[](#customizing-auto-devops "Permalink")

尽管[Auto DevOps](index.html)提供了很好的默认设置来帮助您入门，但是您可以自定义几乎所有内容以满足您的需求. Auto DevOps 提供了从自定义[buildpacks](#custom-buildpacks)到[Dockerfiles](#custom-dockerfile)和[Helm 图表的所有内容](#custom-helm-chart) . 您甚至可以将完整的[CI / CD 配置](#customizing-gitlab-ciyml)复制到您的项目中，以启用暂存和 Canary 部署等.

## Custom buildpacks[](#custom-buildpacks "Permalink")

如果您的项目无法自动检测到构建包，或者要使用自定义构建包，则可以在项目中使用项目变量或`.buildpacks`文件覆盖`.buildpacks` ：

*   **项目变量** -使用要使用的 buildpack 的 URL 创建项目变量`BUILDPACK_URL` .
*   **`.buildpacks`文件** -在项目的存储库中添加一个名为`.buildpacks`的文件，并添加要在文件中一行使用的 buildpack 的 URL. 如果要使用多个 buildpack，请每行输入一个 buildpack.

buildpack URL 可以指向 Git 存储库 URL 或 tarball URL. 对于 Git 存储库，您可以通过将`#<ref>`附加到 Git 存储库 URL 来指向特定的 Git 引用（例如，提交 SHA，标记名称或分支名称）. 例如：

*   标签`v142` ： `https://github.com/heroku/heroku-buildpack-ruby.git#v142` : `https://github.com/heroku/heroku-buildpack-ruby.git#v142` .
*   分支`mybranch` ： `https://github.com/heroku/heroku-buildpack-ruby.git#mybranch` : `https://github.com/heroku/heroku-buildpack-ruby.git#mybranch` .
*   提交 SHA `f97d8a8ab49` ： `https://github.com/heroku/heroku-buildpack-ruby.git#f97d8a8ab49` : `https://github.com/heroku/heroku-buildpack-ruby.git#f97d8a8ab49` .

### Multiple buildpacks[](#multiple-buildpacks "Permalink")

Auto DevOps 不完全支持使用多个 buildpack，因为在使用`.buildpacks`文件时，自动测试将不起作用. 在后端用于解析`.buildpacks`文件的 buildpack [heroku-buildpack-multi](https://github.com/heroku/heroku-buildpack-multi/)没有提供必要的命令`bin/test-compile`和`bin/test` .

If your goal is to use only a single custom buildpack, you should provide the project variable `BUILDPACK_URL` instead.

## Custom `Dockerfile`[](#custom-dockerfile "Permalink")

> [在 GitLab 13.2](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/35662)中[添加了](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/35662)对`DOCKERFILE_PATH`支持

如果您的项目在项目存储库的根目录中有一个`Dockerfile` ，则 Auto DevOps 会基于 Dockerfile 而不是使用 buildpacks 构建 Docker 映像. 这样可以更快，并产生较小的映像，尤其是在您的 Dockerfile 基于[Alpine 的情况下](https://hub.docker.com/_/alpine/) .

如果设置`DOCKERFILE_PATH` CI 变量，则"自动构建"将在其中查找 Dockerfile.

## Passing arguments to `docker build`[](#passing-arguments-to-docker-build "Permalink")

可以使用`AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS`项目变量将参数传递给`AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS` `docker build`命令. 例如，要基于`ruby:alpine`而不是默认的`ruby:latest`构建 Docker 映像：

1.  Set `AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS` to `--build-arg=RUBY_VERSION=alpine`.
2.  将以下内容添加到自定义`Dockerfile` ：

    ```
    ARG RUBY_VERSION=latest
    FROM ruby:$RUBY_VERSION

    # ... put your stuff here 
    ```

**注意：**如果需要传递复杂的值（例如换行符和空格）， **请**使用 Base64 编码. 由于 Auto DevOps 如何使用自变量，此类未经编码的复杂值可能导致转义问题.**警告：**尽可能避免将秘密作为 Docker 构建参数传递，因为它们可能会保留在映像中. 有关详细信息，请参见[有关最佳实践的讨论](https://github.com/moby/moby/issues/13490) .

## Forward CI variables to the build environment[](#forward-ci-variables-to-the-build-environment "Permalink")

在 GitLab 12.3 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/25514) ，但在 11.9 及更高版本中可用.

可以使用`AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` CI 变量将 CI 变量转发到构建环境中. 转发的变量应在逗号分隔的列表中按名称指定. 例如，要转发变量`CI_COMMIT_SHA`和`CI_ENVIRONMENT_NAME` ，请将`AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES`设置为`CI_COMMIT_SHA,CI_ENVIRONMENT_NAME` .

*   使用 Buildpacks 时，转发的变量将自动用作环境变量.
*   使用`Dockerfile` ，需要执行以下附加步骤：

    1.  通过将以下代码添加到文件顶部来激活实验性`Dockerfile`语法：

        ```
        # syntax = docker/dockerfile:experimental 
        ```

    2.  要在任何可用的秘密`RUN $COMMAND`在`Dockerfile` ，秘密文件和源安装运行之前，它`$COMMAND` ：

        ```
        RUN --mount=type=secret,id=auto-devops-build-secrets . /run/secrets/auto-devops-build-secrets && $COMMAND 
        ```

**注意：**设置`AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` ，Auto DevOps 会启用实验性[Docker BuildKit](https://s0docs0docker0com.icopy.site/develop/develop-images/build_enhancements/)功能以使用`--secret`标志.

## Custom Helm Chart[](#custom-helm-chart "Permalink")

Auto DevOps 使用[Helm](https://helm.sh/)将您的应用程序部署到 Kubernetes. 您可以通过将图表捆绑到项目存储库中或通过指定项目变量来覆盖使用的 Helm 图表：

*   **捆绑图** -如果您的项目中有一个带有`Chart.yaml`文件的`./chart`目录，则 Auto DevOps 将检测到该图并使用它代替[默认图](https://gitlab.com/gitlab-org/charts/auto-deploy-app) ，从而使您能够精确地控制应用程序的部署方式.
*   **项目变量** -创建一个[项目变量](../../ci/variables/README.html#gitlab-cicd-environment-variables) `AUTO_DEVOPS_CHART`有一个自定义图表的 URL 来使用，或创建两个项目变量： `AUTO_DEVOPS_CHART_REPOSITORY`有一个自定义图表库的 URL，并`AUTO_DEVOPS_CHART`与路径图.

## Customize values for Helm Chart[](#customize-values-for-helm-chart "Permalink")

[介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/30628)在 GitLab 12.6， `.gitlab/auto-deploy-values.yaml`将默认为头盔升级使用.

您可以通过以下任一方式覆盖[默认 Helm 图表中](https://gitlab.com/gitlab-org/charts/auto-deploy-app) `values.yaml`文件中的[默认值](https://gitlab.com/gitlab-org/charts/auto-deploy-app) ：

*   将名为`.gitlab/auto-deploy-values.yaml`的文件添加到您的存储库，如果找到，该文件将自动使用.
*   将具有不同名称或路径的文件添加到存储库，并使用路径和名称设置`HELM_UPGRADE_VALUES_FILE` [环境变量](#environment-variables) .

**注：**对于 GitLab 12.5 和更早的版本，使用`HELM_UPGRADE_EXTRA_ARGS`环境变量设置以覆盖默认图表值`HELM_UPGRADE_EXTRA_ARGS`到`--values <my-values.yaml>`

## Custom Helm chart per environment[](#custom-helm-chart-per-environment "Permalink")

您可以通过将环境变量定义为所需环境来指定每个环境使用自定义 Helm 图表. 请参阅[限制变量的环境范围](../../ci/variables/README.html#limit-the-environment-scopes-of-environment-variables) .

## Customizing `.gitlab-ci.yml`[](#customizing-gitlab-ciyml "Permalink")

Auto DevOps 是完全可自定义的，因为[Auto DevOps 模板](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)只是[`.gitlab-ci.yml`](../../ci/yaml/README.html)文件的实现，并且仅使用任何`.gitlab-ci.yml`实现的`.gitlab-ci.yml` .

要修改 Auto DevOps 使用的 CI / CD 管道，请[`include`模板](../../ci/yaml/README.html#includetemplate) ，并根据需要通过向包含以下内容的存储库的根目录中添加`.gitlab-ci.yml`文件来自定义它：

```
include:
  - template: Auto-DevOps.gitlab-ci.yml 
```

添加您的更改，您的添加将使用[`include`](../../ci/yaml/README.html#include)所描述的行为与[Auto DevOps 模板](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)合并.

如果您需要专门删除文件的一部分，还可以将[Auto DevOps 模板](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)的内容复制并粘贴到您的项目中，并根据需要进行编辑.

## Customizing the Kubernetes namespace[](#customizing-the-kubernetes-namespace "Permalink")

在 GitLab 12.6 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/27630) .

对于不受 GitLab 管理的集群，可以通过指定[`environment:kubernetes:namespace`](../../ci/environments/index.html#configuring-kubernetes-deployments)来自定义`.gitlab-ci.yml`的[`environment:kubernetes:namespace`](../../ci/environments/index.html#configuring-kubernetes-deployments) . 例如，以下配置将覆盖用于`production`部署的名称空间：

```
include:
  - template: Auto-DevOps.gitlab-ci.yml

production:
  environment:
    kubernetes:
      namespace: production 
```

使用 Auto DevOps 部署到自定义名称空间时，群集随附的服务帐户至少需要名称空间内的`edit`角色.

*   如果服务帐户可以创建名称空间，则可以按需创建名称空间.
*   否则，名称空间必须在部署之前存在.

## Using components of Auto DevOps[](#using-components-of-auto-devops "Permalink")

如果仅需要 Auto DevOps 提供的功能的子集，则可以将各个 Auto DevOps 作业包括在自己的`.gitlab-ci.yml` . 每个组件作业都依赖于一个阶段，该阶段应该在包含模板的`.gitlab-ci.yml`中定义.

例如，要使用[自动构建](stages.html#auto-build) ，可以将以下内容添加到`.gitlab-ci.yml` ：

```
stages:
  - build

include:
  - template: Jobs/Build.gitlab-ci.yml 
```

有关可用作业的信息，请参见[Auto DevOps 模板](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml) .

**弃用：**从[GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/213336)开始，使用[`only`](../../ci/yaml/README.html#onlyexcept-basic)或[`except`](../../ci/yaml/README.html#onlyexcept-basic)语法的 Auto DevOps 模板将切换到[`rules`](../../ci/yaml/README.html#rules)语法. 如果您`.gitlab-ci.yml`扩展了这些汽车的 DevOps 模板和覆盖`only`或`except`关键字，您必须迁移模板使用[`rules`](../../ci/yaml/README.html#rules)语法的基本模板被迁移到使用后`rules`语法. 对于尚不能迁移的用户，您可以选择将模板固定到[基于 GitLab 12.10 的模板](https://gitlab.com/gitlab-org/auto-devops-v12-10) .

## PostgreSQL database support[](#postgresql-database-support "Permalink")

为了支持需要数据库的应用程序，默认情况下配置[PostgreSQL](https://s0www0postgresql0org.icopy.site/) . 访问数据库的凭据已预先配置，但可以通过设置关联[变量](#environment-variables)进行自定义. 您可以使用这些凭据来定义`DATABASE_URL` ：

```
postgres://user:password@postgres-host:postgres-port/postgres-database 
```

### Upgrading PostgresSQL[](#upgrading-postgressql "Permalink")

**弃用：**用于控制默认`AUTO_DEVOPS_POSTGRES_CHANNEL`配置 PostgreSQL 的变量`AUTO_DEVOPS_POSTGRES_CHANNEL`在[GitLab 13.0 中](https://gitlab.com/gitlab-org/gitlab/-/issues/210499)已更改为`2` . 要继续使用旧的 PostgreSQL，请将`AUTO_DEVOPS_POSTGRES_CHANNEL`变量设置为`1` .

用于配置 PostgreSQL 的图表的版本：

*   在 GitLab 13.0 和更高版本中为 8.2.1，但如果需要可以将其设置回 0.7.1.
*   可以在 GitLab 12.9 和 12.10 中设置为 0.7.1 至 8.2.1.
*   在 GitLab 12.8 及更早版本中为 0.7.1.

GitLab 鼓励用户[将其数据库迁移](upgrading_postgresql.html)到较新的 PostgreSQL.

### Using external PostgreSQL database providers[](#using-external-postgresql-database-providers "Permalink")

尽管 Auto DevOps 为生产环境提供了对 PostgreSQL 容器的开箱即用支持，但在某些情况下，它可能不够安全或没有弹性，您可能要使用外部托管提供程序（例如 AWS Relational Database）服务）（适用于 PostgreSQL）.

您必须在项目的 CI / CD 设置中为`POSTGRES_ENABLED`和`DATABASE_URL`定义环境范围的变量：

1.  使用范围内的[环境变量](../../ci/environments/index.html#scoping-environments-with-specs)针对所需环境禁用内置 PostgreSQL 安装. 对于此用例，可能只需要将`production`添加到此列表中. 用于 Review Apps 和登台的内置 PostgreSQL 设置就足够了.

    [![Auto Metrics](img/f4a6d7020c73bd402fc6428d02a4e550.png)](img/disable_postgres.png)

2.  Define the `DATABASE_URL` CI variable as a scoped environment variable that will be available to your application. This should be a URL in the following format:

    ```
    postgres://user:password@postgres-host:postgres-port/postgres-database 
    ```

您必须确保您的 Kubernetes 集群可以访问托管 PostgreSQL 的任何地方的网络.

## Environment variables[](#environment-variables "Permalink")

以下变量可用于设置 Auto DevOps 域，提供自定义 Helm 图表或缩放应用程序. PostgreSQL 也可以自定义，您可以使用[自定义 buildpack](#custom-buildpacks) .

### Build and deployment[](#build-and-deployment "Permalink")

下表列出了与构建和部署应用程序有关的变量.

| **Variable** | **Description** |
| --- | --- |
| `ADDITIONAL_HOSTS` | 指定为逗号分隔列表的标准域名，添加到 Ingress 主机中. |
| `<ENVIRONMENT>_ADDITIONAL_HOSTS` | 对于特定环境，将指定为逗号分隔列表的标准域名添加到 Ingress 主机. 这优先于`ADDITIONAL_HOSTS` . |
| `AUTO_DEVOPS_ATOMIC_RELEASE` | 从 GitLab 13.0 开始，默认情况下，Auto DevOps 使用[`--atomic`](https://v2.helm.sh/docs/helm/#options-43)进行 Helm 部署. 将此变量设置为`false`可禁用`--atomic` |
| `AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED` | 当设置为非空值且不存在`Dockerfile` ，"自动构建"将使用 Cloud Native Buildpacks 而非 Herokuish 构建应用程序. [更多细节](stages.html#auto-build-using-cloud-native-buildpacks-beta) . |
| `AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER` | 使用 Cloud Native Buildpacks 构建时使用的构建器. 默认的构建器是`heroku/buildpacks:18` . [更多细节](stages.html#auto-build-using-cloud-native-buildpacks-beta) . |
| `AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS` | 要传递给`docker build`命令的额外参数. 请注意，使用引号不会阻止单词拆分. [更多细节](#passing-arguments-to-docker-build) . |
| `AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` | A [comma-separated list of CI variable names](#forward-ci-variables-to-the-build-environment) to be forwarded to the build environment (the buildpack builder or `docker build`). |
| `AUTO_DEVOPS_CHART` | Helm Chart 用于部署您的应用程序. 默认为[GitLab 提供的](https://gitlab.com/gitlab-org/charts/auto-deploy-app) . |
| `AUTO_DEVOPS_CHART_REPOSITORY` | Helm Chart 存储库用于搜索图表. 默认为`https://charts.gitlab.io` . |
| `AUTO_DEVOPS_CHART_REPOSITORY_NAME` | 从 GitLab 11.11 开始，用于设置 Helm 存储库的名称. 默认为`gitlab` . |
| `AUTO_DEVOPS_CHART_REPOSITORY_USERNAME` | 从 GitLab 11.11 开始，用于设置用户名以连接到 Helm 存储库. 默认为无凭据. 还要设置`AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD` . |
| `AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD` | 从 GitLab 11.11 开始，用于设置密码以连接到 Helm 存储库. 默认为无凭据. 还要设置`AUTO_DEVOPS_CHART_REPOSITORY_USERNAME` . |
| `AUTO_DEVOPS_DEPLOY_DEBUG` | 从 GitLab 13.1 开始，如果存在此变量，Helm 将输出调试日志. |
| `AUTO_DEVOPS_ALLOW_TO_FORCE_DEPLOY_V<N>` | 从[auto-deploy-image](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image) v1.0.0 起，如果存在此变量，则将强制部署新的主要图表版本. [更多细节](upgrading_chart.html#ignore-warning-and-continue-deploying) |
| `AUTO_DEVOPS_MODSECURITY_SEC_RULE_ENGINE` | 从 GitLab 12.5 起，与[ModSecurity 功能标记](../../user/clusters/applications.html#web-application-firewall-modsecurity)结合使用可切换[ModSecurity 的`SecRuleEngine`](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#SecRuleEngine)行为. 默认为`DetectionOnly` . |
| `BUILDPACK_URL` | Buildpack’s full URL. Can point to either [a Git repository URL or a tarball URL](#custom-buildpacks). |
| `CANARY_ENABLED` | 从 GitLab 11.0 开始，用于定义[Canary 环境](#deploy-policy-for-canary-environments-premium)的[部署策略](#deploy-policy-for-canary-environments-premium) . |
| `CANARY_PRODUCTION_REPLICAS` | 要在生产环境中为[Canary 部署](../../user/project/canary_deployments.html)进行部署的 Canary 副本数. 优先于`CANARY_REPLICAS` . 默认为 1. |
| `CANARY_REPLICAS` | 用于[Canary 部署](../../user/project/canary_deployments.html)的 Canary 副本数. 默认为 1. |
| `DOCKERFILE_PATH` | 从 GitLab 13.2 开始，允许[在构建阶段](#custom-dockerfile)覆盖[默认的 Dockerfile 路径](#custom-dockerfile) |
| `HELM_RELEASE_NAME` | 从 GitLab 12.1 起，可以覆盖`helm`发布名称. 将多个项目部署到单个名称空间时，可用于分配唯一的发行版名称. |
| `HELM_UPGRADE_VALUES_FILE` | 从 GitLab 12.6 起，可以覆盖`helm upgrade`值文件. 默认为`.gitlab/auto-deploy-values.yaml` . |
| `HELM_UPGRADE_EXTRA_ARGS` | 从 GitLab 11.11 开始，在部署应用程序时允许在`helm`命令中使用其他参数. 请注意，使用引号不会阻止单词拆分. |
| `INCREMENTAL_ROLLOUT_MODE` | 从 GitLab 11.4 起，如果存在的话，可用于为生产环境启用应用程序的[增量部署](#incremental-rollout-to-production-premium) . 对于手动部署作业，设置为" `manual` ；对于自动部署部署，则设置为" `timed` ，每个延迟 5 分钟. |
| `K8S_SECRET_*` | 从 GitLab 11.7 开始，Auto DevOps 会将任何前缀为[`K8S_SECRET_`](#application-secret-variables)变量作为环境变量提供给已部署的应用程序. |
| `KUBE_INGRESS_BASE_DOMAIN` | 从 GitLab 11.8 开始，可用于为每个群集设置一个域. 有关更多信息，请参见[群集域](../../user/project/clusters/index.html#base-domain) . |
| `PRODUCTION_REPLICAS` | 要在生产环境中部署的副本数. 优先于`REPLICAS` ，默认值为 1.对于零停机升级，设置为 2 或更大. |
| `REPLICAS` | 要部署的副本数. 默认为 1. |
| `ROLLOUT_RESOURCE_TYPE` | 从 GitLab 11.9 开始，允许使用自定义 Helm 图表指定正在部署的资源类型. 默认值为`deployment` . |
| `ROLLOUT_STATUS_DISABLED` | 从 GitLab 12.0 开始，用于禁用推出状态检查，因为它不支持所有资源类型，例如`cronjob` . |
| `STAGING_ENABLED` | 从 GitLab 10.8 开始，用于定义[登台和生产环境](#deploy-policy-for-staging-and-production-environments)的[部署策略](#deploy-policy-for-staging-and-production-environments) . |

**提示：**使用[项目变量](../../ci/variables/README.html#gitlab-cicd-environment-variables)设置副本[变量后](../../ci/variables/README.html#gitlab-cicd-environment-variables) ，可以通过重新部署来缩放应用程序.**注意：**您*不*应该直接扩展使用 Kubernetes 您的应用程序. 这可能会导致 Helm 无法检测到更改而造成混乱，随后使用 Auto DevOps 进行的部署可能会撤消您的更改.

### Database[](#database "Permalink")

下表列出了与数据库有关的变量.

| **Variable** | **Description** |
| --- | --- |
| `DB_INITIALIZE` | 从 GitLab 11.4 开始，用于指定运行以初始化应用程序的 PostgreSQL 数据库的命令. 在应用程序窗格中运行. |
| `DB_MIGRATE` | 从 GitLab 11.4 开始，用于指定运行以迁移应用程序的 PostgreSQL 数据库的命令. 在应用程序窗格中运行. |
| `POSTGRES_ENABLED` | 是否启用 PostgreSQL. 默认为`true` . 设置为`false`可禁用 PostgreSQL 的自动部署. |
| `POSTGRES_USER` | PostgreSQL 用户. 默认为`user` . 将其设置为使用自定义用户名. |
| `POSTGRES_PASSWORD` | PostgreSQL 密码. 默认为`testing-password` . 将其设置为使用自定义密码. |
| `POSTGRES_DB` | PostgreSQL 数据库名称. 默认为[`$CI_ENVIRONMENT_SLUG`](../../ci/variables/README.html#predefined-environment-variables)的值. 将其设置为使用自定义数据库名称. |
| `POSTGRES_VERSION` | 用于[`postgres` Docker 映像的](https://hub.docker.com/_/postgres)标签. 对于`9.6.16` GitLab 13.0 `9.6.16`的测试和部署，默认值为`9.6.16` （以前为`9.6.2` ）. 如果`AUTO_DEVOPS_POSTGRES_CHANNEL`设置为`1` ，则部署将使用默认版本`9.6.2` . |

### Disable jobs[](#disable-jobs "Permalink")

下表列出了用于禁用作业的变量.

| **Variable** | **Description** |
| --- | --- |
| `CODE_QUALITY_DISABLED` | 从 GitLab 11.0 起，用于禁用`codequality`作业. 如果存在变量，则不会创建作业. |
| `CONTAINER_SCANNING_DISABLED` | From GitLab 11.0, used to disable the `sast:container` job. If the variable is present, the job won’t be created. |
| `DAST_DISABLED` | 从 GitLab 11.0 起，用于禁用`dast`作业. 如果存在变量，则不会创建作业. |
| `DEPENDENCY_SCANNING_DISABLED` | 从 GitLab 11.0 起，用于禁用`dependency_scanning`作业. 如果存在变量，则不会创建作业. |
| `LICENSE_MANAGEMENT_DISABLED` | 从 GitLab 11.0 开始，用于禁用`license_management`作业. 如果存在变量，则不会创建作业. |
| `PERFORMANCE_DISABLED` | 从 GitLab 11.0 起，用于禁用浏览器`performance`作业. 如果存在变量，则不会创建作业. |
| `LOAD_PERFORMANCE_DISABLED` | 从 GitLab 13.2 开始，用于禁用`load_performance`作业. 如果存在变量，则不会创建作业. |
| `REVIEW_DISABLED` | 从 GitLab 11.0 开始，用于禁用`review`和手动`review:stop`作业. 如果存在该变量，则不会创建这些作业. |
| `SAST_DISABLED` | 从 GitLab 11.0 起，用于禁用`sast`作业. 如果存在变量，则不会创建作业. |
| `TEST_DISABLED` | 从 GitLab 11.0 起，用于禁用`test`作业. 如果存在变量，则不会创建作业. |

### Application secret variables[](#application-secret-variables "Permalink")

在 GitLab 11.7 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/49056) .

某些应用程序需要定义可由部署的应用程序访问的秘密变量. Auto DevOps 会检测以`K8S_SECRET_`开头的变量，并将这些带前缀的变量作为环境变量提供给已部署的应用程序.

要配置您的应用程序变量：

1.  Go to your project’s **设置> CI / CD**, then expand the **Variables** section.

2.  创建一个 CI / CD 变量，确保密钥以`K8S_SECRET_`为前缀. 例如，您可以使用键`K8S_SECRET_RAILS_MASTER_KEY`创建一个变量.

3.  通过手动创建新管道或将代码更改推送到 GitLab 来运行 Auto DevOps 管道.

Auto DevOps 管道将使用您的应用程序秘密变量来填充 Kubernetes 秘密. 这个秘密在每个环境中都是唯一的. 部署应用程序时，机密将作为环境变量加载到运行应用程序的容器中. 在上面的示例之后，您可以在下面看到包含`RAILS_MASTER_KEY`变量的机密.

```
$ 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 容器中是不可变的. 如果在不更改任何代码的情况下更新应用程序机密，然后手动创建新管道，则会发现任何正在运行的应用程序吊舱都不会具有更新后的机密. 要更新机密，请执行以下任一操作：

*   将代码更新推送到 GitLab，以强制 Kubernetes 部署重新创建 Pod.
*   手动删除正在运行的 Pod，以使 Kubernetes 创建具有更新机密的新 Pod.

**注意：**由于当前 Auto DevOps 脚本环境的限制，当前不支持具有多行值的变量.

### Advanced replica variables setup[](#advanced-replica-variables-setup "Permalink")

除了上面提到的两个与副本相关的生产变量之外，您还可以将其他变量用于不同的环境.

Kubernetes 的标签名为`track` ，GitLab CI / CD 环境名称和副本环境变量被组合为`TRACK_ENV_REPLICAS`格式，使您能够定义自己的变量来扩展 Pod 的副本：

*   `TRACK` ：Helm Chart 应用程序定义中`track` [Kubernetes 标签](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)的大写值. 如果未设置，则不会考虑到变量名.
*   `ENV` ：部署作业的大写环境名称，在`.gitlab-ci.yml`设置.

在下面的示例中，环境的名称为`qa` ，并且部署了轨道`foo` ，这将导致一个名为`FOO_QA_REPLICAS`的环境变量：

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

还必须在应用程序的 Helm 图表中定义被引用的`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 
```

### Deploy policy for staging and production environments[](#deploy-policy-for-staging-and-production-environments "Permalink")

在 GitLab 10.8 中[引入](https://gitlab.com/gitlab-org/gitlab-ci-yml/-/merge_requests/160) .

**提示：**您也可以在[项目的设置中进行设置](index.html#deployment-strategy) .

Auto DevOps 的正常行为是使用连续部署，每次在默认分支上运行新管道时，都会自动推送到`production`环境. 但是，在某些情况下，您可能需要使用暂存环境并手动部署到生产环境. 对于这种情况，引入了`STAGING_ENABLED`环境变量.

如果您定义`STAGING_ENABLED` ，例如将`STAGING_ENABLED`设置为`1`作为 CI / CD 变量，则 GitLab 会自动将应用程序部署到`staging`环境，并在准备好手动部署到生产环境时为您创建`production_manual`作业.

### Deploy policy for canary environments[](#deploy-policy-for-canary-environments-premium "Permalink")

在 GitLab 11.0 中[引入](https://gitlab.com/gitlab-org/gitlab-ci-yml/-/merge_requests/171) .

在将任何更改部署到生产之前，可以使用[Canary 环境](../../user/project/canary_deployments.html) .

如果您在项目中定义`CANARY_ENABLED` ，例如将`CANARY_ENABLED`设置为`1`作为 CI / CD 变量，则会创建两个手动作业：

*   `canary` -将应用程序部署到金丝雀环境.
*   `production_manual`手动将应用程序部署到生产环境.

### Incremental rollout to production[](#incremental-rollout-to-production-premium "Permalink")

在 GitLab 10.8 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/5415) .

**提示：**您也可以在[项目的设置中进行设置](index.html#deployment-strategy) .

当您准备将新版本的应用程序部署到生产环境时，您可能希望使用增量部署将最新的代码替换为少数 Pod，以检查应用程序的行为，然后手动将部署率提高到 100％ .

如果在项目中将`INCREMENTAL_ROLLOUT_MODE`设置为`manual` ，则将创建 4 个不同的[手动](../../ci/pipelines/index.html#add-manual-interaction-to-your-pipeline)作业，而不是标准`production`作业：

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

该百分比基于`REPLICAS`变量，并定义了您要用于部署的 Pod 数量. 如果该值为`10` ，并且您运行`10%`部署作业，那么将有`1`新容器+ `9`个旧容器.

要开始工作，请点击播放图标（ ）旁边的职位名称. 您不需要从`10%`增加到`100%` ，您可以跳到所需的任何工作. 您也可以在达到`100%`之前通过执行较低百分比的作业来缩小规模. 一旦达到`100%` ，您将无法缩小规模，并且必须通过使用环境页面中的" [回滚"按钮](../../ci/environments/index.html#retrying-and-rolling-back)重新部署旧版本来进行[回滚](../../ci/environments/index.html#retrying-and-rolling-back) .

在下面，您可以看到如果定义了发布或登台变量，管道的外观.

没有`INCREMENTAL_ROLLOUT_MODE`和`STAGING_ENABLED` ：

[![Staging and rollout disabled](img/4a3c28657f884da12667bc861ea60e0c.png)](img/rollout_staging_disabled.png)

没有`INCREMENTAL_ROLLOUT_MODE`和`STAGING_ENABLED` ：

[![Staging enabled](img/c79ebe6e2611f151d42f879eaee753fe.png)](img/staging_enabled.png)

在将`INCREMENTAL_ROLLOUT_MODE`设置为`manual`且没有`STAGING_ENABLED`情况`STAGING_ENABLED` ：

[![Rollout enabled](img/ceb135d0071e5591ba58f5d2820e8f4b.png)](img/rollout_enabled.png)

将`INCREMENTAL_ROLLOUT_MODE`设置为`manual` ，并将`STAGING_ENABLED`

[![Rollout and staging enabled](img/1780684b75826fc70c4f9d6a00cd9984.png)](img/rollout_staging_enabled.png)

**注意：**在 GitLab 11.4 之前， `INCREMENTAL_ROLLOUT_ENABLED`环境变量的存在启用了此功能. 此配置已弃用，以后将被删除.

### Timed incremental rollout to production[](#timed-incremental-rollout-to-production-premium "Permalink")

在 GitLab 11.4 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/7545) .

**提示：**您也可以在[项目的设置中进行设置](index.html#deployment-strategy) .

此配置基于[向生产的增量部署](#incremental-rollout-to-production-premium) .

除以下内容外，其他所有行为均相同：

*   要启用它，请将`INCREMENTAL_ROLLOUT_MODE`变量设置为`timed` .
*   Instead of the standard `production` job, the following jobs are created with a 5 minute delay between each:

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

## Auto DevOps banner[](#auto-devops-banner "Permalink")

在未启用自动 DevOps 的情况下，对新项目具有维护者或更高权限的用户将显示以下 Auto DevOps 标语：

[![Auto DevOps banner](img/5262199c26e59a11bfa467901c29122a.png)](img/autodevops_banner_v12_6.png)

可以为以下内容禁用横幅：

*   用户，当他们自己关闭它时.
*   通过显式[禁用 Auto DevOps 的项目](index.html#enablingdisabling-auto-devops) .
*   整个 GitLab 实例：
    *   由管理员在 Rails 控制台中运行以下命令：

        ```
         Feature . enable ( :auto_devops_banner_disabled ) 
        ```

    *   通过带有管理员访问令牌的 REST API：

        ```
         curl --data "value=true" --header "PRIVATE-TOKEN: <personal_access_token>" https://gitlab.example.com/api/v4/features/auto_devops_banner_disabled 
        ```