構成スキーマリファレンス

Cloud Deploy 構成ファイルでは、デリバリーパイプライン、デプロイするターゲット、ターゲットの進行状況を定義します。

デリバリーパイプライン構成ファイルにターゲット定義を含めることが可能であり、別のファイルに含めることも可能です。慣例により、デリバリーパイプライン構成とターゲット構成の両方を含むファイルは clouddeploy.yaml 呼ばれ、ターゲットのないパイプライン構成は delivery-pipeline.yaml と呼ばれます。これらのファイルには任意の名前を付けることができます。

各部の名称

Cloud Deploy では、次の 2 つの主な構成ファイルが使用されます。

デリバリーパイプライン定義
ターゲット定義

これらは別々のファイルにすることも、デリバリーパイプラインとターゲットを同じファイルに構成することもできます。

デリバリーパイプライン構成ファイルの構造

次の構成には、ターゲット定義が含まれています。

# 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:
 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:
---

# 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:
- target:
    id:
    # or
    labels:
rules:
- [RULE_TYPE]:
  name:
  [RULE-SPECIFIC_CONFIG]

この YAML には次の 3 つの主要なコンポーネントがあります。

主なデリバリーパイプラインと進行状況

構成ファイルには、任意の数のパイプライン定義を含めることができます。
ターゲットの定義

わかりやすくするために、この例では、1 つのターゲットのみが示されていますが、任意の数を指定できます。また、ターゲットは別のファイルで定義することもできます。
カスタムターゲットタイプの定義

カスタムターゲットには、カスタムターゲットタイプの定義が必要です。ターゲットや自動化と同様に、カスタムターゲットタイプは、デリバリーパイプラインと同じファイルでも別のファイルでも定義できます。
自動化の定義

デプロイの自動化は、デリバリーパイプラインおよびターゲットと同じファイルか、別のファイルで作成できます。わかりやすくするため、ここでは Automation を 1 つだけ示していますが、任意の数を作成できます。

これらのコンポーネントについては、以降で定義します。

パイプラインの定義と進行状況

メインのパイプライン定義には、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 プロパティです。

strategy.standard.verify が true に設定されていると、ターゲットでデプロイの検証が有効になります。デプロイ戦略が指定されていない場合、standard デプロイ戦略が使用され、検証が false に設定されます。

`profiles`

0 個以上の Skaffold プロファイル名のリストを skaffold.yaml から取得します。 Cloud Deploy では、リリースの作成時に skaffold render でプロファイルを使用します。Skaffold プロファイルを使用すると、1 つの構成ファイルを使用しながらターゲット間で構成を変更できます。

`strategy`

デプロイ戦略を指定するプロパティが含まれます。次の戦略がサポートされています。

standard:

アプリケーションは、指定されたターゲットに完全にデプロイされます。

これはデフォルトのデプロイ戦略です。strategy を省略すると、Cloud Deploy は standard デプロイ戦略を使用します。
canary:

カナリアデプロイでは、アプリケーションの新しいバージョンを段階的にデプロイし、すでに実行されているバージョンをパーセントベースの増分値（たとえば、25%、次に 50%、75%、フルと続きます）。

デプロイ戦略はターゲットごとに定義されます。たとえば、prod ターゲットにはカナリア戦略を、他のターゲットには標準戦略（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

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"
        canaryDeployment:
          percentages: ["PERCENTAGES"]
          verify: true | false

この例の routeUpdateWaitTime に着目してください。これは、Gateway API が HTTPRoute リソースを使用してトラフィックを分割し、HTTPRoute の変更の伝播に遅延が生じる可能性があるため記載されています。このような場合、トラフィックが使用できないリソースに送信されるため、リクエストがドロップされる可能性があります。routeUpdateWaitTime を使用すると、このような遅延が発生した場合に HTTPRoute の変更が適用された後に Cloud Deploy を待機させることができます。

次の YAML は、カスタムまたはカスタム自動のカナリアデプロイ戦略を構成する方法を示しています。runtimeConfig セクションにあるランタイム固有の構成は、カスタムカナリアでは省略されますが、自動およびカスタム自動カナリア構成に含まれます。

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`

デプロイパラメータを使用するときに、ラベルが一致するターゲットのマニフェストに値を渡すために Key-Value ペアを指定できます。

ターゲットに設定することもできます。

デリバリーパイプラインに設定されたデプロイパラメータは、ラベルを使用してターゲットを照合します。

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

この例では、キーに 2 つの値が指定されており、それぞれの値にラベルがあります。この値は、一致するラベルを持つターゲットのマニフェストに適用されます。

`predeploy` ジョブと `postdeploy` ジョブ

これにより、デプロイジョブ（predeploy）の前と検証ジョブの後に実行されるカスタムアクション（skaffold.yaml で個別に定義される）を参照できます。デプロイ後のジョブは、検証ジョブ（postdeploy）があればその後で、なければ、デプロイジョブのすぐ後に実行されます。

デプロイフックは、次のように strategy.standard または strategy.canary の下に構成されます。

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

ここで、ACTION_NAME は customActions.name 用に skaffold.yaml で構成された名前です。

任意の戦略（standard、canary など）で predeploy ジョブと postdeploy ジョブを構成できます。

デプロイ前フックとデプロイ後フックの構成と使用の詳細については、デプロイの前後にフックを実行するをご覧ください。

ターゲットの定義

デリバリーパイプラインの定義ファイルには、ターゲットの定義を含めることができます。また、別のファイルでターゲットを指定することもできます。プロジェクト内でターゲット名を繰り返すことはできますが、デリバリーパイプライン内で一意である必要があります。

複数のデリバリーパイプライン間でターゲットを再利用できます。ただし、ターゲットを 1 つのデリバリーパイプラインの進行状況から参照できるのは 1 回だけです。

カスタムターゲットタイプの定義もご覧ください。

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]
      internalIp:
      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 スタンザは、次のように Key-Value ペアを取ります。

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

multi-targetにデプロイパラメータを設定すると、値が対象のすべてのマルチターゲットの子ターゲットのマニフェストに割り当てられます。

`multiTarget.targetIds: []`

このプロパティは省略可能です。並行デプロイに使用するmulti-targetを構成するために使用されます。

値は、子ターゲットのカンマ区切りのリストです。子ターゲットは通常のターゲットとして構成され、この 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

multi-targetを構成する場合は、gke プロパティを省略します。 GKE クラスタは代わりに、対応する子ターゲットの内部で構成されます。

実行環境のプロパティの詳細については、この記事の executionConfigs をご覧ください。

`internalIp`

指定した GKE クラスタがプライベート IP アドレスを使用するかどうか。このプロパティは省略可能です。デフォルトでは、Cloud Deploy はクラスタに一般公開されている IP アドレスを使用します。プライベート IP アドレスがあり、使用する場合は、これを true に設定します。

`proxyUrl`

プロキシ経由でクラスタにアクセスする場合は、ここに proxyUrl プロパティを指定します。この値は、プロキシ GKE クラスタの URL です。クラスタに接続するときに 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 では必須ではありません。

`description`

このフィールドには、このターゲットの使用を説明する任意の文字列を指定します。

`multiTarget.targetIds: []`

このプロパティは省略可能です。並行デプロイに使用するmulti-targetを構成するために使用されます。

値は、子ターゲットのカンマ区切りのリストです。子ターゲットは通常のターゲットとして構成され、この multiTarget プロパティは含まれません。

`requireApproval`

このターゲットへのプロモーションに手動での承認が必要かどうか。true、false のいずれかを設定できます。

このプロパティは省略可能です。デフォルトは false です。

並行デプロイを構成する場合、マルチターゲットのみで承認を要求できます。子ターゲットではできません。

`run`

Cloud Run サービスの場合のみです。サービスが作成されるロケーションを示します。

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

project_name

サービスが存在する Google Cloud プロジェクト。
location

サービスが存在する場所。例: us-central1

[multi-target] を構成するときに run プロパティを省略します。Cloud Run サービスのロケーションは代わりに、対応する子ターゲットの内部に構成されます。

実行環境のプロパティの詳細については、この記事の executionConfigs をご覧ください。

GKE Enterprise ターゲットの場合

GKE クラスタにデプロイするターゲット構成は、GKE ターゲットのターゲット構成と似ていますが、プロパティは gke.cluster ではなく、anthosCluster.membership になります。リソースパスが異なり、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 ワーカープールを識別するリソースパスを指定します。次に例を示します。

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

デフォルトの Cloud Build プールを使用するには、このプロパティを省略します。

1 つのターゲットには、2 つの workerPool（RENDER 用と DEPLOY 用）を指定できます。デフォルトプールを構成するときは、代替のサービスアカウントまたはストレージの場所、または両方を指定できます。
serviceAccount

このターゲットのこのオペレーション（RENDER または DEPLOY）に使用するサービスアカウントの名前。
artifactStorage

デフォルトのバケットの代わりに、このターゲット（RENDER または DEPLOY）に使用する Cloud Storage バケット。
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]

multi-target用に 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 の定義は、デリバリーパイプラインの定義で記述することも、別のファイルで記述することもできます。

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]:
    name:[RULE_NAME]
  [RULE-SPECIFIC_CONFIG]

ここで

[PIPELINE_NAME]

この自動化を使用するデリバリーパイプラインの metadata.name 値と同じです。すべての自動化は、それぞれのデリバリーパイプライン専用に作成されます。つまり、1 つの自動化を複数のデリバリーパイプラインで共有することはできません。
[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]

ターゲットで定義された Key-Value ペアと照合する Key-Value ペアです。これにより、同じラベルと値を持つデリバリーパイプラインに関連付けられたすべてのターゲットを選択します。
[RULE_TYPE]

この自動化で使用される自動化ルールの名前です。これは promoteReleaseRule または advanceRolloutRule のいずれかです。複数のルールを自動化に含めることができます。同じ RULE_TYPE を複数含めることもできます。たとえば、同じ自動化に複数の promoteReleaseRule ルールを作成できます。詳細

注: ルール名 promoteRelease と advanceRollout は引き続きサポートされます。
[RULE_NAME]

ルールの名前。この名前は、デリバリーパイプライン内で一意である必要があります。このプロパティの値は必須です。
[RULE-SPECIFIC_CONFIG]

構成は、サポートされている自動化の種類ごとに異なります。それらの構成については、自動化ルールの使用をご覧ください。

次のステップ

Cloud Deploy の仕組みの詳細を確認する。
アプリケーションのデリバリーパイプラインを設定する方法を学習する。
マニフェストの管理方法を学習する。
パイプラインインスタンスについて学習することで、リリースとデリバリーパイプラインの不一致を回避する。

構成スキーマ リファレンス

各部の名称

デリバリー パイプライン構成ファイルの構造

パイプラインの定義と進行状況

metadata.name

metadata.annotations と metadata.labels

description

suspended

serialPipeline

stages

targetId

profiles

strategy

strategy 構成

標準的なデプロイ戦略

カナリア デプロイ戦略

Cloud Run ターゲットの場合

GKE と GKE Enterprise ターゲットの場合

verify

deployParameters

predeploy ジョブと postdeploy ジョブ

ターゲットの定義

GKE ターゲットの場合

metadata.name

metadata.annotations と metadata.labels

description

deployParameters

multiTarget.targetIds: []

requireApproval

gke

internalIp

proxyUrl

Cloud Run ターゲットの場合

metadata.name

metadata.annotations と metadata.labels

description

multiTarget.targetIds: []

requireApproval

run

GKE Enterprise ターゲットの場合

カスタム ターゲットの場合

executionConfigs

サポートされている代替構文

カスタム ターゲット タイプの定義

自動化の定義

次のステップ

構成スキーマリファレンス

デリバリーパイプライン構成ファイルの構造

`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`

`internalIp`

`proxyUrl`

`metadata.name`

`metadata.annotations` と `metadata.labels`

`description`

`multiTarget.targetIds: []`

`requireApproval`

`run`

カスタムターゲットの場合

`executionConfigs`

カスタムターゲットタイプの定義