本頁面由 Cloud Translation API 翻譯而成。

設定結構定義參照

Cloud Deploy 設定檔會定義交付管道、要部署的目標，以及這些目標的進度。

交付管道設定檔可以包含目標定義，也可以位於個別檔案中。按照慣例，同時包含推送 pipeline 設定和目標設定的檔案稱為 clouddeploy.yaml，不含目標的 pipeline 設定則稱為 delivery-pipeline.yaml。但您可以隨意命名這些檔案。其他資源定義 (例如自動化和部署政策) 也可以與傳送管道或目標定義位於同一個檔案中。

瞭解使用方式

Cloud Deploy 主要使用兩個設定檔：

推送管道定義
目標定義

這些可以是個別檔案，也可以在同一個檔案中設定傳送管道和目標。

推送管道設定檔的結構

以下是推送管道設定的結構，包括目標定義的屬性。部分目標屬性未列在此。如要瞭解所有目標設定屬性，請參閱目標定義。

# Delivery pipeline config
apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
 name:
 annotations:
 labels:
description:
suspended:
serialPipeline:
 stages:
 - targetId:
   profiles: []
# Deployment strategies
# One of:
#   standard:
#   canary:
# See the strategy section in this document for details.
   strategy:
     standard:
       verify:
       predeploy:
         actions: []
       postdeploy:
         actions: []
   deployParameters:
   - values:
     matchTargetLabels:
 - targetId:
   profiles: []
   strategy:
   deployParameters:
---

# Target config
apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
 name:
 annotations:
 labels:
description:
multiTarget:
 targetIds: []
deployParameters:
requireApproval:
#
# Runtimes
# one of the following runtimes:
gke:
 cluster:
 dnsEndpoint:
 internalIp:
 proxyUrl:
#
# or:
anthosCluster:
 membership:
#
# or:
run:
 location:
#
# or:
customTarget:
  customTargetType:
#
# (End runtimes. See documentation in this article for more details.)
#
executionConfigs:
- usages:
  - [RENDER | PREDEPLOY | DEPLOY | VERIFY | POSTDEPLOY]
  workerPool:
  serviceAccount:
  artifactStorage:
  executionTimeout:
  verbose:
---

# Custom target type config
apiVersion: deploy.cloud.google.com/v1
kind: CustomTargetType
metadata:
  name:
  annotations:
  labels:
description:
customActions:
  renderAction:
  deployAction:
  includeSkaffoldModules:
    - configs:
    # either:
    googleCloudStorage:
      source:
      path:
    # or:
    git:
      repo:
      path:
      ref:
---

# Automation config
apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
  name:
  labels:
  annotations:
description:
suspended:
serviceAccount:
selector:
  targets:
    -  id: [TARGET_ID]
       labels:
         [LABEL_KEY]:[LABEL_VALUE]
rules:
- [RULE_TYPE]:
  id:
  [RULE-SPECIFIC_CONFIG]

這個 YAML 包含三個主要元件：

主要推送管道和進度

設定檔可包含任意數量的管道定義。
目標定義

為求簡潔，本範例只顯示一個目標，但目標數量不限。此外，目標也可以在個別檔案中定義。
自訂目標類型定義

自訂目標需要自訂目標類型定義。與目標和自動化功能一樣，自訂目標類型可以在與放送管道相同或不同的檔案中定義。
自動化定義

您可以在與發布管道和目標相同的檔案中，或在個別檔案中，建立任何部署自動化程序。為求簡單，這裡只顯示一個 Automation，但您可以視需要建立任意數量的 Automation。

本文件其他部分會定義這些元件。

管道定義和進展

除了管道中繼資料 (例如 name)，主要管道定義還包含部署順序中目標的參照清單。也就是說，列出的第一個目標是第一個部署目標。部署至該目標後，推送版本會部署至清單中的下一個目標。

以下是放送管道的設定屬性，不包括目標定義。

`metadata.name`

name 欄位會採用字串，且每個專案和位置都不得重複。

`metadata.annotations` 和 `metadata.labels`

推送管道設定可以包含註解和標籤。管道註冊後，註解和標籤會與傳送管道資源一併儲存。

詳情請參閱「使用 Cloud Deploy 的標籤和註解」。

`description`

說明這個推送管道的任意字串。這個說明會顯示在 Google Cloud 控制台的推送管道詳細資料中。

`suspended`

布林值，如果為 true，則暫停發布管道，因此無法用於建立、宣傳、復原或重新部署發布內容。此外，如果推送管道已停用，您就無法核准或拒絕透過該管道建立的推出作業。

預設為 false。

`serialPipeline`

定義連續推送管道的開頭。這是必要節。

`stages`

這份清單內含已設定這個推送管道要部署的所有目標。

清單必須按照你希望的傳送順序排列。舉例來說，如果您有 dev、staging 和 production 這三個目標，請依序列出，這樣第一次部署就會到 dev，最後一次部署則會到 production。

將每個 stages.targetId 欄位填入對應目標定義中的 metadata.name 欄位值。在「targetId」下方，請加入以下內容： profiles

serialPipeline:
 stages:
 - targetId:
   profiles: []
   strategy:
     standard:
       verify:

`targetId`

識別要用於推送管道這個階段的特定目標。這個值是目標定義中的 metadata.name 屬性。

設為 true 可在目標上啟用部署驗證。strategy.standard.verify如果未指定部署策略，系統會使用 standard 部署策略，並將驗證設為 false。

`profiles`

從 skaffold.yaml 中取得零或多個 Skaffold 設定檔名稱的清單。 Cloud Deploy 會在建立版本時使用 skaffold render 設定檔。使用單一設定檔時，Skaffold 設定檔可讓您在目標之間變更設定。

`strategy`

包括用於指定部署策略的屬性。系統支援下列策略：

standard:

應用程式會完整部署至指定目標。

這是預設部署策略。如果省略 strategy，Cloud Deploy 會使用 standard 部署策略。
canary:

在初期測試部署中，您會逐步部署應用程式的新版本，並以百分比為增量，取代已執行的版本 (例如 25%、50%、75%，然後完全取代)。

部署策略是依目標定義，舉例來說，您可能為 prod 目標採用 Canary 策略，但為其他目標採用標準策略 (未指定 strategy)。

詳情請參閱「使用部署策略」。

`strategy` 設定

本節會針對每個支援的執行階段，顯示 strategy 的設定元素。

標準部署策略

標準策略只包含下列元素：

strategy:
  standard:
    verify: true|false

verify 屬性為選用項目。預設值為 false，表示產生的推出作業不會有驗證階段。

如果是標準部署策略，則可以省略 strategy 元素。

初期測試部署策略

以下各節說明如何為 Cloud Deploy 支援的每個執行階段，設定灰度發布策略。

針對 Cloud Run 目標

strategy:
  canary:
    runtimeConfig:
      cloudRun:
        automaticTrafficControl: true | false
    canaryDeployment:
      percentages: [PERCENTAGES]
      verify: true | false

如果是 Cloud Run 目標，AutomaticTrafficControl 必須是 true，除非您要設定自訂 Canary 版本。

適用於 GKE 和 GKE Enterprise 目標

下列 YAML 顯示如何使用以服務為基礎的網路，為 GKE 或 GKE Enterprise 目標設定部署策略：

      canary:
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
              disablePodOverprovisioning: true | false
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true | false

下列 YAML 顯示如何使用 Gateway API，為 GKE 或 GKE Enterprise 目標設定部署策略：

      canary:
        runtimeConfig:
          kubernetes:
            gatewayServiceMesh:
              httpRoute: "HTTP_ROUTE_NAME"
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
              routeUpdateWaitTime: "WAIT_TIME"
              routeDestinations:
                destinationIds: ["KEY"]
                propagateService: [true|false]
        canaryDeployment:
          percentages: ["PERCENTAGES"]
          verify: true | false

請注意，在本例中，routeUpdateWaitTime 這是因為 Gateway API 會使用 HTTPRoute 資源分割流量，有時傳播對 HTTPRoute 所做變更時會發生延遲。在這種情況下，要求可能會遭到捨棄，因為流量會傳送至無法使用的資源。如果發現有這類延遲，可以使用 routeUpdateWaitTime 讓 Cloud Deploy 在套用 HTTPRoute 變更後等待。

下列 YAML 顯示如何設定自訂 Canary 部署策略 (適用於服務網路、Gateway API 或 Cloud Run)，或自訂自動 Canary 部署策略 (適用於服務網路、Gateway API 或 Cloud Run)。自訂初期測試會省略 runtimeConfig 部分的執行階段專屬設定，但自動和自訂自動初期測試設定會納入這類設定。

自訂 Canary 設定

strategy:
       canary:
         # Runtime configs are configured as shown in the
         # Canary Deployment Strategy section of this document.
         runtimeConfig:

         # Manual configuration for each canary phase
         customCanaryDeployment:
           - name: "PHASE1_NAME"
             percent: PERCENTAGE1
             profiles: [ "PROFILE1_NAME" ]
             verify: true | false
           - …
           - name: "stable"
             percent: 100
             profiles: [ "LAST_PROFILE_NAME" ]
             verify: true|false

`verify`

選用布林值，指出是否支援這個目標的部署作業驗證。預設值為 false。

啟用部署驗證時，skaffold.yaml 中也需要 verify 節。如果未提供這項屬性，驗證工作就會失敗。

`deployParameters`

使用部署參數時，可指定鍵/值組合，將值傳遞至符合標籤目標的資訊清單。

您也可以在目標中加入這項設定。

在推送管道上設定的部署作業參數會使用標籤來比對目標：

deployParameters:
- values:
    someKey: "value1"
  matchTargetLabels:
    label1: firstLabel
- values:
    someKey: "value2"
  matchTargetLabels:
    label2: secondLabel

在本例中，鍵有兩個值，且每個值都有標籤。如果目標有相符的標籤，系統就會將這個值套用至該目標的資訊清單。

「`predeploy`」和「`postdeploy`」工作

您可藉此參照個別定義的自訂動作 (位於 skaffold.yaml 中)，在部署作業 (predeploy) 之前和驗證作業 (如有) 之後執行。如果沒有驗證作業，則會在部署作業後執行後續部署作業。postdeploy

部署掛鉤會在 strategy.standard 或 strategy.canary 下方設定，如下所示：

serialPipeline:
  stages:
  - targetId:
    strategy:
      standard:
        predeploy:
          actions: [ACTION_NAME]
        postdeploy:
          actions: [ACTION_NAME]

其中 ACTION_NAME 是在 skaffold.yaml 中為 customActions.name 設定的名稱。

您可以在任何策略 (例如 standard、canary) 下設定 predeploy 和 postdeploy 工作。

如要進一步瞭解如何設定及使用部署前和部署後掛鉤，請參閱「在部署前後執行掛鉤」。

目標定義

傳送管道定義檔可以包含目標定義，您也可以在個別檔案中指定目標。

您可以在多個發布管道之間重複使用目標。不過，您只能在單一推送管道的進度中參照目標一次。

另請參閱：自訂目標類型定義

適用於 GKE 目標

下列 YAML 顯示如何設定部署至 GKE 叢集的目標：

     apiVersion: deploy.cloud.google.com/v1
     kind: Target
     metadata:
      name:
      annotations:
      labels:
     description:
     deployParameters:
     multiTarget:
      targetIds: []

     requireApproval:
     gke:
      cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]
      dnsEndpoint:
      internalIp:
      proxyUrl:

     associatedEntities:
       [KEY]:
         gkeClusters:
         - cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]
           dnsEndpoint: [true|false]
           internalIp: [true|false]
           proxyUrl:

     executionConfigs:
     - usages:
       - [RENDER | PREDEPLOY | DEPLOY | VERIFY | POSTDEPLOY]
       workerPool:
       serviceAccount:
       artifactStorage:
       executionTimeout:
       verbose:

`metadata.name`

這個目標的名稱。每個區域的名稱不得重複。

`metadata.annotations` 和 `metadata.labels`

目標設定支援 Kubernetes 註解和標籤，但 Cloud Deploy 並未強制要求。

註解和標籤會與目標資源一併儲存。詳情請參閱搭配 Cloud Deploy 使用標籤和註解。

`description`

這個欄位會採用任意字串，說明這個目標的用途。

`deployParameters`

您可以在任何目標上加入部署參數和值。這些值會在算繪後，指派給資訊清單中的對應鍵。

deployParameters 節會採用鍵/值組合，如下所示：

deployParameters:
  someKey: "someValue"
  someOtherKey: "someOtherValue"

如果您在多重目標上設定部署參數，系統會將值指派給所有多重目標的子目標資訊清單。

`multiTarget.targetIds: []`

這個屬性為選用屬性，用於設定多重目標，以進行平行部署。

值是以半形逗號分隔的子目標清單。子項目標會設定為一般目標，且不包含這項 multiTarget 屬性。

`requireApproval`

是否需要手動核准才能推送至這個目標。可以是 true 或 false。

這是選用屬性。預設為 false。

設定平行部署時，您只需要在多重目標上要求核准，不必在子目標上要求核准。

`gke`

僅適用於 GKE 叢集，用於識別應用程式部署位置的叢集資源路徑：

gke:
  cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]

project_name

叢集所在的 Google Cloud 專案。
location

叢集所在位置。例如，us-central1。叢集也可以是區域叢集 (us-central1-c)。
cluster_name

叢集名稱，與Google Cloud 控制台的叢集清單中顯示的名稱相同。

範例如下：

gke:
  cluster: projects/cd-demo-01/locations/us-central1/clusters/prod

設定多目標時，請省略 gke 屬性。GKE 叢集改為在對應的子目標中設定。

如需執行環境屬性的說明，請參閱本文中的executionConfigs。如要瞭解如何將 HTTPRoute 部署至替代的非目標叢集，請參閱將 HTTPRoute 部署至其他叢集。

`dnsEndpoint`

設為 true 時，Cloud Deploy 會使用 DNS 端點連線至 GKE 叢集，而非預設端點 (可能是公開 IP、私人 IP 或 DNS 端點，視叢集設定而定)。

這個選項無法與 internalIp 選項同時使用。

`internalIp`

設為 true 時，Cloud Deploy 會使用私人 IP 位址連線至 GKE 叢集，而非預設端點 (可能是公開 IP、私人 IP 或 DNS 端點，視叢集設定而定)。

這個選項無法與 dnsEndpoint 選項同時使用。因為 dnsEndpoint 的網路設定簡單許多，我們建議改用這個方法。

`proxyUrl`

如果您透過 HTTP Proxy 存取叢集，請在此提供 proxyUrl 屬性。這個值是 Proxy 的網址，連線至叢集時會傳遞至 kubectl。

針對 Cloud Run 目標

下列 YAML 顯示如何設定部署至 Cloud Run 服務的目標：

     apiVersion: deploy.cloud.google.com/v1
     kind: Target
     metadata:
      name:
      annotations:
      labels:
     description:
     multiTarget:
      targetIds: []

     requireApproval:
     run:
      location: projects/[project_name]/locations/[location]

     executionConfigs:
     - usages:
       - [RENDER | PREDEPLOY|  DEPLOY | VERIFY | POSTDEPLOY]
       workerPool:
       serviceAccount:
       artifactStorage:
       executionTimeout:
       verbose:

`metadata.name`

這個目標的名稱。每個區域的名稱不得重複。

`metadata.annotations` 和 `metadata.labels`

目標設定支援註解和標籤，但 Cloud Deploy 並不要求這些項目。

註解和標籤會與目標資源一併儲存。詳情請參閱搭配 Cloud Deploy 使用標籤和註解。

`description`

這個欄位會採用任意字串，說明這個目標的用途。

`multiTarget.targetIds: []`

這個屬性為選用屬性，用於設定多重目標，以進行平行部署。

值是以半形逗號分隔的子目標清單。子項目標會設定為一般目標，且不包含這項 multiTarget 屬性。

`requireApproval`

是否需要手動核准才能推送至這個目標。可以是 true 或 false。

這是選用屬性。預設為 false。

設定平行部署時，您只需要在多重目標上要求核准，不必在子目標上要求核准。

`run`

僅適用於 Cloud Run 服務，服務的建立位置：

run:
  location: projects/[project_name]/locations/[location]

project_name

服務所在的 Google Cloud 專案。
location

服務的所在位置。例如 us-central1。

設定 [多重目標]時，請省略 run 屬性。Cloud Run 服務的位置改為在對應的子項目標中設定。

如需執行環境屬性的說明，請參閱本文中的executionConfigs。

適用於 GKE Enterprise 目標

部署至 GKE 叢集的目標設定與GKE 目標的設定類似，但屬性為 anthosCluster.membership，而非 gke.cluster，資源路徑也不同，且不適用特定連線方法 (dnsEndpoint 或 internalIp)。

anthosCluster:
  membership: projects/[project_name]/locations/global/memberships/[membership_name]

project_name

GKE Enterprise 叢集所在的 Google Cloud 專案。
/location/global/

叢集的註冊位置。global，適用於所有情況。
membership_name

GKE Enterprise 叢集成員資格的名稱。

範例如下：

anthosCluster:
  membership: projects/cd-demo-01/locations/global/memberships/prod

設定 [多重目標]時，請省略 anthosCluster 屬性。GKE Enterprise 叢集改為在對應的子目標中設定。

如要進一步瞭解如何部署至 GKE 叢集，請參閱「部署至 Anthos 使用者叢集」。

自訂目標

自訂目標的設定與所有其他目標類型類似，但不會包含 gke 節、run 節或 anthosCluster 節。

自訂目標包含 customTarget 節：

customTarget:
  customTargetType: [CUSTOM_TARGET_TYPE_NAME]

其中 CUSTOM_TARGET_TYPE_NAME 是您在自訂目標類型定義中使用的名稱。

範例如下：

apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
  name: sample-env
customTarget:
  customTargetType: basic-custom-target

`executionConfigs`

一組欄位，用於指定這個目標的非預設執行環境。

usages

RENDER 或 DEPLOY，或兩者皆是，加上 PREDEPLOY、VERIFY 或 POSTDEPLOY (如果目標驗證或部署掛鉤已啟用)。這些值會指出要使用這個執行環境，對這個目標執行哪些作業。如要指出預先部署掛鉤、算繪、部署、後期部署掛鉤和驗證作業應使用自訂執行環境，請按照下列方式設定：
```
usages:
- RENDER
- PREDEPLOY
- DEPLOY
- VERIFY
- POSTDEPLOY
```
如果在管道階段啟用驗證，且您未在 usages 節中指定 VERIFY，Cloud Deploy 會使用預設執行環境進行驗證。前置部署和後置部署掛鉤的運作方式相同。

不過，如果 RENDER 和 DEPLOY 有自訂執行環境，則必須為 VERIFY、PREDEPLOY 或 POSTDEPLOY 指定執行環境 (如果這些環境已在推送管道中設定)。VERIFY、PREDEPLOY，而 POSTDEPLOY 可以與 RENDER 或 DEPLOY 位於同一個 usages，也可以位於不同的 usages。

除非 RENDER 和 DEPLOY 是在相同或個別的自訂執行環境中指定，否則無法指定 usages.VERIFY、usages.PREDEPLOY 或 usages.POSTDEPLOY。
workerPool

要使用的工作站集區設定。這會採用資源路徑，識別要用於這個目標的 Cloud Build worker 集區。例如：

projects/p123/locations/us-central1/workerPools/wp123。

如要使用預設的 Cloud Build 集區，請省略這個屬性。

指定目標可以有兩個 workerPool (一個用於 RENDER，另一個用於 DEPLOY)。設定預設集區時，您可以指定替代服務帳戶或儲存空間位置，也可以同時指定兩者。
serviceAccount

要用於這項作業的服務帳戶名稱 (RENDER 或 DEPLOY)，適用於這個目標。
artifactStorage

要用於這項作業的 Cloud Storage 值區 (RENDER 或 DEPLOY)，而非預設值區。
executionTimeout

(選用步驟) 設定 Cloud Build 為 Cloud Deploy 執行的作業逾時時間 (以秒為單位)。預設值為 3600 秒 (1 小時)。
範例：executionTimeout: "5000s"
verbose

(選用步驟) 如果 true，下列工具的詳細程度會設為 debug：
- Skaffold --verbosity 設為 debug。Skaffold 預設值為 warn。
- kubectl --v 已設為 4，這是偵錯。kubectl 預設值為 2。
- Google Cloud CLI --verbosity 設為 debug。預設值為 warning。

其他支援的語法

本文所述的 executionConfigs 設定為新設定。系統仍支援先前的語法：

executionConfigs:
- privatePool:
    workerPool:
    serviceAccount:
    artifactStorage:
  usages:
  - [RENDER | DEPLOY]
- defaultPool:
    serviceAccount:
    artifactStorage:
  usages:
  - [RENDER | DEPLOY]

設定多部署目標的 executionConfigs 節時，每個子目標都可以從該多部署目標繼承執行環境。

自訂目標類型定義

本節說明用於定義自訂目標類型的欄位。

與標準目標和自動化功能一樣，CustomTargetType 定義可以包含在放送管道定義中，也可以放在個別檔案中。

下列 YAML 顯示如何設定自訂目標類型：

apiVersion: deploy.cloud.google.com/v1
kind: CustomTargetType
metadata:
  name: [CUSTOM_TARGET_TYPE_NAME]
  annotations:
  labels:
description:
customActions:
  renderAction: [RENDER_ACTION_NAME]
  deployAction: [DEPLOY_ACTION_NAME]
  includeSkaffoldModules:
    - configs:
    # either:
    googleCloudStorage:
      source:
      path:
    # or:
    git:
      repo:
      path:
      ref:

其中：

[CUSTOM_TARGET_TYPE_NAME]

這是您為這個自訂目標類型定義指定的任意名稱。在任何使用您定義的自訂目標類型的目標中，都會參照這個名稱的目標定義。
[RENDER_ACTION_NAME]

是自訂算繪動作的名稱。這個值是 skaffold.yaml 中定義的 customAction.name。
[DEPLOY_ACTION_NAME]

是自訂部署動作的名稱。這個值是 skaffold.yaml 中定義的 customAction.name。
如要瞭解 includeSkaffoldModules，請參閱「使用遠端 Skaffold 設定」。

自動化定義

本節說明用於定義 Cloud Deploy automation 資源的欄位。

與目標相同，Automation 定義可納入提交管道定義，或位於個別檔案中。

如要進一步瞭解 Cloud Deploy 中的自動化作業，請參閱自動化說明文件。

以下 YAML 顯示如何設定自動化程序。請注意，每個自動化規則的具體內容都不相同。(如要瞭解如何設定可用的自動規則類型，請參閱「使用自動規則」一文)。

apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
  name: [PIPELINE_NAME]/[PURPOSE]
  labels:
  annotations:
description: [DESCRIPTION]
suspended: true | false
serviceAccount: [SERVICE_ACCOUNT_ID]
selector:
  targets:
    -  id: [TARGET_ID]
       labels:
         [LABEL_KEY]:[LABEL_VALUE]

rules:
- [RULE_TYPE]:
    id:[RULE_NAME]
  [RULE-SPECIFIC_CONFIG]

其中：

[PIPELINE_NAME]

與使用這項自動化功能的發布管道中的 metadata.name 值相同。所有自動化作業都專屬於建立時所用的推送軟體更新管道。也就是說，您無法在多個推送管道之間共用自動化作業。
[PURPOSE]

這是這項自動化動作的進一步說明名稱。通常這是自動執行的動作。例如 my-app-pipeline/promote。
labels 和 annotations 是要與這項自動化動作建立關聯的任何標籤或註解。
[DESCRIPTION]

這是這項自動化動作的說明 (選填)。
suspended

true 或 false，指出這項自動化動作是否有效或已暫停。如果設為 true，系統就不會使用自動化功能。這項功能有助於測試自動化功能，而不影響放送管道。
[SERVICE_ACCOUNT_ID]

這是用來執行自動化的服務帳戶 ID。舉例來說，如果自動化程序使用 promoteReleaseRule，則此服務帳戶會執行發行內容升級作業，因此需要升級發行內容所需的權限。

這項屬性必須有值。Cloud Deploy 不會使用預設服務帳戶執行自動化作業。

這個服務帳戶必須具備下列權限：
- actAs 權限，模擬執行服務帳戶。
- 權限，才能執行自動化作業，例如 clouddeploy.releases.promote 升級版本，或 clouddeploy.rollouts.advance 將推出作業推進至下一個階段。
[TARGET_ID]

這是指使用這項自動化功能的目標 ID。雖然自動化作業會與推送管道連結，但只會在指定目標上執行。

您可以將此值設為 *，選取放送管道中的所有目標。
[LABEL_KEY]:[LABEL_VALUE]

這是鍵/值組合，可與目標上定義的鍵/值組合比對。這會選取與放送管道相關聯的所有目標，這些目標具有相同的標籤和值。
[RULE_TYPE]

這是用於這項自動化動作的自動化規則名稱。這可以是 promoteReleaseRule、timedPromoteReleaseRule、advanceRolloutRule 或 repairRolloutRule。自動化動作可以包含多項規則，包括多個相同的 RULE_TYPE。舉例來說，您可以在同一項自動化作業中設定多項 promoteReleaseRule 規則。瞭解詳情。
[RULE_NAME]

規則名稱。此名稱在自動化資源中不得重複。這項屬性必須有值。
[RULE-SPECIFIC_CONFIG]

每種支援的自動化類型都有不同的設定。這些設定會顯示在「使用自動規則」中。

部署政策定義

本節說明用於定義部署政策的欄位。

與其他 Cloud Deploy 資源一樣，您可以將 DeployPolicy 定義納入推送管道定義中，或放在個別檔案中。

下列 YAML 顯示如何設定部署政策：

apiVersion: deploy.cloud.google.com/v1
kind: DeployPolicy
metadata:
  name: [POLICY_NAME]
  annotations: [ANNOTATIONS]
  labels: [LABELS]
description: [DESCRIPTION]
suspended: [true | false]
selectors:
- deliveryPipeline:
    id: [PIPELINE_ID]
    labels:
      [LABEL_KEY]:[LABEL_VALUE]
  target:
    id: [TARGET_ID]
    labels:
      [LABEL_KEY]:[LABEL_VALUE]
rules:
  - [RULE_TYPE]
      [CONFIGS]

其中：

[DESCRIPTION]

是說明這項政策的選用文字。
[POLICY_NAME]

原則的名稱。這個欄位會採用字串，且每個專案和位置都不得重複。這必須是小寫英文字母、數字和連字號，第一個字元須為英文字母，最後一個字元則是英文字母或數字，且最多只能有 63 個字元。這個名稱會做為Google Cloud 控制台中的顯示名稱。
[ANNOTATIONS] 和 [LABELS]

政策可包含註解和標籤，這些項目會在政策建立後成為政策資源的一部分。詳情請參閱搭配 Cloud Deploy 使用註解和標籤。
suspended: [true | false]

將 suspended 設為 true 會停用這項政策。
[PIPELINE_ID]

這是要套用這項政策的發布管道 ID。您可以使用 * 表示所有管道。這個 ID 與提交管道中的 metadata.name 屬性相同。
[TARGET_ID]

這是要套用這項政策的目標 ID。您可以使用 * 表示所有目標。這個 ID 與目標上的 metadata.name 屬性相同。
[LABEL_KEY]:[LABEL_VALUE]

這是鍵/值組合，可與傳送管道或目標上定義的鍵/值組合比對。這會選取具有相同標籤和值的所有管道或目標。除了 id 之外，你也可以指定 labels。
[RULE_TYPE]

您要設定的專屬政策規則類型。唯一有效的值為 rolloutRestriction。
[CONFIGS]

您要建立特定政策規則的設定屬性集。本參考資料的後續章節會說明各項可用規則的設定。

部署政策規則

本節說明如何設定各項部署政策規則。

`rolloutRestriction`

rolloutRestriction 規則可防止 Cloud Deploy 在指定的時間範圍內，對部署政策的 selectors 所指出的推送管道和目標，執行特定作業。

以下 YAML 顯示如何設定 rolloutRestriction 規則：

rules:
- rolloutRestriction:
    id: [RULE_ID]
    actions:
    - [ACTIONS]
    invokers:
    - [INVOKERS]
    timeWindows:
      timeZone: [TIMEZONE]
      oneTimeWindows:
      - start: [START_DATE_TIME]
        end: [END_DATE_TIME]
      weeklyWindows:
      - daysOfWeek:
        - [DAY_OF_WEEK]
        - [DAY_OF_WEEK]
        startTime: [START_TIME]
        endTime: [END_TIME]

其中：

RULE_ID

這項規則的 ID。(這是必要資訊)。必須包含小寫英文字母、數字和連字號，開頭須為英文字母，結尾須為英文字母或數字，且最多只能使用 63 個字元。部署政策中的名稱不得重複。
ACTIONS

選用：要限制的推出動作 (政策的一部分)。如果留空，所有動作都會受到限制。有效的值包括：
- ADVANCE
  
  無法推進推出階段。
- APPROVE
  
  無法核准推出促銷活動。
- CANCEL
  
  推出作業無法取消。
- CREATE
  
  無法建立推出作業。
- IGNORE_JOB
  
  工作無法忽略。
- RETRY_JOB
  
  工作無法重試。
- ROLLBACK
  
  推出後就無法復原。
- TERMINATE_JOBRUN
  
  無法終止工作執行作業
INVOKERS

指定叫用者後，系統會根據受限動作是由使用者還是部署自動化程序叫用，篩選政策強制執行作業。有效值如下：
- USER
  
  這項動作是由使用者發起。例如，使用 gcloud CLI 指令手動建立推出作業。
- DEPLOY_AUTOMATION
  
  Cloud Deploy 的自動化動作。
您可以指定其中一個值，也可以同時指定兩個值。如果您未指定任何項目，預設值為兩者。
TIMEZONE

時區 (採用 IANA 格式)，用於表示時間範圍。例如：America/New_York。必填。
START_DATE_TIME

對於 oneTimeWindows，這是限制期開始的日期和時間，格式為 "yyyy-mm-dd hh:mm"。如要表示一天開始，請使用 00:00。這是必填欄位。
END_DATE_TIME

對於 oneTimeWindows，這是指限制時間範圍的結束日期和時間，格式為 "yyyy-mm-dd hh:mm"。如要指定一天結束的時間，請使用 24:00。這是必填欄位。
DAY_OF_WEEK

如為 weeklyWindows，則為星期幾，SUNDAY、MONDAY、TUESDAY、WEDNESDAY、THURSDAY、FRIDAY 或 SATURDAY。如果將這個欄位留空，系統會比對一週內的所有日期
START_TIME

對於 weeklyWindows，這是指定星期幾的開始時間。如要加入開始時間，就必須加入結束時間。如要表示一天開始，請使用 00:00。
END_TIME

weeklyWindows：指定星期幾的結束時間。如要加入開始時間，就必須加入結束時間。如要結束當天的工作，請使用 24:00。

後續步驟

進一步瞭解 Cloud Deploy 的運作方式。
瞭解如何為應用程式設定發布管道。
瞭解如何管理資訊清單。
請先瞭解管道執行個體，避免發行內容與推送管道不符。

設定結構定義參照 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

瞭解使用方式

推送管道設定檔的結構

管道定義和進展

metadata.name

metadata.annotations 和 metadata.labels

description

suspended

serialPipeline

stages

targetId

profiles

strategy

strategy 設定

標準部署策略

初期測試部署策略

針對 Cloud Run 目標

適用於 GKE 和 GKE Enterprise 目標

自訂 Canary 設定

verify

deployParameters

「predeploy」和「postdeploy」工作

目標定義

適用於 GKE 目標

metadata.name

metadata.annotations 和 metadata.labels

description

deployParameters

multiTarget.targetIds: []

requireApproval

gke

dnsEndpoint

internalIp

proxyUrl

針對 Cloud Run 目標

metadata.name

metadata.annotations 和 metadata.labels

description

multiTarget.targetIds: []

requireApproval

run

適用於 GKE Enterprise 目標

自訂目標

executionConfigs

其他支援的語法

自訂目標類型定義

自動化定義

部署政策定義

部署政策規則

rolloutRestriction

後續步驟

設定結構定義參照

`metadata.name`

`metadata.annotations` 和 `metadata.labels`

`description`

`suspended`

`serialPipeline`

`stages`

`targetId`

`profiles`

`strategy`

`strategy` 設定

`verify`

`deployParameters`

「`predeploy`」和「`postdeploy`」工作

`metadata.name`

`metadata.annotations` 和 `metadata.labels`

`description`

`deployParameters`

`multiTarget.targetIds: []`

`requireApproval`

`gke`

`dnsEndpoint`

`internalIp`

`proxyUrl`

`metadata.name`

`metadata.annotations` 和 `metadata.labels`

`description`

`multiTarget.targetIds: []`

`requireApproval`

`run`

`executionConfigs`

`rolloutRestriction`