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

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

# 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"
              routeDestinations:
                destinationIds: ["KEY"]
                propagateService: [true|false]
        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 で構成された名前です。

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]
      internalIp:
      proxyUrl:

     associatedEntities:
       [KEY]:
         gkeClusters:
         - cluster: projects/[project_name]/locations/[location]/clusters/[cluster_name]
           internalIp: [true|false]
           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

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

実行環境のプロパティの詳細については、このドキュメントの executionConfigs をご覧ください。ターゲット以外の別のクラスタに HTTPRoute をデプロイする方法については、HTTPRoute を別のクラスタにデプロイするをご覧ください。

internalIp

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

proxyUrl

プロキシ経由でクラスタにアクセスする場合は、ここに proxyUrl プロパティを指定します。この値は、クラスタに接続するときに kubectl に渡されるプロキシ GKE クラスタの URL です。

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

[マルチターゲット] を構成する場合は、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]

マルチ ターゲット用に 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、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 で指定されたデリバリー パイプラインとターゲットに対して、指定された時間枠でロールアウトに対する特定のオペレーションが Cloud Deploy によって実行されないようにします。

次の 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 を使用します。

次のステップ