

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# CodeDeploy와 제품 및 서비스 통합
<a name="integrations"></a>

기본적으로 CodeDeploy는 여러 AWS 서비스 및 파트너 제품 및 서비스와 통합됩니다. 다음 정보를 통해 사용 중인 제품과 서비스를 통합할 CodeDeploy를 구성할 수 있습니다.
+ [다른 AWS 서비스와의 통합](integrations-aws.md)
+  [파트너 제품 및 서비스와의 통합](integrations-partners.md)
+ [커뮤니티의 통합 예제](integrations-community.md)

# 다른 AWS 서비스와의 통합
<a name="integrations-aws"></a>

CodeDeploy는 다음 AWS 서비스와 통합됩니다.


|  |  | 
| --- |--- |
| Amazon CloudWatch |  [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/)는 AWS 클라우드 리소스 및 AWS에서 실행하는 애플리케이션을 모니터링하는 서비스입니다. Amazon CloudWatch를 사용하여 지표를 수집 및 추적하고, 로그 파일을 수집 및 모니터링하고, 경보를 설정할 수 있습니다. CodeDeploy는 다음 CloudWatch 도구를 지원합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/integrations-aws.html)  | 
| Amazon EC2 Auto Scaling |  CodeDeploy는 [Amazon EC2 Auto Scaling](https://aws.amazon.com/autoscaling)을 지원합니다. 이 AWS 서비스는 다음과 같이 지정한 기준에 따라 Amazon EC2 인스턴스를 자동으로 시작할 수 있습니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/integrations-aws.html) 필요할 때 언제든지 Amazon EC2 인스턴스 그룹을 확장한 다음 CodeDeploy를 사용하여 애플리케이션 개정 버전을 자동으로 배포할 수 있습니다. Amazon EC2 Auto Scaling은 더 이상 필요하지 않은 경우 해당 Amazon EC2 인스턴스를 종료합니다. 자세히 알아보기: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/integrations-aws.html)  | 
| Amazon Elastic Container Service |   CodeDeploy를 사용하여 Amazon ECS 컨테이너화된 애플리케이션을 작업 세트로 배포할 수 있습니다. CodeDeploy는 애플리케이션의 업데이트 버전을 새로운 대체 작업 세트로 설치하여 블루/그린 배포를 수행합니다. CodeDeploy는 프로덕션 트래픽을 원래 애플리케이션 작업 세트에서 대체 작업 세트로 다시 라우팅합니다. 배포가 성공하면 기존 작업 세트는 종료됩니다. Amazon ECS에 대한 자세한 내용은 [Amazon Elastic Container Service](https://aws.amazon.com/ecs/)를 참조하세요.  카나리(Canary), 선형(Linear) 또는 한번에 모두(All-at-once) 구성을 선택하여 배포 중 업데이트된 작업 세트로 트래픽을 전송하는 방식을 관리할 수 있습니다. Amazon ECS 배포에 대한 자세한 내용은 [Amazon ECS 컴퓨팅 플랫폼에 배포](https://docs.aws.amazon.com/en_us/codedeploy/latest/userguide/deployment-steps-ecs.html)를 참조하세요.  | 
| AWS CloudTrail |  CodeDeploy는 [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)과 통합되어 있습니다. 이 서비스는 AWS 계정에서 CodeDeploy에 의해 또는 CodeDeploy를 대신하여 수행된 API 호출을 캡처하고 사용자가 지정하는 Amazon S3 버킷에 로그 파일을 전송합니다. CloudTrail은 CodeDeploy 콘솔, AWS CLI를 통한 CodeDeploy 명령 또는 CodeDeploy API에서 직접 API 호출을 캡처합니다. CloudTrail에서 수집한 정보를 사용하여 다음을 확인할 수 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/integrations-aws.html) 자세히 알아보기: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/integrations-aws.html)  | 
| AWS Cloud9 |  [AWS Cloud9](https://docs.aws.amazon.com/cloud9/latest/user-guide/)는 인터넷에 연결된 시스템의 브라우저만 사용하여 코드를 작성, 실행, 디버깅 및 배포하는 데 사용할 수 있는 온라인 클라우드 기반 통합 개발 환경(IDE)입니다. 에는 코드 편집기, 디버거, 터미널 및 AWS CLI 및 Git과 같은 필수 도구가 AWS Cloud9 포함되어 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/integrations-aws.html) 에 대한 자세한 내용은 [ 정의 AWS Cloud9](https://docs.aws.amazon.com/cloud9/latest/user-guide/welcom.html) 및 시작하기를 AWS Cloud9참조하세요. [AWS Cloud9](https://docs.aws.amazon.com/cloud9/latest/user-guide/get-started.html)   | 
| AWS CodePipeline |  [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/)은 지속적인 전송 프로세스에서 소프트웨어 출시에 필요한 단계를 모델링, 시각화 및 자동화하는 데 사용할 수 있는 지속적인 전송 서비스입니다. AWS CodePipeline 을 사용하면 고유한 릴리스 프로세스를 정의할 수 있습니다. 따라서 해당 서비스에서 코드 변경이 발생할 때마다 코드를 빌드, 테스트, 배포합니다. 예를 들어, 하나의 애플리케이션에 대해 Beta, Gamma, Prod의 세 가지 배포 그룹이 있을 수 있습니다. 소스 코드 변경 시마다 업데이트된 내용이 각 배포 그룹에 하나씩 배포되도록 파이프라인을 설정할 수 있습니다. CodeDeploy를 사용하여 배포 AWS CodePipeline 하도록를 구성할 수 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/integrations-aws.html)  파이프라인을 생성하기 전 단계나 **파이프라인 생성(Create Pipeline)** 마법사에서 배포 작업에 사용할 CodeDeploy 애플리케이션, 배포 및 배포 그룹을 생성할 수 있습니다. 자세히 알아보기: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/integrations-aws.html)  | 
| AWS 서버리스 애플리케이션 모델 |  AWS 서버리스 애플리케이션 모델(AWS SAM)은 서버리스 애플리케이션을 정의하는 모델입니다. 이를 확장 CloudFormation 하여 서버리스 애플리케이션에 필요한 함수, Amazon API Gateway APIs 및 Amazon DynamoDB 테이블을 정의하는 AWS Lambda 간소화된 방법을 제공합니다. 이미 AWS SAM을 사용하는 경우 배포 기본 설정을 추가하여 CodeDeploy를 사용하여 AWS Lambda 애플리케이션 배포 중에 트래픽이 이동하는 방식을 관리할 수 있습니다. 자세한 내용은 [AWS Serverless Application Model](https://github.com/awslabs/serverless-application-model)을 참조하세요.  | 
| Elastic Load Balancing |  CodeDeploy는 수신 애플리케이션 트래픽을 여러 Amazon EC2 인스턴스로 분산하는 서비스인 [Elastic Load Balancing](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elastic-load-balancing.html)을 지원합니다. CodeDeploy 배포 시, 로드 밸런서는 준비되지 않았거나, 현재 배포 중이거나, 더 이상 환경의 일부로 필요하지 않은 인스턴스로 트래픽이 라우팅되지 않도록 합니다. 자세히 알아보기: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/integrations-aws.html)  | 

**Topics**
+ [Amazon EC2 오토 스케일링](integrations-aws-auto-scaling.md)
+ [Integrating CodeDeploy with Elastic Load Balancing](integrations-aws-elastic-load-balancing.md)

# Amazon EC2 Auto Scaling과 CodeDeploy 통합
<a name="integrations-aws-auto-scaling"></a>

CodeDeploy는 정의한 조건에 따라 Amazon EC2 인스턴스를 자동으로 시작하는 AWS 서비스인 Amazon EC2 Auto Scaling을 지원합니다. 이러한 조건에는 지정된 시간 간격에서 CPU 사용률, 디스크 읽기 또는 쓰기, 인바운드 또는 아웃바운드 네트워크 트래픽에 대해 초과되는 제한이 포함될 수 있습니다. Amazon EC2 Auto Scaling은 더 이상 필요하지 않은 경우 해당 인스턴스를 종료합니다. 자세한 내용은 *Amazon EC2 Auto Scaling 사용 설명서*의 [Amazon EC2 Auto Scaling이란?](https://docs.aws.amazon.com/autoscaling/latest/userguide/WhatIsAutoScaling.html)을 참조하세요.

새 Amazon EC2 인스턴스가 Amazon EC2 Auto Scaling 그룹의 일부로 시작되면 CodeDeploy에서는 개정을 새 인스턴스로 자동 배포할 수 있습니다. 또한 Elastic Load Balancing 로드 밸런서에 등록된 Amazon EC2 Auto Scaling 인스턴스를 사용하여 CodeDeploy에서 배포를 조정할 수도 있습니다. 자세한 내용은 [CodeDeploy와 Elastic Load Balancing 통합](integrations-aws-elastic-load-balancing.md) 및 [Elastic Load Balancing에서 CodeDeploy Amazon EC2 배포에 대한 로드 밸런서 설정](deployment-groups-create-load-balancer.md) 섹션을 참조하세요.

**참고**  
여러 배포 그룹과 단일 Amazon EC2 Auto Scaling 그룹을 연결하는 경우 문제가 발생할 수 있습니다. 한 개의 배포에 실패하면 예를 들어, 인스턴스가 종료되기 시작하지만 실행 중인 다른 배포는 시간 초과까지 한 시간 가량 걸릴 수 있습니다. 자세한 내용은 [단일 Amazon EC2 Auto Scaling 그룹으로 여러 배포 그룹 연결 피하기](troubleshooting-auto-scaling.md#troubleshooting-multiple-depgroups) 및 [세부 정보: CodeDeploy 및 Amazon EC2 Auto Scaling 통합](https://aws.amazon.com/blogs/devops/under-the-hood-aws-codedeploy-and-auto-scaling-integration/)을 참조하세요.

**Topics**
+ [Amazon EC2 Auto Scaling 그룹에 CodeDeploy 애플리케이션 배포](#integrations-aws-auto-scaling-deploy)
+ [Auto Scaling 확장 이벤트 중 종료 배포 활성화](#integrations-aws-auto-scaling-behaviors-hook-enable)
+ [Amazon EC2 Auto Scaling에서 CodeDeploy를 사용하는 방식](#integrations-aws-auto-scaling-behaviors)
+ [CodeDeploy 및 Amazon EC2 Auto Scaling에서 사용자 지정 AMI 사용](#integrations-aws-auto-scaling-custom-ami)

## Amazon EC2 Auto Scaling 그룹에 CodeDeploy 애플리케이션 배포
<a name="integrations-aws-auto-scaling-deploy"></a>

Amazon EC2 Auto Scaling 그룹에 CodeDeploy 애플리케이션 개정 버전을 배포하려면 다음을 수행하세요.

1. Amazon EC2 Auto Scaling 그룹이 Amazon S3와 연동할 수 있도록 허용하는 IAM 인스턴스 프로파일을 만들거나 찾습니다. 자세한 내용은 [4단계: Amazon EC2 인스턴스에 대한 IAM 인스턴스 프로파일 만들기](getting-started-create-iam-instance-profile.md) 단원을 참조하십시오.
**참고**  
CodeDeploy를 사용하여 GitHub 리포지토리에서 Amazon EC2 Auto Scaling 그룹으로 개정을 배포할 수도 있습니다. Amazon EC2 인스턴스는 IAM 인스턴스 프로파일을 계속 필요로 하지만, 이 프로파일에는 GitHub 리포지토리에서 배포하기 위한 추가 권한이 필요하지 않습니다.

1. 시작 구성이나 템플릿에서 IAM 인스턴스 프로파일을 지정하여 Amazon EC2 Auto Scaling 그룹을 생성하거나 사용합니다. 자세한 내용은 [Amazon EC2 인스턴스에서 실행되는 애플리케이션의 IAM 역할](https://docs.aws.amazon.com/autoscaling/ec2/userguide/us-iam-role.html)을 참조하세요.

1. CodeDeploy가 Amazon EC2 Auto Scaling 그룹이 포함된 배포 그룹을 생성하도록 허용하는 서비스 역할을 만들거나 찾습니다.

1. Amazon EC2 Auto Scaling 그룹 이름, 서비스 역할 및 기타 몇 가지 옵션을 지정하여 CodeDeploy로 배포 그룹을 생성합니다. 자세한 내용은 [인 플레이스(in-place) 배포에 사용할 수 있는 배포 그룹 만들기(콘솔)](deployment-groups-create-in-place.md) 또는 [인 플레이스(in-place) 배포에 사용할 수 있는 배포 그룹 만들기(콘솔)](deployment-groups-create-in-place.md)을 참조하세요.

1. CodeDeploy를 사용하여 Amazon EC2 Auto Scaling 그룹이 포함된 배포 그룹에 수정 버전을 배포합니다.

자세한 내용은 [튜토리얼: CodeDeploy를 사용하여 Auto Scaling 그룹에 애플리케이션 배포](tutorials-auto-scaling-group.md) 단원을 참조하십시오.

## Auto Scaling 확장 이벤트 중 종료 배포 활성화
<a name="integrations-aws-auto-scaling-behaviors-hook-enable"></a>

**종료 배포는 Auto Scaling [스케일 인](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-lifecycle.html#as-lifecycle-scale-in) 이벤트가 발생하면 자동으로 활성화되는 CodeDeploy 배포의 한 유형입니다. CodeDeploy는 Auto Scaling 서비스가 인스턴스를 종료하기 직전에 종료 배포를 수행합니다. 종료 배포 중에는 CodeDeploy는 아무것도 배포하지 않습니다. 대신 수명 주기 이벤트를 생성하며, 이를 자체 스크립트에 연결하여 사용자 지정 종료 기능을 활성화할 수 있습니다. 예를 들어, 인스턴스가 종료되기 전에 애플리케이션을 정상적으로 종료하는 스크립트에 `ApplicationStop` 수명 주기 이벤트를 연결할 수 있습니다.

종료 배포 중에 CodeDeploy가 생성하는 수명 주기 이벤트 목록은 수[수명 주기 이벤트 후크 가용성](reference-appspec-file-structure-hooks.md#reference-appspec-file-structure-hooks-availability)을 참조하세요.

종료 배포가 어떤 이유로든 실패하면 CodeDeploy는 인스턴스 종료를 계속 진행하도록 허용합니다. 즉, CodeDeploy가 수명 주기 이벤트의 전체 집합(또는 일부)을 완료까지 실행하지 않았더라도 인스턴스가 종료됩니다.

종료 배포를 활성화하지 않으면 Auto Scaling 서비스는 스케일인 이벤트가 발생할 때 Amazon EC2 인스턴스를 계속 종료하지만 CodeDeploy는 수명 주기 이벤트를 생성하지 않습니다.

**참고**  
종료 배포를 사용하도록 설정했는지 여부와 관계없이 자동 확장 서비스가 CodeDeploy 배포가 진행 중인 동안 Amazon EC2 인스턴스를 종료하면 자동 확장 및 CodeDeploy 서비스에서 생성된 수명 주기 이벤트 간에 경합 조건이 발생할 수 있습니다. 예를 들어, Auto Scaling 서비스에 의해 생성된 `Terminating` 수명 주기 이벤트가 CodeDeploy 배포에 의해 생성된 `ApplicationStart` 이벤트보다 우선할 수 있습니다. 이 시나리오에서는 Amazon EC2 인스턴스 종료 또는 CodeDeploy 배포에 실패가 발생할 수 있습니다.

**CodeDeploy가 종료 배포를 수행하도록 하려면 다음을 수행하세요.**
+ 배포 그룹을 생성하거나 업데이트할 때 **Auto Scaling 그룹에 종료 후크 추가** 확인란을 선택합니다. 자세한 내용은 [인 플레이스(in-place) 배포에 사용할 수 있는 배포 그룹 만들기(콘솔)](deployment-groups-create-in-place.md) 또는 [EC2/온프레미스 블루/그린 배포에 사용할 수 있는 배포 그룹 만들기(콘솔)](deployment-groups-create-blue-green.md)을 참조하세요.

  이 확인란을 활성화하면 CodeDeploy 배포 그룹을 만들거나 업데이트할 때 지정한 [Auto Scaling 그룹에 자동 확장 수명 주기 후크](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)가 설치됩니다. 이 후크를 *종료 후크*라고 하며 종료 배포를 활성화합니다.

**종료 후크가 설치되면 다음과 같이 스케일 인(종료) 이벤트가 전개됩니다.**

1. Auto Scaling 서비스(또는 간단히 자동 확장)는 스케일 인 이벤트가 발생해야 한다고 판단하고 EC2 인스턴스를 종료하기 위해 EC2 서비스에 연락합니다.

1. EC2 서비스가 EC2 인스턴스를 종료하기 시작합니다. 인스턴스는 `Terminating` 상태가 되고 그 다음엔 `Terminating:Wait` 상태가 됩니다.

1. `Terminating:Wait` 동안 Auto Scaling은 CodeDeploy에서 설치된 종료 후크를 포함한 Auto Scaling 그룹에 연결된 모든 수명 주기 후크를 실행합니다.

1. 종료 후크가 알림을 CodeDeploy에 의해 폴링된 [Amazon SQS 대기열](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)로 보냅니다.

1. 알림을 받으면 CodeDeploy는 메시지를 구문 분석하고 몇 가지 유효성 검사를 수행한 후 [종료 배포](#integrations-aws-auto-scaling-behaviors-hook-enable)를 수행합니다.

1. 종료 배포가 실행되는 동안 CodeDeploy 5분마다 하트비트를 Auto Scaling으로 전송하여 인스턴스가 여전히 작업 중임을 알립니다.

1. 지금까지 EC2 인스턴스는 여전히 `Terminating:Wait` 상태(또는 [Auto Scaling group 워밍 풀](https://docs.aws.amazon.com/autoscaling/ec2/userguide/warm-pool-instance-lifecycle.html)을 활성화한 경우 `Warmed:Pending:Wait` 상태일 수 있음)에 있습니다.

1. 배포가 완료되면 종료 배포의 성공 또는 실패 여부에 관계없이 Auto Scaling에 EC2 종료 프로세스를 계속 진행하도록 CodeDeploy가 표시합니다.

## Amazon EC2 Auto Scaling에서 CodeDeploy를 사용하는 방식
<a name="integrations-aws-auto-scaling-behaviors"></a>

Auto Scaling 그룹을 포함하도록 CodeDeploy 배포 그룹을 생성하거나 업데이트하면 CodeDeploy는 CodeDeploy 서비스 역할을 사용하여 Auto Scaling 그룹에 액세스한 다음 [Auto Scaling 수명 주기 후크](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)를 Auto Scaling 그룹에 설치합니다.

**참고**  
*Auto Scaling 수명 주기 후크*는 CodeDeploy에 의해 생성되고 이 안내서의 AppSpec '후크' 섹션에 설명된 수명 주기 이벤트(*수명 주기 이벤트 후크라고도 함*)와는 다릅니다.

CodeDeploy가 설치하는 Auto Scaling 수명 주기 훅은 다음과 같습니다.
+ **시작 후크** - 이 후크는 Auto Scaling [스케일 아웃 이벤트](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-lifecycle.html#as-lifecycle-scale-out)가 진행 중이며 CodeDeploy가 시작 배포를 시작해야 한다는 것을 CodeDeploy에 알립니다.

  *시작 배포* 중에 CodeDeploy는 다음을 수행합니다.
  + 애플리케이션의 개정 버전을 스케일 아웃 인스턴스에 배포합니다.
  + 배포 진행 상황을 나타내는 수명 주기 이벤트를 생성합니다. 이러한 수명 주기 이벤트를 자체 스크립트에 연결하여 사용자 지정 시작 기능을 활성화할 수 있습니다. 자세한 내용은 [수명 주기 이벤트 후크 가용성](reference-appspec-file-structure-hooks.md#reference-appspec-file-structure-hooks-availability) 표를 참조하세요.

  시작 후크 및 관련 시작 배포는 항상 활성화되어 있으며 끌 수 없습니다.
+ **종료 후크** - 이 선택적 후크는 Auto Scaling [스케일 인 이벤트](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-lifecycle.html#as-lifecycle-scale-in)가 진행 중이며 CodeDeploy가 종료 배포를 시작해야 함을 CodeDeploy에 알립니다.

  *종료 배포* 중에 CodeDeploy는 수명 주기 이벤트를 생성하여 인스턴스 종료의 진행 상황을 나타냅니다. 자세한 내용은 [Auto Scaling 확장 이벤트 중 종료 배포 활성화](#integrations-aws-auto-scaling-behaviors-hook-enable) 단원을 참조하십시오.

**Topics**
+ [CodeDeploy가 수명 주기 훅을 설치한 후에는 어떻게 사용되나요?](#integrations-aws-auto-scaling-behaviors-hook-usage)
+ [CodeDeploy가 Amazon EC2 Auto Scaling 그룹에 이름을 지정하는 방법](#integrations-aws-auto-scaling-behaviors-naming)
+ [사용자 지정 수명 주기 후크의 실행 순서](#integrations-aws-auto-scaling-behaviors-hook-order)
+ [배포 중 이벤트 확장](#integrations-aws-auto-scaling-behaviors-mixed-environment)
+ [배포 중에 스케일 인 이벤트](#integrations-aws-auto-scaling-behaviors-scale-in)
+ [AWS CloudFormation cfn-init 스크립트의 이벤트 순서](#integrations-aws-auto-scaling-behaviors-event-order)

### CodeDeploy가 수명 주기 훅을 설치한 후에는 어떻게 사용되나요?
<a name="integrations-aws-auto-scaling-behaviors-hook-usage"></a>

시작 및 종료 수명 주기 후크가 설치되면 Auto Scaling 그룹 스케일 아웃 및 스케일 인 이벤트 중에 각각 CodeDeploy에서 사용됩니다.

**스케일 아웃(시작) 이벤트는 다음과 같이 전개됩니다.**

1. Auto Scaling 서비스(또는 단순히 Auto Scaling)가 확장 이벤트가 발생해야 한다고 판단하면 EC2 서비스에 연결하여 새 EC2 인스턴스를 시작합니다.

1. EC2 서비스는 새 EC2 인스턴스를 시작합니다. 인스턴스는 `Pending` 상태가 되고 그 다음엔 `Pending:Wait` 상태가 됩니다.

1. `Pending:Wait` 동안 Auto Scaling은 Auto Scaling 그룹에 연결된 모든 수명 주기 후크를 실행하며, 여기에는 CodeDeploy에 의해 설치된 런치 후크가 포함됩니다.

1. 시작 후크는 CodeDeploy가 폴링하는 [Amazon SQS 대기열](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)에 알림을 보냅니다.

1. 알림을 받으면 CodeDeploy는 메시지를 구문 분석하고 몇 가지 유효성 검사를 수행한 후 [시작 배포](#launch-deployment)를 시작합니다.

1. 시작 배포가 실행되는 동안 CodeDeploy 5분마다 하트비트를 Auto Scaling으로 전송하여 인스턴스가 여전히 작업 중임을 알립니다.

1. 지금까지 EC2 인스턴스는 여전히 `Pending:Wait` 상태입니다.

1. 배포가 완료되면 CodeDeploy는 배포 성공 또는 실패 여부에 따라 Auto Scaling에 `CONTINUE` 또는 `ABANDON` EC2 시작 프로세스를 알립니다.
   + CodeDeploy가 `CONTINUE`를 알리면 Auto Scaling은 시작 프로세스를 이어가서 다른 후크가 완료될 때까지 기다리거나 인스턴스를 `Pending:Proceed` 상태로 설정한 다음 `InService` 상태로 설정합니다.
   + CodeDeploy가 `ABANDON`을 알리면 Auto Scaling은 EC2 인스턴스를 종료하고 Auto Scaling의 **원하는 용량(Desired Capacity)** 설정에 정의된 인스턴스 수를 충족하기 위해 필요한 경우 시작 절차를 다시 시작합니다.

**스케일 인(종료) 이벤트는 다음과 같이 전개됩니다.**

[Auto Scaling 확장 이벤트 중 종료 배포 활성화](#integrations-aws-auto-scaling-behaviors-hook-enable)을(를) 참조하세요.

### CodeDeploy가 Amazon EC2 Auto Scaling 그룹에 이름을 지정하는 방법
<a name="integrations-aws-auto-scaling-behaviors-naming"></a>

 

EC2/온프레미스 컴퓨팅 플랫폼을 기반으로 한 블루/그린 배포 과정에서는 인스턴스를 대체(그린) 환경에 추가하는 옵션이 두 가지입니다.
+  이미 존재하거나, 혹은 수동으로 생성한 인스턴스를 사용합니다.
+  지정한 Amazon EC2 Auto Scaling 그룹의 설정을 사용하여 새 Amazon EC2 Auto Scaling 그룹에서 인스턴스를 정의하고 생성합니다.

 두 번째 옵션을 선택하면 CodeDeploy는 새로운 Amazon EC2 Auto Scaling 그룹을 프로비저닝합니다. 그룹 이름을 지정할 때 사용하는 규칙은 다음과 같습니다.

```
CodeDeploy_deployment_group_name_deployment_id
```

예를 들어 ID가 `10`인 배포를 통해 `alpha-deployments`라는 이름의 배포 그룹을 배포하는 경우 프로비저닝되는 Amazon EC2 Auto Scaling 그룹은 `CodeDeploy_alpha-deployments_10`이라는 이름으로 지정됩니다. 자세한 내용은 [EC2/온프레미스 블루/그린 배포에 사용할 수 있는 배포 그룹 만들기(콘솔)](deployment-groups-create-blue-green.md) 및 [GreenFleetProvisioningOption](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_GreenFleetProvisioningOption.html) 단원을 참조하세요.

### 사용자 지정 수명 주기 후크의 실행 순서
<a name="integrations-aws-auto-scaling-behaviors-hook-order"></a>

CodeDeploy에서 배포하는 Amazon EC2 Auto Scaling 그룹에 고유한 수명 주기 후크를 추가할 수 있습니다. 그러나 사용자 지정 수명 주기 후크 이벤트가 실행되는 순서는 CodeDeploy 기본 배포 수명 주기 이벤트를 기준으로 미리 결정할 수 없습니다. 예를 들어 `ReadyForSoftwareInstall`이라는 사용자 지정 수명 주기 후크를 Amazon EC2 Auto Scaling 그룹에 추가하면 이 후크가 첫 번째 CodeDeploy 기본 배포 수명 주기 이벤트 이전에 실행될지 또는 마지막 이벤트 이후에 실행될지 사전에 알 수 없습니다.

사용자 지정 수명 주기 후크를 Amazon EC2 Auto Scaling 그룹에 추가하는 방법을 알아보려면 *Amazon EC2 Auto Scaling 사용 설명서*의 [수명 주기 후크 추가](https://docs.aws.amazon.com/autoscaling/latest/userguide/lifecycle-hooks.html#adding-lifecycle-hooks)를 참조하세요.

### 배포 중 이벤트 확장
<a name="integrations-aws-auto-scaling-behaviors-mixed-environment"></a>

배포가 진행되는 동안 Auto Scaling 스케일 아웃 이벤트가 발생하면 새 인스턴스는 최신 애플리케이션 개정 버전이 아닌 이전에 배포된 애플리케이션 개정 버전으로 업데이트됩니다. 배포에 성공하면 이전 인스턴스와 새로 확장된 인스턴스가 다른 애플리케이션 개정을 호스팅합니다. 이전 개정 버전의 인스턴스를 최신 상태로 유지하기 위해 CodeDeploy는 자동으로 후속 배포를 시작하여(첫 번째 배포 직후에) 오래된 인스턴스를 업데이트합니다. 오래된 EC2 인스턴스가 이전 버전으로 유지되도록 이 기본 동작을 변경하려면 [Automatic updates to outdated instances](deployment-groups-configure-advanced-options.md#auto-updates-outdated-instances) 섹션을 참조하세요.

배포가 진행되는 동안 Amazon EC2 Auto Scaling 확장 프로세스를 일시 중단하려면 CodeDeploy를 통해 로드 밸런싱에 사용되는 `common_functions.sh` 스크립트 설정을 통해 수행합니다. `HANDLE_PROCS=true`이면 배포 프로세스 중 다음 Auto Scaling 이벤트가 자동으로 일시 중단됩니다.
+ AZRebalance
+ AlarmNotification
+ ScheduledActions
+ ReplaceUnhealthy

**중요**  
CodeDeployDefault.OneAtATime 배포 구성만 이 기능을 지원합니다.

Amazon EC2 Auto Scaling을 사용할 때 `HANDLE_PROCS=true`를 사용하여 배포 문제를 방지하려면 GitHub에 있는 [aws-codedeploy-samples](https://github.com/awslabs/aws-codedeploy-samples)에서 [AutoScaling 프로세스 처리에 대한 중요 공지](https://github.com/awslabs/aws-codedeploy-samples/tree/master/load-balancing/elb#important-notice-about-handling-autoscaling-processes)를 참조하세요.

### 배포 중에 스케일 인 이벤트
<a name="integrations-aws-auto-scaling-behaviors-scale-in"></a>

해당 Auto Scaling 그룹에서 CodeDeploy 배포가 진행 중인 동안 Auto Scaling 그룹이 확장을 시작하면 종료 프로세스(CodeDeploy 종료 배포 수명 주기 이벤트 포함)와 종료 인스턴스의 다른 CodeDeploy 수명 주기 이벤트 간에 경합 조건이 발생할 수 있습니다. 모든 CodeDeploy 수명 주기 이벤트가 완료되기 전에 인스턴스가 종료되면 해당 특정 인스턴스에 대한 배포가 실패할 수 있습니다. 또한 배포 구성에서 **최소 정상 호스트** 설정을 어떻게 설정했는지에 따라 전체 CodeDeploy 배포가 실패할 수도 있고 실패하지 않을 수도 있습니다.

### AWS CloudFormation cfn-init 스크립트의 이벤트 순서
<a name="integrations-aws-auto-scaling-behaviors-event-order"></a>

새로 프로비저닝된 Linux 기반 인스턴스에서 `cfn-init`(또는 `cloud-init`)를 사용하여 스크립트를 실행하는 경우 인스턴스 시작 후 발생하는 이벤트 순서를 엄격하게 제어하지 않으면 배포에 실패할 수 있습니다.

순서는 다음과 같아야 합니다.

1. 새로 프로비저닝된 인스턴스가 시작합니다.

1. 모든 `cfn-init` 부트스트래핑 스크립트가 완료될 때까지 실행됩니다.

1. CodeDeploy 에이전트가 시작됩니다.

1. 최신 애플리케이션 개정이 인스턴스에 배포됩니다.

이벤트 순서를 신중하게 제어하지 않으면 모든 스크립트의 실행이 완료되기 전에 CodeDeploy 에이전트가 배포를 시작할 수 있습니다.

이벤트 순서를 제어하려면 다음 모범 사례 중 하나를 사용합니다.
+ `cfn-init` 스크립트를 통해 CodeDeploy 에이전트를 설치합니다. 이때 이 스크립트를 다른 모든 스크립트 뒤에 배치합니다.
+ 사용자 정의 AMI에 CodeDeploy 에이전트를 포함하고 `cfn-init` 스크립트를 사용해 시작합니다. 이때 이 스크립트를 다른 모든 스크립트 뒤에 배치합니다.

`cfn-init` 사용에 대한 자세한 내용은 *AWS CloudFormation 사용 설명서*의 [cfn-init](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-init.html)를 참조하세요.

## CodeDeploy 및 Amazon EC2 Auto Scaling에서 사용자 지정 AMI 사용
<a name="integrations-aws-auto-scaling-custom-ami"></a>

새 Amazon EC2 인스턴스를 Amazon EC2 Auto Scaling 그룹에서 시작하는 경우 사용할 기본 AMI를 지정하는 데 다음 두 가지 옵션이 있습니다.
+ CodeDeploy 에이전트가 이미 설치된 기본 사용자 지정 AMI를 지정할 수 있습니다. 에이전트가 이미 설치되어 있으므로 이 옵션은 다른 옵션보다 훨씬 빨리 새 Amazon EC2 인스턴스를 시작합니다. 그러나 이 옵션은 특히 CodeDeploy 에이전트가 오래된 경우 Amazon EC2 인스턴스의 초기 배포에 실패할 가능성이 더 큽니다. 이 옵션을 선택하면 기본 사용자 지정 AMI에서 CodeDeploy 에이전트를 정기적으로 업데이트하는 것이 좋습니다.
+ CodeDeploy 에이전트가 설치되지 않은 기본 AMI를 지정하고 각각의 새 인스턴스가 Amazon EC2 Auto Scaling 그룹에서 시작될 때 이 에이전트가 설치되도록 할 수 있습니다. 이 옵션은 다른 옵션보다 새 Amazon EC2 인스턴스의 시작 속도가 훨씬 느리긴 하지만 초기 인스턴스 배포에 성공할 가능성이 더 큽니다. 이 옵션은 최신 버전의 CodeDeploy 에이전트를 사용합니다.

# CodeDeploy와 Elastic Load Balancing 통합
<a name="integrations-aws-elastic-load-balancing"></a>

CodeDeploy 배포 시, 로드 밸런서는 준비되지 않았거나, 현재 배포 중이거나, 더 이상 환경의 일부로 필요하지 않은 인스턴스로 인터넷 트래픽이 라우팅되지 않도록 합니다. 그러나 로드 밸런서의 정확한 역할은 블루/그린 배포에 사용되는지 아니면 인 플레이스(in-place) 배포에 사용되는지에 따라 다릅니다.

**참고**  
블루/그린(Blue/Green) 배포에서는 Elastic Load Balancing 로드 밸런서를 반드시 사용해야 하고, 인 플레이스(In-place) 배포에서는 선택 사항입니다.

## Elastic Load Balancing 유형
<a name="integrations-aws-elastic-load-balancing-types"></a>

Elastic Load Balancing은 CodeDeploy 배포에서 사용할 수 있는 Classic Load Balancer, Application Load Balancer, Network Load Balancer의 세 가지 로드 밸런서 유형을 제공합니다.

Classic Load Balancer  
전송 계층(TCP/SSL) 또는 애플리케이션 계층(HTTP/HTTPS)에서 라우팅 및 로드 밸런싱합니다. VPC를 지원합니다.  
Classic Load Balancer는 Amazon ECS 배포에서 지원되지 않습니다.

Application Load Balancer  
애플리케이션 계층(HTTP/HTTPS)에서 라우팅 및 로드 밸런싱하며 경로 기반 라우팅을 지원합니다. Virtual Private Cloud(VPC)에서 각 EC2 인스턴스 또는 컨테이너 인스턴스에서 포트로 요청을 라우팅할 수 있습니다.  
 Application Load Balancer 대상 그룹의 대상 유형은 EC2 인스턴스에서 배포 시 `instance`이고, Fargate에서 배포 시 `IP`여야 합니다. 자세한 내용은 [대상 유형](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#target-type)을 참조하세요.

Network Load Balancer  
패킷 콘텐츠가 아닌 TCP 패킷 헤더에서 추출된 주소 정보를 기반으로 한 전송 계층(TCP/UDP Layer-4)에서 라우팅 및 로드 밸런싱합니다. Network Load Balancer는 트래픽 급증을 처리하고, 클라이언트의 소스 IP를 유지하며, 로드 밸런서의 수명 동안 고정 IP를 사용할 수 있도록 합니다.

Elastic Load Balancing 로드 밸런서에 대해 자세히 알아보려면 다음 주제를 참조하세요.
+ [Elastic Load Balancing이란 무엇인가요?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ [Classic Load Balancer란 무엇인가요?](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/introduction.html)
+ [Application Load Balancer란 무엇인가요?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ [Network Load Balancer란 무엇인가요?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)

## 블루/그린 배포
<a name="integrations-aws-elastic-load-balancing-blue-green"></a>

Elastic Load Balancing 로드 밸런서 뒤에서 인스턴스 트래픽을 다시 라우팅하는 것은 CodeDeploy 블루/그린 배포의 기본 사항입니다.

블루/그린 배포 중 로드 밸런서는 사용자가 지정한 규칙에 따라 최신 애플리케이션 개정이 배포된 배포 그룹(대체 환경)에서 새 인스턴스로 트래픽이 라우팅되도록 한 다음 이전 애플리케이션 개정이 실행 중인 이전 인스턴스(원본 환경)에서의 트래픽은 차단합니다.

대체 환경의 인스턴스가 하나 이상의 로드 밸런서에 등록되면 원래 환경의 인스턴스는 등록 취소되고 선택한 경우 종료됩니다.

블루/그린 배포의 경우 배포 그룹에서 하나 이상의 Classic Load Balancer, Application Load Balancer 대상 그룹 또는 Network Load Balancer 대상 그룹을 지정할 수 있습니다. CodeDeploy 콘솔 또는를 사용하여 배포 그룹에 로드 밸런서를 AWS CLI 추가합니다.

블루/그린 배포에서 로드 밸런서에 대한 자세한 내용은 다음 항목을 참조하세요.
+ [Elastic Load Balancing에서 CodeDeploy Amazon EC2 배포에 대한 로드 밸런서 설정](deployment-groups-create-load-balancer.md)
+ [Blue/Green 배포를 위한 애플리케이션 생성(콘솔)](applications-create-blue-green.md)
+ [EC2/온프레미스 블루/그린 배포에 사용할 수 있는 배포 그룹 만들기(콘솔)](deployment-groups-create-blue-green.md)

## 인 플레이스(in-place) 배포
<a name="integrations-aws-elastic-load-balancing-in-place"></a>

인 플레이스(in-place) 배포 시 로드 밸런서는 배포 대상 인스턴스로 인터넷 트래픽이 라우팅되지 않도록 하고 해당 인스턴스에 대한 배포가 완료되면 인스턴스가 다시 트래픽을 처리할 수 있도록 합니다.

인 플레이스(in-place) 배포에서 로드 밸런서를 사용하지 않으면, 배포 프로세스 중 인터넷 트래픽이 인스턴스로 계속 보내질 수 있습니다. 그로 인해 고객에게 웹 애플리케이션이 끊기거나, 완료되지 않거나, 이전 상태로 표시되는 문제가 생길 수 있습니다. 인플레이스 배포에서 Elastic Load Balancing 로드 밸런서를 사용할 경우, 배포 그룹의 인스턴스가 로드 밸런서에서 등록 취소되고 최신 애플리케이션 버전으로 업데이트된 다음 배포가 성공하고 나면 동일한 배포 그룹의 일부로 로드 밸런서에 다시 등록됩니다. CodeDeploy는 인스턴스가 로드 밸런서 뒤에서 정상 상태가 될 때까지 최대 1시간을 기다립니다. 인스턴스가 대기 기간 동안 로드 밸런서에 의해 정상 상태로 표시되지 않으면 CodeDeploy는 배포 구성에 따라 다음 인스턴스로 이동하거나 배포에 실패합니다.

인플레이스 배포의 경우 하나 이상의 Classic Load Balancer, Application Load Balancer 대상 그룹 또는 Network Load Balancer 대상 그룹을 지정할 수 있습니다. 로드 밸런서를 배포 그룹 구성의 일부로 지정하거나, CodeDeploy에서 제공하는 스크립트를 사용하여 로드 밸런서를 구현할 수 있습니다.

### 배포 그룹을 사용한 인 플레이스(In-place) 배포 로드 밸런서 지정
<a name="integrations-aws-elastic-load-balancing-in-place-deployment-group"></a>

배포 그룹에 로드 밸런서를 추가하려면 CodeDeploy 콘솔 또는를 사용합니다 AWS CLI. 인 플레이스(in-place) 배포를 위해 배포 그룹에 로드 밸런서를 지정하는 자세한 내용은 다음 항목을 참조하세요.
+ [현재 위치(in-place) 배포를 위한 애플리케이션 생성(콘솔)](applications-create-in-place.md)
+ [인 플레이스(in-place) 배포에 사용할 수 있는 배포 그룹 만들기(콘솔)](deployment-groups-create-in-place.md)
+ [Elastic Load Balancing에서 CodeDeploy Amazon EC2 배포에 대한 로드 밸런서 설정](deployment-groups-create-load-balancer.md)

### 스크립트를 사용한 인 플레이스(In-place) 배포 로드 밸런서 지정
<a name="integrations-aws-elastic-load-balancing-in-place-script"></a>

배포 수명 주기 스크립트를 사용하여 인 플레이스(in-place) 배포를 위한 로드 밸런싱을 설정하려면 다음 절차의 단계를 수행합니다.
**참고**  
인 플레이스 배포에 대한 로드 밸런서를 설정하는 스크립트를 사용 중일 때에만 CodeDeployDefault.OneAtATime 배포 구성을 사용해야 합니다. 동시 실행은 지원되지 않으며, CodeDeployDefault.OneAtATime 설정은 스크립트의 직렬 실행을 보장합니다. 배포 구성에 대한 자세한 내용은 [CodeDeploy에서 배포 구성 작업](deployment-configurations.md) 단원을 참조하세요.

GitHub의 CodeDeploy 샘플 리포지토리에 CodeDeploy Elastic Load Balancing 로드 밸런서를 사용할 때 적용할 수 있는 지침과 샘플이 있습니다. 이 리포지토리에는 진행에 필요한 모든 코드를 제공하는 3가지 샘플 스크립트(`register_with_elb.sh`, `deregister_from_elb.sh`, `common_functions.sh`)가 포함되어 있습니다. 이러한 3개 스크립트에서 자리 표시자를 편집한 후 `appspec.yml` 파일에서 해당 스크립트를 참조하면 됩니다.

CodeDeploy에서 Elastic Load Balancing 로드 밸런서에 등록된 Amazon EC2 인스턴스에 대해 인 플레이스(In-place) 배포를 설정하려면 다음을 수행하세요.

1. 인 플레이스(in-place) 배포에 사용할 로드 밸런서 유형의 샘플을 다운로드합니다.
   + [Classic Load Balancer](https://github.com/awslabs/aws-codedeploy-samples/tree/master/load-balancing/elb)
   + [Application Load Balancer[ 또는 Network Load Balancer](https://github.com/awslabs/aws-codedeploy-samples/tree/master/load-balancing/elb-v2)(두 유형에 동일한 스크립트를 사용할 수 있음)](https://github.com/awslabs/aws-codedeploy-samples/tree/master/load-balancing/elb-v2)

1. 각 대상 Amazon EC2 인스턴스에가 AWS CLI 설치되어 있는지 확인합니다.

1. 대상 Amazon EC2 인스턴스 각각에 최소한 elasticloadbalancing:\$1 및 autoscaling:\$1 권한을 가진 IAM 인스턴스 프로파일이 연결되어 있는지 확인합니다.

1. 애플리케이션의 소스 코드 디렉터리에 배포 수명 주기 이벤트 스크립트 (`register_with_elb.sh`, `deregister_from_elb.sh`, `common_functions.sh`)를 포함합니다.

1. 애플리케이션 수정 버전의 `appspec.yml`에서 **ApplicationStart** 이벤트 중에 `register_with_elb.sh` 스크립트, **ApplicationStop** 이벤트 중에 `deregister_from_elb.sh` 스크립트를 실행할 수 있도록 CodeDeploy에 대한 지침을 제공합니다.

1. 인스턴스가 Amazon EC2 Auto Scaling 그룹에 포함된 경우 이 단계를 건너뛸 수 있습니다.

   `common_functions.sh` 스크립트:
   + [Classic Load Balancer](https://github.com/awslabs/aws-codedeploy-samples/tree/master/load-balancing/elb)를 사용하는 경우, `ELB_LIST=""`에 Elastic Load Balancing 로드 밸런서의 이름을 지정하고 파일에서 다른 배포 설정에 필요한 사항을 수정합니다.
   + [Application Load Balancer[ 또는 Network Load Balancer](https://github.com/awslabs/aws-codedeploy-samples/tree/master/load-balancing/elb-v2)](https://github.com/awslabs/aws-codedeploy-samples/tree/master/load-balancing/elb-v2)를 사용하는 경우, `TARGET_GROUP_LIST=""`에 Elastic Load Balancing 대상 그룹의 이름을 지정하고 파일에서 다른 배포 설정에 필요한 사항을 수정합니다.

1. 애플리케이션의 소스 코드, `appspec.yml`, 배포 수명 주기 이벤트 스크립트를 하나의 애플리케이션 개정으로 번들링한 후 이 개정을 업로드합니다. 개정을 Amazon EC2 인스턴스로 배포합니다. 배포 진행 중에 배포 수명 주기 이벤트 스크립트는 로드 밸런서에서 Amazon EC2 인스턴스 등록을 취소하고 연결이 해제될 때까지 기다린 후, 배포가 완료되면 로드 밸런서에 Amazon EC2 인스턴스를 다시 등록합니다.

# 파트너 제품 및 서비스와의 통합
<a name="integrations-partners"></a>

CodeDeploy는 다음 파트너 제품 및 서비스와 기본적으로 통합되어 있습니다.


|  |  | 
| --- |--- |
| Ansible |  [Ansible](http://www.ansible.com) 플레이북 세트가 이미 있는데 어딘가에서 실행해야 하는 경우, Ansible 및 CodeDeploy용 템플릿은 단순한 배포 후크 2개가 로컬 배포 인스턴스에서 Ansible의 사용 및 플레이북 실행을 보장할 수 있는 방법을 보여줍니다. 인벤토리 구축 및 유지 관리를 위한 프로세스가 이미 마련되어 있으면 CodeDeploy 에이전트를 설치 및 실행하는 데 사용할 수 있는 Ansible 모듈도 있습니다. 자세히 알아보기: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/integrations-partners.html)  | 
| Atlassian – Bamboo 및 Bitbucket |  [Bamboo](https://www.atlassian.com/software/bamboo/)에 대한 CodeDeploy 작업은 AppSpec 파일이 포함된 디렉터리를 .zip 파일로 압축하고 파일을 Amazon S3에 업로드한 다음 CodeDeploy 애플리케이션에서 제공하는 구성에 따라 배포를 시작합니다. CodeDeploy에 대한 Atlassian Bitbucket 지원은 요청 시 Amazon EC2 인스턴스에 대한 코드를 Bitbucket UI에서 배포 그룹으로 직접 푸시할 수 있도록 합니다. 즉, Bitbucket 리포지토리에서 코드를 업데이트한 후에는 배포 프로세스를 수동으로 실행하기 위해 지속적 통합(CI) 플랫폼 또는 Amazon EC2 인스턴스에 로그인할 필요가 없습니다. 자세히 알아보기: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/integrations-partners.html)  | 
| Chef |  AWS 는 [Chef](https://www.chef.io/)와 CodeDeploy를 통합하기 위한 두 가지 템플릿 샘플을 제공합니다. 첫 번째 샘플 템플릿은 CodeDeploy 에이전트를 설치 및 시작하는 Chef 쿡북입니다. 이 템플릿은 CodeDeploy를 사용하는 동안에도 계속해서 호스트 인프라를 관리할 수 있도록 합니다. 두 번째 샘플 템플릿은 CodeDeploy를 사용하여 각 노드에서 chef-solo로 쿡북 및 레시피 실행을 오케스트레이션하는 방법을 보여줍니다. 자세히 알아보기: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/integrations-partners.html)  | 
| CircleCI |  [CircleCI](https://circleci.com/)는 자동화된 테스트, 지속적 통합 및 배포 도구 세트를 제공합니다. 에서 CircleCI와 함께 AWS 사용할 IAM 역할을 생성하고 circle.yml 파일에서 배포 파라미터를 구성한 후, CircleCI를 CodeDeploy와 함께 사용하여 애플리케이션 개정을 생성하고 Amazon S3 버킷에 업로드한 다음 배포를 시작하고 모니터링할 수 있습니다. 자세히 알아보기: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/integrations-partners.html)  | 
| CloudBees |  [CloudBees](https://www.cloudbees.com/) DEV@cloud에서 이용할 수 있는 CodeDeploy Jenkins 플러그인을 구축 후 작업으로 사용할 수 있습니다. 예를 들어, 지속적인 배포 파이프라인 종료 시 이 플러그인을 사용하여 서버 집합에 애플리케이션 개정을 배포할 수 있습니다. 자세히 알아보기: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/integrations-partners.html)  | 
| Codeship |  [Codeship](https://codeship.com/)을 사용하여 CodeDeploy를 통해 애플리케이션 수정 버전을 배포할 수 있습니다. Codeship UI를 사용하여 브랜치의 배포 파이프라인에 CodeDeploy를 추가할 수 있습니다. 자세히 알아보기:  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/integrations-partners.html)  | 
| GitHub |  CodeDeploy를 사용하여 [GitHub](http://www.github.com) 리포지토리에서 애플리케이션 수정 버전을 배포할 수 있습니다. 또한 GitHub 리포지토리의 소스 코드가 변경될 때마다 해당 리포지토리에서 배포를 트리거할 수도 있습니다. 자세히 알아보기: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/integrations-partners.html)  | 
|  **HashiCorp Consul**  |  CodeDeploy에서 애플리케이션을 배포하는 경우 오픈 소스 HashiCorp Consul 도구를 사용하여 애플리케이션 환경의 상태 및 안정성을 보장할 수 있습니다. Consul을 사용하여 배포 중 검색할 수 있도록 애플리케이션을 등록하고, 배포에서 제외하기 위해 애플리케이션 및 노드를 유지 관리 모드로 전환하고, 대상 인스턴스가 비정상 상태가 되면 배포를 중지할 수 있습니다. 자세히 알아보기: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/integrations-partners.html)  | 
| Jenkins |  CodeDeploy [Jenkins](http://jenkins-ci.org/) 플러그 인은 Jenkins 프로젝트에 구축 후 단계를 제공합니다. 구축에 성공하면 작업 영역을 압축해 Amazon S3로 업로드하고 새 배포를 시작합니다. 자세히 알아보기:  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/integrations-partners.html)  | 
| Puppet Labs |  AWS 는 [Puppet](https://puppetlabs.com/) 및 CodeDeploy용 샘플 템플릿을 제공합니다. 첫 번째 샘플 템플릿은 CodeDeploy 에이전트를 설치 및 시작하는 Puppet 모듈입니다. 이 템플릿은 CodeDeploy를 사용하는 동안에도 Puppet으로 계속해서 호스트 인프라를 관리할 수 있도록 합니다. 두 번째 샘플 템플릿은 CodeDeploy를 사용하여 각 노드에서 마스터 없는 puppet으로 모듈 및 매니페스트 실행을 오케스트레이션하는 방법을 보여줍니다. 자세히 알아보기:  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/integrations-partners.html)  | 
| SaltStack |  [SaltStack](https://saltproject.io/index.html) 인프라를 CodeDeploy와 통합할 수 있습니다. CodeDeploy 모듈을 사용해 미니언에 CodeDeploy 에이전트를 설치 및 실행하거나 단순한 배포 후크 2개와 함께 CodeDeploy를 사용해 Salt States 실행을 오케스트레이션할 수 있습니다. 자세히 알아보기:  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/integrations-partners.html)  | 
|  **TeamCity**  |  CodeDeploy Runner 플러그 인을 사용하여 TeamCity에서 직접 애플리케이션을 배포할 수 있습니다. 이 플러그 인은 애플리케이션 개정을 준비해 Amazon S3 버킷으로 업로드하는 TeamCity 구축 단계를 추가하고 해당 개정을 CodeDeploy 애플리케이션에 등록하며, CodeDeploy 배포를 만들고 선택한 경우 배포가 완료될 때까지 대기합니다. 자세히 알아보기: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/integrations-partners.html)  | 
| Travis CI |  성공적인 구축 후 CodeDeploy에서 배포를 트리거하도록 [Travis CI](https://travis-ci.com/)를 구성할 수 있습니다. 자세히 알아보기:  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/integrations-partners.html)  | 

**Topics**
+ [GitHub](integrations-partners-github.md)

# GitHub와 CodeDeploy 통합
<a name="integrations-partners-github"></a>

CodeDeploy는 웹 기반 호스팅 및 공유 서비스인 [GitHub](https://github.com/about)를 지원합니다. CodeDeploy는 GitHub 리포지토리 또는 Amazon S3 버킷에 저장된 애플리케이션 수정 버전을 인스턴스에 배포할 수 있습니다. CodeDeploy는 EC2 및 온프레미스 배포에 대해서만 GitHub를 지원합니다.

**Topics**
+ [GitHub에서 CodeDeploy 수정 버전 배포](#github-deployment-steps)
+ [CodeDeploy를 사용한 GitHub 동작](#github-behaviors)

## GitHub에서 CodeDeploy 수정 버전 배포
<a name="github-deployment-steps"></a>

GitHub 리포지토리에서 인스턴스로 애플리케이션 개정을 배포하려면:

1. 배포할 Amazon EC2 인스턴스 유형 및 CodeDeploy와 호환되는 개정을 만듭니다.

   호환되는 계정을 만들려면 [CodeDeploy의 개정 계획](application-revisions-plan.md) 및 [CodeDeploy에 대한 개정에 애플리케이션 사양 파일 추가](application-revisions-appspec-file.md)의 지침을 따르십시오.

1. GitHub 계정을 사용하여 GitHub 리포지토리에 개정을 추가합니다.

   GitHub 계정을 만들려면 [GitHub 조인](https://github.com/join)을 참조하세요. GitHub 리포지토리를 만들려면 [리포지토리 생성](https://help.github.com/articles/create-a-repo/)을 참조하세요.

1. CodeDeploy 콘솔의 **배포 생성** 페이지 또는 명령을 사용하여 GitHub AWS CLI **create-deployment**리포지토리에서 CodeDeploy 배포에 사용하도록 구성된 대상 인스턴스로 개정을 배포합니다.

   **create-deployment** 명령을 호출하려면 먼저 콘솔의 **배포 생성(Create deployment)** 페이지를 사용하여 지정된 애플리케이션에 대해 해당 GitHub 계정을 대신하여 GitHub와 상호 작용할 권한을 CodeDeploy에 부여해야 합니다. 애플리케이션당 한번만 이 작업을 수행하면 됩니다.

   [**Create deployment**] 페이지를 사용하여 GitHub 리포지토리에서 배포하는 방법에 대한 자세한 내용은 [CodeDeploy에서 배포 만들기](deployments-create.md)을 참조하세요.

   **create-deployment** 명령을 호출하여 GitHub 리포지토리에서 배포하는 방법은 [EC2/온프레미스 컴퓨팅 플랫폼의 배포 생성(CLI)](deployments-create-cli.md) 단원을 참조하세요.

   CodeDeploy 배포용으로 인스턴스를 준비하는 방법은 [CodeDeploy용 인스턴스 작업](instances.md) 섹션을 참조하세요.

자세한 내용은 [튜토리얼: CodeDeploy를 사용하여 GitHub에서 애플리케이션 배포](tutorials-github.md) 단원을 참조하십시오.

## CodeDeploy를 사용한 GitHub 동작
<a name="github-behaviors"></a>

**Topics**
+ [CodeDeploy에서 애플리케이션으로 GitHub 인증](#behaviors-authentication)
+ [프라이빗 및 퍼블릭 GitHub 리포지토리와 CodeDeploy 통합](#behaviors-interactions-private-and-public)
+ [조직에서 관리하는 GitHub 리포지토리와 CodeDeploy 통합](#behaviors-interactions-organization-managed)
+ [CodeDeploy를 사용하여 CodePipeline에서 자동으로 배포](#behaviors-deploy-automatically)

### CodeDeploy에서 애플리케이션으로 GitHub 인증
<a name="behaviors-authentication"></a>

GitHub와의 상호 작용 권한을 CodeDeploy에 부여한 후 GitHub 계정과 애플리케이션 간의 연결은 CodeDeploy에 저장됩니다. 애플리케이션을 다른 GitHub 계정에 연결할 수 있습니다. 또한 CodeDeploy가 GitHub와 상호 작용할 수 있는 권한을 취소할 수도 있습니다.

**CodeDeploy에서 GitHub 계정을 애플리케이션에 연결하려면**

1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/codedeploy](https://console.aws.amazon.com/codedeploy) CodeDeploy 콘솔을 엽니다.
**참고**  
[CodeDeploy 시작하기](getting-started-codedeploy.md)에서 설정한 사용자와 동일한 사용자로 로그인합니다.

1. 탐색 창에서 **배포(Deploy)**를 확장하고 **애플리케이션(Applications)**을 선택합니다.

1. 다른 GitHub 계정에 연결할 애플리케이션을 선택합니다.

1. 애플리케이션에 배포 그룹이 없는 경우, **배포 그룹 생성(Create deployment group)**을 선택하여 하나를 생성합니다. 자세한 내용은 [CodeDeploy에서 배포 그룹 만들기](deployment-groups-create.md) 단원을 참조하십시오. 다음 단계에서 **배포 만들기**를 선택하려면 배포 그룹이 필요합니다.

1.  **배포**에서 **배포 만들기**를 선택합니다.
**참고**  
새 배포를 만들 필요는 없습니다. 현재로서는 이 방법이 다른 GitHub 계정을 애플리케이션에 연결하는 유일한 방법입니다.

1.  **배포 설정**의 **개정 유형**에서 **애플리케이션을 GitHub에 저장**을 선택합니다.

1. 다음 중 하나를 수행하세요.
   +  AWS CodeDeploy 애플리케이션을 GitHub 계정에 연결하려면 별도의 웹 브라우저 탭에서 GitHub에서 로그아웃합니다. **GitHub 토큰 이름**에 이 연결을 식별하는 이름을 입력한 후 **GitHub에 연결**을 선택합니다. 웹 페이지에 애플리케이션에 대해 GitHub와 상호 작용할 권한을 CodeDeploy에 부여하라는 메시지가 표시됩니다. 계속해서 10단계를 진행합니다.
   + 이미 만든 연결을 사용하려면 **GitHub 토큰 이름**에서 이름을 선택한 후 **GitHub에 연결**을 선택합니다. 계속해서 8단계를 진행합니다.
   + 다른 GitHub 계정에 대한 연결을 만들려면 별도의 웹 브라우저 탭에서 GitHub에서 로그아웃합니다. **GitHub 토큰 이름**에 연결을 식별하는 이름을 입력한 후 **GitHub에 연결**을 선택합니다. 웹 페이지에 애플리케이션에 대해 GitHub와 상호 작용할 권한을 CodeDeploy에 부여하라는 메시지가 표시됩니다. 계속해서 10단계를 진행합니다.

1. GitHub에 아직 로그인하기 전이라면 [**Sign in**] 페이지의 지침을 따라 애플리케이션을 연결하려는 GitHub 계정에 로그인합니다.

1. [**Authorize application**]을 선택합니다. GitHub는 선택한 애플리케이션에 대해 로그인한 GitHub 계정을 대신하여 GitHub와 상호 작용할 수 있는 권한을 CodeDeploy에 부여합니다.

1. 배포를 만들지 않으려면 [**Cancel**]를 선택합니다.

**CodeDeploy가 GitHub와 상호 작용할 수 있는 권한을 취소하려면**

1.  AWS CodeDeploy 권한을 취소하려는 GitHub 계정의 자격 증명을 사용하여 [GitHub](https://github.com/dashboard)에 로그인합니다.

1. GitHub [애플리케이션](https://github.com/settings/applications) 페이지를 열어 권한이 있는 애플리케이션 목록에서 **CodeDeploy**를 찾은 다음 GitHub 절차에 따라 애플리케이션의 권한 부여를 취소합니다.

### 프라이빗 및 퍼블릭 GitHub 리포지토리와 CodeDeploy 통합
<a name="behaviors-interactions-private-and-public"></a>

CodeDeploy는 프라이빗 및 퍼블릭 GitHub 리포지토리에서 애플리케이션 배포를 지원합니다. 사용자 대신 GitHub에 액세스할 수 있도록 CodeDeploy에 권한을 부여하면 CodeDeploy에는 사용자의 GitHub 계정에서 액세스할 수 있는 모든 프라이빗 GitHub 리포지토리에 대한 읽기/쓰기 액세스 권한이 생깁니다. 그러나 CodeDeploy에서는 GitHub 리포지토리 읽기만 할 수 있습니다. 사용자의 프라이빗 GitHub 리포지토리에는 쓸 수 없습니다.

### 조직에서 관리하는 GitHub 리포지토리와 CodeDeploy 통합
<a name="behaviors-interactions-organization-managed"></a>

기본적으로, 사용자 계정의 프라이빗 또는 퍼블릭 리포지토리와 달리 조직에서 관리하는 GitHub 리포지토리는 CodeDeploy를 비롯하여 서드 파티 애플리케이션에 대한 액세스 권한을 부여하지 않습니다. 조직의 타사 애플리케이션 제약 조건이 GitHub에서 활성화되어 있는데 GitHub 리포지토리에서 코드를 배포하려고 하면 배포에 실패합니다. 이 문제는 두 가지 방법으로 해결할 수 있습니다.
+ 조직의 멤버는 조직 소유자에게 CodeDeploy에 대한 액세스를 승인하도록 요청할 수 있습니다. 이러한 액세스 요청 단계는 개별 계정에 대한 CodeDeploy의 액세스 권한이 이미 부여되었는지 여부에 따라 달라집니다.
  + 계정에서 CodeDeploy에 대한 액세스를 승인한 경우 [승인된 애플리케이션에 대한 조직 승인 요청](https://help.github.com/articles/requesting-organization-approval-for-your-authorized-applications/)을 참조하세요.
  + 계정에서 CodeDeploy에 대한 액세스를 아직 승인하지 않은 경우 [서드 파티 애플리케이션에 대한 조직 승인 요청](https://help.github.com/articles/requesting-organization-approval-for-third-party-applications/)을 참조하세요.
+ 조직 소유자는 조직에 대한 모든 타사 애플리케이션 제한을 비활성화할 수 있습니다. 자세한 내용은 [조직에 대한 서드 파티 애플리케이션 제한 비활성화](https://help.github.com/articles/disabling-third-party-application-restrictions-for-your-organization/)를 참조하세요.

자세한 내용은 [서드 파티 애플리케이션 제한 정보](https://help.github.com/articles/about-third-party-application-restrictions/)를 참조하세요.

### CodeDeploy를 사용하여 CodePipeline에서 자동으로 배포
<a name="behaviors-deploy-automatically"></a>

소스 코드가 변경될 때마다 CodePipeline에서 배포를 트리거할 수 있습니다. 자세한 내용은 [CodePipeline](https://aws.amazon.com/codepipeline/)을 참조하세요.

# 커뮤니티의 통합 예제
<a name="integrations-community"></a>

다음 단원에서는 블로그 포스트, 자료 및 커뮤니티에서 제공하는 예제를 제공합니다.

**참고**  
링크는 정보 제공 목적으로만 제공되며 포괄적인 목록이나 예제 내용의 보증으로 간주해서는 안됩니다. AWS 는 내용이나 외부 콘텐츠의 정확성에 대해서 책임을 지지 않습니다.

## 블로그 게시물
<a name="integrations-community-blogposts"></a>
+ [에서 CodeDeploy 프로비저닝 자동화 CloudFormation](http://www.stelligent.com/cloud/automating-aws-codedeploy-provisioning-in-cloudformation/)

   CloudFormation을(를) 사용하여 CodeDeploy에서 애플리케이션 배포를 프로비저닝하는 방법을 알아봅니다.

  *2016년 1월 게시*
+ [AWS Toolkit for Eclipse CodeDeploy와 통합(1부)](https://aws.amazon.com/blogs/developer/aws-toolkit-for-eclipse-integration-with-aws-codedeploy-part-1/)

  [AWS Toolkit for Eclipse CodeDeploy와 통합(2부)](https://aws.amazon.com/blogs/developer/aws-toolkit-for-eclipse-integration-with-aws-codedeploy-part-2/)

  [AWS Toolkit for Eclipse CodeDeploy와 통합(3부)](https://aws.amazon.com/blogs/developer/aws-toolkit-for-eclipse-integration-with-aws-codedeploy-part-3/)

  Java 개발자가 Eclipse용 CodeDeploy 플러그인을 사용하여 Eclipse 개발 환경에서 AWS 직접에 웹 애플리케이션을 배포하는 방법을 알아봅니다.

  *2015년 2월 게시*
+ [CodeDeploy를 사용하여 GitHub에서 자동 배포](https://aws.amazon.com/blogs/devops/automatically-deploy-from-github-using-aws-codedeploy/)

  GitHub에서 CodeDeploy로의 자동 배포를 사용하여 소스 제어에서 테스트 또는 프로덕션 환경으로 엔드 투 엔드 파이프라인을 만드는 방법을 알아봅니다.

  *2014년 12월 게시*