Auto DevOps · Gitlab 中文文檔

# Auto DevOps > 原文：[https://docs.gitlab.com/ee/topics/autodevops/](https://docs.gitlab.com/ee/topics/autodevops/) * [Overview](#overview) * [Enabled by default](#enabled-by-default) * [Quick start](#quick-start) * [Comparison to application platforms and PaaS](#comparison-to-application-platforms-and-paas) * [Features](#features) * [Auto DevOps base domain](#auto-devops-base-domain) * [Enabling/Disabling Auto DevOps](#enablingdisabling-auto-devops) * [At the project level](#at-the-project-level) * [At the group level](#at-the-group-level) * [At the instance level (Administrators only)](#at-the-instance-level-administrators-only) * [Deployment strategy](#deployment-strategy) * [Using multiple Kubernetes clusters](#using-multiple-kubernetes-clusters-premium) * [Limitations](#limitations) * [Private registry support](#private-registry-support) * [Installing Helm behind a proxy](#installing-helm-behind-a-proxy) * [Troubleshooting](#troubleshooting) * [Unable to select a buildpack](#unable-to-select-a-buildpack) * [Pipeline that extends Auto DevOps with only / except fails](#pipeline-that-extends-auto-devops-with-only--except-fails) * [Failure to create a Kubernetes namespace](#failure-to-create-a-kubernetes-namespace) * [Detected an existing PostgreSQL database](#detected-an-existing-postgresql-database) * [Development guides](#development-guides) # Auto DevOps[](#auto-devops "Permalink") 版本歷史 * 在 GitLab 10.0 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/37115) . * 通常在 GitLab 11.0 上可用. Auto DevOps provides pre-defined CI/CD configuration allowing you to automatically detect, build, test, deploy, and monitor your applications. Leveraging CI/CD best practices and tools, Auto DevOps aims to simplify the setup and execution of a mature and modern software development lifecycle. ## Overview[](#overview "Permalink") 您可以花費大量精力來設置構建，部署和監視項目所需的工作流和流程. 當您的公司要維護數百個（甚至數千個）項目時，情況會變得更糟. 隨著新項目的不斷啟動，整個軟件開發過程變得難以管理. Auto DevOps 通過自動檢測以最小的配置測試，構建，打包，部署和監視每個項目所需的所有依賴關系和語言技術，為您提供了無縫的軟件開發過程. 自動化可確保項目之間的一致性，流程的無縫管理以及更快地創建新項目：推送代碼，而 GitLab 則完成其余工作，從而提高了生產率和效率. 有關 Auto DevOps 的介紹， [請在 GitLab 11.0 中](https://youtu.be/0Tc0YYBxqi4)觀看[AutoDevOps](https://youtu.be/0Tc0YYBxqi4) . 有關要求，請參閱[Auto DevOps 要求以](requirements.html)獲取更多信息. ## Enabled by default[](#enabled-by-default "Permalink") 在 GitLab 11.3 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/41729) . 默認情況下，所有項目都會啟用 Auto DevOps，并嘗試在每個項目的所有管道中運行. 實例管理員可以在[Auto DevOps 設置中](../../user/admin_area/settings/continuous_integration.html#auto-devops-core-only)啟用或禁用此默認[設置](../../user/admin_area/settings/continuous_integration.html#auto-devops-core-only) . 如果尚未為項目顯式啟用，Auto DevOps 會在各個項目的第一個管道故障時自動將其禁用. 從[GitLab 12.7 開始](https://gitlab.com/gitlab-org/gitlab/-/issues/26655) ，僅當存在[`Dockerfile`或匹配的 buildpack](stages.html#auto-build)時，Auto DevOps 才會在管道上自動運行. 如果項目中存在[CI / CD 配置文件](../../ci/yaml/README.html) ，則無論是否啟用了 Auto DevOps，它都將繼續使用. ## Quick start[](#quick-start "Permalink") 如果您使用的是 GitLab.com，請參閱[快速入門指南](quick_start_guide.html) ，以使用 GitLab.com 和 Google Kubernetes Engine（GKE）上的 Kubernetes 集群設置 Auto DevOps. 如果使用 GitLab 的自我管理實例，則必須先配置[Google OAuth2 OmniAuth Provider，](../../integration/google.html)然后才能在 GKE 上配置集群. 配置提供程序后，您可以按照[快速入門指南中](quick_start_guide.html)的步驟進行入門. In [GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/208132) and later, it is possible to leverage Auto DevOps to deploy to [AWS ECS](requirements.html#auto-devops-requirements-for-amazon-ecs). ## Comparison to application platforms and PaaS[](#comparison-to-application-platforms-and-paas "Permalink") Auto DevOps provides features often included in an application platform or a Platform as a Service (PaaS). It takes inspiration from the innovative work done by [Heroku](https://www.heroku.com/) and goes beyond it in multiple ways: * Auto DevOps 可與任何 Kubernetes 集群一起使用; 您不僅限于在 GitLab 的基礎架構上運行. （請注意，許多功能在沒有 Kubernetes 的情況下也可以使用）. * 沒有額外的費用（基礎設施費用沒有加價），您可以在任何公共云（例如[Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) ）上使用托管的 Kubernetes 群集或容器即服務. * Auto DevOps 具有更多功能，包括安全測試，性能測試和代碼質量測試. * Auto DevOps 提供增量的畢業路徑. 如果需要高級自定義，則可以開始修改模板，而無需在完全不同的平臺上重新開始. 查看[定制](customize.html)文檔以獲取更多信息. ## Features[](#features "Permalink") Auto DevOps 由一組[階段組成](stages.html) ，以簡單，自動的方式為您的項目帶來了這些最佳實踐： 1. [Auto Build](stages.html#auto-build) 2. [Auto Test](stages.html#auto-test) 3. [Auto Code Quality](stages.html#auto-code-quality-starter) 4. [Auto SAST (Static Application Security Testing)](stages.html#auto-sast-ultimate) 5. [Auto Secret Detection](stages.html#auto-secret-detection-ultimate) 6. [Auto Dependency Scanning](stages.html#auto-dependency-scanning-ultimate) 7. [Auto License Compliance](stages.html#auto-license-compliance-ultimate) 8. [Auto Container Scanning](stages.html#auto-container-scanning-ultimate) 9. [Auto Review Apps](stages.html#auto-review-apps) 10. [Auto DAST (Dynamic Application Security Testing)](stages.html#auto-dast-ultimate) 11. [Auto Deploy](stages.html#auto-deploy) 12. [Auto Browser Performance Testing](stages.html#auto-browser-performance-testing-premium) 13. [Auto Monitoring](stages.html#auto-monitoring) 由于 Auto DevOps 依賴于許多不同的組件，因此您應該具有以下基本知識： * [Kubernetes](https://kubernetes.io/docs/home/) * [Helm](https://helm.sh/docs/) * [Docker](https://s0docs0docker0com.icopy.site) * [GitLab Runner](https://docs.gitlab.com/runner/) * [Prometheus](https://s0prometheus0io.icopy.site/docs/introduction/overview/) Auto DevOps 為所有階段提供了出色的默認設置. 但是，您可以[根據](customize.html)需要[自定義](customize.html)幾乎所有內容. 有關創建 Auto DevOps 的概述，請閱讀[本博客文章中的](https://about.gitlab.com/blog/2017/06/29/whats-next-for-gitlab-ci/)更多[信息](https://about.gitlab.com/blog/2017/06/29/whats-next-for-gitlab-ci/) . **注意** Kubernetes 集群可以[在沒有](../../user/project/clusters/index.html) Auto DevOps 的[情況下使用](../../user/project/clusters/index.html) . ## Auto DevOps base domain[](#auto-devops-base-domain "Permalink") 必須使用 Auto DevOps 基本域才能使用[Auto Review Apps](stages.html#auto-review-apps) ， [Auto Deploy](stages.html#auto-deploy)和[Auto Monitoring](stages.html#auto-monitoring) . 您可以在以下任意位置定義基本域： * 在集群的設置下（對于實例， [項目](../../user/project/clusters/index.html#base-domain)還是[組）](../../user/group/clusters/index.html#base-domain) * 或在項目級別作為變量： `KUBE_INGRESS_BASE_DOMAIN` * 或在組級別作為變量： `KUBE_INGRESS_BASE_DOMAIN` * 或作為實例范圍的后備 **持續集成和交付**部分下的**管理區域>設置** 基本域變量`KUBE_INGRESS_BASE_DOMAIN`與其他環境[變量](../../ci/variables/README.html#priority-of-environment-variables)遵循相同的優先級順序. 如果未設置 CI / CD 變量，并且群集設置為空，則在設置實例范圍的**Auto DevOps 域**設置時將使用該設置. **提示：**如果您將[GitLab 托管應用程序用于 Ingress](../../user/clusters/applications.html#ingress) ，則應自動為您配置 URL 端點. 您所要做的就是將其值用于`KUBE_INGRESS_BASE_DOMAIN`變量.**注：** `AUTO_DEVOPS_DOMAIN`被[棄用 GitLab 11.8](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/52363) ，取而代之的`KUBE_INGRESS_BASE_DOMAIN` ，并在除去[GitLab 12.0](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/56959) . Auto DevOps 需要與基礎域匹配的通配符 DNS A 記錄. 對于`example.com`的基本域，您需要一個 DNS 條目，例如： ``` *.example.com 3600 A 1.2.3.4 ``` 在這種情況下，已部署的應用程序是從`example.com` ，而`1.2.3.4`是負載均衡器的 IP 地址. 通常為 NGINX（ [請參閱要求](#requirements) ）. 設置 DNS 記錄不在本文檔的討論范圍內. 請與您的 DNS 提供商聯系以獲取信息. 另外，您可以使用免費的公共服務，例如[nip.io](https://nip.io) ，無需任何配置即可提供自動通配符 DNS. 對于[nip.io](https://nip.io) ，將 Auto DevOps 基本域設置為`1.2.3.4.nip.io` 完成設置后，所有請求都將到達負載均衡器，該負載均衡器會將請求路由到運行您的應用程序的 Kubernetes Pod. ## Enabling/Disabling Auto DevOps[](#enablingdisabling-auto-devops "Permalink") 首次使用 Auto DevOps 時，請查看[要求，](#requirements)以確保可以充分利用 Auto DevOps 的所有必需組件. 初學者應遵循[快速入門指南](quick_start_guide.html) . GitLab.com 用戶只能在項目級別啟用或禁用 Auto DevOps. 自我管理的用戶可以在項目，組或實例級別啟用或禁用 Auto DevOps. ### At the project level[](#at-the-project-level "Permalink") 如果啟用，請檢查您的項目是否沒有`.gitlab-ci.yml` ，或者如果存在，請將其刪除. 1. 轉到項目的 **設置> CI / CD>自動 DevOps** . 2. 選中**默認為 Auto DevOps 管道**復選框以啟用它. 3. （可選，但建議使用）啟用后，您可以在 Auto DevOps 用于[部署應用程序](stages.html#auto-deploy)的[基本域中](#auto-devops-base-domain)添加，并選擇[部署策略](#deployment-strategy) . 4. 單擊**保存更改**以使更改生效. 啟用該功能后，將在默認分支上觸發 Auto DevOps 管道. ### At the group level[](#at-the-group-level "Permalink") 在 GitLab 11.10 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/52447) . 僅管理員和組所有者可以在組級別啟用或禁用自動 DevOps. 在組級別啟用或禁用 Auto DevOps 時，除非在子組或項目上專門啟用或禁用了 Auto DevOps，否則組配置將隱式用于該組內的子組和項目. 要在組級別啟用或禁用自動 DevOps： 1. 前往您小組的 **設置> CI / CD>自動 DevOps**頁面. 2. 選中**默認為 Auto DevOps 管道**復選框以啟用它. 3. 單擊**保存更改**以使更改生效. ### At the instance level (Administrators only)[](#at-the-instance-level-administrators-only "Permalink") 即使在實例級別被禁用，組所有者和項目維護者仍可以分別在組和項目級別啟用 Auto DevOps. 1. 去 **管理區域>設置>持續集成和部署** . 2. **為所有項目**選擇" **默認為自動 DevOps 管道"**以啟用它. 3. （可選）您可以設置 Auto DevOps [基本域](#auto-devops-base-domain) ，以供 Auto Deploy 和 Auto Review Apps 使用. 4. 單擊**保存更改**以使更改生效. ### Deployment strategy[](#deployment-strategy "Permalink") 在 GitLab 11.0 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/38542) . 您可以轉到項目的目錄，更改 Auto DevOps 使用的部署策略. **設置> CI / CD>自動 DevOps** . 提供以下選項： * **持續部署到生產中** ：啟用將`master`分支直接部署到生產中的[自動部署](stages.html#auto-deploy) . * **使用定時增量部署連續部署到生產中** ：將[`INCREMENTAL_ROLLOUT_MODE`](customize.html#timed-incremental-rollout-to-production-premium)變量設置為`timed` . 生產部署在每次部署增量之間有 5 分鐘的延遲執行. * **自動部署到登臺，手動部署到生產** ：將[`STAGING_ENABLED`](customize.html#deploy-policy-for-staging-and-production-environments)和[`INCREMENTAL_ROLLOUT_MODE`](customize.html#incremental-rollout-to-production-premium)變量設置為`1`并`manual` . 這表示： * `master`分支直接部署到登臺. * 提供了手動操作以逐步推廣到生產中. **提示：**使用[藍綠色部署](../../ci/environments/incremental_rollouts.html#blue-green-deployment)技術可最大程度地減少停機時間和風險. ## Using multiple Kubernetes clusters[](#using-multiple-kubernetes-clusters-premium "Permalink") 使用 Auto DevOps 時，由于[它們之間存在](../../user/project/clusters/index.html#multiple-kubernetes-clusters-premium) 1：1 連接，因此可以將不同的環境部署到不同的 Kubernetes 集群. Auto DevOps 使用的" [部署作業"模板](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-ci.yml)當前定義了 3 個環境名稱： * `review/` （從`review/`開始的所有環境`review/` ） * `staging` * `production` 這些環境使用[Auto Deploy](stages.html#auto-deploy)與作業綁定，因此，除了環境范圍外，它們必須具有不同的部署域. 您必須[根據環境](../../ci/variables/README.html#limit-the-environment-scopes-of-environment-variables)為上述每個項定義一個單獨的`KUBE_INGRESS_BASE_DOMAIN`變量. 下表是如何配置三個不同群集的示例： | 集群名稱 | 集群環境范圍 | `KUBE_INGRESS_BASE_DOMAIN`變量值 | 可變環境范圍 | Notes | | --- | --- | --- | --- | --- | | review | `review/*` | `review.example.com` | `review/*` | 運行所有[Review Apps](../../ci/review_apps/index.html)的評論集群. `*`是一個通配符，每個環境名稱都以`review/`開頭使用. | | staging | `staging` | `staging.example.com` | `staging` | （可選）運行臨時環境的部署的臨時集群. 您必須先[啟用它](customize.html#deploy-policy-for-staging-and-production-environments) . | | production | `production` | `example.com` | `production` | 運行生產環境部署的生產集群. 您可以使用[增量卷展欄](customize.html#incremental-rollout-to-production-premium) . | 為每個環境添加不同的集群： 1. 導航到您項目的 **運營> Kubernetes** . 2. 如上表所述，使用各自的環境范圍創建 Kubernetes 集群. 3. 創建集群后，導航至每個集群并安裝 Helm Tiller 和 Ingress. 等待分配入口 IP 地址. 4. 確保已使用指定的 Auto DevOps 域[配置 DNS](#auto-devops-base-domain) . 5. 導航到每個集群的頁面，方法是 **操作> Kubernetes** ，然后根據其入口 IP 地址添加域. 完成配置后，您可以通過創建合并請求并驗證您的應用程序是否已作為具有 Review `review/*`環境范圍的 Kubernetes 集群中的 Review App 部署來測試設置. 同樣，您可以檢查其他環境. ## Limitations[](#limitations "Permalink") 以下限制適用. ### Private registry support[](#private-registry-support "Permalink") 沒有記錄的將私有容器注冊表與 Auto DevOps 結合使用的方式. 我們強烈建議將 GitLab 容器注冊表與 Auto DevOps 結合使用，以簡化配置并防止任何不可預見的問題. ### Installing Helm behind a proxy[](#installing-helm-behind-a-proxy "Permalink") 當在代理后面時，GitLab 不支持將[Helm 作為 GitLab 管理的應用程序](../../user/clusters/applications.html#helm)安裝. 想要這樣做的用戶必須在運行時將其代理設置注入到安裝 Pod 中，例如使用[`PodPreset`](https://kubernetes.io/docs/concepts/workloads/pods/podpreset/) ： ``` apiVersion: settings.k8s.io/v1alpha1 kind: PodPreset metadata: name: gitlab-managed-apps-default-proxy namespace: gitlab-managed-apps spec: env: - name: http_proxy value: "PUT_YOUR_HTTP_PROXY_HERE" - name: https_proxy value: "PUT_YOUR_HTTPS_PROXY_HERE" ``` ## Troubleshooting[](#troubleshooting "Permalink") ### Unable to select a buildpack[](#unable-to-select-a-buildpack "Permalink") 自動構建和自動測試可能無法檢測到您的語言或框架，并出現以下錯誤： ``` Step 5/11 : RUN /bin/herokuish buildpack build ---> Running in eb468cd46085 -----> Unable to select a buildpack The command '/bin/sh -c /bin/herokuish buildpack build' returned a non-zero code: 1 ``` 以下是可能的原因： * 您的應用程序可能缺少 buildpack 尋找的關鍵文件. Ruby 應用程序需要正確檢測`Gemfile` ，即使編寫不帶`Gemfile`的 Ruby 應用程序也是`Gemfile` . * 您的應用程序可能不存在 buildpack. 嘗試指定[自定義 buildpack](customize.html#custom-buildpacks) . ### Pipeline that extends Auto DevOps with only / except fails[](#pipeline-that-extends-auto-devops-with-only--except-fails "Permalink") 如果您的管道失敗并顯示以下消息： ``` Found errors in your .gitlab-ci.yml: jobs:test config key may not be used with `rules`: only ``` 當包含作業的規則配置已被`only`或`except`語法覆蓋時，將出現此錯誤. 要解決此問題，您必須： * 將您的`only/except`語法轉換為規則. * （臨時）將模板固定到[基于 GitLab 12.10 的模板](https://gitlab.com/gitlab-org/auto-devops-v12-10) . ### Failure to create a Kubernetes namespace[](#failure-to-create-a-kubernetes-namespace "Permalink") 如果 GitLab 無法為您的項目創建 Kubernetes 命名空間和服務帳戶，則 Auto Deploy 將失敗. 有關調試此問題的幫助，請參閱[對失敗的部署作業進行故障排除](../../user/project/clusters/index.html#troubleshooting) . ### Detected an existing PostgreSQL database[](#detected-an-existing-postgresql-database "Permalink") 升級到 GitLab 13.0 后，使用 Auto DevOps 部署時可能會遇到以下消息： > 檢測到已安裝在不贊成使用的通道 1 上的現有 PostgreSQL 數據庫，但當前通道設置為 2.在 GitLab 13.0 中，默認通道更改為 2\. […] 默認情況下，Auto DevOps 會在應用程序旁邊安裝集群內 PostgreSQL 數據庫. 在 GitLab 13.0 中更改了默認安裝方法，并且升級現有數據庫需要用戶參與. 兩種安裝方法是： * **通道 1（不建議使用）：**作為關聯的 Helm 圖表的依賴項拉入數據庫. 只支持 Kubernetes 版本 1.15 之前的版本. * **通道 2（當前）：**將數據庫安裝為獨立的 Helm 圖表. 將集群內數據庫功能與 Kubernetes 1.16 及更高版本一起使用時是必需的. 如果收到此錯誤，則可以執行以下操作之一： * 通過將`AUTO_DEVOPS_POSTGRES_CHANNEL`設置為`1`并重新部署，可以*放心地*忽略該警告并繼續使用通道 1 PostgreSQL 數據庫. * 通過將`AUTO_DEVOPS_POSTGRES_DELETE_V1`設置為非空值并重新部署，可以刪除通道 1 PostgreSQL 數據庫并安裝新的通道 2 數據庫. **危險：**刪除通道 1 PostgreSQL 數據庫將永久刪除現有的通道 1 數據庫及其所有數據. 有關備份和升級數據庫的更多信息，請參見[升級 PostgreSQL](upgrading_postgresql.html) . * 如果不使用集群內數據庫，則可以將`POSTGRES_ENABLED`設置為`false`并重新部署. 此選項與*沒有圖表內 PostgreSQL 依賴項*的*自定義圖表的*用戶特別相關. 數據庫自動檢測基于您的發行版的`postgresql.enabled` Helm 值. 該值是基于`POSTGRES_ENABLED` CI 變量設置的，并且由 Helm 保留，無論您的圖表是否使用該變量. **危險：**將`POSTGRES_ENABLED`設置為`false`永久刪除您環境中的任何現有通道 1 數據庫. ## Development guides[](#development-guides "Permalink") [Development guide for Auto DevOps](../../development/auto_devops.html)