DevOps/AWS

AWS CodeDeploy

devdubu 2025. 4. 14. 11:29
해당 본문은 AWS CodeDeploy의 공식 문서를 발췌하여 작성한 내용입니다.
오역과 오타가 있을 수 있습니다, 해당 부분을 댓글로 알려주시면 감사하겠습니다.

CodeDeploy

CodeDeploy에 대한 개념과 사용 방법에 대한 내용을 기술하는 문서 입니다.

 

CodeDeploy는 Amazon EC2 인스턴스, 온프레미스 인스턴스, 서버리스 Lambda 함수 또는 Amazon ECS 서비스로 애플리케이션 배포를 자동화하는 배포 서비스입니다.

CodeDeploy의 이점

배포 자동화

  • CodeDeploy는 개발, 테스트 및 프로덕션 환경에 걸쳐 애플리케이션 배포를 완전 자동화합니다.
  • CodeDeploy는 인프라에 맞춰 규모를 조정할 수 있으므로 인스턴스 하나 또는 수천 개에 배포할 수 있습니다.

가동 중지 최소화

  • 애플리케이션이 EC2/온프레미스 컴퓨팅 플랫폼을 사용하는 경우 CodeDeploy는 애플리케이션 가용성을 극대화합니다.
  • 인 플레이스(In-place) 배포에서 CodeDeploy는 Amazon EC2 인스턴스 전체에 대해 롤링 업데이트를 수행합니다.
  • 업데이트 시 오프라인 상태가 될 수 있는 인스턴스 수를 지정할 수 있습니다.
  • 블루/그린 배포 시에는 최신 애플리케이션 수정이 대체 인스턴스에 설치됩니다.
    • 선택한 경우 새로운 환경 테스트를 완료한 직후 이러한 인스턴스로 트래픽이 다시 라우팅됩니다.
    • 두 가지 배포 유형에 대해 CodeDeploy는 사용자가 구성한 규칙에 따라 애플리케이션 상태를 추적합니다.

중지 및 롤백

  • 오류가 있는 경우 자동 또는 수동으로 배포를 중지하고 롤백할 수 있습니다.

중앙 집중식 제어

  • CodeDeploy 콘솔 또는 AWS CLI를 통해 배포 상태를 시작 및 추적할 수 있습니다.
  • 각 애플리케이션 개정이 배포된 시점 및 Amazon EC2 인스턴스가 나열된 보고서가 제공됩니다.

채택 편의성

  • CodeDeploy는 플랫폼과 관련된 제약이 없으므로 모든 애플리케이션과 작동합니다.
  • 사용자는 설정 코드를 쉽게 재 사용할 수 있습니다.
  • 또한 CodeDeploy는 소프트웨어 릴리스 프로세스 또는 지속적 전달 도구 체인과 통합이 가능합니다.

동시 배포

  • EC2/온프레미스 컴퓨팅 플랫폼을 사용하는 1개 이상의 애플리케이션이 있는 경우에는 CodeDeploy를 통해 동일한 인스턴스 세트에 동시에 배포할 수 있습니다.

CodeDeploy 배포 유형

인 플레이스 배포

AWS Lambda 및 Amazon ECS 배포는 인 플레이스 배포 유형을 사용할 수 없습니다.

  1. 로컬 개발 머신 또는 유사한 환경에서 배포 가능한 콘텐츠를 만든 다음 application specification file(AppSpec 파일)을 추가합니다.
    1. AppSpec 파일은 CodeDeploy에서만 사용 가능 하며, CodeDeploy가 실행하게 하려는 배포 작업을 정의합니다.
  2. 다음으로, CodeDeploy에 배포에 관한 정보를 제공합니다
    1. (예: 개정을 풀링하려는 Amazon S3 버킷 또는 GitHub 리포지토리 및 개정의 내용을 배포하려는 Amazon EC2 인스턴스 세트).
    2. CodeDeploy에서는 Amazon EC2 인스턴스 세트를 배포 그룹이라고 합니다.
    3. 배포 그룹에는 개별적으로 태그가 지정된 Amazon EC2 인스턴스, Amazon EC2 Auto Scaling 그룹의 Amazon EC2 인스턴스 또는 둘 다가 포함됩니다.
    4. 배포 그룹에 배포하려는 새 애플리케이션 수정을 성공적으로 업로드할 때마다 번들이 배포 그룹의 대상 수정으로 설정됩니다.
    5. 다시 말해 현재 배포의 대상으로 지정된 애플리케이션 수정이 대상 수정입니다. 또한 이 수정은 자동 배포를 위해 풀링되는 수정입니다.
  3. 다음으로, 각 인스턴스의 CodeDeploy 에이전트가 CodeDeploy를 폴링하여 지정된 Amazon S3 버킷 또는 GitHub 리포지토리에서 풀링할 항목 및 시점을 결정합니다.
  4. 마지막으로, 각 인스턴스의 CodeDeploy 에이전트가 Amazon S3 버킷 또는 GitHub 리포지토리에서 대상 개정을 풀링하고 AppSpec 파일의 지침을 따르면 콘텐츠가 인스턴스에 배포됩니다.
    1. CodeDeploy는 배포에 대한 레코드를 유지하므로 배포 상태, 배포 구성 파라미터, 인스턴스 상태를 확인할 수 있습니다.

블루 / 그린 배포

블루/그린 배포는 새 애플리케이션 버전의 변경으로 인한 중단을 최소화하면서 애플리케이션을 업데이트하는 데 사용됩니다.

CodeDeploy 주요 구성 요소

애플리케이션

  • 애플리케이션은 배포할 애플리케이션을 식별할 수 있는 고유 이름입니다.
  • CodeDeploy는 컨테이너 역할을 하는 이 이름을 사용하여 배포 중에 수정 버전, 배포 구성 및 배포 그룹의 올바른 조합을 참조하도록 합니다.

컴퓨팅 플랫폼

EC2 / 온 프레미스

  • 물리적 서버의 인스턴스를 설명합니다.
    • Amazon EC2 클라우드 인스턴스나 온프레미스 서버 또는 둘 다일 수 있습니다.
  • EC2/온프레미스 컴퓨팅 플랫폼을 사용하여 만든 애플리케이션은 실행 파일과 구성 파일, 이미지 및 기타 항목으로 구성될 수 있습니다.
  • EC2/온프레미스 컴퓨팅 플랫폼을 사용하는 배포에서는 인 플레이스 또는 블루/그린 배포 유형을 사용하여 인스턴스로 트래픽이 전송되는 방식을 관리합니다.

AWS Lambda

  • 업데이트 버전의 Lambda 함수로 구성된 애플리케이션을 배포하는 데 사용됩니다.
  • AWS Lambda는 고가용성 컴퓨팅 구조의 서버리스 컴퓨팅 환경에서 Lambda 함수를 관리합니다.
  • 컴퓨팅 리소스에 대한 모든 관리는 AWS Lambda를 통해 수행됩니다.
  • 카나리(Canary), 선형(Linear) 또는 한 번에 모두(All-at-once) 구성을 선택하여 업데이트된 Lambda 함수 버전으로 트래픽을 전송하는 방식을 관리할 수 있습니다.

Amazon ECS

  • Amazon ECS 컨테이너화된 애플리케이션을 작업 세트로 배포하는 데 사용됩니다.
  • CodeDeploy는 애플리케이션의 업데이트 버전을 새로운 대체 작업 세트로 설치하여 블루/그린 배포를 수행합니다.
  • CodeDeploy는 프로덕션 트래픽을 원래 애플리케이션 작업 세트에서 대체 작업 세트로 다시 라우팅합니다.

배포 구성

배포 중 CodeDeploy에서 사용하는 배포 규칙과 배포 성공 및 실패 조건 집합입니다.

EC2/온프레미스 컴퓨팅 플랫폼

  • 해당 배포에 대해 정상 인스턴스의 최소 개수를 지정할 수 있습니다.

AWS Lambda 또는 Amazon ECS

  • 업데이트된 Lambda 함수 또는 ECS 태스크 집합으로 트래픽을 라우팅하는 방식을 지정할 수 있습니다.
    • 카나리(Canary)
      • 트래픽이 두 증분으로 나뉘어 이동합니다.
      • 첫 번째 증분에서 업데이트된 Lambda 함수 또는 ECS 태스크로 이동할 트래픽의 백분율 및 두 번째 증분에서 나머지 트래픽의 이동을 시작하기 전까지 간격(분)을 지정하는 사전 정의된 카나리(Canary) 옵션 중에서 선택할 수 있습니다.
    • 리니어(Linear)
      • 트래픽이 동일한 증분 이동하며 각 증분 간에 시간 간격(분)이 동일합니다.
      • 각 증분에서 이동할 트래픽 비율(%)과 각 증분 간의 시간 간격(분)을 지정하는 사전 정의된 선형 옵션에서 선택할 수 있습니다.
    • 한 번에 모두(All-at-once)
      • 모든 트래픽이 원본 Lambda 함수 또는 ECS 태스크 집합에서 업데이트된 함수 또는 태스크 집합으로 전부 한꺼번에 이동합니다.

배포 그룹

개별 인스턴스 집합입니다.

  • 배포 그룹에는 개별적으로 태그가 지정된 인스턴스, Amazon EC2 Auto Scaling 그룹의 Amazon EC2 인스턴스 또는 둘 다가 포함됩니다.

배포 유형

배포 유형이란 배포 그룹의 인스턴스에서 최신 애플리케이션 수정 버전을 사용 가능하게 만드는 방법입니다.

현재 위치 배포

  • 배포 그룹의 각 인스턴스에 있는 애플리케이션이 중지되고 최신 애플리케이션 개정 버전이 설치되며 애플리케이션의 새 버전이 시작되고 유효성이 검사됩니다.
  • 로드 밸런서를 사용하면 배포가 진행될 때 각 인스턴스를 등록 취소한 후 배포가 완료된 후 서비스로 복원할 수 있습니다.
  • EC2/온프레미스 컴퓨팅 플랫폼을 사용하는 배포만 인 플레이스 배포를 사용할 수 있습니다.

Blue/Green 배포

EC2 / 온프레미스

  • 인스턴스는 대체 환경을 위해 프로비저닝됩니다.
  • 최신 애플리케이션 수정은 대체 인스턴스에 설치됩니다.
  • 애플리케이션 테스트 및 시스템 검증과 같은 활동에 선택적 대기 시간이 발생합니다.
  • 대체 환경의 인스턴스가 Elastic Load Balancing 로드 밸런서에 등록되고 트래픽이 이러한 인스턴스로 라우팅됩니다.
    • 원래 환경의 인스턴스는 등록이 취소되고 종료되거나 다른 용도로 계속 실행될 수 있습니다.

AWS Lambda 또는 Amazon ECS 컴퓨팅

  • 트래픽이 Canary(카나리), Linear(리니어) 또는 All-at-once(한 번에 모두) 배포 구성에 따라 증분 이동합니다.

AWS CloudFormation을 통한 블루/그린 배포

  • AWS CloudFormation 스택 업데이트의 일부로 트래픽이 현재 리소스에서 업데이트된 리소스로 이동합니다.
  • 현재는 ECS 블루/그린 배포만 지원됩니다.

CodeDeploy 배포

Amazon ECS 배포

ECS 배포 시작 전

Amazon ECS 애플리케이션 배포를 시작하기 전에 다음을 준비해야 합니다.
일부 요구 사항은 배포 그룹을 만들 때 지정되고, 일부는 AppSpec 파일에 지정됩니다.

요구사항 지정되는 위치
Amazon ECS 클러스터 배포 그룹
Amazon ECS 서비스 배포 그룹
Application Load Balancer or Network Load Balancer 배포 그룹
프로덕션 리스너 배포 그룹
테스트 리스너(선택 사항) AppSpec 파일
Amazon ECS 작업 정의 AppSpec 파일
컨테이너 이름 AppSpec 파일
컨테이너 포트 AppSpec 파

Amazon ECS 클러스터

  • Amazon ECS 클러스터는 작업 또는 서비스의 논리적 그룹입니다.
  • CodeDeploy 애플리케이션의 배포 그룹을 만들 때 Amazon ECS 서비스가 포함된 Amazon ECS 클러스터를 지정합니다.

Amazon ECS 서비스

  • Amazon ECS 서비스는 Amazon ECS 클러스터에서 지정된 작업 정의 인스턴스를 유지하고 실행합니다.
    • Amazon ECS 서비스는 CodeDeploy에서 활성화되어 있어야 합니다.
  • 배포 그룹을 만들 때 Amazon ECS 클러스터에 있는 Amazon ECS 서비스를 배포하도록 선택합니다.

Application Load Balancer OR Network Load Balancer

  • Amazon ECS 배포로 업데이트하려는 Amazon ECS 서비스에서 Elastic Load Balancing을 사용해야 합니다.
    • Application Load Balancer 또는 Network Load Balancer를 사용할 수 있습니다.
  • 동적 포트 매핑 및 경로 기반 라우팅과 우선순위 규칙 등의 기능을 활용할 수 있도록 Application Load Balancer를 사용하는 것이 좋습니다.
    • CodeDeploy 애플리케이션의 배포 그룹을 만들 때 로드 밸런서를 지정합니다.

프로덕션 리스너

  • 리스너는 로드 밸런서가 대상 그룹으로 트래픽을 보내기 위해 사용합니다.
    • 프로덕션 리스너 한 개는 필수입니다.
  • 확인 테스트를 실행하는 동안 대체 작업 세트로 트래픽을 보내는 두 번째 테스트 리스너(선택 사항)를 지정할 수 있습니다.
    • 배포 그룹을 만들 때 리스너를 한 개 또는 두 개 지정합니다.
  • Amazon ECS 콘솔을 사용하여 Amazon ECS 서비스를 생성하는 경우, 리스너가 자동으로 생성됩니다.

2개의 Amazon ECS 대상 그룹

  • 대상 그룹은 등록된 대상으로 트래픽을 라우팅하는 데 사용됩니다.
  • Amazon ECS 배포에는 대상 그룹이 2개 필요합니다.
    • 하나는 Amazon ECS 애플리케이션의 원래 작업 세트 용이고 다른 하나는 대체 작업 세트 용입니다.
  • 배포 중에 CodeDeploy는 대체 작업 세트를 만들고 원래 작업 세트에서 새 작업 세트로 트래픽을 다시 라우팅합니다.
    • CodeDeploy 애플리케이션의 배포 그룹을 만들 때 대상 그룹을 지정합니다.
    • 배포 중에 CodeDeploy는 상태가 PRIMARY인 Amazon ECS 서비스의 작업 세트(원래 작업 세트)와 연결된 대상 그룹을 확인하고 대상 그룹 하나를 이 작업 세트와 연결한 후 다른 대상 그룹을 대체 작업 세트와 연결합니다.
  • 다른 배포를 수행하는 경우, 현재 배포의 원래 작업 세트와 연결된 대상 그룹은 다음 배포의 대체 작업 세트와 연결됩니다.

Amzon ECS 작업 정의

  • 작업 정의는 Amazon ECS 애플리케이션이 포함된 도커 컨테이너를 실행하는 데 필요합니다.
  • CodeDeploy 애플리케이션의 AppSpec 파일에서 작업 정의의 ARN을 지정합니다.

Amzon ECS 애플리케이션의 컨테이너

  • Docker 컨테이너란 애플리케이션이 실행될 수 있도록 코드와 해당 종속성을 패키징하는 소프트웨어 단위를 말합니다.
    • 컨테이너는 애플리케이션을 격리하므로 애플리케이션이 다른 컴퓨팅 환경에서도 실행됩니다.
  • 로드 밸런서는 Amazon ECS 애플리케이션 작업 세트의 컨테이너로 트래픽을 보냅니다.
  • CodeDeploy 애플리케이션의 AppSpec 파일에서 컨테이너의 이름을 지정합니다.
    • AppSpec 파일에 지정된 컨테이너는 Amazon ECS 작업 정의에 지정된 컨테이너 중 하나 여야 합니다.

대체 작업 세트의 포트

  • Amazon ECS 배포 중에 로드 밸런서가 CodeDeploy 애플리케이션의 AppSpec 파일에 지정된 이 포트로 트래픽을 보냅니다.

Amazon ECS 컴퓨팅 플랫폼의 배포 워크 플로

  • 다음 다이어그램은 업데이트된 Amzon ECSa 서비스 배포의 기본 단계를 보여줍니다.

  1. 배포하려는 항목을 고유하게 나타내는 이름을 지정하여 AWS CodeDeploy 애플리케이션을 만듭니다.
    1. Amazon ECS 애플리케이션을 배포하려면 AWS CodeDeploy 애플리케이션에서 Amazon ECS 컴퓨팅 플랫폼을 선택합니다.
    2. CodeDeploy는 배포 중에 애플리케이션을 사용하여 배포 그룹, 대상 그룹, 리스너, 트래픽 다시 라우팅 동작, 애플리케이션 개정 등의 올바른 배포 구성 요소를 참조합니다.
  2. 다음을 지정하여 배포 그룹을 설정합니다.
    1. 배포 그룹 이름
    2. Amazon ECS 클러스터와 서비스 이름.
      1. Amazon ECS 서비스의 배포 컨트롤러는 CodeDeploy로 설정되어야 합니다.
    3. 배포 중에 사용되는 프로덕션 리스너, 테스트 리스너(선택 사항), 대상 그룹
    4. 배포 설정
      1. 예: Amazon ECS 서비스의 대체 Amazon ECS 작업 세트로 프로덕션 트래픽을 다시 라우팅할 시기 및 Amazon ECS 서비스의 원래 Amazon ECS 작업 세트를 종료할 시기
    5. 설정(선택 사항)
      1. 예: 트리거, 경보, 롤백 동작
  3. 애플리케이션 사양 파일(AppSpec 파일)을 지정합니다.
    1. 파일을 Amazon S3에 업로드하거나, 콘솔에 YAML 또는 JSON 형식으로 입력하거나, AWS CLI 또는 SDK로 지정할 수 있습니다.
    2. AppSpec 파일은 배포에 사용되는 Amazon ECS 작업 정의, 트래픽을 라우팅하는 데 사용되는 포트 매핑과 컨테이너 이름, 배포 수명 주기 후크 후 실행되는 Lambda 함수를 지정합니다.
    3. 컨테이너 이름은 Amazon ECS 작업 정의의 컨테이너여야 합니다.
  4. 애플리케이션을 배포합니다.
    1. AWS CodeDeploy는 Amazon ECS 서비스의 원래 작업 세트 버전에서 새로운 대체 작업 세트로 트래픽을 다시 라우팅합니다.
    2. 배포 그룹에 지정된 대상 그룹은 원래 및 대체 작업 세트에 트래픽을 제공하는 데 사용됩니다.
    3. 배포가 완료되면 원래 작업 세트가 종료됩니다.

Amazon ECS 배포 중에 발생하는 일

  • 다음 다이어그램은 Amazon ECS 배포를 시작하려면 먼저 구성 요소를 구성 해야 합니다.

  • 배포가 시작되면 배포 수명 주기 이벤트가 한 번에 하나씩 실행되기 시작합니다.
  • 일부 수명 주기 이벤트는 AppSpec 파일에서 지정된 Lambda 함수만 실행하는 후크입니다.
  • 다음 표의 배포 수명 주기 이벤트는 실행 순서대로 나열되어 있습니다.
   
수명 주기 이벤트 수명 주기 이벤트 작업
BeforeInstall(Lambda 함수 후크) Lambda 함수 실행
Install 대체 작업 세트를 설정합니다.
AfterInstall(Lambda 함수 후크) Lambda 함수 실행
AllowTestTraffic 트래픽을 테스트 리스너에서 대상 그룹 2로 라우팅합니다.
AfterAllowTestTraffic(Lambda 함수 후크) Lambda 함수 실행
BeforeAllowTraffic(Lambda 함수 후크) Lambda 함수 실행
AllowTraffic 트래픽을 프로덕션 리스너에서 대상 그룹 2로 라우팅합니다.
AfterAllowTraffic Lambda 함수 실행
  1. AppSpec 파일의 BeforeInstall 후크에서 지정한 Lambda 함수를 실행합니다.
  2. Install 수명 주기 이벤트 도중
    1. 대체 작업 세트가 Amazon ECS 서비스에 생성됩니다.
    2. 업데이트된 컨테이너화 애플리케이션이 대체 작업 세트에 설치됩니다.
    3. 두 번째 대상 그룹이 대체 작업 세트와 연결됩니다.

아래 다이어그램은 새로운 대체 작업 세트와 함께 배포 구성 요소를 나타낸 것입니다.

  1. AppSpec 파일의 AfterInstall 후크에서 지정한 Lambda 함수를 실행합니다.
  2. AllowTestTraffic 이벤트가 호출됩니다.
    1. 수명 주기 이벤트 과정에서 테스트 리스너가 트래픽을 업데이트된 컨테이너화 애플리케이션으로 라우팅합니다.

  1. AppSpec 파일의 AfterAllowTestTraffic 후크에서 지정한 Lambda 함수를 실행합니다.
    1. Lambda 함수는 테스트 트래픽을 사용해 배포를 검증할 수 있습니다.
    2. 예를 들어 Lambda 함수는 트래픽을 테스트 리스너까지 전송한 후 대체 작업 세트에서 지표를 추적할 수 있습니다.
    3. 롤백이 구성된 경우에는 Lambda 함수에서 검증 테스트에 실패할 경우 롤백을 트리거하는 CloudWatch 경보를 구성할 수 있습니다.
  • 검증 테스트가 완료되면 다음 중 한 가지가 발생합니다.
    • 검증에 실패하고 롤백이 구성된 경우 배포 상태가 Failed로 표시되고 구성 요소는 배포가 시작되었던 상태로 돌아갑니다.
    • 검증에 실패하였지만 롤백이 구성되어 있지 않다면 배포 상태가 Failed로 표시되고 구성 요소는 현재 상태를 유지합니다.
    • 검증에 성공한 경우에는 배포가 BeforeAllowTraffic 후크까지 이어집니다.
  1. AppSpec 파일의 BeforeAllowTraffic 후크에서 지정한 Lambda 함수를 실행합니다.
  2. AllowTraffic 이벤트가 호출됩니다.
    1. 프로덕션 트래픽이 원래 작업 세트에서 대체 작업 세트로 다시 라우팅됩니다.
    2. 다음 다이어그램은 프로덕션 트래픽을 수신하는 대체 작업 세트를 나타낸 것입니다.

  1. AppSpec 파일의 AfterAllowTraffic 후크에서 지정한 Lambda 함수를 실행합니다.
  2. 모든 이벤트에 성공하면 배포 상태가 Succeeded로 설정되고 원래 작업 세트는 제거됩니다.

EC2 / 온프레미스 컴퓨팅 플랫폼의 배포

EC2 / 온프레미스 컴퓨팅 플랫폼의 배포 워크 플로

  • 다음 다이어그램은 애플리케이션 개정 배포의 주요 단계를 보여줍니다.

고유 이름 지정

  • 애플리케이션을 생성하고 배포하려는 애플리케이션 업데이트 버전과 애플리케이션의 컴퓨팅 플랫폼을 고유하게 식별하는 이름을 지정합니다.
    • CodeDeploy에서는 배포 중 이 이름을 사용하여 해당 배포가 올바른 배포 구성 요소(예: 배포 그룹, 배포 구성 및 애플리케이션 개정)를 참조하도록 합니다.

배포 유형 그룹 지정

  • 애플리케이션 개정을 배포하려는 인스턴스 및 배포 유형을 지정하여 배포 그룹을 설정합니다.
  • 인스턴스, Amazon EC2 Auto Scaling 그룹 이름 또는 둘 다에 적용되는 태그를 지정할 수 있습니다.
    • 배포 그룹에 하나의 태그 그룹을 지정한 경우, CodeDeploy에서는 최소 한 개의 지정된 태그가 적용된 인스턴스를 배포합니다.
    • 2개 이상의 태그 그룹을 지정한 경우 CodeDeploy는 각 태그 그룹의 기준에 맞는 인스턴스만 배포합니다.
  • 어떤 경우든 인스턴스는 배포에 사용하도록 구성되어야 하며(즉, 태그가 지정되거나 Amazon EC2 Auto Scaling 그룹에 속해야 함), CodeDeploy 에이전트를 설치하여 실행 중이어야 합니다.

다음 옵션도 지정할 수 있습니다.

  • Amazon SNS 알림
  • 배포 및 인스턴스에서 지정된 이벤트(예: 성공 또는 실패 이벤트)가 발생하면 Amazon SNS 주제 구독자에게 알림을 보내는 트리거를 만듭니다.
  • 경보 기반 배포 및 관리
  • 지표가 CloudWatch에 설정된 임계값을 초과하거나 임계값 미만인 경우 배포를 중지하는 Amazon CloudWatch 경보 모니터링을 구현합니다.
  • 자동 배포 롤백
  • 배포에 실패하거나 경보 임계값에 도달한 경우 이전에 알려진 양호한 상태의 어플리케이션으로 자동 롤백되도록 배포를 구성합니다.

인프레이스 배포

  • 최신 애플리케이션 개정으로 인스턴스를 업데이트합니다.

블루 / 그린 배포

  • 로드 밸런서에 배포 그룹의 대체 인스턴스 세트를 등록하고 원본 인스턴스의 등록을 취소합니다.

배포 구성 지정

  • 애플리케이션 개정을 동시에 배포해야 할 인스턴스 수와 배포 성공 및 실패 조건을 설정하는 배포 구성을 지정합니다.

업데이트할 애플리케이션 업로드

  • 업데이트할 애플리케이션을 Amazon S3 또는 GitHub로 업로드합니다.
    • 배포하려는 파일 및 배포 중 실행하려는 모든 스크립트 이외에 애플리케이션 사양 파일(AppSpec file)을 포함해야 합니다.
  • 이 파일에는 각 인스턴스에 파일을 복사할 위치 및 배포 스크립트를 실행할 시점 등과 같은 배포 명세가 포함되어 있습니다.

배포 그룹에 배포

  • 업데이트할 애플리케이션을 배포 그룹에 배포합니다.
  • 배포 그룹의 각 인스턴스에 설치된 CodeDeploy 에이전트는 애플리케이션 개정을 Amazon S3 또는 GitHub에서 인스턴스로 복사합니다.
  • 그런 다음 CodeDeploy 에이전트는 개정의 번들을 해제하고, AppSpec 파일을 사용하여 지정한 위치로 파일을 복사하고, 배포 스크립트를 실행합니다.

배포 확인 후

  • 소스 콘텐츠에서 버그를 수정하거나, 배포 스크립트를 다른 순서로 실행하거나, 실패한 배포를 해결해야 하는 경우 다시 배포하려고 할 수 있습니다.
  • 다시 배포하려면 수정된 소스 콘텐츠, 배포 스크립트, AppSpec 파일을 새 개정으로 다시 번들링한 다음 해당 개정을 Amazon S3 버킷 또는 GitHub 리포지토리로 업로드합니다.
  • 그런 다음 새로 업데이트된 어플리케이션을 사용하여 동일한 배포 그룹으로 새로 배포를 실행합니다.

EC2 / 온프레미스 배포용 AppSpec 파일 예제

version: 0.0
os: linux
files: 
  - source: Config/config.txt 
    destination: /webapps/Config 
  - source: source 
    destination: /webapps/myApp
hooks: 
  BeforeInstall: 
    - location: Scripts/UnzipResourceBundle.sh 
    - location: Scripts/UnzipDataBundle.sh 
  AfterInstall: 
    - location: Scripts/RunResourceTests.sh 
      timeout: 180 
  ApplicationStart: 
    - location: Scripts/RunFunctionalTests.sh 
      timeout: 3600 
  ValidateService: 
    - location: Scripts/MonitorService.sh 
      timeout: 3600 
      runas: codedeployuser
  1. Scripts/UnzipResourceBundle.sh에 있는 스크립트를 실행합니다.
  2. 이전 스크립트가 종료 코드 0(성공)을 반환한 경우 이 스크립트를 Scripts/UnzipDataBundle.sh에서 실행합니다.
  3. Config/config.txt 경로의 파일을 /webapps/Config/config.txt 경로로 복사합니다.
  4. source 디렉터리의 파일을 /webapps/myApp 디렉터리로 모두 복사합니다.
  5. Scripts/RunResourceTests.sh에 있는 스크립트를 실행합니다.
    1. 제한 시간은 180초(3분)입니다.
  6. Scripts/RunFunctionalTests.sh에 있는 스크립트를 실행합니다.
    1. 제한 시간은 3600초(1시간)입니다.
  7. Scripts/MonitorService.sh에 있는 스크립트를 사용자 codedeploy로 실행합니다.
    1. 제한 시간은 3600초(1시간)입니다.

CodeDeploy 배포 구성

EC2 / 온프레미스 컴퓨팅 플랫폼에 대한 배포 구성

배포 구문 설명
CodeDeployDefault.AllAtOnce 인 플레이스(in-place) 배포

- 한 번에 가급적 많은 수의 인스턴스에 애플리케이션 개정을 배포하기 위한 시도입니다.

- 하나 이상의 인스턴스에 애플리케이션 개정이 배포되면 전체 배포 상태가 성공으로 표시됩니다.

- 어떤 인스턴스에도 애플리케이션 개정이 배포되지 않으면 전체 배포 상태가 실패로 표시됩니다.

- 아홉 개의 인스턴스가 있는 예제에서CodeDeployDefault.AllAtOnce는 한 번에 아홉 개의 인스턴스 모두에 배포를 시도합니다.

- 인스턴스 하나에라도 배포에 성공하면 전체 배포가 성공합니다. 아홉 개 인스턴스 모두에 대한 배포에 실패하는 경우에만 실패합니다.


블루/그린 배포

- 대체 환경으로 배포

- 인 플레이스(in-place) 배포의 CodeDeployDefault.AllAtOnce와 동일한 배포 규칙을 따릅니다.


- 트래픽 라우팅

- 한 번에 대체 환경의 모든 인스턴스로 트래픽을 라우팅합니다.

- 트래픽이 하나 이상의 인스턴스로 성공적으로 라우팅되면 성공합니다.

- 모든 인스턴스로 다시 라우팅하지 못하며 실패합니다.
CodeDeployDefault.HalfAtATime 인 플레이스(in-place) 배포

- 최대 절반의 인스턴스(분수는 반내림함)에 한번에 배포합니다.

- 애플리케이션 개정이 인스턴스의 절반 이상(분수는 반올림함)에 배포되면 전체 배포가 성공합니다.

- 그렇지 않으면 배포가 실패합니다.


블루 / 그린 배포

- 대체 환경으로 배포

- 인 플레이스(in-place) 배포의 CodeDeployDefault.HalfAtATime과 동일한 배포 규칙을 따릅니다.


- 트래픽 라우팅

- 한 번에 대체 환경의 인스턴스 중 최대 절반으로 트래픽을 라우팅합니다.

- 인스턴스 중 절반 이상으로의 다시 라우팅에 성공하는 경우 성공합니다.

- 그렇지 않으면 가 실패합니다.
CodeDeployDefault.OneAtATime 인 플레이스(in-place) 배포

- 인스턴스가 두 개 이상 포함된 배포 그룹

- 애플리케이션이 모든 인스턴스에 배포되면 전체 배포가 성공입니다.

- 이 규칙의 예외는 마지막 인스턴스에 대한 배포에 실패했는데 전체 배포에 성공하는 경우입니다.

- 이는 CodeDeploy가 CodeDeployDefault.OneAtATime 구성을 사용하여 한 번에 한 인스턴스만 오프라인 상태가 되도록 허용하기 때문입니다.

- 애플리케이션이 마지막 인스턴스를 제외한 모든 인스턴스에 배포되지 못하면 즉시 전체 배포에 실패합니다.


블루 / 그린 배포

- 대체 환경으로 배포

- 인 플레이스(in-place) 배포의 CodeDeployDefault.OneAtATime과 동일한 배포 규칙을 따릅니다.


#### 트래픽 라우팅

- 한 번에 대체 환경의 인스턴스 하나로 트래픽을 라우팅합니다.

- 트래픽이 모든 대체 인스턴스로 성공적으로 라우팅되면 성공합니다.

- 맨 처음으로 다시 라우팅하지 못하면 실패합니다.

- 이 규칙의 예외는 마지막 인스턴스 등록에 실패했는데 전체 배포에 성공하는 경우입니다.

Amazon ECS 컴퓨팅 플랫폼에 대한 배포 구성

Amazon ECS 컴퓨팅 플랫폼에 배포할 때 배포 구성은 트래픽이 업데이트된 Amazon ECS 작업 세트로 이동되는 방법을 지정합니다.

카나리(Canary), 리니어(Linear) 또는 한 번에 모두(All-at-once) 배포 구성을 사용하여 트래픽을 이동할 수 있습니다.

   
배포 구성 설명
CodeDeployDefault.ECSLinear10PercentEvery1Minutes 모든 트래픽이 전환될 때까지 트래픽의 10%가 매 분마다 전환됩니다.
CodeDeployDefault.ECSLinear10PercentEvery3Minutes 모든 트래픽이 전환될 때까지 트래픽의 10%가 3분마다 전환됩니다.
CodeDeployDefault.ECSCanary10Percent5Minutes 첫 번째 증분에 트래픽의 10%가 전환됩니다.

나머지 90%는 5분 이후 배포됩니다.
CodeDeployDefault.ECSCanary10Percent15Minutes 첫 번째 증분에 트래픽의 10%가 전환됩니다.

나머지 90%는 15분 이후 배포됩니다.
CodeDeployDefault.ECSAllAtOnce 모든 트래픽을 업데이트 된 Amazon ECS 컨테이너로 한 번에 이동합니다.

 

'DevOps > AWS' 카테고리의 다른 글

AWS CodePipeline  (0) 2025.04.14
AWS CodeBuild  (1) 2025.04.14
AWS Elastic Beanstalk  (0) 2025.04.14
AWS RDS  (0) 2025.04.14
AWS IAM  (0) 2023.08.05

'DevOps/AWS'의 다른글

  • 현재글AWS CodeDeploy

관련글

티스토리툴바