# 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