Stages of Auto DevOps

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

• Auto Build
  • Auto Build using a Dockerfile
  • Auto Build using Heroku buildpacks
  • Auto Build using Cloud Native Buildpacks (beta)
• Auto Test
  • Currently supported languages
• Auto Code Quality
• Auto SAST
• Auto Secret Detection
• Auto Dependency Scanning
• Auto License Compliance
• Auto Container Scanning
• Auto Review Apps
• Auto DAST
  • Overriding the DAST target
  • Disabling Auto DAST
• Auto Browser Performance Testing
• Auto Load Performance Testing
• Auto Deploy
  • GitLab deploy tokens
  • Kubernetes 1.16+
  • Migrations
  • Workers
  • Network Policy
  • Web Application Firewall (ModSecurity) customization
  • Running commands in the container
• Auto Monitoring

Stages of Auto DevOps

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

Auto Build

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

Auto Build using a Dockerfile

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

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

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

Auto Build using Heroku buildpacks

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

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

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

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

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

Auto Build using Cloud Native Buildpacks (beta)

在GitLab 12.10 中引入.

自动构建支持通过pack命令使用Cloud Native Buildpacks构建应用程序. 要使用 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 cnb-shim将 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 this issue.

Auto Test

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

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

Currently supported languages

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

Auto Code Quality

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

Auto SAST

在GitLab Ultimate 10.3 中引入.

Static Application Security Testing (SAST) uses the SAST Docker image 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 GitLab Runner 11.5 or above.

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

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

Auto Secret Detection

在GitLab Ultimate 13.1 中引入.

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

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

要了解更多信息，请参阅秘密检测 .

Auto Dependency Scanning

在GitLab Ultimate 10.7 中引入.

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

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

要了解有关” 依赖关系扫描”的更多信息，请参阅文档.

Auto License Compliance

在GitLab Ultimate 11.0 中引入.

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

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

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

Auto Container Scanning

在 GitLab 10.4 中引入.

Vulnerability Static Analysis for containers uses Clair to check for potential security issues on Docker images. The Auto Container Scanning stage is skipped on licenses other than Ultimate.

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

To learn more about Container Scanning, see the documentation.

Auto Review Apps

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

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

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 开始，使用本地 Tiller . 早期版本的 GitLab 在项目名称空间中安装了一个 Tiller.

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

Auto DAST

在GitLab Ultimate 10.4 中引入.

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

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

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

To learn more about Dynamic Application Security Testing, see the documentation.

Overriding the DAST target

要使用自定义目标而不是自动部署的审阅应用程序，请将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

在GitLab Premium 10.4 中引入.

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

/
/features
/direction

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

Auto Load Performance Testing

在GitLab Premium 13.2 中引入.

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

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

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

Auto Deploy

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

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

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

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

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

从 GitLab 11.4 开始，将使用本地 Tiller . 早期版本的 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 12.9 中引入了对部署支持 Kubernetes 1.16+的 PostgreSQL 版本的支持.
• 自 GitLab 13.0 起为新部署提供开箱即用的支持.

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

在 Kubernetes 1.16 和更高版本中， 删除了许多API ，包括在extensions/v1beta1版本中支持Deployment .

要在 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 ，请按照指南升级 PostgreSQL .

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 上，需要附加变量来触发数据库删除）.

Migrations

在 GitLab 11.4 中引入

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

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

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

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

例如，在用Herokuish构建的图像中的 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 中使用的默认 Helm 图表 支持运行工作进程 .

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

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

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

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

workers:
  sidekiq:
    replicaCount: 1
    command:
      - /bin/herokuish
      - procfile
      - exec
      - sidekiq
    preStopCommand:
      - /bin/herokuish
      - procfile
      - exec
      - sidekiqctl
      - quiet
    terminationGracePeriodSeconds: 60

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

有关安装网络策略的更多信息，请参阅使用 GitLab CI / CD 安装 Cilium .

Web Application Firewall (ModSecurity) customization

在 GitLab 12.8 中引入 .

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

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

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

ingress:
  modSecurity:
    enabled: true
    secRuleEngine: "On"
    secRules:
      - variable: "REQUEST_HEADERS:User-Agent"
        operator: "printer"
        action: "log,deny,id:'2010',status:403,msg:'printer  is  an  invalid  agent'"
      - variable: "REQUEST_HEADERS:Content-Type"
        operator: "text/plain"
        action: "log,deny,id:'2011',status:403,msg:'Text  is  not  supported  as  content  type'"

Running commands in the container

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

/bin/herokuish procfile exec $COMMAND

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

• 使用kubectl exec附加.
• 使用 GitLab 的Web 终端 .

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

/bin/herokuish procfile exec bin/rails c

Auto Monitoring

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

指标包括：

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

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

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

要使用自动监视：

1. Install and configure the Auto DevOps requirements.
2. 如果尚未启用 Auto DevOps ，请启用它 .
3. 导航到您项目的 CI / CD>管道 ，然后单击运行管道 .
4. 管道成功完成后，打开已部署环境的监视仪表板以查看已部署应用程序的指标. 要查看整个 Kubernetes 集群的指标，请导航至 操作>指标 .