Stages of Auto DevOps

• • Auto Build using a Dockerfile
  • Auto Build using Cloud Native Buildpacks (beta)
• • Currently supported languages
• Auto Secret Detection
• Auto License Compliance
• Auto Review Apps
• • Overriding the DAST target
• Auto Browser Performance Testing
• Auto Deploy
  • Kubernetes 1.16+
  • Workers
  • Web Application Firewall (ModSecurity) customization
• Auto Monitoring

Stages of Auto DevOps

以下各节描述了Auto DevOps的阶段. 仔细阅读它们，以了解它们的工作原理.

自动构建使用现有的或 Heroku 构建包创建应用程序的构建. 生成的 Docker 映像被推送到 ，并用提交 SHA 或标记进行标记.

如果项目的存储库在其根目录中包含Dockerfile ，则”自动构建”将使用Dockerfile docker build来创建 Docker 映像.

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

• 将您的应用程序公开到端口5000 ，因为默认的 Helm 图表假定此端口可用.
• 通过覆盖默认值.

Auto Build using Heroku buildpacks

自动构建使用项目的Dockerfile如果存在）构建应用程序. 如果不存在Dockerfile ，它将使用和Heroku buildpacks检测应用程序并将其构建到 Docker 映像中.

每个 buildpack 都需要您项目的存储库包含某些文件，以便 Auto Build 成功构建您的应用程序. 例如，您的应用程序的根目录必须包含与您的应用程序语言相对应的文件：

• 对于 Python 项目，为Pipfile或requirements.txt文件.
• 对于 Ruby 项目，请使用Gemfile或Gemfile.lock文件.

有关其他语言和框架的要求，请阅读 .

提示：如果尽管项目满足 buildpack 要求，但 Auto Build 失败，请设置项目变量TRACE=true启用详细日志记录，这可能有助于您进行故障排除.

Auto Build using Cloud Native Buildpacks (beta)

在引入.

自动构建支持通过pack命令使用构建应用程序. 要使用 Cloud Native Buildpacks，请将 CI 变量AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED设置为非空值. 默认的构建器是heroku/buildpacks:18但是可以使用 CI 变量AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER选择其他构建器.

Cloud Native Buildpacks（CNB）是 Heroku buildpack 的演进，最终将取代 Auto DevOps 中基于 Herokuish 的构建. 有关更多信息，请参见此问题 .

使用 Cloud Native Buildpacks 的构建与使用 Heroku buildpacks 的构建支持相同的选项，但有以下警告：

• 该构建包必须是 Cloud Native Buildpack. 可以使用 Heroku 的 cnb 将 Heroku 构建包转换为 Cloud Native 构建包.
• BUILDPACK_URL必须采用pack支持的格式.
• /bin/herokuish命令不出现在结果图像中，并且不再需要（也不可能）使用/bin/herokuish procfile exec作为前缀命令.

Note: Auto Test still uses Herokuish, as test suite detection is not yet part of the Cloud Native Buildpack specification. For more information, see .

Auto Test

自动测试通过分析项目以检测语言和框架，使用和Heroku构建为您的应用程序运行适当的测试. 系统会自动检测到多种语言和框架，但是如果未检测到您的语言，则可以创建自定义 buildpack . 检查 .

自动测试使用您的应用程序中已有的测试. 如果没有测试，则由您决定添加它们.

Currently supported languages

请注意，并不是所有的 buildpack 都支持自动测试，因为它是一个相对较新的增强功能. Heroku 的所有支持自动测试. Heroku 的 Herokuish buildpack 支持的语言都支持自动测试，但值得注意的是 multi-buildpack 不支持.

支持的构建包是：

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

Auto Code Quality

自动代码质量使用代码质量图像对当前代码运行静态分析和其他代码检查. 创建报告后，报告将作为工件上传，您可以稍后下载并签出. 合并请求小部件还显示任何差异 .

Auto SAST

在GitLab Ultimate 10.3 中引入.

Static Application Security Testing (SAST) uses the to run static analysis on the current code, and checks for potential security issues. The Auto SAST stage will be skipped on licenses other than Ultimate, and requires 11.5 or above.

创建报告后，报告将作为工件上传，您可以稍后下载并签出. 合并请求小部件还显示任何安全警告.

要了解有关SAST 工作原理的更多信息，请参阅文档.

在 13.1 中引入.

秘密检测使用秘密检测 Docker 映像在当前代码上运行秘密检测，并检查泄漏的秘密. 自动秘密检测阶段仅在层上运行，并且需要GitLab Runner 11.5 或更高版本.

创建报告后，报告将作为工件上传，您可以稍后下载和评估. 合并请求小部件还显示任何安全警告.

要了解更多信息，请参阅 .

Auto Dependency Scanning

在 10.7 中引入.

Dependency Scanning 使用Dependency Scanning Docker 映像对项目依赖项进行分析，并检查潜在的安全问题. 在非许可证上，将跳过”自动依赖项扫描”阶段，并且需要GitLab Runner 11.5 或更高版本.

创建报告后，报告将作为工件上传，您可以稍后下载并签出. 合并请求小部件显示检测到的所有安全警告，

要了解有关” 更多信息，请参阅文档.

Auto License Compliance

在 11.0 中引入.

许可证合规性使用许可证合规性 Docker 映像在项目依赖项中搜索其许可证. 除以外的其他许可证将跳过”自动许可证合规性”阶段.

创建报告后，报告将作为工件上传，您可以稍后下载并签出. 合并请求显示所有检测到的许可证.

要了解有关许可证合规性的更多 ，请参阅文档.

Auto Container Scanning

在 GitLab 10.4 中引入.

创建报告后，报告将作为工件上传，您可以稍后下载并签出. 合并请求显示所有检测到的安全问题.

To learn more about , see the documentation.

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

是基于分支机构代码的临时应用程序环境，因此开发人员，设计人员，质量检查人员，产品经理和其他审阅者可以在审阅过程中实际查看代码更改并与之交互. 自动审核应用程序为每个分支创建一个审核应用程序.

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

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

可以使用带有 Helm 的auto-deploy-app图表来部署评论应用，您可以对其进行 . 该应用程序将部署到环境的Kubernetes 命名空间中.

从 GitLab 11.4 开始，使用 . 早期版本的 GitLab 在项目名称空间中安装了一个 Tiller.

注意：您的应用程序不应该（直接使用 Kubernetes）以外的操纵舵的. 这可能会导致 Helm 无法检测到更改而造成混乱，随后使用 Auto DevOps 进行的部署可能会撤消您的更改. 同样，如果您更改了某些内容并想通过再次部署来撤消它，Helm 可能不会在一开始就检测到任何更改，因此不会意识到它需要重新应用旧配置.

Auto DAST

在 10.4 中引入.

动态应用程序安全测试（DAST）使用流行的开源工具OWASP ZAProxy分析当前代码并检查潜在的安全问题. 除以外的其他许可证将跳过 Auto DAST 阶段.

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

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

To learn more about , see the documentation.

要使用自定义目标而不是自动部署的审阅应用程序，请将DAST_WEBSITE环境变量设置为 URL 以便 DAST 进行扫描.

危险：如果启用了DAST Full Scan ，则 GitLab 强烈建议不要将DAST_WEBSITE设置为任何暂存或生产环境. DAST 全面扫描会主动攻击目标，这可能会破坏您的应用程序并导致数据丢失或损坏.

Disabling Auto DAST

您可以禁用 DAST：

• 通过将DAST_DISABLED环境变量设置为"true"在所有分支上.
• 通过将DAST_DISABLED_FOR_DEFAULT_BRANCH环境变量设置为"true"仅在默认分支上.
• 通过将环境变量REVIEW_DISABLED设置为"true"仅在要素分支上. 这也会禁用 Review App.

Auto Browser Performance Testing

在 10.4 中引入.

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

/
/features
/direction

合并请求小部件中还会源分支与目标分支之间的任何浏览器性能差异.

Auto Load Performance Testing

在 13.2 中引入.

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

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

中还会显示源分支与目标分支之间的任何负载性能测试结果差异.

这是一个可选步骤，因为许多项目没有可用的 Kubernetes 集群. 如果不满足 ，则跳过该作业.

将分支或合并请求合并到项目的默认分支（通常是master ）后，Auto Deploy 会将应用程序部署到 Kubernetes 集群中的环境中，该环境具有基于项目名称和唯一项目 ID 的命名空间，例如project-4321 .

默认情况下，”自动部署”不包括到暂存或 Canary 环境的部署，但是如果要启用这些任务，则” Auto DevOps”模板包含这些任务的作业定义.

您可以使用来自动缩放 Pod 副本，并将自定义参数应用于 Auto DevOps helm upgrade命令. 这是自定义 Auto Deploy Helm 图表的简便方法.

Helm 使用图表将应用程序部署到环境的Kubernetes 命名空间中.

从 GitLab 11.4 开始，将使用 . 早期版本的 GitLab 在项目名称空间中安装了一个 Tiller.

注意：您的应用程序不应该（直接使用 Kubernetes）以外的操纵舵的. 这可能会导致 Helm 无法检测到更改而造成混乱，随后使用 Auto DevOps 进行的部署可能会撤消您的更改. 同样，如果您更改了某些内容并想通过再次部署来撤消它，Helm 可能不会在一开始就检测到任何更改，因此不会意识到它需要重新应用旧配置.

GitLab deploy tokens

在 GitLab 11.0 中 .

启用 Auto DevOps 时，将为内部和私有项目创建GitLab 部署令牌 ，并保存 Auto DevOps 设置. 您可以使用部署令牌对注册表进行永久访问. 手动吊销 GitLab 部署令牌后，将不会自动创建它.

如果找不到 GitLab 部署令牌，则使用CI_REGISTRY_PASSWORD .

Note: CI_REGISTRY_PASSWORD is only valid during deployment. Kubernetes will be able to successfully pull the container image during deployment, but if the image must be pulled again, such as after pod eviction, Kubernetes will fail to do so as it attempts to fetch the image using CI_REGISTRY_PASSWORD.

Kubernetes 1.16+

版本历史

• 在 GitLab 12.8 中引入 .
• 自 GitLab 13.0 起为新部署提供开箱即用的支持.

弃用：在 ， deploymentApiVersion设置的默认值已从extensions/v1beta更改为apps/v1 .

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

1. 如果您是第一次在 GitLab 13.0 或更高版本上部署应用程序，则无需进行配置.

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

   deploymentApiVersion: apps/v1

3. 如果您安装了集群内 PostgreSQL 数据库，并且AUTO_DEVOPS_POSTGRES_CHANNEL设置为1 ，请按照 .

4. 如果您是第一次部署应用程序，并且使用的是 GitLab 12.9 或 12.10，请将AUTO_DEVOPS_POSTGRES_CHANNEL设置为2 .

危险：在 GitLab 12.9 和 12.10 上，选择使用AUTO_DEVOPS_POSTGRES_CHANNEL版本2会删除版本1 PostgreSQL 数据库. 在选择版本2之前，请遵循升级 PostgreSQL的备份和还原数据库（在 GitLab 13.0 上，需要附加变量来触发数据库删除）.

在 GitLab 11.4 中引入

您可以通过分别设置项目变量DB_INITIALIZE和DB_MIGRATE来配置 PostgreSQL 的数据库初始化和迁移，以使其在应用程序窗格中运行.

如果存在， DB_INITIALIZE作为 Shell 命令作为 Helm 安装后挂钩在外壳中运行. 由于某些应用程序如果没有成功的数据库初始化步骤就无法运行，因此 GitLab 部署的第一个发行版没有应用程序部署，而只有数据库初始化步骤. 数据库初始化完成后，GitLab 部署第二个版本，并且应用程序部署正常.

请注意，安装后挂钩意味着如果任何部署成功，则DB_INITIALIZE将不再处理DB_INITIALIZE .

如果存在， DB_MIGRATE作为 Shell 命令作为 Helm 预升级挂钩在 Shell 中运行.

例如，在用构建的图像中的 Rails 应用程序中：

• 可以将DB_INITIALIZE设置为RAILS_ENV=production /bin/herokuish procfile exec bin/rails db:setup
• 可以将DB_MIGRATE设置为RAILS_ENV=production /bin/herokuish procfile exec bin/rails db:migrate

除非您的存储库包含Dockerfile ，否则映像是使用 Herokuish 构建的，并且必须在这些映像中运行的命令前加上/bin/herokuish procfile exec前缀，以复制将在其中运行应用程序的环境.

Workers

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

Auto Deploy 中使用的 支持运行工作进程 .

要运行工作程序，必须确保工作程序可以响应标准的运行状况检查，该检查将在端口5000上期望成功的 HTTP 响应. 对于 ，可以使用sidekiq_alive gem .

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

• 维护您自己的 Redis 实例.
• 设置 CI 变量K8S_SECRET_REDIS_URL ，它是该实例的 URL，以确保将其传递到您的部署中.

在将工作程序配置为对运行状况检查作出响应之后，为您的 Rails 应用程序运行 Sidekiq 工作程序. 您可以通过在设置以下内容来启用工作.gitlab/auto-deploy-values.yaml ：

Network Policy

在 GitLab 12.7 中引入 .

默认情况下，所有 Kubernetes 容器都是 ，并且接受来自任何来源的流量. 您可以使用NetworkPolicy限制与选定 Pod，名称空间和 Internet 之间的连接.

注意：您必须使用 Kubernetes 网络插件来实现对NetworkPolicy支持. Kubernetes（ kubenet ）的默认网络插件 kubenet支持. 可以将Cilium网络插件安装为以支持网络策略.

您可以通过在.gitlab/auto-deploy-values.yaml文件中设置以下内容来启用网络策略.gitlab/auto-deploy-values.yaml ：

networkPolicy:
  enabled: true

Auto Deploy 管道部署的默认策略允许本地名称空间内以及gitlab-managed-apps名称空间的gitlab-managed-apps . 所有其他入站连接均被阻止. 出站流量（例如，到 Internet 的流量）不受默认策略的影响.

您还可以在.gitlab/auto-deploy-values.yaml文件中提供自定义策略规范 ，例如：

networkPolicy:
  enabled: true
  spec:
    podSelector:
      matchLabels:
        app.gitlab.com/env: staging
    ingress:
      - from:
        - podSelector:
            matchLabels: {}
        - namespaceSelector:
            matchLabels:
              app.gitlab.com/managed_by: gitlab

有关安装网络策略的更多信息，请参阅 .

Web Application Firewall (ModSecurity) customization

在 GitLab 12.8 中 .

安装了群集可以在Ingress或部署基础上进行自定义.

要在 Auto Deploy 中启用 ModSecurity，必须在项目中使用以下属性创建.gitlab/auto-deploy-values.yaml文件.

在以下auto-deploy-values.yaml示例中，为 ModSecurity 启用了一些自定义设置. 其中包括将其引擎设置为处理规则，而不是仅记录规则，同时添加两个基于标头的特定规则：

除非您的存储库包含 ，否则默认情况下使用 Herokuish 使用Auto Build 构建的应用程序可能要求将命令包装如下：

/bin/herokuish procfile exec $COMMAND

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

• 使用kubectl exec附加.
• 使用 GitLab 的 .

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

/bin/herokuish procfile exec bin/rails c

Auto Monitoring

部署应用程序后，”自动监视”可帮助您立即监视应用程序的服务器和响应指标. 自动监控使用直接从Kubernetes检索系统指标，例如 CPU 和内存使用情况，以及从检索响应指标，例如 HTTP 错误率，延迟和吞吐量.

指标包括：

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

安装 Prometheus 之后，GitLab 会为您提供一些初始警报：

• 入口状态码 > 0.1％
• NGINX 状态码500 > 0.1％

要使用自动监视：

1. Install and configure the Auto DevOps requirements.
2. 如果尚未 ，请启用它 .
3. 管道成功完成后，打开已的监视仪表板以查看已部署应用程序的指标. 要查看整个 Kubernetes 集群的指标，请导航至 操作>指标 .