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.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
に設定すると、ターゲットでデプロイの検証が有効になります。デプロイ戦略が指定されていない場合は、検証が 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.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:
executionConfigs:
- usages:
- [RENDER | PREDEPLOY | DEPLOY | VERIFY | POSTDEPLOY]
workerPool:
serviceAccount:
artifactStorage:
executionTimeout:
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
をご覧ください。
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.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"
サポートされている別の構文
このドキュメントで説明する 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
labels
とannotations
は、この自動化に関連付けるラベルまたはアノテーションです。[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]
構成は、サポートされている自動化タイプごとに異なります。この構成については、自動化ルールの使用をご覧ください。
次のステップ
Cloud Deploy の仕組みの詳細を確認する。
アプリケーションのデリバリー パイプラインを設定する方法を学習する。
マニフェストを管理する方法を確認する。
パイプライン インスタンスについて学習することで、リリースとデリバリー パイプラインの不一致を回避する。