기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # CodeDeploy란 무엇인가요? CodeDeploy는 Amazon EC2 인스턴스, 온프레미스 인스턴스, 서버리스 Lambda 함수 또는 Amazon ECS 서비스로 애플리케이션 배포를 자동화하는 배포 서비스입니다. 다음을 포함하여 다양한 애플리케이션 콘텐츠를 거의 무제한으로 배포할 수 있습니다. + 코드 + 서버리스 AWS Lambda 함수 + 웹 및 구성 파일 + Executables + Packages + 스크립트 + 멀티미디어 파일 CodeDeploy는 서버에서 실행되고 Amazon S3 버킷, GitHub 리포지토리 또는 Bitbucket 리포지토리에 저장되는 애플리케이션 콘텐츠를 배포할 수 있습니다. 또한 CodeDeploy는 서버리스 Lambda 함수를 배포할 수 있습니다. CodeDeploy를 사용하기 위해 기존 코드를 변경할 필요가 없습니다. CodeDeploy를 사용하면 다음 작업을 쉽게 수행할 수 있습니다. + 새 기능을 신속하게 출시. + AWS Lambda 함수 버전을 업데이트합니다. + 애플리케이션 배포 시 가동 중지 방지 + 오류가 발생하는 수동 배포와 관련된 다양한 위험 없이 애플리케이션 업데이트에 따른 복잡성 처리. 이 서비스는 인프라와 함께 규모를 조정할 수 있으므로 인스턴스 하나 또는 수천 개에 쉽게 배포할 수 있습니다. CodeDeploy는 구성 관리, 소스 제어, [지속적인 통합](https://aws.amazon.com/devops/continuous-integration/), [지속적인 전송](https://aws.amazon.com/devops/continuous-delivery/) 및 지속적인 배포 등을 위해 다양한 시스템과 함께 작동합니다. 자세한 내용은 [제품 통합](https://aws.amazon.com/codedeploy/product-integrations/)을 참조하세요. CodeDeploy 콘솔에서 리포지토리, 구축 프로젝트, 배포 애플리케이션 및 파이프라인과 같은 리소스를 신속하게 검색할 수도 있습니다. **리소스로 이동**을 선택하거나 `/` 키를 누른 후 리소스 이름을 입력하세요. 목록에 일치 항목이 나타납니다. 검색은 대/소문자를 구분하지 않습니다. 보기 권한이 있는 리소스만 표시됩니다. 자세한 내용은 [에 대한 자격 증명 및 액세스 관리 AWS CodeDeploy](security-iam.md) 단원을 참조하십시오. **Topics** + [의 이점 AWS CodeDeploy](#benefits) + [CodeDeploy 컴퓨팅 플랫폼 개요](#compute-platform) + [CodeDeploy 배포 유형 개요](#welcome-deployment-overview) + [연락을 기다리겠습니다.](#welcome-contact-us) + [Primary Components](primary-components.md) + [Deployments](deployment-steps.md) + [Application Specification Files](application-specification-files.md) ## 의 이점 AWS CodeDeploy CodeDeploy는 다음 이점을 제공합니다 + **서버, 서버리스 및 컨테이너 애플리케이션**. CodeDeploy를 사용하면 서버리스 AWS Lambda 함수 버전 또는 Amazon ECS 애플리케이션을 배포하는 애플리케이션과 서버에 기존 애플리케이션을 모두 배포할 수 있습니다. + **배포 자동화**. CodeDeploy는 개발, 테스트 및 프로덕션 환경에 걸쳐 애플리케이션 배포를 완전 자동화합니다. 그리고 CodeDeploy는 인프라에 맞춰 규모를 조정할 수 있으므로 인스턴스 하나 또는 수천 개에 배포할 수 있습니다. + **가동 중지 최소화**. 애플리케이션이 EC2/온프레미스 컴퓨팅 플랫폼을 사용하는 경우 CodeDeploy는 애플리케이션 가용성을 극대화합니다. 인 플레이스(In-place) 배포에서 CodeDeploy는 Amazon EC2 인스턴스 전체에 대해 롤링 업데이트를 수행합니다. 업데이트 시 오프라인 상태가 될 수 있는 인스턴스 수를 지정할 수 있습니다. 블루/그린 배포 시에는 최신 애플리케이션 수정이 대체 인스턴스에 설치됩니다. 선택한 경우 새로운 환경 테스트를 완료한 직후 이러한 인스턴스로 트래픽이 다시 라우팅됩니다. 두 가지 배포 유형에 대해 CodeDeploy는 사용자가 구성한 규칙에 따라 애플리케이션 상태를 추적합니다. + **중지 및 롤백**. 오류가 있는 경우 자동 또는 수동으로 배포를 중지하고 롤백할 수 있습니다. + **중앙 집중식 제어**. CodeDeploy 콘솔 또는 AWS CLI를 통해 배포 상태를 시작 및 추적할 수 있습니다. 각 애플리케이션 개정이 배포된 시점 및 Amazon EC2 인스턴스가 나열된 보고서가 제공됩니다. + **채택 편의성**. CodeDeploy는 플랫폼과 관련된 제약이 없으므로 모든 애플리케이션과 작동합니다. 사용자는 설정 코드를 쉽게 재사용할 수 있습니다. 또한 CodeDeploy는 소프트웨어 릴리스 프로세스 또는 지속적 전달 도구 체인과 통합이 가능합니다. + **동시 배포**. EC2/온프레미스 컴퓨팅 플랫폼을 사용하는 1개 이상의 애플리케이션이 있는 경우에는 CodeDeploy를 통해 동일한 인스턴스 세트에 동시에 배포할 수 있습니다. ## CodeDeploy 컴퓨팅 플랫폼 개요 CodeDeploy는 세 가지 컴퓨팅 플랫폼에 애플리케이션을 배포할 수 있습니다. + **EC2/온프레미스**: 물리적 서버의 인스턴스를 설명합니다. Amazon EC2 클라우드 인스턴스나 온프레미스 서버 또는 둘 다일 수 있습니다. EC2/온프레미스 컴퓨팅 플랫폼을 사용하여 만든 애플리케이션은 실행 파일과 구성 파일, 이미지 및 기타 항목으로 구성될 수 있습니다. EC2/온프레미스 컴퓨팅 플랫폼을 사용하는 배포에서는 인 플레이스 또는 블루/그린 배포 유형을 사용하여 인스턴스로 트래픽이 전송되는 방식을 관리합니다. 자세한 내용은 [CodeDeploy 배포 유형 개요](#welcome-deployment-overview) 단원을 참조하십시오. + **AWS Lambda**: 업데이트된 버전의 Lambda 함수로 구성된 애플리케이션을 배포하는 데 사용됩니다.는 고가용성 컴퓨팅 구조로 구성된 서버리스 컴퓨팅 환경에서 Lambda 함수를 AWS Lambda 관리합니다. 컴퓨팅 리소스의 모든 관리는에서 수행합니다 AWS Lambda. 자세한 정보는 [서버리스 컴퓨팅 및 애플리케이션](https://aws.amazon.com/serverless/)을 참조하세요. AWS Lambda 및 Lambda 함수에 대한 자세한 내용은 섹션을 참조하세요[AWS Lambda](https://aws.amazon.com/lambda/). 카나리(Canary), 선형(Linear) 또는 한 번에 모두(All-at-once) 구성을 선택하여 업데이트된 Lambda 함수 버전으로 트래픽을 전송하는 방식을 관리할 수 있습니다. + **Amazon ECS**: Amazon ECS 컨테이너화된 애플리케이션을 작업 세트로 배포하는 데 사용됩니다. CodeDeploy는 애플리케이션의 업데이트 버전을 새로운 대체 작업 세트로 설치하여 블루/그린 배포를 수행합니다. CodeDeploy는 프로덕션 트래픽을 원래 애플리케이션 작업 세트에서 대체 작업 세트로 다시 라우팅합니다. 배포가 성공하면 기존 작업 세트는 종료됩니다. Amazon ECS에 대한 자세한 내용은 [Amazon Elastic Container Service](https://aws.amazon.com/ecs/)를 참조하세요. 카나리(Canary), 선형(Linear) 또는 한번에 모두(All-at-once) 구성을 선택하여 배포 중 업데이트된 작업 세트로 트래픽을 전송하는 방식을 관리할 수 있습니다. **참고** Amazon ECS 블루/그린 배포는 CodeDeploy 및 CloudFormation모두를 통해 지원됩니다. 이러한 배포에 대한 세부 정보는 다음 단원에서 설명합니다. 다음 표에는 CodeDeploy 구성 요소가 각 컴퓨팅 플랫폼에서 어떻게 사용되는지 나와 있습니다. 자세한 내용은 다음을 참조하세요. + [CodeDeploy에서 배포 그룹 작업](deployment-groups.md) + [CodeDeploy에서 배포 작업](deployments.md) + [CodeDeploy에서 배포 구성 작업](deployment-configurations.md) + [CodeDeploy의 애플리케이션 개정 작업](application-revisions.md) + [CodeDeploy의 애플리케이션 작업](applications.md) | CodeDeploy 구성 요소 | EC2/온프레미스 | AWS Lambda | Amazon ECS | | --- | --- | --- | --- | | 배포 그룹 | 인스턴스 세트에 수정을 배포합니다. | 고가용성 컴퓨팅 인프라에서 새 버전의 서버리스 Lambda 함수를 배포합니다. | 작업 세트로 배포할 컨테이너화된 애플리케이션이 있는 Amazon ECS 서비스, 배포된 애플리케이션에 트래픽을 제공하는 데 사용되는 프로덕션 및 테스트 리스너(선택 사항), 트래픽을 다시 라우팅하고 배포된 애플리케이션의 원래 작업 세트를 종료할 시기, 트리거(선택 사항), 경보, 롤백 설정을 지정합니다. | | 배포 | 애플리케이션과 AppSpec 파일로 구성된 새로운 수정을 배포합니다. AppSpec은 배포 그룹의 인스턴스에 애플리케이션을 배포하는 방식을 지정합니다. | Lambda 함수의 한 버전에서 동일한 함수의 새 버전으로 프로덕션 트래픽을 전환합니다. AppSpec 파일은 배포할 Lambda 함수 버전을 지정합니다. | Amazon ECS 컨테이너화된 애플리케이션의 업데이트된 버전을 새로운 대체 작업 세트로 배포합니다. CodeDeploy는 프로덕션 트래픽을 원래 버전의 작업 세트에서 업데이트된 버전의 대체 작업 세트로 다시 라우팅합니다. 배포가 완료되면 원래 작업 세트가 종료됩니다. | | 배포 구성 | 배포 시 항상 정상 상태를 유지해야 하는 최소 인스턴스 수와 배포 속도를 정의하는 설정입니다. | 업데이트된 Lambda 함수 버전으로 트래픽이 이동되는 방식을 정의하는 설정입니다. | 업데이트된 Amazon ECS 작업 세트로 트래픽이 이동되는 방식을 정의하는 설정입니다. | | 개정 | AppSpec 파일과 애플리케이션 파일의 조합입니다(실행 파일, 구성 파일 등). | 배포할 Lambda 함수와 배포 수명 주기 이벤트 후크 중에 검증 테스트를 실행할 수 있는 Lambda 함수를 지정하는 AppSpec 파일입니다. | 다음을 지정하는 AppSpec 파일입니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/welcome.html) | | 애플리케이션 | 배포 그룹과 수정 모음입니다. EC2/온프레미스 애플리케이션은 EC2/온프레미스 컴퓨팅 플랫폼을 사용합니다. | 배포 그룹과 수정 모음입니다. AWS Lambda 배포에 사용되는 애플리케이션은 서버리스 AWS Lambda 컴퓨팅 플랫폼을 사용합니다. | 배포 그룹과 수정 모음입니다. Amazon ECS 배포에 사용되는 애플리케이션은 Amazon ECS 컴퓨팅 플랫폼을 사용합니다. | ## CodeDeploy 배포 유형 개요 CodeDeploy는 두 가지 배포 유형 옵션을 제공합니다. + **실행 중 배포**: 배포 그룹의 각 인스턴스에 있는 애플리케이션이 중지되고 최신 애플리케이션 수정 버전이 설치되며 애플리케이션의 새 버전이 시작되고 유효성이 검사됩니다. 로드 밸런서를 사용하면 배포가 진행될 때 각 인스턴스를 등록 취소한 후 배포가 완료된 후 서비스로 복원할 수 있습니다. EC2/온프레미스 컴퓨팅 플랫폼을 사용하는 배포만 인 플레이스 배포를 사용할 수 있습니다. 현재 위치 배포에 대한 자세한 내용은 [인 플레이스 배포 개요](#welcome-deployment-overview-in-place) 단원을 참조하세요. **참고** AWS Lambda 및 Amazon ECS 배포는 현재 위치 배포 유형을 사용할 수 없습니다. + **블루/그린 배포**: 배포 동작은 사용하는 컴퓨팅 플랫폼에 따라 다릅니다. + **EC2/온프레미스 컴퓨팅 플랫폼에서의 블루/그린 배포**: 배포 그룹(원래 환경)의 인스턴스가 다음 단계를 거쳐 인스턴스의 다른 집합(대체 환경)으로 대체됩니다. + 인스턴스는 대체 환경을 위해 프로비저닝됩니다. + 최신 애플리케이션 수정은 대체 인스턴스에 설치됩니다. + 애플리케이션 테스트 및 시스템 검증과 같은 활동에 선택적 대기 시간이 발생합니다. + 대체 환경의 인스턴스가 하나 이상의 Elastic Load Balancing 로드 밸런서에 등록되고 트래픽이 이러한 인스턴스로 라우팅됩니다. 원래 환경의 인스턴스는 등록이 취소되고 종료되거나 다른 용도로 계속 실행될 수 있습니다. **참고** EC2/온프레미스 컴퓨팅 플랫폼을 사용할 경우 블루/그린 배포는 Amazon EC2 인스턴스에서만 작동합니다. + ** AWS Lambda 또는 Amazon ECS 컴퓨팅 플랫폼의 블루/그린**: 트래픽은 **canary**, **선형** 또는 **all-at-once** 배포 구성에 따라 증분으로 이동합니다. + **블루/그린 배포: CloudFormation** CloudFormation 스택 업데이트의 일부로 트래픽이 현재 리소스에서 업데이트된 리소스로 이동합니다. 현재는 ECS 블루/그린 배포만 지원됩니다. 블루/그린 배포에 대한 자세한 내용은 [블루/그린 배포 개요](#welcome-deployment-overview-blue-green) 섹션을 참조하세요. **참고** CodeDeploy 에이전트를 사용하면 애플리케이션, 배포 그룹 또는 AWS 계정 없이도 로그인한 인스턴스에서 배포를 수행할 수 있습니다. 자세한 내용은 [CodeDeploy 에이전트를 사용하여 로컬 시스템에서 배포 패키지의 유효성을 검사합니다.](deployments-local.md) 단원을 참조하세요. **Topics** + [인 플레이스 배포 개요](#welcome-deployment-overview-in-place) + [블루/그린 배포 개요](#welcome-deployment-overview-blue-green) ### 인 플레이스 배포 개요 **참고** AWS Lambda 및 Amazon ECS 배포는 현재 위치 배포 유형을 사용할 수 없습니다. 인플레이스 배포의 작동 방식은 다음과 같습니다. 1. 먼저, 로컬 개발 머신 또는 유사한 환경에서 배포 가능한 콘텐츠를 만든 다음 *application specification file*(AppSpec 파일)을 추가합니다. AppSpec 파일은 CodeDeploy에 고유합니다. 또한 CodeDeploy가 실행하게 하려는 배포 작업을 정의합니다. 배포 가능한 콘텐츠 및 AppSpec 파일을 아카이브 파일로 번들링한 다음 Amazon S3 버킷 또는 GitHub 리포지토리로 업로드합니다. 이러한 아카이브 파일을 *애플리케이션 수정*(또는 간단하게 *수정*)이라고 합니다. 1. 다음으로, CodeDeploy에 배포에 관한 정보를 제공합니다(예: 개정을 풀링하려는 Amazon S3 버킷 또는 GitHub 리포지토리 및 개정의 내용을 배포하려는 Amazon EC2 인스턴스 세트). CodeDeploy에서는 Amazon EC2 인스턴스 세트를 *배포 그룹*이라고 합니다. 배포 그룹에는 개별적으로 태그가 지정된 Amazon EC2 인스턴스, Amazon EC2 Auto Scaling 그룹의 Amazon EC2 인스턴스 또는 둘 다가 포함됩니다. 배포 그룹에 배포하려는 새 애플리케이션 수정을 성공적으로 업로드할 때마다 번들이 배포 그룹의 *대상 수정*으로 설정됩니다. 다시 말해 현재 배포의 대상으로 지정된 애플리케이션 수정이 대상 수정입니다. 또한 이 수정은 자동 배포를 위해 풀링되는 수정입니다. 1. 다음으로, 각 인스턴스의 CodeDeploy 에이전트가 CodeDeploy를 폴링하여 지정된 Amazon S3 버킷 또는 GitHub 리포지토리에서 풀링할 항목 및 시점을 결정합니다. 1. 마지막으로, 각 인스턴스의 CodeDeploy 에이전트가 Amazon S3 버킷 또는 GitHub 리포지토리에서 대상 개정을 풀링하고 AppSpec 파일의 지침을 따르면 콘텐츠가 인스턴스에 배포됩니다. CodeDeploy는 배포에 대한 레코드를 유지하므로 배포 상태, 배포 구성 파라미터, 인스턴스 상태를 확인할 수 있습니다. ### 블루/그린 배포 개요 블루/그린 배포는 새 애플리케이션 버전의 변경으로 인한 중단을 최소화하면서 애플리케이션을 업데이트하는 데 사용됩니다. CodeDeploy는 프로덕션 트래픽을 다시 라우팅하기 전에 이전 버전과 함께 새 애플리케이션 버전을 프로비저닝합니다. + **AWS Lambda**: 트래픽이 Lambda 함수의 한 버전에서 동일한 Lambda 함수의 새 버전으로 전환됩니다. + **Amazon ECS**: 트래픽이 Amazon ECS 서비스의 작업 세트에서 동일한 Amazon ECS 서비스의 업데이트된 대체 작업 세트로 전환됩니다. + **EC2/온프레미스**: 트래픽이 원래 환경의 한 인스턴스 세트에서 대체 인스턴스 세트로 전환됩니다. 모든 AWS Lambda 및 Amazon ECS 배포는 블루/그린입니다. EC2/온프레미스 배포는 인플레이스 또는 블루/그린일 수 있습니다. 블루/그린 배포는 인플레이스(in-place) 배포보다 많은 이점을 제공합니다. + 애플리케이션을 새 대체 환경에서 설치 및 테스트하고 트래픽을 다시 라우팅하여 프로덕션에 간단히 배포할 수 있습니다. + EC2/온프레미스 컴퓨팅 플랫폼을 사용하는 경우, 최신 버전의 애플리케이션으로 다시 전환하는 것이 더 빠르고 신뢰할 수 있습니다. 원래 인스턴스가 종료되지 않은 한 트래픽이 원래 인스턴스로 다시 라우팅될 수 있기 때문입니다. 인 플레이스(in-place) 배포의 경우, 애플리케이션의 이전 버전을 다시 배포하여 버전을 롤백해야 합니다. + EC2/온프레미스 컴퓨팅 플랫폼을 사용하는 경우 블루/그린 배포에 대해 새로운 인스턴스가 프로비저닝되고, 최신 서버 구성이 반영됩니다. 따라서 장기 실행 인스턴스에서 발생할 수 있는 다양한 문제를 예방할 수 있습니다. + AWS Lambda 컴퓨팅 플랫폼을 사용하는 경우 트래픽이 원래 AWS Lambda 함수 버전에서 새 AWS Lambda 함수 버전으로 이동하는 방식을 제어합니다. + Amazon ECS 컴퓨팅 플랫폼을 사용하는 경우 기존 작업 세트에서 새 작업 세트로 트래픽을 어떻게 이동할지 제어할 수 있습니다. 를 사용한 블루/그린 배포는 다음 방법 중 하나를 사용할 CloudFormation 수 있습니다. + **CloudFormation 배포용 템플릿**: CloudFormation 템플릿을 사용하여 배포를 구성하면 CloudFormation 업데이트에 의해 배포가 트리거됩니다. 리소스를 변경하고 템플릿 변경 사항을 업로드하면의 스택 업데이트가 새 배포를 CloudFormation 시작합니다. CloudFormation 템플릿에서 사용할 수 있는 리소스 목록은 섹션을 참조하세요[CloudFormation CodeDeploy 참조용 템플릿](reference-cloudformation-templates.md). + **를 통한 블루/그린 배포 CloudFormation**: CloudFormation 를 사용하여 스택 업데이트를 통해 블루/그린 배포를 관리할 수 있습니다. 스택 템플릿 내에서 트래픽 라우팅 및 안정화 설정을 지정하는 것 외에도 블루 및 그린 리소스를 모두 정의합니다. 그런 다음 스택 업데이트 중에 선택한 리소스를 업데이트하면는 필요한 모든 그린 리소스를 CloudFormation 생성하고, 지정된 트래픽 라우팅 파라미터를 기반으로 트래픽을 이동하고, 블루 리소스를 삭제합니다. 자세한 내용은 *AWS CloudFormation 사용 설명서*의 [CloudFormation을 사용하여 CodeDeploy를 통한 Amazon ECS 블루/그린 배포 자동화](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/blue-green.html)를 참조하세요. **참고** Amazon ECS 블루/그린 배포에만 지원됩니다. 블루/그린 배포를 어떻게 구성하는지는 배포에서 사용하는 컴퓨팅 플랫폼에 따라 다릅니다. #### AWS Lambda 또는 Amazon ECS 컴퓨팅 플랫폼에 블루/그린 배포 AWS Lambda 또는 Amazon ECS 컴퓨팅 플랫폼을 사용하는 경우 트래픽이 원래 AWS Lambda 함수 또는 Amazon ECS 작업 세트에서 새 함수 또는 작업 세트로 어떻게 전환되는지 표시해야 합니다. 트래픽 이동 방식을 지정하려면 다음 배포 구성 중 하나를 지정해야 합니다. + **카나리(Canary)** + **리니어(Linear)** + **한 번에 모두(All-at-once)** 카나리(Canary), 리니어(Linear) 또는 한 번에 모두(All-at-once) 배포 구성에서 트래픽이 이동하는 방식에 대한 자세한 내용은 [배포 구성](primary-components.md#primary-components-deployment-configuration) 섹션을 참조하세요. Lambda 배포 구성에 대한 자세한 내용은 [AWS Lambda 컴퓨팅 플랫폼의 배포 구성](deployment-configurations.md#deployment-configuration-lambda) 섹션을 참조하세요. Amazon ECS 배포 구성에 대한 자세한 내용은 [Amazon ECS 컴퓨팅 플랫폼에 대한 배포 구성](deployment-configurations.md#deployment-configuration-ecs) 섹션을 참조하세요. #### EC2/온프레미스 컴퓨팅 플랫폼의 블루/그린 배포 **참고** EC2/온프레미스 컴퓨팅 플랫폼에서의 블루/그린 배포에는 Amazon EC2 인스턴스를 사용해야 합니다. 온프레미스 인스턴스는 블루/그린 배포 유형을 지원하지 않습니다. EC2/온프레미스 컴퓨팅 플랫폼을 사용하는 경우 다음 사항이 적용됩니다. Amazon EC2 태그를 식별하는 하나 이상의 Amazon EC2 인스턴스 또는 Amazon EC2 Auto Scaling 그룹이 있어야 합니다. 이러한 인스턴스는 다음 추가 요구 사항을 충족해야 합니다. + 각 Amazon EC2 인스턴스에 올바른 IAM 인스턴스 프로파일이 연결되어 있어야 합니다. + 각 인스턴스에 CodeDeploy 에이전트가 설치되어 실행 중이어야 합니다. **참고** 또한 일반적으로 기존 환경의 인스턴스에서 실행되는 애플리케이션 수정이 있지만, 블루/그린 배포의 경우 반드시 이럴 필요는 없습니다. 블루/그린 배포에서 사용되는 배포 그룹을 만들 때 다음과 같은 대체 환경 지정 방법을 선택할 수 있습니다. **기존 Amazon EC2 Auto Scaling 그룹 복사**: 블루/그린 배포 시 CodeDeploy는 배포 중 대체 환경에 필요한 인스턴스를 만듭니다. 이 옵션을 선택하면 CodeDeploy는 사용자가 지정한 Amazon EC2 Auto Scaling 그룹을 대체 환경의 템플릿(동일한 수의 실행 인스턴스 및 여러 가지 기타 구성 옵션을 포함)으로 사용합니다. **수동으로 인스턴스 선택**: Amazon EC2 인스턴스 태그, Amazon EC2 Auto Scaling 그룹 이름 또는 둘 다를 사용하여 인스턴스를 대체 인스턴스로 계산하도록 지정할 수 있습니다. 이 옵션을 선택하면 배포를 만들 때까지 대체 환경을 위한 인스턴스를 지정할 필요가 없습니다. 작동 방식은 다음과 같습니다. 1. 원본 환경으로 작동할 인스턴스 또는 Amazon EC2 Auto Scaling 그룹이 이미 있습니다. 블루/그린 배포를 처음 실행할 때는 일반적으로 인 플레이스(in-place) 배포에서 이미 사용된 인스턴스를 사용합니다. 1. 기존 CodeDeploy 애플리케이션에서는 인 플레이스 배포에 필요한 옵션 이외에 블루/그린 배포 그룹을 만들어 다음을 지정합니다. + 블루/그린 배포 프로세스 중 원래 환경에서 대체 환경으로 트래픽을 라우팅할 로드 밸런서 + 트래픽을 대체 환경으로 즉시 다시 라우팅하거나 수동으로 다시 라우팅할 때까지 대기할지 여부 + 트래픽이 대체 인스턴스로 라우팅되는 속도 + 대체된 인스턴스를 종료 또는 계속 실행할지 여부 1. 다음과 같은 이벤트가 발생하는 동안 배포 그룹에 대한 배포를 만듭니다. 1. Amazon EC2 Auto Scaling 그룹을 복사하도록 선택한 경우 대체 환경에 필요한 인스턴스가 프로비저닝됩니다. 1. 배포 대상으로 지정한 애플리케이션 수정이 대체 인스턴스에 설치됩니다. 1. 배포 그룹 설정에서 대기 시간을 지정한 경우 배포가 일시 중지됩니다. 이러한 대기 시간에 대체 환경에서 테스트 및 확인을 실행할 수 있습니다. 대기 시간 종료 전 트래픽을 수동으로 다시 라우팅하지 않으면 배포가 중지됩니다. 1. 대체 환경의 인스턴스가 Elastic Load Balancing 로드 밸런서에 등록되고 트래픽이 이러한 인스턴스로 라우팅되기 시작합니다. 1. 원본 환경의 인스턴스는 등록 취소되어 배포 그룹의 사양에 따라 처리됩니다. 즉, 종료되거나 계속 실행됩니다. #### 를 통한 블루/그린 배포 CloudFormation CloudFormation 템플릿으로 리소스를 모델링하여 CodeDeploy 블루/그린 배포를 관리할 수 있습니다. CloudFormation 템플릿을 사용하여 블루/그린 리소스를 모델링할 때 작업 세트를 업데이트 CloudFormation 하는 스택 업데이트를에 생성합니다. 프로덕션 트래픽은 선형 배포 및 베이킹 시간 또는 Canary 배포를 사용하여 서비스의 원래 작업 세트에서 대체 작업 세트로 한 번에 모두 이동합니다. 스택 업데이트가 CodeDeploy에서 배포를 시작합니다. CodeDeploy에서 배포 상태 및 기록을 볼 수 있지만 CloudFormation 템플릿 외부에서 CodeDeploy 리소스를 생성하거나 관리하지는 않습니다. **참고** 를 통한 블루/그린 배포의 CloudFormation경우 CodeDeploy 애플리케이션 또는 배포 그룹을 생성하지 않습니다. 이 방법은Amazon ECS 블루/그린 배포만 지원합니다. 를 통한 블루/그린 배포에 대한 자세한 내용은 섹션을 CloudFormation참조하세요[를 통해 Amazon ECS 블루/그린 배포 생성 CloudFormation](deployments-create-ecs-cfn.md). ## 연락을 기다리겠습니다. 우리는 여러분의 의견을 환영합니다. 문의 사항이 있는 경우 [CodeDeploy 포럼](https://forums.aws.amazon.com/forum.jspa?forumID=179)을 방문하세요. **주제** + [Primary Components](primary-components.md) + [Deployments](deployment-steps.md) + [Application Specification Files](application-specification-files.md) # CodeDeploy 주요 구성 요소 서비스 작업을 시작하기 전에 CodeDeploy 배포 프로세스의 주요 구성 요소를 숙지해야 합니다. **Topics** + [애플리케이션](#primary-components-application) + [컴퓨팅 플랫폼](#primary-components-compute-platform) + [배포 구성](#primary-components-deployment-configuration) + [배포 그룹](#primary-components-deployment-group) + [배포 유형](#primary-components-deployment-type) + [IAM 인스턴스 프로파일](#primary-components-iam-instance-profile) + [개정](#primary-components-revision) + [서비스 역할](#primary-components-service-role) + [대상 수정 버전](#primary-components-target-revision) + [기타 구성 요소](#primary-components-other-components) ## 애플리케이션 *애플리케이션*은 배포할 애플리케이션을 식별할 수 있는 고유 이름입니다. CodeDeploy는 컨테이너 역할을 하는 이 이름을 사용하여 배포 중에 수정 버전, 배포 구성 및 배포 그룹의 올바른 조합을 참조하도록 합니다. ## 컴퓨팅 플랫폼 *컴퓨팅 플랫폼*은 CodeDeploy가 애플리케이션을 배포하는 플랫폼입니다. 다음과 같은 세 가지 컴퓨팅 플랫폼이 있습니다. + **EC2/온프레미스**: 물리적 서버의 인스턴스를 설명합니다. Amazon EC2 클라우드 인스턴스나 온프레미스 서버 또는 둘 다일 수 있습니다. EC2/온프레미스 컴퓨팅 플랫폼을 사용하여 만든 애플리케이션은 실행 파일과 구성 파일, 이미지 및 기타 항목으로 구성될 수 있습니다. EC2/온프레미스 컴퓨팅 플랫폼을 사용하는 배포에서는 인 플레이스 또는 블루/그린 배포 유형을 사용하여 인스턴스로 트래픽이 전송되는 방식을 관리합니다. 자세한 내용은 [CodeDeploy 배포 유형 개요](welcome.md#welcome-deployment-overview) 단원을 참조하십시오. + **AWS Lambda**: 업데이트된 버전의 Lambda 함수로 구성된 애플리케이션을 배포하는 데 사용됩니다.는 고가용성 컴퓨팅 구조로 구성된 서버리스 컴퓨팅 환경에서 Lambda 함수를 AWS Lambda 관리합니다. 컴퓨팅 리소스의 모든 관리는에서 수행합니다 AWS Lambda. 자세한 정보는 [서버리스 컴퓨팅 및 애플리케이션](https://aws.amazon.com/serverless/)을 참조하세요. AWS Lambda 및 Lambda 함수에 대한 자세한 내용은 섹션을 참조하세요[AWS Lambda](https://aws.amazon.com/lambda/). 카나리(Canary), 선형(Linear) 또는 한 번에 모두(All-at-once) 구성을 선택하여 업데이트된 Lambda 함수 버전으로 트래픽을 전송하는 방식을 관리할 수 있습니다. + **Amazon ECS**: Amazon ECS 컨테이너화된 애플리케이션을 작업 세트로 배포하는 데 사용됩니다. CodeDeploy는 애플리케이션의 업데이트 버전을 새로운 대체 작업 세트로 설치하여 블루/그린 배포를 수행합니다. CodeDeploy는 프로덕션 트래픽을 원래 애플리케이션 작업 세트에서 대체 작업 세트로 다시 라우팅합니다. 배포가 성공하면 기존 작업 세트는 종료됩니다. Amazon ECS에 대한 자세한 내용은 [Amazon Elastic Container Service](https://aws.amazon.com/ecs/)를 참조하세요. 카나리(Canary), 선형(Linear) 또는 한번에 모두(All-at-once) 구성을 선택하여 배포 중 업데이트된 작업 세트로 트래픽을 전송하는 방식을 관리할 수 있습니다. **참고** Amazon ECS 블루/그린 배포는CodeDeploy 및 CloudFormation모두를 통해 지원됩니다. 이러한 배포에 대한 세부 정보는 다음 단원에서 설명합니다. ## 배포 구성 *배포 구성*이란 배포 중 CodeDeploy에서 사용하는 배포 규칙과 배포 성공 및 실패 조건 집합입니다. EC2/온프레미스 컴퓨팅 플랫폼을 사용하는 배포의 경우, 해당 배포에 대해 정상 인스턴스의 최소 개수를 지정할 수 있습니다. 배포에서 AWS Lambda 또는 Amazon ECS 컴퓨팅 플랫폼을 사용하는 경우 업데이트된 Lambda 함수 또는 ECS 작업 세트로 트래픽이 라우팅되는 방법을 지정할 수 있습니다. EC2/온프레미스 컴퓨팅 플랫폼을 사용하는 배포에서 최소 정상 호스트 개수를 지정하는 방법은 [최소 정상 인스턴스 수 정보](instances-health.md#minimum-healthy-hosts) 단원을 참조하세요. 다음은 Lambda 또는 ECS 컴퓨팅 플랫폼을 사용하는 배포에서 트래픽을 라우팅하는 방식을 지정하는 배포 구성입니다. + **카나리(Canary)**: 트래픽이 두 증분으로 나뉘어 이동합니다. 첫 번째 증분에서 업데이트된 Lambda 함수 또는 ECS 태스크로 이동할 트래픽의 백분율 및 두 번째 증분에서 나머지 트래픽의 이동을 시작하기 전까지 간격(분)을 지정하는 사전 정의된 카나리(Canary) 옵션 중에서 선택할 수 있습니다. + **리니어(Linear)**: 트래픽이 동일한 증분 이동하며 각 증분 간에 시간 간격(분)이 동일합니다. 각 증분에서 이동할 트래픽 비율(%)과 각 증분 간의 시간 간격(분)을 지정하는 사전 정의된 선형 옵션에서 선택할 수 있습니다. + **한 번에 모두(All-at-once)**: 모든 트래픽이 원본 Lambda 함수 또는 ECS 태스크 집합에서 업데이트된 함수 또는 태스크 집합으로 전부 한꺼번에 이동합니다. ## 배포 그룹 *배포 그룹*이란 개별 인스턴스 집합입니다. 배포 그룹에는 개별적으로 태그가 지정된 인스턴스, Amazon EC2 Auto Scaling 그룹의 Amazon EC2 인스턴스 또는 둘 다가 포함됩니다. Amazon EC2 인스턴스 태그에 대한 자세한 정보는 [콘솔을 사용한 태그 작업](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console)을 참조하세요. 온프레미스 인스턴스에 대한 자세한 정보는 [CodeDeploy용 온프레미스 인스턴스 작업](instances-on-premises.md) 단원을 참조하세요. Amazon EC2 Auto Scaling에 대한 자세한 내용은 [Amazon EC2 Auto Scaling과 CodeDeploy 통합](integrations-aws-auto-scaling.md) 단원을 참조하세요. ## 배포 유형 *배포 유형*이란 배포 그룹의 인스턴스에서 최신 애플리케이션 수정 버전을 사용 가능하게 만드는 방법입니다. 배포 유형에는 두 가지가 있습니다. + **현재 위치 배포**: 배포 그룹의 각 인스턴스에 있는 애플리케이션이 중지되고 최신 애플리케이션 개정 버전이 설치되며 애플리케이션의 새 버전이 시작되고 유효성이 검사됩니다. 로드 밸런서를 사용하면 배포가 진행될 때 각 인스턴스를 등록 취소한 후 배포가 완료된 후 서비스로 복원할 수 있습니다. EC2/온프레미스 컴퓨팅 플랫폼을 사용하는 배포만 인 플레이스 배포를 사용할 수 있습니다. 현재 위치 배포에 대한 자세한 내용은 [인 플레이스 배포 개요](welcome.md#welcome-deployment-overview-in-place) 단원을 참조하세요. + **Blue/Green 배포**: 배포 동작은 사용하는 컴퓨팅 플랫폼에 따라 다릅니다. + **EC2/온프레미스 컴퓨팅 플랫폼에서의 블루/그린 배포**: 배포 그룹(원래 환경)의 인스턴스가 다음 단계를 거쳐 인스턴스의 다른 집합(대체 환경)으로 대체됩니다. + 인스턴스는 대체 환경을 위해 프로비저닝됩니다. + 최신 애플리케이션 수정은 대체 인스턴스에 설치됩니다. + 애플리케이션 테스트 및 시스템 검증과 같은 활동에 선택적 대기 시간이 발생합니다. + 대체 환경의 인스턴스가 하나 이상의 Elastic Load Balancing 로드 밸런서에 등록되고 트래픽이 이러한 인스턴스로 라우팅됩니다. 원래 환경의 인스턴스는 등록이 취소되고 종료되거나 다른 용도로 계속 실행될 수 있습니다. **참고** EC2/온프레미스 컴퓨팅 플랫폼을 사용할 경우 블루/그린 배포는 Amazon EC2 인스턴스에서만 작동합니다. + ** AWS Lambda 또는 Amazon ECS 컴퓨팅 플랫폼의 블루/그린**: 트래픽은 **canary**, **선형** 또는 **all-at-once** 배포 구성에 따라 증분으로 이동합니다. + **블루/그린 배포: CloudFormation** CloudFormation 스택 업데이트의 일부로 트래픽이 현재 리소스에서 업데이트된 리소스로 이동합니다. 현재는 ECS 블루/그린 배포만 지원됩니다. 블루/그린 배포에 대한 자세한 내용은 [블루/그린 배포 개요](welcome.md#welcome-deployment-overview-blue-green) 섹션을 참조하세요. **참고** Amazon ECS 블루/그린 배포는CodeDeploy 및 CloudFormation모두를 통해 지원됩니다. 이러한 배포에 대한 세부 정보는 다음 단원에서 설명합니다. ## IAM 인스턴스 프로파일 *IAM 인스턴스 프로파일*이란 Amazon EC2 인스턴스에 연결하는 IAM 역할입니다. 이 프로파일에는 애플리케이션이 저장되는 Amazon S3 버킷 또는 GitHub 리포지토리에 액세스할 때 필요한 권한이 포함됩니다. 자세한 내용은 [4단계: Amazon EC2 인스턴스에 대한 IAM 인스턴스 프로파일 만들기](getting-started-create-iam-instance-profile.md) 단원을 참조하십시오. ## 개정 *수정 버전*이란 애플리케이션의 버전입니다. AWS Lambda 배포 개정은 배포할 Lambda 함수에 대한 정보를 지정하는 YAML 또는 JSON 형식의 파일입니다. EC2/온프레미스 배포 개정은 소스 콘텐츠(소스 코드, 웹 페이지, 실행 파일 및 배포 스크립트)와 애플리케이션 사양 파일(AppSpec 파일)이 포함된 아카이브 파일입니다. AWS Lambda 개정은 Amazon S3 버킷에 저장할 수 있습니다. EC2/온프레미스 수정 버전은 Amazon S3 버킷 또는 GitHub 리포지토리에 저장됩니다. Amazon S3의 경우 수정 버전은 Amazon S3 객체 키 및 해당 ETag, 버전 또는 둘 다에 의해 고유하게 식별됩니다. GitHub의 경우 수정은 커밋 ID에 의해 고유하게 식별됩니다. ## 서비스 역할 *서비스 역할은* AWS 리소스에 액세스할 수 있도록 AWS 서비스에 권한을 부여하는 IAM 역할입니다. 서비스 역할에 연결하는 정책에 따라 서비스가 액세스할 수 있는 AWS 리소스와 해당 리소스로 수행할 수 있는 작업이 결정됩니다. CodeDeploy의 경우 서비스 역할은 다음 작업에 사용됩니다. + 인스턴스에 적용된 태그 또는 인스턴스와 연결된 Amazon EC2 Auto Scaling 그룹 이름을 읽습니다. 이를 통해 CodeDeploy는 애플리케이션을 배포할 수 있는 인스턴스를 식별할 수 있습니다. + Amazon EC2 Auto Scaling 그룹 및 Elastic Load Balancing 로드 밸런서의 인스턴스에 대한 작업을 수행합니다. + 지정된 배포 또는 인스턴스 이벤트가 발생할 때 알림을 전송할 수 있도록 Amazon SNS 주제에 정보를 게시합니다. + CloudWatch 경보에 대한 정보를 검색하여 배포에 대한 경보 모니터링을 설정합니다. 자세한 내용은 [2단계: CodeDeploy에 대한 서비스 역할 생성](getting-started-create-service-role.md) 단원을 참조하십시오. ## 대상 수정 버전 *대상 수정 버전*이란 리포지토리에 업로드했고 배포 그룹의 인스턴스에 배포하려는 가장 최신 버전의 애플리케이션 수정 버전입니다. 다시 말해서, 애플리케이션 수정은 현재 배포를 위해 대상 지정됩니다. 또한 이 수정은 자동 배포를 위해 풀링되는 수정입니다. ## 기타 구성 요소 CodeDeploy 워크플로의 다른 구성 요소에 대한 자세한 내용은 다음 주제를 참조하세요. + [CodeDeploy 리포지토리 유형 선택](application-revisions-repository-type.md) + [CodeDeploy 배포](deployment-steps.md) + [CodeDeploy 애플리케이션 사양(AppSpec) 파일](application-specification-files.md) + [CodeDeploy 인스턴스 상태](instances-health.md) + [CodeDeploy 에이전트 작업](codedeploy-agent.md) + [CodeDeploy용 온프레미스 인스턴스 작업](instances-on-premises.md) # CodeDeploy 배포 이 항목에서는 CodeDeploy의 배포 워크플로와 구성 요소에 대해 설명합니다. 배포 프로세스는 배포에 사용하는 컴퓨팅 플랫폼 또는 배포 방법(Lambda, Amazon ECS, EC2/온프레미스 또는 경유 AWS CloudFormation)에 따라 달라집니다. **Topics** + [AWS Lambda 컴퓨팅 플랫폼에 배포](deployment-steps-lambda.md) + [Amazon ECS 컴퓨팅 플랫폼에서의 배포](deployment-steps-ecs.md) + [EC2/온프레미스 컴퓨팅 플랫폼의 배포](deployment-steps-server.md) # AWS Lambda 컴퓨팅 플랫폼에 배포 이 주제에서는 AWS Lambda 컴퓨팅 플랫폼을 사용하는 CodeDeploy 배포의 구성 요소 및 워크플로에 대한 정보를 제공합니다. **Topics** + [AWS Lambda 컴퓨팅 플랫폼의 배포 워크플로](#deployment-process-workflow-lambda) + [애플리케이션 개정 업로드](#deployment-steps-uploading-your-app-lambda) + [애플리케이션 및 배포 그룹 만들기](#deployment-steps-registering-app-deployment-groups-lambda) + [애플리케이션 개정 배포](#deployment-steps-deploy-lambda) + [애플리케이션 업데이트](#deployment-steps-updating-your-app-lambda) + [중지 및 실패한 배포](#deployment-stop-fail-lambda) + [다시 배포 및 배포 롤백](#deployment-rollback-lambda) ## AWS Lambda 컴퓨팅 플랫폼의 배포 워크플로 다음 다이어그램은 새로 업데이트된 AWS Lambda 함수 배포의 기본 단계를 보여줍니다. ![\[CodeDeploy가 새 함수 또는 업데이트된 AWS Lambda 함수를 배포하는 방법.\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/images/deployment-process-lambda.png) 이러한 단계는 다음과 같습니다. 1. 애플리케이션을 만든 후 배포할 애플리케이션 개정을 식별할 수 있는 고유 이름을 지정합니다. Lambda 함수를 배포하려면 애플리케이션을 만들 때 AWS Lambda 컴퓨팅 플랫폼을 선택합니다. CodeDeploy에서는 배포 중 이 이름을 사용하여 해당 배포가 올바른 배포 구성 요소(예: 배포 그룹, 배포 구성 및 애플리케이션 개정)를 참조하도록 합니다. 자세한 내용은 [CodeDeploy를 사용하여 애플리케이션 생성](applications-create.md) 단원을 참조하십시오. 1. 배포 그룹 이름을 지정하여 배포 그룹을 설정합니다. 1. 배포 구성을 선택하여 트래픽이 원래 AWS Lambda 함수 버전에서 새 Lambda 함수 버전으로 이동하는 방법을 지정합니다. 자세한 내용은 [CodeDeploy의 배포 구성 세부 정보 보기](deployment-configurations-view-details.md) 단원을 참조하십시오. 1. *애플리케이션 사양 파일*(AppSpec 파일)을 Amazon S3로 업로드 AppSpec 파일은 배포를 확인하는 데 사용되는 Lambda 함수 버전과 Lambda 함수를 지정합니다. AppSpec 파일을 만들지 않으려면 YAML 또는 JSON을 사용하여 콘솔에서 직접 Lambda 함수 버전과 Lambda 배포 확인 함수를 지정하면 됩니다. 자세한 내용은 [CodeDeploy의 애플리케이션 개정 작업](application-revisions.md) 단원을 참조하십시오. 1. 애플리케이션 개정을 배포 그룹에 배포합니다.는 지정한 Lambda 함수 개정을 AWS CodeDeploy 배포합니다. 애플리케이션을 만들 때 선택한 배포 AppSpec 파일을 사용하여 Lambda 함수 개정으로 트래픽이 이동합니다. 자세한 내용은 [CodeDeploy에서 배포 만들기](deployments-create.md) 단원을 참조하십시오. 1. 배포 결과를 확인합니다. 자세한 내용은 [CodeDeploy에서 배포 모니터링](monitoring.md) 단원을 참조하십시오. ## 애플리케이션 개정 업로드 AppSpec 파일을 Amazon S3에 배치하거나, 콘솔 또는 AWS CLI에서 직접 입력합니다. 자세한 내용은 [CodeDeploy 애플리케이션 사양(AppSpec) 파일](application-specification-files.md) 단원을 참조하십시오. ## 애플리케이션 및 배포 그룹 만들기 AWS Lambda 컴퓨팅 플랫폼의 CodeDeploy 배포 그룹은 하나 이상의 AppSpec 파일 모음을 식별합니다. 각 AppSpec 파일은 한 개의 Lambda 함수 버전을 배포할 수 있습니다. 배포 그룹은 또한 이후 배포를 위해 일련의 구성 옵션(경보 및 롤백 구성 등) 세트를 정의합니다. ## 애플리케이션 개정 배포 이제 AppSpec 파일에 지정된 함수 개정 버전을 배포 그룹에 배포할 수 있습니다. CodeDeploy 콘솔 또는 [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html) 명령을 사용할 수 있습니다. 개정, 배포 그룹 및 배포 구성을 비롯하여 배포를 제어하기 위해 지정할 수 있는 파라미터가 있습니다. ## 애플리케이션 업데이트 애플리케이션을 업데이트한 다음 CodeDeploy 콘솔을 사용하거나 [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html) 명령을 호출하여 개정 버전을 푸시할 수 있습니다. ## 중지 및 실패한 배포 CodeDeploy 콘솔 또는 [stop-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/stop-deployment.html) 명령을 사용하여 배포를 중지할 수 있습니다. 배포를 중지하려고 하면 다음 3가지 동작 중 하나가 발생합니다. + 배포가 중지되고 성공 상태가 반환됩니다. 이 경우 중지된 배포의 배포 그룹에서 더 이상 배포 수명 주기 이벤트가 실행되지 않습니다. + 배포가 즉시 중지되지 않고, 대기 중 상태가 반환됩니다. 이 경우, 일부 배포 수명 주기 이벤트는 배포 그룹에서 계속 실행 중일 수 있습니다. 대기 중인 작업이 완료되면 배포 중지를 위한 후속 호출에서 성공 상태를 반환합니다. + 배포를 중지할 수 없고 오류가 반환됩니다. 자세한 내용은 AWS CodeDeploy API 참조의 [ErrorInformation](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_ErrorInformation.html) and [Common errors](https://docs.aws.amazon.com/codedeploy/latest/APIReference/CommonErrors.html)를 참조하세요. 중지된 배포와 마찬가지로, 실패한 배포도 일부 배포 수명 주기 이벤트가 이미 실행되었을 수 있습니다. 배포가 실패한 이유를 확인하려면 CodeDeploy 콘솔을 사용하거나 실패한 배포의 로그 파일 데이터를 분석합니다. 자세한 내용은 [애플리케이션 수정 버전 및 로그 파일 정리](codedeploy-agent.md#codedeploy-agent-revisions-logs-cleanup) 및 [CodeDeploy EC2/온프레미스 배포에 대한 로그 데이터 보기](deployments-view-logs.md) 단원을 참조하세요. ## 다시 배포 및 배포 롤백 CodeDeploy에서는 이전에 배포된 개정 버전을 새 배포로 다시 배포하여 롤백을 구현합니다. 배포에 실패한 경우 또는 경보 모니터링 임계값에 도달한 경우 등 특정 조건이 충족되면 배포를 자동으로 롤백하도록 배포 그룹을 구성할 수 있습니다. 또한 개별 배포에서 배포 그룹에 대해 지정한 롤백 설정을 재정의할 수도 있습니다. 뿐만 아니라 이전에 배포한 개정을 수동으로 다시 배포하여 실패한 배포를 롤백하도록 선택할 수도 있습니다. 어느 경우에도 새 배포나 롤백 배포에 고유의 배포 ID가 할당됩니다. CodeDeploy 콘솔에서 볼 수 있는 배포 목록에는 자동 배포로 배포된 항목이 표시됩니다. 자세한 내용은 [CodeDeploy를 사용하여 재배포 및 배포 롤백](deployments-rollback-and-redeploy.md) 단원을 참조하십시오. # Amazon ECS 컴퓨팅 플랫폼에서의 배포 이 항목에서는 Amazon ECS 컴퓨팅 플랫폼을 사용하는 CodeDeploy 배포의 워크플로 및 구성 요소에 대해 설명합니다. **Topics** + [Amazon ECS 배포를 시작하기 전](#deployment-steps-prerequisites-ecs) + [Amazon ECS 컴퓨팅 플랫폼의 배포 워크플로(높은 수준)](#deployment-process-workflow-ecs) + [Amazon ECS 배포 중에 발생하는 일](#deployment-steps-what-happens) + [애플리케이션 개정 업로드](#deployment-steps-uploading-your-app-ecs) + [애플리케이션 및 배포 그룹 만들기](#deployment-steps-registering-app-deployment-groups-ecs) + [애플리케이션 개정 배포](#deployment-steps-deploy-ecs) + [애플리케이션 업데이트](#deployment-steps-updating-your-app-ecs) + [중지 및 실패한 배포](#deployment-stop-fail-ecs) + [다시 배포 및 배포 롤백](#deployment-rollback-ecs) + [를 통한 Amazon ECS 블루/그린 배포 AWS CloudFormation](#deployment-steps-ecs-cf) ## Amazon ECS 배포를 시작하기 전 Amazon ECS 애플리케이션 배포를 시작하기 전에 다음을 준비해야 합니다. 일부 요구 사항은 배포 그룹을 만들 때 지정되고, 일부는 AppSpec 파일에 지정됩니다. **** | 요구 사항 | 지정되는 위치 | | --- | --- | | Amazon ECS 클러스터 | 배포 그룹 | | Amazon ECS 서비스 | 배포 그룹 | | Application Load Balancer 또는 Network Load Balancer | 배포 그룹 | | 프로덕션 리스너 | 배포 그룹 | | 테스트 리스너(선택 사항) | 배포 그룹 | | 대상 그룹 두 개 | 배포 그룹 | | Amazon ECS 작업 정의 | AppSpec 파일 | | 컨테이너 이름 | AppSpec 파일 | | 컨테이너 포트 | AppSpec 파일 | **Amazon ECS 클러스터** Amazon ECS *클러스터*는 작업 또는 서비스의 논리적 그룹입니다. CodeDeploy 애플리케이션의 배포 그룹을 만들 때 Amazon ECS 서비스가 포함된 Amazon ECS 클러스터를 지정합니다. 자세한 내용은 *Amazon Elastic Container Service 사용 설명서*의 [Amazon ECS 클러스터](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_clusters.html)를 참조하세요. **Amazon ECS 서비스** Amazon ECS *서비스*는 Amazon ECS 클러스터에서 지정된 작업 정의 인스턴스를 유지하고 실행합니다. Amazon ECS 서비스는 CodeDeploy에서 활성화되어 있어야 합니다. 기본적으로 Amazon ECS 서비스는 Amazon ECS 배포에 활성화되어 있어야 합니다. 배포 그룹을 만들 때 Amazon ECS 클러스터에 있는 Amazon ECS 서비스를 배포하도록 선택합니다. 자세한 내용은 *Amazon Elastic Container Service 사용 설명서*의 [Amazon ECS 서비스](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html)를 참조하세요. **Application Load Balancer 또는 Network Load Balancer** Amazon ECS 배포로 업데이트하려는 Amazon ECS 서비스에서 Elastic Load Balancing을 사용해야 합니다. Application Load Balancer 또는 Network Load Balancer를 사용할 수 있습니다. 동적 포트 매핑 및 경로 기반 라우팅과 우선순위 규칙 등의 기능을 활용할 수 있도록 Application Load Balancer를 사용하는 것이 좋습니다. CodeDeploy 애플리케이션의 배포 그룹을 만들 때 로드 밸런서를 지정합니다. 자세한 내용은 [CodeDeploy Amazon ECS 배포를 위한 로드 밸런서, 대상 그룹 및 리스너 설정](deployment-groups-create-load-balancer-for-ecs.md) 및 *Amazon Elastic Container Service 사용 설명서*의 [로드 밸런서 생성](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-load-balancer.html)을 참조하세요. **리스너 한 개 또는 두 개** *리스너*는 로드 밸런서가 대상 그룹으로 트래픽을 보내기 위해 사용합니다. 프로덕션 리스너 한 개는 필수입니다. 확인 테스트를 실행하는 동안 대체 작업 세트로 트래픽을 보내는 두 번째 테스트 리스너(선택 사항)를 지정할 수 있습니다. 배포 그룹을 만들 때 리스너를 한 개 또는 두 개 지정합니다. Amazon ECS 콘솔을 사용하여 Amazon ECS 서비스를 생성하는 경우, 리스너가 자동으로 생성됩니다. 자세한 내용은 *Elastic Load Balancing 사용 설명서*에서 [애플리케이션 로드 밸런서의 리스너](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listener.html) 및 *Amazon Elastic Container Service 사용 설명서*의 [서비스 생성](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-service.html)을 참조하세요. **2개의 Amazon ECS 대상 그룹** *대상 그룹*은 등록된 대상으로 트래픽을 라우팅하는 데 사용됩니다. Amazon ECS 배포에는 대상 그룹이 2개 필요합니다. 하나는 Amazon ECS 애플리케이션의 원래 작업 세트용이고 다른 하나는 대체 작업 세트용입니다. 배포 중에 CodeDeploy는 대체 작업 세트를 만들고 원래 작업 세트에서 새 작업 세트로 트래픽을 다시 라우팅합니다. CodeDeploy 애플리케이션의 배포 그룹을 만들 때 대상 그룹을 지정합니다. 배포 중에 CodeDeploy는 상태가 `PRIMARY`인 Amazon ECS 서비스의 작업 세트(원래 작업 세트)와 연결된 대상 그룹을 확인하고 대상 그룹 하나를 이 작업 세트와 연결한 후 다른 대상 그룹을 대체 작업 세트와 연결합니다. 다른 배포를 수행하는 경우, 현재 배포의 원래 작업 세트와 연결된 대상 그룹은 다음 배포의 대체 작업 세트와 연결됩니다. 자세한 내용은 *Elastic Load Balancing 사용 설명서*의 [애플리케이션 로드 밸런서의 대상 그룹](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html)을 참조하세요. **Amazon ECS 작업 정의** *작업 정의*는 Amazon ECS 애플리케이션이 포함된 도커 컨테이너를 실행하는 데 필요합니다. CodeDeploy 애플리케이션의 AppSpec 파일에서 작업 정의의 ARN을 지정합니다. 자세한 내용은 *Amazon Elastic Container Service 사용 설명서* 및 [Amazon ECS 배포를 위한 AppSpec 'resources' 섹션](reference-appspec-file-structure-resources.md#reference-appspec-file-structure-resources-ecs)의 [Amazon ECS 작업 정의](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html)를 참조하세요. **Amazon ECS 애플리케이션의 컨테이너** Docker *컨테이너*란 애플리케이션이 실행될 수 있도록 코드와 해당 종속성을 패키징하는 소프트웨어 단위를 말합니다. 컨테이너는 애플리케이션을 격리하므로 애플리케이션이 다른 컴퓨팅 환경에서도 실행됩니다. 로드 밸런서는 Amazon ECS 애플리케이션 작업 세트의 컨테이너로 트래픽을 보냅니다. CodeDeploy 애플리케이션의 AppSpec 파일에서 컨테이너의 이름을 지정합니다. AppSpec 파일에 지정된 컨테이너는 Amazon ECS 작업 정의에 지정된 컨테이너 중 하나여야 합니다. 자세한 내용은 *Amazon Elastic Container Service 사용 설명서*의 [Amazon Elastic Container Service란 무엇입니까?](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html)와 [Amazon ECS 배포를 위한 AppSpec 'resources' 섹션](reference-appspec-file-structure-resources.md#reference-appspec-file-structure-resources-ecs)를 참조하세요. **대체 작업 세트의 포트** Amazon ECS 배포 중에 로드 밸런서가 CodeDeploy 애플리케이션의 AppSpec 파일에 지정된 이 *포트*로 트래픽을 보냅니다. CodeDeploy 애플리케이션의 AppSpec 파일에서 포트의 이름을 지정합니다. 자세한 내용은 [Amazon ECS 배포를 위한 AppSpec 'resources' 섹션](reference-appspec-file-structure-resources.md#reference-appspec-file-structure-resources-ecs) 단원을 참조하십시오. ## Amazon ECS 컴퓨팅 플랫폼의 배포 워크플로(높은 수준) 다음 다이어그램은 업데이트된 Amazon ECS 서비스 배포의 기본 단계를 보여줍니다. ![\[CodeDeploy가 애플리케이션을 Amazon ECS에 태스크 세트로 배포하는 방법.\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/images/deployment-process-ecs.png) 이러한 단계는 다음과 같습니다. 1. 배포하려는 항목을 고유하게 나타내는 이름을 지정하여 AWS CodeDeploy 애플리케이션을 생성합니다. Amazon ECS 애플리케이션을 배포하려면 AWS CodeDeploy 애플리케이션에서 Amazon ECS 컴퓨팅 플랫폼을 선택합니다. CodeDeploy는 배포 중에 애플리케이션을 사용하여 배포 그룹, 대상 그룹, 리스너, 트래픽 다시 라우팅 동작, 애플리케이션 개정 등의 올바른 배포 구성 요소를 참조합니다. 자세한 내용은 [CodeDeploy를 사용하여 애플리케이션 생성](applications-create.md) 단원을 참조하십시오. 1. 다음을 지정하여 배포 그룹을 설정합니다. + 배포 그룹 이름. + Amazon ECS 클러스터와 서비스 이름. Amazon ECS 서비스의 배포 컨트롤러는 CodeDeploy로 설정되어야 합니다. + 배포 중에 사용되는 프로덕션 리스너, 테스트 리스너(선택 사항), 대상 그룹 + 배포 설정(예: Amazon ECS 서비스의 대체 Amazon ECS 작업 세트로 프로덕션 트래픽을 다시 라우팅할 시기 및 Amazon ECS 서비스의 원래 Amazon ECS 작업 세트를 종료할 시기) + 설정(선택 사항) (예: 트리거, 경보, 롤백 동작) 1. *애플리케이션 사양 파일*(AppSpec 파일)을 지정합니다. Amazon S3에 업로드하거나, 콘솔에 YAML 또는 JSON 형식으로 입력하거나, AWS CLI 또는 SDK를 사용하여 지정할 수 있습니다. AppSpec 파일은 배포에 사용되는 Amazon ECS 작업 정의, 트래픽을 라우팅하는 데 사용되는 포트 매핑과 컨테이너 이름, 배포 수명 주기 후크 후 실행되는 Lambda 함수를 지정합니다. 컨테이너 이름은 Amazon ECS 작업 정의의 컨테이너여야 합니다. 자세한 내용은 [CodeDeploy의 애플리케이션 개정 작업](application-revisions.md) 단원을 참조하십시오. 1. 애플리케이션 개정을 배포합니다.는 Amazon ECS 서비스에 있는 작업 세트의 원래 버전에서 새로운 대체 작업 세트로 트래픽을 AWS CodeDeploy 다시 라우팅합니다. 배포 그룹에 지정된 대상 그룹은 원래 및 대체 작업 세트에 트래픽을 제공하는 데 사용됩니다. 배포가 완료되면 원래 작업 세트가 종료됩니다. 트래픽을 다시 라우팅하기 전에 테스트 리스너(선택 사항)를 지정하여 대체 버전에 테스트 트래픽을 제공할 수 있습니다. 자세한 내용은 [CodeDeploy에서 배포 만들기](deployments-create.md) 단원을 참조하십시오. 1. 배포 결과를 확인합니다. 자세한 내용은 [CodeDeploy에서 배포 모니터링](monitoring.md) 단원을 참조하십시오. ## Amazon ECS 배포 중에 발생하는 일 테스트 리스너를 사용해 Amazon ECS 배포를 시작하려면 먼저 구성 요소를 구성해야 합니다. 자세한 내용은 [Amazon ECS 배포를 시작하기 전](#deployment-steps-prerequisites-ecs) 단원을 참조하십시오. 다음 다이어그램은 Amazon ECS 배포를 시작할 준비를 마쳤을 때 구성 요소의 관계를 나타낸 것입니다. ![\[Amazon ECS 배포가 시작 준비가 되었을 때 로드 밸런서, 리스너, 대상 그룹 및 태스크 간의 관계입니다.\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/images/codedeploy-ecs-deployment-step-1.png) 배포가 시작되면 배포 수명 주기 이벤트가 한 번에 하나씩 실행되기 시작합니다. 일부 수명 주기 이벤트는 AppSpec 파일에서 지정된 Lambda 함수만 실행하는 후크입니다. 다음 표의 배포 수명 주기 이벤트는 실행 순서대로 나열되어 있습니다. 자세한 내용은 [Amazon ECS 배포를 위한 AppSpec 'hooks' 섹션](reference-appspec-file-structure-hooks.md#appspec-hooks-ecs) 단원을 참조하십시오. | 수명 주기 이벤트 | 수명 주기 이벤트 작업 | | --- | --- | | BeforeInstall(Lambda 함수 후크) | Lambda 함수 실행 | | 설치 | 대체 작업 세트를 설정합니다. | | AfterInstall(Lambda 함수 후크) | Lambda 함수 실행 | | AllowTestTraffic | 트래픽을 테스트 리스너에서 대상 그룹 2로 라우팅합니다. | | AfterAllowTestTraffic(Lambda 함수 후크) | Lambda 함수 실행 | | BeforeAllowTraffic(Lambda 함수 후크) | Lambda 함수 실행 | | AllowTraffic | 트래픽을 프로덕션 리스너에서 대상 그룹 2로 라우팅합니다. | | AfterAllowTraffic | Lambda 함수 실행 | **참고** 후크의 Lambda 함수는 선택 사항입니다. 1. **** AppSpec 파일의 `BeforeInstall` 후크에서 지정한 Lambda 함수를 실행합니다. 1. **** `Install` 수명 주기 이벤트 도중: 1. 대체 작업 세트가 Amazon ECS 서비스에 생성됩니다. 1. 업데이트된 컨테이너화 애플리케이션이 대체 작업 세트에 설치됩니다. 1. 두 번째 대상 그룹이 대체 작업 세트와 연결됩니다. 아래 다이어그램은 새로운 대체 작업 세트와 함께 배포 구성 요소를 나타낸 것입니다. 컨테이너화 애플리케이션은 이 작업 세트에 설치되어 있습니다. 작업 세트는 세 가지 작업으로 구성됩니다. 애플리케이션의 작업 수는 무제한입니다. 이제 두 번째 대상 그룹이 대체 작업 세트와 연결됩니다. ![\[새로운 대체 작업 세트와 함께 배포 구성 요소입니다. 컨테이너화 애플리케이션은 이 작업 세트에 설치되어 있습니다. 작업 세트는 세 가지 작업으로 구성됩니다. 이제 두 번째 대상 그룹이 대체 작업 세트와 연결됩니다.\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/images/codedeploy-ecs-deployment-step-2.png) 1. **** AppSpec 파일의 `AfterInstall` 후크에서 지정한 Lambda 함수를 실행합니다. 1. **** `AllowTestTraffic` 이벤트가 호출됩니다. 수명 주기 이벤트 과정에서 테스트 리스너가 트래픽을 업데이트된 컨테이너화 애플리케이션으로 라우팅합니다. ![\[테스트 리스너가 트래픽을 업데이트된 컨테이너화 애플리케이션으로 라우팅합니다.\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/images/codedeploy-ecs-deployment-step-3.png) 1. **** AppSpec 파일의 `AfterAllowTestTraffic` 후크에서 지정한 Lambda 함수를 실행합니다. Lambda 함수는 테스트 트래픽을 사용해 배포를 검증할 수 있습니다. 예를 들어 Lambda 함수는 트래픽을 테스트 리스너까지 전송한 후 대체 작업 세트에서 지표를 추적할 수 있습니다. 롤백이 구성된 경우에는 Lambda 함수에서 검증 테스트에 실패할 경우 롤백을 트리거하는 CloudWatch 경보를 구성할 수 있습니다. 검증 테스트가 완료되면 다음 중 한 가지가 발생합니다. + 검증에 실패하고 롤백이 구성된 경우 배포 상태가 `Failed`로 표시되고 구성 요소는 배포가 시작되었던 상태로 돌아갑니다. + 검증에 실패하였지만 롤백이 구성되어 있지 않다면 배포 상태가 `Failed`로 표시되고 구성 요소는 현재 상태를 유지합니다. + 검증에 성공한 경우에는 배포가 `BeforeAllowTraffic` 후크까지 이어집니다. 자세한 내용은 [CodeDeploy에서 CloudWatch 경보를 사용하여 배포 모니터링](monitoring-create-alarms.md), [자동 롤백](deployments-rollback-and-redeploy.md#deployments-rollback-and-redeploy-automatic-rollbacks), [배포 그룹에 대한 고급 옵션 구성](deployment-groups-configure-advanced-options.md) 단원을 참조하세요. 1. **** AppSpec 파일의 `BeforeAllowTraffic` 후크에서 지정한 Lambda 함수를 실행합니다. 1. **** `AllowTraffic` 이벤트가 호출됩니다. 프로덕션 트래픽이 원래 작업 세트에서 대체 작업 세트로 다시 라우팅됩니다. 다음 다이어그램은 프로덕션 트래픽을 수신하는 대체 작업 세트를 나타낸 것입니다. ![\[대체 태스크 세트는 프로덕션 트래픽을 수신합니다.\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/images/codedeploy-ecs-deployment-step-4.png) 1. **** AppSpec 파일의 `AfterAllowTraffic` 후크에서 지정한 Lambda 함수를 실행합니다. 1. **** 모든 이벤트에 성공하면 배포 상태가 `Succeeded`로 설정되고 원래 작업 세트는 제거됩니다. ![\[모든 이벤트가 성공합니다.\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/images/codedeploy-ecs-deployment-step-6.png) ## 애플리케이션 개정 업로드 AppSpec 파일을 Amazon S3에 배치하거나, 콘솔 또는 AWS CLI에서 직접 입력합니다. 자세한 내용은 [CodeDeploy 애플리케이션 사양(AppSpec) 파일](application-specification-files.md) 단원을 참조하십시오. ## 애플리케이션 및 배포 그룹 만들기 Amazon ECS 컴퓨팅 플랫폼의 CodeDeploy 배포 그룹은 배포 중에 사용되는 두 대상 그룹과 업데이트된 Amazon ECS 애플리케이션에 트래픽을 제공하는 리스너를 식별합니다. 배포 그룹은 또한 일련의 구성 옵션(경보 및 롤백 구성 등) 세트를 정의합니다. ## 애플리케이션 개정 배포 이제 배포 그룹에 지정된 업데이트된 Amazon ECS 서비스를 배포할 준비가 되었습니다. CodeDeploy 콘솔 또는 [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html) 명령을 사용할 수 있습니다. 개정 및 배포 그룹을 비롯하여 배포를 제어하기 위해 지정할 수 있는 파라미터가 있습니다. ## 애플리케이션 업데이트 애플리케이션을 업데이트한 다음 CodeDeploy 콘솔을 사용하거나 [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html) 명령을 호출하여 개정 버전을 푸시할 수 있습니다. ## 중지 및 실패한 배포 CodeDeploy 콘솔 또는 [stop-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/stop-deployment.html) 명령을 사용하여 배포를 중지할 수 있습니다. 배포를 중지하려고 하면 다음 3가지 동작 중 하나가 발생합니다. + 배포가 중지되고 성공 상태가 반환됩니다. 이 경우 중지된 배포의 배포 그룹에서 더 이상 배포 수명 주기 이벤트가 실행되지 않습니다. + 배포가 즉시 중지되지 않고, 대기 중 상태가 반환됩니다. 이 경우, 일부 배포 수명 주기 이벤트는 배포 그룹에서 계속 실행 중일 수 있습니다. 대기 중인 작업이 완료되면 배포 중지를 위한 후속 호출에서 성공 상태를 반환합니다. + 배포를 중지할 수 없고 오류가 반환됩니다. 자세한 내용은 AWS CodeDeploy API 참조의 [오류 정보](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_ErrorInformation.html) 및 [일반 오류를](https://docs.aws.amazon.com/codedeploy/latest/APIReference/CommonErrors.html) 참조하세요. ## 다시 배포 및 배포 롤백 CodeDeploy는 대체 작업 세트에서 원래 작업 세트로 트래픽을 다시 라우팅하여 롤백을 구현합니다. 배포에 실패한 경우 또는 경보 모니터링 임계값에 도달한 경우 등 특정 조건이 충족되면 배포를 자동으로 롤백하도록 배포 그룹을 구성할 수 있습니다. 또한 개별 배포에서 배포 그룹에 대해 지정한 롤백 설정을 재정의할 수도 있습니다. 뿐만 아니라 이전에 배포한 개정을 수동으로 다시 배포하여 실패한 배포를 롤백하도록 선택할 수도 있습니다. 어느 경우에도 새 배포나 롤백 배포에 고유의 배포 ID가 할당됩니다. CodeDeploy 콘솔에 자동 배포의 결과인 배포 목록이 표시됩니다. 다시 배포하는 경우 현재 배포의 원래 작업 세트와 연결된 대상 그룹은 재배포의 대체 작업 세트와 연결됩니다. 자세한 내용은 [CodeDeploy를 사용하여 재배포 및 배포 롤백](deployments-rollback-and-redeploy.md) 단원을 참조하십시오. ## 를 통한 Amazon ECS 블루/그린 배포 AWS CloudFormation AWS CloudFormation 를 사용하여 CodeDeploy를 통해 Amazon ECS 블루/그린 배포를 관리할 수 있습니다. 자세한 내용은 [를 통해 Amazon ECS 블루/그린 배포 생성 CloudFormation](deployments-create-ecs-cfn.md) 단원을 참조하십시오. **참고** 아시아 태평양(오사카) 리전에서는를 사용하여 Amazon ECS 블루/그린 배포를 관리할 수 CloudFormation 없습니다. # EC2/온프레미스 컴퓨팅 플랫폼의 배포 이 항목에서는 EC2/온프레미스 컴퓨팅 플랫폼을 사용하는 CodeDeploy 배포의 워크플로 및 구성 요소에 대해 설명합니다. 블루/그린 배포에 대한 자세한 내용은 [블루/그린 배포 개요](welcome.md#welcome-deployment-overview-blue-green) 단원을 참조하세요. **Topics** + [EC2/온프레미스 컴퓨팅 플랫폼의 배포 구성 요소](#deployment-steps-components-server) + [EC2/온프레미스 컴퓨팅 플랫폼의 배포 워크플로](#deployment-steps-workflow) + [인스턴스 설정](#deployment-steps-setting-up-instances) + [애플리케이션 개정 업로드](#deployment-steps-uploading-your-app) + [애플리케이션 및 배포 그룹 만들기](#deployment-steps-registering-app-deployment-groups) + [애플리케이션 개정 배포](#deployment-steps-deploy) + [애플리케이션 업데이트](#deployment-steps-updating-your-app) + [중지 및 실패한 배포](#deployment-stop-fail) + [다시 배포 및 배포 롤백](#deployment-rollback) ## EC2/온프레미스 컴퓨팅 플랫폼의 배포 구성 요소 다음 다이어그램은 EC2/온프레미스 컴퓨팅 플랫폼에서의 CodeDeploy 배포 구성 요소를 보여줍니다. ![\[EC2/온프레미스 컴퓨팅 플랫폼에서의 CodeDeploy 배포 구성 요소입니다.\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/images/deployment-components-workflow.png) ## EC2/온프레미스 컴퓨팅 플랫폼의 배포 워크플로 다음 다이어그램은 애플리케이션 개정 배포의 주요 단계를 보여줍니다. ![\[애플리케이션 개정 배포의 주요 단계입니다.\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/images/deployment-process.png) 이러한 단계는 다음과 같습니다. 1. 애플리케이션을 생성하고 배포하려는 애플리케이션 개정 버전과 애플리케이션의 컴퓨팅 플랫폼을 고유하게 식별하는 이름을 지정합니다. CodeDeploy에서는 배포 중 이 이름을 사용하여 해당 배포가 올바른 배포 구성 요소(예: 배포 그룹, 배포 구성 및 애플리케이션 개정)를 참조하도록 합니다. 자세한 내용은 [CodeDeploy를 사용하여 애플리케이션 생성](applications-create.md) 단원을 참조하십시오. 1. 애플리케이션 개정을 배포하려는 인스턴스 및 배포 유형을 지정하여 배포 그룹을 설정합니다. 인 플레이스(in-place) 배포는 최신 애플리케이션 개정으로 인스턴스를 업데이트합니다. 블루/그린 배포는 로드 밸런서에 배포 그룹의 대체 인스턴스 세트를 등록하고 원본 인스턴스의 등록을 취소합니다. 인스턴스, Amazon EC2 Auto Scaling 그룹 이름 또는 둘 다에 적용되는 태그를 지정할 수 있습니다. 배포 그룹에 하나의 태그 그룹을 지정한 경우, CodeDeploy에서는 최소 한 개의 지정된 태그가 적용된 인스턴스를 배포합니다. 2개 이상의 태그 그룹을 지정한 경우 CodeDeploy는 각 태그 그룹의 기준에 맞는 인스턴스만 배포합니다. 자세한 내용은 [CodeDeploy에서 배포 그룹에 대한 인스턴스에 태그 지정](instances-tagging.md) 단원을 참조하십시오. 어떤 경우든 인스턴스는 배포에 사용하도록 구성되어야 하며(즉, 태그가 지정되거나 Amazon EC2 Auto Scaling 그룹에 속해야 함), CodeDeploy 에이전트를 설치하여 실행 중이어야 합니다. Amazon Linux 또는 Windows Server를 기반으로 Amazon EC2 인스턴스를 빠르게 설정하는 데 사용할 수 있는 CloudFormation 템플릿을 제공합니다. 또한 Amazon Linux, Ubuntu Server, Red Hat Enterprise Linux(RHEL) 또는 Windows Server 인스턴스에 설치할 수 있는 독립 실행형 CodeDeploy 에이전트도 제공합니다. 자세한 내용은 [CodeDeploy에서 배포 그룹 만들기](deployment-groups-create.md) 단원을 참조하십시오. 다음 옵션도 지정할 수 있습니다. + **Amazon SNS 알림**. 배포 및 인스턴스에서 지정된 이벤트(예: 성공 또는 실패 이벤트)가 발생하면 Amazon SNS 주제 구독자에게 알림을 보내는 트리거를 만듭니다. 자세한 내용은 [Amazon SNS 이벤트 알림으로 배포 모니터링](monitoring-sns-event-notifications.md) 단원을 참조하십시오. + **경보 기반 배포 및 관리**. 지표가 CloudWatch에 설정된 임계값을 초과하거나 임계값 미만인 경우 배포를 중지하는 Amazon CloudWatch 경보 모니터링을 구현합니다. + **자동 배포 롤백**. 배포에 실패하거나 경보 임계값에 도달한 경우 이전에 알려진 양호한 상태의 개정으로 자동 롤백되도록 배포를 구성합니다. 1. 애플리케이션 개정을 동시에 배포해야 할 인스턴스 수와 배포 성공 및 실패 조건을 설정하는 배포 구성을 지정합니다. 자세한 내용은 [CodeDeploy의 배포 구성 세부 정보 보기](deployment-configurations-view-details.md) 단원을 참조하십시오. 1. 애플리케이션 개정을 Amazon S3 또는 GitHub로 업로드합니다. 배포하려는 파일 및 배포 중 실행하려는 모든 스크립트 이외에 *애플리케이션 사양 파일*(AppSpec file)을 포함해야 합니다. 이 파일에는 각 인스턴스에 파일을 복사할 위치 및 배포 스크립트를 실행할 시점 등과 같은 배포 명세가 포함되어 있습니다. 자세한 내용은 [CodeDeploy의 애플리케이션 개정 작업](application-revisions.md) 단원을 참조하십시오. 1. 애플리케이션 개정을 배포 그룹에 배포합니다. 배포 그룹의 각 인스턴스에 설치된 CodeDeploy 에이전트는 애플리케이션 개정을 Amazon S3 또는 GitHub에서 인스턴스로 복사합니다. 그런 다음 CodeDeploy 에이전트는 개정의 번들을 해제하고, AppSpec 파일을 사용하여 지정한 위치로 파일을 복사하고, 배포 스크립트를 실행합니다. 자세한 내용은 [CodeDeploy에서 배포 만들기](deployments-create.md) 단원을 참조하십시오. 1. 배포 결과를 확인합니다. 자세한 내용은 [CodeDeploy에서 배포 모니터링](monitoring.md) 단원을 참조하십시오. 1. 개정을 다시 배포합니다. 소스 콘텐츠에서 버그를 수정하거나, 배포 스크립트를 다른 순서로 실행하거나, 실패한 배포를 해결해야 하는 경우 다시 배포하려고 할 수 있습니다. 다시 배포하려면 개정된 소스 콘텐츠, 배포 스크립트, AppSpec 파일을 새 개정으로 다시 번들링한 다음 해당 개정을 Amazon S3 버킷 또는 GitHub 리포지토리로 업로드합니다. 그런 다음 새 개정을 사용하여 동일한 배포 그룹으로 새로 배포를 실행합니다. 자세한 내용은 [CodeDeploy에서 배포 만들기](deployments-create.md) 단원을 참조하십시오. ## 인스턴스 설정 처음으로 애플리케이션 개정을 배포하려면 인스턴스를 설정해야 합니다. 애플리케이션 개정에 프로덕션 서버 3개와 백업 서버 2개가 필요한 경우 인스턴스 5개를 시작 또는 사용합니다. 인스턴스를 수동으로 프로비저닝하려면: 1. 인스턴스에 CodeDeploy 에이전트 설치합니다. Amazon Linux, Ubuntu Server, RHEL, Windows Server 인스턴스에 CodeDeploy 에이전트를 설치할 수 있습니다. 1. 배포 그룹에서 인스턴스를 식별하는 데 태그를 사용하는 경우 태깅을 활성화합니다. CodeDeploy에서는 태그를 사용하여 인스턴스를 식별하고 CodeDeploy 배포 그룹으로 그룹화합니다. 시작하기 자습서를 둘 다 진행했지만 키 또는 값을 사용하여 배포 그룹의 태그를 정의할 수 있습니다. 1. IAM 인스턴스 프로파일로 Amazon EC2 인스턴스를 시작합니다. IAM 인스턴스 프로파일은 CodeDeploy 에이전트가 인스턴스의 자격 증명을 확인하기 위해 시작되므로 Amazon EC2 인스턴스에 연결되어 있어야 합니다. 1. 서비스 역할을 만듭니다. CodeDeploy가 AWS 계정의 태그를 확장할 수 있도록 서비스 액세스 권한을 제공합니다. 초기 배포의 경우 CloudFormation 템플릿이이 모든 작업을 자동으로 수행합니다. 이 템플릿은 이미 설치된 CodeDeploy 에이전트를 사용하여 Amazon Linux 또는 Windows Server에 기반한 단일 Amazon EC2 인스턴스를 새로 만들고 구성합니다. 자세한 내용은 [CodeDeploy용 인스턴스 작업](instances.md) 단원을 참조하십시오. **참고** 블루/그린 배포의 경우 대체 환경을 위해 이미 보유하고 있는 인스턴스를 사용하거나, CodeDeploy에서 배포 프로세스의 일부로 새 인스턴스를 프로비저닝하게 하는 두 가지 옵션 중에서 선택할 수 있습니다. ## 애플리케이션 개정 업로드 AppSpec 파일을 애플리케이션의 소스 콘텐츠 폴더 구조의 루트 폴더에 저장합니다. 자세한 내용은 [CodeDeploy 애플리케이션 사양(AppSpec) 파일](application-specification-files.md) 단원을 참조하십시오. 애플리케이션의 소스 콘텐츠 폴더 구조를 아카이브 파일 형식(예: zip, tar 또는 압축 tar)으로 번들링합니다. 아카이브 파일(*개정 버전*)을 Amazon S3 버킷 또는 GitHub 리포지토리에 업로드합니다. **참고** tar 및 압축된 tar 아카이브 파일 형식(.tar 및 .tar.gz)은 Windows Server 인스턴스에서 지원되지 않습니다. ## 애플리케이션 및 배포 그룹 만들기 CodeDeploy 배포 그룹은 태그, Amazon EC2 Auto Scaling 그룹 이름 또는 둘 모두를 기반으로 인스턴스 모음을 식별합니다. 애플리케이션 개정 여러 개를 동일한 인스턴스에 배포하거나, 애플리케이션 개정 하나를 여러 인스턴스에 배포할 수 있습니다. 예를 들어, 프로덕션 서버 3개에 태그 "Prod"를 추가하고 백업 서버 2개에 태그 "Backup"을 추가할 수 있습니다. 이러한 두 태그를 사용하여 CodeDeploy 애플리케이션에서 두 가지 배포 그룹을 만들 수 있으며, 배포에 포함시킬 서버 집합(또는 둘 다)을 선택할 수 있습니다. 배포 그룹에 여러 태그 그룹을 사용하여 적은 수의 인스턴스로 배포를 제한할 수 있습니다. 자세한 내용은 [CodeDeploy에서 배포 그룹에 대한 인스턴스에 태그 지정](instances-tagging.md) 단원을 참조하세요. ## 애플리케이션 개정 배포 이제 Amazon S3 또는 GitHub에서 배포 그룹으로 애플리케이션 개정을 배포할 준비가 되었습니다. CodeDeploy 콘솔 또는 [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html) 명령을 사용할 수 있습니다. 개정, 배포 그룹 및 배포 구성을 비롯하여 배포를 제어하기 위해 지정할 수 있는 파라미터가 있습니다. ## 애플리케이션 업데이트 애플리케이션을 업데이트한 다음 CodeDeploy 콘솔을 사용하거나 [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html) 명령을 호출하여 개정 버전을 푸시할 수 있습니다. ## 중지 및 실패한 배포 CodeDeploy 콘솔 또는 [stop-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/stop-deployment.html) 명령을 사용하여 배포를 중지할 수 있습니다. 배포를 중지하려고 하면 다음 3가지 동작 중 하나가 발생합니다. + 배포가 중지되고 성공 상태가 반환됩니다. 이 경우 중지된 배포의 배포 그룹에서 더 이상 배포 수명 주기 이벤트가 실행되지 않습니다. 배포 그룹의 인스턴스 중 하나 이상에 일부 파일이 이미 복사되었거나 이러한 인스턴스에서 일부 스크립트가 이미 실행되었을 수 있습니다. + 배포가 즉시 중지되지 않고, 대기 중 상태가 반환됩니다. 이 경우, 일부 배포 수명 주기 이벤트는 배포 그룹에서 계속 실행 중일 수 있습니다. 배포 그룹의 인스턴스 중 하나 이상에 일부 파일이 이미 복사되었거나 이러한 인스턴스에서 일부 스크립트가 이미 실행되었을 수 있습니다. 대기 중인 작업이 완료되면 배포 중지를 위한 후속 호출에서 성공 상태를 반환합니다. + 배포를 중지할 수 없고 오류가 반환됩니다. 자세한 내용은 AWS CodeDeploy API 참조의 [ErrorInformation](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_ErrorInformation.html) 및 [Common errors](https://docs.aws.amazon.com/codedeploy/latest/APIReference/CommonErrors.html)를 참조하세요. 중지된 배포와 마찬가지로 배포에 실패하면 배포 그룹에 있는 하나 이상의 인스턴스에서 일부 배포 수명 주기 이벤트가 이미 실행되었을 수 있습니다. 배포에 실패한 이유를 확인하려면 CodeDeploy 콘솔을 사용하거나, [get-deployment-instance](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-instance.html) 명령을 호출하거나, 실패한 배포에서 로그 파일 데이터를 분석할 수 있습니다. 자세한 내용은 [애플리케이션 수정 버전 및 로그 파일 정리](codedeploy-agent.md#codedeploy-agent-revisions-logs-cleanup) 및 [CodeDeploy EC2/온프레미스 배포에 대한 로그 데이터 보기](deployments-view-logs.md) 단원을 참조하세요. ## 다시 배포 및 배포 롤백 CodeDeploy에서는 이전에 배포된 개정 버전을 새 배포로 다시 배포하여 롤백을 구현합니다. 배포에 실패한 경우 또는 경보 모니터링 임계값에 도달한 경우 등 특정 조건이 충족되면 배포를 자동으로 롤백하도록 배포 그룹을 구성할 수 있습니다. 또한 개별 배포에서 배포 그룹에 대해 지정한 롤백 설정을 재정의할 수도 있습니다. 뿐만 아니라 이전에 배포한 개정을 수동으로 다시 배포하여 실패한 배포를 롤백하도록 선택할 수도 있습니다. 어느 경우에도 새 배포나 롤백 배포에 고유의 배포 ID가 할당됩니다. CodeDeploy 콘솔에서 볼 수 있는 배포 목록에는 자동 배포로 배포된 항목이 표시됩니다. 자세한 내용은 [CodeDeploy를 사용하여 재배포 및 배포 롤백](deployments-rollback-and-redeploy.md) 단원을 참조하십시오. # CodeDeploy 애플리케이션 사양(AppSpec) 파일 CodeDeploy에 고유한 애플리케이션 사양 파일(AppSpec 파일)은 [YAML](http://www.yaml.org) 형식 또는 [JSON](http://www.json.org) 형식 파일입니다. AppSpec 파일은 파일에 정의된 일련의 수명 주기 이벤트 후크로 각 배포를 관리하는 데 사용됩니다. 올바른 형식의 AppSpec 파일을 만드는 방법에 대한 자세한 내용은 [CodeDeploy AppSpec 파일 참조](reference-appspec-file.md) 단원을 참조하세요. **Topics** + [Amazon ECS 컴퓨팅 플랫폼에 대한 AppSpec 파일](#appspec-files-on-ecs-compute-platform) + [AWS Lambda 컴퓨팅 플랫폼의 AppSpec 파일](#appspec-files-on-lambda-compute-platform) + [EC2/온프레미스 컴퓨팅 플랫폼에 대한 AppSpec 파일](#appspec-files-on-server-compute-platform) + [CodeDeploy 에이전트에서 AppSpec 파일을 사용하는 방법](#application-specification-files-agent-usage) ## Amazon ECS 컴퓨팅 플랫폼에 대한 AppSpec 파일 애플리케이션에서 Amazon ECS 컴퓨팅 플랫폼을 사용하는 경우 AppSpec 파일은 YAML 또는 JSON 형식일 수도 있습니다. 콘솔의 편집기에 직접 입력할 수도 있습니다. AppSpec 파일은 다음을 지정하는 데 사용됩니다. + Amazon ECS 서비스의 이름과 새 작업 세트로 트래픽을 보내는 데 사용되는 컨테이너 이름 및 포트. + 검증 테스트로 사용할 함수 배포 수명 주기 이벤트 후에 유효성 검사 Lambda 함수를 실행할 수 있습니다. 자세한 내용은 [Amazon ECS 배포를 위한 AppSpec 'hooks' 섹션](reference-appspec-file-structure-hooks.md#appspec-hooks-ecs), [Amazon ECS 배포의 AppSpec 파일 구조](reference-appspec-file-structure.md#ecs-appspec-structure), [Amazon ECS 배포용 AppSpec 파일 예제](reference-appspec-file-example.md#appspec-file-example-ecs) 단원을 참조하세요. ## AWS Lambda 컴퓨팅 플랫폼의 AppSpec 파일 애플리케이션이 AWS Lambda 컴퓨팅 플랫폼을 사용하는 경우 AppSpec 파일의 형식을 YAML 또는 JSON으로 지정할 수 있습니다. 콘솔의 편집기에 직접 입력할 수도 있습니다. AppSpec 파일은 다음을 지정하는 데 사용됩니다. + 배포할 AWS Lambda 함수 버전입니다. + 검증 테스트로 사용할 함수 배포 수명 주기 이벤트 후에 유효성 검사 Lambda 함수를 실행할 수 있습니다. 자세한 내용은 [AWS Lambda 배포를 위한 AppSpec 'hooks' 섹션](reference-appspec-file-structure-hooks.md#appspec-hooks-lambda) 단원을 참조하십시오. ## EC2/온프레미스 컴퓨팅 플랫폼에 대한 AppSpec 파일 애플리케이션에서 EC2/온프레미스 컴퓨팅 플랫폼을 사용하는 경우 AppSpec 파일은 항상 YAML 형식입니다. AppSpec 파일은 다음 작업을 수행하는 데 사용됩니다. + 애플리케이션 개정의 소스 파일을 인스턴스의 대상으로 매핑합니다. + 배포된 파일에 대한 사용자 지정 권한을 지정합니다. + 배포 프로세스의 다양한 단계에서 각 인스턴스에 실행할 스크립트를 지정합니다. 여러 개별 배포 수명 주기 이벤트 후에 인스턴스에서 스크립트를 실행할 수 있습니다. CodeDeploy는 파일에 지정된 스크립트만 실행하지만 이러한 스크립트는 인스턴스에서 다른 스크립트를 호출할 수 있습니다. 인스턴스에서 실행 중인 운영 체제에서 지원하는 경우 모든 유형의 스크립트를 실행할 수 있습니다. 자세한 내용은 [EC2/온프레미스 배포를 위한 AppSpec 'hooks' 섹션](reference-appspec-file-structure-hooks.md#appspec-hooks-server) 단원을 참조하십시오. ## CodeDeploy 에이전트에서 AppSpec 파일을 사용하는 방법 배포하는 동안 CodeDeploy 에이전트는 AppSpec 파일의 **hooks** 섹션에서 현재 이벤트의 이름을 조회합니다. 이벤트가 발견되지 않으면 CodeDeploy 에이전트가 다음 단계로 이동합니다. 이벤트가 발견되면 CodeDeploy 에이전트가 실행할 스크립트 목록을 검색합니다. 스크립트는 파일에 나타나는 순서대로 순차적으로 실행됩니다. 각 스크립트의 상태는 인스턴스의 CodeDeploy 에이전트 로그 파일에 기록됩니다. 스크립트가 성공적으로 실행되면 종료 코드 0(영)을 반환합니다. **참고** CodeDeploy 에이전트는 AWS Lambda 또는 Amazon ECS 배포에 사용되지 않습니다. **설치** 이벤트 중에 CodeDeploy 에이전트는 AppSpec 파일의 **files** 섹션에 정의된 매핑을 사용하여 개정에서 인스턴스로 복사할 폴더 또는 파일을 결정합니다. 운영 체제에 설치된 CodeDeploy 에이전트가 AppSpec 파일에 나열된 항목과 일치하지 않으면 배포가 실패합니다. CodeDeploy 에이전트 로그 파일에 대한 자세한 내용은 [CodeDeploy 에이전트 작업](codedeploy-agent.md) 단원을 참조하세요.