設定結構定義參照

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:
       predeploy:
         tasks: []
       verify:
         tasks: []
       analysis:
       postdeploy:
         tasks: []
   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 | ANALYSIS]
  workerPool:
  serviceAccount:
  artifactStorage:
  executionTimeout:
  verbose:
---

# Custom target type config
apiVersion: deploy.cloud.google.com/v1
kind: CustomTargetType
metadata:
  name:
  annotations:
  labels:
description:
tasks:
  render:
  deploy:
---

# 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:
      tasks: []
    analysis:

verify 屬性可讓您參照一或多個要執行的工作，以驗證部署作業。如果已設定，驗證工作會在「deploy」工作完成後立即依序執行。

verify 屬性為選用項目。如未指定，結果發布中就不會有驗證工作。

analysis 節為選用項目，可搭配 Cloud Deploy 分析使用。

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

初期測試部署策略

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

針對 Cloud Run 目標

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

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

適用於 GKE 和 GKE 附加叢集目標

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

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

下列 YAML 顯示如何使用 Gateway API，為部署至 GKE 或 GKE 連結叢集的目標設定部署策略：

      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:
            tasks: []

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

下列 YAML 顯示如何設定自訂 Canary 部署策略 (適用於服務網路、閘道 API 或 Cloud Run)，或自訂自動 Canary 部署策略 (適用於服務網路、閘道 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:
          tasks: []
      - …
      - name: "stable"
        percent: 100
        profiles: [ "LAST_PROFILE_NAME" ]
        analysis: [ANALYSIS_CONFIGS]
        verify:
          tasks: []

`verify`

verify 節可包含在 strategy.standard、strategy.canary.canaryDeployment 或 strategy.canary.customCanaryDeployment 的每個階段中。這個物件可用來為目標啟用部署驗證。這個節是選用項目；如果省略，系統不會對推出作業或 Canary 階段執行驗證。

您可以透過下列兩種方式設定 verify：

設定 verify: true。

如果採取這種做法，您也必須在 skaffold.yaml 中設定 verify 節，詳情請參閱「設定 Skaffold 以進行驗證」。
設定 verify，使用一或多個 tasks 執行驗證：
```
verify:
  tasks: [VERIFY_TASKS]
```

`analysis`

部署分析 (可用於對 Google Cloud Observability 警示執行一或多項檢查) 是在 strategy 節中設定。如需設定詳細資料，請參閱「分析定義」。

`deployParameters`

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

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

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

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

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

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

預先部署和後期部署掛鉤是在推出作業中，於部署作業前後執行的工作。您可以透過下列任一方式定義部署前和部署後掛鉤：

設定工作
請參閱自訂動作。

在發布作業中，前置部署工作會在部署工作前立即執行。部署後工作會在推出作業中的所有其他工作 (包括驗證和分析) 完成後執行 (如適用)。

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

正在使用 tasks

serialPipeline:
  stages:
  - targetId:
    strategy:
      standard:
        predeploy:
          tasks: [PREDEPLOY_TASKS]
        postdeploy:
          tasks: [POSTDEPLOY_TASKS]

其中：

PREDEPLOY_TASKS 是要在部署前掛鉤中執行的一或多個「工作」。
POSTDEPLOY_TASKS 是要在部署後掛鉤中執行的一或多個「工作」。

使用 actions (和 Skaffold)

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 | ANALYSIS]
       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 部署至其他叢集」。

`associatedEntities.[KEY]`

在 Canary 設定中，您可以使用這個名稱參照 routeDestinations 中的實體。瞭解詳情。

`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 | ANALYSIS]
       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 附加叢集目標

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

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

project_name

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

叢集的註冊位置。global，在所有情況下皆是如此。
membership_name

叢集成員名稱。

範例如下：

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

設定 [多重目標] 時，請省略 anthosCluster 屬性。而是改為在相應的子項目標中設定叢集。

如要進一步瞭解如何部署至 GKE 附加叢集，請參閱「部署至 GKE 附加叢集」。

自訂目標

自訂目標的設定與所有其他目標類型類似，但不會包含 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
- ANALYSIS
```
如果在管道階段啟用驗證，且您未在 usages 節中指定 VERIFY，Cloud Deploy 會使用預設執行環境進行驗證。前置部署和後置部署掛鉤的運作方式相同。

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

除非在相同或個別的自訂執行環境中指定 RENDER 和 DEPLOY，否則無法指定 usages.VERIFY、usages.PREDEPLOY、usages.POSTDEPLOY 或 usages.ANALYSIS。
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。

分析定義

analysis 節可讓您設定分析工作，針對 Google Cloud Observability 快訊或其他監控供應商的類似資料執行一或多項檢查，以便根據這些快訊採取行動。

analysis 節會因設定對象而異，如果是為 Google Cloud Observability 設定，或是為使用自訂分析的其他供應商設定，節會有所不同。

`analysis` Google Cloud Observability

analysis 節可直接用於部署策略設定 (標準策略為 strategy.standard.analysis)。如要設定每個階段的分析，請使用自訂初期測試 (strategy.canary.customCanaryDepolyment.phaseConfigs.phaseId.analysis)。

analysis:
  duration: DURATION
  googleCloud:
    alertPolicyChecks:
    - id: CHECK_ID
      alertPolicies:
      - ALERT_POLICY_NAME
      labels:
        LABEL_KEY: LABEL_VALUE

使用 Google Cloud Observability 時，analysis 的設定屬性如下：

你可以擁有任意數量的 alertPolicyChecks。
DURATION 是執行分析的時間長度，以秒、分鐘或小時為單位。時間到期後，Google Cloud Observability 的快訊就不會再影響分析結果。例如：200s。

CHECK_ID 是快訊政策檢查的專屬 ID。這項資訊會顯示在每項檢查的分析結果中。
ALERT_POLICY_NAME 是您在 Google Cloud Observability 中建立的快訊政策名稱。
LABEL_KEY 是檢查使用的任何標籤名稱，可與 Google Cloud Observability 快訊政策比對。
LABEL_VALUE 是每個標籤要比對的值。

自訂 `analysis`

使用自訂檢查 (針對來自 Google Cloud Observability 以外監控服務供應商的資料) 的分析工作。自訂檢查會使用「工作」指定包含自訂行為的容器，以及要在該容器上執行的指令。

自訂分析的設定如下：

analysis:
  duration: DURATION
  customChecks:
  - id: CHECK_ID
    frequency: FREQUENCY
    task:
      type: container
      image: IMAGE_NAME
      command: [COMMAND]
      args: [ARGS]
      env:
        [VAR: VALUE]

DURATION 是執行分析的時間長度，以秒、分鐘或小時為單位。時間到期後，分析結果就不會再受到監控系統傳入的遙測資料影響。例如：200s。
CHECK_ID 是您為快訊政策檢查提供的專屬 ID。這項資訊會顯示在每項檢查的分析結果中。
FREQUENCY：指定檢查的執行頻率 (以秒、分鐘或小時為單位)。例如：300s。
IMAGE_NAME 是映像檔存放區中容器映像檔的路徑。
COMMAND 是要在該容器上執行的進入點。「/bin/sh」是這裡指定的典型指令，用於叫用殼層，您會在 args 中加入要在該殼層中執行的指令。
ARGS 是要提供給指令的引數清單。如果 COMMAND 是「/bin/sh」，則其中一個引數會是「-c」，另一個引數則會是您要在叫用的殼層中執行的完整指令。

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

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

瞭解使用方式

推送管道設定檔的結構

管道定義和進展

metadata.name

metadata.annotations 和 metadata.labels

description

suspended

serialPipeline

stages

targetId

profiles

strategy

strategy 設定

標準部署策略

初期測試部署策略

針對 Cloud Run 目標

適用於 GKE 和 GKE 附加叢集目標

自訂 Canary 設定

verify

analysis

deployParameters

「predeploy」和「postdeploy」工作

目標定義

適用於 GKE 目標

metadata.name

metadata.annotations 和 metadata.labels

description

deployParameters

multiTarget.targetIds: []

requireApproval

gke

associatedEntities.[KEY]

dnsEndpoint

internalIp

proxyUrl

針對 Cloud Run 目標

metadata.name

metadata.annotations 和 metadata.labels

description

multiTarget.targetIds: []

requireApproval

run

適用於 GKE 附加叢集目標

自訂目標

executionConfigs

支援的替代語法

自訂目標類型定義

自動化定義

部署政策定義

部署政策規則

rolloutRestriction

分析定義

analysis Google Cloud Observability

自訂 analysis

後續步驟

設定結構定義參照

`metadata.name`

`metadata.annotations` 和 `metadata.labels`

`description`

`suspended`

`serialPipeline`

`stages`

`targetId`

`profiles`

`strategy`

`strategy` 設定

`verify`

`analysis`

`deployParameters`

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

`metadata.name`

`metadata.annotations` 和 `metadata.labels`

`description`

`deployParameters`

`multiTarget.targetIds: []`

`requireApproval`

`gke`

`associatedEntities.[KEY]`

`dnsEndpoint`

`internalIp`

`proxyUrl`

`metadata.name`

`metadata.annotations` 和 `metadata.labels`

`description`

`multiTarget.targetIds: []`

`requireApproval`

`run`

`executionConfigs`

`rolloutRestriction`

`analysis` Google Cloud Observability

自訂 `analysis`