# Auto DevOps

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

*   [Overview](#overview)
*   [Enabled by default](#enabled-by-default)
*   [Quick start](#quick-start)
*   [Comparison to application platforms and PaaS](#comparison-to-application-platforms-and-paas)
*   [Features](#features)
*   [Auto DevOps base domain](#auto-devops-base-domain)
*   [Enabling/Disabling Auto DevOps](#enablingdisabling-auto-devops)
    *   [At the project level](#at-the-project-level)
    *   [At the group level](#at-the-group-level)
    *   [At the instance level (Administrators only)](#at-the-instance-level-administrators-only)
    *   [Deployment strategy](#deployment-strategy)
*   [Using multiple Kubernetes clusters](#using-multiple-kubernetes-clusters-premium)
*   [Limitations](#limitations)
    *   [Private registry support](#private-registry-support)
    *   [Installing Helm behind a proxy](#installing-helm-behind-a-proxy)
*   [Troubleshooting](#troubleshooting)
    *   [Unable to select a buildpack](#unable-to-select-a-buildpack)
    *   [Pipeline that extends Auto DevOps with only / except fails](#pipeline-that-extends-auto-devops-with-only--except-fails)
    *   [Failure to create a Kubernetes namespace](#failure-to-create-a-kubernetes-namespace)
    *   [Detected an existing PostgreSQL database](#detected-an-existing-postgresql-database)
*   [Development guides](#development-guides)

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

版本历史

*   在 GitLab 10.0 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/37115) .
*   通常在 GitLab 11.0 上可用.

Auto DevOps provides pre-defined CI/CD configuration allowing you to automatically detect, build, test, deploy, and monitor your applications. Leveraging CI/CD best practices and tools, Auto DevOps aims to simplify the setup and execution of a mature and modern software development lifecycle.

## Overview[](#overview "Permalink")

您可以花费大量精力来设置构建，部署和监视项目所需的工作流和流程. 当您的公司要维护数百个（甚至数千个）项目时，情况会变得更糟. 随着新项目的不断启动，整个软件开发过程变得难以管理.

Auto DevOps 通过自动检测以最小的配置测试，构建，打包，部署和监视每个项目所需的所有依赖关系和语言技术，为您提供了无缝的软件开发过程. 自动化可确保项目之间的一致性，流程的无缝管理以及更快地创建新项目：推送代码，而 GitLab 则完成其余工作，从而提高了生产率和效率.

有关 Auto DevOps 的介绍， [请在 GitLab 11.0 中](https://youtu.be/0Tc0YYBxqi4)观看[AutoDevOps](https://youtu.be/0Tc0YYBxqi4) .

有关要求，请参阅[Auto DevOps 要求以](requirements.html)获取更多信息.

## Enabled by default[](#enabled-by-default "Permalink")

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

默认情况下，所有项目都会启用 Auto DevOps，并尝试在每个项目的所有管道中运行. 实例管理员可以在[Auto DevOps 设置中](../../user/admin_area/settings/continuous_integration.html#auto-devops-core-only)启用或禁用此默认[设置](../../user/admin_area/settings/continuous_integration.html#auto-devops-core-only) . 如果尚未为项目显式启用，Auto DevOps 会在各个项目的第一个管道故障时自动将其禁用.

从[GitLab 12.7 开始](https://gitlab.com/gitlab-org/gitlab/-/issues/26655) ，仅当存在[`Dockerfile`或匹配的 buildpack](stages.html#auto-build)时，Auto DevOps 才会在管道上自动运行.

如果项目中存在[CI / CD 配置文件](../../ci/yaml/README.html) ，则无论是否启用了 Auto DevOps，它都将继续使用.

## Quick start[](#quick-start "Permalink")

如果您使用的是 GitLab.com，请参阅[快速入门指南](quick_start_guide.html) ，以使用 GitLab.com 和 Google Kubernetes Engine（GKE）上的 Kubernetes 集群设置 Auto DevOps.

如果使用 GitLab 的自我管理实例，则必须先配置[Google OAuth2 OmniAuth Provider，](../../integration/google.html)然后才能在 GKE 上配置集群. 配置提供程序后，您可以按照[快速入门指南中](quick_start_guide.html)的步骤进行入门.

In [GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/208132) and later, it is possible to leverage Auto DevOps to deploy to [AWS ECS](requirements.html#auto-devops-requirements-for-amazon-ecs).

## Comparison to application platforms and PaaS[](#comparison-to-application-platforms-and-paas "Permalink")

Auto DevOps provides features often included in an application platform or a Platform as a Service (PaaS). It takes inspiration from the innovative work done by [Heroku](https://www.heroku.com/) and goes beyond it in multiple ways:

*   Auto DevOps 可与任何 Kubernetes 集群一起使用; 您不仅限于在 GitLab 的基础架构上运行. （请注意，许多功能在没有 Kubernetes 的情况下也可以使用）.
*   没有额外的费用（基础设施费用没有加价），您可以在任何公共云（例如[Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) ）上使用托管的 Kubernetes 群集或容器即服务.
*   Auto DevOps 具有更多功能，包括安全测试，性能测试和代码质量测试.
*   Auto DevOps 提供增量的毕业路径. 如果需要高级自定义，则可以开始修改模板，而无需在完全不同的平台上重新开始. 查看[定制](customize.html)文档以获取更多信息.

## Features[](#features "Permalink")

Auto DevOps 由一组[阶段组成](stages.html) ，以简单，自动的方式为您的项目带来了这些最佳实践：

1.  [Auto Build](stages.html#auto-build)
2.  [Auto Test](stages.html#auto-test)
3.  [Auto Code Quality](stages.html#auto-code-quality-starter)
4.  [Auto SAST (Static Application Security Testing)](stages.html#auto-sast-ultimate)
5.  [Auto Secret Detection](stages.html#auto-secret-detection-ultimate)
6.  [Auto Dependency Scanning](stages.html#auto-dependency-scanning-ultimate)
7.  [Auto License Compliance](stages.html#auto-license-compliance-ultimate)
8.  [Auto Container Scanning](stages.html#auto-container-scanning-ultimate)
9.  [Auto Review Apps](stages.html#auto-review-apps)
10.  [Auto DAST (Dynamic Application Security Testing)](stages.html#auto-dast-ultimate)
11.  [Auto Deploy](stages.html#auto-deploy)
12.  [Auto Browser Performance Testing](stages.html#auto-browser-performance-testing-premium)
13.  [Auto Monitoring](stages.html#auto-monitoring)

由于 Auto DevOps 依赖于许多不同的组件，因此您应该具有以下基本知识：

*   [Kubernetes](https://kubernetes.io/docs/home/)
*   [Helm](https://helm.sh/docs/)
*   [Docker](https://s0docs0docker0com.icopy.site)
*   [GitLab Runner](https://docs.gitlab.com/runner/)
*   [Prometheus](https://s0prometheus0io.icopy.site/docs/introduction/overview/)

Auto DevOps 为所有阶段提供了出色的默认设置. 但是，您可以[根据](customize.html)需要[自定义](customize.html)几乎所有内容.

有关创建 Auto DevOps 的概述，请阅读[本博客文章中的](https://about.gitlab.com/blog/2017/06/29/whats-next-for-gitlab-ci/)更多[信息](https://about.gitlab.com/blog/2017/06/29/whats-next-for-gitlab-ci/) .

**注意** Kubernetes 集群可以[在没有](../../user/project/clusters/index.html) Auto DevOps 的[情况下使用](../../user/project/clusters/index.html) .

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

必须使用 Auto DevOps 基本域才能使用[Auto Review Apps](stages.html#auto-review-apps) ， [Auto Deploy](stages.html#auto-deploy)和[Auto Monitoring](stages.html#auto-monitoring) . 您可以在以下任意位置定义基本域：

*   在集群的设置下（对于实例， [项目](../../user/project/clusters/index.html#base-domain)还是[组）](../../user/group/clusters/index.html#base-domain)
*   或在项目级别作为变量： `KUBE_INGRESS_BASE_DOMAIN`
*   或在组级别作为变量： `KUBE_INGRESS_BASE_DOMAIN`
*   或作为实例范围的后备 **持续集成和交付**部分下的**管理区域>设置**

基本域变量`KUBE_INGRESS_BASE_DOMAIN`与其他环境[变量](../../ci/variables/README.html#priority-of-environment-variables)遵循相同的优先级顺序. 如果未设置 CI / CD 变量，并且群集设置为空，则在设置实例范围的**Auto DevOps 域**设置时将使用该设置.

**提示：**如果您将[GitLab 托管应用程序用于 Ingress](../../user/clusters/applications.html#ingress) ，则应自动为您配置 URL 端点. 您所要做的就是将其值用于`KUBE_INGRESS_BASE_DOMAIN`变量.**注：** `AUTO_DEVOPS_DOMAIN`被[弃用 GitLab 11.8](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/52363) ，取而代之的`KUBE_INGRESS_BASE_DOMAIN` ，并在除去[GitLab 12.0](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/56959) .

Auto DevOps 需要与基础域匹配的通配符 DNS A 记录. 对于`example.com`的基本域，您需要一个 DNS 条目，例如：

```
*.example.com   3600     A     1.2.3.4 
```

在这种情况下，已部署的应用程序是从`example.com` ，而`1.2.3.4`是负载均衡器的 IP 地址. 通常为 NGINX（ [请参阅要求](#requirements) ）. 设置 DNS 记录不在本文档的讨论范围内. 请与您的 DNS 提供商联系以获取信息.

另外，您可以使用免费的公共服务，例如[nip.io](https://nip.io) ，无需任何配置即可提供自动通配符 DNS. 对于[nip.io](https://nip.io) ，将 Auto DevOps 基本域设置为`1.2.3.4.nip.io`

完成设置后，所有请求都将到达负载均衡器，该负载均衡器会将请求路由到运行您的应用程序的 Kubernetes Pod.

## Enabling/Disabling Auto DevOps[](#enablingdisabling-auto-devops "Permalink")

首次使用 Auto DevOps 时，请查看[要求，](#requirements)以确保可以充分利用 Auto DevOps 的所有必需组件. 初学者应遵循[快速入门指南](quick_start_guide.html) .

GitLab.com 用户只能在项目级别启用或禁用 Auto DevOps. 自我管理的用户可以在项目，组或实例级别启用或禁用 Auto DevOps.

### At the project level[](#at-the-project-level "Permalink")

如果启用，请检查您的项目是否没有`.gitlab-ci.yml` ，或者如果存在，请将其删除.

1.  转到项目的 **设置> CI / CD>自动 DevOps** .
2.  选中**默认为 Auto DevOps 管道**复选框以启用它.
3.  （可选，但建议使用）启用后，您可以在 Auto DevOps 用于[部署应用程序](stages.html#auto-deploy)的[基本域中](#auto-devops-base-domain)添加，并选择[部署策略](#deployment-strategy) .
4.  单击**保存更改**以使更改生效.

启用该功能后，将在默认分支上触发 Auto DevOps 管道.

### At the group level[](#at-the-group-level "Permalink")

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

仅管理员和组所有者可以在组级别启用或禁用自动 DevOps.

在组级别启用或禁用 Auto DevOps 时，除非在子组或项目上专门启用或禁用了 Auto DevOps，否则组配置将隐式用于该组内的子组和项目.

要在组级别启用或禁用自动 DevOps：

1.  前往您小组的 **设置> CI / CD>自动 DevOps**页面.
2.  选中**默认为 Auto DevOps 管道**复选框以启用它.
3.  单击**保存更改**以使更改生效.

### At the instance level (Administrators only)[](#at-the-instance-level-administrators-only "Permalink")

即使在实例级别被禁用，组所有者和项目维护者仍可以分别在组和项目级别启用 Auto DevOps.

1.  去 **管理区域>设置>持续集成和部署** .
2.  **为所有项目**选择" **默认为自动 DevOps 管道"**以启用它.
3.  （可选）您可以设置 Auto DevOps [基本域](#auto-devops-base-domain) ，以供 Auto Deploy 和 Auto Review Apps 使用.
4.  单击**保存更改**以使更改生效.

### Deployment strategy[](#deployment-strategy "Permalink")

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

您可以转到项目的目录，更改 Auto DevOps 使用的部署策略. **设置> CI / CD>自动 DevOps** . 提供以下选项：

*   **持续部署到生产中** ：启用将`master`分支直接部署到生产中的[自动部署](stages.html#auto-deploy) .
*   **使用定时增量部署连续部署到生产中** ：将[`INCREMENTAL_ROLLOUT_MODE`](customize.html#timed-incremental-rollout-to-production-premium)变量设置为`timed` . 生产部署在每次部署增量之间有 5 分钟的延迟执行.
*   **自动部署到登台，手动部署到生产** ：将[`STAGING_ENABLED`](customize.html#deploy-policy-for-staging-and-production-environments)和[`INCREMENTAL_ROLLOUT_MODE`](customize.html#incremental-rollout-to-production-premium)变量设置为`1`并`manual` . 这表示：

    *   `master`分支直接部署到登台.
    *   提供了手动操作以逐步推广到生产中.

**提示：**使用[蓝绿色部署](../../ci/environments/incremental_rollouts.html#blue-green-deployment)技术可最大程度地减少停机时间和风险.

## Using multiple Kubernetes clusters[](#using-multiple-kubernetes-clusters-premium "Permalink")

使用 Auto DevOps 时，由于[它们之间存在](../../user/project/clusters/index.html#multiple-kubernetes-clusters-premium) 1：1 连接，因此可以将不同的环境部署到不同的 Kubernetes 集群.

Auto DevOps 使用的" [部署作业"模板](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-ci.yml)当前定义了 3 个环境名称：

*   `review/` （从`review/`开始的所有环境`review/` ）
*   `staging`
*   `production`

这些环境使用[Auto Deploy](stages.html#auto-deploy)与作业绑定，因此，除了环境范围外，它们必须具有不同的部署域. 您必须[根据环境](../../ci/variables/README.html#limit-the-environment-scopes-of-environment-variables)为上述每个项定义一个单独的`KUBE_INGRESS_BASE_DOMAIN`变量.

下表是如何配置三个不同群集的示例：

| 集群名称 | 集群环境范围 | `KUBE_INGRESS_BASE_DOMAIN`变量值 | 可变环境范围 | Notes |
| --- | --- | --- | --- | --- |
| review | `review/*` | `review.example.com` | `review/*` | 运行所有[Review Apps](../../ci/review_apps/index.html)的评论集群. `*`是一个通配符，每个环境名称都以`review/`开头使用. |
| staging | `staging` | `staging.example.com` | `staging` | （可选）运行临时环境的部署的临时集群. 您必须先[启用它](customize.html#deploy-policy-for-staging-and-production-environments) . |
| production | `production` | `example.com` | `production` | 运行生产环境部署的生产集群. 您可以使用[增量卷展栏](customize.html#incremental-rollout-to-production-premium) . |

为每个环境添加不同的集群：

1.  导航到您项目的 **运营> Kubernetes** .
2.  如上表所述，使用各自的环境范围创建 Kubernetes 集群.
3.  创建集群后，导航至每个集群并安装 Helm Tiller 和 Ingress. 等待分配入口 IP 地址.
4.  确保已使用指定的 Auto DevOps 域[配置 DNS](#auto-devops-base-domain) .
5.  导航到每个集群的页面，方法是 **操作> Kubernetes** ，然后根据其入口 IP 地址添加域.

完成配置后，您可以通过创建合并请求并验证您的应用程序是否已作为具有 Review `review/*`环境范围的 Kubernetes 集群中的 Review App 部署来测试设置. 同样，您可以检查其他环境.

## Limitations[](#limitations "Permalink")

以下限制适用.

### Private registry support[](#private-registry-support "Permalink")

没有记录的将私有容器注册表与 Auto DevOps 结合使用的方式. 我们强烈建议将 GitLab 容器注册表与 Auto DevOps 结合使用，以简化配置并防止任何不可预见的问题.

### Installing Helm behind a proxy[](#installing-helm-behind-a-proxy "Permalink")

当在代理后面时，GitLab 不支持将[Helm 作为 GitLab 管理的应用程序](../../user/clusters/applications.html#helm)安装. 想要这样做的用户必须在运行时将其代理设置注入到安装 Pod 中，例如使用[`PodPreset`](https://kubernetes.io/docs/concepts/workloads/pods/podpreset/) ：

```
apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
  name: gitlab-managed-apps-default-proxy
  namespace: gitlab-managed-apps
spec:
   env:
    - name: http_proxy
      value: "PUT_YOUR_HTTP_PROXY_HERE"
    - name: https_proxy
      value: "PUT_YOUR_HTTPS_PROXY_HERE" 
```

## Troubleshooting[](#troubleshooting "Permalink")

### Unable to select a buildpack[](#unable-to-select-a-buildpack "Permalink")

自动构建和自动测试可能无法检测到您的语言或框架，并出现以下错误：

```
Step 5/11 : RUN /bin/herokuish buildpack build
 ---> Running in eb468cd46085
    -----> Unable to select a buildpack
The command '/bin/sh -c /bin/herokuish buildpack build' returned a non-zero code: 1 
```

以下是可能的原因：

*   您的应用程序可能缺少 buildpack 寻找的关键文件. Ruby 应用程序需要正确检测`Gemfile` ，即使编写不带`Gemfile`的 Ruby 应用程序也是`Gemfile` .
*   您的应用程序可能不存在 buildpack. 尝试指定[自定义 buildpack](customize.html#custom-buildpacks) .

### Pipeline that extends Auto DevOps with only / except fails[](#pipeline-that-extends-auto-devops-with-only--except-fails "Permalink")

如果您的管道失败并显示以下消息：

```
Found errors in your .gitlab-ci.yml:

  jobs:test config key may not be used with `rules`: only 
```

当包含作业的规则配置已被`only`或`except`语法覆盖时，将出现此错误. 要解决此问题，您必须：

*   将您的`only/except`语法转换为规则.
*   （临时）将模板固定到[基于 GitLab 12.10 的模板](https://gitlab.com/gitlab-org/auto-devops-v12-10) .

### Failure to create a Kubernetes namespace[](#failure-to-create-a-kubernetes-namespace "Permalink")

如果 GitLab 无法为您的项目创建 Kubernetes 命名空间和服务帐户，则 Auto Deploy 将失败. 有关调试此问题的帮助，请参阅[对失败的部署作业进行故障排除](../../user/project/clusters/index.html#troubleshooting) .

### Detected an existing PostgreSQL database[](#detected-an-existing-postgresql-database "Permalink")

升级到 GitLab 13.0 后，使用 Auto DevOps 部署时可能会遇到以下消息：

> 检测到已安装在不赞成使用的通道 1 上的现有 PostgreSQL 数据库，但当前通道设置为 2.在 GitLab 13.0 中，默认通道更改为 2\. […]

默认情况下，Auto DevOps 会在应用程序旁边安装集群内 PostgreSQL 数据库. 在 GitLab 13.0 中更改了默认安装方法，并且升级现有数据库需要用户参与. 两种安装方法是：

*   **通道 1（不建议使用）：**作为关联的 Helm 图表的依赖项拉入数据库. 只支持 Kubernetes 版本 1.15 之前的版本.
*   **通道 2（当前）：**将数据库安装为独立的 Helm 图表. 将集群内数据库功能与 Kubernetes 1.16 及更高版本一起使用时是必需的.

如果收到此错误，则可以执行以下操作之一：

*   通过将`AUTO_DEVOPS_POSTGRES_CHANNEL`设置为`1`并重新部署，可以*放心地*忽略该警告并继续使用通道 1 PostgreSQL 数据库.

*   通过将`AUTO_DEVOPS_POSTGRES_DELETE_V1`设置为非空值并重新部署，可以删除通道 1 PostgreSQL 数据库并安装新的通道 2 数据库.

    **危险：**删除通道 1 PostgreSQL 数据库将永久删除现有的通道 1 数据库及其所有数据. 有关备份和升级数据库的更多信息，请参见[升级 PostgreSQL](upgrading_postgresql.html) .
*   如果不使用集群内数据库，则可以将`POSTGRES_ENABLED`设置为`false`并重新部署. 此选项与*没有图表内 PostgreSQL 依赖项*的*自定义图表的*用户特别相关. 数据库自动检测基于您的发行版的`postgresql.enabled` Helm 值. 该值是基于`POSTGRES_ENABLED` CI 变量设置的，并且由 Helm 保留，无论您的图表是否使用该变量.

**危险：**将`POSTGRES_ENABLED`设置为`false`永久删除您环境中的任何现有通道 1 数据库.

## Development guides[](#development-guides "Permalink")

[Development guide for Auto DevOps](../../development/auto_devops.html)