기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# CodeDeploy 문제 해결
이 단원의 주제는 CodeDeploy 사용 시 발생할 수 있는 문제 및 오류를 해결하는 데 유용하게 활용할 수 있습니다.
**참고**
배포 프로세스 중 생성되는 로그 파일을 검토하면 다양한 배포 실패의 원인을 파악할 수 있습니다. 간소화를 위해 인스턴스별로 로그 파일을 보는 대신 Amazon CloudWatch Logs를 사용하여 중앙에서 로그 파일을 모니터링하는 것이 좋습니다. 자세한 내용은 [Amazon CloudWatch 도구를 사용하여 배포 모니터링](monitoring-cloudwatch.md) 단원을 참조하세요.
**Topics**
+ [이 시나리오에서는 플릿에 상태에서 정상 인스턴스가 표시되지만 위의 오류도 표시됩니다.](troubleshooting-general.md)
+ [EC2/온프레미스 배포 문제 해결](troubleshooting-deployments.md)
+ [Amazon ECS 배포 문제 해결](troubleshooting-ecs.md)
+ [AWS Lambda 배포 문제 해결](troubleshooting-deployments-lambda.md)
+ [배포 그룹 관련 문제 해결](troubleshooting-deployment-groups.md)
+ [인스턴스 문제 해결](troubleshooting-ec2-instances.md)
+ [GitHub 토큰 문제 해결](troubleshooting-github-token-issues.md)
+ [Amazon EC2 Auto Scaling 문제 해결](troubleshooting-auto-scaling.md)
+ [AWS CodeDeploy의 오류 코드](error-codes.md)
# 이 시나리오에서는 플릿에 상태에서 정상 인스턴스가 표시되지만 위의 오류도 표시됩니다.
**Topics**
+ [일반적인 문제 해결 체크리스트](#troubleshooting-checklist)
+ [CodeDeploy 배포 리소스는 일부 AWS 리전에서만 지원됩니다.](#troubleshooting-supported-regions)
+ [이 설명서의 절차가 CodeDeploy 콘솔과 일치하지 않음](#troubleshooting-old-console)
+ [필요한 IAM 역할을 사용할 수 없음](#troubleshooting-iam-cloudformation)
+ [일부 텍스트 편집기를 사용하여 AppSpec 파일 및 쉘 스크립트를 작성하면 배포에 실패할 수 있음](#troubleshooting-text-editors)
+ [macOS에서 Finder를 사용하여 애플리케이션 수정을 번들링하면 배포에 실패할 수 있음](#troubleshooting-bundle-with-finder)
## 일반적인 문제 해결 체크리스트
다음 체크리스트를 사용하여 실패한 배포 문제를 해결할 수 있습니다.
1. 배포에 실패했는지 확인하려면 [CodeDeploy 배포 세부 정보 보기](deployments-view-details.md) 및 [CodeDeploy에서 인스턴스 정보 보기](instances-view-details.md) 단원을 확인하세요. 원인을 알 수 없는 경우에는 이 체크리스트의 항목을 살펴보십시오.
1. 다음과 같이 인스턴스가 올바르게 구성되었는지 확인합니다.
+ 지정된 EC2 키 페어로 인스턴스가 시작되었습니까? 자세한 내용은 *Amazon EC2 사용 설명서*의 [EC2 키 페어](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2-key-pairs.html)를 참조하세요.
+ 올바른 IAM 인스턴스 프로파일이 인스턴스에 연결되어 있습니까? 자세한 내용은 [CodeDeploy 작업을 위한 Amazon EC2 인스턴스 구성](instances-ec2-configure.md) 및 [4단계: Amazon EC2 인스턴스에 대한 IAM 인스턴스 프로파일 만들기](getting-started-create-iam-instance-profile.md) 단원을 참조하세요.
+ 인스턴스에 태그가 지정되어 있습니까? 자세한 내용은 *Amazon EC2 사용 설명서*의 [콘솔의 태그 작업](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console)을 참조하세요.
+ 인스턴스에서 CodeDeploy 에이전트가 설치 및 업데이트되었고 실행 중인가요? 자세한 내용은 [CodeDeploy 에이전트 작업 관리](codedeploy-agent-operations.md) 단원을 참조하십시오. 설치된 에이전트의 버전을 확인하려면 [CodeDeploy 에이전트의 버전 확인](codedeploy-agent-operations-version.md) 섹션을 참조하세요.
1. 다음과 같이 애플리케이션 및 배포 그룹 설정을 확인합니다.
+ 애플리케이션 설정을 확인하려면 [CodeDeploy로 애플리케이션 세부 정보 보기](applications-view-details.md) 단원을 참조하세요.
+ 배포 그룹 설정을 확인하려면 [CodeDeploy에서 배포 그룹 세부 정보 보기](deployment-groups-view-details.md) 단원을 참조하세요.
1. 다음과 같이 애플리케이션 수정이 올바르게 구성되었는지 확인합니다.
+ AppSpec 파일의 형식을 확인합니다. 자세한 내용은 [CodeDeploy에 대한 개정에 애플리케이션 사양 파일 추가](application-revisions-appspec-file.md) 및 [CodeDeploy AppSpec 파일 참조](reference-appspec-file.md) 단원을 참조하세요.
+ Amazon S3 버킷 또는 GitHub 리포지토리를 점검하여 애플리케이션이 예상된 위치에 있는지 확인합니다.
+ CodeDeploy 애플리케이션 수정의 세부 정보를 검토하여 애플리케이션 수정이 올바르게 등록되었는지 확인합니다. 자세한 내용은 [CodeDeploy를 사용하여 애플리케이션 개정 세부 정보 보기](application-revisions-view-details.md) 단원을 참조하세요.
+ Amazon S3에서 배포하는 경우 Amazon S3 버킷을 점검하여 CodeDeploy에 애플리케이션 개정 버전을 다운로드할 수 있는 권한이 부여되었는지 확인합니다. 버킷 정책에 대한 자세한 내용은 [배포 사전 조건](deployments-create-prerequisites.md) 단원을 참조하세요.
+ GitHub에서 배포하는 경우 GitHub 리포지토리를 점검하여 CodeDeploy에 애플리케이션 수정을 다운로드할 수 있는 권한이 부여되었는지 확인합니다. 자세한 내용은 [CodeDeploy에서 배포 만들기](deployments-create.md) 및 [CodeDeploy에서 애플리케이션으로 GitHub 인증](integrations-partners-github.md#behaviors-authentication) 단원을 참조하세요.
1. 서비스 역할이 올바르게 구성되었는지 확인합니다. 자세한 내용은 [2단계: CodeDeploy에 대한 서비스 역할 생성](getting-started-create-service-role.md) 단원을 참조하세요.
1. [CodeDeploy 시작하기](getting-started-codedeploy.md)의 단계를 수행했는지 확인하고 다음을 수행합니다.
+ 사용자에게 적절한 권한을 프로비저닝합니다.
+ AWS CLI를 설치 또는 업그레이드한 후 구성합니다.
+ IAM 인스턴스 프로파일 및 서비스 역할을 생성합니다.
자세한 내용은 [에 대한 자격 증명 및 액세스 관리 AWS CodeDeploy](security-iam.md) 단원을 참조하십시오.
1. AWS CLI 버전 1.6.1 이상을 사용하고 있는지 확인합니다. 설치된 버전을 확인하려면 **aws --version**을 호출합니다.
실패한 배포 관련 문제를 여전히 해결할 수 없는 경우 이 항목의 다른 문제를 검토합니다.
## CodeDeploy 배포 리소스는 일부 AWS 리전에서만 지원됩니다.
AWS CLI 또는 CodeDeploy 콘솔에서 애플리케이션, 배포 그룹, 인스턴스 또는 기타 배포 리소스가 표시되지 않거나 액세스할 수 없는 경우의 AWS 리전 [및 엔드포인트에 나열된 리전](https://docs.aws.amazon.com/general/latest/gr/rande.html#codedeploy_region) 중 하나를 참조해야 합니다*AWS 일반 참조*.
CodeDeploy 배포에 사용되는 EC2 인스턴스 및 Amazon EC2 Auto Scaling 그룹은 이러한 AWS 리전 중 하나에서 시작하고 생성해야 합니다.
를 사용하는 경우에서 **aws configure** 명령을 AWS CLI실행합니다 AWS CLI. 그런 다음 기본 AWS 리전을 보고 설정할 수 있습니다.
CodeDeploy 콘솔을 사용하는 경우 탐색 모음의 리전 선택기에서 지원되는 AWS 리전 중 하나를 선택합니다.
**중요**
중국(베이징) 리전 또는 중국(닝샤) 리전에서 서비스를 이용하려면 이들 리전에 대한 계정 및 자격 증명이 있어야 합니다. 다른 AWS 리전의 계정 및 자격 증명은 베이징 및 닝샤 리전에서는 작동하지 않으며 그 반대의 경우도 마찬가지입니다.
CodeDeploy 리소스 키트 버킷 이름 및 CodeDeploy 에이전트 설치 절차와 같은 중국 리전의 일부 리소스 관련 정보는 이 *CodeDeploy 사용 설명서* 에디션에 포함되어 있지 않습니다.
자세한 내용:
*[중국(베이징) 리전 AWS 에서 시작하기의](http://docs.amazonaws.cn/en_us/aws/latest/userguide/introduction.html) *[CodeDeploy](http://docs.amazonaws.cn/en_us/aws/latest/userguide/codedeploy.html)
*중국 리전의 CodeDeploy 사용 설명서*([영어 버전](http://docs.amazonaws.cn/en_us/codedeploy/latest/userguide/welcome.html) \$1 [중국어 버전](http://docs.amazonaws.cn/codedeploy/latest/userguide/welcome.html))
## 이 설명서의 절차가 CodeDeploy 콘솔과 일치하지 않음
이 설명서의 절차는 새 콘솔 디자인을 반영하여 작성되었습니다. 이전 버전의 콘솔을 사용하더라도 이 설명서의 여러 가지 개념과 기본 절차가 계속해서 적용됩니다. 새 콘솔에서 도움말에 액세스하려면 정보 아이콘을 선택하세요.
## 필요한 IAM 역할을 사용할 수 없음
AWS CloudFormation 스택의 일부로 생성된 IAM 인스턴스 프로파일 또는 서비스 역할에 의존하는 경우 스택을 삭제하면 모든 IAM 역할도 삭제됩니다. 이로 인해 IAM 콘솔에 IAM 역할이 더 이상 표시되지 않고 CodeDeploy가 예상대로 더 이상 작동하지 않을 수 있습니다. 이 문제를 해결하려면 삭제된 IAM 역할을 수동으로 다시 만들어야 합니다.
## 일부 텍스트 편집기를 사용하여 AppSpec 파일 및 쉘 스크립트를 작성하면 배포에 실패할 수 있음
일부 텍스트 편집기에서는 파일에는 인쇄되지 않는 비준수 문자가 포함됩니다. Amazon Linux, Ubuntu Server 또는 RHEL 인스턴스에서 실행하기 위해 텍스트 편집기를 사용하여 AppSpec 파일 또는 쉘 스크립트를 만들거나 수정하면 이러한 파일을 사용하는 모든 배포에 실패할 수 있습니다. CodeDeploy에서 배포 중 이러한 파일을 사용하면 이러한 문자로 인해 해결하기 어려운 AppSpec 파일 검증 실패 및 스크립트 실행 오류가 발생할 수 있습니다.
CodeDeploy 콘솔의 배포 이벤트 세부 정보 페이지에서 **로그 보기(View logs)**를 선택합니다. (또는를 사용하여 [get-deployment-instance](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-instance.html) 명령을 호출 AWS CLI 합니다.) `invalid character`, `command not found`, `file not found`와 같은 오류를 찾습니다.
이 문제를 해결하려면 다음과 같이 수행하는 것이 좋습니다.
+ AppSpec 파일 및 쉘 스크립트 파일에 캐리지 리턴(`^M` 문자) 등 인쇄되지 않는 문자를 포함하는 텍스트 편집기는 사용하지 마십시오.
+ AppSpec 파일 및 쉘 스크립트 파일에 캐리지 리턴 등과 같이 인쇄되지 않는 문자를 표시하는 텍스트 편집기를 사용합니다. 그러면 삽입될 수 있는 해당 문자를 모두 찾아서 제거할 수 있습니다. 이러한 유형의 텍스트 편집기에 대한 예를 찾아보려면 인터넷에서 캐리지 리턴을 표시하는 텍스트 편집기를 검색해 보십시오.
+ Amazon Linux, Ubuntu Server 또는 RHEL 인스턴스에서 실행되는 쉘 스크립트 파일을 생성하려면 Amazon Linux, Ubuntu Server 또는 RHEL 인스턴스에서 실행되는 텍스트 편집기를 사용합니다. 이러한 유형의 텍스트 편집기에 대한 예를 찾아보려면 인터넷에서 Linux 셸 스크립트 편집기를 검색해 보십시오.
+ Windows 또는 macOS에서 텍스트 편집기를 사용하여 Amazon Linux, Ubuntu Server 또는 RHEL 인스턴스에서 실행하기 위한 셸 스크립트 파일을 작성해야 하는 경우 Windows 또는 macOS 형식 텍스트를 Unix 형식으로 변환하는 프로그램 또는 유틸리티를 사용합니다. 이러한 프로그램 및 유틸리티의 예를 찾아보려면 인터넷에서 DOS에서 UNIX로 변환 또는 Mac에서 UNIX로 변환을 검색해 보십시오. 대상 운영 체제에서 변환된 셸 스크립트 파일을 테스트해 보십시오.
## macOS에서 Finder를 사용하여 애플리케이션 수정을 번들링하면 배포에 실패할 수 있음
Mac에서 Finder 그래픽 사용자 인터페이스(GUI) 애플리케이션을 사용하여 AppSpec 파일 및 관련 파일과 스크립트를 애플리케이션 수정 아카이브(.zip) 파일로 번들링(압축)하면 배포에 실패할 수 있습니다. 이는 Finder가 .zip 파일에 중간 `__MACOSX` 폴더를 만들어 이 폴더에 구성 요소 파일을 배치하는 것이 원인일 수 있습니다. CodeDeploy가 구성 요소 파일을 찾을 수 없으므로 배포에 실패합니다.
이 문제를 해결하려면 AWS CLI 를 사용하여 구성 요소 파일을 예상 구조로 압축하는 [push](https://docs.aws.amazon.com/cli/latest/reference/deploy/push.html) 명령을 호출하는 것이 좋습니다. 또는 GUI 대신 터미널을 사용하여 구성 요소 파일을 압축할 수 있습니다. 터미널은 중간 `__MACOSX` 폴더를 만들지 않습니다.
# EC2/온프레미스 배포 문제 해결
**Topics**
+ [CodeDeploy 플러그 인 CommandPoller 자격 증명 누락 오류](#troubleshooting-agent-commandpoller-error)
+ [배포에 실패하고 메시지 "Validation of PKCS7 signed message failed"가 표시됨](#troubleshooting-deployments-agent-SHA-256)
+ [동일한 파일을 같은 인스턴스 위치로 배포 또는 다시 배포하려고 하면 실패하고 오류 "The deployment failed because a specified file already exists at this location"이 표시됨](#troubleshooting-same-files-different-app-name)
+ [파일 경로가 길면 “No such file or directory(해당 파일 또는 디렉터리가 없음)” 오류가 발생함](#troubleshooting-long-file-paths)
+ [오래 실행되는 프로세스로 인해 배포에 실패할 수 있음](#troubleshooting-long-running-processes)
+ [배포 로그에 오류를 보고하지 않은 실패한 AllowTraffic 수명 주기 이벤트 문제 해결](#troubleshooting-deployments-allowtraffic-no-logs)
+ [실패한 ApplicationStop, BeforeBlockTraffic 또는 AfterBlockTraffic 배포 수명 주기 이벤트 문제 해결](#troubleshooting-deployments-lifecycle-event-failures)
+ [실패하고 UnknownError: not opened for reading이 표시되는 DownloadBundle 배포 수명 주기 이벤트 문제 해결](#troubleshooting-deployments-downloadbundle)
+ [모든 수명 주기 이벤트를 건너뛰었을 때 문제 해결](#troubleshooting-skipped-lifecycle-events)
+ [Windows PowerShell 스크립트에서 기본적으로 Windows PowerShell 64비트 버전을 사용하지 못함](#troubleshooting-deployments-powershell)
**참고**
배포 프로세스 중 생성되는 로그 파일을 검토하면 다양한 배포 실패의 원인을 파악할 수 있습니다. 간소화를 위해 인스턴스별로 로그 파일을 보는 대신 Amazon CloudWatch Logs를 사용하여 중앙에서 로그 파일을 모니터링하는 것이 좋습니다. 자세한 내용은 [CloudWatch Logs 콘솔에서 CodeDeploy 로그 보기](https://aws.amazon.com/blogs/devops/view-aws-codedeploy-logs-in-amazon-cloudwatch-console/)를 참조하세요.
**작은 정보**
EC2/온프레미스 배포와 관련된 많은 문제 해결 작업을 자동화하는 런북은 **AWS Systems Manager 자동화 런북 참조에서 [AWSSupport-TroubleshootCodeDeploy](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-troubleshootcodedeploy.html)를 참조하세요.
## CodeDeploy 플러그 인 CommandPoller 자격 증명 누락 오류
`InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Missing credentials - please check if this instance was started with an IAM instance profile`과 비슷한 오류 메시지가 수신되면 다음 중 한 가지가 원인일 수 있습니다.
+ 배포하려는 인스턴스에 IAM 인스턴스 프로파일이 연결되어 있지 않습니다.
+ IAM 인스턴스 프로파일에 권한이 올바르게 구성되어 있지 않습니다.
IAM 인스턴스 프로파일은 CodeDeploy 에이전트에게 CodeDeploy와 통신하고, Amazon S3에서 개정 버전을 다운로드할 수 있는 권한을 부여합니다. EC2 인스턴스에 대한 자세한 내용은 [에 대한 자격 증명 및 액세스 관리 AWS CodeDeploy](security-iam.md) 단원을 참조하세요. 온프레미스 인스턴스는 [CodeDeploy용 온프레미스 인스턴스 작업](instances-on-premises.md) 단원을 참조하세요.
## 배포에 실패하고 메시지 "Validation of PKCS7 signed message failed"가 표시됨
이 오류 메시지는 인스턴스가 SHA-1 해시 알고리즘만 지원하는 CodeDeploy 에이전트 버전을 실행하는 중임을 나타냅니다. SHA-2 해시 알고리즘에 대한 지원은 2015년 11월에 출시된 CodeDeploy 에이전트 버전 1.0.1.854에서 도입되었습니다. 2016년 10월 17일부터 CodeDeploy 에이전트 버전 1.0.1.854 이전이 설치되어 있는 경우에는 배포에 실패합니다. 자세한 내용은 [SSL 인증서를 위해 SHA256 해시 알고리즘으로 전환하는AWS](https://aws.amazon.com/security/security-bulletins/aws-to-switch-to-sha256-hash-algorithm-for-ssl-certificates/), [알림: 버전 1.0.1.85 이전 CodeDeploy 호스트 에이전트 사용 중지](https://forums.aws.amazon.com/thread.jspa?threadID=223319) 및 [CodeDeploy 에이전트 업데이트](codedeploy-agent-operations-update.md) 섹션을 참조하세요.
## 동일한 파일을 같은 인스턴스 위치로 배포 또는 다시 배포하려고 하면 실패하고 오류 "The deployment failed because a specified file already exists at this location"이 표시됨
CodeDeploy에서 파일을 인스턴스에 배포하려고 하지만, 지정된 대상 위치에 같은 이름의 파일이 이미 있는 경우 해당 인스턴스에 대한 배포에 실패할 수 있습니다. "The deployment failed because a specified file already exists at this location: *location-name*" 오류 메시지가 표시될 수 있습니다. 이는 각 배포 중 CodeDeploy가 먼저 정리 로그 파일에 나열된 파일을 이전 배포에서 모두 삭제하기 때문입니다. 대상 설치 폴더에 정리 파일에 나열되지 않은 파일이 있는 경우 기본적으로 CodeDeploy 에이전트에서는 이러한 파일을 오류로 해석하고 배포에 실패합니다.
**참고**
Amazon Linux, RHEL 및 Ubuntu Server 인스턴스에서 정리 파일은 `/opt/codedeploy-agent/deployment-root/deployment-instructions/`에 있습니다. Windows Server 인스턴스에서의 위치는 `C:\ProgramData\Amazon\CodeDeploy\deployment-instructions\`입니다.
이러한 오류를 피하려면 기본 동작을 배포 실패 이외의 옵션으로 지정하는 것이 가장 쉬운 방법입니다. 각 배포에 대해 배포에 실패하거나, 정리 파일에 나열되지 않은 파일을 덮어 쓰거나, 인스턴스에 이미 있는 파일을 보관하도록 선택할 수 있습니다.
예를 들어, 마지막 배포 후 인스턴스에 수동으로 파일을 배치했으나 다음 애플리케이션 수정에 이름이 동일한 파일을 추가한 경우 덮어쓰기 옵션이 유용합니다.
애플리케이션 수정 패키지에 추가하지 않고 다음 배포의 일부로 포함하려는 파일에 대해 보관 옵션을 선택할 수 있습니다. 또한 애플리케이션 파일이 프로덕션 환경에 이미 있는데 처음으로 CodeDeploy를 사용하여 배포하려고 하는 경우에는 보관 옵션이 유용합니다. 자세한 내용은 [EC2/온프레미스 컴퓨팅 플랫폼의 배포 생성(콘솔)](deployments-create-console.md) 및 [기존 컨텐츠의 롤백 동작](deployments-rollback-and-redeploy.md#deployments-rollback-and-redeploy-content-options) 단원을 참조하세요.
### `The deployment failed because a specified file already exists at this location` 배포 문제 해결
CodeDeploy가 대상 배포 위치에서 감지한 콘텐츠를 덮어 쓰거나 보관하는 옵션을 지정하지 않은 경우(또는 프로그래밍 방식 명령에서 기존 콘텐츠를 처리하기 위한 배포 옵션을 지정하지 않은 경우)에는 오류를 해결하도록 선택할 수 있습니다.
다음 정보는 콘텐츠를 보관 또는 덮어쓰도록 선택하지 않은 경우에만 적용됩니다.
동일한 이름 및 위치를 사용해 파일을 다시 배포하려는 경우 이전에 사용한 것과 동일한 기본 배포 그룹 ID로 애플리케이션 이름 및 배포 그룹을 지정하면 다시 배포에 성공할 가능성이 더욱 높습니다. CodeDeploy는 기본 배포 그룹 ID를 사용하여 재배포 전에 제거할 파일을 식별합니다.
다음과 같은 이유로 새 파일을 배포 또는 인스턴스의 같은 위치로 동일한 파일 다시 배포에 실패할 수 있습니다.
+ 동일한 수정을 같은 인스턴스로 다시 배포하기 위해 다른 애플리케이션 이름을 지정했습니다. 배포 그룹 이름이 동일하다고 하더라도 다른 애플리케이션 이름을 사용하면 다른 기본 배포 그룹 ID가 사용되기 때문에 다시 배포에 실패합니다.
+ 애플리케이션의 배포 그룹을 삭제한 다음 다시 만든 후 해당 배포 그룹으로 동일한 수정을 다시 배포하려고 했습니다. 배포 그룹 이름이 동일하다고 하더라도 CodeDeploy에서 다른 기본 배포 그룹 ID를 참조하기 때문에 다시 배포에 실패합니다.
+ CodeDeploy에서 애플리케이션 및 배포 그룹을 삭제한 다음 삭제한 것과 동일한 이름을 사용해 새 애플리케이션 및 배포 그룹을 만들었습니다. 그런 다음 이전 배포 그룹에 배포한 수정을 동일한 이름을 가진 새 배포 그룹에 다시 배포하려고 했습니다. 애플리케이션 및 배포 그룹 이름이 동일하다고 하더라도 CodeDeploy는 삭제한 배포 그룹의 ID를 참조하기 때문에 다시 배포에 실패합니다.
+ 수정을 배포 그룹 하나에 배포한 다음 동일한 수정을 같은 인스턴스의 다른 배포 그룹에 배포했습니다. CodeDeploy는 다른 기본 배포 그룹 ID를 참조하기 때문에 두 번째 배포에 실패합니다.
+ 수정을 배포 그룹 하나에 배포한 다음 다른 수정을 같은 인스턴스의 다른 배포 그룹에 배포했습니다. 두 번째 배포 그룹에서 배포하려고 하는 파일 중 이름과 위치가 같은 파일이 하나 이상 있습니다. CodeDeploy가 두 번째 배포를 시작하기 전에 기존 파일을 제거하지 않기 때문에 두 번째 배포에 실패합니다. 두 개의 배포에서는 다른 배포 그룹 ID를 참조합니다.
+ CodeDeploy에서 수정을 배포했으나 이름과 위치가 동일한 파일이 하나 이상 있습니다. 기본적으로 CodeDeploy에서 배포를 시작하기 전에 기존 파일을 제거하지 않기 때문에 배포에 실패합니다.
이러한 상황을 해결하려면 다음 중 하나를 수행하세요.
+ 이전에 배포된 위치 및 인스턴스에서 파일을 제거한 다음 배포를 다시 시도합니다.
+ ApplicationStop 또는 BeforeInstall 배포 수명 주기 이벤트 시 수정의 AppSpec 파일에서 수정에서 설치하려고 하는 파일과 일치하는 파일을 모든 위치에서 삭제하는 사용자 지정 스크립트를 지정합니다.
+ 이전 배포의 일부가 아닌 위치 또는 인스턴스로 파일을 배포 또는 다시 배포합니다.
+ 애플리케이션 또는 배포 그룹을 삭제하기 전에 인스턴스로 파일을 복사하지 않도록 지정하는 AppSpec 파일이 포함된 수정을 배포합니다. 배포에 대해 삭제하려는 것과 동일한 기본 애플리케이션 및 배포 그룹 ID를 사용하는 애플리케이션 이름 및 배포 그룹 이름을 지정합니다. ([get-groument-grout-name](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-group.html) 명령을 사용하여 배포 그룹 ID를 검색할 수 있습니다.) CodeDeploy는 기본 배포 그룹 ID와 AppSpec 파일을 사용하여 이전의 성공한 배포에서 설치한 파일을 모두 제거합니다.
## 파일 경로가 길면 “No such file or directory(해당 파일 또는 디렉터리가 없음)” 오류가 발생함
Windows 인스턴스에 배포할 때 appspec.yml 파일의 파일 섹션에 파일 경로가 260자를 초과하는 경우 다음과 비슷한 오류가 발생하며 배포가 실패하는 것을 볼 수 있습니다.
`No such file or directory @ dir_s_mkdir - C:\your-long-file-path`
이 오류는 [Microsoft 설명서에](https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=powershell#enable-long-paths-in-windows-10-version-1607-and-later) 자세히 설명된 것처럼 Windows에서 기본적으로 260자 이상의 파일 경로를 허용하지 않기 때문에 발생합니다.
CodeDeploy 에이전트 버전 1.4.0 이상에서는 에이전트 설치 프로세스에 따라 두 가지 방법으로 긴 파일 경로를 활성화할 수 있습니다.
CodeDeploy 에이전트가 아직 설치되지 않은 경우:
1. CodeDeploy 에이전트를 설치하려는 시스템에서 다음 명령을 사용하여 `LongPathsEnabled` Windows 레지스트리 키를 활성화합니다.
```
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem"
-Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force
```
1. CodeDeploy 에이전트를 설치합니다. 자세한 내용은 [CodeDeploy 에이전트 설치](codedeploy-agent-operations-install.md) 단원을 참조하십시오.
CodeDeploy 에이전트가 이미 설치된 경우:
1. CodeDeploy 에이전트 시스템에서 다음 명령을 사용하여 `LongPathsEnabled` Windows 레지스트리 키를 활성화합니다.
```
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem"
-Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force
```
1. 레지스트리 키 변경 사항을 적용하려면 CodeDeploy 에이전트를 다시 시작합니다. 에이전트를 다시 시작하려면 다음 명령을 사용합니다.
```
powershell.exe -Command Restart-Service -Name codedeployagent
```
## 오래 실행되는 프로세스로 인해 배포에 실패할 수 있음
Amazon Linux, Ubuntu Server 및 RHEL 인스턴스에 배포하는 경우, 오래 실행되는 프로세스를 시작하는 배포 스크립트가 있으면 CodeDeploy에서는 배포 수명 주기 이벤트를 오랜 시간 기다린 뒤 배포에 실패합니다. 해당 이벤트에서 실행이 예상되는 포그라운드 및 백그라운드 프로세스보다 오래 실행되는 프로세스가 있으면 이 프로세스가 예상대로 실행 중이더라도 CodeDeploy는 배포를 중지하고 배포에 실패합니다.
예를 들어, 애플리케이션 수정의 루트에는 `after-install.sh` 및 `sleep.sh`라는 두 파일이 있습니다. 이 AppSpec 파일에는 다음과 같은 지침이 포함되어 있습니다.
```
version: 0.0
os: linux
files:
- source: ./sleep.sh
destination: /tmp
hooks:
AfterInstall:
- location: after-install.sh
timeout: 60
```
`after-install.sh` 파일이 AfterInstall 애플리케이션 수명 주기 이벤트 중 실행됩니다. 이 파일의 내용은 다음과 같습니다.
```
#!/bin/bash
/tmp/sleep.sh
```
`sleep.sh` 파일에는 프로그램 실행을 3분(180초) 동안 일시 중지하여 오래 실행되는 프로세스를 시뮬레이션하는 다음과 같은 내용이 포함되어 있습니다.
```
#!/bin/bash
sleep 180
```
`after-install.sh`가 `sleep.sh`를 호출할 경우 `sleep.sh`가 시작되어 3분(180초) 동안 실행됩니다. 이는 CodeDeploy에서 `sleep.sh`(및 관계에 따라 `after-install.sh`)의 실행이 중지될 것으로 예상하는 시간보다 2분(120초)이 더 지난 시간입니다. 1분(60초)의 제한 시간이 지나면 CodeDeploy는 `sleep.sh`가 예상대로 계속해서 실행되더라도 AfterInstall 애플리케이션 수명 주기 이벤트에서 배포를 중지하고 배포에 실패합니다. 다음 오류가 표시됩니다.
`Script at specified location: after-install.sh failed to complete in 60 seconds`.
`after-install.sh`에 앰퍼샌드(`&`)를 추가하기만 해서는 `sleep.sh`가 백그라운드에서 실행되도록 할 수 없습니다.
```
#!/bin/bash
# Do not do this.
/tmp/sleep.sh &
```
앰퍼샌드를 추가하면 배포가 최대 1시간의 기본 배포 수명 주기 이벤트 제한 시간 동안 보류 중인 상태로 남아 있은 후 CodeDeploy가 이전처럼 AfterInstall 애플리케이션 수명 주기 이벤트에서 배포를 중지하고 배포에 실패합니다.
`after-install.sh`에서 다음과 같이 프로세스 실행 시작 후 CodeDeploy가 계속해서 실행되도록 하는 `sleep.sh`를 호출합니다.
```
#!/bin/bash
/tmp/sleep.sh > /dev/null 2> /dev/null < /dev/null &
```
이전 호출에서 `sleep.sh`는 백그라운드에서 실행하기 시작하려는 프로세스의 이름으로, stdout, stderr 및 stdin을 `/dev/null`로 리디렉션합니다.
## 배포 로그에 오류를 보고하지 않은 실패한 AllowTraffic 수명 주기 이벤트 문제 해결
AllowTraffic 수명 주기 이벤트 중 블루/그린 배포에 실패하지만 배포 로그에서 실패 원인을 확인할 수 없는 경우가 있습니다.
이 실패는 일반적으로 배포 그룹의 트래픽을 관리하는 데 사용되는 Classic Load Balancer, Application Load Balancer 또는 네트워크 로드 밸런서에 대해 Elastic Load Balancing에서 상태 확인이 잘못 구성되었기 때문에 발생합니다.
이 문제를 해결하려면 로드 밸런서의 상태 확인 구성에서 모든 오류를 검토해 수정합니다.
Classic Load Balancer의 경우 *Classic Load Balancers 사용 설명서*의 [상태 확인 구성](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-healthchecks.html) 및 *Elastic Load Balancing API 참조 버전 2012-06-01*의 [ConfigureHealthCheck](https://docs.aws.amazon.com/elasticloadbalancing/2012-06-01/APIReference/API_ConfigureHealthCheck.html)을 참조하세요.
Application Load Balancers의 경우 *Application Load Balancer 사용 설명서*의 [대상 그룹에 대한 상태 확인](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html)을 참조하세요.
네트워크 로드 밸런서의 경우 *Network Load Balancer 사용 설명서*의 [대상 그룹에 대한 상태 확인](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-health-checks.html)을 참조하세요.
## 실패한 ApplicationStop, BeforeBlockTraffic 또는 AfterBlockTraffic 배포 수명 주기 이벤트 문제 해결
배포 중 CodeDeploy 에이전트는 이전에 성공한 배포의 AppSpec 파일에서 ApplicationStop, BeforeBlockTraffic 및 AfterBlockTraffic에 대해 지정된 스크립트를 실행합니다. 기타 모든 스크립트는 현재 배포의 AppSpec 파일에서 실행됩니다. 이러한 스크립트 중 하나가 오류를 포함하고 있고 성공적으로 실행하지 않으면 배포에 실패할 수 있습니다.
이러한 실패의 가능한 원인은 다음과 같습니다.
+ CodeDeploy 에이전트는 올바른 위치에서 `deployment-group-id_last_successful_install` 파일을 찾지만, `deployment-group-id_last_successful_install` 파일에 지정된 위치가 존재하지 않습니다.
**Amazon Linux, Ubuntu Server 및 RHEL 인스턴스에서** 이 파일은 `/opt/codedeploy-agent/deployment-root/deployment-instructions`에 있어야 합니다.
**Windows Server 인스턴스에서** 이 파일의 위치는 `C:\ProgramData\Amazon\CodeDeploy\deployment-instructions` 폴더여야 합니다.
+ `deployment-group-id_last_successful_install` 파일에 지정된 위치에서 AppSpec 파일이 잘못되었거나 스크립트가 성공적으로 실행되지 않습니다.
+ 스크립트에 해결할 수 없는 오류가 포함되어 있어 성공적으로 실행할 수 없습니다.
CodeDeploy 콘솔을 사용하여 이러한 이벤트 중 배포에 실패할 수 있는 이유를 조사합니다. 배포의 세부 정보 페이지에서 [**View events**]를 선택합니다. 인스턴스 세부 정보 페이지의 **ApplicationStop**, **BeforeBlockTraffic** 또는 **AfterBlockTraffic** 행에서 **로그 보기**를 선택합니다. 또는 AWS CLI 를 사용하여 [get-deployment-instance](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-instance.html) 명령을 호출합니다.
이전에 성공한 배포에 포함된, 성공적으로 실행할 수 없는 스크립트가 실패의 원인인 경우 배포를 만들고 ApplicationStop, BeforeBlockTraffic 및 AfterBlockTraffic 실패를 무시하도록 지정합니다. 이렇게 하는 방법은 두 가지입니다.
+ CodeDeploy 콘솔을 사용하여 배포를 만듭니다. [**Create deployment**] 페이지의 [**ApplicationStop lifecycle event failure**]에서 [**Don't fail the deployment to an instance if this lifecycle event on the instance fails**]을 선택합니다.
+ AWS CLI 를 사용하여 **[create-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html)** 명령을 호출하고 `--ignore-application-stop-failures` 옵션을 포함합니다.
그러면 애플리케이션 수정을 다시 배포하는 경우 이러한 3가지 수명 주기 이벤트 중 하나가 실패하더라도 배포는 계속 진행됩니다. 새 수정에 이러한 수명 주기 이벤트에 대한 수정된 스크립트가 포함되어 있으면 이러한 수정 사항을 적용하지 않아도 향후 배포에 성공할 수 있습니다.
## 실패하고 UnknownError: not opened for reading이 표시되는 DownloadBundle 배포 수명 주기 이벤트 문제 해결
Amazon S3에서 애플리케이션 수정 버전을 배포하려고 하는데 DownloadBundle 배포 수명 주기 이벤트 중 배포에 실패하고 `UnknownError: not opened for reading` 오류가 표시됩니다.
+ 내부 Amazon S3 서비스 오류가 있습니다. 애플리케이션 수정을 다시 배포합니다.
+ EC2 인스턴스의 IAM 인스턴스 프로파일에 Amazon S3에서 애플리케이션 개정 버전에 액세스할 수 있는 권한이 없습니다. Amazon S3 버킷 정책에 대한 자세한 내용은 [Amazon S3에 CodeDeploy의 개정 푸시(EC2 온프레미스 배포 전용)](application-revisions-push.md) 및 [배포 사전 조건](deployments-create-prerequisites.md) 섹션을 참조하세요.
+ 에 배포하는 인스턴스는 한 AWS 리전(예: 미국 서부(오레곤))과 연결되지만 애플리케이션 개정이 포함된 Amazon S3 버킷은 다른 AWS 리전(예: 미국 동부(버지니아 북부))과 연결됩니다. 애플리케이션 개정이 인스턴스와 동일한 AWS 리전과 연결된 Amazon S3 버킷에 있는지 확인합니다.
배포의 이벤트 세부 정보 페이지에 있는 **Download bundle** 행에서 **로그 보기**를 선택합니다. 또는 AWS CLI 를 사용하여 [get-deployment-instance](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-instance.html) 명령을 호출합니다. 오류가 발생하면 출력에 오류 코드 `UnknownError` 및 오류 메시지 `not opened for reading`과 함께 오류가 표시되어야 합니다.
이 오류가 발생한 이유를 확인하려면:
1. 하나 이상의 인스턴스에서 유선 로깅을 활성화한 후 애플리케이션 수정을 다시 배포합니다.
1. 유선 로깅 파일을 검사하여 오류를 찾습니다. 이 문제에 대한 일반적인 오류 메시지에는 "액세스 거부됨(access denied)"이라는 문구가 포함됩니다.
1. 로그 파일을 검사한 후에는 유선 로깅을 비활성화하여, 이후 인스턴스에서 출력에 일반 텍스트로 표시될 수 있는 민감한 정보의 양과 로그 파일의 크기를 줄이는 것이 좋습니다.
유선 로깅 파일을 찾아 유선 로깅을 활성화 및 비활성화하는 방법에 대한 자세한 내용은 [CodeDeploy 에이전트 구성 참조](https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-agent-configuration.html)의 `:log_aws_wire:` 단원을 참조하세요.
## 모든 수명 주기 이벤트를 건너뛰었을 때 문제 해결
EC2 또는 온프레미스 배포 수명 주기 이벤트를 모두 건너뛸 경우 "`The overall deployment failed because too many individual instances failed deployment, too few healthy instances are available for deployment, or some instances in your deployment group are experiencing problems. (Error code: HEALTH_CONSTRAINTS)`"와 비슷한 오류 메시지가 수신될 수 있습니다. 이때 몇 가지 가능한 원인과 해결책은 다음과 같습니다.
+ CodeDeploy 에이전트가 인스턴스에 설치되어 있지 않거나 실행되고 있지 않을 수 있습니다. CodeDeploy 에이전트의 실행 여부를 확인하려면:
+ Amazon Linux RHEL 또는 Ubuntu 서버일 경우 다음과 같이 실행합니다.
```
systemctl status codedeploy-agent
```
+ Windows일 경우 다음과 같이 실행합니다.
```
powershell.exe -Command Get-Service -Name CodeDeployagent
```
CodeDeploy 에이전트가 설치되어 있지 않거나, 혹은 실행되지 않으면 [CodeDeploy 에이전트가 실행 중인지 확인](codedeploy-agent-operations-verify.md) 단원을 참조하세요.
인스턴스가 포트 443을 사용해서 CodeDeploy 또는 Amazon S3 퍼블릭 엔드포인트에 도달하지 못할 수 있습니다. 다음 중 하나를 시도하세요.
+ 퍼블릭 IP 주소를 인스턴스에 할당한 후 라우팅 테이블을 사용해 인터넷 액세스를 허용합니다. 이때 인스턴스에 연결된 보안 그룹이 포트 443을 통한 아웃바운드 액세스를 허용해야 합니다(HTTPS). 자세한 내용은 [CodeDeploy 에이전트용 통신 프로토콜 및 포트](codedeploy-agent.md#codedeploy-agent-outbound-port) 단원을 참조하십시오.
+ 인스턴스가 프라이빗 서브넷에 프로비저닝되어 있을 경우에는 라우팅 테이블에서 인터넷 게이트웨이가 아닌 NAT 게이트웨이를 사용합니다. 자세한 내용은 [NAT 게이트웨이](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) 단원을 참조하세요.
+ CodeDeploy 서비스 역할은 권한이 필요하지 않을 수도 있습니다. CodeDeploy 서비스 역할을 구성하려면 [2단계: CodeDeploy에 대한 서비스 역할 생성](getting-started-create-service-role.md) 단원을 참조하세요.
+ HTTP 프록시를 사용할 때는 이 프록시를 CodeDeploy 에이전트 구성 파일의 `:proxy_uri:` 설정에서 지정해야 합니다. 자세한 내용은 [CodeDeploy 에이전트 구성 참조](reference-agent-configuration.md) 단원을 참조하십시오.
+ 배포 인스턴스의 날짜 및 시간 서명이 배포 요청의 날짜 및 시간 서명과 일치하지 않을 수도 있습니다. CodeDeploy 에이전트 로그 파일에서 "`Cannot reach InstanceService: Aws::CodeDeployCommand::Errors::InvalidSignatureException - Signature expired`"와 유사한 오류 메시지가 있는지 찾습니다. 오류 메시지가 있다면 ["InvalidSignatureException - Signature expired: [time] is now earlier than [time]" 배포 오류 문제 해결](troubleshooting-ec2-instances.md#troubleshooting-instance-time-failures)의 단계를 따르십시오. 자세한 내용은 [CodeDeploy EC2/온프레미스 배포에 대한 로그 데이터 보기](deployments-view-logs.md) 단원을 참조하십시오.
+ 인스턴스 실행 중 메모리 또는 하드 디스크 공간 부족으로 인해 CodeDeploy 에이전트가 실행을 멈췄을 수도 있습니다. 이때는 CodeDeploy 에이전트 구성에서 `max_revisions` 설정을 업데이트하여 인스턴스에 보관된 배포 수를 줄여 봅니다. EC2 인스턴스에서 배포 수를 줄인 후에도 문제가 지속되면 용량이 더 큰 인스턴스를 사용하는 것이 좋습니다. 예를 들어 인스턴스 유형이 `t2.small`이라면 `t2.medium`으로 바꿔 사용하세요. 자세한 내용은 [CodeDeploy 에이전트에 의해 설치된 파일](codedeploy-agent.md#codedeploy-agent-install-files), [CodeDeploy 에이전트 구성 참조](reference-agent-configuration.md) 및 [ 인스턴스 유형](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) 섹션을 참조하세요.
+ 배포하려는 인스턴스에 IAM 인스턴스 프로파일이 연결되어 있지 않거나 IAM 인스턴스 프로파일이 필요한 권한 없이 연결되어 있을 수 있습니다.
+ IAM 인스턴스 프로파일이 인스턴스에 연결되어 있지 않다면 필요한 권한과 함께 인스턴스 프로파일을 생성하여 연결합니다.
+ IAM 인스턴스 프로파일이 이미 인스턴스에 연결되어 있다면 필요한 권한이 있는지 확인합니다.
연결된 인스턴스 프로파일이 필요한 권한과 함께 구성되어 있는지 확인한 후 인스턴스를 다시 시작합니다. 자세한 내용은 [4단계: Amazon EC2 인스턴스에 대한 IAM 인스턴스 프로파일 만들기](getting-started-create-iam-instance-profile.md) 섹션과 *Amazon EC2 사용 설명서*에서 [Amazon EC2의 IAM 역할](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-EC2.html)을 참조하세요.
## Windows PowerShell 스크립트에서 기본적으로 Windows PowerShell 64비트 버전을 사용하지 못함
배포의 일부로 실행 중인 Windows PowerShell 스크립트가 64비트 기능을 사용하는 경우(예를 들어 32비트보다 더 많은 메모리를 사용하기 때문에 애플리케이션에서 64비트 버전에서만 제공하는 라이브러리만 허용 또는 호출함) 이 스크립트가 충돌하거나 그렇지 않으면 예상대로 실행되지 않을 수 있습니다. 기본적으로 CodeDeploy가 Windows PowerShell 32비트 버전을 사용하여 애플리케이션 수정의 일부인 Windows PowerShell 스크립트를 실행하는 것이 원인입니다.
Windows PowerShell 64비트 버전을 사용해 실행해야 하는 스크립트의 시작 부분에 다음과 같은 코드를 추가합니다.
```
# Are you running in 32-bit mode?
# (\SysWOW64\ = 32-bit mode)
if ($PSHOME -like "*SysWOW64*")
{
Write-Warning "Restarting this script under 64-bit Windows PowerShell."
# Restart this script under 64-bit Windows PowerShell.
# (\SysNative\ redirects to \System32\ for 64-bit mode)
& (Join-Path ($PSHOME -replace "SysWOW64", "SysNative") powershell.exe) -File `
(Join-Path $PSScriptRoot $MyInvocation.MyCommand) @args
# Exit 32-bit script.
Exit $LastExitCode
}
# Was restart successful?
Write-Warning "Hello from $PSHOME"
Write-Warning " (\SysWOW64\ = 32-bit mode, \System32\ = 64-bit mode)"
Write-Warning "Original arguments (if any): $args"
# Your 64-bit script code follows here...
# ...
```
이 코드의 파일 경로 정보가 합리적이지 않은 것처럼 보일 수 있지만 32비트 Windows PowerShell은 다음과 같은 경로를 사용합니다.
`c:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe`
64비트 Windows PowerShell은 다음과 같은 경로를 사용합니다.
`c:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe`
# Amazon ECS 배포 문제 해결
**Topics**
+ [대체 작업 세트를 기다리는 동안 시간 초과 발생](#troubleshooting-ecs-timeout)
+ [알림이 계속되기를 기다리는 동안 시간 초과 발생](#troubleshooting-ecs-timeout-notif)
+ [IAM 역할에 충분한 권한이 없음](#troubleshooting-ecs-iam)
+ [상태 콜백을 기다리는 동안 배포 시간 초과](#troubleshooting-ecs-timeout-callback)
+ [하나 이상의 수명 주기 이벤트 검증 함수가 실패하여 배포 실패](#troubleshooting-ecs-lifecycle)
+ [다음 오류로 인해 ELB를 업데이트할 수 없음: 기본 작업 세트 대상 그룹은 리스너 뒤에 있어야 함](#troubleshooting-ecs-elb)
+ [Auto Scaling을 사용할 때 때때로 배포가 실패함](#troubleshooting-ecs-auto-scaling)
+ [ALB만 점진적인 트래픽 라우팅을 지원하므로 배포 그룹을 생성/업데이트할 때는 대신 AllAtOnce 트래픽 라우팅을 대신 사용해야 함](#troubleshooting-ecs-lb)
+ [배포에 성공했는데도 대체 작업 세트가 Elastic Load Balancing 상태 확인에 실패하고 애플리케이션이 다운됨](#troubleshooting-ecs-task-set-stability)
+ [배포 그룹에 여러 로드 밸런서를 연결할 수 있나요?](#troubleshooting-ecs-lb-multi)
+ [로드 밸런서 없이 CodeDeploy 블루/그린 배포를 수행할 수 있나요?](#troubleshooting-ecs-lb-bg)
+ [배포 중에 새 정보로 Amazon ECS 서비스를 업데이트하려면 어떻게 해야 하나요?](#troubleshooting-ecs-exec)
## 대체 작업 세트를 기다리는 동안 시간 초과 발생
**문제**: CodeDeploy를 사용하여 Amazon ECS 애플리케이션을 배포하는 동안 다음 오류 메시지가 표시됩니다.
`The deployment timed out while waiting for the replacement task set to become healthy. This time out period is 60 minutes.`
**가능한 원인**: 작업 정의 파일 또는 기타 배포 관련 파일에 오류가 있는 경우 이 오류가 발생할 수 있습니다. 예를 들어 작업 정의 파일의 `image` 필드에 오타가 있는 경우 Amazon ECS가 잘못된 컨테이너 이미지를 가져오려고 시도하고 계속 실패하여 이 오류가 발생합니다.
**가능한 해결 방법 및 다음 단계**:
+ 작업 정의 파일과 기타 파일의 오타 및 구성 문제를 해결합니다.
+ 관련 Amazon ECS 서비스 이벤트를 확인하고 대체 작업이 정상적으로 진행되지 않는 이유를 알아봅니다. Amazon ECS 이벤트에 대한 자세한 내용은 *Amazon Elastic 컨테이너 서비스 개발자 안내서*의 [Amazon ECS 이벤트](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)를 참조하세요.
+ *Amazon Elastic Container Service 개발자 안내서*의 [Amazon ECS 문제 해결](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html) 섹션에서 이벤트의 메시지와 관련된 오류를 확인합니다.
## 알림이 계속되기를 기다리는 동안 시간 초과 발생
**문제**: CodeDeploy를 사용하여 Amazon ECS 애플리케이션을 배포하는 동안 다음 오류 메시지가 표시됩니다.
`The deployment timed out while waiting for a notification to continue. This time out period is n minutes.`
**가능한 원인**: 배포 그룹을 생성할 때 **트래픽을 언제 다시 라우팅할지 지정**에 대기 시간을 지정했지만 대기 시간이 만료되기 전에 배포가 완료되지 못한 경우 이 오류가 발생할 수 있습니다.
**가능한 해결 방법 및 다음 단계**:
+ 배포 그룹에서 **트래픽을 언제 다시 라우팅할지 지정**을 더 많은 시간으로 설정하고 다시 배포합니다. 자세한 내용은 [Amazon ECS 배포에 사용할 수 있는 배포 그룹 만들기(콘솔)](deployment-groups-create-ecs.md) 단원을 참조하십시오.
+ 배포 그룹에서 **트래픽을 언제 다시 라우팅할지 지정**을 **즉시 트래픽 다시 라우팅**으로 변경하고 다시 배포합니다. 자세한 내용은 [Amazon ECS 배포에 사용할 수 있는 배포 그룹 만들기(콘솔)](deployment-groups-create-ecs.md) 단원을 참조하십시오.
+ `--deployment-wait-type` 옵션을 로 설정하여 다시 배포한 다음 [https://docs.aws.amazon.com/cli/latest/reference/deploy/continue-deployment.html](https://docs.aws.amazon.com/cli/latest/reference/deploy/continue-deployment.html) AWS CLI 명령을 실행합니다`READY_WAIT`. **트래픽을 언제 다시 라우팅할지 지정**에 지정된 시간이 만료되기 *전에* 이 명령을 실행해야 합니다.
## IAM 역할에 충분한 권한이 없음
**문제**: CodeDeploy를 사용하여 Amazon ECS 애플리케이션을 배포하는 동안 다음 오류 메시지가 표시됩니다.
`The IAM role role-arn does not give you permission to perform operations in the following AWS service: AWSLambda.`
**가능한 원인**: [AppSpec 파일의 `Hooks` 섹션](reference-appspec-file-structure-hooks.md#appspec-hooks-ecs)에서 Lambda 함수를 지정했지만 Lambda 서비스에 CodeDeploy 권한을 부여하지 않은 경우 이 오류가 발생할 수 있습니다.
**가능한 해결 방법**: CodeDeploy 서비스 역할에 `lambda:InvokeFunction` 권한을 추가합니다. 이 권한을 추가하려면 다음 AWS관리형 정책 중 하나를 **AWSCodeDeployRoleForECS** 또는 **AWSCodeDeployRoleForECSLimited** 역할에 추가합니다. 이러한 정책 및 CodeDeploy 서비스 역할에 정책을 추가하는 방법에 대한 자세한 내용은 [2단계: CodeDeploy에 대한 서비스 역할 생성](getting-started-create-service-role.md) 섹션을 참조하세요.
## 상태 콜백을 기다리는 동안 배포 시간 초과
**문제**: CodeDeploy를 사용하여 Amazon ECS 애플리케이션을 배포하는 동안 다음 오류 메시지가 표시됩니다.
`The deployment timed out while waiting for a status callback. CodeDeploy expects a status callback within one hour after a deployment hook is invoked.`
**가능한 원인**: [AppSpec 파일의 `Hooks` 섹션](reference-appspec-file-structure-hooks.md#appspec-hooks-ecs)에서 Lambda 함수를 지정했지만 Lambda 함수가 CodeDeploy에 `Succeeded` 또는 `Failed` 상태를 반환하는 데 필요한 `PutLifecycleEventHookExecutionStatus` API를 호출하지 못한 경우 이 오류가 발생할 수 있습니다.
**가능한 해결 방법 및 다음 단계**:
+ AppSpec 파일에서 지정한 Lambda 함수가 사용하는 Lambda 실행 역할에 `codedeploy:putlifecycleEventHookExecutionStatus` 권한을 추가합니다. 이 권한은 Lambda 함수가 CodeDeploy에 `Succeeded` 또는 `Failed` 상태를 반환할 수 있도록 허용합니다. Lambda 실행 역할에 대한 자세한 내용은 *AWS Lambda 사용 설명서*의 [Lambda 실행 역할](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)을 참조하세요.
+ Lambda 함수 코드와 실행 로그를 검토해 Lambda 함수가 CodeDeploy의 `PutLifecycleEventHookExecutionStatus` API를 호출하여 수명 주기 검증 테스트 `Succeeded` 또는 `Failed`에 대해 CodeDeploy에 알리고 있는지 확인합니다. `putlifecycleEventHookExecutionStatus` API에 대한 자세한 내용은 *AWS CodeDeploy API 참조*의 [PutLifecycleEventHookExecutionStatus](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_PutLifecycleEventHookExecutionStatus.html)를 참조하세요. Lambda 실행 로그에 대한 자세한 내용은 [AWS Lambda에 대한 Amazon CloudWatch Logs 액세스](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html)를 참조하세요.
## 하나 이상의 수명 주기 이벤트 검증 함수가 실패하여 배포 실패
**문제**: CodeDeploy를 사용하여 Amazon ECS 애플리케이션을 배포하는 동안 다음 오류 메시지가 표시됩니다.
`The deployment failed because one or more of the lifecycle event validation functions failed.`
**가능한 원인**: [AppSpec 파일의 `Hooks` 섹션](reference-appspec-file-structure-hooks.md#appspec-hooks-ecs)에서 Lambda 함수를 지정했지만 Lambda 함수가 `PutLifecycleEventHookExecutionStatus`를 호출할 때 CodeDeploy에 `Failed`를 반환한 경우 이 오류가 발생할 수 있습니다. 이 실패는 CodeDeploy에 수명 주기 검증 테스트가 실패했음을 나타냅니다.
**가능한 다음 단계**: Lambda 실행 로그를 검토하여 검증 테스트 코드가 실패한 이유를 확인합니다. Lambda 실행 로그에 대한 자세한 내용은 [AWS Lambda에 대한 Amazon CloudWatch Logs 액세스](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html)를 참조하세요.
## 다음 오류로 인해 ELB를 업데이트할 수 없음: 기본 작업 세트 대상 그룹은 리스너 뒤에 있어야 함
**문제**: CodeDeploy를 사용하여 Amazon ECS 애플리케이션을 배포하는 동안 다음 오류 메시지가 표시됩니다.
`The ELB could not be updated due to the following error: Primary taskset target group must be behind listener`
**가능한 원인**: 선택적 테스트 리스너를 구성했는데 잘못된 대상 그룹으로 구성된 경우 이 오류가 발생할 수 있습니다. CodeDeploy의 테스트 리스너에 대한 자세한 내용은 [Amazon ECS 배포를 시작하기 전](deployment-steps-ecs.md#deployment-steps-prerequisites-ecs) 및 [Amazon ECS 배포 중에 발생하는 일](deployment-steps-ecs.md#deployment-steps-what-happens) 섹션을 참조하세요. 작업 세트에 대한 자세한 내용은 *Amazon Elastic Container Service API 참조*의 [TaskSet](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_TaskSet.html) 및 *AWS CLI 명령 참조*의 Amazon ECS 섹션에 있는 [describe-task-set](https://docs.aws.amazon.com/cli/latest/reference/ecs/describe-task-set.html)를 참조하세요.
**가능한 해결 방법**: Elastic Load Balancing의 프로덕션 리스너와 테스트 리스너가 모두 현재 워크로드를 제공하는 대상 그룹을 가리키고 있는지 확인합니다. 다음 세 곳에서 확인할 수 있습니다.
+ Amazon EC2에서 로드 밸런서의 **리스너 및 규칙** 설정. 자세한 내용은 *Application Load Balancer 사용 설명서*의 [Application Load Balancer를 위한 리스너](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html) 또는 *Network Load Balancer 사용 설명서*의 [Network Load Balancer를 위한 리스너](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-listeners.html)를 참조하세요.
+ Amazon ECS에서 클러스터의 서비스 **네트워킹** 구성 아래. 자세한 내용은 *Amazon Elastic Container Service 개발자 안내서*의 [Application Load Balancer 및 Network Load Balancer 고려 사항](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/load-balancer-types.html#alb-considerations)을 참조하세요.
+ CodeDeploy의 배포 그룹 설정. 자세한 내용은 [Amazon ECS 배포에 사용할 수 있는 배포 그룹 만들기(콘솔)](deployment-groups-create-ecs.md) 단원을 참조하십시오.
## Auto Scaling을 사용할 때 때때로 배포가 실패함
**문제**: CodeDeploy와 함께 Auto Scaling을 사용하고 있는데 배포가 실패하는 경우가 있습니다. 이 문제의 증상에 대한 자세한 내용은 *Amazon Elastic Container Service 개발자 안내서*의 [서비스 자동 크기 조정 및 블루/그린 배포 유형을 사용하도록 구성된 서비스의 경우 배포 중에 자동 크기 조정이 차단되지 않지만 일부 상황에서는 배포가 실패할 수 있습니다](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-bluegreen.html#deployment-type-bluegreen-considerations)라는 주제를 참조하세요.
**가능한 원인**: CodeDeploy와 Auto Scaling 프로세스가 충돌하는 경우 이 문제가 발생할 수 있습니다.
**수정 방법**: `RegisterScalableTarget` API(또는 해당 `register-scalable-target` AWS CLI 명령)를 사용하여 CodeDeploy 배포 중에 Auto Scaling 프로세스를 일시 중지하고 재개합니다. 자세한 내용을 알아보려면 *Application Auto Scaling 사용 설명서*의 [Application Auto Scaling의 조정 일시 중지 및 재개](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-suspend-resume-scaling.html)를 참조하세요.
**참고**
CodeDeploy는 `RegisterScaleableTarget`를 직접 호출할 수 없습니다. 이 API를 사용하려면 Amazon Simple Notification Service(또는 Amazon CloudWatch)에 알림 또는 이벤트를 전송하도록 CodeDeploy를 구성해야 합니다. 그런 다음 Lambda 함수를 호출하도록 Amazon SNS(또는 CloudWatch)를 구성하고, `RegisterScalableTarget` API를 호출하도록 Lambda 함수를 구성해야 합니다. Auto Scaling 작업을 일시 중지하려면 `SuspendedState` 파라미터를 `true`로 설정하고, 재개하려면 `false`로 설정하여 `RegisterScalableTarget` API를 호출해야 합니다.
CodeDeploy가 전송하는 알림 또는 이벤트는 배포가 시작될 때(Auto Scaling 일시 중지 작업을 트리거하기 위해) 또는 배포가 성공, 실패 또는 중지될 때(Auto Scaling 재개 작업을 트리거하기 위해) 발생해야 합니다.
Amazon SNS 알림 또는 CloudWatch 이벤트를 생성하도록 CodeDeploy를 구성하는 방법에 대한 자세한 내용은 [Amazon CloudWatch Events를 사용하여 배포 모니터링](monitoring-cloudwatch-events.md) 및 [Amazon SNS 이벤트 알림으로 배포 모니터링](monitoring-sns-event-notifications.md) 섹션을 참조하세요.
## ALB만 점진적인 트래픽 라우팅을 지원하므로 배포 그룹을 생성/업데이트할 때는 대신 AllAtOnce 트래픽 라우팅을 대신 사용해야 함
**문제**: CodeDeploy에서 배포 그룹을 생성하거나 업데이트하는 동안 다음 오류 메시지가 표시됩니다.
`Only ALB supports gradual traffic routing, use AllAtOnce Traffic routing instead when you create/update Deployment group.`
**가능한 원인**: Network Load Balancer를 사용 중이고 `CodeDeployDefault.ECSAllAtOnce` 이외의 미리 정의된 배포 구성을 사용하려고 하면 이 오류가 발생할 수 있습니다.
**수정 방법:**
+ 미리 정의된 배포 구성을 `CodeDeployDefault.ECSAllAtOnce`로 변경합니다. 이는 Network Load Balancer에서 지원하는 유일한 미리 정의된 배포 구성입니다.
미리 정의된 배포 구성에 대한 자세한 내용은 [Amazon ECS 컴퓨팅 플랫폼에 대해 미리 정의된 배포 구성](deployment-configurations.md#deployment-configurations-predefined-ecs) 섹션을 참조하세요.
+ 로드 밸런서를 Application Load Balancer로 변경합니다. Application Load Balancer는 미리 정의된 모든 배포 구성을 지원합니다. Application Load Balancer 생성에 대한 자세한 내용은 [CodeDeploy Amazon ECS 배포를 위한 로드 밸런서, 대상 그룹 및 리스너 설정](deployment-groups-create-load-balancer-for-ecs.md) 섹션을 참조하세요.
## 배포에 성공했는데도 대체 작업 세트가 Elastic Load Balancing 상태 확인에 실패하고 애플리케이션이 다운됨
**문제**: CodeDeploy에 배포가 성공했다고 표시되지만 대체 작업 세트가 Elastic Load Balancing의 상태 확인에 실패하고 애플리케이션이 다운되었습니다.
**가능한 원인**: 이 문제는 CodeDeploy 일괄 배포를 수행했고 대체(그린) 작업 세트에 Elastic Load Balancing 상태 확인 실패를 유발하는 잘못된 코드가 포함된 경우 발생할 수 있습니다. 일괄 배포 구성을 사용하는 경우 트래픽이 이동된 *후*(즉, CodeDeploy의 `AllowTraffic` 수명 주기 이벤트가 발생한 *후*) 대체 작업 세트에서 로드 밸런서의 상태 확인이 실행되기 시작합니다. 따라서 트래픽이 이동하기 전에는 안 그렇지만 이동한 후에는 대체 작업 세트에 대한 상태 확인이 실패하게 됩니다. CodeDeploy에서 생성하는 수명 주기 이벤트에 대한 자세한 내용은 [Amazon ECS 배포 중에 발생하는 일](deployment-steps-ecs.md#deployment-steps-what-happens) 섹션을 참조하세요.
**수정 방법:**
+ 배포 구성을 일괄에서 Canary 또는 Linear로 변경합니다. Canary 또는 Linear 구성에서는 CodeDeploy가 대체 환경에 애플리케이션을 설치하는 동안, 그리고 트래픽이 이동되기 *전*(즉, `Install` 수명 주기 이벤트 중 및 `AllowTraffic` 이벤트 *전*) 대체 작업 세트에서 로드 밸런서의 상태 확인이 실행되기 시작합니다. 애플리케이션 설치 중에 트래픽이 이동하기 전에 검사를 실행하도록 허용하면 잘못된 애플리케이션 코드가 탐지되어 애플리케이션이 공개되기 전에 배포가 실패하게 됩니다.
Canary 또는 Linear 배포를 구성하는 방법에 대한 자세한 내용은 [CodeDeploy에서 배포 그룹 설정 변경](deployment-groups-edit.md) 섹션을 참조하세요.
Amazon ECS 배포 중에 실행되는 CodeDeploy 수명 주기 이벤트에 대한 자세한 내용은 [Amazon ECS 배포 중에 발생하는 일](deployment-steps-ecs.md#deployment-steps-what-happens) 섹션을 참조하세요.
**참고**
Canary 및 Linear 배포 구성은 Application Load Balancer에서만 지원됩니다.
+ 일괄 배포 구성을 유지하려면 테스트 리스너를 설정하고 `BeforeAllowTraffic` 수명 주기 후크를 사용하여 대체 작업 세트의 상태를 확인합니다. 자세한 내용은 [Amazon ECS 배포를 위한 수명 주기 이벤트 후크 목록](reference-appspec-file-structure-hooks.md#reference-appspec-file-structure-hooks-list-ecs) 단원을 참조하십시오.
## 배포 그룹에 여러 로드 밸런서를 연결할 수 있나요?
아니요. 여러 Application Load Balancer 또는 Network Load Balancer를 사용하려면 CodeDeploy 블루/그린 배포 대신 Amazon ECS 롤링 업데이트를 사용하세요. 롤링 업데이트에 대한 자세한 내용은 *Amazon Elastic Container Service 개발자 안내서*의 [롤링 업데이트](https://docs.aws.amazon.com/AmazonECS/latest/userguide/deployment-type-ecs.html)를 참조하세요. Amazon ECS에 여러 로드 밸런서를 사용하는 방법에 대한 자세한 내용을 알아보려면 *Amazon Elastic Container Service 개발자 안내서*의 [서비스에 여러 대상 그룹 등록](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/register-multiple-targetgroups.html)을 참조하세요.
## 로드 밸런서 없이 CodeDeploy 블루/그린 배포를 수행할 수 있나요?
아니요. 로드 밸런서 없이 CodeDeploy 블루/그린 배포를 수행할 수 없습니다. 로드 밸런서를 사용할 수 없는 경우 Amazon ECS의 롤링 업데이트 기능을 대신 사용하세요. Amazon ECS 롤링 업데이트에 대한 자세한 내용은 *Amazon Elastic Container Service 개발자 안내서*의 [롤링 업데이트](https://docs.aws.amazon.com/AmazonECS/latest/userguide/deployment-type-ecs.html)를 참조하세요.
## 배포 중에 새 정보로 Amazon ECS 서비스를 업데이트하려면 어떻게 해야 하나요?
배포를 수행하는 동안 CodeDeploy가 Amazon ECS 서비스를 새 파라미터로 업데이트하도록 하려면 AppSpec 파일의 `resources` 섹션에서 해당 파라미터를 지정하세요. CodeDeploy는 작업 정의 파일 및 컨테이너 이름 파라미터와 같은 몇 가지 Amazon ECS 파라미터만 지원합니다. CodeDeploy에서 업데이트할 수 있는 Amazon ECS 파라미터의 전체 목록은 [Amazon ECS 배포를 위한 AppSpec 'resources' 섹션](reference-appspec-file-structure-resources.md#reference-appspec-file-structure-resources-ecs) 섹션을 참조하세요.
**참고**
CodeDeploy에서 지원하지 않는 파라미터로 Amazon ECS 서비스를 업데이트해야 하는 경우 다음 작업을 완료합니다.
업데이트하려는 파라미터를 사용하여 Amazon ECS의 `UpdateService` API를 호출합니다. 업데이트할 수 있는 파라미터의 전체 목록은 *Amazon Elastic Container Service API 참조*의 [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)를 참조하세요.
작업에 변경 내용을 적용하려면 새 Amazon ECS 블루/그린 배포를 생성합니다. 자세한 내용은 [Amazon ECS 컴퓨팅 플랫폼에 대한 배포 생성(콘솔)](deployments-create-console-ecs.md) 단원을 참조하십시오.
# AWS Lambda 배포 문제 해결
**Topics**
+ [AWS Lambda 롤백이 구성되지 않은 Lambda 배포를 수동으로 중지한 후 배포가 실패함](#troubleshooting-manually-stopped-lambda-deployment)
## AWS Lambda 롤백이 구성되지 않은 Lambda 배포를 수동으로 중지한 후 배포가 실패함
경우에 따라 배포에 지정된 Lambda 함수 별칭이 두 가지 서로 다른 함수 버전을 참조할 수 있습니다. 이 경우 Lambda 함수를 배포하기 위한 다음 시도가 실패합니다. Lambda 배포에 구성된 롤백이 없고 수동으로 중지한 경우 배포가 이러한 상태로 될 수 있습니다. 계속하려면 AWS Lambda 콘솔을 사용하여 함수가 두 버전 간에 트래픽을 이동하도록 구성되지 않았는지 확인합니다.
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/) AWS Lambda 콘솔을 엽니다.
1. 왼쪽 창에서 **함수**를 선택합니다.
1. CodeDeploy 배포에 있는 Lambda 함수의 이름을 선택합니다.
1. **Aliases**(별칭)에서 CodeDeploy 배포에 사용된 별칭을 선택한 다음 **Edit**(편집)을 선택합니다.
1. **Weighted alias**(가중치 기반 별칭)에서 **none**을 선택합니다. 이렇게 하면 트래픽의 백분율이나 가중치가 여러 버전으로 이동하도록 별칭이 구성되지 않습니다. **버전**에서 선택한 버전을 메모해 두십시오.
1. **저장**을 선택합니다.
1. CodeDeploy 콘솔을 열고 5단계의 드롭다운 메뉴에 표시된 버전의 배포를 시도합니다.
# 배포 그룹 관련 문제 해결
## 인스턴스에 배포 그룹의 일부로 태그를 지정해도 애플리케이션이 새 인스턴스로 자동으로 배포되지 않음
CodeDeploy는 새로 태그가 지정된 인스턴스로 애플리케이션을 자동으로 배포하지 않습니다. 배포 그룹에서 새 배포를 만들어야 합니다.
CodeDeploy를 사용하여 Amazon EC2 Auto Scaling 그룹의 새 EC2 인스턴스에 자동으로 배포할 수 있습니다. 자세한 내용은 [Amazon EC2 Auto Scaling과 CodeDeploy 통합](integrations-aws-auto-scaling.md) 단원을 참조하십시오.
# 인스턴스 문제 해결
**Topics**
+ [태그를 올바르게 설정해야 함](#troubleshooting-EC2-tags)
+ [AWS CodeDeploy 인스턴스에 에이전트를 설치하고 실행해야 합니다.](#troubleshooting-sds-agent)
+ [배포 중 인스턴스가 종료되면 최대 1시간 동안 배포에 실패하지 않음](#troubleshooting-one-hour-timeout)
+ [인스턴스에 대한 배포 실패를 조사하기 위해 로그 파일 분석](#troubleshooting-deploy-failures)
+ [실수로 삭제된 경우 새 CodeDeploy 로그 파일 만들기](#troubleshooting-create-new-log-file)
+ ["InvalidSignatureException - Signature expired: [time] is now earlier than [time]" 배포 오류 문제 해결](#troubleshooting-instance-time-failures)
## 태그를 올바르게 설정해야 함
[list-deployment-instances](https://docs.aws.amazon.com/cli/latest/reference/deploy/list-deployment-instances.html) 명령을 사용하여 배포에 사용되는 인스턴스에 태그가 올바르게 지정되었는지 확인합니다. 출력에서 EC2 인스턴스가 누락된 경우 EC2 콘솔을 사용하여 인스턴스에 대해 태그가 설정되었는지 확인합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [콘솔의 태그 작업](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console)을 참조하세요.
**참고**
인스턴스에 태그를 지정한 다음 즉시 CodeDeploy를 사용하여 해당 인스턴스에 애플리케이션을 배포하면 이 인스턴스가 배포에 포함되지 않을 수 있습니다. 이는 CodeDeploy가 태그를 읽으려면 몇 분 가량 걸릴 수 있기 때문입니다. 따라서 인스턴스에 태그를 지정하고 5분 이상 기다린 다음 해당 인스턴스에 배포하는 것이 좋습니다.
## AWS CodeDeploy 인스턴스에 에이전트를 설치하고 실행해야 합니다.
인스턴스에서 CodeDeploy 에이전트가 설치되어 실행 중인지 확인하려면 [CodeDeploy 에이전트가 실행 중인지 확인](codedeploy-agent-operations-verify.md) 단원을 참조하세요.
CodeDeploy 에이전트를 설치, 제거 또는 다시 설치하려면 [CodeDeploy 에이전트 설치](codedeploy-agent-operations-install.md) 단원을 참조하세요.
## 배포 중 인스턴스가 종료되면 최대 1시간 동안 배포에 실패하지 않음
CodeDeploy는 각 배포 수명 주기 이벤트가 완료될 때까지 실행되도록 1시간의 기간을 제공합니다. 이 기간은 길게 실행되는 스크립트에 충분한 시간입니다.
수명 주기 이벤트 진행 중 스크립트가 완료될 때까지 실행되지 않는 경우(예: 인스턴스 또는 CodeDeploy 에이전트가 종료된 경우)에는 최대 1시간 가량 지난 후 배포 상태가 Failed로 표시될 수 있습니다. 스크립트에 지정된 제한 시간이 1시간보다 짧은 경우에도 마찬가지입니다. 이는 인스턴스가 종료되면 CodeDeploy 에이전트도 종료되어 스크립트를 더 이상 처리하지 못하기 때문입니다.
그러나 인스턴스가 수명 주기 이벤트 사이에 종료되거나 첫 번째 수명 주기 이벤트 단계 시작 전에 종료되면 불과 5분 뒤에 시간 초과가 발생합니다.
## 인스턴스에 대한 배포 실패를 조사하기 위해 로그 파일 분석
배포의 인스턴스 상태가 `Succeeded` 이외의 다른 상태이면 배포 로그 파일을 검토해 문제를 식별할 수 있습니다. 배포 로그 데이터에 액세스하는 방법은 [CodeDeploy EC2/온프레미스 배포에 대한 로그 데이터 보기](deployments-view-logs.md) 단원을 참조하세요.
## 실수로 삭제된 경우 새 CodeDeploy 로그 파일 만들기
인스턴스에서 배포 로그 파일을 실수로 삭제한 경우 CodeDeploy는 대체 로그 파일을 만들지 않습니다. 새 로그 파일을 만들려면 인스턴스에 로그인한 후 다음 명령을 실행합니다.
**Amazon Linux, Ubuntu Server 또는 RHEL 인스턴스의 경우**, 다음 명령을 아래의 순서대로 한 번에 하나씩 실행합니다.
```
systemctl stop codedeploy-agent
```
```
systemctl start codedeploy-agent
```
**Windows Server 인스턴스**:
```
powershell.exe -Command Restart-Service -Name codedeployagent
```
## "InvalidSignatureException - Signature expired: [time] is now earlier than [time]" 배포 오류 문제 해결
CodeDeploy는 작업을 수행하기 위해 정확한 시간 참조가 필요합니다. 인스턴스의 날짜와 시간이 잘못 설정되어 있으면 배포 요청의 서명 날짜와 일치하지 않아 CodeDeploy가 해당 요청을 거부합니다.
잘못된 시간 설정과 관련된 배포 실패를 피하려면 다음 항목을 참조하세요.
+ [Linux 인스턴스의 시간 설정](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html)
+ [Windows 인스턴스에 대한 시간 설정](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/windows-set-time.html)
# GitHub 토큰 문제 해결
## 유효하지 않은 GitHub OAuth 토큰
2017년 6월 이후에 만든 CodeDeploy 애플리케이션은 각 AWS 리전에 GitHub OAuth 토큰을 사용합니다. 특정 AWS 리전에 연결된 토큰을 사용하면 GitHub 리포지토리에 액세스할 수 있는 CodeDeploy 애플리케이션을 더 잘 제어할 수 있습니다.
GitHub 토큰 오류가 발생하면 현재 유효하지 않은 이전 토큰일 수 있습니다.
**유효하지 않은 GitHub OAuth 토큰 문제를 해결하려면**
1. 다음 방법 중 하나를 사용하여 이전 토큰을 제거합니다.
+ API를 사용하여 이전 토큰을 삭제하려면 [DeleteGitHubAccountToken](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_DeleteGitHubAccountToken.html)을 사용합니다.
+ AWS Command Line Interface를 사용하여 이전 토큰을 제거하려면
1. 토큰이 있는 컴퓨터로 이동합니다.
1. 이 컴퓨터에 AWS CLI 가 설치되어 있는지 확인합니다. 설치 지침은 *AWS Command Line Interface 사용 설명서*에서 [AWS CLI설치, 업데이트 및 제거](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)를 참조하세요.
1. 토큰이 있는 컴퓨터에서 다음 명령을 입력합니다.
**aws delete-git-hub-account-token**
명령 구문에 대한 세부 정보는 [delete-git-hub-account-token](https://docs.aws.amazon.com/cli/latest/reference/deploy/delete-git-hub-account-token.html)을 참조하세요.
1. 새 OAuth 토큰을 추가합니다. 자세한 내용은 [GitHub와 CodeDeploy 통합](integrations-partners-github.md) 단원을 참조하십시오.
## GitHub OAuth 토큰 최대 수 초과
CodeDeploy 배포를 생성할 때 허용되는 GitHub 토큰의 최대 수는 10개입니다. GitHub OAuth 토큰에 대한 오류가 발생하면 토큰 수가 10개 이하인지 확인하세요. 토큰이 10개가 넘으면 가장 오래된 토큰이 무효해집니다. 예를 들어 토큰이 11개이면 제일 처음에 만든 토큰이 무효해집니다. 토큰이 12개이면 처음에 만든 토큰 2개가 무효해집니다. CodeDeploy API를 사용하여 오래 된 토큰을 삭제하는 방법은 [ DeleteGitHubAccountToken](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_DeleteGitHubAccountToken.html)을 참조하세요.
# Amazon EC2 Auto Scaling 문제 해결
**Topics**
+ [일반적인 Amazon EC2 Auto Scaling 문제 해결](#troubleshooting-auto-scaling-general)
+ [“CodeDeployRole은 AmazonAutoScaling” 오류 AWS 서비스에서 작업을 수행할 수 있는 권한을 부여하지 않습니다.](#troubleshooting-auto-scaling-permissions-error)
+ [개정 버전을 배포하기 전에 Amazon EC2 Auto Scaling 그룹의 인스턴스가 계속해서 프로비저닝 및 종료됨](#troubleshooting-auto-scaling-provision-termination-loop)
+ [Amazon EC2 Auto Scaling 인스턴스를 종료 또는 재부팅하면 배포에 실패할 수 있음](#troubleshooting-auto-scaling-reboot)
+ [단일 Amazon EC2 Auto Scaling 그룹으로 여러 배포 그룹 연결 피하기](#troubleshooting-multiple-depgroups)
+ [Amazon EC2 Auto Scaling 그룹의 EC2 인스턴스를 시작하지 못하고 "하트비트 제한 시간” 오류 발생](#troubleshooting-auto-scaling-heartbeat)
+ [일치하지 않는 Amazon EC2 Auto Scaling 수명 주기 후크로 인해 Amazon EC2 Auto Scaling 그룹에 대한 자동 배포가 중지되거나 실패할 수 있습니다.](#troubleshooting-auto-scaling-hooks)
+ [“배포 그룹에 대한 인스턴스를 찾을 수 없어서 배포에 실패했습니다.” 오류](#troubleshooting-deployment-failed-because-no-instances-found)
## 일반적인 Amazon EC2 Auto Scaling 문제 해결
Amazon EC2 Auto Scaling 그룹에서 EC2 인스턴스로의 배포에 실패할 수 있는 원인은 다음과 같습니다.
+ **Amazon EC2 Auto Scaling은 EC2 인스턴스를 계속해서 시작하고 종료합니다.** CodeDeploy가 애플리케이션 수정을 자동으로 배포할 수 없는 경우 Amazon EC2 Auto Scaling은 EC2 인스턴스를 계속해서 시작하고 종료합니다.
CodeDeploy 배포 그룹에서 Amazon EC2 Auto Scaling 그룹을 연결 해제하거나 원하는 수의 인스턴스가 현재 인스턴스 개수와 일치하도록(따라서 Amazon EC2 Auto Scaling에서 EC2 인스턴스를 더 이상 시작할 수 없도록) Amazon EC2 Auto Scaling 그룹의 구성을 변경합니다. 자세한 내용은 [CodeDeploy에서 배포 그룹 설정 변경](deployment-groups-edit.md) 또는 [Amazon EC2 Auto Scaling의 수동 확장](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-manual-scaling.html)을 참조하세요.
+ **CodeDeploy 에이전트가 응답하지 않습니다.** EC2 인스턴스가 시작된 직후 실행되는 초기화 스크립트(예: cloud-init 스크립트)가 한 시간 이상 실행되는 경우 CodeDeploy 에이전트가 설치되지 않았을 수 있습니다. CodeDeploy는 CodeDeploy 에이전트가 보류 중인 배포에 대한 응답에 대해 1시간의 제한 시간을 둡니다. 이 문제를 해결하려면 초기화 스크립트를 CodeDeploy 애플리케이션 수정버전으로 합니다.
+ **Amazon EC2 Auto Scaling 그룹의 EC2 인스턴스가 배포 중에 재부팅됩니다.** EC2 인스턴스가 배포 중 재부팅되거나 배포 명령 처리 중 CodeDeploy 에이전트가 종료되면 배포에 실패할 수 있습니다. 자세한 내용은 [Amazon EC2 Auto Scaling 인스턴스를 종료 또는 재부팅하면 배포에 실패할 수 있음](#troubleshooting-auto-scaling-reboot) 단원을 참조하십시오.
+ **여러 애플리케이션 개정 버전이 Amazon EC2 Auto Scaling 그룹의 동일한 EC2 인스턴스에 동시에 배포됩니다.** 배포 중 하나에 실행하는 데 몇 분 이상 걸리는 스크립트가 있는 경우 Amazon EC2 Auto Scaling 그룹의 동일한 EC2 인스턴스로 여러 애플리케이션 개정 버전 배포에 실패할 수 있습니다. 여러 애플리케이션 개정 버전을 Amazon EC2 Auto Scaling 그룹의 동일한 EC2 인스턴스에 배포하지 마세요.
+ **Amazon EC2 Auto Scaling 그룹의 일부로 실행된 새 EC2 인스턴스에 대한 배포에 실패합니다.** 이 시나리오에서 배포 스크립트를 실행하면 Amazon EC2 Auto Scaling 그룹에서 EC2 인스턴스가 시작되지 않을 수 있습니다. (Amazon EC2 Auto Scaling 그룹의 다른 EC2 인스턴스는 정상적으로 실행되는 것처럼 보일 수 있습니다.) 이 문제를 해결하려면 먼저 다른 모든 스크립트가 완벽한지 확인해야 합니다.
+ **CodeDeploy 에이전트는 AMI에 포함되지 않습니다. **명령을 사용하여 새 인스턴스를 시작하는 동안 CodeDeploy 에이전트를 **cfn-init** 설치하는 경우 CloudFormation 템플릿의 `cfn-init` 섹션 끝에 에이전트 설치 스크립트를 배치합니다.
+ **CodeDeploy 에이전트가 AMI에 포함됨**: 인스턴스 생성 시 에이전트의 상태가 `Stopped`가 되도록 AMI를 구성한 다음 `cfn-init` 스크립트 라이브러리의 최종 단계로 에이전트를 시작하는 스크립트를 포함합니다.
## “CodeDeployRole은 AmazonAutoScaling” 오류 AWS 서비스에서 작업을 수행할 수 있는 권한을 부여하지 않습니다.
시작 템플릿으로 생성된 Auto Scaling 그룹을 사용하는 배포는 다음 권한을 필요로 합니다. 이는 `AWSCodeDeployRole` AWS 관리형 정책에서 부여한 권한에 추가됩니다.
+ `EC2:RunInstances`
+ `EC2:CreateTags`
+ `iam:PassRole`
이러한 권한이 없다면 이 오류가 표시됩니다. 자세한 내용은 [튜토리얼: CodeDeploy를 사용하여 Auto Scaling 그룹에 애플리케이션 배포](tutorials-auto-scaling-group.md), [Auto Scaling 그룹에 대한 시작 템플릿 생성](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-launch-template.html) 및 **Amazon EC2 Auto Scaling 사용 설명서의 [권한](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-templates.html#launch-templates-permissions)을 참조하세요.
## 개정 버전을 배포하기 전에 Amazon EC2 Auto Scaling 그룹의 인스턴스가 계속해서 프로비저닝 및 종료됨
오류로 인해 Amazon EC2 Auto Scaling 그룹의 새로 프로비저닝된 인스턴스로 성공적인 배포에 실패할 수 있습니다. 그 결과, 정상 인스턴스와 성공한 인스턴스가 없습니다. 배포를 실행하거나 성공적으로 완료할 수 없기 때문에 인스턴스가 생성 직후에 종료됩니다. 그런 다음 Amazon EC2 Auto Scaling 그룹 구성으로 인해 최소 정상 호스트 요구 사항을 충족하기 위한 또 다른 인스턴스 배치가 프로비저닝됩니다. 이 배치 역시 종료되고 이러한 주기가 계속 반복됩니다.
가능한 원인은 다음과 같습니다.
+ Amazon EC2 Auto Scaling 그룹 상태 확인에 실패했습니다.
+ 애플리케이션 수정의 오류
이 문제를 해결하려면 다음 단계를 수행하세요.
1. Amazon EC2 Auto Scaling 그룹에 속하지 않는 EC2 인스턴스를 수동으로 생성합니다. 고유한 EC2 인스턴스 태그로 인스턴스에 태그를 지정합니다.
1. 새 인스턴스를 영향을 받는 배포 그룹에 추가합니다.
1. 배포 그룹에 오류가 없는 새 애플리케이션 수정을 배포합니다.
Amazon EC2 Auto Scaling 그룹의 이후 인스턴스에 애플리케이션 수정 버전을 배포하라는 메시지를 Amazon EC2 Auto Scaling 그룹에 표시합니다.
**참고**
배포가 성공했는지 확인한 후 AWS 계정에 지속적인 요금이 부과되지 않도록 생성한 인스턴스를 삭제합니다.
## Amazon EC2 Auto Scaling 인스턴스를 종료 또는 재부팅하면 배포에 실패할 수 있음
EC2 인스턴스가 Amazon EC2 Auto Scaling을 통해 시작된 다음에 인스턴스가 종료 또는 재부팅된 경우, 다음과 같은 이유로 해당 인스턴스에 대한 배포가 실패할 수 있습니다.
+ 진행 중인 배포에서 축소 이벤트 또는 기타 모든 종료 이벤트로 인해 인스턴스가 Amazon EC2 Auto Scaling 그룹에서 분리된 다음 종료됩니다. 배포를 완료할 수 없기 때문에 배포에 실패합니다.
+ 인스턴스가 재부팅되지만 시작되는 데에는 5분 이상 걸립니다. CodeDeploy는 이것을 시간 초과로 처리합니다. 이 서비스에서 인스턴스에 대한 현재 및 이후 배포에 모두 실패합니다.
이 문제를 해결하려면:
+ 일반적으로, 인스턴스가 종료 또는 재부팅되기 전에 모든 배포가 완료되어야 합니다. 일반적으로, 인스턴스가 시작 또는 재부팅된 후 모든 배포가 시작됩니다.
+ Amazon EC2 Auto Scaling 구성에 대해 Windows Server 기본 Amazon Machine Image(AMI)를 지정하고 EC2Config 서비스를 사용해 인스턴스의 컴퓨터 이름을 설정하는 경우 배포에 실패할 수 있습니다. 이 문제를 해결하려면 Windows Server 기본 AMI에서 **EC2 서비스 속성(Ec2 Service Properties)**의 **일반(General)** 탭에서 **컴퓨터 이름 설정(Set Computer Name)**을 삭제합니다. 이 확인란을 선택 해제하면 해당 Windows Server 기본 AMI로 시작된 모든 새 WindowsServer Amazon EC2 Auto Scaling 인스턴스에 대해 이러한 동작이 비활성화됩니다. 이 동작이 비활성화된 WindowsServer Amazon EC2 Auto Scaling 인스턴스의 경우에는 이 확인란의 선택을 취소할 필요가 없습니다. 인스턴스가 재부팅된 후 실패한 배포를 인스턴스에 다시 부팅하기만 하면 됩니다.
## 단일 Amazon EC2 Auto Scaling 그룹으로 여러 배포 그룹 연결 피하기
모범 사례에 따라, 각 Amazon EC2 Auto Scaling 그룹에 배포 그룹을 하나만 연결하는 것이 좋습니다.
이는 Amazon EC2 Auto Scaling이 여러 배포 그룹과 연결된 후크를 보유한 인스턴스를 확장하는 경우 모든 후크에 대한 알림을 한 번에 보내기 때문입니다. 이로 인해 각 인스턴스에 대한 여러 배포가 동시에 시작됩니다. 여러 배포가 명령을 CodeDeploy 에이전트에 동시에 전달하면, 수명 주기 이벤트와 배포 시작 또는 이전 수명 주기 이벤트 종료 간의 5분 시간제한에 도달할 수 있습니다. 이렇게 되면 배포 프로세스가 예상대로 실행 중이더라도 배포에 실패하게 됩니다.
**참고**
수명 주기 이벤트의 스크립트에 대한 기본 제한 시간은 30분입니다. AppSpec 파일에서 제한 시간을 다른 값으로 변경할 수 있습니다. 자세한 내용은 [EC2 온프레미스 배포용 AppSpec 파일 추가](application-revisions-appspec-file.md#add-appspec-file-server) 단원을 참조하십시오.
동시에 두 개 이상의 배포 시도가 실행되는 경우 배포가 수행되는 순서를 제어할 수 없습니다.
마지막으로 인스턴스에 대한 배포에 실패하면 Amazon EC2 Auto Scaling은 즉시 해당 인스턴스를 종료합니다. 첫 번째 인스턴스가 종료되면 나머지 실행 중인 배포가 실패로 중단되기 시작합니다. CodeDeploy는 CodeDeploy 에이전트가 대기 중인 배포에 대해 응답하는데 1시간의 제한 시간을 두고 있기 때문에 각 인스턴스에서 제한 시간 초과가 발생하는 데 최대 60분이 걸릴 수 있습니다.
Amazon EC2 Auto Scaling에 대한 자세한 내용은 [세부 정보: CodeDeploy 및 Amazon EC2 Auto Scaling 통합](https://aws.amazon.com/blogs/devops/under-the-hood-aws-codedeploy-and-auto-scaling-integration/)을 참조하세요.
## Amazon EC2 Auto Scaling 그룹의 EC2 인스턴스를 시작하지 못하고 "하트비트 제한 시간” 오류 발생
Amazon EC2 Auto Scaling 그룹이 새 EC2 인스턴스를 시작하지 못하고 다음과 유사한 메시지가 생성될 수 있습니다.
`Launching a new EC2 instance . Status Reason: Instance failed to complete user's Lifecycle Action: Lifecycle Action with token was abandoned: Heartbeat Timeout`.
이 메시지는 일반적으로 다음 중 하나를 나타냅니다.
+ AWS 계정과 연결된 최대 동시 배포 수에 도달했습니다. 배포 한도에 대한 자세한 내용은 [CodeDeploy 할당량](limits.md) 단원을 참조하세요.
+ Auto Scaling 그룹이 너무 많은 EC2 인스턴스를 너무 빨리 시작하려고 했습니다. 각 새 인스턴스에 대한 [RecordLifecycleActionHeartbeat](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_RecordLifecycleActionHeartbeat.html) 또는 [CompleteLifecycleAction](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_CompleteLifecycleAction.html) API 호출이 제한되었습니다.
+ CodeDeploy의 애플리케이션과 연결된 배포 그룹이 업데이트 또는 삭제되기 전에 이러한 애플리케이션이 삭제되었습니다.
애플리케이션 또는 배포 그룹을 삭제하면 CodeDeploy는 해당 애플리케이션 또는 배포 그룹과 연결된 Amazon EC2 Auto Scaling 후크를 모두 정리하려고 하지만 일부 후크가 남아 있을 수 있습니다. 명령을 실행하여 배포 그룹을 삭제하는 경우 남아있는 후크가 출력으로 반환됩니다. 하지만 명령을 실행하여 애플리케이션을 삭제할 경우에는 남아있는 후크가 출력 화면에 표시되지 않습니다.
따라서 애플리케이션을 삭제하기 전에 애플리케이션과 연결된 배포 그룹을 모두 삭제하는 것이 모범 사례입니다. 명령으로 출력된 결과를 보고 수동으로 삭제해야 하는 수명 주기 후크를 식별할 수 있습니다.
"Hearbeat Timeout" 오류 메시지가 표시되면 남아 있는 수명 주기 후크가 원인인지 확인하여 다음과 같이 문제를 해결할 수 있습니다.
1. 다음 중 하나를 수행하세요.
+ [delete-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/delete-deployment-group.html) 명령을 호출하여 하트비트 제한 시간 초과를 일으키는 Auto Scaling 그룹과 연결된 배포 그룹을 삭제합니다.
+ null이 아닌 빈 Auto Scaling 그룹 이름 목록을 사용하여 [update-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/update-deployment-group.html) 명령을 호출해 모든 CodeDeploy-관리형 Auto Scaling 수명 주기 후크를 분리합니다.
예를 들어 다음 AWS CLI 명령을 입력합니다.
`aws deploy update-deployment-group --application-name my-example-app --current-deployment-group-name my-deployment-group --auto-scaling-groups`
또 다른 예로 Java와 함께 CodeDeploy API를 사용하는 경우 `UpdateDeploymentGroup`을 호출하고 `autoScalingGroups`를 `new ArrayList()`으로 설정합니다. 이것은 `autoScalingGroups`를 빈 목록으로 설정하고 기존 목록을 제거합니다. 기본값으로 `null`을 사용하지 마세요. 이렇게 하면 `autoScalingGroups`가 원하는 대로 유지되지 않기 때문입니다.
호출의 출력을 검사합니다. 출력에 Amazon EC2 Auto Scaling 수명 주기 후크 목록이 포함된 `hooksNotCleanedUp` 구조가 있는 경우, 남아 있는 수명 주기 후크가 있습니다.
1. [describe-lifecycle-hooks](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/describe-lifecycle-hooks.html) 명령을 호출하여, 시작에 실패하는 EC2 인스턴스에 연결된 Amazon EC2 Auto Scaling 그룹의 이름을 지정합니다. 출력에서 다음 중 하나를 찾습니다.
+ 1단계에서 식별한 `hooksNotCleanedUp` 구조에 해당하는 Amazon EC2 Auto Scaling 수명 주기 후크 이름.
+ Auto Scaling 그룹과 연결된 배포 그룹의 이름을 포함하는 Amazon EC2 Auto Scaling 수명 주기 후크 이름.
+ CodeDeploy 배포에 대한 하트비트 제한 시간을 발생시켰을 수 있는 Amazon EC2 Auto Scaling 수명 주기 후크 이름.
1. 후크가 2단계에서 나열된 범주 중 하나에 속하는 경우 [delete-lifecycle-hook](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/delete-lifecycle-hook.html) 명령을 사용하여 삭제합니다. 호출에서 Amazon EC2 Auto Scaling 그룹 및 수명 주기 후크를 지정합니다.
**중요**
2단계에서 설명한 대로 문제를 일으키는 후크만 삭제합니다. 실행 가능한 후크를 삭제하면 배포에 실패하거나 CodeDeploy가 확장된 EC2 인스턴스에 애플리케이션 개정 버전을 배포하지 못할 수 있습니다.
1. 원하는 Auto Scaling 그룹 이름으로 [update-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/update-deployment-group.html) 또는 [create-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment-group.html) 명령을 호출합니다. CodeDeploy는 새로운 UUID로 Auto Scaling 후크를 다시 설치합니다.
**참고**
CodeDeploy 배포 그룹에서 Auto Scaling 그룹을 분리하면 Auto Scaling 그룹에 대한 진행 중인 배포에 실패할 수 있으며 Auto Scaling 그룹에 의해 확장된 새 EC2 인스턴스는 CodeDeploy에서 애플리케이션 개정 버전을 받지 못합니다. CodeDeploy에서 Auto Scaling을 다시 사용하려면 Auto Scaling 그룹을 배포 그룹에 다시 연결하고 새 `CreateDeployment`를 호출하여 플릿 전체 배포를 시작할 수 있습니다.
## 일치하지 않는 Amazon EC2 Auto Scaling 수명 주기 후크로 인해 Amazon EC2 Auto Scaling 그룹에 대한 자동 배포가 중지되거나 실패할 수 있습니다.
Amazon EC2 Auto Scaling 및 CodeDeploy는 Amazon EC2 Auto Scaling 그룹에서 시작된 수명 주기 후크를 사용하여 어떤 애플리케이션 개정 버전을 어떤 EC2 인스턴스에 배포해야 할지 결정합니다. Amazon EC2 Auto Scaling 및 CodeDeploy에서 수명 주기 후크 및 이러한 후크에 대한 정보가 정확하게 일치하지 않는 경우 자동 배포가 중지 또는 실패할 수 있습니다.
Amazon EC2 Auto Scaling 그룹에 대한 배포에 실패하면 Amazon EC2 Auto Scaling 및 CodeDeploy의 수명 주기 후크 이름이 일치하는지 확인하세요. 그렇지 않은 경우 다음 AWS CLI 명령 호출을 사용합니다.
먼저, Amazon EC2 Auto Scaling 그룹 및 배포 그룹 둘 다에 대한 수명 주기 후크 이름 목록을 가져옵니다.
1. [describe-lifecycle-hooks](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/describe-lifecycle-hooks.html) 명령을 호출하여, CodeDeploy의 배포 그룹에 연결된 Amazon EC2 Auto Scaling 그룹의 이름을 지정합니다. 출력의 `LifecycleHooks` 목록에서 각 `LifecycleHookName` 값을 기록합니다.
1. [get-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-group.html) 명령을 호출하여, Amazon EC2 Auto Scaling 그룹에 연결된 배포 그룹의 이름을 지정합니다. 출력의 `autoScalingGroups` 목록에서 Amazon EC2 Auto Scaling 그룹 이름에 일치하는 각 항목의 이름 값을 찾아서 해당되는 `hook` 값을 기록합니다.
이제 두 수명 주기 후크 이름 세트를 비교합니다. 문자 대 문자로 정확하게 일치하는 경우에는 후크 이름이 문제가 아닙니다. 이 단원의 다른 부분에서 설명한 기타 Amazon EC2 Auto Scaling 문제 해결 단계를 시도해 볼 수 있습니다.
그러나 두 세트의 수명 주기 후크 이름이 문자 대 문자로 정확하게 일치하지 않는 경우에는 다음을 수행하세요.
1. **get-deployment-group** 명령 출력에 없는 수명 주기 후크 이름이 **describe-lifecycle-hooks** 명령 출력에 있으면 다음과 같이 합니다.
1. **describe-lifecycle-hooks** 명령 출력의 각 수명 주기 후크 이름에 대해 [delete-lifecycle-hook](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/delete-lifecycle-hook.html) 명령을 호출합니다.
1. [update-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/update-deployment-group.html) 명령을 호출하여, 원래 Amazon EC2 Auto Scaling 그룹의 이름을 지정합니다. CodeDeploy는 Amazon EC2 Auto Scaling 그룹에 새로운 대체 수명 주기 후크를 생성하고 수명 주기 후크를 배포 그룹과 연결합니다. 새 인스턴스가 Amazon EC2 Auto Scaling 그룹에 추가되면 자동 배포가 다시 시작되어야 합니다.
1. **describe-lifecycle-hooks** 명령 출력에 없는 수명 주기 후크 이름이 **get-deployment-group** 명령 출력에 있으면 다음과 같이 합니다.
1. [update-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/update-deployment-group.html) 명령을 호출하되, 원래 Amazon EC2 Auto Scaling 그룹의 이름은 지정하지 마세요.
1. **update-deployment-group** 명령을 다시 호출하여, 이번에는 원래 Amazon EC2 Auto Scaling 그룹의 이름을 지정합니다. CodeDeploy는 Amazon EC2 Auto Scaling 그룹에 누락된 수명 주기 후크를 다시 생성합니다. 새 인스턴스가 Amazon EC2 Auto Scaling 그룹에 추가되면 자동 배포가 다시 시작되어야 합니다.
두 세트의 수명 주기 후크 이름이 문자 대 문자로 정확하게 일치된 후에는 애플리케이션 수정을 다시 배포해 봅니다. 하지만 Amazon EC2 Auto Scaling 그룹에 추가된 새 인스턴스에만 배포합니다. Amazon EC2 Auto Scaling 그룹에 이미 있는 인스턴스에는 자동으로 배포되지 않습니다.
## “배포 그룹에 대한 인스턴스를 찾을 수 없어서 배포에 실패했습니다.” 오류
다음 CodeDeploy 오류가 표시되면 이 섹션을 읽어 보세요.
`The deployment failed because no instances were found for your deployment group. Check your deployment group settings to make sure the tags for your EC2 instances or Auto Scaling groups correctly identify the instances you want to deploy to, and then try again.`
가능한 원인은 다음과 같습니다.
1. 배포 그룹 설정에는 EC2 인스턴스, 온프레미스 인스턴스 또는 올바르지 않은 Auto Scaling 그룹에 대한 태그가 포함됩니다. 이 문제를 해결하려면 태그가 올바른지 확인하고 애플리케이션을 다시 배포합니다.
1. 배포가 시작된 후 플릿이 확장되었습니다. 이 시나리오에서는 플릿에 `InService` 상태에서 정상 인스턴스가 표시되지만 위의 오류도 표시됩니다. 이 문제를 해결하려면 애플리케이션을 다시 배포합니다.
1. Auto Scaling 그룹에 `InService` 상태의 인스턴스가 없습니다. 이 시나리오에서 플릿 전체 배포를 수행하려고 할 경우 CodeDeploy에 하나 이상의 인스턴스가 `InService` 상태여야 하므로 위의 오류 메시지와 함께 배포에 실패합니다. `InService` 상태의 인스턴스가 없는 데는 여러 가지 이유가 있을 수 있습니다. 몇 가지 이유는 다음과 같습니다.
+ Auto Scaling 그룹 크기를 `0`으로 예약(또는 수동으로 구성)했습니다.
+ Auto Scaling이 잘못된 EC2 인스턴스(예: EC2 인스턴스에 하드웨어 오류가 있음)를 감지하고 모두 취소하여 `InService` 상태의 인스턴스가 하나도 남지 않았습니다.
+ `0`에서 `1`로 확장 이벤트 중 CodeDeploy가 가장 최근 배포 후에 비정상 상태가 된, 이전에 성공한 개정 버전(*마지막으로 성공한 개정 버전*)을 배포했습니다. 이로 인해 확장된 인스턴스로의 배포가 실패하고 그 결과 Auto Scaling이 인스턴스를 취소하고 `InService` 상태의 인스턴스가 남지 않았습니다.
`InService` 상태의 인스턴스가 없는 경우, [To troubleshoot the error if there are no instances in the InService state](#ToTroubleshootIfNoInServiceInstances) 절차에 설명된 대로 문제를 해결합니다.
**InService 상태의 인스턴스가 없는 경우 오류를 해결하려면**
1. Amazon EC2 콘솔에서 **원하는 용량(Desired Capacity)** 설정을 확인합니다. 값이 0이면 양수로 설정합니다. 인스턴스가 `InService` 상태가 되어 배포가 성공할 때까지 기다립니다. 문제를 해결했으면 이 문제 해결 절차의 나머지 단계를 건너뛸 수 있습니다. **원하는 용량(Desired Capacity)** 설정에 대한 자세한 내용은 [Auto Scaling 그룹에 용량 제한 설정](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-capacity-limits.html)의 *Amazon EC2 Auto Scaling 사용 설명서*를 참조하세요.
1. Auto Scaling이 원하는 용량을 충족하기 위해 새 EC2 인스턴스를 계속 시작하려고 시도하지만 확장을 수행할 수 없는 경우, 일반적으로 Auto Scaling 수명 주기 후크가 실패하기 때문입니다. 이 문제는 다음과 같이 해결합니다.
1. 어떤 Auto Scaling 수명 주기 후크 이벤트가 실패하는지 확인하려면 Amazon EC2 Auto Scaling 사용 설명서의 [Auto Scaling 그룹에 대한 크기 조정 활동 확인](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-verify-scaling-activity.html)을 참조하세요.
1. 실패한 후크의 이름이 `CodeDeploy-managed-automatic-launch-deployment-hook-DEPLOYMENT_GROUP_NAME`인 경우, CodeDeploy로 이동하여 배포 그룹을 찾은 다음 Auto Scaling에서 시작된 실패한 배포를 찾습니다. 그런 다음 배포에 실패한 이유를 조사합니다.
1. 배포가 실패한 이유(예: CloudWatch 경보가 발생한 경우)를 이해하고 개정을 변경하지 않고 문제를 해결할 수 있다면 지금 바로 그렇게 합니다.
1. 조사 후 CodeDeploy의 *마지막으로 성공한 개정*이 더 이상 정상적이지 않고 Auto Scaling 그룹에 정상 인스턴스가 0개로 나타난다면 배포 교착 시나리오 상황인 것입니다. 이 문제를 해결하려면 Auto Scaling 그룹에서 CodeDeploy의 수명 주기 후크를 일시적으로 제거한 다음 후크를 다시 설치하고 새로운 정상 개정을 다시 배포하여 비정상적인 CodeDeploy 개정을 수정해야 합니다. 지침은 다음 섹션을 참조하세요.
+ [To fix the deployment deadlock issue (CLI)](#ToFixDeployDeadlockCLI)
+ [To fix the deployment deadlock issue (console)](#ToFixDeployDeadlockConsole)
**배포 교착 상태 문제를 해결하려면(CLI)**
1. (선택 사항) 이 문제를 해결하는 동안 예기치 않은 배포가 발생하지 않도록 CodeDeploy 오류를 일으키는 CI/CD 파이프라인을 차단합니다.
1. 현재 Auto Scaling **DesiredCapacity** 설정에 유의합니다.
`aws autoscaling describe-auto-scaling-groups --auto-scaling-group-name ASG_NAME`
이 절차의 끝부분에서 이 숫자로 다시 크기를 조정해야 할 수도 있습니다.
1. Auto Scaling **DesiredCapacity** 설정을 `1`로 설정합니다. 원하는 용량이 `1`보다 큰 경우 시작할 수 있는 선택 사항입니다 이 설정을 `1`로 줄이면 인스턴스가 나중에 프로비저닝하고 배포하는 데 걸리는 시간이 단축되어 문제 해결 속도가 빨라집니다. Auto Scaling에서 원하는 용량이 원래대로 `0`으로 설정된 경우, `1`로 늘려야 합니다. 이 변경은 필수입니다.
aws autoscaling set-desired-capacity --auto-scaling-group-name *ASG\$1NAME* --desired-capacity 1
**참고**
이 절차의 나머지 단계에서는 **DesiredCapacity**를 `1`로 설정했다고 가정합니다.
이때 Auto Scaling은 하나의 인스턴스로 크기를 조정하려고 시도합니다. 그런 다음 CodeDeploy가 추가한 후크가 여전히 존재하기 때문에 CodeDeploy가 배포를 시도하고, 이 배포가 실패하고, Auto Scaling이 인스턴스를 취소하고, Auto Scaling이 원하는 용량에 도달하기 위해 인스턴스를 다시 시작하려고 시도하고, 다시 실패합니다. 즉, 취소와 재실행이 반복되는 상태인 것입니다.
1. 배포 그룹에서 Auto Scaling 그룹의 등록을 취소합니다.
**주의**
다음 명령은 소프트웨어가 없는 새 EC2 인스턴스를 시작합니다. 명령을 실행하기 전에 소프트웨어를 실행하지 않는 Auto Scaling `InService` 인스턴스가 허용되는지 확인합니다. 예를 들어, 인스턴스에 연결된 로드 밸런서가 소프트웨어 없이 이 호스트로 트래픽을 전송하지 않는지 확인합니다.
**중요**
아래 표시된 CodeDeploy 명령을 사용하여 후크를 제거합니다. CodeDeploy에서 제거를 인식하지 못하므로 Auto Scaling 서비스를 통해 후크를 제거하지 마세요.
`aws deploy update-deployment-group --application-name APPLICATION_NAME --current-deployment-group-name DEPLOYMENT_GROUP_NAME --auto-scaling-groups`
이 명령을 실행하면 다음과 같은 문제가 발생합니다.
1. CodeDeploy가 배포 그룹에서 Auto Scaling 그룹의 등록을 취소합니다.
1. CodeDeploy가 Auto Scaling 그룹의 Auto Scaling 수명 주기 후크를 제거합니다.
1. 배포가 실패한 원인인 후크가 더 이상 존재하지 않으므로 Auto Scaling은 기존 EC2 인스턴스를 취소하고 즉시 새 인스턴스를 시작하여 원하는 용량으로 크기를 조정합니다. 새 인스턴스 곧 `InService` 상태로 변경됩니다. 새 인스턴스에는 소프트웨어가 포함되어 있지 않습니다.
1. EC2 인스턴스가 `InService` 상태가 될 때까지 기다립니다. 이를 확인하려면 다음 명령을 사용합니다.
`aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names ASG_NAME --query AutoScalingGroups[0].Instances[*].LifecycleState`
1. EC2 인스턴스에 후크를 다시 추가합니다.
**중요**
아래 표시된 CodeDeploy 명령을 사용하여 후크를 추가합니다. CodeDeploy에서 추가가 인식되지 않으므로 Auto Scaling 서비스를 사용하여 후크를 추가하지 마세요.
`aws deploy update-deployment-group --application-name APPLICATION_NAME --current-deployment-group-name DEPLOYMENT_GROUP_NAME --auto-scaling-groups ASG_NAME`
이 명령을 실행하면 다음과 같은 문제가 발생합니다.
1. CodeDeploy EC2 인스턴스에 Auto Scaling 수명 주기 후크를 다시 설치합니다.
1. CodeDeploy Auto Scaling 그룹을 배포 그룹에 다시 등록합니다.
1. 정상 상태이고 사용하려는 Amazon S3 또는 GitHub 개정판을 사용하여 플릿 전체 배포를 생성합니다.
예를 들어 개정이 `httpd_app.zip` 객체 키를 사용하여 `my-revision-bucket`을 호출하는 Amazon S3 버킷의 .zip 파일인 경우 다음 명령을 입력합니다.
`aws deploy create-deployment --application-name APPLICATION_NAME --deployment-group-name DEPLOYMENT_GROUP_NAME --revision "revisionType=S3,s3Location={bucket=my-revision-bucket,bundleType=zip,key=httpd_app.zip}"`
이제 `InService` 인스턴스 1개가 Auto Scaling 그룹에 있으므로 배포는 정상 작동하며 더 이상 *배포 그룹에 대한 인스턴스를 찾을 수 없어서 배포에 실패했습니다* 오류가 표시되지 않습니다.
1. 다음은 이전에 Auto Scaling 그룹을 크기 조정한 경우, 배포가 성공한 후 원래 용량으로 다시 조정하는 방법입니다.
`aws autoscaling set-desired-capacity --auto-scaling-group-name ASG_NAME --desired-capacity ORIGINAL_CAPACITY`
**배포 교착 상태 문제를 해결하려면 (콘솔)**
1. (선택 사항) 이 문제를 해결하는 동안 예기치 않은 배포가 발생하지 않도록 CodeDeploy 오류를 일으키는 CI/CD 파이프라인을 차단합니다.
1. Amazon EC2 콘솔로 이동하여 Auto Scaling **원하는 용량(Desired capacity)** 설정을 확인합니다. 이 절차의 끝부분에서 이 숫자로 다시 크기를 조정해야 할 수도 있습니다. 이 설정을 찾는 방법에 대한 자세한 내용은 [Auto Scaling 그룹의 용량 제한 설정](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-capacity-limits.html)을 참조하세요.
1. 원하는 EC2 인스턴스 수를 `1`로 설정합니다.
원하는 용량이 처음부터 `1`보다 컸다면 이 설정은 선택 사항입니다. 이 설정을 `1`로 줄이면 인스턴스가 나중에 프로비저닝하고 배포하는 데 걸리는 시간이 단축되어 문제 해결 속도가 빨라집니다. Auto Scaling에 대해 **원하는 용량(Desired capacity)**이 원래 `0`으로 설정되어 있었다면 `1`로 늘려야 합니다. 이 변경은 필수입니다.
**참고**
이 절차의 나머지 단계에서는 **원하는 용량(Desired capacity)**을 `1`로 설정했다고 가정합니다.
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling Groups**(Auto Scaling 그룹)를 선택합니다.
1. 해당 리전을 선택합니다.
1. 문제가 있는 Auto Scaling 그룹으로 이동합니다.
1. **일반 세부 정보(General details)**에서 **편집(Edit)**을 선택합니다.
1. **원하는 용량(Desired capacity)**을 **1**로 설정합니다.
1. **업데이트**를 선택합니다.
1. 배포 그룹에서 Auto Scaling 그룹의 등록을 취소합니다.
**주의**
다음 하위 단계에서는 소프트웨어가 없는 새 EC2 인스턴스를 시작합니다. 명령을 실행하기 전에 소프트웨어를 실행하지 않는 Auto Scaling `InService` 인스턴스가 허용되는지 확인합니다. 예를 들어, 인스턴스에 연결된 로드 밸런서가 소프트웨어 없이 이 호스트로 트래픽을 전송하지 않는지 확인합니다.
1. [https://console.aws.amazon.com/codedeploy/](https://console.aws.amazon.com/codedeploy/)에서 CodeDeploy 콘솔을 엽니다.
1. 해당 리전을 선택합니다.
1. 탐색 창에서 **애플리케이션**을 선택합니다.
1. CodeDeploy 애플리케이션 이름을 선택합니다.
1. CodeDeploy 배포 그룹의 이름을 선택합니다.
1. **편집**을 선택합니다.
1. **환경 구성(Environment configuration)**에서 **Amazon EC2 Auto Scaling 그룹(Amazon EC2 Auto Scaling groups)**을 선택 해제합니다.
**참고**
환경 구성이 정의되어 있지 않으면 콘솔에서 구성을 저장할 수 없습니다. 확인을 우회하려면 호스트로 확인되지 않는 `EC2` 또는 `On-premises` 태그를 임시로 추가하세요. 태그를 추가하려면 **Amazon EC2 인스턴스(Amazon EC2 instances)**또는**온프레미스 인스턴스(On-premises instance)**를 선택하고 **EC2** 또는 **On-premises**의 태그 **Key(키)**를 추가하세요. 태그 **값(Value)**은 비워 둘 수 있습니다.
1. **변경 사항 저장**을 선택합니다.
이러한 하위 단계를 완료한 후 다음과 같은 상황이 발생합니다.
1. CodeDeploy가 배포 그룹에서 Auto Scaling 그룹의 등록을 취소합니다.
1. CodeDeploy가 Auto Scaling 그룹의 Auto Scaling 수명 주기 후크를 제거합니다.
1. 배포가 실패한 원인인 후크가 더 이상 존재하지 않으므로 Auto Scaling은 기존 EC2 인스턴스를 취소하고 즉시 새 인스턴스를 시작하여 원하는 용량으로 크기를 조정합니다. 새 인스턴스 곧 `InService` 상태로 변경됩니다. 새 인스턴스에는 소프트웨어가 포함되어 있지 않습니다.
1. EC2 인스턴스가 `InService` 상태가 될 때까지 기다립니다. 상태를 확인하는 방법은 다음과 같습니다.
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다.
1. 탐색 창에서 **Auto Scaling 그룹**을 선택합니다.
1. 사용자의 Auto Scaling 그룹을 선택합니다.
1. 콘텐츠 창에서 **인스턴스 관리(Instance Management)** 탭을 선택합니다.
1. **인스턴스(Instances)**에서 인스턴스 옆에 있는 **수명 주기(Lifecycle)** 열이 **InService**라고 표시되는지 확인합니다.
1. Auto Scaling 그룹을 등록 취소했을 때 사용한 방법으로 CodeDeploy 배포 그룹에 다시 등록합니다.
1. [https://console.aws.amazon.com/codedeploy/](https://console.aws.amazon.com/codedeploy/)에서 CodeDeploy 콘솔을 엽니다.
1. 해당 리전을 선택합니다.
1. 탐색 창에서 **애플리케이션**을 선택합니다.
1. CodeDeploy 애플리케이션 이름을 선택합니다.
1. CodeDeploy 배포 그룹의 이름을 선택합니다.
1. **편집**을 선택합니다.
1. **환경 구성(Environment configuration)**에서 **Amazon EC2 Auto Scaling 그룹(Amazon EC2 Auto Scaling groups)**을 선택하고 목록에서 사용자의 Auto Scaling 그룹을 선택합니다.
1. **Amazon EC2 인스턴스(Amazon EC2 instances)** 또는 **온프레미스 인스턴스(On-premises instances)**에서 추가한 태그를 찾아 제거합니다.
1. **Amazon EC2 인스턴스(Amazon EC2 instances)** 또는 **온프레미스 인스턴스(On-premises instances)** 옆에 있는 확인란을 선택 취소합니다.
1. **변경 사항 저장**을 선택합니다.
이 구성으로 Auto Scaling 그룹에 수명 주기 후크를 다시 설치합니다.
1. 정상 상태이고 사용하려는 Amazon S3 또는 GitHub 개정판을 사용하여 플릿 전체 배포를 생성합니다.
예를 들어 개정이 `httpd_app.zip` 객체 키를 사용하여 `my-revision-bucket`을 호출하는 Amazon S3 버킷의 .zip 파일인 경우 다음을 수행합니다.
1. CodeDeploy 콘솔의 **배포 그룹(Deployment Group)** 페이지에서 **배포 생성(Create deployment)**을 선택합니다.
1. **Revision type(수정 유형)**에서 **My application is stored in Amazon S3(내 애플리케이션은 Amazon S3에 저장됨)**를 선택합니다.
1. **개정 위치(Revision location)**는 `s3://my-revision-bucket/httpd_app.zip`을 선택합니다.
1. **개정 파일 형식(Revision file type)**은 `.zip`을 선택합니다.
1. **배포 만들기**를 선택합니다.
이제 `InService` 인스턴스 1개가 Auto Scaling 그룹에 있으므로 배포가 정상 작동하며 더 이상 “*배포 그룹에 대한 인스턴스를 찾을 수 없어서 배포에 실패했습니다.*” 오류가 표시되지 않습니다.
1. 다음은 이전에 Auto Scaling 그룹을 크기 조정한 경우, 배포가 성공한 후 원래 용량으로 다시 조정하는 방법입니다.
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 열고 탐색 창에서 **Auto Scaling Groups**(Auto Scaling 그룹)를 선택합니다.
1. 해당 리전을 선택합니다.
1. Auto Scaling 그룹으로 이동합니다.
1. **일반 세부 정보(General details)**에서 **편집(Edit)**을 선택합니다.
1. **원하는 용량(Desired capacity)**을 원래 값으로 다시 설정합니다.
1. **업데이트**를 선택합니다.
# AWS CodeDeploy의 오류 코드
이 단원에서는 CodeDeploy 오류에 대한 참조 정보를 제공합니다.
****
| 오류 코드 | 설명 |
| --- | --- |
| `AGENT_ISSUE` | CodeDeploy 에이전트의 문제로 인해 배포에 실패했습니다. 에이전트가 설치되어 이 배포 그룹의 모든 인스턴스에서 실행 중인지 확인하세요. 자세히 알아보기: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/error-codes.html) |
| `AUTO_SCALING_IAM_ROLE_PERMISSIONS` | 배포 그룹과 연결된 서비스 역할에 AWS 서비스에서 작업을 수행하는 데 필요한 권한이 없습니다. 자세히 알아보기: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/error-codes.html) |
| `HEALTH_CONSTRAINTS` | 너무 많은 개별 인스턴스가 배포에 실패했거나, 배포에 사용할 수 있는 정상 인스턴스가 너무 적거나, 배포 그룹의 일부 인스턴스에 문제가 발생하여 전체 배포가 실패했습니다. 자세히 알아보기: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/error-codes.html) |
| `HEALTH_CONSTRAINTS_INVALID` | 배포 구성에 정의된 최소 정상 인스턴스 수를 사용할 수 없으므로 배포를 시작할 수 없습니다. 배포 구성을 업데이트하여 필요한 정상 인스턴스 수를 줄이거나 이 배포 그룹의 인스턴스 수를 늘릴 수 있습니다. 자세히 알아보기: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/error-codes.html) |
| `IAM_ROLE_MISSING` | 배포 그룹에 대해 지정된 서비스 역할 이름을 가진 서비스 역할이 없으므로 배포에 실패했습니다. 올바른 서비스 역할 이름을 사용 중인지 확인하세요. 자세히 알아보기: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/error-codes.html) |
| `IAM_ROLE_PERMISSIONS` | CodeDeploy에 역할을 위임하는 데 필요한 권한이 없거나 사용 중인 IAM 역할에 AWS 서비스에서 작업을 수행할 수 있는 권한이 없습니다. 자세히 알아보기: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/error-codes.html) |
| `NO_INSTANCES` | 이는 다음 중 하나로 인해 발생할 수 있습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/error-codes.html) 자세히 알아보기: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/error-codes.html) |
| `OVER_MAX_INSTANCES` | 계정에 허용되는 것보다 더 많은 인스턴스가 배포 대상으로 지정되었기 때문에 배포에 실패했습니다. 이 배포의 대상 인스턴스 수를 줄이려면 이 배포 그룹에 대한 태그 설정을 업데이트하거나 대상 인스턴스 중 일부를 삭제합니다. 또는 한도 증가를 요청하려면 AWS Support에 문의하세요. 자세히 알아보기: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/error-codes.html) |
| `THROTTLED` | IAM 역할에 의해 AWS CodeDeploy에 허용되는 것보다 많은 요청이 만들어졌기 때문에 배포에 실패했습니다. . 요청 수를 줄이세요. 자세히 알아보기: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/error-codes.html) |
| `UNABLE_TO_SEND_ASG` | 배포 그룹이 Amazon EC2 Auto Scaling 그룹에서 올바르게 구성되지 않았기 때문에 배포에 실패했습니다. CodeDeploy 콘솔에서 배포 그룹에서 Amazon EC2 Auto Scaling 그룹을 삭제한 다음 다시 추가합니다. 자세히 알아보기: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/error-codes.html) |
## 관련 주제
[CodeDeploy 문제 해결](troubleshooting.md)