기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 문제 해결 AWS CodeBuild 이 주제의 정보를 활용하면 문제를 식별, 진단 및 해결하는 데 도움이 됩니다. 문제를 해결하기 위해 CodeBuild 빌드를 기록하고 모니터링하는 방법은 [로깅 및 모니터링](logging-monitoring.md) 섹션을 참조하세요. **Topics** + [Apache Maven 빌드가 잘못된 리포지토리의 아티팩트를 참조함](#troubleshooting-maven-repos) + [기본적으로 루트로 실행되는 빌드 명령](#troubleshooting-root-build-commands) + [파일 이름에 미국 영어 이외의 문자가 있으면 빌드가 실패할 수 있음](#troubleshooting-utf-8) + [Amazon EC2 Parameter Store에서 파라미터를 가져올 때 빌드가 실패할 수 있음](#troubleshooting-parameter-store) + [CodeBuild 콘솔에서 브랜치 필터에 액세스할 수 없음](#troubleshooting-webhook-filter) + [빌드 성공 또는 실패 여부를 볼 수 없음](#no-status-when-build-triggered) + [빌드 상태가 소스 공급자에게 보고되지 않음](#build-status-not-reported) + [Windows Server Core 2019 플랫폼의 기본 이미지를 찾고 선택할 수 없습니다.](#windows-image-not-available) + [buildspec 파일의 앞에 있는 명령을 나중에 있는 명령에서 인식하지 못함](#troubleshooting-build-spec-commands) + [오류: 캐시를 다운로드하려고 할 때 “Access denied”라는 메시지가 표시됨](#troubleshooting-dependency-caching) + [오류: 사용자 지정 빌드 이미지를 사용할 때 "BUILD\$1CONTAINER\$1UNABLE\$1TO\$1PULL\$1IMAGE"라는 메시지가 표시됨](#troubleshooting-unable-to-pull-image) + [오류: “빌드를 완료하기 전에 빌드 컨테이너가 종료된 것으로 나타났습니다. 빌드 컨테이너가 메모리가 부족하거나 도커 이미지가 지원되지 않기 때문에 종료되었습니다. ErrorCode: 500"](#windows-server-core-version) + [오류: 빌드 실행 시 "도커 데몬에 연결할 수 없음"](#troubleshooting-cannot-connect-to-docker-daemon) + [오류: 빌드 프로젝트를 생성 또는 업데이트할 때 "CodeBuild is not authorized to perform: sts:AssumeRole"오류가 표시됨](#troubleshooting-assume-role) + [오류: "GetBucketAcl 호출 중 오류 발생: 버킷 소유자가 변경되었거나 해당 서비스 역할에 s3:GetBucketAcl이라는 이름의 권한이 없습니다"](#troubleshooting-calling-bucket-error) + [오류: 빌드를 실행할 때 "Failed to upload artifacts: Invalid arn"이라는 메시지가 표시됨](#troubleshooting-output-bucket-different-region) + [오류: "Git Clone Failed: unable to access `'your-repository-URL'`: SSL certificate problem: self signed certificate"](#troubleshooting-self-signed-certificate) + [오류: 빌드를 실행할 때 "The bucket you are attempting to access must be addressed using the specified endpoint..."라는 메시지가 표시됨](#troubleshooting-input-bucket-different-region) + [오류: "이 빌드 이미지는 하나 이상의 런타임 버전을 선택해야 합니다."](#troubleshooting-build-must-specify-runtime) + [오류: 빌드 대기열의 빌드가 실패할 때 "QUEUED: INSUFFICIENT\$1SUBNET"이라는 메시지가 표시됨](#queued-insufficient-subnet-error) + [오류: "Unable to download cache: RequestError: Send request failed caused by: x509: Failed to load system roots and no roots provided"](#troubleshooting-cache-image) + [오류: "Unable to download certificate from S3. AccessDenied"](#troubleshooting-certificate-in-S3) + [오류: "Unable to locate credentials"](#troubleshooting-versions) + [프록시 서버에서 CodeBuild를 실행할 때 RequestError 시간 초과 오류](#code-request-timeout-error) + [빌드 이미지에 있어야 하는 Bourne 쉘(sh)](#troubleshooting-sh-build-images) + [경고: 빌드 실행 시 “런타임 설치를 건너뜁니다. 런타임 버전 선택은 이 빌드 이미지에서 지원되지 않습니다.”가 표시됨](#troubleshooting-skipping-all-runtimes-warning) + [CodeBuild 콘솔을 열 때 오류: “JobWorker ID를 확인할 수 없음”이 표시됨](#troubleshooting-unable-to-verify-jobworker) + [빌드를 시작하지 못함](#troubleshooting-build-failed-to-start) + [로컬로 캐시된 빌드의 GitHub 메타데이터에 액세스](#troubleshooting-github-metadata) + [AccessDenied: 보고서 그룹의 버킷 소유자가 S3 버킷 소유자와 일치하지 않습니다.](#troubleshooting-bucket-owner) + [오류: CodeConnections를 사용하여 CodeBuild 프로젝트 생성 시 '자격 증명에 필요한 권한 범위가 하나 이상 없음'](#troubleshooting-permission-bitbucket) + [오류: Ubuntu 설치 명령을 사용하여 빌드 시 '죄송합니다. 터미널이 전혀 요청되지 않았습니다. 입력을 가져올 수 없습니다'](#troubleshooting-nvidia-container-toolkit) ## Apache Maven 빌드가 잘못된 리포지토리의 아티팩트를 참조함 **문제:** Maven을 AWS CodeBuild제공 Java 빌드 환경과 함께 사용하는 경우 Maven은 [https://repo1.maven.org/maven2](https://repo1.maven.org/maven2) 보안 중앙 Maven 리포지토리에서 빌드 및 플러그인 종속성을 가져옵니다. 빌드 프로젝트의 `pom.xml` 파일에 대신 사용할 다른 위치가 명시적으로 선언되어 있는 경우에도 이러한 문제가 발생합니다. **가능한 원인:** CodeBuild 제공 Java 빌드 환경에 빌드 환경의 `/root/.m2` 디렉터리에 사전 설치되어 있는 `settings.xml`이라는 파일이 포함되어 있습니다. 이 `settings.xml` 파일에는 다음 선언이 포함되어 있는데, 이는 Maven이 항상 [https://repo1.maven.org/maven2](https://repo1.maven.org/maven2)에 있는 보안된 중앙 Maven 리포지토리로부터 빌드 및 플러그인 종속성을 가져오도록 지시합니다. ``` securecentral securecentral central https://repo1.maven.org/maven2 true central https://repo1.maven.org/maven2 true ``` **권장 솔루션:** 다음을 실행합니다. 1. 소스 코드에 `settings.xml` 파일을 추가합니다. 1. 이 `settings.xml` 파일에서, 이전 `settings.xml` 형식을 참고하여 Maven이 빌드 및 플러그인 종속성을 가져오게 하려는 다른 리포지토리를 선언합니다. 1. 빌드 프로젝트의 `install` 단계에서 CodeBuild가 사용자가 만든 `settings.xml` 파일을 빌드 환경의 `/root/.m2` 디렉터리에 복사하도록 명령을 설정합니다. 예를 들어 이러한 작업을 수행하는 `buildspec.yml` 파일의 다음 코드 조각을 고려해 보십시오. ``` version 0.2 phases: install: commands: - cp ./settings.xml /root/.m2/settings.xml ``` ## 기본적으로 루트로 실행되는 빌드 명령 **Issue:** 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 -f noninteractive 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` 작업을 호출할 권한이 없거나 빌드 프로젝트가에서 생성하고 `ssm:GetParameters` 작업 호출을 AWS CodeBuild 허용하는 서비스 역할을 사용하지만 파라미터에는 로 시작하지 않는 이름이 있습니다`/CodeBuild/`. **권장 솔루션:** + 서비스 역할이 CodeBuild로 생성되지 않은 경우 CodeBuild가 `ssm:GetParameters` 작업을 호출할 수 있게 허용하도록 정의를 업데이트합니다. 예를 들어 다음 정책 설명은 `ssm:GetParameters` 작업 호출을 허용하여 `/CodeBuild/`로 시작하는 이름을 가진 파라미터를 가져옵니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": "ssm:GetParameters", "Effect": "Allow", "Resource": "arn:aws:ssm:us-east-1:111122223333:parameter/CodeBuild/*" } ] } ``` ------ + 서비스 역할이 CodeBuild로 생성되지 않은 경우 CodeBuild가 Amazon EC2 Parameter Store에서 `/CodeBuild/`로 시작하는 이름이 아닌 다른 이름의 파라미터에 액세스할 수 있게 허용하도록 정의를 업데이트합니다. 예를 들어 다음 정책 설명은 `ssm:GetParameters` 작업 호출을 허용하여 지정된 이름을 가진 파라미터를 가져옵니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": "ssm:GetParameters", "Effect": "Allow", "Resource": "arn:aws:ssm:us-east-1:111122223333:parameter/PARAMETER_NAME" } ] } ``` ------ ## CodeBuild 콘솔에서 브랜치 필터에 액세스할 수 없음 **문제:** AWS CodeBuild 프로젝트를 생성하거나 업데이트할 때 콘솔에서 브랜치 필터 옵션을 사용할 수 없습니다. **가능한 원인:** 브랜치 필터 옵션이 사용되지 않습니다. 이 옵션은 CodeBuild에서 새 빌드를 트리거하는 Webhook 이벤트에 대해 더 다양한 제어를 제공하는 Webhook 필터 그룹으로 대체되었습니다. **권장 솔루션:** Webhook 필터 도입 이전에 생성된 브랜치 필터를 마이그레이션하려면 정규식 `^refs/heads/branchName$`를 사용하여 `HEAD_REF` 필터를 포함하는 Webhook 필터 그룹을 생성합니다. 예를 들어 브랜치 필터 정규식이 `^branchName$`이었다면 `HEAD_REF` 필터에 삽입하는 업데이트된 정규식은 `^refs/heads/branchName$`입니다. 자세한 내용은 [Bitbucket Webhook 이벤트](bitbucket-webhook.md) 및 [GitHub Webhook 이벤트 필터링(콘솔)](github-webhook-events-console.md) 섹션을 참조하세요. ## 빌드 성공 또는 실패 여부를 볼 수 없음 **문제:** 재시도한 빌드의 성공 또는 실패 여부를 볼 수 없습니다. **가능한 원인:** 빌드 상태를 보고하는 옵션이 활성화되어 있지 않습니다. **권장 솔루션:** CodeBuild 프로젝트를 생성하거나 업데이트할 때 **보고서 빌드 상태**를 활성화하세요. 이 옵션은 CodeBuild에 빌드가 트리거되었을 때 상태를 다시 보고하도록 지시합니다. 자세한 내용은 *AWS CodeBuild API 참조*의 [reportBuildStatus](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_ProjectSource.html#CodeBuild-Type-ProjectSource-reportBuildStatus)를 참조하세요. ## 빌드 상태가 소스 공급자에게 보고되지 않음 **문제:** GitHub 또는 Bitbucket과 같은 소스 공급자에게 빌드 상태 보고를 허용한 후 빌드 상태가 업데이트되지 않습니다. **가능한 원인:** 소스 공급자와 연결된 사용자에게 리포지토리에 대한 쓰기 권한이 없습니다. **권장 솔루션:** 소스 공급자에게 빌드 상태를 보고하려면 소스 공급자와 연결된 사용자에게 리포지토리에 대한 쓰기 권한이 있어야 합니다. 사용자에게 쓰기 권한이 없는 경우 빌드 상태를 업데이트할 수 없습니다. 자세한 내용은 [소스 공급자 액세스](access-tokens.md) 단원을 참조하십시오. ## 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 파일에서 단일 명령으로 해당 쉘 스크립트를 호출합니다. 자세한 내용은 [빌드 환경의 쉘 및 명령](build-env-ref-cmd.md) 및 [빌드 환경의 환경 변수](build-env-ref-env-vars.md) 섹션을 참조하세요. ## 오류: 캐시를 다운로드하려고 할 때 “Access denied”라는 메시지가 표시됨 **문제:** 캐시가 활성화된 빌드 프로젝트에서 캐시를 다운로드하려고 하면 `Access denied` 오류가 표시됩니다. **가능한 원인:** + 방금 빌드 프로젝트의 일부로 캐싱을 구성했습니다. + 최근 `InvalidateProjectCache` API를 통해 캐시가 무효화되었습니다. + CodeBuild에서 사용 중인 서비스 역할에는 캐시를 보유하고 있는 S3 버킷에 대한 `s3:GetObject` 및 `s3:PutObject` 권한이 없습니다. **권장 솔루션:** 처음으로 사용하는 경우 일반적으로 캐시 구성을 업데이트한 직후에 확인할 수 있습니다. 이러한 오류가 계속되는 경우 서비스 역할에 캐시를 보유하고 있는 S3 버킷에 대한 `s3:GetObject` 및 `s3:PutObject` 권한이 있는지 확인해야 합니다. 자세한 내용을 알아보려면 *Amazon S3 개발자 안내서*의 [S3 권한 지정](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-with-s3-actions.html)을 참조하세요. ## 오류: 사용자 지정 빌드 이미지를 사용할 때 "BUILD\$1CONTAINER\$1UNABLE\$1TO\$1PULL\$1IMAGE"라는 메시지가 표시됨 **문제:** 사용자 지정 빌드 이미지를 사용하는 빌드를 실행하려고 할 때 `BUILD_CONTAINER_UNABLE_TO_PULL_IMAGE`라는 오류가 표시되며 빌드가 실패합니다. ***가능한 원인:** 빌드 이미지의 압축되지 않은 전체 크기는 빌드 환경 컴퓨팅 유형의 사용 가능한 디스크 공간보다 큽니다. 빌드 이미지의 크기를 확인하려면 Docker를 사용하여 `docker images REPOSITORY:TAG` 명령을 실행합니다. 컴퓨팅 유형별로 사용 가능한 디스크 공간 목록은 [빌드 환경 컴퓨팅 모드 및 유형](build-env-ref-compute-types.md) 단원을 참조하십시오.* **권장 솔루션:** 사용 가능한 디스크 공간이 많은 더 큰 컴퓨팅 유형을 사용하거나 사용자 지정 빌드 이미지의 크기를 줄입니다. ***가능한 원인:** AWS CodeBuild Amazon Elastic Container Registry(Amazon ECR)에서 빌드 이미지를 가져올 권한이 없습니다.* **권장 솔루션:** CodeBuild가 사용자 지정 빌드 이미지를 빌드 환경으로 가져올 수 있도록 Amazon ECR에서 리포지토리의 권한을 업데이트합니다. 자세한 내용은 [Amazon ECR 샘플](sample-ecr.md) 단원을 참조하십시오. ***가능한 원인:** 요청한 Amazon ECR 이미지를 AWS 계정이 사용 중인 AWS 리전에서 사용할 수 없습니다.* **권장 솔루션:** AWS 계정에서 사용 중인 리전과 동일한 AWS 리전에 있는 Amazon ECR 이미지를 사용합니다. ***가능한 원인:** 퍼블릭 인터넷 액세스가 불가능한 VPC에서 프라이빗 레지스트리를 사용하고 있습니다. CodeBuild는 VPC의 프라이빗 IP 주소에서 이미지를 끌어올 수 없습니다. 자세한 내용은 [CodeBuild용 AWS Secrets Manager 샘플이 포함된 프라이빗 레지스트리](sample-private-registry.md) 단원을 참조하십시오.* **권장 솔루션:** VPC에서 프라이빗 레지스트리를 사용하는 경우 VPC가 퍼블릭 인터넷에 액세스할 수 있는지 확인합니다. ***가능한 원인:** 오류 메시지에 "**toomanyrequests**“이 포함되어 있고 Docker Hub에서 이미지를 가져온 경우 이 오류는 Docker Hub 풀 제한에 도달했음을 의미합니다.* **권장 솔루션:** Docker Hub 프라이빗 레지스트리를 사용하거나 Amazon ECR에서 이미지를 가져옵니다. 프라이빗 레지스트리 사용에 대한 자세한 내용은 [CodeBuild용 AWS Secrets Manager 샘플이 포함된 프라이빗 레지스트리](sample-private-registry.md) 섹션을 참조하세요. Amazon ECR 사용에 대한 자세한 내용은 [CodeBuild용 Amazon ECR 샘플](sample-ecr.md) 섹션을 참조하세요. ## 오류: “빌드를 완료하기 전에 빌드 컨테이너가 종료된 것으로 나타났습니다. 빌드 컨테이너가 메모리가 부족하거나 도커 이미지가 지원되지 않기 때문에 종료되었습니다. ErrorCode: 500" **문제:**에서 Microsoft Windows 또는 Linux 컨테이너를 사용하려고 하면 프로비저닝 단계에서 AWS CodeBuild이 오류가 발생합니다. **가능한 원인:** + CodeBuild에서 컨테이너 OS 버전을 지원하지 않습니다. + `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/](https://console.aws.amazon.com/codebuild/)에서 CodeBuild 콘솔을 엽니다. 1. 탐색 창에서 **빌드 프로젝트**를 선택한 후 빌드 프로젝트를 선택합니다. 1. **Edit(편집)**에서 **Environment(환경)**을 선택합니다. 1. **추가 구성**을 선택합니다. 1. **권한 있음**에서 **Docker 이미지를 빌드하거나 빌드에서 승격된 권한을 얻으려는 경우 이 플래그 활성화**를 선택합니다. 1. **Update environment(환경 업데이트)**를 선택합니다. 1. **Start build(빌드 시작)**을 선택하여 빌드를 다시 시도합니다. 컨테이너 내에서 Docker 데몬도 시작해야 합니다. Buildspec의 `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 스토리지 드라이버 사용](https://docs.docker.com/storage/storagedriver/overlayfs-driver/)을 참조하십시오. **참고** 기본 운영 체제가 Alpine Linux인 경우 `buildspec.yml`에서 `-t` 인수를 `timeout`에 추가합니다. ``` - timeout -t 15 sh -c "until docker info; do echo .; sleep 1; done" ``` 를 사용하여 도커 이미지를 빌드하고 실행하는 방법에 대한 자세한 내용은 섹션을 AWS CodeBuild참조하세요[CodeBuild용 Docker 사용자 지정 이미지 샘플](sample-docker-custom-image.md). ## 오류: 빌드 프로젝트를 생성 또는 업데이트할 때 "CodeBuild is not authorized to perform: sts:AssumeRole"오류가 표시됨 **문제:** 빌드 프로젝트를 생성하거나 업데이트하려고 하면 `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 CodeBuild 서비스 역할 대소문자가 실제 IAM 역할과 일치하지 않습니다. **권장 솔루션:** + 빌드 프로젝트를 생성하거나 업데이트하려는 AWS 리전에 대해가 활성화 AWS STS 되어 있는지 확인합니다. 자세한 내용은 *IAM 사용 설명서*의 [AWS 리전 AWS STS 에서 활성화 및 비활성화](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html)를 참조하세요. + 대상 CodeBuild 서비스 역할이 AWS 계정에 있는지 확인합니다. 콘솔을 사용하고 있지 않은 경우, 빌드 프로젝트를 생성하거나 업데이트할 때 서비스 역할의 Amazon 리소스 이름(ARN)을 잘못 입력하지 않았는지 확인합니다. IAM 역할은 대소문자를 구분하므로 IAM 역할의 대소문자가 올바른지 확인합니다. + 대상 CodeBuild 서비스 역할에 CodeBuild를 신뢰할 만큼 충분한 권한이 있는지 확인합니다. 자세한 내용은 [CodeBuild가 다른 AWS 서비스와 상호 작용하도록 허용](setting-up-service-role.md) 섹션의 신뢰 관계 정책 설명을 참조하십시오. ## 오류: "GetBucketAcl 호출 중 오류 발생: 버킷 소유자가 변경되었거나 해당 서비스 역할에 s3:GetBucketAcl이라는 이름의 권한이 없습니다" **문제:** 빌드를 실행하면 S3 버킷 및 `GetBucketAcl` 권한 소유자 변동에 관한 오류가 표시됩니다. **가능한 원인:** `s3:GetBucketAcl` 및 `s3:GetBucketLocation` 권한을 IAM 역할에 추가했습니다. 이러한 권한은 프로젝트의 S3 버킷을 보호하여 사용자만 액세스할 수 있게 합니다. 이러한 권한을 추가한 후에 S3 버킷 소유자가 변경되었습니다. **권장 솔루션:** 사용자가 S3 버킷 소유자인지 확인한 후에 IAM 역할에 다시 권한을 추가합니다. 자세한 내용은 [S3 버킷에 대한 보안 액세스](auth-and-access-control-iam-access-control-identity-based.md#secure-s3-buckets) 단원을 참조하십시오. ## 오류: 빌드를 실행할 때 "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을 무시하려면 [**Insecure 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 리전에 있습니다 AWS CodeBuild . **권장 솔루션:** 사전 작성된 소스 코드가 포함되어 있는 버킷을 가리키도록 빌드 프로젝트 설정을 업데이트합니다. 버킷이 빌드 프로젝트와 동일한 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](build-spec-ref.md#runtime-versions-buildspec-file) 단원을 참조하십시오. ## 오류: 빌드 대기열의 빌드가 실패할 때 "QUEUED: INSUFFICIENT\$1SUBNET"이라는 메시지가 표시됨 **문제:** `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 서버](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#AmazonDNS)를 참조하세요.** + `10.0.0.3`: 향후 사용을 AWS 위해에서 예약했습니다. + `10.0.0.255`: 네트워크 브로드캐스트 주소. VPC에서는 브로드캐스트를 지원하지 않습니다. 이 주소는 예약되어 있습니다. **권장 솔루션:** VPC가 예약된 IP 주소를 사용하는지 확인합니다. 예약된 IP 주소를 예약되지 않은 IP 주소로 바꿉니다. 자세한 내용은 *Amazon VPC 사용 설명서*의 [VPC 및 서브넷 크기 조정](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#VPC_Sizing)을 참조하세요. ## 오류: "Unable to download cache: RequestError: Send request failed caused by: x509: Failed to load system roots and no roots provided" **문제:** 빌드 프로젝트를 실행하려고 하면 이 오류가 표시되면서 빌드가 실패합니다. **가능한 원인:** 캐시를 빌드 프로젝트의 일부로 구성했으며 만료된 루트 인증서가 포함된 기존 도커 이미지를 사용하고 있습니다. **권장 솔루션:** 프로젝트에서 사용 중인 Docker 이미지를 업데이트 AWS CodeBuild 합니다. 자세한 내용은 [CodeBuild가 제공하는 도커 이미지](build-env-ref-available.md) 단원을 참조하십시오. ## 오류: "Unable to download certificate from S3. AccessDenied" **문제:** 빌드 프로젝트를 실행하려고 하면 이 오류가 표시되면서 빌드가 실패합니다. **가능한 원인:** + 인증서에 대해 잘못된 S3 버킷을 선택한 것입니다. + 인증서에 대해 잘못된 객체 키를 입력한 것입니다. **권장 솔루션:** + 프로젝트를 편집합니다. **Bucket of certificate(인증서 버킷)**에 SSL 인증서가 저장된 S3 버킷을 선택합니다. + 프로젝트를 편집합니다. **인증서의 객체 키**에 S3 객체 키의 이름을 입력합니다. ## 오류: "Unable to locate credentials" **문제:**를 실행하거나 AWS CLI SDK를 AWS 사용하거나 빌드의 일부로 다른 유사한 구성 요소를 호출하려고 하면 AWS CLI, , AWS SDK 또는 구성 요소와 직접 관련된 빌드 오류가 발생합니다. 예를 들어 `Unable to locate credentials`와 같은 빌드 오류가 발생할 수 있습니다. **가능한 원인:** + 빌드 환경의 AWS CLI, AWS SDK 또는 구성 요소의 버전이와 호환되지 않습니다 AWS CodeBuild. + Docker를 사용하는 빌드 환경 내에서 Docker 컨테이너를 실행 중이며 컨테이너는 기본적으로 AWS 자격 증명에 액세스할 수 없습니다. **권장 솔루션:** + 빌드 환경에 다음 버전 이상의 AWS CLI, AWS SDK 또는 구성 요소가 있는지 확인합니다. + AWS CLI: 1.10.47 + AWS C\$1\$1용 SDK: 0.2.19 + AWS Go용 SDK: 1.2.5 + AWS Java용 SDK: 1.11.16 + AWS JavaScript용 SDK: 2.4.7 + AWS PHP용 SDK: 3.18.28 + AWS Python용 SDK(Boto3): 1.4.0 + AWS SDK for Ruby: 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 ``` 1. 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 . ``` ## 프록시 서버에서 CodeBuild를 실행할 때 RequestError 시간 초과 오류 **문제:** 다음 중 하나와 비슷한 `RequestError` 오류가 발생합니다. + CloudWatch Logs의 `RequestError: send request failed caused by: Post https://logs..amazonaws.com/: dial tcp 52.46.158.105:443: i/o timeout` + 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를 명시적 프록시 서버로 구성](run-codebuild-in-explicit-proxy-server.md#use-proxy-server-explicit-squid-configure) 단원을 참조하십시오. + 다음 단계에 따라 Amazon S3 및 CloudWatch Logs에 대해 프라이빗 엔드포인트를 사용합니다. 1. 프라이빗 서브넷 라우팅 테이블에서 이전에 추가한 인터넷으로 향하는 트래픽을 프록시 서버로 라우팅하는 규칙을 제거합니다. 자세한 내용은 Amazon VPC 사용 설명서의 [VPC에서 서브넷 만들기](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#AddaSubnet)를 참조하세요.** 1. 프라이빗 Amazon S3 엔드포인트 및 CloudWatch Logs 엔드포인트를 생성한 후 Amazon VPC의 프라이빗 서브넷과 연결합니다. 자세한 내용은 Amazon VPC 사용 설명서의 [VPC 엔드포인트 서비스](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-service.html)를 참조하세요.** 1. Amazon VPC에서 **프라이빗 DNS 이름 활성화**가 선택되었는지 확인합니다. 자세한 내용은 *Amazon VPC 사용 설명서*의 [인터페이스 엔드포인트 생성](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#create-interface-endpoint)을 참조하세요. + 명시적 프록시 서버에 `ssl-bump`를 사용하지 않을 경우 `proxy` 요소를 사용하여 buildspec 파일에 프록시 구성을 추가하십시오. 자세한 내용은 [명시적 프록시 서버에서 CodeBuild 실행](run-codebuild-in-explicit-proxy-server.md) 및 [buildspec 구문](build-spec-ref.md#build-spec-ref-syntax) 섹션을 참조하세요. ``` version: 0.2 proxy: upload-artifacts: yes logs: yes phases: build: commands: ``` ## 빌드 이미지에 있어야 하는 Bourne 쉘(sh) **문제:**에서 제공하지 않는 빌드 이미지를 사용하고 AWS CodeBuild있으며 메시지와 함께 빌드가 실패합니다`Build container found dead before completing the build`. **가능한 원인:** Bourne 쉘(`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`). ## 빌드를 시작하지 못함 **문제:** 빌드를 시작할 때 **빌드를 시작하지 못함** 오류 메시지가 나타납니다. **가능한 원인:** 동시 빌드 수에 도달했습니다. **권장 솔루션:** 다른 빌드가 완료될 때까지 기다리거나 프로젝트의 동시 빌드 제한을 늘린 다음, 빌드를 다시 시작하세요. 자세한 내용은 [프로젝트 구성](create-project.md#create-project-console-project-config) 단원을 참조하십시오. ## 로컬로 캐시된 빌드의 GitHub 메타데이터에 액세스 **문제:** 캐시된 빌드의 .git 디렉터리가 디렉터리가 아닌 텍스트 파일인 경우가 있습니다. **가능한 원인:** 빌드에 대해 로컬 소스 캐싱이 활성화되면 CodeBuild는 `.git` 디렉터리에 대한 gitlink를 생성합니다. 즉, `.git` 디렉터리는 실제로 디렉터리 경로가 포함된 텍스트 파일입니다. **권장 솔루션:** 모든 경우에 다음 명령을 사용하여 Git 메타데이터 디렉터리를 가져오세요. 이 명령은 다음과 같은 `.git` 형식에 관계없이 작동합니다. ``` git rev-parse --git-dir ``` ## AccessDenied: 보고서 그룹의 버킷 소유자가 S3 버킷 소유자와 일치하지 않습니다. **문제:** Amazon S3 버킷에 테스트 데이터를 업로드할 때 CodeBuild가 테스트 데이터를 버킷에 쓸 수 없습니다. **가능한 원인:** + 보고서 그룹 버킷 소유자로 지정된 계정이 Amazon S3 버킷 소유자와 일치하지 않습니다. + 서비스 역할에는 버킷에 대한 쓰기 권한이 없습니다. **권장 솔루션:** + Amazon S3 버킷 소유자와 일치하도록 보고서 그룹 버킷 소유자를 변경합니다. + Amazon S3 버킷에 대한 쓰기 액세스 권한을 허용하도록 서비스 역할을 수정합니다. ## 오류: CodeConnections를 사용하여 CodeBuild 프로젝트 생성 시 '자격 증명에 필요한 권한 범위가 하나 이상 없음' **문제:** CodeConnections를 사용하여 CodeBuild 프로젝트를 만들 때 Bitbucket 웹후크를 설치할 권한이 없습니다. **가능한 원인:** + Bitbucket 계정에서 새 권한 범위가 수락되지 않았을 수 있습니다. **권장 솔루션:** + 새 권한을 수락하려면 Bitbucket,에서 보낸 **작업 필요 - Scopes for AWS CodeStar**라는 제목의 이메일을 수신했어야 합니다`notifications-noreply@bitbucket.org`. 이메일에는 기존 CodeConnections Bitbucket 앱 설치에 웹후크 권한을 부여하는 링크가 포함되어 있습니다. + 이메일을 찾을 수 없는 경우 `https://bitbucket.org/site/addons/reauthorize?account=&addon_key=aws-codestar` 또는 `https://bitbucket.org/site/addons/reauthorize?addon_key=aws-codestar`로 이동하고 웹후크 권한을 부여하려는 워크스페이스를 선택하여 권한을 부여할 수 있습니다. ![\[워크스페이스에 웹후크 권한을 부여합니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/bitbucket-csc.png) ## 오류: Ubuntu 설치 명령을 사용하여 빌드 시 '죄송합니다. 터미널이 전혀 요청되지 않았습니다. 입력을 가져올 수 없습니다' **문제:** GPU 컨테이너 권한 빌드를 실행하는 경우 이 [절차](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html#installing-with-apt)에 따라 NVIDIA 컨테이너 툴킷을 설치할 수 있습니다. 최신 CodeBuild 이미지 릴리스에서 CodeBuild는 최신 `amazonlinux` 및 `ubuntu` 큐레이션 이미지에 `nvidia-container-toolkit`을 사용하여 Docker를 사전 설치하고 구성합니다. 이 절차를 따르면 Ubuntu 설치 명령을 사용한 빌드가 실패하고 다음 오류가 발생합니다. ``` Running command curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | gpg --dearmor --no-tty -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg gpg: Sorry, no terminal at all requested - can't get input curl: (23) Failed writing body ``` **가능한 원인:** gpg 키가 이미 동일한 위치에 있습니다. **권장 솔루션:** `nvidia-container-toolkit`이 이미지에 이미 설치되어 있습니다. 이 오류가 표시되면 buildspec에서 Docker 설치 및 재시작 프로세스를 건너뛸 수 있습니다.