배포 자동화

이 문서는 배포 자동화의 개요입니다.

특정 배포 파이프라인에 대한 출시 버전 관련 및 출시 관련 태스크를 자동으로 수행하도록 Cloud Deploy를 구성할 수 있습니다. 이러한 태스크에는 출시 버전 승격 및 단계별 진행이 포함됩니다.

Cloud Deploy에서 출시 버전 자동화에 사용되는 리소스에 대해 자세히 알아보세요.

이러한 자동화의 작동 방식을 정의하는 규칙을 설정하는 방법에 대해 자세히 알아보세요.

자동화할 수 있는 작업

Cloud Deploy에서 다음 출시 버전 및 출시 활동을 자동화할 수 있습니다.

  • 출시 버전 자동 승격

    대상에 성공적으로 출시되면 출시 버전을 자동으로 승격하도록 Cloud Deploy를 구성할 수 있습니다. 예를 들어 dev, staging, prod와 같이 3개의 대상이 있는 경우 staging에 성공적으로 배포되는 즉시 추가적인 인적 상호작용 없이 그러한 출시 버전이 prod로 승격되도록 자동화를 구성할 수 있습니다. 지연 시간을 지정할 수도 있습니다.

  • 일정에 따라 출시 버전 승격

    크론 일정에 따라 출시 버전을 승격하도록 Cloud Deploy를 구성할 수 있습니다.

  • 출시 진행

    이전 대상으로 성공적으로 출시한 후 한 단계에서 다음 단계로 출시를 진행하도록 Cloud Deploy를 구성할 수 있습니다. 단계별 진행은 카나리아 배포 전략을 사용하는 대상에서만 사용할 수 있습니다.

  • 출시 복구

    실패한 출시를 자동으로 재시도하도록 Cloud Deploy를 구성할 수 있습니다. 여기에는 지정된 횟수만큼 출시를 재시도하고 해당 재시도 횟수가 실패한 경우 자동으로 롤백하는 작업이 포함됩니다.

이러한 작업 및 이를 구성하는 방법에 대한 자세한 내용은 자동화 규칙을 참조하세요.

자동화는 어떻게 작동하나요?

각 자동화는 해당 자동화가 사용되는 전달 파이프라인에 연결됩니다. 여러 배포 파이프라인 간에 자동화를 공유할 수 없습니다.

다음은 자동화를 구성 및 실행하는 일반적인 프로세스입니다.

  1. 자동화 구성

    이 자동화는 하나의 배포 파이프라인과 연결됩니다.

  2. gcloud deploy apply를 사용하여 해당 자동화를 등록합니다.

    그러면 자동화 리소스가 생성됩니다.

  3. 출시를 만들어서 이 자동화와 연결된 배포 파이프라인을 호출합니다.

  4. 출시가 하나 이상의 대상에서 성공하거나 실패합니다.

    출시가 성공하면 자동화가 promoteReleaseRule입니다.

    1. 실행은 소스 대상으로의 출시가 성공할 때까지 대기합니다. 소스 대상은 AutomationRule이 아닌 자동화를 위해 구성된 selector.targets입니다.

    2. wait 시간이 구성되어 있으면 실행도 해당 시간 동안 대기합니다.

    3. 출시 버전은 파이프라인 진행의 다음 대상으로 또는 지정된 경우 특정 대상으로 자동 승격됩니다.

    출시가 성공하면 자동화가 advanceRolloutRule이고 대상에 카나리아 배포 전략이 사용됩니다.

    1. 실행 시 식별된 소스 단계가 있으면 이를 기다립니다.

      sourcePhase 속성은 선택사항이며, 소스 단계를 지정하지 않으면 출시의 각 단계가 자동으로 진행됩니다. 자동 단계 진행은 소스 단계가 IN_PROGRESS인 경우 발생하며 wait 시간이 적용됩니다.

    2. wait 시간이 구성되어 있으면 실행도 해당 시간 동안 대기합니다.

      카나리아 배포를 자동화할 때는 이 대기 시간을 사용하여 각 카나리아 단계의 기간을 지정합니다.

    3. 출시는 해당 소스 단계에서 출시의 다음 단계로 자동으로 진행됩니다.

    4. 추가 소스 단계가 있고 해당하는 경우 동일한 대기 시간을 포함하여 동일하게 처리됩니다.

    출시가 실패하면 repairRollout 규칙을 포함한 자동화가 수행됩니다.

    1. 출시는 구성된 wait 시간(있는 경우) 이후에 재시도됩니다.

      이 repairRollout 규칙에 특정 단계 또는 작업이 구성된 경우 그러한 단계 또는 작업만 재시도됩니다. 작업 또는 단계가 지정되지 않은 경우에는 기본적으로 출시에 있는 모든 단계 및 작업을 재시도합니다.

      재시도는 선택사항이기 때문에 재시도할 자동화가 구성되지 않았으면 이 단계가 수행되지 않습니다.

    2. 첫 번째 재시도가 실패하면 구성된 wait 시간 동안 실행을 기다린 후 다시 시도합니다.

    3. 재시도는 Cloud Deploy에서 재시도 attempts가 소진될 때까지 반복됩니다.

      각 시도가 실패하고 attempts가 소진되면 출시가 실패합니다.

      재시도 중 출시 상태는 최종 재시도 이후 출시가 성공하거나 실패할 때까지 IN_PROGRESS입니다. 단계 상태는 재시도 중 IN_PROGRESS이지만 각 출시가 실패한 후에는 FAILED입니다.

    4. 모든 재시도가 실패하거나 아무 것도 구성되지 않았으면 대사에서 최근 성공한 출시 버전으로 롤백하는 새로운 출시가 생성됩니다.

자동화 리소스

특히 자동화를 위한 2개의 Cloud Deploy 리소스가 있습니다.

  • 자동화

    Automation은 배포 파이프라인의 하위 리소스이며, 다음 정보를 포함합니다.

    • 자동화가 사용되는 대상에 대한 포인터
    • 자동화가 수행하는 작업과 수행 방법을 제어하는 규칙

    자동화 리소스의 구성은 자동화 리소스 정보 문서에 설명되어 있습니다.

    자동화 구성(kind: Automation)이 포함된 파일에 대해 gcloud deploy apply를 실행하면 Cloud Deploy에서 배포 파이프라인과 대상을 하나 이상의 자동화 규칙과 연결하는 자동화 리소스를 생성합니다.

  • 자동화 실행

    AutomationRun은 자동화의 인스턴스로, 해당 자동화 리소스에 대한 포인터와 이를 생성한 출시 관련 정보 및 기타 메타데이터입니다.

    자동화 실행은 자동화가 트리거될 때 생성됩니다.

자동화 리소스에 대해 자세히 알아보기

자동화 규칙

자동화 규칙은 배포 파이프라인에서 자동으로 수행할 수 있는 작업과 자동화 수행 방법에 대한 세부정보를 정의합니다.

자동화 규칙에 대해 자세히 알아보기

필수 Identity and Access Management 역할 및 권한

Cloud Deploy 배포 파이프라인을 실행하고 자동화 태스크(예: 출시 진행)를 수행할 때 필요한 권한 외에도 Automation 및 AutomationRun 리소스에 대한 특정 작업을 수행하는 데 필요한 몇 가지 권한이 있습니다.

  • clouddeploy.automations.create
  • clouddeploy.automations.delete
  • clouddeploy.automations.get
  • clouddeploy.automations.list
  • clouddeploy.automations.update
  • clouddeploy.automationRuns.cancel
  • clouddeploy.automationRuns.get
  • clouddeploy.automationRuns.list

이러한 권한 외에도 각 자동화 규칙에는 자동화된 작업을 수행하기 위한 추가 권한이 필요할 수 있습니다. 자동화 규칙별로 필요한 특정 권한에 대해서는 자동화 규칙 구성을 참조하세요.

이러한 권한이 포함된 Cloud Deploy 역할을 비롯한 자세한 내용은 IAM 역할 및 권한을 참조하세요.

자동화 만들기

자동화를 구성한 다음 gcloud deploy apply를 사용하여 자동화 리소스를 만들어 사용 가능한 자동화 규칙을 사용하는 자동화를 만들 수 있습니다.

다음 섹션(자동 구성) 및 자동화 규칙 구성을 참조하세요.

자동화 구성

Automation 리소스 구성 방법에 대한 자세한 내용은 구성 파일 스키마를 참조하세요.

자동화 규칙 구성

이 자동화 구성 외에도 자동화 규칙을 지정합니다. 구성은 사용 가능한 각 규칙마다 다릅니다.

사용 가능한 각 규칙에 대한 설명은 자동화 규칙 사용을 참조하세요.

자동화 일시중지

기존 리소스를 삭제하지 않고 일시중지할 수 있습니다. 이는 배포 파이프라인에 영향을 주지 않고 자동화를 테스트하는 데 유용할 수 있습니다. 자동화를 정지하면 자동화가 실행되지 않지만 플랫폼 로그는 계속 생성됩니다.

  1. Automation 구성에서 suspended 속성을 true로 업데이트합니다.

  2. 이 구성 파일에 대해 gcloud deploy apply를 실행합니다.

  3. 플랫폼 로그는 자동화가 정지된 경우에도 자동화가 인스턴스화되면 계속 생성됩니다. 이를 통해 배포 파이프라인에 영향을 주지 않고 자동화를 테스트하고 디버깅할 수 있습니다.

다음 단계