Auto DevOps 的阶段

以下章节描述了 Auto DevOps 的各个阶段。 请仔细阅读，了解每个阶段的工作原理。

Auto Build

Auto Build 使用现有的 Dockerfile 或 Heroku buildpacks 创建应用程序的构建。生成的 Docker 镜像会被推送到 Container Registry，并使用提交 SHA 或标签进行标记。

使用 Dockerfile 进行 Auto Build

如果项目的仓库根目录包含 Dockerfile，Auto Build 会使用 docker build 创建 Docker 镜像。

如果您同时使用 Auto Review Apps 和 Auto Deploy，并且选择提供自己的 Dockerfile，您必须：

• 将您的应用程序暴露到端口 5000，因为 默认 Helm chart 假设此端口可用。
• 通过 自定义 Auto Deploy Helm chart 覆盖默认值。

使用 Cloud Native Buildpacks 进行 Auto Build

如果存在 Dockerfile，Auto Build 会使用项目的 Dockerfile 构建应用程序。如果没有 Dockerfile，Auto Build 会使用 Cloud Native Buildpacks 来检测并构建应用程序为 Docker 镜像。该功能使用 pack 命令。 默认的 builder 是 heroku/buildpacks:22，但可以使用 CI/CD 变量 AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER 选择不同的 builder。

每个 buildpack 都要求项目的仓库包含某些文件，以便 Auto Build 能够成功构建您的应用程序。结构取决于您选择的 builder 和 buildpacks。 例如，使用 Heroku builder（默认）时，应用程序的根目录必须包含适用于您应用程序语言的文件：

• 对于 Python 项目，需要一个 Pipfile 或 requirements.txt 文件。
• 对于 Ruby 项目，需要一个 Gemfile 或 Gemfile.lock 文件。

有关其他语言和框架的要求，请阅读 Heroku buildpacks 文档。

将卷挂载到构建容器中

变量 BUILDPACK_VOLUMES 可用于将卷挂载定义传递给 pack 命令。挂载通过 --volume 参数传递给 pack build。 每个卷定义可以包含 build pack 提供的任何功能，例如主机路径、目标路径、卷是否可写，以及一个或多个卷选项。

使用管道 | 字符传递多个卷。 列表中的每个项目都通过单独的 --volume 参数传递给 build back。

在此示例中，三个卷被挂载到容器中，分别为 /etc/foo、/opt/foo 和 /var/opt/foo：

buildjob:
  variables:
    BUILDPACK_VOLUMES: /mnt/1:/etc/foo:ro|/mnt/2:/opt/foo:ro|/mnt/3:/var/opt/foo:rw

有关在 pack build 文档 中定义卷的更多信息。

从 Herokuish 迁移到 Cloud Native Buildpacks

使用 Cloud Native Buildpacks 的构建与使用 Herokuish 的构建支持相同的选项，但有以下注意事项：

• buildpack 必须是 Cloud Native Buildpack。可以使用 Heroku 的 cnb-shim 将 Heroku buildpack 转换为 Cloud Native Buildpack。
• BUILDPACK_URL 必须采用 pack 支持的格式。
• 构建的镜像中不存在 /bin/herokuish 命令，并且不再需要（也不可能）使用 /bin/herokuish procfile exec 前缀命令。相反，自定义命令应前缀 /cnb/lifecycle/launcher 以接收正确的执行环境。

Auto Test

Auto Test 通过分析您的项目来检测语言和框架，使用 Herokuish 和 Heroku buildpacks 运行适用于您应用程序的测试。多种语言和框架会被自动检测，但如果您的语言未被检测到，您可能可以创建一个 自定义 buildpack。请检查 当前支持的语言。

Auto Test 使用您应用程序中已有的测试。如果没有测试，则需要您自行添加。

当前支持的语言

并非所有 buildpack 都支持 Auto Test，因为它是一个相对较新的增强功能。所有 Heroku 的 官方支持语言 都支持 Auto Test。Heroku 的 Herokuish buildpacks 支持的语言都支持 Auto Test，但值得注意的是 multi-buildpack 不支持。

支持的 buildpack 有：

- heroku-buildpack-multi
- heroku-buildpack-ruby
- heroku-buildpack-nodejs
- heroku-buildpack-clojure
- heroku-buildpack-python
- heroku-buildpack-java
- heroku-buildpack-gradle
- heroku-buildpack-scala
- heroku-buildpack-play
- heroku-buildpack-php
- heroku-buildpack-go
- buildpack-nginx

如果您的应用程序需要不在上述列表中的 buildpack，您可能需要使用 自定义 buildpack。

Auto Code Quality

Auto Code Quality 使用 Code Quality image 对当前代码运行静态分析和其他代码检查。创建报告后，会上传为工件，您可以稍后下载并查看。合并请求小部件也会显示 源分支和目标分支之间的差异。

Auto SAST

静态应用程序安全测试 (SAST) 对当前代码运行静态分析，并检查潜在的安全问题。Auto SAST 阶段需要 GitLab Runner 11.5 或更高版本。

创建报告后，会上传为工件，您可以稍后下载并查看。合并请求小部件也会显示 Ultimate 许可证上的任何安全警告。

有关更多信息，请参阅 静态应用程序安全测试 (SAST)。

Auto Secret Detection

Secret Detection 使用 Secret Detection Docker image 对当前代码运行 Secret Detection，并检查泄露的密钥。

创建报告后，会上传为工件，您可以稍后下载并评估。合并请求小部件也会显示 Ultimate 许可证上的任何安全警告。

有关更多信息，请参阅 Secret Detection。

Auto Dependency Scanning

Dependency Scanning 对项目的依赖项运行分析，并检查潜在的安全问题。 Auto Dependency Scanning 阶段在 Ultimate 以外的许可证上会被跳过。

创建报告后，会上传为工件，您可以稍后下载并查看。合并请求小部件显示检测到的任何安全警告，

有关更多信息，请参阅 Dependency Scanning。

Auto Container Scanning

容器漏洞静态分析使用 Trivy 检查 Docker 镜像中的潜在安全问题。Auto Container Scanning 阶段在 Ultimate 以外的许可证上会被跳过。

创建报告后，会上传为工件，您可以稍后下载并查看。合并请求显示检测到的任何安全问题。

有关更多信息，请参阅 Container Scanning。

Auto Review Apps

这是一个可选步骤，因为许多项目没有可用的 Kubernetes 集群。如果未满足 要求，作业将被静默跳过。

Review apps 是基于分支代码的临时应用程序环境，以便开发人员、设计师、QA、产品经理和其他审查者可以在审查过程中实际查看和与代码更改进行交互。Auto Review Apps 为每个分支创建一个 Review App。

Auto Review Apps 仅将您的应用程序部署到您的 Kubernetes 集群。如果没有可用的集群，则不会发生部署。

Review App 具有基于项目 ID、分支或标签名称、唯一编号和 Auto DevOps 基础域组合的唯一 URL，例如 13083-review-project-branch-123456.example.com。合并请求小部件显示 Review App 的链接以便于发现。当分支或标签被删除（例如合并合并请求后），Review App 也会被删除。

Review apps 使用 Helm 和 auto-deploy-app chart 部署，您可以 自定义。应用程序部署到环境的 Kubernetes namespace 中。

使用 Local Tiller。早期版本的 GitLab 在项目命名空间中安装了 Tiller。

Auto DAST

动态应用程序安全测试 (DAST) 使用流行的开源工具 OWASP ZAProxy 分析当前代码并检查潜在的安全问题。Auto DAST 阶段在 Ultimate 以外的许可证上会被跳过。

• 在您的默认分支上，DAST 扫描专门为此目的部署的应用程序，除非您 覆盖目标分支。 应用程序在 DAST 运行后被删除。
• 在功能分支上，DAST 扫描 review app。

DAST 扫描完成后，任何安全警告都会显示在 Security Dashboard 和合并请求小部件上。

有关更多信息，请参阅 动态应用程序安全测试 (DAST)。

覆盖 DAST 目标

要使用自定义目标而不是自动部署的 review apps， 请设置 DAST_WEBSITE CI/CD 变量为 DAST 要扫描的 URL。

跳过 Auto DAST

您可以跳过 DAST 作业：

• 通过将 DAST_DISABLED CI/CD 变量设置为 "true" 来跳过所有分支。
• 通过将 DAST_DISABLED_FOR_DEFAULT_BRANCH 变量设置为 "true" 来仅跳过默认分支。
• 通过将 REVIEW_DISABLED 变量设置为 "true" 来仅跳过功能分支。这也会跳过 Review App。

Auto Browser Performance Testing

Auto Browser Performance Testing 使用 Sitespeed.io 容器 测量网页的浏览器性能， 创建包含每个页面总体性能分数的 JSON 报告，并将报告作为工件上传。默认情况下，它测试您的 Review 和 Production 环境的根页面。如果要测试其他 URL，请在根目录中添加一个名为 .gitlab-urls.txt 的文件，每行一个 URL。例如：

/
/features
/direction

源分支和目标分支之间的任何浏览器性能差异也会 显示在合并请求小部件中。

Auto Load Performance Testing

Auto Load Performance Testing 使用 k6 容器 测量应用程序的服务器性能， 创建包含多个关键结果指标的 JSON 报告，并将报告作为工件上传。

需要进行一些初始设置。需要编写一个针对您的特定应用程序定制的 k6 测试。还需要配置测试以便它可以通过 CI/CD 变量获取环境的动态 URL。

源分支和目标分支之间的任何负载性能测试结果差异也会 显示在合并请求小部件中。

Auto Deploy

除了 Kubernetes 集群外，您还可以选择部署到 Amazon Elastic Compute Cloud (Amazon EC2)。

Auto Deploy 是 Auto DevOps 的可选步骤。如果未满足 要求，作业将被跳过。

当分支或合并请求被合并到项目的默认分支后，Auto Deploy 会将应用程序部署到 Kubernetes 集群中的 production 环境，命名空间基于项目名称和唯一项目 ID，例如 project-4321。

默认情况下，Auto Deploy 不包括暂存或金丝雀环境的部署，但 Auto DevOps template 包含这些任务的作业定义，如果您想启用它们。

您可以使用 CI/CD variables 自动 扩展您的 pod 副本，并将自定义参数应用到 Auto DevOps helm upgrade 命令。这是 自定义 Auto Deploy Helm chart 的简单方法。

Helm 使用 auto-deploy-app chart 将应用程序部署到环境的 Kubernetes namespace 中。

使用 Local Tiller。早期版本的 GitLab 在项目命名空间中安装了 Tiller。

GitLab deploy tokens

当启用 Auto DevOps 并保存 Auto DevOps 设置时，会为内部和私有项目创建 GitLab Deploy Tokens。 您可以使用 Deploy Token 永久访问 registry。手动撤销 GitLab Deploy Token 后，它不会自动重新创建。

如果找不到 GitLab Deploy Token，则使用 CI_REGISTRY_PASSWORD。

Kubernetes 1.16+

在 Kubernetes 1.16 及更高版本中，许多 API 已被移除， 包括对 extensions/v1beta1 版本中 Deployment 的支持。

要在 Kubernetes 1.16+ 集群上使用 Auto Deploy：

1. 如果您在 GitLab 13.0 或更高版本中首次部署应用程序，则不需要配置。

2. 如果您使用 AUTO_DEVOPS_POSTGRES_CHANNEL 设置为 1 安装了集群内 PostgreSQL 数据库，请遵循 升级 PostgreSQL 的指南。

Migrations

您可以通过设置项目 CI/CD 变量 DB_INITIALIZE 和 DB_MIGRATE 来配置 PostgreSQL 的数据库初始化和迁移在应用程序 pod 中运行。

如果存在 DB_INITIALIZE，它会在应用程序 pod 中作为 shell 命令运行，作为 Helm post-install hook。由于某些应用程序在没有成功的数据库初始化步骤的情况下无法运行，GitLab 首次部署时不包含应用程序部署，仅包含数据库初始化步骤。数据库初始化完成后，GitLab 部署第二个包含标准应用程序部署的版本。

post-install hook 意味着如果任何部署成功， DB_INITIALIZE 不会在此后处理。

如果存在 DB_MIGRATE，它会在应用程序 pod 中作为 shell 命令运行，作为 Helm pre-upgrade hook。

例如，在使用 Cloud Native Buildpacks 构建的镜像中的 Rails 应用程序中：

• DB_INITIALIZE 可以设置为 RAILS_ENV=production /cnb/lifecycle/launcher bin/rails db:setup
• DB_MIGRATE 可以设置为 RAILS_ENV=production /cnb/lifecycle/launcher bin/rails db:migrate

除非您的仓库包含 Dockerfile，否则您的镜像使用 Cloud Native Buildpacks 构建，并且您必须在这些镜像中运行的命令前加上 /cnb/lifecycle/launcher 以复制您的应用程序运行的环境。

Upgrade auto-deploy-app Chart

您可以按照 升级指南 升级 auto-deploy-app chart。

Workers

一些 Web 应用程序必须为"worker 进程"运行额外的部署。例如，Rails 应用程序通常使用单独的 worker 进程来运行发送电子邮件等后台任务。

Auto Deploy 中使用的 默认 Helm chart 支持运行 worker 进程。

要运行 worker，您必须确保 worker 能够响应 标准健康检查，这期望在端口 5000 上获得成功的 HTTP 响应。对于 Sidekiq，您可以使用 sidekiq_alive gem。

要使用 Sidekiq，您还必须确保您的部署可以访问 Redis 实例。Auto DevOps 不会为您部署此实例，因此您必须：

• 维护您自己的 Redis 实例。
• 设置 CI/CD 变量 K8S_SECRET_REDIS_URL，这是此实例的 URL， 以确保它被传递到您的部署中。

配置您的 worker 以响应健康检查后，为您的 Rails 应用程序运行 Sidekiq worker。您可以通过在 .gitlab/auto-deploy-values.yaml 文件 中设置以下内容来启用 workers：

workers:
  sidekiq:
    replicaCount: 1
    command:
      - /cnb/lifecycle/launcher
      - sidekiq
    preStopCommand:
      - /cnb/lifecycle/launcher
      - sidekiqctl
      - quiet
    terminationGracePeriodSeconds: 60

在容器中运行命令

除非您的仓库包含 自定义 Dockerfile，否则使用 Auto Build 构建的应用程序可能需要将命令包装如下：

/cnb/lifecycle/launcher $COMMAND

您可能需要包装命令的一些原因：

• 使用 kubectl exec 附加。
• 使用 GitLab Web Terminal。

例如，要从应用程序根目录启动 Rails 控制台，运行：

/cnb/lifecycle/launcher procfile exec bin/rails c

Auto Code Intelligence

GitLab code intelligence 添加了 交互式开发环境 (IDE) 中常见的代码导航功能，包括类型签名、符号文档和 go-to-definition。它由 LSIF 提供支持，并且仅适用于使用 Go 语言的 Auto DevOps 项目。GitLab 计划随着更多 LSIF indexers 的可用性增加而对更多语言提供支持。您可以关注 code intelligence epic 获取更新。

此阶段默认启用。您可以通过添加 CODE_INTELLIGENCE_DISABLED CI/CD 变量来禁用它。有关更多信息，请参阅 禁用 Auto DevOps 作业。