Auto DevOps

原文：https://docs.gitlab.com/ee/topics/autodevops/

Auto DevOps

版本历史

  • 在 GitLab 10.0 中引入 .
  • 通常在 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

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

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

有关 Auto DevOps 的介绍， 请在 GitLab 11.0 中观看AutoDevOps .

有关要求，请参阅Auto DevOps 要求以获取更多信息.

Enabled by default

在 GitLab 11.3 中引入 .

默认情况下，所有项目都会启用 Auto DevOps，并尝试在每个项目的所有管道中运行. 实例管理员可以在Auto DevOps 设置中启用或禁用此默认设置 . 如果尚未为项目显式启用，Auto DevOps 会在各个项目的第一个管道故障时自动将其禁用.

从GitLab 12.7 开始 ，仅当存在Dockerfile或匹配的 buildpack时，Auto DevOps 才会在管道上自动运行.

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

Quick start

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

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

In GitLab 13.0 and later, it is possible to leverage Auto DevOps to deploy to AWS ECS.

Comparison to application platforms and PaaS

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 and goes beyond it in multiple ways:

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

Features

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

  1. Auto Build
  2. Auto Test
  3. Auto Code Quality
  4. Auto SAST (Static Application Security Testing)
  5. Auto Secret Detection
  6. Auto Dependency Scanning
  7. Auto License Compliance
  8. Auto Container Scanning
  9. Auto Review Apps
  10. Auto DAST (Dynamic Application Security Testing)
  11. Auto Deploy
  12. Auto Browser Performance Testing
  13. Auto Monitoring

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

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

有关创建 Auto DevOps 的概述，请阅读本博客文章中的更多信息 .

注意 Kubernetes 集群可以在没有 Auto DevOps 的情况下使用 .

Auto DevOps base domain

必须使用 Auto DevOps 基本域才能使用Auto Review Apps ， Auto Deploy和Auto Monitoring . 您可以在以下任意位置定义基本域：

  • 在集群的设置下（对于实例， 项目还是组）
  • 或在项目级别作为变量： KUBE_INGRESS_BASE_DOMAIN
  • 或在组级别作为变量： KUBE_INGRESS_BASE_DOMAIN
  • 或作为实例范围的后备 持续集成和交付部分下的管理区域>设置

基本域变量KUBE_INGRESS_BASE_DOMAIN与其他环境变量遵循相同的优先级顺序. 如果未设置 CI / CD 变量，并且群集设置为空，则在设置实例范围的Auto DevOps 域设置时将使用该设置.

提示：如果您将GitLab 托管应用程序用于 Ingress ，则应自动为您配置 URL 端点. 您所要做的就是将其值用于KUBE_INGRESS_BASE_DOMAIN变量.注： AUTO_DEVOPS_DOMAIN被弃用 GitLab 11.8 ，取而代之的KUBE_INGRESS_BASE_DOMAIN ，并在除去GitLab 12.0 .

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

  1. *.example.com   3600     A     1.2.3.4

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

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

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

Enabling/Disabling Auto DevOps

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

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

At the project level

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

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

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

At the group level

在 GitLab 11.10 中引入 .

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

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

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

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

At the instance level (Administrators only)

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

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

Deployment strategy

在 GitLab 11.0 中引入 .

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

  • 持续部署到生产中 ：启用将master分支直接部署到生产中的自动部署 .
  • 使用定时增量部署连续部署到生产中 ：将INCREMENTAL_ROLLOUT_MODE变量设置为timed . 生产部署在每次部署增量之间有 5 分钟的延迟执行.

  • 自动部署到登台，手动部署到生产 ：将STAGING_ENABLED和INCREMENTAL_ROLLOUT_MODE变量设置为1并manual . 这表示：

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

提示：使用蓝绿色部署技术可最大程度地减少停机时间和风险.

Using multiple Kubernetes clusters

使用 Auto DevOps 时，由于它们之间存在 1：1 连接，因此可以将不同的环境部署到不同的 Kubernetes 集群.

Auto DevOps 使用的” 部署作业”模板当前定义了 3 个环境名称：

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

这些环境使用Auto Deploy与作业绑定，因此，除了环境范围外，它们必须具有不同的部署域. 您必须根据环境为上述每个项定义一个单独的KUBE_INGRESS_BASE_DOMAIN变量.

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

集群名称 集群环境范围 KUBE_INGRESS_BASE_DOMAIN变量值 可变环境范围 Notes
review review/* review.example.com review/* 运行所有Review Apps的评论集群. *是一个通配符，每个环境名称都以review/开头使用.
staging staging staging.example.com staging （可选）运行临时环境的部署的临时集群. 您必须先启用它 .
production production example.com production 运行生产环境部署的生产集群. 您可以使用增量卷展栏 .

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

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

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

Limitations

以下限制适用.

Private registry support

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

Installing Helm behind a proxy

当在代理后面时，GitLab 不支持将Helm 作为 GitLab 管理的应用程序安装. 想要这样做的用户必须在运行时将其代理设置注入到安装 Pod 中，例如使用PodPreset ：

  1. apiVersion: settings.k8s.io/v1alpha1
  2. kind: PodPreset
  3. metadata:
  4.   name: gitlab-managed-apps-default-proxy
  5.   namespace: gitlab-managed-apps
  6. spec:
  7.    env:
  8.     - name: http_proxy
  9.       value: "PUT_YOUR_HTTP_PROXY_HERE"
  10.     - name: https_proxy
  11.       value: "PUT_YOUR_HTTPS_PROXY_HERE"

Troubleshooting

Unable to select a buildpack

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

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

以下是可能的原因：

  • 您的应用程序可能缺少 buildpack 寻找的关键文件. Ruby 应用程序需要正确检测Gemfile ，即使编写不带Gemfile的 Ruby 应用程序也是Gemfile .
  • 您的应用程序可能不存在 buildpack. 尝试指定自定义 buildpack .

Pipeline that extends Auto DevOps with only / except fails

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

  1. Found errors in your .gitlab-ci.yml:
  3.   jobs:test config key may not be used with `rules`: only

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

Failure to create a Kubernetes namespace

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

Detected an existing PostgreSQL database

升级到 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 .

  • 如果不使用集群内数据库，则可以将POSTGRES_ENABLED设置为false并重新部署. 此选项与没有图表内 PostgreSQL 依赖项的自定义图表的用户特别相关. 数据库自动检测基于您的发行版的postgresql.enabled Helm 值. 该值是基于POSTGRES_ENABLED CI 变量设置的，并且由 Helm 保留，无论您的图表是否使用该变量.

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

Development guides

Development guide for Auto DevOps