이 문서에서는 배포 파이프라인에서 자동으로 수행할 수 있는 작업인 자동화 규칙에 대해 설명합니다. 예를 들어 특정 대상으로의 승격이 적절한 상황에서 자동으로 발생하도록 배포 파이프라인을 구성할 수 있습니다.
Cloud Deploy에 내장된 자동화 규칙만 사용할 수 있습니다. 이 문서에는 사용 가능한 자동화 규칙이 나와 있습니다.
사용 가능한 자동화 규칙
Cloud Deploy에서 사용할 수 있는 자동화 규칙은 다음과 같습니다.
규칙 | 설명 |
---|---|
promoteReleaseRule
|
진행 중인 이전 대상에서 성공적으로 출시된 후 표시된 대상으로
출시 버전을 자동으로 승격합니다. |
timedPromoteReleaseRule
|
한 대상에서 다음 대상으로 자동 승격
크론 일정에 따라 |
advanceRolloutRule
|
표시된
단계에서 다음 단계로 자동으로 출시를 진행합니다. |
repairRolloutRule
|
출시에서 실패한 작업을 지정된 횟수만큼 자동으로
재시도하고 모든 재시도가 실패하면 롤백합니다. |
자동화 규칙 구성
각 자동화 규칙의 구성은 특정 규칙에 따라 다릅니다. 이 섹션에서는 모든 규칙에 공통적인 구성과 사용 가능한 각 규칙을 구성하는 방법에 대해 설명합니다.
각 자동화 규칙은 자동화 리소스 구성의 일부로 구성됩니다. 이는 관련 배포 파이프라인의 구성 (일반적으로 clouddeploy.yaml
라고 함)과 동일한 파일 내 또는 원하는 파일 내에 있을 수 있습니다. 자동화 구성에 대해 자세히 알아보세요.
다음 섹션에서는 개별 자동화 규칙과 관련된 구성을 설명합니다. 자동화 자체 구성은 배포 자동화를 참조하세요.
promoteReleaseRule
자동화 규칙 구성
promoteReleaseRule
규칙은 대상으로의 성공적인 출시 후 출시 버전을 승격합니다. 예를 들어 3개의 대상이 있는 경우 출시 버전이 첫 번째 대상에 성공적으로 배포되면 자동으로 두 번째 대상으로 승격되도록 이 규칙을 설정할 수 있습니다.
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
). 이 속성은 선택사항으로, 생략하면 출시 버전이 대상의 첫 번째 단계로 승격됩니다.
timedPromoteReleaseRule
자동화 규칙 구성
timedPromoteReleaseRule
규칙을 사용하면 선택한 대상에서 진행 중인 다음 대상 또는 지정된 대상으로 출시 버전을 승격할 시점을 예약할 수 있습니다. timedPromoteReleaseRule
자동화를 구성할 때는 cron 일정에 따라 출시를 승격할 시점을 지정합니다.
rules:
- timedPromoteReleaseRule:
name: "[RULE_NAME]"
schedule: "[CRON]"
timeZone: "[TIME_ZONE]"
destinationTargetId: "[TO_TARGET]"
destinationPhase: "[TO_PHASE]"
각 항목의 의미는 다음과 같습니다.
[RULE_NAME]
이 규칙에 지정할 이름입니다. 이 이름은 전송 파이프라인 내에서 고유해야 합니다.
[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
). 이 속성은 선택사항으로, 생략하면 출시 버전이 대상의 첫 번째 단계로 승격됩니다.
advanceRolloutRule
자동화 규칙 구성
advanceRolloutRule
은 한 단계가 성공적으로 완료된 후 다음 단계로 자동으로 출시를 진행합니다. 이 자동화 규칙은 카나리아 배포에 유용합니다. 예를 들어 25%
, 50%
, stable
단계로 대상에 카나리아 배포 전략을 구성한 경우 50%
단계가 완료된 후 자동으로 stable
로 단계를 진행하는 자동화 규칙을 구성할 수 있습니다.
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의 배포 자동화 자세히 알아보기