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

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:
       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 には次の 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 プロファイルを使用すると、単一の構成ファイルを使用しながら、ターゲット間で構成を変更できます。

`strategy`

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

standard:

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

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

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

デプロイ戦略はターゲットごとに定義されます。たとえば、prod ターゲットにはカナリア戦略を使用し、他のターゲットには標準戦略（strategy を指定しない）を使用するとします。

詳細については、デプロイ戦略を使用するをご覧ください。

`strategy` 構成

このセクションでは、サポートされている各ランタイムの strategy の構成要素を示します。

標準のデプロイ戦略

標準戦略には、次の要素のみが含まれます。

strategy:
  standard:
    verify:
      tasks: []
    analysis:

verify プロパティを使用すると、デプロイの検証のために実行する 1 つ以上のタスクを参照できます。構成されている場合、検証タスクは「deploy」ジョブの直後に順番に実行されます。

verify プロパティは省略できます。指定しない場合、結果のロールアウトに 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 である必要があります。

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 を使用すると、このような遅延が発生した場合に HTTPRoute の変更が適用された後に Cloud Deploy を待機させることができます。

次の YAML は、カスタムカナリアデプロイ戦略（サービスネットワーキング、Gateway API、Cloud Run の場合）またはカスタム自動カナリアデプロイ戦略（サービスネットワーキング、Gateway API、Cloud Run の場合）を構成する方法を示しています。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:
          tasks: []
      - …
      - name: "stable"
        percent: 100
        profiles: [ "LAST_PROFILE_NAME" ]
        analysis: [ANALYSIS_CONFIGS]
        verify:
          tasks: []

`verify`

verify スタンザは、strategy.standard、strategy.canary.canaryDeployment、または strategy.canary.customCanaryDeployment の各フェーズに含めることができます。ターゲットのデプロイの検証を有効にするために使用されます。このスタンザは省略可能です。省略した場合、ロールアウトまたはカナリアフェーズの検証は行われません。

verify は、次のいずれかの方法で構成できます。

verify: true を設定します。

この場合、検証用に Skaffold を構成するの説明に従って、skaffold.yaml で verify スタンザも構成する必要があります。
検証用に実行する 1 つ以上のタスクを使用して verify を構成します。
```
verify:
  tasks: [VERIFY_TASKS]
```

`analysis`

デプロイ分析（Google Cloud Observability アラートに対して 1 つ以上のチェックを実行するために使用）は、strategy スタンザ内で構成されます。構成の詳細については、分析の定義をご覧ください。

`deployParameters`

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

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

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

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

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

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

デプロイ前フックとデプロイ後フックは、ロールアウトのデプロイジョブの前後に実行するジョブです。predeploy フックと postdeploy フックは、次のいずれかの方法で定義できます。

タスクを構成する
カスタムアクションを参照します。

デプロイ前ジョブは、ロールアウトのデプロイジョブの直前に実行されます。postdeploy ジョブは、ロールアウト内の他のすべてのジョブ（検証や分析など）の後に実行されます（該当する場合）。

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

tasks の使用

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

ここで

PREDEPLOY_TASKS は、デプロイ前フックで実行する 1 つ以上のタスクです。
POSTDEPLOY_TASKS は、デプロイ後フックで実行する 1 つ以上のタスクです。

actions（および Skaffold）の使用
```
serialPipeline:
  stages:
  - targetId:
    strategy:
      standard:
        predeploy:
          actions: [ACTION_NAME]
        postdeploy:
          actions: [ACTION_NAME]
```
ここで、ACTION_NAME は customActions.name の skaffold.yaml で構成された名前です。

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

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

ターゲットの定義

デリバリーパイプラインの定義ファイルには、ターゲットの定義を含めることができます。また、別のファイルでターゲットを指定することもできます。

複数のデリバリーパイプライン間でターゲットを再利用できます。ただし、ターゲットを 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]
      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 スタンザは、次のように Key-Value ペアを受け取ります。

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

カナリア構成では、この名前を使用して routeDestinations からエンティティを参照します。詳細

`dnsEndpoint`

true に設定すると、Cloud Deploy は、クラスタ構成に応じて一般公開 IP、限定公開 IP、DNS エンドポイントのいずれかになるデフォルトエンドポイントではなく、DNS エンドポイントを使用して GKE クラスタに接続します。

このオプションは、internalIp オプションと同時に使用できません。

`internalIp`

true に設定すると、Cloud Deploy は、クラスタ構成に応じてパブリック IP、プライベート IP、DNS エンドポイントのいずれかになる可能性があるデフォルトのエンドポイントではなく、プライベート IP アドレスを使用して GKE クラスタに接続します。

このオプションは、dnsEndpoint オプションと同時に使用できません。dnsEndpoint のネットワーク構成ははるかに簡単であるため、代わりにそれを使用することをおすすめします。

`proxyUrl`

HTTP プロキシ経由でクラスタにアクセスする場合は、ここに proxyUrl プロパティを指定します。この値はプロキシの 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 | ANALYSIS]
       workerPool:
       serviceAccount:
       artifactStorage:
       executionTimeout:
       verbose:

`metadata.name`

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

`metadata.annotations` と `metadata.labels`

ターゲット構成はアノテーションとラベルをサポートしていますが、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

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

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

GKE 接続クラスタターゲットの場合

GKE 接続クラスタにデプロイするターゲット構成は、GKE ターゲットのターゲット構成と似ていますが、プロパティは gke.cluster ではなく anthosCluster.membership になります。リソースパスが異なり、特定の接続方法（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

[multi-target] を構成する場合は、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 ワーカープールを識別するリソースパスを指定します。次に例を示します。

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]

マルチターゲット用に 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]:
    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]

ターゲットで定義された Key-Value ペアと照合する Key-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]

デリバリーパイプラインまたはターゲットで定義された Key-Value ペアと照合する Key-Value ペアです。これにより、同じラベルと値を持つすべてのパイプラインまたはターゲットが選択されます。id の代わりに、またはそれに加えて labels を指定できます。
[RULE_TYPE]

構成する特定のポリシールールタイプです。有効な値は rolloutRestriction のみです。
[CONFIGS]

作成する特定のポリシールールの構成プロパティのセットです。ルールの構成については、このリファレンスのこのセクションの後半で、使用可能なルールごとに説明します。

ポリシールールをデプロイする

このセクションでは、各デプロイポリシーのルールを構成する方法について説明します。

`rolloutRestriction`

rolloutRestriction ルールは、デプロイポリシーの 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

このルールの識別子。必須入力項目です。英小文字、数字、ハイフンで構成する必要があります。先頭の文字は英字、末尾の文字は英字または数字にする必要があります。最大文字数は 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" 形式）。1 日の始まりには 00:00 を使用します。このフィールドは必須です。
END_DATE_TIME

oneTimeWindows の場合、制限期間の終了日時です（"yyyy-mm-dd hh:mm" 形式）。1 日の終わりには 24:00 を使用します。このフィールドは必須です。
DAY_OF_WEEK

weeklyWindows の場合、曜日の SUNDAY、MONDAY、TUESDAY、WEDNESDAY、THURSDAY、FRIDAY、SATURDAY です。この項目を空白のままにすると、すべての曜日が一致します。
START_TIME

weeklyWindows の場合、指定した曜日の開始時間です。開始時刻を含める場合は、終了時刻も指定する必要があります。1 日の始まりには 00:00 を使用します。
END_TIME

weeklyWindows の場合、指定した曜日の終了時間です。開始時刻を含める場合は、終了時刻も指定する必要があります。1 日の終わりには 24:00 を使用します。

分析の定義

analysis スタンザを使用すると、Google Cloud Observability アラート、または他のモニタリングプロバイダの同様のデータに対して 1 つ以上のチェックを実行し、それらのアラートに基づいてアクションを実行するように分析ジョブを構成できます。

analysis スタンザは、Google Cloud Observability 用に構成しているか、カスタム分析を使用して別のプロバイダ用に構成しているかによって異なります。

Google Cloud Observability の `analysis`

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」の場合、ここでの引数の 1 つは「-c」になり、別の引数は呼び出したシェルで実行するコマンドの全体です。

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

構成スキーマ リファレンス コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

各部の名称

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

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

metadata.name

metadata.annotations と metadata.labels

description

suspended

serialPipeline

stages

targetId

profiles

strategy

strategy 構成

標準のデプロイ戦略

カナリア デプロイ戦略

Cloud Run ターゲットの場合

GKE クラスタと GKE 接続クラスタのターゲットの場合

カスタム カナリア構成

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

分析の定義

Google Cloud Observability の analysis

カスタムの 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`

GKE 接続クラスタターゲットの場合

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

`executionConfigs`

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

ポリシールールをデプロイする

`rolloutRestriction`

Google Cloud Observability の `analysis`

カスタムの `analysis`