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

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

CodeDeploy 플러그인 CommandPoller 누락 보안 인증 오류

InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Missing credentials - please check if this instance was started with an IAM instance profile과 비슷한 오류 메시지가 수신되면 다음 중 한 가지가 원인일 수 있습니다.

IAM 인스턴스 프로필은 CodeDeploy 에이전트에게 Amazon S3와 CodeDeploy 통신하고 Amazon S3에서 개정을 다운로드할 수 있는 권한을 부여합니다. Amazon S3 EC2 인스턴스는 섹션을 참조하세요AWS CodeDeploy의 Identity and Access Management(IAM). 온프레미스 인스턴스는 Working with On-Premises Instances 단원을 참조하세요.

“PKCS7서명된 메시지 검증 실패” 메시지와 함께 배포 실패

이 오류 메시지는 인스턴스가 SHA-1 해시 알고리즘만 지원하는 CodeDeploy 에이전트 버전을 실행 중임을 나타냅니다. SHA-2 해시 알고리즘에 대한 지원은 2015년 11월에 릴리스된 CodeDeploy 에이전트 버전 1.0.1.854에 도입되었습니다. 2016년 10월 17일부터 1.0.1.854 이전의 CodeDeploy 에이전트 버전이 설치된 경우 배포가 실패합니다. 자세한 내용은 AWS 을 참조하여 SSL 인증서 , : 버전 1.0.1.85 이전의 호스트 에이전트 사용 중지 및 에 대한 SHA256해시 알고리즘으로 전환합니다 CodeDeploy 에이전트 업데이트. NOTICE CodeDeploy

동일한 파일을 같은 인스턴스 위치로 배포 또는 다시 배포하려고 하면 실패하고 오류 "The deployment failed because a specified file already exists at this location"이 표시됨

CodeDeploy 가 인스턴스에 파일을 배포하려고 하지만 이름이 같은 파일이 지정된 대상 위치에 이미 있는 경우 해당 인스턴스에 대한 배포가 실패할 수 있습니다. 다음과 같은 오류 메시지가 표시될 수 있습니다. “지정된 파일이 이미 이 위치에 있기 때문에 배포가 실패했습니다.location-name“.” 이는 각 배포 중에 CodeDeploy 먼저 정리 로그 파일에 나열된 이전 배포의 모든 파일을 삭제하기 때문입니다. 대상 설치 폴더에 이 정리 파일에 나열되지 않은 파일이 있는 경우 CodeDeploy 에이전트는 기본적으로 이를 오류로 해석하고 배포에 실패합니다.

이러한 오류를 피하려면 기본 동작을 배포 실패 이외의 옵션으로 지정하는 것이 가장 쉬운 방법입니다. 각 배포에 대해 배포에 실패하거나, 정리 파일에 나열되지 않은 파일을 덮어 쓰거나, 인스턴스에 이미 있는 파일을 보관하도록 선택할 수 있습니다.

예를 들어, 마지막 배포 후 인스턴스에 수동으로 파일을 배치했으나 다음 애플리케이션 수정에 이름이 동일한 파일을 추가한 경우 덮어쓰기 옵션이 유용합니다.

애플리케이션 수정 패키지에 추가하지 않고 다음 배포의 일부로 포함하려는 파일에 대해 보관 옵션을 선택할 수 있습니다. 보존 옵션은 애플리케이션 파일이 이미 프로덕션 환경에 있고 를 CodeDeploy 사용하여 처음 배포하려는 경우에도 유용합니다. 자세한 내용은 EC2/온프레미스 컴퓨팅 플랫폼 배포 생성(콘솔) 및 기존 컨텐츠의 롤백 동작 단원을 참조하세요.

The deployment failed because a specified file already exists at this location 배포 문제 해결

대상 배포 위치에서 가 감지하는 CodeDeploy 콘텐츠를 덮어쓰거나 보존하는 옵션을 지정하지 않기로 선택한 경우(또는 프로그래밍 명령에서 기존 콘텐츠를 처리하기 위한 배포 옵션을 지정하지 않은 경우) 오류 문제를 해결하도록 선택할 수 있습니다.

다음 정보는 콘텐츠를 보관 또는 덮어쓰도록 선택하지 않은 경우에만 적용됩니다.

이름과 위치가 동일한 파일을 재배포하려고 하면 애플리케이션 이름과 이전에 사용한 기본 배포 그룹 ID가 동일한 배포 그룹을 지정하면 재배포가 성공할 가능성이 높아집니다. 는 기본 배포 그룹 ID를 CodeDeploy 사용하여 재배포 전에 제거할 파일을 식별합니다.

다음과 같은 이유로 새 파일을 배포 또는 인스턴스의 같은 위치로 동일한 파일 다시 배포에 실패할 수 있습니다.

이러한 상황을 해결하려면 다음 중 하나를 수행하세요.

파일 경로가 길면 “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 에이전트가 아직 설치되지 않은 경우:

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

오래 실행되는 프로세스로 인해 배포에 실패할 수 있음

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

sleep.sh가 after-install.sh를 호출하면 가 를 sleep.sh 시작하고 3분(180초) 동안 실행되며, 이는 CodeDeploy 예상 시간(및 관계별로 )이 실행을 중지할 때까지 2분sleep.sh(120초after-install.sh) 경과한 시간입니다. 1분(60초)이 초과되면 는 예상대로 sleep.sh 계속 실행되더라도 AfterInstall 애플리케이션 수명 주기 이벤트에서 배포를 CodeDeploy 중지하고 실패합니다. 다음 오류가 표시됩니다.

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시간 배포 수명 주기 이벤트 제한 시간 동안 보류 상태로 유지될 수 있으며, 이후 는 이전과 같이 AfterInstall 애플리케이션 수명 주기 이벤트에서 배포를 CodeDeploy 중지하고 실패합니다.

에서 다음과 sleep.sh 같이 를 after-install.sh호출 CodeDeploy 합니다. 그러면 프로세스가 실행된 후 가 계속됩니다.

#!/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 Balancer 사용 설명서의 상태 확인 구성 및 Elastic Load Balancing API 참조 버전 2012-06-01ConfigureHealthCheck의 상태 확인을 참조하세요.

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

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

실패한 ApplicationStop BeforeBlockTraffic, 또는 AfterBlockTraffic 배포 수명 주기 이벤트 문제 해결

배포 중에 CodeDeploy 에이전트는 이전에 성공한 배포의 AppSpec 파일 AfterBlockTraffic 에서 BeforeBlockTraffic, 및 ApplicationStop에 지정된 스크립트를 실행합니다. (다른 모든 스크립트는 현재 배포의 AppSpec 파일에서 실행됩니다.) 이러한 스크립트 중 하나가 오류를 포함하고 있고 성공적으로 실행하지 않으면 배포에 실패할 수 있습니다.

이러한 실패의 가능한 원인은 다음과 같습니다.

CodeDeploy 콘솔을 사용하여 이러한 이벤트 중에 배포가 실패했을 수 있는 이유를 조사합니다. 배포의 세부 정보 페이지에서 [View events]를 선택합니다. 인스턴스의 세부 정보 페이지의 ApplicationStop, BeforeBlockTraffic또는 AfterBlockTraffic 행에서 로그 보기를 선택합니다. 또는 AWS CLI 를 사용하여 get-deployment-instance 명령을 호출합니다.

실패의 원인이 성공적으로 실행되지 않은 마지막 성공 배포의 스크립트인 경우 배포를 생성하고 ApplicationStop, BeforeBlockTraffic및 AfterBlockTraffic 실패를 무시하도록 지정합니다. 이렇게 하는 방법은 두 가지입니다.

그러면 애플리케이션 수정을 다시 배포하는 경우 이러한 3가지 수명 주기 이벤트 중 하나가 실패하더라도 배포는 계속 진행됩니다. 새 수정에 이러한 수명 주기 이벤트에 대한 수정된 스크립트가 포함되어 있으면 이러한 수정 사항을 적용하지 않아도 향후 배포에 성공할 수 있습니다.

를 사용하여 실패한 DownloadBundle 배포 수명 주기 이벤트 문제 해결 UnknownError: 읽기 위해 열리지 않음

Amazon S3에서 애플리케이션 개정을 배포하려고 하는데 배포 수명 주기 이벤트 중에 UnknownError: not opened for reading 오류와 함께 DownloadBundle 배포가 실패하는 경우:

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

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

와이어 로깅 파일을 찾고 와이어 로깅을 활성화 및 비활성화하는 방법에 대한 자세한 내용은 에이전트 구성 참조:log_aws_wire:의 섹션을 참조하세요. CodeDeploy

모든 수명 주기 이벤트를 건너뛰었을 때 문제 해결

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). 이때 몇 가지 가능한 원인과 해결책은 다음과 같습니다.

Windows PowerShell 스크립트는 PowerShell 기본적으로 Windows의 64비트 버전을 사용하지 않습니다.

배포의 일부로 실행되는 Windows PowerShell 스크립트가 64비트 기능에 의존하는 경우(예: 32비트 애플리케이션에서 허용하는 것보다 더 많은 메모리를 소비하거나 64비트 버전에서만 제공되는 라이브러리를 호출하기 때문에) 스크립트가 충돌하거나 예상대로 실행되지 않을 수 있습니다. 이는 기본적으로 가 32비트 버전의 Windows를 CodeDeploy 사용하여 애플리케이션 개정의 일부인 Windows PowerShell 스크립트를 실행 PowerShell 하기 때문입니다.

Windows 의 64비트 버전으로 실행해야 하는 스크립트의 시작 부분에 다음과 같은 코드를 추가합니다 PowerShell.

# 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