• 自动构建
  • 使用 Dockerfile 自动构建
  • 使用 Cloud Native Buildpacks 自动构建
    • 将卷挂载到构建容器中
  • 从 Herokuish 移动到 Cloud Native Buildpacks
• 自动测试
  • 当前支持的语言
• 自动代码质量
• 自动 SAST
• 自动密钥检测
• 自动依赖扫描
• 自动容器扫描
• 自动审查应用程序
• 自动 DAST
  • 覆盖 DAST 目标
  • 跳过自动 DAST
• 自动浏览器性能测试
• 自动负载性能测试
• 自动部署
  • 极狐GitLab 部署令牌
  • Kubernetes 1.16+
  • 迁移
  • 升级 auto-deploy-app 图表
  • 工作者
  • 在容器中运行命令
• 自动代码智能

{{< details >}}

• Tier: 基础版, 专业版, 旗舰版
• Offering: JihuLab.com, 私有化部署

{{< /details >}}

下面的章节描述了自动 DevOps的阶段。仔细阅读它们以了解每个阶段是如何工作的。

自动构建

{{< alert type=”note” >}}

如果你的极狐GitLab Runner 中的 Docker in Docker 不可用，例如在 OpenShift 集群中，则不支持自动构建。

{{< /alert >}}

自动构建使用现有的 Dockerfile 或 Heroku 构建包创建应用程序的构建。生成的 Docker 镜像被推送到容器镜像仓库，并使用提交的 SHA 或标记进行标记。

使用 Dockerfile 自动构建

如果项目的代码库在其根目录中包含一个 Dockerfile，自动构建使用 docker build 来创建一个 Docker 镜像。

如果您也在使用自动审查应用程序和自动部署，并且选择提供自己的 Dockerfile，您必须：

• 将您的应用程序暴露给端口 5000，因为默认 Helm chart 假定这个端口是可用的。
• 通过自定义自动部署 Helm chart来覆盖默认值。

使用 Cloud Native Buildpacks 自动构建

自动构建使用项目的 Dockerfile 来构建应用程序（如果存在）。如果没有 Dockerfile，自动构建使用 Cloud Native Buildpacks 来检测和构建应用程序到 Docker 镜像中。该功能使用 pack 命令是 heroku/buildpacks:22，但可以使用 CI/CD 变量 AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER 选择不同的构建器。

每个构建包要求您的项目代码库包含某些文件，以便自动构建成功构建您的应用程序。结构是特定于您选择的构建器和构建包的。例如，使用 Heroku 构建器（默认）时，您的应用程序根目录必须包含适合您应用程序语言的文件：

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

{{< alert type=”note” >}}

自动测试仍然使用 Herokuish，因为测试套件检测尚未成为 Cloud Native Buildpack 规范的一部分。

{{< /alert >}}

将卷挂载到构建容器中

变量 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

从 Herokuish 移动到 Cloud Native Buildpacks

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

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

自动测试

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

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

{{< alert type=”note” >}}

并非所有 自动构建 支持的构建包都支持自动测试。自动测试使用 Herokuish，而不是 Cloud Native Buildpacks，并且只有实现 Testpack API 的构建包才被支持。

{{< /alert >}}

当前支持的语言

并非所有构建包都支持自动测试，因为它是一个相对较新的增强功能。Heroku 的官方支持语言都支持自动测试。Heroku 的 Herokuish 构建包支持的语言都支持自动测试，但值得注意的是多构建包不支持。

支持的构建包有：

- 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

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

自动代码质量

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

自动 SAST

{{< history >}}

• 在极狐GitLab 旗舰版 10.3 中引入。
• 从 13.1 开始在所有层级中提供选择功能

{{< /history >}}

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

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

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

自动密钥检测

密钥检测使用密钥检测 Docker 镜像对当前代码运行密钥检测，并检查泄露的密钥。

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

有关更多信息，请参阅密钥检测。

自动依赖扫描

{{< details >}}

• Tier: 旗舰版
• Offering: JihuLab.com, 私有化部署

{{< /details >}}

依赖扫描对项目的依赖项进行分析，并检查潜在的安全问题。在旗舰版以外的许可证中，自动依赖扫描阶段被跳过。

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

有关更多信息，请参阅依赖扫描。

自动容器扫描

容器的静态漏洞分析使用 Trivy 检查 Docker 镜像中的潜在安全问题。在旗舰版以外的许可证中，自动容器扫描阶段被跳过。

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

有关更多信息，请参阅容器扫描。

自动审查应用程序

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

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

自动审查应用程序仅将您的应用程序部署到您的 Kubernetes 集群中。如果没有集群可用，则不会进行部署。

审查应用程序具有一个基于项目 ID、分支或标签名称、唯一编号和自动 DevOps 基础域组合的唯一 URL，例如 13083-review-project-branch-123456.example.com。合并请求小部件显示指向审查应用程序的链接以便于发现。当分支或标签被删除时，例如合并请求合并后，审查应用程序也会被删除。

审查应用程序是使用 Helm 部署的 auto-deploy-app 图表，您可以自定义。应用程序部署到环境的Kubernetes 命名空间中。

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

{{< alert type=”warning” >}}

您的应用程序不应在 Helm 之外进行操作（直接使用 Kubernetes）。这可能会导致 Helm 无法检测到更改，并且后续的自动 DevOps 部署可能会撤销您的更改。此外，如果您更改了某些内容并想通过再次部署来撤销它，Helm 可能无法检测到任何更改，从而无法意识到需要重新应用旧配置。

{{< /alert >}}

自动 DAST

{{< details >}}

• Tier: 旗舰版
• Offering: JihuLab.com, 私有化部署

{{< /details >}}

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

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

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

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

覆盖 DAST 目标

要使用自定义目标而不是自动部署的审查应用程序，请将 DAST_WEBSITE CI/CD 变量设置为 DAST 要扫描的 URL。

{{< alert type=”warning” >}}

如果启用了DAST 完全扫描，极狐GitLab 强烈建议不要将 DAST_WEBSITE 设置为任何暂存或生产环境。DAST 完全扫描会主动攻击目标，这可能导致应用程序宕机并导致数据丢失或损坏。

{{< /alert >}}

跳过自动 DAST

您可以跳过 DAST 作业：

• 通过设置 DAST_DISABLED CI/CD 变量为 "true" 在所有分支上。
• 仅在默认分支上，通过设置 DAST_DISABLED_FOR_DEFAULT_BRANCH 变量为 "true"。
• 仅在功能分支上，通过设置 REVIEW_DISABLED 变量为 "true"。这也会跳过审查应用程序。

自动浏览器性能测试

{{< details >}}

• Tier: Premium, Ultimate
• Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

{{< /details >}}

自动浏览器性能测试 使用 Sitespeed.io 容器测量网页的浏览器性能，创建包含每个页面整体性能分数的 JSON 报告，并将报告作为产物上传。默认情况下，它测试您的审查和生产环境的根页面。如果您想测试其他 URL，请将路径添加到根目录中的一个名为 .gitlab-urls.txt 的文件中，每行一个文件。例如：

/
/features
/direction

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

自动负载性能测试

{{< details >}}

• Tier: Premium, Ultimate
• Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

{{< /details >}}

自动负载性能测试 使用 k6 容器测量应用程序的服务器性能，创建包含多个关键结果指标的 JSON 报告，并将报告作为产物上传。

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

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

自动部署

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

自动部署是自动 DevOps 的一个可选步骤。如果不满足要求，作业将被跳过。

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

自动部署默认不包括部署到暂存或金丝雀环境，但自动 DevOps 模板 包含这些任务的作业定义，如果您想启用它们。

您可以使用 CI/CD 变量 自动缩放您的 pod 副本，并为自动 DevOps helm upgrade 命令应用自定义参数。这是自定义自动部署 Helm chart的简单方法。

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

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

{{< alert type=”warning” >}}

您的应用程序不应在 Helm 之外进行操作（直接使用 Kubernetes）。这可能会导致 Helm 无法检测到更改，并且后续的自动 DevOps 部署可能会撤销您的更改。此外，如果您更改了某些内容并想通过再次部署来撤销它，Helm 可能无法检测到任何更改，从而无法意识到需要重新应用旧配置。

{{< /alert >}}

极狐GitLab 部署令牌

极狐GitLab 部署令牌 在启用自动 DevOps 时为内部和私有项目创建，并保存自动 DevOps 设置。您可以使用部署令牌永久访问注册表。在您手动撤销极狐GitLab 部署令牌后，它不会自动创建。

如果找不到极狐GitLab 部署令牌，则使用 CI_REGISTRY_PASSWORD。

{{< alert type=”note” >}}

CI_REGISTRY_PASSWORD 仅在部署期间有效。Kubernetes 可以在部署期间成功拉取容器镜像，但如果必须再次拉取镜像，例如在 pod 驱逐后，Kubernetes 无法这样做，因为它尝试使用 CI_REGISTRY_PASSWORD 获取镜像。

{{< /alert >}}

Kubernetes 1.16+

{{< alert type=”warning” >}}

deploymentApiVersion 设置的默认值从 extensions/v1beta 更改为 apps/v1。

{{< /alert >}}

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

要在 Kubernetes 1.16+ 集群上使用自动部署：

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

2. 如果您有一个集群中的 PostgreSQL 数据库，安装了 AUTO_DEVOPS_POSTGRES_CHANNEL 设置为 1，请按照升级 PostgreSQL 的指南进行操作。

{{< alert type=”warning” >}}

按照升级 PostgreSQL 的指南在选择加入版本 2 之前备份和恢复您的数据库。

{{< /alert >}}

迁移

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

如果存在，DB_INITIALIZE 作为 Helm 后安装钩子在应用程序 pod 中作为 shell 命令运行。由于某些应用程序在没有成功的数据库初始化步骤时无法运行，极狐GitLab 在没有应用程序部署的情况下部署第一个版本，仅进行数据库初始化步骤。数据库初始化完成后，极狐GitLab 以标准的应用程序部署方式部署第二个版本。

后安装钩子意味着如果任何部署成功，DB_INITIALIZE 将不再被处理。

如果存在，DB_MIGRATE 作为 Helm 预升级钩子在应用程序 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 前缀以复制应用程序运行的环境。

升级 auto-deploy-app 图表

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

工作者

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

在自动部署中使用的默认 Helm chart 支持运行工作进程。

要运行工作进程，您必须确保工作进程能够响应标准健康检查，这要求在端口 5000 上成功的 HTTP 响应。对于 Sidekiq，您可以使用 sidekiq_alive gem。

要与 Sidekiq 一起工作，您还必须确保您的部署可以访问 Redis 实例。自动 DevOps 不会为您部署此实例，因此您必须：

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

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

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

在容器中运行命令

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

/cnb/lifecycle/launcher $COMMAND

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

• 使用 kubectl exec 附加。
• 使用极狐GitLab Web 终端。

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

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

自动代码智能

极狐GitLab 代码智能 添加了交互式开发环境 (IDE) 常见的代码导航功能，包括类型签名、符号文档和转到定义。它由 LSIF 提供支持，并可用于使用 Go 语言的自动 DevOps 项目。极狐GitLab 计划在更多 LSIF 索引器可用时添加对更多语言的支持。

此阶段默认启用。您可以通过添加 CODE_INTELLIGENCE_DISABLED CI/CD 变量禁用它。阅读有关禁用自动 DevOps 作业的更多信息。