EC2/온프레미스 배포 문제 해결

참고

배포 프로세스 중 생성되는 로그 파일을 검토하면 다양한 배포 실패의 원인을 파악할 수 있습니다. 간소화를 위해 인스턴스별로 로그 파일을 보는 대신 Amazon CloudWatch Logs를 사용하여 중앙에서 로그 파일을 모니터링하는 것이 좋습니다. 자세한 내용은 CloudWatch Logs 콘솔에서 CodeDeploy 로그 보기를 참조하세요.

작은 정보

EC2/온프레미스 배포와 관련된 많은 문제 해결 작업을 자동화하는 런북은 AWS Systems Manager 자동화 런북 참조에서 AWSSupport-TroubleshootCodeDeploy를 참조하세요.

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의 Identity and Access Management(IAM) 단원을 참조하세요. 온프레미스 인스턴스는 Working with On-Premises Instances 단원을 참조하세요.

배포에 실패하고 메시지 "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, 알림: 버전 1.0.1.85 이전 CodeDeploy 호스트 에이전트 사용 중지 및 CodeDeploy 에이전트를 업데이트하십시오. 섹션을 참조하세요.

동일한 파일을 같은 인스턴스 위치로 배포 또는 다시 배포하려고 하면 실패하고 오류 "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/온프레미스 컴퓨팅 플랫폼의 배포 생성(콘솔) 및 기존 컨텐츠의 롤백 동작 단원을 참조하세요.

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 명령을 사용하여 배포 그룹 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 설명서에 자세히 설명된 것처럼 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

2. CodeDeploy 에이전트를 설치합니다. 자세한 내용은 에이전트를 설치합니다. CodeDeploy 섹션을 참조하세요.

CodeDeploy 에이전트가 이미 설치된 경우:

1. CodeDeploy 에이전트 시스템에서 다음 명령을 사용하여 LongPathsEnabled Windows 레지스트리 키를 활성화합니다.

   New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" 
   -Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force
   

2. 레지스트리 키 변경 사항을 적용하려면 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 사용 설명서의 상태 확인 구성 및 Elastic Load Balancing API 참조 버전 2012-06-01의 ConfigureHealthCheck을 참조하세요.

Application Load Balancers의 경우 Application Load Balancer 사용 설명서의 대상 그룹에 대한 상태 확인을 참조하세요.

네트워크 로드 밸런서의 경우 Network Load Balancer 사용 설명서의 대상 그룹에 대한 상태 확인을 참조하세요.

실패한 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 명령을 호출해도 됩니다.

이전에 성공한 배포에 포함된, 성공적으로 실행할 수 없는 스크립트가 실패의 원인인 경우 배포를 만들고 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 명령을 호출하고 --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 온프레미스 배포 전용) 및 배포 사전 조건 섹션을 참조하세요.

• 배포하려는 인스턴스가 하나의 AWS 리전(예: 미국 서부(오레곤)과 연결되어 있으나 애플리케이션 수정 버전이 포함된 Amazon S3 버킷이 다른 AWS 리전(예: 미국 동부(버지니아 북부)과 연결되어 있습니다. 애플리케이션 수정이 인스턴스와 동일한 AWS 리전과 연결된 Amazon S3 버킷에 있는지 확인하세요.

배포의 이벤트 세부 정보 페이지에 있는 Download bundle 행에서 로그 보기를 선택합니다. 또는 AWS CLI를 사용하여 get-deployment-instance 명령을 호출합니다. 오류가 발생하면 출력에 오류 코드 UnknownError 및 오류 메시지 not opened for reading과 함께 오류가 표시되어야 합니다.

이 오류가 발생한 이유를 확인하려면:

1. 하나 이상의 인스턴스에서 유선 로깅을 활성화한 후 애플리케이션 수정을 다시 배포합니다.

2. 유선 로깅 파일을 검사하여 오류를 찾습니다. 이 문제에 대한 일반적인 오류 메시지에는 "액세스 거부됨(access denied)"이라는 문구가 포함됩니다.

3. 로그 파일을 검사한 후에는 유선 로깅을 비활성화하여, 이후 인스턴스에서 출력에 일반 텍스트로 표시될 수 있는 민감한 정보의 양과 로그 파일의 크기를 줄이는 것이 좋습니다.

유선 로깅 파일을 찾아 유선 로깅을 활성화 및 비활성화하는 방법에 대한 자세한 내용은 CodeDeploy 에이전트 구성 참조의 :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 에이전트가 실행 중인지 확인하십시오. 단원을 참조하세요.

  인스턴스가 포트 443을 사용해서 CodeDeploy 또는 Amazon S3 퍼블릭 엔드포인트에 도달하지 못할 수 있습니다. 다음 중 하나를 시도하세요.

  • 퍼블릭 IP 주소를 인스턴스에 할당한 후 라우팅 테이블을 사용해 인터넷 액세스를 허용합니다. 이때 인스턴스에 연결된 보안 그룹이 포트 443을 통한 아웃바운드 액세스를 허용해야 합니다(HTTPS). 자세한 내용은 CodeDeploy 에이전트의 통신 프로토콜 및 포트 섹션을 참조하세요.

  • 인스턴스가 프라이빗 서브넷에 프로비저닝되어 있을 경우에는 라우팅 테이블에서 인터넷 게이트웨이가 아닌 NAT 게이트웨이를 사용합니다. 자세한 내용은 NAT 게이트웨이 단원을 참조하세요.

• CodeDeploy 서비스 역할은 권한이 필요하지 않을 수도 있습니다. CodeDeploy 서비스 역할을 구성하려면 2단계: CodeDeploy에 대한 서비스 역할 생성 단원을 참조하세요.

• HTTP 프록시를 사용할 때는 이 프록시를 CodeDeploy 에이전트 구성 파일의 :proxy_uri: 설정에서 지정해야 합니다. 자세한 내용은 CodeDeploy 에이전트 구성 참조 섹션을 참조하세요.

• 배포 인스턴스의 날짜 및 시간 서명이 배포 요청의 날짜 및 시간 서명과 일치하지 않을 수도 있습니다. CodeDeploy 에이전트 로그 파일에서 "Cannot reach InstanceService: Aws::CodeDeployCommand::Errors::InvalidSignatureException - Signature expired"와 유사한 오류 메시지가 있는지 찾습니다. 오류 메시지가 있다면 "InvalidSignatureException - Signature expired: [time] is now earlier than [time]" 배포 오류 문제 해결의 단계를 따르십시오. 자세한 내용은 CodeDeploy EC2/온프레미스 배포에 대한 로그 데이터 보기 섹션을 참조하세요.

• 인스턴스 실행 중 메모리 또는 하드 디스크 공간 부족으로 인해 CodeDeploy 에이전트가 실행을 멈췄을 수도 있습니다. 이때는 CodeDeploy 에이전트 구성에서 max_revisions 설정을 업데이트하여 인스턴스에 보관된 배포 수를 줄여 봅니다. EC2 인스턴스에서 배포 수를 줄인 후에도 문제가 지속되면 용량이 더 큰 인스턴스를 사용하는 것이 좋습니다. 예를 들어 인스턴스 유형이 t2.small이라면 t2.medium으로 바꿔 사용하세요. 자세한 내용은 에이전트가 설치한 파일 CodeDeploy , CodeDeploy 에이전트 구성 참조 및 인스턴스 유형 섹션을 참조하세요.

• 배포하려는 인스턴스에 IAM 인스턴스 프로파일이 연결되어 있지 않거나 IAM 인스턴스 프로파일이 필요한 권한 없이 연결되어 있을 수 있습니다.

  • IAM 인스턴스 프로파일이 인스턴스에 연결되어 있지 않다면 필요한 권한과 함께 인스턴스 프로파일을 생성하여 연결합니다.

  • IAM 인스턴스 프로파일이 이미 인스턴스에 연결되어 있다면 필요한 권한이 있는지 확인합니다.

  연결된 인스턴스 프로파일이 필요한 권한과 함께 구성되어 있는지 확인한 후 인스턴스를 다시 시작합니다. 자세한 내용은 4단계: Amazon EC2 인스턴스에 대한 IAM 인스턴스 프로파일 만들기 섹션과 Amazon EC2 사용 설명서에서 Amazon EC2의 IAM 역할을 참조하세요.

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