문제 해결 AWS CodeBuild

이 주제의 정보를 활용하면 문제를 식별, 진단 및 해결하는 데 도움이 됩니다. CodeBuild 빌드를 기록하고 모니터링하여 문제를 해결하는 방법을 알아보려면 을 참조하십시오로깅 및 모니터링.

Apache Maven 빌드가 잘못된 리포지토리의 아티팩트를 참조함

문제: Maven을 AWS CodeBuild제공된 Java 빌드 환경과 함께 사용하는 경우 Maven은 https://repo1.maven.org/maven2 의 안전한 중앙 Maven 리포지토리에서 빌드 및 플러그인 종속성을 가져옵니다. 빌드 프로젝트의 pom.xml 파일에 대신 사용할 다른 위치가 명시적으로 선언되어 있는 경우에도 이러한 문제가 발생합니다.

가능한 원인: CodeBuild -제공된 Java 빌드 환경에 빌드 환경 디렉터리에 사전 설치된 이름이 지정된 settings.xml 파일이 포함되어 있습니다. /root/.m2 이 settings.xml 파일에는 다음 선언이 포함되어 있는데, 이는 Maven이 항상 https://repo1.maven.org/maven2에 있는 보안된 중앙 Maven 리포지토리로부터 빌드 및 플러그인 종속성을 가져오도록 지시합니다.

<settings>
  <activeProfiles>
    <activeProfile>securecentral</activeProfile>
  </activeProfiles>
  <profiles>
    <profile>
      <id>securecentral</id>
      <repositories>
        <repository>
          <id>central</id>
          <url>https://repo1.maven.org/maven2</url>
          <releases>
            <enabled>true</enabled>
          </releases>
        </repository>
      </repositories>
      <pluginRepositories>
        <pluginRepository>
          <id>central</id>
          <url>https://repo1.maven.org/maven2</url>
          <releases>
            <enabled>true</enabled>
          </releases>
        </pluginRepository>
      </pluginRepositories>
    </profile>
  </profiles>
</settings>

권장 솔루션: 다음을 실행합니다.

1. 소스 코드에 settings.xml 파일을 추가합니다.

2. 이 settings.xml 파일에서, 이전 settings.xml 형식을 참고하여 Maven이 빌드 및 플러그인 종속성을 가져오게 하려는 다른 리포지토리를 선언합니다.

3. 빌드 프로젝트 install 단계에서 settings.xml 파일을 빌드 환경의 디렉터리에 CodeBuild 복사하도록 지시하세요. /root/.m2 예를 들어 이러한 작업을 수행하는 buildspec.yml 파일의 다음 코드 조각을 고려해 보십시오.

   version 0.2
   
   phases:
     install:
       commands:
         - cp ./settings.xml /root/.m2/settings.xml

기본적으로 루트로 실행되는 빌드 명령

문제: 루트 사용자로 빌드 명령을 AWS CodeBuild 실행합니다. 관련 빌드 이미지의 Dockerfile이 USER 명령을 다른 사용자에게 설정하는 경우에도 이러한 문제가 발생합니다.

원인: 기본적으로 모든 빌드 명령을 루트 사용자로 CodeBuild 실행합니다.

권장 솔루션: 없음.

파일 이름에 미국 영어 이외의 문자가 있으면 빌드가 실패할 수 있음

문제: 영어 이외의 문자(예: 중국어 문자)가 포함된 파일 이름을 사용하는 빌드를 실행하면 빌드가 실패합니다.

가능한 원인: 에서 AWS CodeBuild 제공하는 빌드 환경의 기본 로케일이 로 POSIX 설정되어 있습니다. POSIX현지화 설정은 미국 이외의 국가를 포함하는 파일 CodeBuild 이름과 호환되지 않습니다. 영문자이므로 관련 빌드가 실패할 수 있습니다.

권장 솔루션: 다음 명령을 buildspec 파일의 pre_build 섹션에 추가합니다. 이러한 명령을 사용하면 빌드 환경에서 현지화 설정에 미국 영어 UTF-8 형식을 사용하므로 미국 외 언어를 포함하는 파일 CodeBuild 이름과 호환성이 더 높습니다. 영어 문자.

Ubuntu 기반의 빌드 환경:

pre_build:
  commands:
    - export LC_ALL="en_US.UTF-8"
    - locale-gen en_US en_US.UTF-8
    - dpkg-reconfigure locales

Amazon Linux 기반의 빌드 환경:

pre_build:
  commands:
    - export LC_ALL="en_US.utf8"

Amazon EC2 Parameter Store에서 파라미터를 가져올 때 빌드가 실패할 수 있음

문제: 빌드가 Amazon EC2 Parameter Store에 저장된 하나 이상의 파라미터 값을 가져오려고 하면 Parameter does not exist라는 오류가 표시되면서 DOWNLOAD_SOURCE 단계에서 빌드가 실패합니다.

가능한 원인: 빌드 프로젝트가 사용하는 서비스 역할에 작업을 호출할 권한이 없거나, 빌드 프로젝트가 ssm:GetParameters 작업을 생성하여 AWS CodeBuild 호출을 허용하는 서비스 역할을 사용하지만 매개 변수의 이름이 로 /CodeBuild/ 시작되지 않습니다. ssm:GetParameters

권장 솔루션:

• 에서 서비스 역할을 생성하지 않은 경우 ssm:GetParameters 작업을 호출할 수 CodeBuild 있도록 해당 정의를 업데이트하세요. CodeBuild 예를 들어 다음 정책 설명은 ssm:GetParameters 작업 호출을 허용하여 /CodeBuild/로 시작하는 이름을 가진 파라미터를 가져옵니다.

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Action": "ssm:GetParameters",
        "Effect": "Allow",
        "Resource": "arn:aws:ssm:REGION_ID:ACCOUNT_ID:parameter/CodeBuild/*"
      }
    ]
  }

• 에서 서비스 역할을 생성한 경우 로 CodeBuild 시작하는 이름이 아닌 다른 이름으로 Amazon EC2 Parameter Store의 파라미터에 액세스할 수 있도록 CodeBuild 해당 정의를 업데이트하십시오. /CodeBuild/ 예를 들어 다음 정책 설명은 ssm:GetParameters 작업 호출을 허용하여 지정된 이름을 가진 파라미터를 가져옵니다.

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Action": "ssm:GetParameters",
        "Effect": "Allow",
        "Resource": "arn:aws:ssm:REGION_ID:ACCOUNT_ID:parameter/PARAMETER_NAME"
      }
    ]
  }

CodeBuild 콘솔에서 브랜치 필터에 액세스할 수 없음

문제: AWS CodeBuild 프로젝트를 생성하거나 업데이트할 때 콘솔에서 브랜치 필터 옵션을 사용할 수 없습니다.

가능한 원인: 브랜치 필터 옵션이 사용되지 않습니다. 이 옵션은 CodeBuild에서 새 빌드를 트리거하는 Webhook 이벤트에 대해 더 다양한 제어를 제공하는 Webhook 필터 그룹으로 대체되었습니다.

권장 솔루션: Webhook 필터 도입 이전에 생성된 브랜치 필터를 마이그레이션하려면 정규식 ^refs/heads/branchName$를 사용하여 HEAD_REF 필터를 포함하는 Webhook 필터 그룹을 생성합니다. 예를 들어 브랜치 필터 정규식이 ^branchName$이었다면 HEAD_REF 필터에 삽입하는 업데이트된 정규식은 ^refs/heads/branchName$입니다. 자세한 내용은 Bitbucket Webhook 이벤트 및 GitHub 웹후크 이벤트 필터링 (콘솔) 섹션을 참조하세요.

빌드 성공 또는 실패 여부를 볼 수 없음

문제: 재시도한 빌드의 성공 또는 실패 여부를 볼 수 없습니다.

가능한 원인: 빌드 상태를 보고하는 옵션이 활성화되어 있지 않습니다.

권장 해결 방법: CodeBuild 프로젝트를 만들거나 업데이트할 때 보고서 빌드 상태를 활성화하세요. 이 옵션은 CodeBuild에게 빌드가 트리거되었을 때 상태를 다시 보고하도록 지시합니다. 자세한 내용을 알아보려면 AWS CodeBuild API 참조의 reportBuildStatus(을)를 참조하세요.

빌드 상태가 소스 공급자에게 보고되지 않음

문제: GitHub 또는 Bitbucket과 같은 소스 공급자에게 빌드 상태 보고를 허용한 후 빌드 상태가 업데이트되지 않습니다.

가능한 원인: 소스 공급자와 연결된 사용자에게 리포지토리에 대한 쓰기 권한이 없습니다.

권장 솔루션: 소스 공급자에게 빌드 상태를 보고하려면 소스 공급자와 연결된 사용자에게 리포지토리에 대한 쓰기 권한이 있어야 합니다. 사용자에게 쓰기 권한이 없는 경우 빌드 상태를 업데이트할 수 없습니다. 자세한 설명은 소스 공급자 액세스 섹션을 참조하세요.

Windows Server Core 2019 플랫폼의 기본 이미지를 찾고 선택할 수 없습니다.

문제: Windows Server Core 2019 플랫폼의 기본 이미지를 찾거나 선택할 수 없습니다.

가능한 원인: 이 이미지를 지원하지 않는 AWS 지역을 사용하고 있습니다.

권장 솔루션: Windows Server Core 2019 플랫폼의 기본 이미지가 지원되는 다음 AWS 리전 중 하나를 사용합니다.

• 미국 동부(버지니아 북부)

• 미국 동부(오하이오)

• 미국 서부(오레곤)

• 유럽(아일랜드)

buildspec 파일의 앞에 있는 명령을 나중에 있는 명령에서 인식하지 못함

문제: buildspec 파일에 있는 하나 이상의 명령 결과를 동일한 buildspec 파일의 나중에 있는 명령에서 인식하지 못합니다. 예를 들어, 명령에서 로컬 환경 변수를 설정했지만 나중에 명령이 실행될 때 해당 로컬 환경 변수 값을 가져오지 못할 수 있습니다.

가능한 원인: buildspec 파일 버전 0.1에서 AWS CodeBuild 는 빌드 환경에 있는 기본 쉘의 서로 다른 인스턴스에서 각 명령을 실행합니다. 즉, 각 명령이 다른 모든 명령과 독립적으로 실행됩니다. 그러면 기본적으로 이전 명령의 상태에 따라 실행 여부가 결정되는 단일 명령을 실행할 수 없습니다.

권장 솔루션: 이 문제를 해결하는 빌드 사양 버전 0.2를 사용하는 것이 좋습니다. buildspec 버전 0.1을 사용해야 하는 경우, 쉘 명령 결합 연산자(예: Linux의 &&)를 사용하여 여러 명령을 하나의 명령으로 결합하는 것이 좋습니다. 또는 여러 명령을 포함하는 쉘 스크립트를 소스 코드에 포함한 다음, buildspec 파일에서 단일 명령으로 해당 쉘 스크립트를 호출합니다. 자세한 내용은 빌드 환경의 쉘 및 명령 및 빌드 환경의 환경 변수 섹션을 참조하세요.

오류: 캐시를 다운로드하려고 할 때 “Access denied”라는 메시지가 표시됨

문제: 캐시가 활성화된 빌드 프로젝트에서 캐시를 다운로드하려고 하면 Access denied 오류가 표시됩니다.

가능한 원인:

• 방금 빌드 프로젝트의 일부로 캐싱을 구성했습니다.

• 최근 InvalidateProjectCache API를 통해 캐시가 무효화되었습니다.

• 에서 사용하는 서비스 역할에는 캐시를 보관하는 S3 버킷에 s3:PutObject 대한 CodeBuild 권한이 s3:GetObject 없습니다.

권장 솔루션: 처음으로 사용하는 경우 일반적으로 캐시 구성을 업데이트한 직후에 확인할 수 있습니다. 이러한 오류가 계속되는 경우 서비스 역할에 캐시를 보유하고 있는 S3 버킷에 대한 s3:GetObject 및 s3:PutObject 권한이 있는지 확인해야 합니다. 자세한 내용을 알아보려면 Amazon S3 개발자 안내서의 S3 권한 지정을 참조하세요.

오류: 사용자 지정 빌드 이미지를 사용할 때 "BUILD_CONTAINER_UNABLE_TO_PULL_IMAGE"라는 메시지가 표시됨

문제: 사용자 지정 빌드 이미지를 사용하는 빌드를 실행하려고 할 때 BUILD_CONTAINER_UNABLE_TO_PULL_IMAGE라는 오류가 표시되며 빌드가 실패합니다.

가능한 원인: 빌드 이미지의 압축되지 않은 전체 크기는 빌드 환경 컴퓨팅 유형의 사용 가능한 디스크 공간보다 큽니다. 빌드 이미지의 크기를 확인하려면 Docker를 사용하여 docker images REPOSITORY:TAG 명령을 실행합니다. 컴퓨팅 유형별로 사용 가능한 디스크 공간 목록은 빌드 환경 컴퓨팅 모드 및 유형 단원을 참조하십시오.

권장 솔루션: 사용 가능한 디스크 공간이 많은 더 큰 컴퓨팅 유형을 사용하거나 사용자 지정 빌드 이미지의 크기를 줄입니다.

가능한 원인: Amazon Elastic 컨테이너 레지스트리 (Amazon ECR) 에서 빌드 이미지를 가져올 AWS CodeBuild 권한이 없습니다.

권장 솔루션: 사용자 지정 빌드 이미지를 빌드 환경으로 가져올 CodeBuild 수 있도록 Amazon ECR의 리포지토리 권한을 업데이트하십시오. 자세한 내용은 아마존 ECR 샘플 섹션을 참조하십시오.

가능한 원인: 요청하신 Amazon ECR 이미지는 AWS 계정에서 사용 중인 AWS 지역에서 사용할 수 없습니다.

권장 해결 방법: AWS 계정에서 사용하는 것과 동일한 AWS 지역에 있는 Amazon ECR 이미지를 사용하십시오.

가능한 원인: 퍼블릭 인터넷 액세스가 불가능한 VPC에서 프라이빗 레지스트리를 사용하고 있습니다. CodeBuild VPC의 프라이빗 IP 주소에서는 이미지를 가져올 수 없습니다. 자세한 설명은 AWS Secrets Manager 샘플이 포함된 사설 레지스트리 CodeBuild 섹션을 참조하세요.

권장 솔루션: VPC에서 프라이빗 레지스트리를 사용하는 경우 VPC가 퍼블릭 인터넷에 액세스할 수 있는지 확인합니다.

가능한 원인: 오류 메시지에 "toomanyrequests“이 포함되어 있고 Docker Hub에서 이미지를 가져온 경우 이 오류는 Docker Hub 풀 제한에 도달했음을 의미합니다.

권장 솔루션: Docker Hub 프라이빗 레지스트리를 사용하거나 Amazon ECR에서 이미지를 가져옵니다. 프라이빗 레지스트리 사용에 대한 자세한 내용은 AWS Secrets Manager 샘플이 포함된 사설 레지스트리 CodeBuild 섹션을 참조하세요. Amazon S3 사용에 대한 자세한 내용은 아마존 ECR 샘플 CodeBuild 섹션을 참조하세요.

오류: “빌드를 완료하기 전에 빌드 컨테이너가 고장난 것으로 확인되었습니다. 빌드 컨테이너가 메모리가 부족하거나 Docker 이미지가 지원되지 않아 종료되었습니다. ErrorCode: 500"

문제: 에서 AWS CodeBuild Microsoft Windows 또는 Linux 컨테이너를 사용하려고 하면 프로비저닝 단계에서 이 오류가 발생합니다.

가능한 원인:

• 에서는 컨테이너 OS 버전을 지원하지 CodeBuild 않습니다.

• HTTP_PROXY, HTTPS_PROXY 또는 둘 다 컨테이너에서 지정됩니다.

권장 솔루션:

• Microsoft Windows의 경우, microsoft/windowsservercore:10.0.x 버전의 컨테이너 OS를 설치한 Windows 컨테이너를 사용합니다(예: microsoft/windowsservercore:10.0.14393.2125).

• Linux의 경우, 도커 이미지에서 HTTP_PROXY 및 HTTPS_PROXY 설정을 지우거나 빌드 프로젝트에서 VPC 구성을 지정합니다.

오류: 빌드 실행 시 "도커 데몬에 연결할 수 없음"

문제: 빌드에 실패하여 빌드 로그에 Cannot connect to the Docker daemon at unix:/var/run/docker.sock. Is the docker daemon running?과 유사한 오류가 표시됩니다.

가능한 원인: 권한이 있는 모드에서 빌드를 실행하지 않았습니다.

권장 해결 방법: 이 오류를 해결하려면 다음 지침에 따라 권한 모드를 활성화하고 buildspec을 업데이트해야 합니다.

빌드를 권한 모드에서 실행하려면 다음 단계를 따르세요.

1. https://console.aws.amazon.com/codebuild/ 에서 CodeBuild 콘솔을 엽니다.

2. 탐색 창에서 프로젝트 빌드를 선택한 다음 빌드 프로젝트를 선택합니다.

3. Edit(편집)에서 Environment(환경)을 선택합니다.

4. 추가 구성을 선택합니다.

5. Docker 이미지를 빌드하거나 빌드에 높은 권한을 부여하려면 Privileged에서 이 플래그 활성화를 선택합니다. .

6. Update environment(환경 업데이트)를 선택합니다.

7. Start build(빌드 시작)을 선택하여 빌드를 다시 시도합니다.

또한 컨테이너 내에서 Docker 데몬을 시작해야 합니다. 빌드스펙의 install 단계는 다음과 비슷할 수 있습니다.

phases:
  install:
    commands:
      - nohup /usr/local/bin/dockerd --host=unix:///var/run/docker.sock --host=tcp://127.0.0.1:2375 --storage-driver=overlay2 &
      - timeout 15 sh -c "until docker info; do echo .; sleep 1; done"

buildspec 파일에 참조된 OverlayFS 스토리지 드라이버에 대한 자세한 내용은 도커 웹사이트의 OverlayFS 스토리지 드라이버 사용을 참조하십시오.

참고

기본 운영 체제가 Alpine Linux인 경우 buildspec.yml에서 -t 인수를 timeout에 추가합니다.

- timeout -t 15 sh -c "until docker info; do echo .; sleep 1; done"

를 사용하여 Docker 이미지를 빌드하고 실행하는 방법에 대한 자세한 내용은 을 참조하십시오. AWS CodeBuild사용자 지정 이미지 샘플의 Docker CodeBuild

오류: 빌드 CodeBuild 프로젝트를 만들거나 업데이트할 때 AssumeRole “sts:"를 수행할 권한이 없습니다.

문제: 빌드 프로젝트를 생성하거나 업데이트하려고 하면 Code:InvalidInputException, Message:CodeBuild is not authorized to perform: sts:AssumeRole on arn:aws:iam::account-ID:role/service-role-name 오류가 표시됩니다.

가능한 원인:

• 빌드 프로젝트를 만들거나 업데이트하려는 AWS 지역에서 AWS Security Token Service (AWS STS) 가 비활성화되었습니다.

• 빌드 프로젝트와 관련된 AWS CodeBuild 서비스 역할이 없거나 신뢰할 수 있는 충분한 권한이 없습니다. CodeBuild

권장 솔루션:

• 빌드 프로젝트를 만들거나 업데이트하려는 AWS 지역에서 AWS STS 이 활성화되어 있는지 확인하세요. 자세한 내용은 IAM 사용 설명서의 AWS 리전 활성화 및 비활성화를 AWS STS 참조하십시오.

• 대상 CodeBuild 서비스 역할이 계정에 존재하는지 확인하십시오. AWS 콘솔을 사용하고 있지 않은 경우, 빌드 프로젝트를 생성하거나 업데이트할 때 서비스 역할의 Amazon 리소스 이름(ARN)을 잘못 입력하지 않았는지 확인합니다.

• 대상 CodeBuild 서비스 역할에 신뢰할 수 있는 충분한 권한이 있는지 확인하세요 CodeBuild. 자세한 내용은 다른 AWS 서비스와 상호 작용할 수 CodeBuild 있도록 허용 섹션의 신뢰 관계 정책 설명을 참조하십시오.

오류: “호출 오류 GetBucketAcl: 버킷 소유자가 변경되었거나 서비스 역할에 더 이상 s3를 호출할 권한이 없습니다.GetBucketAcl”

문제: 빌드를 실행하면 S3 버킷 및 GetBucketAcl 권한 소유자 변동에 관한 오류가 표시됩니다.

가능한 원인: s3:GetBucketAcl 및 s3:GetBucketLocation 권한을 IAM 역할에 추가했습니다. 이러한 권한은 프로젝트의 S3 버킷을 보호하여 사용자만 액세스할 수 있게 합니다. 이러한 권한을 추가한 후에 S3 버킷 소유자가 변경되었습니다.

권장 솔루션: 사용자가 S3 버킷 소유자인지 확인한 후에 IAM 역할에 다시 권한을 추가합니다. 자세한 설명은 S3 버킷에 대한 보안 액세스 섹션을 참조하세요.

오류: 빌드를 실행할 때 "Failed to upload artifacts: Invalid arn"이라는 메시지가 표시됨

문제: 빌드를 실행하면 Failed to upload artifacts: Invalid arn 오류가 표시되면서 UPLOAD_ARTIFACTS 빌드 단계가 실패합니다.

가능한 원인: S3 출력 버킷 (빌드의 출력을 AWS CodeBuild 저장하는 버킷) 이 CodeBuild 빌드 프로젝트와 다른 AWS 지역에 있습니다.

권장 해결 방법: 빌드 프로젝트와 동일한 AWS 리전에 있는 출력 버킷을 가리키도록 빌드 프로젝트 설정을 업데이트하세요.

오류: "Git Clone Failed: unable to access 'your-repository-URL': SSL certificate problem: self signed certificate"

문제: 빌드 프로젝트를 실행하려고 하면 이 오류가 표시되면서 빌드가 실패합니다.

가능한 원인: 소스 리포지토리에 자체 서명된 인증서가 있지만 빌드 프로젝트의 일부로 S3 버킷에서 인증서를 설치하도록 선택하지 않은 것입니다.

권장 솔루션:

• 프로젝트를 편집합니다. 인증서에서 Install certificate from S3(S3에서 인증서 설치)를 선택합니다. Bucket of certificate(인증서 버킷)에 SSL 인증서가 저장된 S3 버킷을 선택합니다. 인증서의 객체 키에 S3 객체 키의 이름을 입력합니다.

• 프로젝트를 편집합니다. GitHub Enterprise Server 프로젝트 리포지토리에 연결하는 동안 SSL 경고를 무시하려면 비보안 SSL을 선택합니다.

  참고

  [Insecure SSL]은 테스트 용도로만 사용하는 것이 좋습니다. 프로덕션 환경에 사용하면 안 됩니다.

오류: 빌드를 실행할 때 "The bucket you are attempting to access must be addressed using the specified endpoint..."라는 메시지가 표시됨

문제: 빌드를 실행하면 The bucket you are attempting to access must be addressed using the specified endpoint. Please send all future requests to this endpoint 오류가 표시되면서 DOWNLOAD_SOURCE 빌드 단계가 실패합니다.

가능한 원인: 사전 빌드된 소스 코드가 S3 버킷에 저장되어 있고 해당 버킷이 AWS CodeBuild 빌드 프로젝트와 다른 AWS 지역에 있습니다.

권장 솔루션: 사전 작성된 소스 코드가 포함되어 있는 버킷을 가리키도록 빌드 프로젝트 설정을 업데이트합니다. 버킷이 빌드 프로젝트와 같은 AWS 리전에 있는지 확인하세요.

오류: "이 빌드 이미지는 하나 이상의 런타임 버전을 선택해야 합니다."

문제: 빌드를 실행하면 YAML_FILE_ERROR: This build image requires selecting at least one runtime version 오류가 표시되면서 DOWNLOAD_SOURCE 빌드 단계가 실패합니다.

가능한 원인: 빌드에서 Amazon Linux 2(AL2) 표준 이미지 버전 1.0 이상 또는 Ubuntu 표준 이미지 버전 2.0 이상을 사용하고, buildspec 파일에 런타임이 지정되어 있지 않습니다.

권장 해결 방법: aws/codebuild/standard:2.0 CodeBuild 관리 이미지를 사용하는 경우 buildspec 파일의 runtime-versions 섹션에서 런타임 버전을 지정해야 합니다. 예를 들어, PHP를 사용하는 프로젝트에는 다음 buildspec 파일을 사용해야 합니다.

version: 0.2

phases:
  install:
    runtime-versions:
        php: 7.3
  build:
    commands:
      - php --version
artifacts:
  files:
    -  README.md

참고

runtime-versions 섹션을 지정하고 Ubuntu 표준 이미지 2.0 이상 또는 Amazon Linux 2(AL2) 표준 이미지 1.0 이상 외의 이미지를 사용하는 경우, 빌드에서 “Skipping install of runtimes. Runtime version selection is not supported by this build image” 경고가 발생합니다.

자세한 설명은 Specify runtime versions in the buildspec file 섹션을 참조하세요.

오류: 빌드 대기열의 빌드가 실패할 때 "QUEUED: INSUFFICIENT_SUBNET"이라는 메시지가 표시됨

문제: QUEUED: INSUFFICIENT_SUBNET과 유사한 오류로 빌드 대기열의 빌드가 실패합니다.

가능한 원인: VPC에 지정된 IPv4 CIDR 블록이 예약된 IP 주소를 사용합니다. 각 서브넷 CIDR 블록에서 처음 4개의 IP 주소와 마지막 IP 주소는 사용자가 사용할 수 없으므로 인스턴스에 할당할 수 없습니다. 예를 들어 10.0.0.0/24 CIDR 블록의 서브넷에서는 다음 5개 IP 주소가 예약되어 있습니다.

• 10.0.0.0:: 네트워크 주소

• 10.0.0.1: VPC AWS 라우터용으로 예약합니다.

• 10.0.0.2: 예약자. AWS DNS 서버의 IP 주소는 항상 기본 VPC 네트워크 범위에 2를 더한 주소입니다. 그러나 각 서브넷 범위에 2를 더한 주소도 예약합니다. CIDR 블록이 여러 개인 VPC의 경우, DNS 서버의 IP 주소가 기본 CIDR에 위치합니다. 자세한 내용은 Amazon VPC 사용 설명서의 Amazon DNS 서버를 참조하세요.

• 10.0.0.3: 나중에 AWS 사용할 수 있도록 예약했습니다.

• 10.0.0.255: 네트워크 브로드캐스트 주소. VPC에서는 브로드캐스트를 지원하지 않습니다. 이 주소는 예약되어 있습니다.

권장 솔루션: VPC가 예약된 IP 주소를 사용하는지 확인합니다. 예약된 IP 주소를 예약되지 않은 IP 주소로 바꿉니다. 자세한 내용은 Amazon VPC 사용 설명서의 VPC 및 서브넷 크기 조정을 참조하세요.

오류: “캐시를 다운로드할 수 없음: RequestError: 전송 요청 실패 원인: x509: 시스템 루트를 로드하지 못했고 루트가 제공되지 않았습니다.”

문제: 빌드 프로젝트를 실행하려고 하면 이 오류가 표시되면서 빌드가 실패합니다.

가능한 원인: 캐시를 빌드 프로젝트의 일부로 구성했으며 만료된 루트 인증서가 포함된 기존 도커 이미지를 사용하고 있습니다.

권장 해결 방법: 프로젝트에서 사용 중인 Docker 이미지를 업데이트하세요. AWS CodeBuild 자세한 설명은 Docker 이미지 제공: CodeBuild 섹션을 참조하세요.

오류: “S3에서 인증서를 다운로드할 수 없습니다. AccessDenied

문제: 빌드 프로젝트를 실행하려고 하면 이 오류가 표시되면서 빌드가 실패합니다.

가능한 원인:

• 인증서에 대해 잘못된 S3 버킷을 선택한 것입니다.

• 인증서에 대해 잘못된 객체 키를 입력한 것입니다.

권장 솔루션:

• 프로젝트를 편집합니다. Bucket of certificate(인증서 버킷)에 SSL 인증서가 저장된 S3 버킷을 선택합니다.

• 프로젝트를 편집합니다. 인증서의 객체 키에 S3 객체 키의 이름을 입력합니다.

오류: "Unable to locate credentials"

문제: 를 실행하거나 AWS SDK를 사용하거나 빌드의 일부로 다른 유사한 구성 요소를 호출하려고 하면 AWS CLI, AWS SDK 또는 구성 요소와 직접 관련된 빌드 오류가 발생합니다. AWS CLI예를 들어 Unable to locate credentials와 같은 빌드 오류가 발생할 수 있습니다.

가능한 원인:

• 빌드 환경의 AWS CLI, AWS SDK 또는 구성 요소 버전이 호환되지 않습니다. AWS CodeBuild

• Docker를 사용하는 빌드 환경 내에서 Docker 컨테이너를 실행하고 있는데 컨테이너는 기본적으로 자격 증명에 액세스할 수 없습니다. AWS

권장 솔루션:

• 빌드 환경에 다음 버전 이상의 AWS SDK 또는 구성 요소가 AWS CLI있는지 확인하세요.

  • AWS CLI: 1.10.47

  • AWS C++용 SDK: 0.2.19

  • AWS Go용 SDK: 1.2.5

  • AWS 자바용 SDK: 1.11.16

  • AWS SDK 버전: 2.4.7 JavaScript

  • AWS PHP용 SDK: 3.18.28

  • AWS 파이썬용 SDK (Boto3): 1.4.0

  • AWS 루비용 SDK: 2.3.22

  • Botocore: 1.4.37

  • CoreCLR: 3.2.6-beta

  • Node.js: 2.4.7

• 빌드 환경에서 Docker 컨테이너를 실행해야 하고 컨테이너에 AWS 자격 증명이 필요한 경우 빌드 환경의 자격 증명을 컨테이너로 전달해야 합니다. buildspec 파일에서 다음과 같은 도커 run 명령을 포함합니다. 이 예에서는 aws s3 ls 명령을 사용하여 사용 가능한 S3 버킷을 나열합니다. -e옵션은 컨테이너가 AWS 자격 증명에 액세스하는 데 필요한 환경 변수를 통과합니다.

  docker run -e AWS_DEFAULT_REGION -e AWS_CONTAINER_CREDENTIALS_RELATIVE_URI your-image-tag aws s3 ls

• Docker 이미지를 빌드하고 있고 빌드에 AWS 자격 증명이 필요한 경우 (예: Amazon S3에서 파일 다운로드), 다음과 같이 빌드 환경의 자격 증명을 Docker 빌드 프로세스로 전달해야 합니다.

  1. 도커 이미지용 소스 코드의 Dockerfile에서 다음 ARG 지침을 지정합니다.

     ARG AWS_DEFAULT_REGION
     ARG AWS_CONTAINER_CREDENTIALS_RELATIVE_URI

  2. buildspec 파일에서 다음과 같은 도커 build 명령을 포함합니다. --build-arg옵션은 Docker 빌드 프로세스가 자격 증명에 액세스하는 데 필요한 환경 변수를 설정합니다. AWS

     docker build --build-arg AWS_DEFAULT_REGION=$AWS_DEFAULT_REGION --build-arg AWS_CONTAINER_CREDENTIALS_RELATIVE_URI=$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI -t your-image-tag .

RequestError 프록시 서버에서 실행할 CodeBuild 때 시간 초과 오류가 발생했습니다.

문제: 다음 중 하나와 비슷한 RequestError 오류가 발생합니다.

• RequestError: send request failed caused by: Post https://logs.<your-region>.amazonaws.com/: dial tcp 52.46.158.105:443: i/o timeout CloudWatch 로그에서.

• Amazon S3의 Error uploading artifacts: RequestError: send request failed caused by: Put https://your-bucket.s3.your-aws-region.amazonaws.com/*: dial tcp 52.219.96.208:443: connect: connection refused

가능한 원인:

• ssl-bump가 제대로 구성되지 않았습니다.

• 조직의 보안 정책이 사용자가 ssl_bump를 사용하는 것을 허용하지 않습니다.

• buildspec 파일에 proxy 요소를 사용하여 지정한 프록시 설정이 없습니다.

권장 솔루션:

• ssl-bump가 올바로 구성되었는지 확인하십시오. Squid를 프록시 서버로 사용하는 경우 Squid를 명시적 프록시 서버로 구성 단원을 참조하십시오.

• Amazon S3 및 CloudWatch Logs에 프라이빗 엔드포인트를 사용하려면 다음 단계를 따르십시오.

  1. 프라이빗 서브넷 라우팅 테이블에서 이전에 추가한 인터넷으로 향하는 트래픽을 프록시 서버로 라우팅하는 규칙을 제거합니다. 자세한 내용은 Amazon VPC 사용 설명서의 VPC에서 서브넷 만들기를 참조하세요.

  2. 프라이빗 Amazon S3 엔드포인트와 CloudWatch 로그 엔드포인트를 생성하고 이를 Amazon VPC의 프라이빗 서브넷과 연결합니다. 자세한 내용은 Amazon VPC 사용 설명서의 VPC 엔드포인트 서비스를 참조하세요.

  3. Amazon VPC에서 프라이빗 DNS 이름 활성화가 선택되었는지 확인합니다. 자세한 내용은 Amazon VPC 사용 설명서의 인터페이스 엔드포인트 생성을 참조하십시오.

• 명시적 프록시 서버에 ssl-bump를 사용하지 않을 경우 proxy 요소를 사용하여 buildspec 파일에 프록시 구성을 추가하십시오. 자세한 내용은 CodeBuild 명시적 프록시 서버에서 실행 및 buildspec 구문 섹션을 참조하세요.

  version: 0.2
  proxy:
    upload-artifacts: yes
    logs: yes
  phases:
    build:
      commands:

빌드 이미지에 있어야 하는 Bourne 쉘(sh)

문제: 에서 제공하지 않은 빌드 이미지를 사용하고 있는데 이 메시지와 함께 빌드가 실패합니다. AWS CodeBuildBuild container found dead before completing the build

가능한 원인: Bourne shell (sh) 이 빌드 이미지에 포함되어 있지 않습니다. CodeBuild 빌드 명령과 스크립트를 sh 실행해야 합니다.

권장 솔루션: sh가 빌드 이미지에 없는 경우, 이미지를 사용하는 더 많은 빌드를 시작하기 전에 먼저 포함해야 합니다. (CodeBuild 이미 빌드 이미지에 포함되어 sh 있습니다.)

경고: 빌드 실행 시 “런타임 설치를 건너뜁니다. 런타임 버전 선택은 이 빌드 이미지에서 지원되지 않습니다.”가 표시됨

문제: 빌드를 실행하면 빌드 로그에 이 경고가 포함되어 있습니다.

가능한 원인: 빌드에서 Amazon Linux 2(AL2) 표준 이미지 버전 1.0 이상 또는 Ubuntu 표준 이미지 버전 2.0 이상을 사용하지 않고, buildspec 파일의 runtime-versions 섹션에 런타임이 지정되어 있습니다.

권장 솔루션: buildspec 파일에 runtime-versions 섹션이 포함되지 않게 하십시오. runtime-versions 섹션은 Amazon Linux 2(AL2) 표준 이미지 버전 이상 또는 Ubuntu 표준 이미지 버전 2.0 이상을 사용하는 경우에만 필요합니다.

오류: CodeBuild 콘솔을 열 때 “ JobWorker ID를 확인할 수 없습니다.”

문제: CodeBuild 콘솔을 열면 “ JobWorker ID를 확인할 수 없음” 오류 메시지가 표시됩니다.

가능한 원인: 콘솔 액세스에 사용되는 IAM 역할에 jobId 키가 있는 태그가 있습니다. 이 태그 키는 CodeBuild 예약용이며 있는 경우 이 오류가 발생합니다.

권장 솔루션: jobId 키가 있는 사용자 지정 IAM 역할 태그를 다른 키를 사용하도록 변경합니다(예: jobIdentifier).

빌드를 시작하지 못함

문제: 빌드를 시작할 때 빌드를 시작하지 못함 오류 메시지가 나타납니다.

가능한 원인: 동시 빌드 수에 도달했습니다.

권장 솔루션: 다른 빌드가 완료될 때까지 기다리거나 프로젝트의 동시 빌드 제한을 늘린 다음, 빌드를 다시 시작하세요. 자세한 설명은 프로젝트 구성 섹션을 참조하세요.

로컬에 캐시된 빌드의 GitHub 메타데이터에 액세스

문제: 캐시된 빌드의 .git 디렉터리가 디렉터리가 아닌 텍스트 파일인 경우가 있습니다.

가능한 원인: 빌드에 로컬 소스 캐싱이 활성화되면 디렉터리에 gitlink가 CodeBuild 생성됩니다. .git 즉, .git 디렉터리는 실제로 디렉터리 경로가 포함된 텍스트 파일입니다.

권장 솔루션: 모든 경우에 다음 명령을 사용하여 Git 메타데이터 디렉터리를 가져오세요. 이 명령은 다음과 같은 .git 형식에 관계없이 작동합니다.

git rev-parse --git-dir

AccessDenied: 보고서 그룹의 버킷 소유자가 S3 버킷 소유자와 일치하지 않습니다...

문제: Amazon S3 버킷에 테스트 데이터를 업로드할 때 테스트 데이터를 버킷에 쓸 수 없습니다. CodeBuild

가능한 원인:

• 보고서 그룹 버킷 소유자로 지정된 계정이 Amazon S3 버킷 소유자와 일치하지 않습니다.

• 서비스 역할에는 버킷에 대한 쓰기 권한이 없습니다.

권장 솔루션:

• Amazon S3 버킷 소유자와 일치하도록 보고서 그룹 버킷 소유자를 변경합니다.

• Amazon S3 버킷에 대한 쓰기 액세스 권한을 허용하도록 서비스 역할을 수정합니다.