# Stages of Auto DevOps
> 原文：[https://docs.gitlab.com/ee/topics/autodevops/stages.html](https://docs.gitlab.com/ee/topics/autodevops/stages.html)
* [Auto Build](#auto-build)
* [Auto Build using a Dockerfile](#auto-build-using-a-dockerfile)
* [Auto Build using Heroku buildpacks](#auto-build-using-heroku-buildpacks)
* [Auto Build using Cloud Native Buildpacks (beta)](#auto-build-using-cloud-native-buildpacks-beta)
* [Auto Test](#auto-test)
* [Currently supported languages](#currently-supported-languages)
* [Auto Code Quality](#auto-code-quality-starter)
* [Auto SAST](#auto-sast-ultimate)
* [Auto Secret Detection](#auto-secret-detection-ultimate)
* [Auto Dependency Scanning](#auto-dependency-scanning-ultimate)
* [Auto License Compliance](#auto-license-compliance-ultimate)
* [Auto Container Scanning](#auto-container-scanning-ultimate)
* [Auto Review Apps](#auto-review-apps)
* [Auto DAST](#auto-dast-ultimate)
* [Overriding the DAST target](#overriding-the-dast-target)
* [Disabling Auto DAST](#disabling-auto-dast)
* [Auto Browser Performance Testing](#auto-browser-performance-testing-premium)
* [Auto Load Performance Testing](#auto-load-performance-testing-premium)
* [Auto Deploy](#auto-deploy)
* [GitLab deploy tokens](#gitlab-deploy-tokens)
* [Kubernetes 1.16+](#kubernetes-116)
* [Migrations](#migrations)
* [Workers](#workers)
* [Network Policy](#network-policy)
* [Web Application Firewall (ModSecurity) customization](#web-application-firewall-modsecurity-customization)
* [Running commands in the container](#running-commands-in-the-container)
* [Auto Monitoring](#auto-monitoring)
# Stages of Auto DevOps[](#stages-of-auto-devops "Permalink")
以下各节描述了[Auto DevOps](index.html)的阶段. 仔细阅读它们，以了解它们的工作原理.
## Auto Build[](#auto-build "Permalink")
自动构建使用现有的`Dockerfile`或 Heroku 构建包创建应用程序的构建. 生成的 Docker 映像被推送到[Container Registry](../../user/packages/container_registry/index.html) ，并用提交 SHA 或标记进行标记.
### Auto Build using a Dockerfile[](#auto-build-using-a-dockerfile "Permalink")
如果项目的存储库在其根目录中包含`Dockerfile` ，则"自动构建"将使用`Dockerfile` `docker build`来创建 Docker 映像.
如果您还使用 Auto Review Apps 和 Auto Deploy，并且选择提供自己的`Dockerfile` ，那么您必须：
* 将您的应用程序公开到端口`5000` ，因为[默认的 Helm 图表](https://gitlab.com/gitlab-org/charts/auto-deploy-app)假定此端口可用.
* 通过[自定义 Auto Deploy Helm 图表来](customize.html#custom-helm-chart)覆盖默认值.
### Auto Build using Heroku buildpacks[](#auto-build-using-heroku-buildpacks "Permalink")
自动构建使用项目的`Dockerfile`如果存在）构建应用程序. 如果不存在`Dockerfile` ，它将使用[Herokuish](https://github.com/gliderlabs/herokuish)和[Heroku buildpacks](https://devcenter.heroku.com/articles/buildpacks)检测应用程序并将其构建到 Docker 映像中.
每个 buildpack 都需要您项目的存储库包含某些文件，以便 Auto Build 成功构建您的应用程序. 例如，您的应用程序的根目录必须包含与您的应用程序语言相对应的文件：
* 对于 Python 项目，为`Pipfile`或`requirements.txt`文件.
* 对于 Ruby 项目，请使用`Gemfile`或`Gemfile.lock`文件.
有关其他语言和框架的要求，请阅读[Heroku buildpacks 文档](https://devcenter.heroku.com/articles/buildpacks#officially-supported-buildpacks) .
**提示：**如果尽管项目满足 buildpack 要求，但 Auto Build 失败，请设置项目变量`TRACE=true`启用详细日志记录，这可能有助于您进行故障排除.
### Auto Build using Cloud Native Buildpacks (beta)[](#auto-build-using-cloud-native-buildpacks-beta "Permalink")
在[GitLab 12.10 中](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28165)引入.
自动构建支持通过[`pack`命令](https://github.com/buildpacks/pack)使用[Cloud Native Buildpacks](https://buildpacks.io)构建应用程序. 要使用 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 的构建. 有关更多信息，请参见此[问题](https://gitlab.com/gitlab-org/gitlab/-/issues/212692) .
使用 Cloud Native Buildpacks 的构建与使用 Heroku buildpacks 的构建支持相同的选项，但有以下警告：
* 该构建包必须是 Cloud Native Buildpack. 可以使用 Heroku 的 cnb [`cnb-shim`](https://github.com/heroku/cnb-shim)将 Heroku 构建包转换为 Cloud Native 构建包.
* `BUILDPACK_URL`必须[采用`pack`支持](https://buildpacks.io/docs/app-developer-guide/specific-buildpacks/)的格式.
* `/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](https://gitlab.com/gitlab-org/gitlab/-/issues/212689).
## Auto Test[](#auto-test "Permalink")
自动测试通过分析项目以检测语言和框架，使用[Herokuish](https://github.com/gliderlabs/herokuish)和[Heroku](https://devcenter.heroku.com/articles/buildpacks)构建[包](https://github.com/gliderlabs/herokuish)为您的应用程序运行适当的测试. 系统会自动检测到多种语言和框架，但是如果未检测到您的语言，则可以创建[自定义 buildpack](customize.html#custom-buildpacks) . 检查[当前支持的语言](#currently-supported-languages) .
自动测试使用您的应用程序中已有的测试. 如果没有测试，则由您决定添加它们.
### Currently supported languages[](#currently-supported-languages "Permalink")
请注意，并不是所有的 buildpack 都支持自动测试，因为它是一个相对较新的增强功能. Heroku 的所有[官方支持的语言都](https://devcenter.heroku.com/articles/heroku-ci#supported-languages)支持自动测试. 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](customize.html#custom-buildpacks) .
## Auto Code Quality[](#auto-code-quality-starter "Permalink")
自动代码质量使用[代码质量图像](https://gitlab.com/gitlab-org/ci-cd/codequality)对当前代码运行静态分析和其他代码检查. 创建报告后，报告将作为工件上传，您可以稍后下载并签出. 合并请求小部件还显示[源分支和目标分支之间的](../../user/project/merge_requests/code_quality.html)任何[差异](../../user/project/merge_requests/code_quality.html) .
## Auto SAST[](#auto-sast-ultimate "Permalink")
在[GitLab Ultimate](https://about.gitlab.com/pricing/) 10.3 中引入.
Static Application Security Testing (SAST) uses the [SAST Docker image](https://gitlab.com/gitlab-org/security-products/sast) 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](https://about.gitlab.com/pricing/), and requires [GitLab Runner](https://docs.gitlab.com/runner/) 11.5 or above.
创建报告后，报告将作为工件上传，您可以稍后下载并签出. 合并请求小部件还显示任何安全警告.
要了解有关[SAST 工作原理的](../../user/application_security/sast/index.html)更多信息，请参阅文档.
## Auto Secret Detection[](#auto-secret-detection-ultimate "Permalink")
在[GitLab Ultimate](https://about.gitlab.com/pricing/) 13.1 中引入.
秘密检测使用[秘密检测 Docker 映像](https://gitlab.com/gitlab-org/security-products/analyzers/secrets)在当前代码上运行秘密检测，并检查泄漏的秘密. 自动秘密检测阶段仅在[Ultimate](https://about.gitlab.com/pricing/)层上运行，并且需要[GitLab Runner](https://docs.gitlab.com/runner/) 11.5 或更高版本.
创建报告后，报告将作为工件上传，您可以稍后下载和评估. 合并请求小部件还显示任何安全警告.
要了解更多信息，请参阅[秘密检测](../../user/application_security/secret_detection/index.html) .
## Auto Dependency Scanning[](#auto-dependency-scanning-ultimate "Permalink")
在[GitLab Ultimate](https://about.gitlab.com/pricing/) 10.7 中引入.
Dependency Scanning 使用[Dependency Scanning Docker 映像](https://gitlab.com/gitlab-org/security-products/dependency-scanning)对项目依赖项进行分析，并检查潜在的安全问题. 在非[Ultimate](https://about.gitlab.com/pricing/)许可证上，将跳过"自动依赖项扫描"阶段，并且需要[GitLab Runner](https://docs.gitlab.com/runner/) 11.5 或更高版本.
创建报告后，报告将作为工件上传，您可以稍后下载并签出. 合并请求小部件显示检测到的所有安全警告，
要了解有关" [依赖关系扫描"的](../../user/application_security/dependency_scanning/index.html)更多信息，请参阅文档.
## Auto License Compliance[](#auto-license-compliance-ultimate "Permalink")
在[GitLab Ultimate](https://about.gitlab.com/pricing/) 11.0 中引入.
许可证合规性使用[许可证合规性 Docker 映像](https://gitlab.com/gitlab-org/security-products/license-management)在项目依赖项中搜索其许可证. 除[Ultimate](https://about.gitlab.com/pricing/)以外的其他许可证将跳过"自动许可证合规性"阶段.
创建报告后，报告将作为工件上传，您可以稍后下载并签出. 合并请求显示所有检测到的许可证.
要了解有关[许可证合规性的](../../user/compliance/license_compliance/index.html)更多[信息](../../user/compliance/license_compliance/index.html) ，请参阅文档.
## Auto Container Scanning[](#auto-container-scanning-ultimate "Permalink")
在 GitLab 10.4 中引入.
Vulnerability Static Analysis for containers uses [Clair](https://github.com/quay/clair) to check for potential security issues on Docker images. The Auto Container Scanning stage is skipped on licenses other than [Ultimate](https://about.gitlab.com/pricing/).
创建报告后，报告将作为工件上传，您可以稍后下载并签出. 合并请求显示所有检测到的安全问题.
To learn more about [Container Scanning](../../user/application_security/container_scanning/index.html), see the documentation.
## Auto Review Apps[](#auto-review-apps "Permalink")
这是一个可选步骤，因为许多项目没有可用的 Kubernetes 集群. 如果不满足[要求](requirements.html) ，则将跳过该作业.
[Review App](../../ci/review_apps/index.html)是基于分支机构代码的临时应用程序环境，因此开发人员，设计人员，质量检查人员，产品经理和其他审阅者可以在审阅过程中实际查看代码更改并与之交互. 自动审核应用程序为每个分支创建一个审核应用程序.
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](https://gitlab.com/gitlab-org/charts/auto-deploy-app)图表来部署评论应用，您可以对其进行[自定义](customize.html#custom-helm-chart) . 该应用程序将部署到环境的[Kubernetes 命名空间](../../user/project/clusters/index.html#deployment-variables)中.
从 GitLab 11.4 开始，使用[本地 Tiller](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/22036) . 早期版本的 GitLab 在项目名称空间中安装了一个 Tiller.
**注意：**您的应用程序*不*应该（直接使用 Kubernetes）以外的操纵舵的. 这可能会导致 Helm 无法检测到更改而造成混乱，随后使用 Auto DevOps 进行的部署可能会撤消您的更改. 同样，如果您更改了某些内容并想通过再次部署来撤消它，Helm 可能不会在一开始就检测到任何更改，因此不会意识到它需要重新应用旧配置.
## Auto DAST[](#auto-dast-ultimate "Permalink")
在[GitLab Ultimate](https://about.gitlab.com/pricing/) 10.4 中引入.
动态应用程序安全测试（DAST）使用流行的开源工具[OWASP ZAProxy](https://github.com/zaproxy/zaproxy)分析当前代码并检查潜在的安全问题. 除[Ultimate](https://about.gitlab.com/pricing/)以外的其他许可证将跳过 Auto DAST 阶段.
* 在默认分支上，除非您[覆盖目标分支](#overriding-the-dast-target) ，否则 DAST 会扫描专门为此目的部署的应用程序. DAST 运行后，该应用将被删除.
* 在功能分支上，DAST 扫描[审阅应用程序](#auto-review-apps) .
DAST 扫描完成后，所有安全警告都会显示在" [安全仪表板"](../../user/application_security/security_dashboard/index.html)和"合并请求"小部件上.
To learn more about [Dynamic Application Security Testing](../../user/application_security/dast/index.html), see the documentation.
### Overriding the DAST target[](#overriding-the-dast-target "Permalink")
要使用自定义目标而不是自动部署的审阅应用程序，请将`DAST_WEBSITE`环境变量设置为 URL 以便 DAST 进行扫描.
**危险：**如果启用了[DAST Full Scan](../../user/application_security/dast/index.html#full-scan) ，则 GitLab 强烈建议**不要**将`DAST_WEBSITE`设置为任何暂存或生产环境. DAST 全面扫描会主动攻击目标，这可能会破坏您的应用程序并导致数据丢失或损坏.
### Disabling Auto DAST[](#disabling-auto-dast "Permalink")
您可以禁用 DAST：
* 通过将`DAST_DISABLED`环境变量设置为`"true"`在所有分支上.
* 通过将`DAST_DISABLED_FOR_DEFAULT_BRANCH`环境变量设置为`"true"`仅在默认分支上.
* 通过将环境变量`REVIEW_DISABLED`设置为`"true"`仅在要素分支上. 这也会禁用 Review App.
## Auto Browser Performance Testing[](#auto-browser-performance-testing-premium "Permalink")
在[GitLab Premium](https://about.gitlab.com/pricing/) 10.4 中引入.
自动[浏览器性能测试](../../user/project/merge_requests/browser_performance_testing.html)使用[Sitespeed.io 容器](https://hub.docker.com/r/sitespeedio/sitespeed.io/)测量网页的浏览器性能，创建包括每个页面的整体性能得分的 JSON 报告，并将报告作为工件上传. 默认情况下，它将测试"审阅"和"生产"环境的根页面. 如果要测试其他 URL，请将路径添加到根目录中名为`.gitlab-urls.txt`的文件中，每行一个文件. 例如：
```
/
/features
/direction
```
[合并请求小部件](../../user/project/merge_requests/browser_performance_testing.html)中还会[显示](../../user/project/merge_requests/browser_performance_testing.html)源分支与目标分支之间的任何浏览器性能差异.
## Auto Load Performance Testing[](#auto-load-performance-testing-premium "Permalink")
在[GitLab Premium](https://about.gitlab.com/pricing/) 13.2 中引入.
自动[负载性能测试](../../user/project/merge_requests/load_performance_testing.html)使用[k6 容器](https://hub.docker.com/r/loadimpact/k6/)测量应用程序的服务器性能，创建包含多个关键结果指标的 JSON 报告，并将报告作为工件上传.
需要一些初始设置. 需要编写针对您的特定应用的[k6](https://k6.io/)测试. 还需要配置测试，以便它可以通过环境变量获取环境的动态 URL.
[合并请求小部件](../../user/project/merge_requests/load_performance_testing.html)中还会[显示](../../user/project/merge_requests/load_performance_testing.html)源分支与目标分支之间的任何负载性能测试结果差异.
## Auto Deploy[](#auto-deploy "Permalink")
这是一个可选步骤，因为许多项目没有可用的 Kubernetes 集群. 如果不满足[要求](requirements.html) ，则跳过该作业.
将分支或合并请求合并到项目的默认分支（通常是`master` ）后，Auto Deploy 会将应用程序部署到 Kubernetes 集群中的`production`环境中，该环境具有基于项目名称和唯一项目 ID 的命名空间，例如`project-4321` .
默认情况下，"自动部署"不包括到暂存或 Canary 环境的部署，但是如果要启用这些任务，则" [Auto DevOps"模板](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)包含这些任务的作业定义.
您可以使用[环境变量](customize.html#environment-variables)来自动缩放 Pod 副本，并将自定义参数应用于 Auto DevOps `helm upgrade`命令. 这是[自定义 Auto Deploy Helm 图表](customize.html#custom-helm-chart)的简便方法.
Helm 使用[auto-deploy-app](https://gitlab.com/gitlab-org/charts/auto-deploy-app)图表将应用程序部署到环境的[Kubernetes 命名空间](../../user/project/clusters/index.html#deployment-variables)中.
从 GitLab 11.4 开始，将使用[本地 Tiller](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/22036) . 早期版本的 GitLab 在项目名称空间中安装了一个 Tiller.
**注意：**您的应用程序*不*应该（直接使用 Kubernetes）以外的操纵舵的. 这可能会导致 Helm 无法检测到更改而造成混乱，随后使用 Auto DevOps 进行的部署可能会撤消您的更改. 同样，如果您更改了某些内容并想通过再次部署来撤消它，Helm 可能不会在一开始就检测到任何更改，因此不会意识到它需要重新应用旧配置.
### GitLab deploy tokens[](#gitlab-deploy-tokens "Permalink")
在 GitLab 11.0 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/19507) .
启用 Auto DevOps 时，将为内部和私有项目创建[GitLab 部署令牌](../../user/project/deploy_tokens/index.html#gitlab-deploy-token) ，并保存 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+[](#kubernetes-116 "Permalink")
版本历史
* 在 GitLab 12.8 中[引入](https://gitlab.com/gitlab-org/charts/auto-deploy-app/-/merge_requests/51) .
* 在 GitLab 12.9 中[引入](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/merge_requests/49)了对部署支持 Kubernetes 1.16+的 PostgreSQL 版本的支持.
* 自 GitLab 13.0 起为新部署提供开箱即用的支持.
**弃用：**在[GitLab 13.0 中](https://gitlab.com/gitlab-org/charts/auto-deploy-app/-/issues/47) ， `deploymentApiVersion`设置的默认值已从`extensions/v1beta`更改为`apps/v1` .
在 Kubernetes 1.16 和更高版本中， [删除](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/)了许多[API](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/) ，包括在`extensions/v1beta1`版本中支持`Deployment` .
要在 Kubernetes 1.16+群集上使用 Auto Deploy：
1. 如果您是第一次在 GitLab 13.0 或更高版本上部署应用程序，则无需进行配置.
2. 在 GitLab 12.10 或更旧版本上，在[`.gitlab/auto-deploy-values.yaml`文件中](customize.html#customize-values-for-helm-chart)设置以下内容：
```
deploymentApiVersion: apps/v1
```
3. 如果您安装了集群内 PostgreSQL 数据库，并且`AUTO_DEVOPS_POSTGRES_CHANNEL`设置为`1` ，请按照[指南升级 PostgreSQL](upgrading_postgresql.html) .
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](upgrading_postgresql.html)的[指南来](upgrading_postgresql.html)备份和还原数据库（在 GitLab 13.0 上，需要附加变量来触发数据库删除）.
### Migrations[](#migrations "Permalink")
在 GitLab 11.4 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/21955)
您可以通过分别设置项目变量`DB_INITIALIZE`和`DB_MIGRATE`来配置 PostgreSQL 的数据库初始化和迁移，以使其在应用程序窗格中运行.
如果存在， `DB_INITIALIZE`作为 Shell 命令作为 Helm 安装后挂钩在外壳中运行. 由于某些应用程序如果没有成功的数据库初始化步骤就无法运行，因此 GitLab 部署的第一个发行版没有应用程序部署，而只有数据库初始化步骤. 数据库初始化完成后，GitLab 部署第二个版本，并且应用程序部署正常.
请注意，安装后挂钩意味着如果任何部署成功，则`DB_INITIALIZE`将不再处理`DB_INITIALIZE` .
如果存在， `DB_MIGRATE`作为 Shell 命令作为 Helm 预升级挂钩在 Shell 中运行.
例如，在用[Herokuish](https://github.com/gliderlabs/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[](#workers "Permalink")
某些 Web 应用程序必须为"工作流程"运行额外的部署. 例如，Rails 应用程序通常使用单独的工作进程来运行后台任务，例如发送电子邮件.
Auto Deploy 中使用的[默认 Helm 图表](https://gitlab.com/gitlab-org/charts/auto-deploy-app) [支持运行工作进程](https://gitlab.com/gitlab-org/charts/auto-deploy-app/-/merge_requests/9) .
要运行工作程序，必须确保工作程序可以响应标准的运行状况检查，该检查将在端口`5000`上期望成功的 HTTP 响应. 对于[Sidekiq](https://github.com/mperham/sidekiq) ，可以使用[`sidekiq_alive` gem](https://rubygems.org/gems/sidekiq_alive) .
要使用 Sidekiq，还必须确保您的部署可以访问 Redis 实例. Auto DevOps 不会为您部署此实例，因此您必须：
* 维护您自己的 Redis 实例.
* 设置 CI 变量`K8S_SECRET_REDIS_URL` ，它是该实例的 URL，以确保将其传递到您的部署中.
在将工作程序配置为对运行状况检查作出响应之后，为您的 Rails 应用程序运行 Sidekiq 工作程序. 您可以通过在[`.gitlab/auto-deploy-values.yaml`文件中](customize.html#customize-values-for-helm-chart)设置以下内容来启用工作[`.gitlab/auto-deploy-values.yaml`](customize.html#customize-values-for-helm-chart) ：
```
workers:
sidekiq:
replicaCount: 1
command:
- /bin/herokuish
- procfile
- exec
- sidekiq
preStopCommand:
- /bin/herokuish
- procfile
- exec
- sidekiqctl
- quiet
terminationGracePeriodSeconds: 60
```
### Network Policy[](#network-policy "Permalink")
在 GitLab 12.7 中[引入](https://gitlab.com/gitlab-org/charts/auto-deploy-app/-/merge_requests/30) .
默认情况下，所有 Kubernetes 容器都是[非隔离的](https://kubernetes.io/docs/concepts/services-networking/network-policies/#isolated-and-non-isolated-pods) ，并且接受来自任何来源的流量. 您可以使用[NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies/)限制与选定 Pod，名称空间和 Internet 之间的连接.
**注意：**您必须使用 Kubernetes 网络插件来实现对`NetworkPolicy`支持. Kubernetes（ `kubenet` ）的默认网络插件[未实现](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#kubenet) `kubenet`支持. 可以将[Cilium](https://cilium.io/)网络插件安装为[群集应用程序，](../../user/clusters/applications.html#install-cilium-using-gitlab-cicd)以支持网络策略.
您可以通过在`.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`文件中提供自定义[策略规范](https://kubernetes.io/docs/concepts/services-networking/network-policies/) ，例如：
```
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](../../user/clusters/applications.html#install-cilium-using-gitlab-cicd) .
### Web Application Firewall (ModSecurity) customization[](#web-application-firewall-modsecurity-customization "Permalink")
在 GitLab 12.8 中[引入](https://gitlab.com/gitlab-org/charts/auto-deploy-app/-/merge_requests/44) .
[安装](../../user/clusters/applications.html#web-application-firewall-modsecurity)了[ModSecurity 的](../../user/clusters/applications.html#web-application-firewall-modsecurity)群集可以在[Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)或部署基础上进行自定义.
要在 Auto Deploy 中启用 ModSecurity，必须在项目中使用以下属性创建`.gitlab/auto-deploy-values.yaml`文件.
| Attribute | Description | Default |
| --- | --- | --- |
| `enabled` | 启用 ModSecurity 的自定义配置，默认为" [核心规则集"](https://coreruleset.org/) | `false` |
| `secRuleEngine` | 配置[规则引擎](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#secruleengine) | `DetectionOnly` |
| `secRules` | 创建一个或多个其他[规则](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#SecRule) | `nil` |
在以下`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[](#running-commands-in-the-container "Permalink")
除非您的存储库包含[自定义 Dockerfile](#auto-build-using-a-dockerfile) ，否则默认情况下使用 Herokuish 使用[Auto Build 构建的](#auto-build)应用程序可能要求将命令包装如下：
```
/bin/herokuish procfile exec $COMMAND
```
您可能需要包装命令的一些原因：
* 使用`kubectl exec`附加.
* 使用 GitLab 的[Web 终端](../../ci/environments/index.html#web-terminals) .
例如，要从应用程序根目录启动 Rails 控制台，请运行：
```
/bin/herokuish procfile exec bin/rails c
```
## Auto Monitoring[](#auto-monitoring "Permalink")
部署应用程序后，"自动监视"可帮助您立即监视应用程序的服务器和响应指标. 自动监控使用[Prometheus](../../user/project/integrations/prometheus.html)直接从[Kubernetes](../../user/project/integrations/prometheus_library/kubernetes.html)检索系统指标，例如 CPU 和内存使用情况，以及从[NGINX 服务器](../../user/project/integrations/prometheus_library/nginx_ingress.html)检索响应指标，例如 HTTP 错误率，延迟和吞吐量.
指标包括：
* **响应指标：**延迟，吞吐量，错误率
* **系统指标：** CPU 利用率，内存利用率
安装 Prometheus 之后，GitLab 会为您提供一些初始警报：
* 入口状态码`500` > 0.1％
* NGINX 状态码`500` > 0.1％
要使用自动监视：
1. [Install and configure the Auto DevOps requirements](requirements.html).
2. 如果尚未[启用 Auto DevOps](index.html#enablingdisabling-auto-devops) ，请[启用它](index.html#enablingdisabling-auto-devops) .
3. 导航到您项目的 **CI / CD>管道** ，然后单击**运行管道** .
4. 管道成功完成后，打开已[部署环境](../../ci/environments/index.html#monitoring-environments)的[监视仪表板](../../ci/environments/index.html#monitoring-environments)以查看已部署应用程序的指标. 要查看整个 Kubernetes 集群的指标，请导航至 **操作>指标** .
[](img/auto_monitoring.png)
- GitLab Docs
- Installation
- Requirements
- GitLab cloud native Helm Chart
- Install GitLab with Docker
- Installation from source
- Install GitLab on Microsoft Azure
- Installing GitLab on Google Cloud Platform
- Installing GitLab on Amazon Web Services (AWS)
- Analytics
- Code Review Analytics
- Productivity Analytics
- Value Stream Analytics
- Kubernetes clusters
- Adding and removing Kubernetes clusters
- Adding EKS clusters
- Adding GKE clusters
- Group-level Kubernetes clusters
- Instance-level Kubernetes clusters
- Canary Deployments
- Cluster Environments
- Deploy Boards
- GitLab Managed Apps
- Crossplane configuration
- Cluster management project (alpha)
- Kubernetes Logs
- Runbooks
- Serverless
- Deploying AWS Lambda function using GitLab CI/CD
- Securing your deployed applications
- Groups
- Contribution Analytics
- Custom group-level project templates
- Epics
- Manage epics
- Group Import/Export
- Insights
- Issues Analytics
- Iterations
- Public access
- SAML SSO for GitLab.com groups
- SCIM provisioning using SAML SSO for GitLab.com groups
- Subgroups
- Roadmap
- Projects
- GitLab Secure
- Security Configuration
- Container Scanning
- Dependency Scanning
- Dependency List
- Static Application Security Testing (SAST)
- Secret Detection
- Dynamic Application Security Testing (DAST)
- GitLab Security Dashboard
- Offline environments
- Standalone Vulnerability pages
- Security scanner integration
- Badges
- Bulk editing issues and merge requests at the project level
- Code Owners
- Compliance
- License Compliance
- Compliance Dashboard
- Create a project
- Description templates
- Deploy Keys
- Deploy Tokens
- File finder
- Project integrations
- Integrations
- Atlassian Bamboo CI Service
- Bugzilla Service
- Custom Issue Tracker service
- Discord Notifications service
- Enabling emails on push
- GitHub project integration
- Hangouts Chat service
- Atlassian HipChat
- Irker IRC Gateway
- GitLab Jira integration
- Mattermost Notifications Service
- Mattermost slash commands
- Microsoft Teams service
- Mock CI Service
- Prometheus integration
- Redmine Service
- Slack Notifications Service
- Slack slash commands
- GitLab Slack application
- Webhooks
- YouTrack Service
- Insights
- Issues
- Crosslinking Issues
- Design Management
- Confidential issues
- Due dates
- Issue Boards
- Issue Data and Actions
- Labels
- Managing issues
- Milestones
- Multiple Assignees for Issues
- Related issues
- Service Desk
- Sorting and ordering issue lists
- Issue weight
- Associate a Zoom meeting with an issue
- Merge requests
- Allow collaboration on merge requests across forks
- Merge Request Approvals
- Browser Performance Testing
- How to create a merge request
- Cherry-pick changes
- Code Quality
- Load Performance Testing
- Merge Request dependencies
- Fast-forward merge requests
- Merge when pipeline succeeds
- Merge request conflict resolution
- Reverting changes
- Reviewing and managing merge requests
- Squash and merge
- Merge requests versions
- Draft merge requests
- Members of a project
- Migrating projects to a GitLab instance
- Import your project from Bitbucket Cloud to GitLab
- Import your project from Bitbucket Server to GitLab
- Migrating from ClearCase
- Migrating from CVS
- Import your project from FogBugz to GitLab
- Gemnasium
- Import your project from GitHub to GitLab
- Project importing from GitLab.com to your private GitLab instance
- Import your project from Gitea to GitLab
- Import your Jira project issues to GitLab
- Migrating from Perforce Helix
- Import Phabricator tasks into a GitLab project
- Import multiple repositories by uploading a manifest file
- Import project from repo by URL
- Migrating from SVN to GitLab
- Migrating from TFVC to Git
- Push Options
- Releases
- Repository
- Branches
- Git Attributes
- File Locking
- Git file blame
- Git file history
- Repository mirroring
- Protected branches
- Protected tags
- Push Rules
- Reduce repository size
- Signing commits with GPG
- Syntax Highlighting
- GitLab Web Editor
- Web IDE
- Requirements Management
- Project settings
- Project import/export
- Project access tokens (Alpha)
- Share Projects with other Groups
- Snippets
- Static Site Editor
- Wiki
- Project operations
- Monitor metrics for your CI/CD environment
- Set up alerts for Prometheus metrics
- Embedding metric charts within GitLab-flavored Markdown
- Embedding Grafana charts
- Using the Metrics Dashboard
- Dashboard YAML properties
- Metrics dashboard settings
- Panel types for dashboards
- Using Variables
- Templating variables for metrics dashboards
- Prometheus Metrics library
- Monitoring AWS Resources
- Monitoring HAProxy
- Monitoring Kubernetes
- Monitoring NGINX
- Monitoring NGINX Ingress Controller
- Monitoring NGINX Ingress Controller with VTS metrics
- Alert Management
- Error Tracking
- Tracing
- Incident Management
- GitLab Status Page
- Feature Flags
- GitLab CI/CD
- GitLab CI/CD pipeline configuration reference
- GitLab CI/CD include examples
- Introduction to CI/CD with GitLab
- Getting started with GitLab CI/CD
- How to enable or disable GitLab CI/CD
- Using SSH keys with GitLab CI/CD
- Migrating from CircleCI
- Migrating from Jenkins
- Auto DevOps
- Getting started with Auto DevOps
- Requirements for Auto DevOps
- Customizing Auto DevOps
- Stages of Auto DevOps
- Upgrading PostgreSQL for Auto DevOps
- Cache dependencies in GitLab CI/CD
- GitLab ChatOps
- Cloud deployment
- Docker integration
- Building Docker images with GitLab CI/CD
- Using Docker images
- Building images with kaniko and GitLab CI/CD
- GitLab CI/CD environment variables
- Predefined environment variables reference
- Where variables can be used
- Deprecated GitLab CI/CD variables
- Environments and deployments
- Protected Environments
- GitLab CI/CD Examples
- Test a Clojure application with GitLab CI/CD
- Using Dpl as deployment tool
- Testing a Phoenix application with GitLab CI/CD
- End-to-end testing with GitLab CI/CD and WebdriverIO
- DevOps and Game Dev with GitLab CI/CD
- Deploy a Spring Boot application to Cloud Foundry with GitLab CI/CD
- How to deploy Maven projects to Artifactory with GitLab CI/CD
- Testing PHP projects
- Running Composer and NPM scripts with deployment via SCP in GitLab CI/CD
- Test and deploy Laravel applications with GitLab CI/CD and Envoy
- Test and deploy a Python application with GitLab CI/CD
- Test and deploy a Ruby application with GitLab CI/CD
- Test and deploy a Scala application to Heroku
- GitLab CI/CD for external repositories
- Using GitLab CI/CD with a Bitbucket Cloud repository
- Using GitLab CI/CD with a GitHub repository
- GitLab Pages
- GitLab Pages
- GitLab Pages domain names, URLs, and baseurls
- Create a GitLab Pages website from scratch
- Custom domains and SSL/TLS Certificates
- GitLab Pages integration with Let's Encrypt
- GitLab Pages Access Control
- Exploring GitLab Pages
- Incremental Rollouts with GitLab CI/CD
- Interactive Web Terminals
- Optimizing GitLab for large repositories
- Metrics Reports
- CI/CD pipelines
- Pipeline Architecture
- Directed Acyclic Graph
- Multi-project pipelines
- Parent-child pipelines
- Pipelines for Merge Requests
- Pipelines for Merged Results
- Merge Trains
- Job artifacts
- Pipeline schedules
- Pipeline settings
- Triggering pipelines through the API
- Review Apps
- Configuring GitLab Runners
- GitLab CI services examples
- Using MySQL
- Using PostgreSQL
- Using Redis
- Troubleshooting CI/CD
- GitLab Package Registry
- GitLab Container Registry
- Dependency Proxy
- GitLab Composer Repository
- GitLab Conan Repository
- GitLab Maven Repository
- GitLab NPM Registry
- GitLab NuGet Repository
- GitLab PyPi Repository
- API Docs
- API resources
- .gitignore API
- GitLab CI YMLs API
- Group and project access requests API
- Appearance API
- Applications API
- Audit Events API
- Avatar API
- Award Emoji API
- Project badges API
- Group badges API
- Branches API
- Broadcast Messages API
- Project clusters API
- Group clusters API
- Instance clusters API
- Commits API
- Container Registry API
- Custom Attributes API
- Dashboard annotations API
- Dependencies API
- Deploy Keys API
- Deployments API
- Discussions API
- Dockerfiles API
- Environments API
- Epics API
- Events
- Feature Flags API
- Feature flag user lists API
- Freeze Periods API
- Geo Nodes API
- Group Activity Analytics API
- Groups API
- Import API
- Issue Boards API
- Group Issue Boards API
- Issues API
- Epic Issues API
- Issues Statistics API
- Jobs API
- Keys API
- Labels API
- Group Labels API
- License
- Licenses API
- Issue links API
- Epic Links API
- Managed Licenses API
- Markdown API
- Group and project members API
- Merge request approvals API
- Merge requests API
- Project milestones API
- Group milestones API
- Namespaces API
- Notes API
- Notification settings API
- Packages API
- Pages domains API
- Pipeline schedules API
- Pipeline triggers API
- Pipelines API
- Project Aliases API
- Project import/export API
- Project repository storage moves API
- Project statistics API
- Project templates API
- Projects API
- Protected branches API
- Protected tags API
- Releases API
- Release links API
- Repositories API
- Repository files API
- Repository submodules API
- Resource label events API
- Resource milestone events API
- Resource weight events API
- Runners API
- SCIM API
- Search API
- Services API
- Application settings API
- Sidekiq Metrics API
- Snippets API
- Project snippets
- Application statistics API
- Suggest Changes API
- System hooks API
- Tags API
- Todos API
- Users API
- Project-level Variables API
- Group-level Variables API
- Version API
- Vulnerabilities API
- Vulnerability Findings API
- Wikis API
- GraphQL API
- Getting started with GitLab GraphQL API
- GraphQL API Resources
- API V3 to API V4
- Validate the .gitlab-ci.yml (API)
- User Docs
- Abuse reports
- User account
- Active sessions
- Deleting a User account
- Permissions
- Personal access tokens
- Profile preferences
- Threads
- GitLab and SSH keys
- GitLab integrations
- Git
- GitLab.com settings
- Infrastructure as code with Terraform and GitLab
- GitLab keyboard shortcuts
- GitLab Markdown
- AsciiDoc
- GitLab Notification Emails
- GitLab Quick Actions
- Autocomplete characters
- Reserved project and group names
- Search through GitLab
- Advanced Global Search
- Advanced Syntax Search
- Time Tracking
- GitLab To-Do List
- Administrator Docs
- Reference architectures
- Reference architecture: up to 1,000 users
- Reference architecture: up to 2,000 users
- Reference architecture: up to 3,000 users
- Reference architecture: up to 5,000 users
- Reference architecture: up to 10,000 users
- Reference architecture: up to 25,000 users
- Reference architecture: up to 50,000 users
- Troubleshooting a reference architecture set up
- Working with the bundled Consul service
- Configuring PostgreSQL for scaling
- Configuring GitLab application (Rails)
- Load Balancer for multi-node GitLab
- Configuring a Monitoring node for Scaling and High Availability
- NFS
- Working with the bundled PgBouncer service
- Configuring Redis for scaling
- Configuring Sidekiq
- Admin Area settings
- Continuous Integration and Deployment Admin settings
- Custom instance-level project templates
- Diff limits administration
- Enable and disable GitLab features deployed behind feature flags
- Geo nodes Admin Area
- GitLab Pages administration
- Health Check
- Job logs
- Labels administration
- Log system
- PlantUML & GitLab
- Repository checks
- Repository storage paths
- Repository storage types
- Account and limit settings
- Service templates
- System hooks
- Changing your time zone
- Uploads administration
- Abuse reports
- Activating and deactivating users
- Audit Events
- Blocking and unblocking users
- Broadcast Messages
- Elasticsearch integration
- Gitaly
- Gitaly Cluster
- Gitaly reference
- Monitoring GitLab
- Monitoring GitLab with Prometheus
- Performance Bar
- Usage statistics
- Object Storage
- Performing Operations in GitLab
- Cleaning up stale Redis sessions
- Fast lookup of authorized SSH keys in the database
- Filesystem Performance Benchmarking
- Moving repositories managed by GitLab
- Run multiple Sidekiq processes
- Sidekiq MemoryKiller
- Switching to Puma
- Understanding Unicorn and unicorn-worker-killer
- User lookup via OpenSSH's AuthorizedPrincipalsCommand
- GitLab Package Registry administration
- GitLab Container Registry administration
- Replication (Geo)
- Geo database replication
- Geo with external PostgreSQL instances
- Geo configuration
- Using a Geo Server
- Updating the Geo nodes
- Geo with Object storage
- Docker Registry for a secondary node
- Geo for multiple nodes
- Geo security review (Q&A)
- Location-aware Git remote URL with AWS Route53
- Tuning Geo
- Removing secondary Geo nodes
- Geo data types support
- Geo Frequently Asked Questions
- Geo Troubleshooting
- Geo validation tests
- Disaster Recovery (Geo)
- Disaster recovery for planned failover
- Bring a demoted primary node back online
- Automatic background verification
- Rake tasks
- Back up and restore GitLab
- Clean up
- Namespaces
- Maintenance Rake tasks
- Geo Rake Tasks
- GitHub import
- Import bare repositories
- Integrity check Rake task
- LDAP Rake tasks
- Listing repository directories
- Praefect Rake tasks
- Project import/export administration
- Repository storage Rake tasks
- Generate sample Prometheus data
- Uploads migrate Rake tasks
- Uploads sanitize Rake tasks
- User management
- Webhooks administration
- X.509 signatures
- Server hooks
- Static objects external storage
- Updating GitLab
- GitLab release and maintenance policy
- Security
- Password Storage
- Custom password length limits
- Restrict allowed SSH key technologies and minimum length
- Rate limits
- Webhooks and insecure internal web services
- Information exclusivity
- How to reset your root password
- How to unlock a locked user from the command line
- User File Uploads
- How we manage the TLS protocol CRIME vulnerability
- User email confirmation at sign-up
- Security of running jobs
- Proxying assets
- CI/CD Environment Variables
- Contributor and Development Docs
- Contribute to GitLab
- Community members & roles
- Implement design & UI elements
- Issues workflow
- Merge requests workflow
- Code Review Guidelines
- Style guides
- GitLab Architecture Overview
- CI/CD development documentation
- Database guides
- Database Review Guidelines
- Database Review Guidelines
- Migration Style Guide
- What requires downtime?
- Understanding EXPLAIN plans
- Rake tasks for developers
- Mass inserting Rails models
- GitLab Documentation guidelines
- Documentation Style Guide
- Documentation structure and template
- Documentation process
- Documentation site architecture
- Global navigation
- GitLab Docs monthly release process
- Telemetry Guide
- Usage Ping Guide
- Snowplow Guide
- Experiment Guide
- Feature flags in development of GitLab
- Feature flags process
- Developing with feature flags
- Feature flag controls
- Document features deployed behind feature flags
- Frontend Development Guidelines
- Accessibility & Readability
- Ajax
- Architecture
- Axios
- Design Patterns
- Frontend Development Process
- DropLab
- Emojis
- Filter
- Frontend FAQ
- GraphQL
- Icons and SVG Illustrations
- InputSetter
- Performance
- Principles
- Security
- Tooling
- Vuex
- Vue
- Geo (development)
- Geo self-service framework (alpha)
- Gitaly developers guide
- GitLab development style guides
- API style guide
- Go standards and style guidelines
- GraphQL API style guide
- Guidelines for shell commands in the GitLab codebase
- HTML style guide
- JavaScript style guide
- Migration Style Guide
- Newlines style guide
- Python Development Guidelines
- SCSS style guide
- Shell scripting standards and style guidelines
- Sidekiq debugging
- Sidekiq Style Guide
- SQL Query Guidelines
- Vue.js style guide
- Instrumenting Ruby code
- Testing standards and style guidelines
- Flaky tests
- Frontend testing standards and style guidelines
- GitLab tests in the Continuous Integration (CI) context
- Review Apps
- Smoke Tests
- Testing best practices
- Testing levels
- Testing Rails migrations at GitLab
- Testing Rake tasks
- End-to-end Testing
- Beginner's guide to writing end-to-end tests
- End-to-end testing Best Practices
- Dynamic Element Validation
- Flows in GitLab QA
- Page objects in GitLab QA
- Resource class in GitLab QA
- Style guide for writing end-to-end tests
- Testing with feature flags
- Translate GitLab to your language
- Internationalization for GitLab
- Translating GitLab
- Proofread Translations
- Merging translations from CrowdIn
- Value Stream Analytics development guide
- GitLab subscription
- Activate GitLab EE with a license