• Auto Build
  • 使用 Dockerfile 自动构建
  • 使用 Cloud Native Buildpacks 自动构建
    • 将卷挂载到构建容器中
  • 从 Herokuish 迁移到 Cloud Native Buildpacks
• Auto Test
  • 当前支持的语言
• Auto Code Quality
• Auto SAST
• Auto Secret Detection
• Auto Dependency Scanning
• Auto License Compliance
• Auto Container Scanning
• Auto Review Apps
• Auto DAST
  • 覆盖 DAST 目标
  • 禁用 Auto DAST
• Auto Browser Performance Testing
• Auto Load Performance Testing
• Auto Deploy
  • GitLab deploy tokens
  • Kubernetes 1.16+
  • Migrations
• Auto Monitoring
• Auto Code Intelligence

Auto DevOps 的 Stages

以下部分描述了 Auto DevOps 的各个 stage。 仔细阅读它们，了解每一个是如何工作的。

Auto Build

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

使用 Dockerfile 自动构建

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

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

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

使用 Cloud Native Buildpacks 自动构建

• 默认情况下使用 Cloud Native Buildpacks 自动构建引入于 14.0 版本。

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

每个 buildpack 都需要您项目的仓库包含某些文件，以便 Auto Build 成功构建您的应用。该结构特定于您选择的 builder 和 buildpack。 例如，当使用 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 buildpack 可以使用 Heroku 的 [cnb-shim] (https://github.com/heroku/cnb-shim) 转换为 Cloud Native Buildpack。
• BUILDACK_URL 必须采用 pack 支持的格式。
• /bin/herokuish 命令在构建的镜像中不存在，并且不再需要（也不可能）以 /bin/herokuish procfile exec 为前缀的命令。相反，自定义命令应以 /cnb/lifecycle/launcher 为前缀，以接收正确的执行环境。

Auto Test

自动测试通过分析您的项目，使用 Herokuish 和 Heroku buildpacks 为您的应用运行适当的测试来检测语言和框架。系统会自动检测多种语言和框架，但如果未检测到您的语言，您可以创建一个自定义 buildpack。

自动测试使用您在应用中已有的 tests。如果没有 tests，则由您来添加它们。

当前支持的语言

请注意，并非所有构建包都支持自动测试，因为它是一个相对较新的增强功能。Heroku 的所有官方支持的语言都支持自动测试。Heroku 的 Herokuish buildpack 支持的语言都支持 Auto Test，但值得注意的是 multi-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

自动代码质量使用 Code Quality 镜像对当前代码运行静态分析和其他代码检查。创建报告后，会作为产物上传，您可以稍后下载并检出。合并请求部件还显示任何源分支和目标分支之间的差异。

Auto SAST

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

创建报告后，它会作为产物上传，您可以稍后下载并检出。合并请求部件还显示旗舰版许可证上的任何安全警告。

Auto Secret Detection

Secret Detection 使用 Secret Detection Docker 镜像对当前代码运行 Secret Detection，并检查泄露的 secret。自动 secret 检测需要 GitLab Runner 11.5 或更高版本。

创建报告后，它会作为产物上传，您可以稍后下载和评估。合并请求部件还显示 旗舰版 许可证上的任何安全警告。

Auto Dependency Scanning

Dependency Scanning 对项目的依赖项进行分析并检查潜在的安全问题。 在 旗舰版 以外的许可证上跳过自动依赖扫描阶段，需要 GitLab Runner 11.5 或更高版本。

创建报告后，它会作为产物上传，您可以稍后下载并检出。合并请求部件显示检测到的任何安全警告。

Auto License Compliance

License Compliance 使用 License Compliance Docker 镜像来搜索项目依赖项并获取其许可证。在旗舰版以外的许可证上，跳过 Auto License Compliance stage。

创建报告后，它会作为产物上传，您可以稍后下载并检出。合并请求显示任何检测到的许可证。

Auto Container Scanning

容器的漏洞静态分析使用 Trivy 来检查 Docker 镜像中的潜在安全问题。在旗舰版以外的许可证上跳过 Auto Container Scanning stage。

创建报告后，它会作为产物上传，您可以稍后下载并检出。合并请求显示任何检测到的安全问题。

Auto Review Apps

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

Review Apps 是基于分支代码的临时应用环境，因此开发人员、设计师、QA、产品经理和其他 review 人员可以实际查看代码更改并与之交互，作为 review 过程的一部分。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 也会被删除。

使用 Helm 的 auto-deploy-app chart 部署 Review App，您可以对其进行自定义。应用部署到环境的 Kubernetes 命名空间中。

Auto DAST

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

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

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

覆盖 DAST 目标

要使用自定义目标而不是自动部署的 Review App，请将 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 的文件中，每行一个文件。例如：

/
/features
/direction

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

Auto Load Performance Testing

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

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

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

Auto Deploy

Auto Deploy 是 Auto DevOps 的可选步骤。如果不满足要求，则跳过该作业。

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

Auto Deploy 默认不包括部署到 staging 或 canary 环境，如果您想启用它们，Auto DevOps 模板包含这些任务的作业定义。

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

Helm 使用 auto-deploy-app chart 将应用部署到环境的 Kubernetes 命名空间。

在 11.4 及更高版本中，使用 local Tiller。以前的版本在项目命名空间中安装了 Tiller。

GitLab deploy tokens

GitLab Deploy Tokens 在启用 Auto DevOps 时为内部和私有项目创建，并保存 Auto DevOps 设置。您可以使用部署令牌永久访问镜像库。手动撤销 GitLab deploy tokens 后，它不会自动创建。

如果找不到 GitLab deploy tokens，则使用 CI_REGISTRY_PASSWORD。

Kubernetes 1.16+

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

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

1. 如果您是首次在 13.0 或更高版本中部署应用程序，则无需进行任何配置。

2. 在 12.10 及更早版本中，在 .gitlab/auto-deploy-values.yaml 文件中设置以下内容：

   deploymentApiVersion: apps/v1
   

3. 如果您安装了集群内 PostgreSQL 数据库，并且 AUTO_DEVOPS_POSTGRES_CHANNEL 设置为 1，需要升级 PostgreSQL。

4. 如果您是第一次部署应用并使用 12.9 或 12.10 版本，请将 AUTO_DEVOPS_POSTGRES_CHANNEL 设置为 2。

Migrations

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

如果存在，DB_INITIALIZE 作为 Helm post-install hook，在应用程序 pod 中作为 shell 命令运行。由于某些应用在没有成功的数据库初始化步骤的情况下无法运行，系统在没有应用部署的情况下部署第一个版本，而只有数据库初始化步骤。数据库初始化完成后，系统会正常部署应用部署的第二个版本。

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

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

例如，在使用 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 的命令（或使用 Herokuish，为 /bin/herokuish procfile exec )，复制应用运行的环境。

Auto Monitoring

应用部署后，Auto Monitoring 可帮助您立即监控应用的服务器和响应指标。Auto Monitoring 使用 Prometheus 直接从 Kubernetes 检索系统指标，例如 CPU 和内存使用情况，并从 NGINX 服务器检索响应指标，例如 HTTP 错误率、延迟和吞吐量。

指标包括：

• 响应指标：延迟、吞吐量、错误率
• 系统指标：CPU 利用率、内存利用率

要使用自动监控：

1. 安装和配置 Auto DevOps 要求。
2. 启用 Auto DevOps，如果您还没有这样做的话。
3. 在左侧边栏中，选择 构建 > 流水线。
4. 选择 运行流水线。
5. 流水线成功完成后，打开已部署环境的监控仪表盘，查看已部署应用的指标。要查看整个 Kubernetes 集群的指标，请在左侧栏中选择 监控 > 指标。

Auto Code Intelligence

GitLab Code Intelligence 添加了交互式开发环境 (IDE) 常见的代码导航功能，包括类型签名、符号文档和转到定义。它由 LSIF 提供支持，仅可用于使用 Go 语言的 Auto DevOps 项目。

此 stage 默认启用。您可以通过添加 CODE_INTELLIGENCE_DISABLED CI/CD 变量来禁用它。