자동화 규칙 사용

이 문서에서는 배포 파이프라인에서 자동으로 수행할 수 있는 작업인 자동화 규칙에 대해 설명합니다. 예를 들어 특정 대상으로의 승격이 적절한 상황에서 자동으로 발생하도록 배포 파이프라인을 구성할 수 있습니다.

Cloud Deploy에 내장된 자동화 규칙만 사용할 수 있습니다. 이 문서에는 사용 가능한 자동화 규칙이 나와 있습니다.

참고: 배포 파이프라인당 최대 250개의 자동화 규칙을 포함할 수 있습니다.

사용 가능한 자동화 규칙

Cloud Deploy에서 사용할 수 있는 자동화 규칙은 다음과 같습니다.

규칙	설명
timedPromoteReleaseRule	한 대상에서 다음 대상으로 자동 승격 크론 일정에 따라
promoteReleaseRule	진행 중인 이전 대상에서 성공적으로 출시된 후 표시된 대상으로 출시 버전을 자동으로 승격합니다.
advanceRolloutRule	표시된 단계에서 다음 단계로 자동으로 출시를 진행합니다.
repairRolloutRule	출시에서 실패한 작업을 지정된 횟수만큼 자동으로 재시도하고 모든 재시도가 실패하면 롤백합니다.

자동화 규칙 구성

각 자동화 규칙의 구성은 특정 규칙에 따라 다릅니다. 이 섹션에서는 모든 규칙에 공통적인 구성과 사용 가능한 각 규칙을 구성하는 방법에 대해 설명합니다.

각 자동화 규칙은 자동화 리소스의 구성으로 구성됩니다. 이는 관련 배포 파이프라인의 구성 (일반적으로 clouddeploy.yaml라고 함)과 동일한 파일 내에 있을 수도 있고 원하는 파일에 있을 수도 있습니다. 자동화 구성에 대해 자세히 알아보세요.

다음 섹션에서는 개별 자동화 규칙과 관련된 구성을 설명합니다. 자동화 자체 구성은 배포 자동화를 참조하세요.

timedPromoteReleaseRule 자동화 규칙 구성

timedPromoteReleaseRule 규칙을 사용하면 선택한 대상에서 진행 중인 다음 대상 또는 지정된 대상으로 출시 버전을 승격할 시점을 예약할 수 있습니다. timedPromoteReleaseRule 자동화를 구성할 때 cron 일정에 따라 출시를 승격할 시점을 지정합니다.

rules:
- timedPromoteReleaseRule:
    name: "[RULE_NAME]"
    schedule: "[CRON]"
    timeZone: "[TIME_ZONE]"
    destinationTargetId: "[TO_TARGET]"
    destinationPhase: "[TO_PHASE]"

각 항목의 의미는 다음과 같습니다.

• [RULE_NAME]

  이 규칙에 지정할 이름입니다. 이 이름은 전송 파이프라인 내에서 고유해야 합니다.

• [CRON]

  출시를 승격할 시점을 지정하는 cron 일정입니다. 이 일정을 사용하여 출시를 홍보할 날짜와 시간을 지정합니다.

  이 일정은 표준 cron 문법을 사용합니다.

  * * * * *

  이 일정에서...

  • 첫 번째 위치는 분 (0~59)입니다.
  • 두 번째 위치는 시간 (0~23)입니다.
  • 세 번째 위치는 월중 일 (1~31)입니다.
  • 네 번째 위치는 월 (1~12)입니다.
  • 다섯 번째 위치는 요일입니다 (0~6, 일요일~토요일).

  예를 들어 예약 프로모션 규칙에 0 9 * * 1 일정이 포함되어 있으면 매주 월요일 오전 9시에 출시 버전이 프로모션됩니다.

  다음과 같은 표준 cron 일정 기능도 사용할 수 있습니다.

  • 범위 (0~5)
  • 목록 (1,3,5)
  • 단계 함수 (예: 시간 필드의 */3은 3시간마다 활성화됨)

• [TIME_ZONE]

  프로모션 예약에 사용할 시간대입니다(IANA 형식).

• [TO_TARGET]

  승격할 대상의 targetId 또는 이 자동화 구성의 selector.targets property에 지정된 대상 이후의 다음 대상으로 출시 버전을 자동으로 승격하는 @next입니다. 이는 선택사항이며 기본값은 @next입니다.

• [TO_PHASE]

  승격할 단계의 단계 이름입니다(예: canary-25 또는 stable). 이 속성은 선택사항으로, 생략하면 출시 버전이 대상의 첫 번째 단계로 승격됩니다.

promoteReleaseRule 자동화 규칙 구성

promoteReleaseRule 규칙은 대상으로의 성공적인 출시 후 출시 버전을 승격합니다. 예를 들어 3개의 대상이 있는 경우 출시 버전이 첫 번째 대상에 성공적으로 배포되면 자동으로 두 번째 대상으로 승격되도록 이 규칙을 설정할 수 있습니다.

참고: 자동화에 구성된 서비스 계정('자동화 서비스 계정')에는 clouddeploy.rollouts.create 권한이 있어야 합니다. 자동화 서비스 계정에는 Cloud Deploy 실행 서비스 계정을 가장할 수 있는 iam.serviceAccount.actAs 권한이 있어야 합니다. 자세한 내용은 IAM 역할 및 권한을 참조하세요.

promoteReleaseRule 자동화를 구성할 때 승격할 대상(destinationTargetId) 또는 @next를 지정할 수 있습니다. Automation 정의에 지정된 대상에서 출시가 성공적으로 완료되면 출시 버전은 wait 시간 간격으로 destinationTargetId에 지정된 대상으로 승격됩니다.

또한 destinationPhase 속성을 사용하여 출시 버전을 의도한 대상의 특정 단계로 승격할 수 있습니다. 여기에 표시된 rules 스탠자는 자동화 정의 내에 있습니다.

rules:
- promoteReleaseRule:
    name: "[RULE_NAME]"
    wait: [WAIT_TIME]
    destinationTargetId: "[TO_TARGET]"
    destinationPhase: "[TO_PHASE]"

각 항목의 의미는 다음과 같습니다.

• [RULE_NAME]

  이 규칙에 지정할 이름입니다. 이 이름은 자동화 리소스 내에서 고유해야 합니다.

• [WAIT_TIME]

  출시 버전이 승격될 준비가 된 후 승격되기 전까지 대기하는 시간(분)입니다. 예를 들면 1m입니다. m는 필수 항목입니다.

  기본값은 0이거나 대기 시간이 없는 것입니다. 최댓값은 20160m(또는 14일)입니다.

• [TO_TARGET]

  승격할 대상의 targetId입니다.

  이 자동화 구성의 selector.targets 속성에 지정된 대상 이후의 다음 대상으로 출시 버전을 자동으로 승격하는 @next일 수도 있습니다. destinationTargetId에서 값을 생략할 경우 기본값입니다.

• [TO_PHASE]

  승격할 단계의 단계 이름입니다(예: canary-25 또는 stable). 이 속성은 선택사항으로, 생략하면 출시 버전이 대상의 첫 번째 단계로 승격됩니다.

advanceRolloutRule 자동화 규칙 구성

advanceRolloutRule은 한 단계가 성공적으로 완료된 후 다음 단계로 자동으로 출시를 진행합니다. 이 자동화 규칙은 카나리아 배포에 유용합니다. 예를 들어 25%, 50%, stable 단계로 대상에 카나리아 배포 전략을 구성한 경우 50% 단계가 완료된 후 자동으로 stable로 단계를 진행하는 자동화 규칙을 구성할 수 있습니다.

참고: 자동화에 구성된 서비스 계정('자동화 서비스 계정')에는 clouddeploy.rollouts.advance 권한이 있어야 합니다. 자동화 서비스 계정에는 Cloud Deploy 실행 서비스 계정을 가장할 수 있는 iam.serviceAccount.actAs 권한이 있어야 합니다. 자세한 내용은 IAM 역할 및 권한을 참조하세요.

advanceRolloutRule 자동화를 구성할 때 sourcePhase에서 진행할 단계를 식별합니다. 여기에 표시된 rules 스탠자는 자동화 정의 내부에 있습니다.

rules:
- advanceRolloutRule:
    name: "[RULE_NAME]"
    sourcePhases: ["[START_PHASE]", "[START_PHASE]"...]
    wait: [WAIT_TIME]

각 항목의 의미는 다음과 같습니다.

• [RULE_NAME]

  이 규칙에 지정할 이름입니다. 이 이름은 전송 파이프라인 내에서 고유해야 합니다.

• [WAIT_TIME]

  출시가 준비된 후 출시를 진행할 때까지 대기하는 시간(분)입니다. 예를 들면 1m입니다. m는 필수 항목입니다.

  기본값은 0이거나 대기 시간이 없는 것입니다. 최댓값은 20160m(또는 14일)입니다.

• ["[START_PHASE]", "[START_PHASE]"...]

  출시가 자동으로 진행되는 단계입니다. 즉, 나열된 단계 중 하나가 성공적으로 완료되면 출시가 해당 단계에서 다음 단계로 자동 진행됩니다.

  단계 이름은 대소문자를 구분합니다. 또한 이러한 단계 이름은 선택사항입니다. sourcePhases를 생략하면 출시의 모든 단계가 자동으로 진행됩니다.

repairRolloutRule 자동화 규칙 구성

repairRolloutRule 규칙은 지정된 횟수만큼 실패한 출시를 재시도합니다. 재시도 횟수가 소진되면 이 규칙에 따라 마지막으로 성공한 출시 버전으로 대상을 자동으로 롤백합니다.

repairRolloutRule 자동화를 구성할 때는 출시 재시도 횟수와 재시도 사이의 대기 시간을 지정할 수 있습니다. 재시도할 특정 단계 또는 작업 중 하나 또는 둘 다 구성할 수 있습니다. 각각의 재시도가 실패하면 출시가 실패합니다. 재시도가 성공하면 자동화가 중지되고 출시가 성공합니다.

선택적으로 대상에서 마지막으로 성공한 출시 버전으로 롤백하도록 자동화를 구성할 수 있습니다. 재시도 구성도 선택사항입니다. 하지만 일정 횟수의 재시도, 롤백 또는 둘 다 중 하나 이상을 구성해야 합니다.

여기에 표시된 rules 스탠자는 자동화 정의 내에 있습니다.

rules:
- repairRolloutRule:
    name: "[RULE_NAME]"
    phases: [PHASES_TO_REPAIR]
    jobs: [JOBS_TO_REPAIR]
    repairPhases:
    - retry:
        attempts: [NUMBER_OF_ATTEMPTS]
        wait: [WAIT_TIME]
        backoffMode: [LINEAR | EXPONENTIAL]
    - rollback:
        destinationPhase: [PHASE_NAME]

각 항목의 의미는 다음과 같습니다.

• [RULE_NAME]

  이 규칙에 지정할 이름입니다. 이 이름은 전송 파이프라인 내에서 고유해야 합니다.

• [PHASES_TO_REPAIR]

  재시도할 출시 문구입니다. 선택사항이며 기본값은 출시의 모든 문구입니다.

• [JOBS_TO_REPAIR]

  재시도할 작업입니다. 선택사항이며 기본값은 모든 작업입니다.

• [NUMBER_OF_ATTEMPTS]

  선택사항. 실패로 간주하기 전 출시를 재시도할 횟수입니다.

• [WAIT_TIME]

  재시도 사이에 대기해야 하는 시간입니다. 예를 들어 1m은 1분 간격을 나타냅니다. 시간 단위(여기에서는 m)는 필수입니다.

  mode가 linear면 이 간격이 각 재시도 사이에 동일합니다. mode가 exponential이면 재시도마다 간격이 증가합니다. 자세한 내용은 mode를 참조하세요.

• backoffMode

  LINEAR 또는 EXPONENTIAL은 재시도 사이에 시간을 늘릴지 여부를 나타냅니다. LINEAR인 경우 WAIT_TIME에서 재시도 사이의 시간이 일정합니다. EXPONENTIAL인 경우 연속된 재시도 중 재시도 사이의 시간이 두 배로 증가합니다. 기본값은 LINEAR입니다.

  예를 들어 WAIT_TIME이 1m이고 backoffMode가 EXPONENTIAL로 설정되었으면 실패와 처음 재시도 사이의 시간이 1분이고, 첫 번째 재시도와 두 번째 재시도 사이의 시간은 2분이고, 두 번째 재시도와 세 번째 재시도 사이의 시간은 4분입니다.

• rollback

  선택사항. 모든 재시도 횟수가 소진된 후 실패한 출시를 롤백할지 여부입니다.

• [PHASE_NAME]

  롤백하려는 특정 단계의 이름입니다. toPhase를 생략하면 롤백이 기본적으로 stable 단계로 지정됩니다.

repairRolloutRule 자동화 실행 중단

출시에서 다음 명령어를 실행하면 repairRolloutRule 자동화가 중단됩니다.

• 작업 다시 시도
• 출시 취소
• 작업 무시
• 작업 실행 종료

예시

다음은 repairRolloutRule이 있는 자동화 구성의 예시입니다.

apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
  name: regular-repair/regular
description: repair regular rollouts
suspended: false
serviceAccount: (REDACTED)
selector:
  targets:
  - id: t1
rules:
- repairRolloutRule:
    name: "repair-rollout"
    repairPhases:
    - retry:
        attempts: 3
        wait: 1m
        backoffMode: LINEAR
    - rollback:
        destinationPhase: "stable"

이 자동화에서 식별된 대상에서 출시가 실패하면 출시가 최대 3회까지 재시도되고 재시도 사이의 대기 시간은 1분입니다. 모든 재시도가 실패하면 대상의 가장 최근 성공한 출시 버전을 해당 대상에 배포하는 새 출시를 생성하여 롤백이 시작됩니다.

다음 단계

• 빠른 시작: 출시 버전 생성 및 출시 진행 사용해보기

• Cloud Deploy의 배포 자동화 자세히 알아보기