구성 스키마 참조

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:
#
# 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입니다. 즉, 결과 출시의 확인 단계가 없습니다.

표준 배포 전략의 경우 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

배포 매개변수를 사용할 때 라벨 일치 대상의 매니페스트에 값을 전달하는 키-값 쌍을 지정할 수 있습니다.

타겟에 포함할 수도 있습니다.

전달 파이프라인에 설정된 배포 매개변수는 라벨을 사용하여 대상을 일치시킵니다.

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 작업을 구성할 수 있습니다.

배포 전 및 배포 후 후크를 구성하고 사용하는 방법에 대한 자세한 내용은 배포 전후 후크 실행을 참조하세요.

대상 정의

배포 파이프라인 정의 파일에는 타겟 정의가 포함될 수 있으며 별도의 파일에서 타겟을 지정할 수도 있습니다. 프로젝트 내에서 타겟 이름을 반복할 수 있지만 배포 파이프라인 내에서 고유해야 합니다.

여러 배포 파이프라인에서 타겟을 재사용할 수 있습니다. 하지만 단일 배포 파이프라인의 진행 내에서 타겟을 한 번만 참조할 수 있습니다.

참조: 커스텀 대상 유형 정의

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 스탠자는 다음과 같이 키-값 쌍을 사용합니다.

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입니다.

[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를 사용합니다. 이 실행 환경을 사용하여 이 대상에 수행할 작업을 나타냅니다. 커스텀 실행 환경이 배포 전 후크, 렌더링, 배포, 배포 후 후크, 확인에 사용되도록 지정하려면 다음과 같이 구성합니다.

    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"

지원되는 대체 구문

이 문서에 설명된 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]

    구성은 지원되는 각 자동화 유형에 따라 다릅니다. 이러한 구성은 자동화 규칙 사용에 나와 있습니다.

다음 단계