Cloud Deploy 구성 파일은 배포 파이프라인, 배포할 대상, 대상의 진행을 정의합니다.
대상 정의는 배포 파이프라인 구성 파일에 포함될 수 있으며 아니면 별도의 파일 하나 이상에 포함될 수도 있습니다. 일반적으로 배포 파이프라인 구성과 대상 구성이 모두 포함된 파일을 clouddeploy.yaml
이라고 하고, 대상이 없는 파이프라인 구성을 delivery-pipeline.yaml
이라고 합니다. 하지만 이러한 파일에 원하는 이름을 지정할 수 있습니다.
각 항목의 위치
Cloud Deploy는 두 가지 기본 구성 파일을 사용합니다.
- 배포 파이프라인 정의
- 타겟 정의
별도의 파일일 수 있으며 배포 파이프라인 및 대상을 동일한 파일에 구성할 수도 있습니다.
전달 파이프라인 구성 파일의 구조
다음 구성에는 대상 정의가 포함됩니다.
# 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에는 세 가지 주요 구성요소가 있습니다.
주 배포 파이프라인 및 진행 상황
구성 파일에는 파이프라인 정의를 원하는 만큼 포함할 수 있습니다.
타겟 정의
이 예시에서는 편의상 하나의 타겟만 보여주지만 그 수에는 제한이 없습니다. 또한 별도의 파일에 타겟을 정의할 수 있습니다.
커스텀 대상 유형 정의
커스텀 대상에는 커스텀 대상 유형 정의가 필요합니다. 대상 및 자동화와 마찬가지로 배포 파이프라인과 동일한 파일 또는 별도의 파일에서 커스텀 대상 유형을 정의할 수 있습니다.
자동화 정의
배포 파이프라인 및 대상과 동일한 파일 또는 별도의 파일에서 배포 자동화를 만들 수 있습니다. 편의상 여기에 하나의
Automation
만 표시되지만 원하는 만큼 만들 수 있습니다.
이러한 구성요소는 이 문서의 나머지 부분에 정의되어 있습니다.
파이프라인 정의 및 진행
기본 파이프라인 정의에는 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
skaffold.yaml
에서 0개 이상의 Skaffold 프로필 이름이 포함된 목록을 가져옵니다.
Cloud Deploy는 출시 버전을 만들 때 skaffold render
와 함께 프로필을 사용합니다. Skaffold 프로필에서는 단일 구성 파일을 사용하는 동안 대상 간에 구성을 변경할 수 있습니다.
strategy
배포 전략을 지정하기 위한 속성을 포함합니다. 다음과 같은 전략이 지원됩니다.
standard:
애플리케이션이 지정된 대상에 완전히 배포됩니다.
기본 배포 전략입니다.
strategy
를 생략하면 Cloud Deploy가standard
배포 전략을 사용합니다.canary:
카나리아 배포에서는 백분율 기반 증분(예: 25%, 50%, 75% 100% 식으로) 방식으로 새 버전의 애플리케이션을 점진적으로 배포하여 이미 실행 중인 버전을 교체합니다.
배포 전략은 대상별로 정의됩니다. 예를 들어 prod
대상에는 카나리아 전략이 있지만 다른 대상에는 표준 전략(strategy
가 지정되지 않음)이 있을 수 있습니다.
자세한 내용은 배포 전략 사용을 참조하세요.
strategy
구성
이 섹션에서는 지원되는 각 런타임에 strategy
의 구성 요소를 보여줍니다.
표준 배포 전략
표준 전략에는 다음 요소만 포함됩니다.
strategy:
standard:
verify: true|false
verify
속성은 선택사항입니다. 기본값은 false
입니다. 즉, 결과 출시에 대한 verify 단계가 없습니다.
표준 배포 전략의 경우 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은 커스텀 또는 custom-automated 카나리아 배포 전략을 구성하는 방법을 보여줍니다. 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
배포 매개변수를 사용할 때 라벨 일치 대상의 매니페스트에 값을 전달하는 키-값 쌍을 지정할 수 있습니다.
대상에 포함할 수도 있습니다.
배포 파이프라인에 설정된 배포 매개변수는 라벨을 사용하여 대상을 일치시킵니다.
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은 skaffold.yaml
에 대해 customActions.name
에 구성된 이름입니다.
모든 전략(예: standard
, canary
)에서 predeploy
및 postdeploy
작업을 구성할 수 있습니다.
배포 전 및 배포 후 후크를 구성하고 사용하는 방법에 대한 자세한 내용은 배포 전후 후크 실행을 참조하세요.
대상 정의
배포 파이프라인 정의 파일에는 타겟 정의가 포함될 수 있으며 별도의 파일에서 타겟을 지정할 수도 있습니다. 프로젝트 내에서 타겟 이름을 반복할 수 있지만 배포 파이프라인 내에서 고유해야 합니다.
여러 배포 파이프라인에서 타겟을 재사용할 수 있습니다. 하지만 단일 배포 파이프라인의 진행 내에서 타겟을 한 번만 참조할 수 있습니다.
참조: 커스텀 대상 유형 정의
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
스탠자는 다음과 같이 키-값 쌍을 사용합니다.
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
로 설정합니다.
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
입니다.
[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
[multi-target]을 구성할 때 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
를 사용합니다. 이 실행 환경을 사용하여 이 대상에 perform할 작업을 나타냅니다. 커스텀 실행 환경이 배포 전 후크, 렌더링, 배포, 배포 후 후크, 확인에 사용되도록 지정하려면 다음과 같이 구성합니다.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 풀을 사용하려면 이 속성을 생략합니다.
지정된 대상에 두 개의
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
값과 동일합니다. 모든 자동화는 해당 자동화가 생성된 배포 파이프라인에만 적용됩니다. 즉, 두 개 이상의 배포 파이프라인 간에 자동화를 공유할 수는 없습니다.[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]
대상에 정의된 키-값 쌍과 일치하는 키-값 쌍입니다. 이렇게 하면 동일한 라벨과 값을 가진 배포 파이프라인과 연결된 모든 대상이 선택됩니다.
[RULE_TYPE]
이 자동화에 사용되는 자동화 규칙의 이름입니다.
promoteReleaseRule
또는advanceRolloutRule
입니다. 동일한RULE_TYPE
을 두 개 이상 포함하여 자동화에 규칙을 두 개 이상 포함할 수 있습니다. 예를 들어 동일한 자동화에promoteReleaseRule
규칙이 두 개 이상 있을 수 있습니다. 자세히 알아보기[RULE_NAME]
규칙의 이름입니다. 이 이름은 배포 파이프라인 내에서 고유해야 합니다. 이 속성에는 값이 필요합니다.
[RULE-SPECIFIC_CONFIG]
구성은 지원되는 각 자동화 유형에 따라 다릅니다. 이러한 구성은 자동화 규칙 사용에 나와 있습니다.
다음 단계
Cloud Deploy 작동 방식에 대해 자세히 알아보기
애플리케이션의 배포 파이프라인 설정 방법 알아보기
매니페스트 관리 방법 알아보기
파이프라인 인스턴스에 대해 알아보고 출시 및 배포 파이프라인 간의 불일치를 방지하세요.