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

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

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

注: 組織はターゲット定義をパイプライン定義から分離する場合があり、これにより、異なるロールでこれらの構成を別々に管理できるようになります。Cloud Deploy はその方法をサポートしています。

各部の名称

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"

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

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

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 では必須ではありません。

アノテーションとラベルは、ターゲット リソースとともに保存されます。詳細については、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 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

このターゲットに対してデフォルト以外の実行環境を指定するためのフィールドのセット。

注: 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 です。

注: RENDER または DEPLOY のいずれかの構成を指定する場合は、一方がデフォルト値を使用している場合でも、他方の構成を指定する必要があります（usages: プロパティのみ）。

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

このドキュメントで説明する 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]:
    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 の仕組みの詳細を確認する。

• アプリケーションのデリバリー パイプラインを設定する方法を学習する。

• マニフェストの管理方法を学習する。

• パイプライン インスタンスについて学習することで、リリースとデリバリー パイプラインの不一致を回避する。