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:
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에는 세 가지 주요 구성요소가 있습니다.
주 배포 파이프라인 및 진행 상황
구성 파일에는 파이프라인 정의를 원하는 만큼 포함할 수 있습니다.
타겟 정의
이 예시에서는 편의상 하나의 타겟만 보여주지만 그 수에는 제한이 없습니다. 또한 별도의 파일에 타겟을 정의할 수 있습니다.
커스텀 대상 유형 정의
커스텀 대상에는 커스텀 대상 유형 정의가 필요합니다. 대상 및 자동화와 마찬가지로 배포 파이프라인과 동일한 파일 또는 별도의 파일에서 커스텀 대상 유형을 정의할 수 있습니다.
자동화 정의
배포 파이프라인 및 대상과 동일한 파일 또는 별도의 파일에서 배포 자동화를 만들 수 있습니다. 편의상 여기에 하나의
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:
tasks: []
analysis:
verify 속성을 사용하면 배포를 확인하기 위해 실행할 하나 이상의 작업을 참조할 수 있습니다. 구성된 경우 확인 작업은 '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은 서비스 네트워킹, 게이트웨이 API 또는 Cloud Run의 커스텀 카나리아 배포 전략 또는 서비스 네트워킹, 게이트웨이 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스탠자도 구성해야 합니다.하나 이상의 작업을 사용하여
verify를 구성하여 확인을 위해 실행합니다.verify: tasks: [VERIFY_TASKS]
analysis
Google Cloud Observability 알림에 대해 하나 이상의 검사를 실행하는 데 사용할 수 있는 배포 분석은 strategy 스탠자 내에서 구성됩니다. 구성 세부정보는 분석 정의를 참고하세요.
deployParameters
배포 매개변수를 사용할 때 라벨 일치 대상의 매니페스트에 값을 전달하는 키-값 쌍을 지정할 수 있습니다.
대상에 포함할 수도 있습니다.
배포 파이프라인에 설정된 배포 매개변수는 라벨을 사용하여 대상을 일치시킵니다.
deployParameters:
- values:
someKey: "value1"
matchTargetLabels:
label1: firstLabel
- values:
someKey: "value2"
matchTargetLabels:
label2: secondLabel
이 예시에서는 키에 제공된 2개의 값이 있고 각 값에는 라벨이 있습니다. 이 값은 일치하는 라벨이 있는 모든 대상의 매니페스트에 적용됩니다.
predeploy 및 postdeploy 작업
배포 전 및 배포 후 후크는 출시에서 배포 작업 전후에 실행되는 작업입니다. 다음 두 가지 방법 중 하나로 predeploy 및 postdeploy 후크를 정의할 수 있습니다.
사전 배포 작업은 출시의 배포 작업 바로 전에 실행됩니다. 배포 후 작업은 확인 및 분석을 포함한 출시의 다른 모든 작업이 완료된 후에 실행됩니다(해당하는 경우).
배포 후크는 strategy.standard 또는 strategy.canary 아래에 다음과 같이 구성됩니다.
tasks사용serialPipeline: stages: - targetId: strategy: standard: predeploy: tasks: [PREDEPLOY_TASKS] postdeploy: tasks: [POSTDEPLOY_TASKS]각 항목의 의미는 다음과 같습니다.
actions(및 Skaffold) 사용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]
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 스탠자는 다음과 같이 키-값 쌍을 사용합니다.
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 프로젝트입니다.