# Environments and deployments > 原文：[https://docs.gitlab.com/ee/ci/environments/](https://docs.gitlab.com/ee/ci/environments/) * [Introduction](#introduction) * [Configuring environments](#configuring-environments) * [Defining environments](#defining-environments) * [Environment variables and Runner](#environment-variables-and-runner) * [Set dynamic environment URLs after a job finishes](#set-dynamic-environment-urls-after-a-job-finishes) * [Example of setting dynamic environment URLs](#example-of-setting-dynamic-environment-urls) * [Configuring manual deployments](#configuring-manual-deployments) * [Configuring dynamic environments](#configuring-dynamic-environments) * [Allowed variables](#allowed-variables) * [Example configuration](#example-configuration) * [Configuring Kubernetes deployments](#configuring-kubernetes-deployments) * [Configuring incremental rollouts](#configuring-incremental-rollouts) * [Deployment safety](#deployment-safety) * [Complete example](#complete-example) * [Protected environments](#protected-environments) * [Working with environments](#working-with-environments) * [Viewing environments and deployments](#viewing-environments-and-deployments) * [Viewing deployment history](#viewing-deployment-history) * [Retrying and rolling back](#retrying-and-rolling-back) * [What to expect with a rollback](#what-to-expect-with-a-rollback) * [Using the environment URL](#using-the-environment-url) * [Going from source files to public pages](#going-from-source-files-to-public-pages) * [Stopping an environment](#stopping-an-environment) * [Automatically stopping an environment](#automatically-stopping-an-environment) * [Environments auto-stop](#environments-auto-stop) * [Auto-stop example](#auto-stop-example) * [Delete a stopped environment](#delete-a-stopped-environment) * [Delete environments through the UI](#delete-environments-through-the-ui) * [Delete environments through the API](#delete-environments-through-the-api) * [Prepare an environment](#prepare-an-environment) * [Grouping similar environments](#grouping-similar-environments) * [Monitoring environments](#monitoring-environments) * [Embedding metrics in GitLab Flavored Markdown](#embedding-metrics-in-gitlab-flavored-markdown) * [Web terminals](#web-terminals) * [Check out deployments locally](#check-out-deployments-locally) * [Scoping environments with specs](#scoping-environments-with-specs) * [Environments Dashboard](#environments-dashboard-premium) * [Limitations](#limitations) * [Further reading](#further-reading) # Environments and deployments[](#environments-and-deployments "Permalink") 在 GitLab 8.9 中引入. 環境允許您在 GitLab 中控制軟件的連續部署. ## Introduction[](#introduction "Permalink") 在準備將軟件投入大眾使用之前，軟件開發過程需要許多階段. 例如： 1. 開發代碼. 2. 測試您的代碼. 3. 在將代碼發布給公眾之前，請將其部署到測試或暫存環境中. This helps find bugs in your software, and also in the deployment process as well. GitLab CI / CD 不僅能夠測試或構建您的項目，而且還可以在基礎架構中部署它們，并具有給您提供一種跟蹤部署的方式的額外好處. 換句話說，您將始終知道服務器上當前正在部署或已經部署了什么. 重要的是要知道： * 環境就像您的 CI 作業的標簽一樣，描述了代碼的部署位置. * [作業](../yaml/README.html#introduction)是在[作業](../yaml/README.html#introduction)將代碼版本部署到環境時創建的，因此每個環境可以有一個或多個部署. GitLab: * 提供每種環境的完整部署歷史記錄. * 跟蹤您的部署，因此您始終知道服務器上當前正在部署什么. 如果您有與項目關聯的部署服務（例如[Kubernetes）](../../user/project/clusters/index.html) ，則可以使用它來協助您的部署，甚至可以從 GitLab 中訪問您環境的[Web 終端](#web-terminals) ！ ## Configuring environments[](#configuring-environments "Permalink") 配置環境涉及： 1. 了解[管道的](../pipelines/index.html)工作方式. 2. 在項目的[`.gitlab-ci.yml`](../yaml/README.html)文件中定義環境. 3. 創建配置為部署您的應用程序的作業. 例如，配置了[`environment`](../yaml/README.html#environment)的部署作業將您的應用程序部署到[Kubernetes 集群](../../user/project/clusters/index.html) . 本節的其余部分說明了如何使用示例方案配置環境和部署. 假設您已經： * 在 GitLab 中創建了一個[項目](../../gitlab-basics/create-project.html) . * 設置[亞軍](../runners/README.html) . 在方案中： * 我們正在開發一個應用程序. * 我們想運行測試并在所有分支上構建我們的應用程序. * 我們的默認分支是`master` . * We deploy the app only when a pipeline on `master` branch is run. ### Defining environments[](#defining-environments "Permalink") 讓我們考慮以下`.gitlab-ci.yml`示例： ``` stages: - test - build - deploy test: stage: test script: echo "Running tests" build: stage: build script: echo "Building the app" deploy_staging: stage: deploy script: - echo "Deploy to staging server" environment: name: staging url: https://staging.example.com only: - master ``` 我們定義了三個[階段](../yaml/README.html#stages) ： * `test` * `build` * `deploy` 分配給這些階段的作業將按此順序運行. 如果任何作業失敗，則管道將失敗，分配給下一階段的作業將不會運行. 在我們的情況下： * `test`作業將首先運行. * 然后是`build`作業. * 最后， `deploy_staging`作業. 使用此配置，我們： * 檢查測試是否通過. * 確保我們的應用程序能夠成功構建. * 最后，我們部署到登臺服務器. **注意：** `environment`關鍵字定義了應用程序的部署位置. 環境`name`和`url`在 GitLab 中的各個位置公開. 每次指定環境的作業成功執行時，都會記錄部署，Git SHA 和環境名稱.**注意：**環境名稱中不允許使用某些字符. 僅使用字母，數字，空格和`-` ， `_` ， `/` ， `{` ， `}`或`.` . 另外，它不得以`/`開頭或結尾. 總而言之，使用上述`.gitlab-ci.yml`我們已經實現了以下目標： * 所有分支機構將運行`test`并`build`作業. * `deploy_staging`作業將[僅](../yaml/README.html#onlyexcept-basic)在`master`分支上運行，這意味著從分支創建的所有合并請求都不會部署到登臺服務器. * 合并請求合并后，所有作業將運行，并且`deploy_staging`作業會將我們的代碼部署到登臺服務器，而部署將記錄在名為`staging`的環境中. #### Environment variables and Runner[](#environment-variables-and-runner "Permalink") 從 GitLab 8.15 開始，環境名稱以兩種形式向 Runner 顯示： * `$CI_ENVIRONMENT_NAME` . `.gitlab-ci.yml`給出的名稱（擴展了所有變量）. * `$CI_ENVIRONMENT_SLUG` . 名稱的"清理"版本，適用于 URL，DNS 等. 如果更改現有環境的名稱，則： * `$CI_ENVIRONMENT_NAME`變量將使用新的環境名稱進行更新. * `$CI_ENVIRONMENT_SLUG`變量將保持不變，以防止意外的副作用. 從 GitLab 9.3 開始，環境 URL 通過`$CI_ENVIRONMENT_URL`向 Runner `$CI_ENVIRONMENT_URL` . URL 可以從以下任意一個展開： * `.gitlab-ci.yml`. * 如果未在`.gitlab-ci.yml`定義，則來自環境的外部 URL. #### Set dynamic environment URLs after a job finishes[](#set-dynamic-environment-urls-after-a-job-finishes "Permalink") 在 GitLab 12.9 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/17066) . 在作業腳本中，您可以指定靜態[環境 URL](#using-the-environment-url) . 但是，有時可能需要動態 URL. 例如，如果您將 Review App 部署到一個外部托管服務，該服務會為每個部署生成一個隨機 URL，例如`https://94dd65b.amazonaws.com/qa-lambda-1234567` ，則在部署腳本之前您不會知道該 URL 完成. 如果要在 GitLab 中使用環境 URL，則必須手動更新. 為了解決此問題，您可以配置部署作業以報告一組變量，包括由外部服務動態生成的 URL. GitLab 支持[dotenv（ `.env` ）](https://github.com/bkeepers/dotenv)文件格式，并使用`.env`文件中定義的變量擴展`environment:url`值. 要使用此功能，請在`.gitlab-ci.yml`指定[`artifacts:reports:dotenv`](../pipelines/job_artifacts.html#artifactsreportsdotenv)關鍵字. 有關概述，請參閱[在作業完成后設置動態 URL](https://youtu.be/70jDXtOf4Ig) . ##### Example of setting dynamic environment URLs[](#example-of-setting-dynamic-environment-urls "Permalink") 以下示例顯示了一個 Review App，該 App 為每個合并請求創建一個新環境. 每次推送都會觸發`review`作業，并創建或更新一個名為`review/your-branch-name` . 環境 URL 設置為`$DYNAMIC_ENVIRONMENT_URL` ： ``` review: script: - DYNAMIC_ENVIRONMENT_URL=$(deploy-script) # In script, get the environment URL. - echo "DYNAMIC_ENVIRONMENT_URL=$DYNAMIC_ENVIRONMENT_URL" >> deploy.env # Add the value to a dotenv file. artifacts: reports: dotenv: deploy.env # Report back dotenv file to rails. environment: name: review/$CI_COMMIT_REF_SLUG url: $DYNAMIC_ENVIRONMENT_URL # and set the variable produced in script to `environment:url` on_stop: stop_review stop_review: script: - ./teardown-environment when: manual environment: name: review/$CI_COMMIT_REF_SLUG action: stop ``` `review`作業完成后，GitLab 會立即更新`review/your-branch-name`環境的 URL. 它解析`deploy.env`報告工件，將變量列表注冊為在運行時創建的變量，并將其用于擴展`environment:url: $DYNAMIC_ENVIRONMENT_URL`并將其設置為環境 URL. 您還可以在`environment:url:`處指定 URL 的靜態部分，例如`https://$DYNAMIC_ENVIRONMENT_URL` . 如果`DYNAMIC_ENVIRONMENT_URL`值為`example.com` ，則最終結果將為`https://example.com` . [在 UI 中可以看到](#using-the-environment-url)為`review/your-branch-name`環境分配的 URL. > **Notes:** > > * `stop_review`不會生成 dotenv 報告工件，因此不會識別`DYNAMIC_ENVIRONMENT_URL`變量. 因此，您不應在`stop_review`作業中設置`environment:url:` `stop_review` > * 如果環境 URL 無效（例如，URL 格式錯誤），則系統不會更新環境 URL. ### Configuring manual deployments[](#configuring-manual-deployments "Permalink") 添加`when: manual`添加到自動執行的作業的配置會將其轉換為需要手動操作的作業. 為了擴展[前面的示例](#defining-environments) ，以下內容包括另一個作業，該作業將我們的應用程序部署到生產服務器，并由`production`環境進行跟蹤. `.gitlab-ci.yml`文件如下： ``` stages: - test - build - deploy test: stage: test script: echo "Running tests" build: stage: build script: echo "Building the app" deploy_staging: stage: deploy script: - echo "Deploy to staging server" environment: name: staging url: https://staging.example.com only: - master deploy_prod: stage: deploy script: - echo "Deploy to production server" environment: name: production url: https://example.com when: manual only: - master ``` The `when: manual` action: * 在 GitLab 的用戶界面中顯示該作業的"播放"按鈕. * 意味著僅在單擊"播放"按鈕時才會觸發`deploy_prod`作業. 您可以在管道，環境，部署和作業視圖中找到"播放"按鈕. | View | Screenshot | | --- | --- | | Pipelines | [](../img/environments_manual_action_pipelines.png) | | 單管道 | [](../img/environments_manual_action_single_pipeline.png) | | Environments | [](../img/environments_manual_action_environments.png) | | Deployments | [](../img/environments_manual_action_deployments.png) | | Jobs | [](../img/environments_manual_action_jobs.png) | 在任何視圖中單擊播放按鈕都將觸發`deploy_prod`作業，并且部署將記錄為名為`production`的新環境. **注意：**如果您環境的名稱是`production` （全部為小寫），它將記錄在[Value Stream Analytics 中](../../user/project/cycle_analytics.html) . ### Configuring dynamic environments[](#configuring-dynamic-environments "Permalink") 當部署到"穩定"的環境（例如分階段或生產）時，常規環境會很好. 但是，對于`master`以外的分支環境，可以使用動態環境. 動態環境可以通過在`.gitlab-ci.yml`動態聲明其名稱來動態創建環境. 動態環境是[Review 應用程序](../review_apps/index.html)的基本組成部分. #### Allowed variables[](#allowed-variables "Permalink") 動態環境的`name`和`url`參數可以使用大多數可用的 CI / CD 變量，包括： * [Predefined environment variables](../variables/README.html#predefined-environment-variables) * [Project and group variables](../variables/README.html#gitlab-cicd-environment-variables) * [`.gitlab-ci.yml` variables](../yaml/README.html#variables) 但是，不能使用定義的變量： * Under `script`. * 在跑步者方面. 在`environment:name`上下文中還不支持其他變量. 有關更多信息，請參見[在哪里可以使用變量](../variables/where_variables_can_be_used.html) . #### Example configuration[](#example-configuration "Permalink") GitLab Runner 在作業運行時會公開各種[環境變量](../variables/README.html) ，因此您可以將它們用作環境名稱. 在以下示例中，作業將部署到`master`以外的所有分支： ``` deploy_review: stage: deploy script: - echo "Deploy a review app" environment: name: review/$CI_COMMIT_REF_NAME url: https://$CI_ENVIRONMENT_SLUG.example.com only: - branches except: - master ``` 在此示例中： * 作業的名稱為`deploy_review` ，它在`deploy`階段運行. * 我們將`environment`設置為`environment` `environment:name`作為`review/$CI_COMMIT_REF_NAME` . 由于[環境名稱](../yaml/README.html#environmentname)可以包含斜杠（ `/` ），因此我們可以使用此模式來區分動態環境和常規環境. * We tell the job to run [`only`](../yaml/README.html#onlyexcept-basic) on branches, [`except`](../yaml/README.html#onlyexcept-basic) `master`. 對于以下值： * `environment:name` ，第一部分是`review` ，后跟一個`/` ，然后是`$CI_COMMIT_REF_NAME` ，它接收分支名稱的值. * `environment:url` ，我們希望每個分支都有一個特定且不同的 URL. `$CI_COMMIT_REF_NAME`可能包含`/`或其他在域名或 URL 中無效的字符，因此我們使用`$CI_ENVIRONMENT_SLUG`來確保獲得有效的 URL. 例如，給定`$CI_COMMIT_REF_NAME`為`100-Do-The-Thing` ，URL 將類似于`https://100-do-the-4f99a2.example.com` . 同樣，設置 Web 服務器來滿足這些請求的方式取決于您的設置. 我們在這里使用了`$CI_ENVIRONMENT_SLUG` ，因為它保證是唯一的. 如果您使用的是[GitLab Flow 之](../../topics/gitlab_flow.html)類的工作[流程](../../topics/gitlab_flow.html) ，則沖突不太可能發生，并且您可能更希望環境名稱與分支名稱更緊密地[關聯](../../topics/gitlab_flow.html) . 在這種情況下，您可以在上面的示例中的`environment:url`中使用`$CI_COMMIT_REF_NAME` ： `https://$CI_COMMIT_REF_NAME.example.com` ，其 URL 為`https://100-do-the-thing.example.com` . **注意：**您不需要在動態環境的名稱中使用相同的前綴或僅使用斜杠（ `/` ）. 但是，使用此格式將啟用[類似環境分組](#grouping-similar-environments)功能. ### Configuring Kubernetes deployments[](#configuring-kubernetes-deployments "Permalink") 在 GitLab 12.6 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/27630) . 如果要部署到與項目關聯的[Kubernetes 集群](../../user/project/clusters/index.html) ，則可以從`gitlab-ci.yml`文件配置這些部署. 支持以下配置選項： * [`namespace`](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) 在以下示例中，作業會將您的應用程序部署到`production` Kubernetes 命名空間. ``` deploy: stage: deploy script: - echo "Deploy to production server" environment: name: production url: https://example.com kubernetes: namespace: production only: - master ``` 使用 GitLab 的 Kubernetes 集成部署到 Kubernetes 集群時，有關集群和名稱空間的信息將顯示在部署作業頁面上的作業跟蹤上方： [](../img/environments_deployment_cluster_v12_8.png) **注意：** [由 GitLab 管理的](../../user/project/clusters/index.html#gitlab-managed-clusters) Kubernetes 集群不支持 Kubernetes 配置. 要跟蹤對 GitLab 管理的集群的支持進度，請參閱[相關問題](https://gitlab.com/gitlab-org/gitlab/-/issues/38054) . #### Configuring incremental rollouts[](#configuring-incremental-rollouts "Permalink") 了解如何通過[增量部署](../environments/incremental_rollouts.html)僅對 Kubernetes Pod 的一部分發布生產更改. ### Deployment safety[](#deployment-safety "Permalink") 部署作業可能比管道中的其他作業更敏感，并且可能需要格外小心. GitLab 中有多個功能可幫助維護部署安全性和穩定性. * [Restrict write-access to a critical environment](deployment_safety.html#restrict-write-access-to-a-critical-environment) * [Limit the job-concurrency for deployment jobs](deployment_safety.html#ensure-only-one-deployment-job-runs-at-a-time) * [Skip outdated deployment jobs](deployment_safety.html#skip-outdated-deployment-jobs) * [Prevent deployments during deploy freeze windows](deployment_safety.html#prevent-deployments-during-deploy-freeze-windows) ### Complete example[](#complete-example "Permalink") 本節中的配置提供了完整的開發工作流程，其中您的應用程序是： * Tested. * Built. * 部署為 Review App. * 合并請求合并后，部署到登臺服務器. * 最后，能夠手動部署到生產服務器. 以下內容結合了之前的配置示例，包括： * Defining [simple environments](#defining-environments) for testing, building, and deployment to staging. * 添加[手動操作](#configuring-manual-deployments)以部署到生產中. * 為部署創建[動態環境](#configuring-dynamic-environments)以供查看. ``` stages: - test - build - deploy test: stage: test script: echo "Running tests" build: stage: build script: echo "Building the app" deploy_review: stage: deploy script: - echo "Deploy a review app" environment: name: review/$CI_COMMIT_REF_NAME url: https://$CI_ENVIRONMENT_SLUG.example.com only: - branches except: - master deploy_staging: stage: deploy script: - echo "Deploy to staging server" environment: name: staging url: https://staging.example.com only: - master deploy_prod: stage: deploy script: - echo "Deploy to production server" environment: name: production url: https://example.com when: manual only: - master ``` 一個更現實的示例還包括將文件復制到 Web 服務器（例如 NGINX）可以訪問并為其提供服務的位置. 下面的示例將`public`目錄復制到`/srv/nginx/$CI_COMMIT_REF_SLUG/public` ： ``` review_app: stage: deploy script: - rsync -av --delete public /srv/nginx/$CI_COMMIT_REF_SLUG environment: name: review/$CI_COMMIT_REF_NAME url: https://$CI_COMMIT_REF_SLUG.example.com ``` 此示例要求在要運行此作業的服務器上設置 NGINX 和 GitLab Runner. **注意：**有關分支機構和 Review Apps 命名的一些極端情況，請參閱" [限制"](#limitations)部分. 完整的示例為開發人員提供了以下工作流程： * 在本地創建分支. * 進行更改并提交. * 將分支推送到 GitLab. * 創建一個合并請求. 在后臺，GitLab Runner 將： * 拾取更改并開始運行作業. * 按`stages`定義順序運行作業： * 首先，運行測試. * 如果測試成功，請構建應用程序. * 如果構建成功，則將應用程序部署到具有特定于分支機構名稱的環境. 所以現在，每個分支： * 獲取自己的環境. * 已部署到其自己的唯一位置，具有以下優點： * 有[部署歷史](#viewing-deployment-history) . * 如果需要，能夠[回滾更改](#retrying-and-rolling-back) . 有關更多信息，請參見[使用環境 URL](#using-the-environment-url) . ### Protected environments[](#protected-environments "Permalink") 可以對環境進行"保護"，限制對它們的訪問. 有關更多信息，請參閱[受保護的環境](protected_environments.html) . ## Working with environments[](#working-with-environments "Permalink") 配置環境后，GitLab 將提供許多用于處理環境的功能，如下所述. ### Viewing environments and deployments[](#viewing-environments-and-deployments "Permalink") 每個項目的" **操作">"環境"**頁面上都提供了環境和部署狀態的列表. 例如： [](../img/environments_available.png) 此示例顯示： * 環境名稱以及指向其部署的鏈接. * 最后的部署 ID 號以及執行者. * 上次部署的作業 ID 及其各自的作業名稱. * 上次部署的提交信息，例如誰提交了它，到哪個分支以及提交的 Git SHA. * 上次部署的確切時間. * 該按鈕`.gitlab-ci.yml`您帶到您在`.gitlab-ci.yml`的`environment`關鍵字下定義的 URL. * 重新部署最新部署的按鈕，這意味著它將運行由環境名稱定義的特定提交的作業. " **環境"**頁面中顯示的信息僅限于最新的部署，但是一個環境可以具有多個部署. > **Notes:** > > * 雖然您可以在 Web 界面中手動創建環境，但建議您首先在`.gitlab-ci.yml`定義環境. 首次部署后，將自動為您創建它們. > * 只有具有[Reporter 權限](../../user/permissions.html#project-members-permissions)及以上[權限](../../user/permissions.html#project-members-permissions)的用戶才能查看環境頁面. 有關權限的更多信息，請參閱[權限文檔](../../user/permissions.html) . > * 只有在正確配置`.gitlab-ci.yml`之后發生的部署才會顯示在" **環境"**和" **最后部署"**列表中. ### Viewing deployment history[](#viewing-deployment-history "Permalink") GitLab keeps track of your deployments, so you: * 始終知道服務器上當前正在部署什么. * 可以具有每種環境的完整部署歷史記錄. 單擊環境可顯示其部署的歷史記錄. 這是具有多個部署的**環境**示例頁面： [](../img/deployments_view.png) 該視圖類似于" **環境"**頁面，但是顯示了所有部署. 在此視圖中，還有一個" **回滾"**按鈕. 有關更多信息，請參閱[重試和回滾](#retrying-and-rolling-back) . ### Retrying and rolling back[](#retrying-and-rolling-back "Permalink") 如果部署存在問題，則可以重試或回滾. 要重試或回滾部署： 1. 導航到" **操作">"環境"** . 2. 單擊環境. 3. 在環境的部署歷史記錄列表中，單擊： * 最后部署旁邊的" **重試"**按鈕，以重試該部署. * 先前成功部署旁邊的" **回滾"**按鈕，以回滾到該部署. #### What to expect with a rollback[](#what-to-expect-with-a-rollback "Permalink") 在特定提交上按**回滾**按鈕將觸發具有其自己的唯一作業 ID 的*新*部署. 這意味著您將看到一個新的部署，該部署指向您要回滾的提交. **注意：**作業`script`定義的部署過程確定回滾是否成功. ### Using the environment URL[](#using-the-environment-url "Permalink") [環境 URL](../yaml/README.html#environmenturl)在 GitLab 中的幾個位置公開： * 在合并請求小部件中作為鏈接： [](../img/environments_mr_review_app.png) * 在"環境"視圖中作為按鈕： [](../img/environments_available.png) * 在"部署"視圖中作為按鈕： [](../img/deployments_view.png) 在以下情況下，您可以在合并請求本身中看到此信息： * 合并請求最終合并到默認分支（通常是`master` ）. * 該分支還部署到環境（例如， `staging`或`production` ）. 例如： [](../img/environments_link_url_mr.png) #### Going from source files to public pages[](#going-from-source-files-to-public-pages "Permalink") 使用 GitLab 的[路線圖，](../review_apps/index.html#route-maps)您可以在為 Review Apps 設置的環境中直接從源文件轉到公共頁面. ### Stopping an environment[](#stopping-an-environment "Permalink") 停止環境： * 將其從" **可用"**環境列表移至" [**環境"**頁面](#viewing-environments-and-deployments)上的"已**停止"**環境列表. * 執行[`on_stop`操作](../yaml/README.html#environmenton_stop) （如果已定義）. 當多個開發人員同時在一個項目上工作時，通常會使用此方法，每個開發人員都將推入自己的分支，從而創建了許多動態環境. **注意：**從 GitLab 8.14 開始，刪除動態環境的關聯分支后，它們會自動停止. #### Automatically stopping an environment[](#automatically-stopping-an-environment "Permalink") 可以使用特殊配置自動停止環境. 考慮以下示例，其中`deploy_review`作業調用`stop_review`清理并停止環境： ``` deploy_review: stage: deploy script: - echo "Deploy a review app" environment: name: review/$CI_COMMIT_REF_NAME url: https://$CI_ENVIRONMENT_SLUG.example.com on_stop: stop_review only: - branches except: - master stop_review: stage: deploy variables: GIT_STRATEGY: none script: - echo "Remove review app" when: manual environment: name: review/$CI_COMMIT_REF_NAME action: stop ``` 設置[`GIT_STRATEGY`](../yaml/README.html#git-strategy)到`none`是必要的`stop_review`使各項工作[GitLab 亞軍](https://docs.gitlab.com/runner/)不會嘗試分支被刪除后退房的代碼. 當您的環境中定義了停止動作時（通常在該環境描述了 Review App 時），當關聯的分支被刪除時，GitLab 將自動觸發停止動作. `stop_review`作業必須與`deploy_review`作業處于同一`stage` ，以便環境自動停止. 此外，兩個作業都應具有匹配的[`rules`](../yaml/README.html#onlyexcept-basic)或[`only/except`](../yaml/README.html#onlyexcept-basic)配置[`only/except`](../yaml/README.html#onlyexcept-basic) . 在上面的示例中，如果配置不同，則`stop_review`作業可能不會包含在所有包含`deploy_review`作業的管道中，并且將無法觸發該`action: stop`會自動停止環境. 您可以在[`.gitlab-ci.yml`參考中](../yaml/README.html#environmenton_stop)閱讀更多[`.gitlab-ci.yml`](../yaml/README.html#environmenton_stop) . #### Environments auto-stop[](#environments-auto-stop "Permalink") 在 GitLab 12.8 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/20956) . 您可以設置環境的到期時間，并在一定時間后自動將其停止. 例如，考慮在 Review Apps 環境中使用此功能. 設置 Review Apps 時，有時它們會長時間運行，因為某些合并請求處于打開狀態. 這種情況的一個示例是，由于優先級更改或決定采用其他方法而導致合并請求的作者未積極處理合并請求，而合并請求卻被遺忘了. 空閑環境會浪費資源，因此應盡快終止它們. 要解決此問題，您可以為 Review Apps 環境指定一個可選的到期日期. 當達到到期時間時，GitLab 將自動觸發作業以停止環境，而無需手動執行此操作. 萬一更新了環境，則到期將得到更新，以確保只有活動的合并請求才能繼續運行 Review Apps. 要啟用此功能，您需要在`.gitlab-ci.yml`指定[`environment:auto_stop_in`](../yaml/README.html#environmentauto_stop_in)關鍵字. 您可以指定一個對人類友好的日期作為值，例如`1 hour and 30 minutes`或`1 day` . `auto_stop_in`使用相同的[`artifacts:expire_in`](../yaml/README.html#artifactsexpire_in)格式[`artifacts:expire_in` docs](../yaml/README.html#artifactsexpire_in) . **注意：**由于資源限制，用于停止環境的后臺工作器每小時僅運行一次. 這意味著不會按指定的確切時間在特定的時間戳記下停止環境，而是在每小時的 cron 工作者檢測到過期的環境時將其停止. ##### Auto-stop example[](#auto-stop-example "Permalink") 在以下示例中，有一個基本的審閱應用程序設置，可為每個合并請求創建一個新環境. 每次推送都會觸發`review_app`作業，并創建或更新一個名為`review/your-branch-name` . 環境一直運行，直到執行`stop_review_app` ： ``` review_app: script: deploy-review-app environment: name: review/$CI_COMMIT_REF_NAME on_stop: stop_review_app auto_stop_in: 1 week stop_review_app: script: stop-review-app environment: name: review/$CI_COMMIT_REF_NAME action: stop when: manual ``` 只要合并請求處于活動狀態并不斷獲得新的提交，審閱應用程序就不會停止，因此開發人員無需擔心重新啟動審閱應用程序. 另一方面，由于將`stop_review_app`設置為`auto_stop_in: 1 week` ，如果合并請求變得不活動超過一個星期，則 G??itLab 會自動觸發`stop_review_app`作業以停止環境. 您還可以通過 GitLab UI 檢查環境的到期日期. 為此，請轉到**操作>環境>環境** . 您可以在左上部分看到自動停止時間，并在右上部分看到一個記號按鈕. 此固定標記按鈕可用于防止環境自動停止. 單擊此按鈕，將`auto_stop_in`設置，并且環境將處于活動狀態，直到手動將其停止為止. [](../img/environment_auto_stop_v12_8.png) #### Delete a stopped environment[](#delete-a-stopped-environment "Permalink") 在 GitLab 12.10 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/20620) . 您可以通過以下兩種方式之一刪除已[停止的環境](#stopping-an-environment) ：通過 GitLab UI 或通過 API. ##### Delete environments through the UI[](#delete-environments-through-the-ui "Permalink") 要查看已**停止**環境的列表，請導航至" **操作">"環境"** ，然后單擊"已**停止"**選項卡. 在此處，您可以直接單擊" **刪除"**按鈕，也可以單擊環境名稱以查看其詳細信息，然后從此處**刪除**它. 您還可以通過查看已停止環境的詳細信息來刪除環境： 1. 導航到" **操作">"環境"** . 2. 在"已**停止的**環境"列表中單擊環境的名稱. 3. 單擊顯示在所有已停止環境頂部的" **刪除"**按鈕. 4. 最后，在似乎要刪除它的模式中確認您選擇的環境. ##### Delete environments through the API[](#delete-environments-through-the-api "Permalink") 也可以使用[Environments API](../../api/environments.html#delete-an-environment)刪除[環境](../../api/environments.html#delete-an-environment) . ### Prepare an environment[](#prepare-an-environment "Permalink") 在 GitLab 13.2 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/208655) . 默認情況下，每次運行具有指定環境的構建時，GitLab 都會創建一個[部署](#viewing-deployment-history) . 較新的部署也可以[取消較舊的](deployment_safety.html#skip-outdated-deployment-jobs)部署. 您可能需要指定一個環境關鍵字來[保護構建免受未經授權的訪問](protected_environments.html) ，或獲得對[范圍變量的](#scoping-environments-with-specs)訪問. 在這些情況下，可以使用以下`action: prepare`關鍵字以確保不會創建部署，并且不會取消任何構建： ``` build: stage: build script: - echo "Building the app" environment: name: staging action: prepare url: https://staging.example.com ``` ### Grouping similar environments[](#grouping-similar-environments "Permalink") 在 GitLab 8.14 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/7015) . 如[配置動態環境中所述](#configuring-dynamic-environments) ，您可以在環境名稱前添加一個單詞，后跟一個`/` ，最后是分支名稱，該分支名稱由`CI_COMMIT_REF_NAME`變量自動定義. 簡而言之，所有名為`type/foo`的環境都在同一個名為`type`組下顯示. 在[最小的示例中](#example-configuration) ，我們將環境命名為`review/$CI_COMMIT_REF_NAME` ，其中`$CI_COMMIT_REF_NAME`是分支名稱. 這是示例的片段： ``` deploy_review: stage: deploy script: - echo "Deploy a review app" environment: name: review/$CI_COMMIT_REF_NAME ``` 在這種情況下，如果您訪問" **環境"**頁面并且分支存在，則應該看到類似以下內容的內容： [](../img/environments_dynamic_groups.png) ### Monitoring environments[](#monitoring-environments "Permalink") 如果已啟用[Prometheus 來監視系統和響應指標](../../user/project/integrations/prometheus.html) ，則可以監視在每個環境中運行的應用程序的行為. 為了顯示監視儀表板，您需要配置 Prometheus 來收集至少一個[支持的指標](../../user/project/integrations/prometheus_library/index.html) . **注意：**從 GitLab 9.2 開始，到環境的所有部署都直接顯示在監視儀表板上. 配置完成后，GitLab 將嘗試為成功部署的任何環境檢索[支持的性能指標](../../user/project/integrations/prometheus_library/index.html) . 如果成功檢索到監視數據，則將為每個環境顯示一個" **監視"**按鈕. [](../img/deployments_view.png) 單擊" **監視"**按鈕將顯示一個新頁面，該頁面最多顯示最近 8 個小時的性能數據. 初始部署后，可能需要一兩分鐘的時間才能顯示數據. 環境的所有部署都直接顯示在監視儀表板上，這使性能的任何變化與應用程序的新版本之間都可以輕松關聯，而無需離開 GitLab. [](../img/environments_monitoring.png) #### Embedding metrics in GitLab Flavored Markdown[](#embedding-metrics-in-gitlab-flavored-markdown "Permalink") 公制圖表可以嵌入到 GitLab Flavored Markdown 中. 有關更多詳細信息，請參見[在 GitLab 風味 Markdown 中嵌入指標](../../operations/metrics/embed.html) . ### Web terminals[](#web-terminals "Permalink") > Web 終端已在 GitLab 8.15 中添加，僅對項目維護者和所有者可用. If you deploy to your environments with the help of a deployment service (for example, the [Kubernetes integration](../../user/project/clusters/index.html)), GitLab can open a terminal session to your environment. 這是一項功能強大的功能，可讓您調試問題而不會離開 Web 瀏覽器. 要啟用它，只需按照服務集成文檔中給出的說明進行操作. 啟用后，您的環境將獲得一個"終端"按鈕： [](../img/environments_terminal_button_on_index.png) 您還可以從頁面訪問特定環境的終端按鈕： [](../img/environments_terminal_button_on_show.png) 無論在哪里找到它，單擊按鈕都會帶您到單獨的頁面來建立終端會話： [](../img/environments_terminal_page.png) 就像其他終端一樣工作. 您將處于部署創建的容器中，因此您可以： * 運行 shell 命令并實時獲取響應. * 檢查日志. * 試用配置或代碼調整等. 您可以在同一環境中打開多個終端，它們每個都有自己的 shell 會話，甚至可以是`screen`或`tmux`的多路復用器. **注意：**基于容器的部署通常缺少基本工具（例如編輯器），并且可以隨時停止或重新啟動. 如果發生這種情況，您將丟失所有更改. 將此視為調試工具，而不是全面的在線 IDE. ### Check out deployments locally[](#check-out-deployments-locally "Permalink") 從 GitLab 8.13 開始，每次部署都會在 Git 存儲庫中保存一個引用，因此僅需`git fetch`知道當前環境的狀態. In your Git configuration, append the `[remote "<your-remote>"]` block with an extra fetch line: ``` fetch = +refs/environments/*:refs/remotes/origin/environments/* ``` ### Scoping environments with specs[](#scoping-environments-with-specs "Permalink") 版本歷史 * 在[GitLab Premium](https://about.gitlab.com/pricing/) 9.4 中[引入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/2112) . * 在 GitLab 12.2 中將[環境變量的作用域移至 Core](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/30779) . 您可以通過定義變量可用于的環境來限制變量的環境范圍. 可以使用通配符，默認環境范圍是`*` ，這意味著任何作業都將具有此變量，與是否定義環境無關. 例如，如果環境范圍是`production` ，那么只有定義了環境`production`的作業才具有此特定變量. 通配符（ `*` ）可以與環境名稱一起使用，因此，如果環境范圍是`review/*`那么任何以環境名稱以`review/`開頭的作業都將具有該特定變量. 對于每個環境，某些 GitLab 功能可能會有不同的行為. 例如，您可以[創建一個秘密變量，僅將其注入生產環境](../variables/README.html#limit-the-environment-scopes-of-environment-variables) . 在大多數情況下，這些功能使用*環境規范*機制，該機制提供了一種在每個環境組內實現作用域的有效方法. 假設有四種環境： * `production` * `staging` * `review/feature-1` * `review/feature-2` Each environment can be matched with the following environment spec: | 環境規格 | `production` | `staging` | `review/feature-1` | `review/feature-2` | | --- | --- | --- | --- | --- | | * | Matched | Matched | Matched | Matched | | production | Matched | ? | ? | ? | | staging | ? | Matched | ? | ? | | review/* | ? | ? | Matched | Matched | | review/feature-1 | ? | ? | Matched | ? | 如您所見，您可以使用特定的匹配來選擇特定的環境，也可以使用通配符匹配（ `*` ）來選擇特定的環境組，例如[Review Apps](../review_apps/index.html) （ `review/*` ）. **注意：**最*具體的*規范優先于其他通配符匹配. 在這種情況下， `review/feature-1`規范優先于`review/*`和`*`規范. ### Environments Dashboard[](#environments-dashboard-premium "Permalink") 有關每個環境的運行狀況的摘要，請參見[環境儀表板](../environments/environments_dashboard.html) . ## Limitations[](#limitations "Permalink") 在`environment: name` ，您僅限于[預定義的環境變量](../variables/predefined_variables.html) . 重用`script`內部定義為環境名稱一部分的變量將不起作用. ## Further reading[](#further-reading "Permalink") 以下是一些您可能會發現有趣的鏈接： * [The `.gitlab-ci.yml` definition of environments](../yaml/README.html#environment) * [A blog post on Deployments & Environments](https://about.gitlab.com/blog/2016/08/26/ci-deployment-and-environments/) * [Review Apps - Use dynamic environments to deploy your code for every branch](../review_apps/index.html) * [Deploy Boards for your applications running on Kubernetes](../../user/project/deploy_boards.html)