Customizing Auto DevOps · Gitlab 中文文檔

# Customizing Auto DevOps > 原文：[https://docs.gitlab.com/ee/topics/autodevops/customize.html](https://docs.gitlab.com/ee/topics/autodevops/customize.html) * [Custom buildpacks](#custom-buildpacks) * [Multiple buildpacks](#multiple-buildpacks) * [Custom `Dockerfile`](#custom-dockerfile) * [Passing arguments to `docker build`](#passing-arguments-to-docker-build) * [Forward CI variables to the build environment](#forward-ci-variables-to-the-build-environment) * [Custom Helm Chart](#custom-helm-chart) * [Customize values for Helm Chart](#customize-values-for-helm-chart) * [Custom Helm chart per environment](#custom-helm-chart-per-environment) * [Customizing `.gitlab-ci.yml`](#customizing-gitlab-ciyml) * [Customizing the Kubernetes namespace](#customizing-the-kubernetes-namespace) * [Using components of Auto DevOps](#using-components-of-auto-devops) * [PostgreSQL database support](#postgresql-database-support) * [Upgrading PostgresSQL](#upgrading-postgressql) * [Using external PostgreSQL database providers](#using-external-postgresql-database-providers) * [Environment variables](#environment-variables) * [Build and deployment](#build-and-deployment) * [Database](#database) * [Disable jobs](#disable-jobs) * [Application secret variables](#application-secret-variables) * [Advanced replica variables setup](#advanced-replica-variables-setup) * [Deploy policy for staging and production environments](#deploy-policy-for-staging-and-production-environments) * [Deploy policy for canary environments](#deploy-policy-for-canary-environments-premium) * [Incremental rollout to production](#incremental-rollout-to-production-premium) * [Timed incremental rollout to production](#timed-incremental-rollout-to-production-premium) * [Auto DevOps banner](#auto-devops-banner) # Customizing Auto DevOps[](#customizing-auto-devops "Permalink") 盡管[Auto DevOps](index.html)提供了很好的默認設置來幫助您入門，但是您可以自定義幾乎所有內容以滿足您的需求. Auto DevOps 提供了從自定義[buildpacks](#custom-buildpacks)到[Dockerfiles](#custom-dockerfile)和[Helm 圖表的所有內容](#custom-helm-chart) . 您甚至可以將完整的[CI / CD 配置](#customizing-gitlab-ciyml)復制到您的項目中，以啟用暫存和 Canary 部署等. ## Custom buildpacks[](#custom-buildpacks "Permalink") 如果您的項目無法自動檢測到構建包，或者要使用自定義構建包，則可以在項目中使用項目變量或`.buildpacks`文件覆蓋`.buildpacks` ： * **項目變量** -使用要使用的 buildpack 的 URL 創建項目變量`BUILDPACK_URL` . * **`.buildpacks`文件** -在項目的存儲庫中添加一個名為`.buildpacks`的文件，并添加要在文件中一行使用的 buildpack 的 URL. 如果要使用多個 buildpack，請每行輸入一個 buildpack. buildpack URL 可以指向 Git 存儲庫 URL 或 tarball URL. 對于 Git 存儲庫，您可以通過將`#<ref>`附加到 Git 存儲庫 URL 來指向特定的 Git 引用（例如，提交 SHA，標記名稱或分支名稱）. 例如： * 標簽`v142` ： `https://github.com/heroku/heroku-buildpack-ruby.git#v142` : `https://github.com/heroku/heroku-buildpack-ruby.git#v142` . * 分支`mybranch` ： `https://github.com/heroku/heroku-buildpack-ruby.git#mybranch` : `https://github.com/heroku/heroku-buildpack-ruby.git#mybranch` . * 提交 SHA `f97d8a8ab49` ： `https://github.com/heroku/heroku-buildpack-ruby.git#f97d8a8ab49` : `https://github.com/heroku/heroku-buildpack-ruby.git#f97d8a8ab49` . ### Multiple buildpacks[](#multiple-buildpacks "Permalink") Auto DevOps 不完全支持使用多個 buildpack，因為在使用`.buildpacks`文件時，自動測試將不起作用. 在后端用于解析`.buildpacks`文件的 buildpack [heroku-buildpack-multi](https://github.com/heroku/heroku-buildpack-multi/)沒有提供必要的命令`bin/test-compile`和`bin/test` . If your goal is to use only a single custom buildpack, you should provide the project variable `BUILDPACK_URL` instead. ## Custom `Dockerfile`[](#custom-dockerfile "Permalink") > [在 GitLab 13.2](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/35662)中[添加了](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/35662)對`DOCKERFILE_PATH`支持如果您的項目在項目存儲庫的根目錄中有一個`Dockerfile` ，則 Auto DevOps 會基于 Dockerfile 而不是使用 buildpacks 構建 Docker 映像. 這樣可以更快，并產生較小的映像，尤其是在您的 Dockerfile 基于[Alpine 的情況下](https://hub.docker.com/_/alpine/) . 如果設置`DOCKERFILE_PATH` CI 變量，則"自動構建"將在其中查找 Dockerfile. ## Passing arguments to `docker build`[](#passing-arguments-to-docker-build "Permalink") 可以使用`AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS`項目變量將參數傳遞給`AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS` `docker build`命令. 例如，要基于`ruby:alpine`而不是默認的`ruby:latest`構建 Docker 映像： 1. Set `AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS` to `--build-arg=RUBY_VERSION=alpine`. 2. 將以下內容添加到自定義`Dockerfile` ： ``` ARG RUBY_VERSION=latest FROM ruby:$RUBY_VERSION # ... put your stuff here ``` **注意：**如果需要傳遞復雜的值（例如換行符和空格）， **請**使用 Base64 編碼. 由于 Auto DevOps 如何使用自變量，此類未經編碼的復雜值可能導致轉義問題.**警告：**盡可能避免將秘密作為 Docker 構建參數傳遞，因為它們可能會保留在映像中. 有關詳細信息，請參見[有關最佳實踐的討論](https://github.com/moby/moby/issues/13490) . ## Forward CI variables to the build environment[](#forward-ci-variables-to-the-build-environment "Permalink") 在 GitLab 12.3 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/25514) ，但在 11.9 及更高版本中可用. 可以使用`AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` CI 變量將 CI 變量轉發到構建環境中. 轉發的變量應在逗號分隔的列表中按名稱指定. 例如，要轉發變量`CI_COMMIT_SHA`和`CI_ENVIRONMENT_NAME` ，請將`AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES`設置為`CI_COMMIT_SHA,CI_ENVIRONMENT_NAME` . * 使用 Buildpacks 時，轉發的變量將自動用作環境變量. * 使用`Dockerfile` ，需要執行以下附加步驟： 1. 通過將以下代碼添加到文件頂部來激活實驗性`Dockerfile`語法： ``` # syntax = docker/dockerfile:experimental ``` 2. 要在任何可用的秘密`RUN $COMMAND`在`Dockerfile` ，秘密文件和源安裝運行之前，它`$COMMAND` ： ``` RUN --mount=type=secret,id=auto-devops-build-secrets . /run/secrets/auto-devops-build-secrets && $COMMAND ``` **注意：**設置`AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` ，Auto DevOps 會啟用實驗性[Docker BuildKit](https://s0docs0docker0com.icopy.site/develop/develop-images/build_enhancements/)功能以使用`--secret`標志. ## Custom Helm Chart[](#custom-helm-chart "Permalink") Auto DevOps 使用[Helm](https://helm.sh/)將您的應用程序部署到 Kubernetes. 您可以通過將圖表捆綁到項目存儲庫中或通過指定項目變量來覆蓋使用的 Helm 圖表： * **捆綁圖** -如果您的項目中有一個帶有`Chart.yaml`文件的`./chart`目錄，則 Auto DevOps 將檢測到該圖并使用它代替[默認圖](https://gitlab.com/gitlab-org/charts/auto-deploy-app) ，從而使您能夠精確地控制應用程序的部署方式. * **項目變量** -創建一個[項目變量](../../ci/variables/README.html#gitlab-cicd-environment-variables) `AUTO_DEVOPS_CHART`有一個自定義圖表的 URL 來使用，或創建兩個項目變量： `AUTO_DEVOPS_CHART_REPOSITORY`有一個自定義圖表庫的 URL，并`AUTO_DEVOPS_CHART`與路徑圖. ## Customize values for Helm Chart[](#customize-values-for-helm-chart "Permalink") [介紹](https://gitlab.com/gitlab-org/gitlab/-/issues/30628)在 GitLab 12.6， `.gitlab/auto-deploy-values.yaml`將默認為頭盔升級使用. 您可以通過以下任一方式覆蓋[默認 Helm 圖表中](https://gitlab.com/gitlab-org/charts/auto-deploy-app) `values.yaml`文件中的[默認值](https://gitlab.com/gitlab-org/charts/auto-deploy-app) ： * 將名為`.gitlab/auto-deploy-values.yaml`的文件添加到您的存儲庫，如果找到，該文件將自動使用. * 將具有不同名稱或路徑的文件添加到存儲庫，并使用路徑和名稱設置`HELM_UPGRADE_VALUES_FILE` [環境變量](#environment-variables) . **注：**對于 GitLab 12.5 和更早的版本，使用`HELM_UPGRADE_EXTRA_ARGS`環境變量設置以覆蓋默認圖表值`HELM_UPGRADE_EXTRA_ARGS`到`--values <my-values.yaml>` ## Custom Helm chart per environment[](#custom-helm-chart-per-environment "Permalink") 您可以通過將環境變量定義為所需環境來指定每個環境使用自定義 Helm 圖表. 請參閱[限制變量的環境范圍](../../ci/variables/README.html#limit-the-environment-scopes-of-environment-variables) . ## Customizing `.gitlab-ci.yml`[](#customizing-gitlab-ciyml "Permalink") Auto DevOps 是完全可自定義的，因為[Auto DevOps 模板](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)只是[`.gitlab-ci.yml`](../../ci/yaml/README.html)文件的實現，并且僅使用任何`.gitlab-ci.yml`實現的`.gitlab-ci.yml` . 要修改 Auto DevOps 使用的 CI / CD 管道，請[`include`模板](../../ci/yaml/README.html#includetemplate) ，并根據需要通過向包含以下內容的存儲庫的根目錄中添加`.gitlab-ci.yml`文件來自定義它： ``` include: - template: Auto-DevOps.gitlab-ci.yml ``` 添加您的更改，您的添加將使用[`include`](../../ci/yaml/README.html#include)所描述的行為與[Auto DevOps 模板](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)合并. 如果您需要專門刪除文件的一部分，還可以將[Auto DevOps 模板](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)的內容復制并粘貼到您的項目中，并根據需要進行編輯. ## Customizing the Kubernetes namespace[](#customizing-the-kubernetes-namespace "Permalink") 在 GitLab 12.6 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/27630) . 對于不受 GitLab 管理的集群，可以通過指定[`environment:kubernetes:namespace`](../../ci/environments/index.html#configuring-kubernetes-deployments)來自定義`.gitlab-ci.yml`的[`environment:kubernetes:namespace`](../../ci/environments/index.html#configuring-kubernetes-deployments) . 例如，以下配置將覆蓋用于`production`部署的名稱空間： ``` include: - template: Auto-DevOps.gitlab-ci.yml production: environment: kubernetes: namespace: production ``` 使用 Auto DevOps 部署到自定義名稱空間時，群集隨附的服務帳戶至少需要名稱空間內的`edit`角色. * 如果服務帳戶可以創建名稱空間，則可以按需創建名稱空間. * 否則，名稱空間必須在部署之前存在. ## Using components of Auto DevOps[](#using-components-of-auto-devops "Permalink") 如果僅需要 Auto DevOps 提供的功能的子集，則可以將各個 Auto DevOps 作業包括在自己的`.gitlab-ci.yml` . 每個組件作業都依賴于一個階段，該階段應該在包含模板的`.gitlab-ci.yml`中定義. 例如，要使用[自動構建](stages.html#auto-build) ，可以將以下內容添加到`.gitlab-ci.yml` ： ``` stages: - build include: - template: Jobs/Build.gitlab-ci.yml ``` 有關可用作業的信息，請參見[Auto DevOps 模板](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml) . **棄用：**從[GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/213336)開始，使用[`only`](../../ci/yaml/README.html#onlyexcept-basic)或[`except`](../../ci/yaml/README.html#onlyexcept-basic)語法的 Auto DevOps 模板將切換到[`rules`](../../ci/yaml/README.html#rules)語法. 如果您`.gitlab-ci.yml`擴展了這些汽車的 DevOps 模板和覆蓋`only`或`except`關鍵字，您必須遷移模板使用[`rules`](../../ci/yaml/README.html#rules)語法的基本模板被遷移到使用后`rules`語法. 對于尚不能遷移的用戶，您可以選擇將模板固定到[基于 GitLab 12.10 的模板](https://gitlab.com/gitlab-org/auto-devops-v12-10) . ## PostgreSQL database support[](#postgresql-database-support "Permalink") 為了支持需要數據庫的應用程序，默認情況下配置[PostgreSQL](https://s0www0postgresql0org.icopy.site/) . 訪問數據庫的憑據已預先配置，但可以通過設置關聯[變量](#environment-variables)進行自定義. 您可以使用這些憑據來定義`DATABASE_URL` ： ``` postgres://user:password@postgres-host:postgres-port/postgres-database ``` ### Upgrading PostgresSQL[](#upgrading-postgressql "Permalink") **棄用：**用于控制默認`AUTO_DEVOPS_POSTGRES_CHANNEL`配置 PostgreSQL 的變量`AUTO_DEVOPS_POSTGRES_CHANNEL`在[GitLab 13.0 中](https://gitlab.com/gitlab-org/gitlab/-/issues/210499)已更改為`2` . 要繼續使用舊的 PostgreSQL，請將`AUTO_DEVOPS_POSTGRES_CHANNEL`變量設置為`1` . 用于配置 PostgreSQL 的圖表的版本： * 在 GitLab 13.0 和更高版本中為 8.2.1，但如果需要可以將其設置回 0.7.1. * 可以在 GitLab 12.9 和 12.10 中設置為 0.7.1 至 8.2.1. * 在 GitLab 12.8 及更早版本中為 0.7.1. GitLab 鼓勵用戶[將其數據庫遷移](upgrading_postgresql.html)到較新的 PostgreSQL. ### Using external PostgreSQL database providers[](#using-external-postgresql-database-providers "Permalink") 盡管 Auto DevOps 為生產環境提供了對 PostgreSQL 容器的開箱即用支持，但在某些情況下，它可能不夠安全或沒有彈性，您可能要使用外部托管提供程序（例如 AWS Relational Database）服務）（適用于 PostgreSQL）. 您必須在項目的 CI / CD 設置中為`POSTGRES_ENABLED`和`DATABASE_URL`定義環境范圍的變量： 1. 使用范圍內的[環境變量](../../ci/environments/index.html#scoping-environments-with-specs)針對所需環境禁用內置 PostgreSQL 安裝. 對于此用例，可能只需要將`production`添加到此列表中. 用于 Review Apps 和登臺的內置 PostgreSQL 設置就足夠了. [![Auto Metrics](https://img.kancloud.cn/c0/36/c0367f1f6e6d5868ae7e27539e2ada9a_969x78.png)](img/disable_postgres.png) 2. Define the `DATABASE_URL` CI variable as a scoped environment variable that will be available to your application. This should be a URL in the following format: ``` postgres://user:password@postgres-host:postgres-port/postgres-database ``` 您必須確保您的 Kubernetes 集群可以訪問托管 PostgreSQL 的任何地方的網絡. ## Environment variables[](#environment-variables "Permalink") 以下變量可用于設置 Auto DevOps 域，提供自定義 Helm 圖表或縮放應用程序. PostgreSQL 也可以自定義，您可以使用[自定義 buildpack](#custom-buildpacks) . ### Build and deployment[](#build-and-deployment "Permalink") 下表列出了與構建和部署應用程序有關的變量. | **Variable** | **Description** | | --- | --- | | `ADDITIONAL_HOSTS` | 指定為逗號分隔列表的標準域名，添加到 Ingress 主機中. | | `<ENVIRONMENT>_ADDITIONAL_HOSTS` | 對于特定環境，將指定為逗號分隔列表的標準域名添加到 Ingress 主機. 這優先于`ADDITIONAL_HOSTS` . | | `AUTO_DEVOPS_ATOMIC_RELEASE` | 從 GitLab 13.0 開始，默認情況下，Auto DevOps 使用[`--atomic`](https://v2.helm.sh/docs/helm/#options-43)進行 Helm 部署. 將此變量設置為`false`可禁用`--atomic` | | `AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED` | 當設置為非空值且不存在`Dockerfile` ，"自動構建"將使用 Cloud Native Buildpacks 而非 Herokuish 構建應用程序. [更多細節](stages.html#auto-build-using-cloud-native-buildpacks-beta) . | | `AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER` | 使用 Cloud Native Buildpacks 構建時使用的構建器. 默認的構建器是`heroku/buildpacks:18` . [更多細節](stages.html#auto-build-using-cloud-native-buildpacks-beta) . | | `AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS` | 要傳遞給`docker build`命令的額外參數. 請注意，使用引號不會阻止單詞拆分. [更多細節](#passing-arguments-to-docker-build) . | | `AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` | A [comma-separated list of CI variable names](#forward-ci-variables-to-the-build-environment) to be forwarded to the build environment (the buildpack builder or `docker build`). | | `AUTO_DEVOPS_CHART` | Helm Chart 用于部署您的應用程序. 默認為[GitLab 提供的](https://gitlab.com/gitlab-org/charts/auto-deploy-app) . | | `AUTO_DEVOPS_CHART_REPOSITORY` | Helm Chart 存儲庫用于搜索圖表. 默認為`https://charts.gitlab.io` . | | `AUTO_DEVOPS_CHART_REPOSITORY_NAME` | 從 GitLab 11.11 開始，用于設置 Helm 存儲庫的名稱. 默認為`gitlab` . | | `AUTO_DEVOPS_CHART_REPOSITORY_USERNAME` | 從 GitLab 11.11 開始，用于設置用戶名以連接到 Helm 存儲庫. 默認為無憑據. 還要設置`AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD` . | | `AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD` | 從 GitLab 11.11 開始，用于設置密碼以連接到 Helm 存儲庫. 默認為無憑據. 還要設置`AUTO_DEVOPS_CHART_REPOSITORY_USERNAME` . | | `AUTO_DEVOPS_DEPLOY_DEBUG` | 從 GitLab 13.1 開始，如果存在此變量，Helm 將輸出調試日志. | | `AUTO_DEVOPS_ALLOW_TO_FORCE_DEPLOY_V<N>` | 從[auto-deploy-image](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image) v1.0.0 起，如果存在此變量，則將強制部署新的主要圖表版本. [更多細節](upgrading_chart.html#ignore-warning-and-continue-deploying) | | `AUTO_DEVOPS_MODSECURITY_SEC_RULE_ENGINE` | 從 GitLab 12.5 起，與[ModSecurity 功能標記](../../user/clusters/applications.html#web-application-firewall-modsecurity)結合使用可切換[ModSecurity 的`SecRuleEngine`](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#SecRuleEngine)行為. 默認為`DetectionOnly` . | | `BUILDPACK_URL` | Buildpack’s full URL. Can point to either [a Git repository URL or a tarball URL](#custom-buildpacks). | | `CANARY_ENABLED` | 從 GitLab 11.0 開始，用于定義[Canary 環境](#deploy-policy-for-canary-environments-premium)的[部署策略](#deploy-policy-for-canary-environments-premium) . | | `CANARY_PRODUCTION_REPLICAS` | 要在生產環境中為[Canary 部署](../../user/project/canary_deployments.html)進行部署的 Canary 副本數. 優先于`CANARY_REPLICAS` . 默認為 1. | | `CANARY_REPLICAS` | 用于[Canary 部署](../../user/project/canary_deployments.html)的 Canary 副本數. 默認為 1. | | `DOCKERFILE_PATH` | 從 GitLab 13.2 開始，允許[在構建階段](#custom-dockerfile)覆蓋[默認的 Dockerfile 路徑](#custom-dockerfile) | | `HELM_RELEASE_NAME` | 從 GitLab 12.1 起，可以覆蓋`helm`發布名稱. 將多個項目部署到單個名稱空間時，可用于分配唯一的發行版名稱. | | `HELM_UPGRADE_VALUES_FILE` | 從 GitLab 12.6 起，可以覆蓋`helm upgrade`值文件. 默認為`.gitlab/auto-deploy-values.yaml` . | | `HELM_UPGRADE_EXTRA_ARGS` | 從 GitLab 11.11 開始，在部署應用程序時允許在`helm`命令中使用其他參數. 請注意，使用引號不會阻止單詞拆分. | | `INCREMENTAL_ROLLOUT_MODE` | 從 GitLab 11.4 起，如果存在的話，可用于為生產環境啟用應用程序的[增量部署](#incremental-rollout-to-production-premium) . 對于手動部署作業，設置為" `manual` ；對于自動部署部署，則設置為" `timed` ，每個延遲 5 分鐘. | | `K8S_SECRET_*` | 從 GitLab 11.7 開始，Auto DevOps 會將任何前綴為[`K8S_SECRET_`](#application-secret-variables)變量作為環境變量提供給已部署的應用程序. | | `KUBE_INGRESS_BASE_DOMAIN` | 從 GitLab 11.8 開始，可用于為每個群集設置一個域. 有關更多信息，請參見[群集域](../../user/project/clusters/index.html#base-domain) . | | `PRODUCTION_REPLICAS` | 要在生產環境中部署的副本數. 優先于`REPLICAS` ，默認值為 1.對于零停機升級，設置為 2 或更大. | | `REPLICAS` | 要部署的副本數. 默認為 1. | | `ROLLOUT_RESOURCE_TYPE` | 從 GitLab 11.9 開始，允許使用自定義 Helm 圖表指定正在部署的資源類型. 默認值為`deployment` . | | `ROLLOUT_STATUS_DISABLED` | 從 GitLab 12.0 開始，用于禁用推出狀態檢查，因為它不支持所有資源類型，例如`cronjob` . | | `STAGING_ENABLED` | 從 GitLab 10.8 開始，用于定義[登臺和生產環境](#deploy-policy-for-staging-and-production-environments)的[部署策略](#deploy-policy-for-staging-and-production-environments) . | **提示：**使用[項目變量](../../ci/variables/README.html#gitlab-cicd-environment-variables)設置副本[變量后](../../ci/variables/README.html#gitlab-cicd-environment-variables) ，可以通過重新部署來縮放應用程序.**注意：**您*不*應該直接擴展使用 Kubernetes 您的應用程序. 這可能會導致 Helm 無法檢測到更改而造成混亂，隨后使用 Auto DevOps 進行的部署可能會撤消您的更改. ### Database[](#database "Permalink") 下表列出了與數據庫有關的變量. | **Variable** | **Description** | | --- | --- | | `DB_INITIALIZE` | 從 GitLab 11.4 開始，用于指定運行以初始化應用程序的 PostgreSQL 數據庫的命令. 在應用程序窗格中運行. | | `DB_MIGRATE` | 從 GitLab 11.4 開始，用于指定運行以遷移應用程序的 PostgreSQL 數據庫的命令. 在應用程序窗格中運行. | | `POSTGRES_ENABLED` | 是否啟用 PostgreSQL. 默認為`true` . 設置為`false`可禁用 PostgreSQL 的自動部署. | | `POSTGRES_USER` | PostgreSQL 用戶. 默認為`user` . 將其設置為使用自定義用戶名. | | `POSTGRES_PASSWORD` | PostgreSQL 密碼. 默認為`testing-password` . 將其設置為使用自定義密碼. | | `POSTGRES_DB` | PostgreSQL 數據庫名稱. 默認為[`$CI_ENVIRONMENT_SLUG`](../../ci/variables/README.html#predefined-environment-variables)的值. 將其設置為使用自定義數據庫名稱. | | `POSTGRES_VERSION` | 用于[`postgres` Docker 映像的](https://hub.docker.com/_/postgres)標簽. 對于`9.6.16` GitLab 13.0 `9.6.16`的測試和部署，默認值為`9.6.16` （以前為`9.6.2` ）. 如果`AUTO_DEVOPS_POSTGRES_CHANNEL`設置為`1` ，則部署將使用默認版本`9.6.2` . | ### Disable jobs[](#disable-jobs "Permalink") 下表列出了用于禁用作業的變量. | **Variable** | **Description** | | --- | --- | | `CODE_QUALITY_DISABLED` | 從 GitLab 11.0 起，用于禁用`codequality`作業. 如果存在變量，則不會創建作業. | | `CONTAINER_SCANNING_DISABLED` | From GitLab 11.0, used to disable the `sast:container` job. If the variable is present, the job won’t be created. | | `DAST_DISABLED` | 從 GitLab 11.0 起，用于禁用`dast`作業. 如果存在變量，則不會創建作業. | | `DEPENDENCY_SCANNING_DISABLED` | 從 GitLab 11.0 起，用于禁用`dependency_scanning`作業. 如果存在變量，則不會創建作業. | | `LICENSE_MANAGEMENT_DISABLED` | 從 GitLab 11.0 開始，用于禁用`license_management`作業. 如果存在變量，則不會創建作業. | | `PERFORMANCE_DISABLED` | 從 GitLab 11.0 起，用于禁用瀏覽器`performance`作業. 如果存在變量，則不會創建作業. | | `LOAD_PERFORMANCE_DISABLED` | 從 GitLab 13.2 開始，用于禁用`load_performance`作業. 如果存在變量，則不會創建作業. | | `REVIEW_DISABLED` | 從 GitLab 11.0 開始，用于禁用`review`和手動`review:stop`作業. 如果存在該變量，則不會創建這些作業. | | `SAST_DISABLED` | 從 GitLab 11.0 起，用于禁用`sast`作業. 如果存在變量，則不會創建作業. | | `TEST_DISABLED` | 從 GitLab 11.0 起，用于禁用`test`作業. 如果存在變量，則不會創建作業. | ### Application secret variables[](#application-secret-variables "Permalink") 在 GitLab 11.7 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/49056) . 某些應用程序需要定義可由部署的應用程序訪問的秘密變量. Auto DevOps 會檢測以`K8S_SECRET_`開頭的變量，并將這些帶前綴的變量作為環境變量提供給已部署的應用程序. 要配置您的應用程序變量： 1. Go to your project’s **設置> CI / CD**, then expand the **Variables** section. 2. 創建一個 CI / CD 變量，確保密鑰以`K8S_SECRET_`為前綴. 例如，您可以使用鍵`K8S_SECRET_RAILS_MASTER_KEY`創建一個變量. 3. 通過手動創建新管道或將代碼更改推送到 GitLab 來運行 Auto DevOps 管道. Auto DevOps 管道將使用您的應用程序秘密變量來填充 Kubernetes 秘密. 這個秘密在每個環境中都是唯一的. 部署應用程序時，機密將作為環境變量加載到運行應用程序的容器中. 在上面的示例之后，您可以在下面看到包含`RAILS_MASTER_KEY`變量的機密. ``` $ kubectl get secret production-secret -n minimal-ruby-app-54 -o yaml apiVersion: v1 data: RAILS_MASTER_KEY: MTIzNC10ZXN0 kind: Secret metadata: creationTimestamp: 2018-12-20T01:48:26Z name: production-secret namespace: minimal-ruby-app-54 resourceVersion: "429422" selfLink: /api/v1/namespaces/minimal-ruby-app-54/secrets/production-secret uid: 57ac2bfd-03f9-11e9-b812-42010a9400e4 type: Opaque ``` 通常認為環境變量在 Kubernetes 容器中是不可變的. 如果在不更改任何代碼的情況下更新應用程序機密，然后手動創建新管道，則會發現任何正在運行的應用程序吊艙都不會具有更新后的機密. 要更新機密，請執行以下任一操作： * 將代碼更新推送到 GitLab，以強制 Kubernetes 部署重新創建 Pod. * 手動刪除正在運行的 Pod，以使 Kubernetes 創建具有更新機密的新 Pod. **注意：**由于當前 Auto DevOps 腳本環境的限制，當前不支持具有多行值的變量. ### Advanced replica variables setup[](#advanced-replica-variables-setup "Permalink") 除了上面提到的兩個與副本相關的生產變量之外，您還可以將其他變量用于不同的環境. Kubernetes 的標簽名為`track` ，GitLab CI / CD 環境名稱和副本環境變量被組合為`TRACK_ENV_REPLICAS`格式，使您能夠定義自己的變量來擴展 Pod 的副本： * `TRACK` ：Helm Chart 應用程序定義中`track` [Kubernetes 標簽](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)的大寫值. 如果未設置，則不會考慮到變量名. * `ENV` ：部署作業的大寫環境名稱，在`.gitlab-ci.yml`設置. 在下面的示例中，環境的名稱為`qa` ，并且部署了軌道`foo` ，這將導致一個名為`FOO_QA_REPLICAS`的環境變量： ``` QA testing: stage: deploy environment: name: qa script: - deploy foo ``` 還必須在應用程序的 Helm 圖表中定義被引用的`foo`軌道，例如： ``` replicaCount: 1 image: repository: gitlab.example.com/group/project tag: stable pullPolicy: Always secrets: - name: gitlab-registry application: track: foo tier: web service: enabled: true name: web type: ClusterIP url: http://my.host.com/ externalPort: 5000 internalPort: 5000 ``` ### Deploy policy for staging and production environments[](#deploy-policy-for-staging-and-production-environments "Permalink") 在 GitLab 10.8 中[引入](https://gitlab.com/gitlab-org/gitlab-ci-yml/-/merge_requests/160) . **提示：**您也可以在[項目的設置中進行設置](index.html#deployment-strategy) . Auto DevOps 的正常行為是使用連續部署，每次在默認分支上運行新管道時，都會自動推送到`production`環境. 但是，在某些情況下，您可能需要使用暫存環境并手動部署到生產環境. 對于這種情況，引入了`STAGING_ENABLED`環境變量. 如果您定義`STAGING_ENABLED` ，例如將`STAGING_ENABLED`設置為`1`作為 CI / CD 變量，則 GitLab 會自動將應用程序部署到`staging`環境，并在準備好手動部署到生產環境時為您創建`production_manual`作業. ### Deploy policy for canary environments[](#deploy-policy-for-canary-environments-premium "Permalink") 在 GitLab 11.0 中[引入](https://gitlab.com/gitlab-org/gitlab-ci-yml/-/merge_requests/171) . 在將任何更改部署到生產之前，可以使用[Canary 環境](../../user/project/canary_deployments.html) . 如果您在項目中定義`CANARY_ENABLED` ，例如將`CANARY_ENABLED`設置為`1`作為 CI / CD 變量，則會創建兩個手動作業： * `canary` -將應用程序部署到金絲雀環境. * `production_manual`手動將應用程序部署到生產環境. ### Incremental rollout to production[](#incremental-rollout-to-production-premium "Permalink") 在 GitLab 10.8 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/5415) . **提示：**您也可以在[項目的設置中進行設置](index.html#deployment-strategy) . 當您準備將新版本的應用程序部署到生產環境時，您可能希望使用增量部署將最新的代碼替換為少數 Pod，以檢查應用程序的行為，然后手動將部署率提高到 100％ . 如果在項目中將`INCREMENTAL_ROLLOUT_MODE`設置為`manual` ，則將創建 4 個不同的[手動](../../ci/pipelines/index.html#add-manual-interaction-to-your-pipeline)作業，而不是標準`production`作業： 1. `rollout 10%` 2. `rollout 25%` 3. `rollout 50%` 4. `rollout 100%` 該百分比基于`REPLICAS`變量，并定義了您要用于部署的 Pod 數量. 如果該值為`10` ，并且您運行`10%`部署作業，那么將有`1`新容器+ `9`個舊容器. 要開始工作，請點擊播放圖標（）旁邊的職位名稱. 您不需要從`10%`增加到`100%` ，您可以跳到所需的任何工作. 您也可以在達到`100%`之前通過執行較低百分比的作業來縮小規模. 一旦達到`100%` ，您將無法縮小規模，并且必須通過使用環境頁面中的" [回滾"按鈕](../../ci/environments/index.html#retrying-and-rolling-back)重新部署舊版本來進行[回滾](../../ci/environments/index.html#retrying-and-rolling-back) . 在下面，您可以看到如果定義了發布或登臺變量，管道的外觀. 沒有`INCREMENTAL_ROLLOUT_MODE`和`STAGING_ENABLED` ： [![Staging and rollout disabled](https://img.kancloud.cn/ce/68/ce685ec64b07bf10cb23886fb264f321_1300x458.png)](img/rollout_staging_disabled.png) 沒有`INCREMENTAL_ROLLOUT_MODE`和`STAGING_ENABLED` ： [![Staging enabled](https://img.kancloud.cn/86/60/8660e80a8dadc9cc1a565dd60d97cd73_1338x443.png)](img/staging_enabled.png) 在將`INCREMENTAL_ROLLOUT_MODE`設置為`manual`且沒有`STAGING_ENABLED`情況`STAGING_ENABLED` ： [![Rollout enabled](https://img.kancloud.cn/37/05/3705ccbde563fb9cd56b99eb5e3689ec_1289x453.png)](img/rollout_enabled.png) 將`INCREMENTAL_ROLLOUT_MODE`設置為`manual` ，并將`STAGING_ENABLED` [![Rollout and staging enabled](https://img.kancloud.cn/7f/0c/7f0c4a7c526527a47aecc6b5cca98f85_1248x379.png)](img/rollout_staging_enabled.png) **注意：**在 GitLab 11.4 之前， `INCREMENTAL_ROLLOUT_ENABLED`環境變量的存在啟用了此功能. 此配置已棄用，以后將被刪除. ### Timed incremental rollout to production[](#timed-incremental-rollout-to-production-premium "Permalink") 在 GitLab 11.4 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/7545) . **提示：**您也可以在[項目的設置中進行設置](index.html#deployment-strategy) . 此配置基于[向生產的增量部署](#incremental-rollout-to-production-premium) . 除以下內容外，其他所有行為均相同： * 要啟用它，請將`INCREMENTAL_ROLLOUT_MODE`變量設置為`timed` . * Instead of the standard `production` job, the following jobs are created with a 5 minute delay between each: 1. `timed rollout 10%` 2. `timed rollout 25%` 3. `timed rollout 50%` 4. `timed rollout 100%` ## Auto DevOps banner[](#auto-devops-banner "Permalink") 在未啟用自動 DevOps 的情況下，對新項目具有維護者或更高權限的用戶將顯示以下 Auto DevOps 標語： [![Auto DevOps banner](https://img.kancloud.cn/e1/bf/e1bfb1b8e67f906a66ff6c04de3b0c71_1924x372.png)](img/autodevops_banner_v12_6.png) 可以為以下內容禁用橫幅： * 用戶，當他們自己關閉它時. * 通過顯式[禁用 Auto DevOps 的項目](index.html#enablingdisabling-auto-devops) . * 整個 GitLab 實例： * 由管理員在 Rails 控制臺中運行以下命令： ``` Feature . enable ( :auto_devops_banner_disabled ) ``` * 通過帶有管理員訪問令牌的 REST API： ``` curl --data "value=true" --header "PRIVATE-TOKEN: <personal_access_token>" https://gitlab.example.com/api/v4/features/auto_devops_banner_disabled ```