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

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:
#
# 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.annotationsmetadata.labels

デリバリー パイプラインの構成にはアノテーションとラベルを含めることができます。アノテーションとラベルは、パイプラインが登録された後にデリバリー パイプライン リソースとともに保存されます。

詳細については、Cloud Deploy でのラベルとアノテーションの使用をご覧ください。

description

このデリバリー パイプラインを説明する任意の文字列。この説明は、Google Cloud コンソールのデリバリー パイプラインの詳細に表示されます。

suspended

ブール値。true によりデリバリー パイプラインを停止する場合、リリースの作成、プロモート、ロールバック、再デプロイには使用できません。また、デリバリー パイプラインが停止している場合、そのパイプラインから作成されたロールアウトを承認または拒否することはできません。

デフォルトは false です。

serialPipeline

連続進行デリバリー パイプラインの定義の開始。このスタンザは必須です。

stages

このデリバリー パイプラインがデプロイされるように構成されているすべてのターゲットのリスト。

リストは、必要な配信シーケンス順序にする必要があります。たとえば、devstagingproduction というターゲットがある場合、同じ順序で一覧表示して、最初のデプロイ先が dev、最後のデプロイ先が production になるようにします。

stages.targetId フィールドに、対応するターゲット定義の metadata.name フィールドの値を入力します。targetId の下に profiles を追加します。

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

targetId

デリバリー パイプラインのこのステージに使用する特定のターゲットを特定します。値は、ターゲット定義metadata.name プロパティです。

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

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.yamlverify スタンザが必要です。このプロパティを指定しないと、確認ジョブは失敗します。

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.nameskaffold.yaml で構成されている名前です。

predeploy ジョブと postdeploy ジョブは、任意の戦略(standardcanary など)で構成できます。

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

ターゲットの定義

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

複数のデリバリー パイプライン間でターゲットを再利用できます。ただし、ターゲットを 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:

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

metadata.name

このターゲットの名前です。この名前はグローバルに一意である必要があります。

metadata.annotationsmetadata.labels

ターゲット構成は Kubernetes アノテーションラベルをサポートしていますが、Cloud Deploy では必須ではありません。

アノテーションとラベルはターゲット リソースと一緒に保存されます。詳細については、Cloud Deploy でのラベルとアノテーションの使用をご覧ください。

description

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

deployParameters

デプロイ パラメータを値とともに任意のターゲットに設定できます。これらの値は、レンダリング後にマニフェスト内の対応するキーに割り当てられます。

deployParameters スタンザは、次のように Key-Value ペアを受け取ります。

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

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

multiTarget.targetIds: []

このプロパティは省略可能です。並行デプロイに使用するマルチターゲットを構成するために使用されます。

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

requireApproval

このターゲットへの昇格に手動の承認が必要かどうか。truefalse のいずれかを設定できます。

このプロパティは省略可能です。デフォルトは 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 をご覧ください。

internalIp

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

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:

metadata.name

このターゲットの名前です。この名前は、リージョンごとに一意である必要があります。

metadata.annotationsmetadata.labels

ターゲット構成はアノテーションとラベルをサポートしていますが、Cloud Deploy では必須ではありません。

アノテーションとラベルはターゲット リソースと一緒に保存されます。詳細については、Cloud Deploy でのラベルとアノテーションの使用をご覧ください。

description

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

multiTarget.targetIds: []

このプロパティは省略可能です。並行デプロイに使用するマルチターゲットを構成するために使用されます。

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

requireApproval

このターゲットへの昇格に手動の承認が必要かどうか。truefalse のいずれかを設定できます。

このプロパティは省略可能です。デフォルトは 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 ターゲットのターゲット構成と似ていますが、プロパティは 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

    RENDERDEPLOY、またはその両方に加えて、デプロイフックまたは検証がターゲットで有効になっている場合のPREDEPLOYVERIFYPOSTDEPLOY。これらは、この実行環境を使用して、このターゲットに対して実行するオペレーションを示しています。カスタム実行環境がデプロイ前フック、レンダリング、デプロイ、デプロイ後フック、検証に使用されることを示すには、次のように構成します。

    usages:
    - RENDER
    - PREDEPLOY
    - DEPLOY
    - VERIFY
    - POSTDEPLOY
    

    パイプライン ステージで検証が有効になっており、usages スタンザで VERIFY を指定していない場合、Cloud Deploy では検証にデフォルトの実行環境が使用されます。デプロイ前とデプロイ後のフックは同じように機能します。

    ただし、RENDERDEPLOY のカスタム実行環境がある場合は、VERIFYPREDEPLOYPOSTDEPLOY のいずれかに必ず指定する必要があります (デリバリー パイプラインで構成されている場合)。VERIFYPREDEPLOYPOSTDEPLOY は、RENDERDEPLOY と同じ usages にあっても、別の usages にあってもかまいません。

    RENDERDEPLOY が同じまたは別のカスタム実行環境で指定されている場合を除き、usages.VERIFYusages.PREDEPLOYusages.POSTDEPLOY は指定できません。

  • workerPool

    使用するワーカープールの構成。このターゲットに使用する Cloud Build ワーカープールを識別するリソースパスを取得します。次に例を示します。

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

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

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

  • serviceAccount

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

  • artifactStorage

    デフォルトのバケットの代わりに、このターゲット(RENDER または DEPLOY)に使用する Cloud Storage バケット。

  • executionTimeout

    省略可。Cloud Build が Cloud Deploy に対して実行するオペレーションのタイムアウトを秒単位で設定します。デフォルトでは 3600 秒(1 時間)です。
    例: executionTimeout: "5000s"

サポートされている別の構文

このドキュメントで説明する 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 定義はデリバリー パイプラインの定義に含めるか、別のファイルに含めることができます。

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

ここで

  • [PIPELINE_NAME]

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

  • [PURPOSE]

    この自動化をわかりやすくするための任意の名前です。通常、これは自動化されている操作です。例: my-app-pipeline/promote

  • labelsannotations は、この自動化に関連付けるラベルまたはアノテーションです。

  • [DESCRIPTION]

    この自動化の説明(省略可)です。

  • suspended

    true または false。この自動化が有効か停止中かを示します。true に設定した場合、自動化は使用されません。これは、デリバリー パイプラインに影響を与えずに自動化をテストする場合に便利です。

  • [SERVICE_ACCOUNT_ID]

    自動化の実行に使用されるサービス アカウントの ID です。たとえば、自動化が promoteRelease の場合、このサービス アカウントはリリース プロモーションを行うため、リリースをプロモートさせるために必要な権限が必要です。

    このプロパティには値が必要です。Cloud Deploy では、自動化にデフォルトのサービス アカウントを使用しません。

    このサービス アカウントには次の権限が必要です。

    • 実行サービス アカウントの権限借用をするための actAs 権限。

    • 自動化されたオペレーションを行う権限。たとえば、リリースをプロモートさせる clouddeploy.releases.promote や、ロールアウト フェーズを進める clouddeploy.rollouts.advance など。

  • [TARGET_ID]

    この自動化が使用されているターゲットの ID です。自動化はデリバリー パイプラインに関連付けられていますが、指定されたターゲットでのみ実行されます。

  • [LABEL_KEY]:[LABEL_VALUE]

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

  • [RULE_TYPE]

    この自動化で使用される自動化ルールの名前です。これは promoteRelease または advanceRollout になります。複数のルールを自動化に含めることができます。同じ RULE_TYPE を複数含めることもできます。たとえば、同じ自動化に複数の promoteRelease ルールを設定できます。詳細

  • [RULE_NAME]

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

  • [RULE-SPECIFIC_CONFIG]

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

次のステップ