빌드 프로젝트 설정 변경(콘솔)빌드 프로젝트 설정 변경(AWS CLI)빌드 프로젝트 설정 변경 (AWS SDKs)

에서 빌드 프로젝트 설정 변경 AWS CodeBuild

AWS CodeBuild 콘솔 AWS CLI, 또는 AWS SDKs 를 사용하여 빌드 프로젝트의 설정을 변경할 수 있습니다.

빌드 프로젝트에 테스트 보고를 추가하는 경우 IAM 역할에 에 설명된 권한이 있는지 확인하세요테스트 보고서 권한.

주제

빌드 프로젝트 설정 변경(콘솔)
빌드 프로젝트 설정 변경(AWS CLI)
빌드 프로젝트 설정 변경 (AWS SDKs)

빌드 프로젝트 설정 변경(콘솔)

빌드 프로젝트의 설정을 변경하려면 다음 절차에 수행하세요.

AWS CodeBuild https://console.aws.amazon.com/codesuite/코드빌드/홈에서 콘솔을 엽니다.
탐색 창에서 프로젝트 빌드를 선택합니다.
다음 중 하나를 수행합니다.
- 변경하려는 빌드 프로젝트의 링크를 선택한 다음 Edit project(프로젝트 편집)를 선택합니다.
- 변경하려는 빌드 프로젝트 옆에 있는 라디오 버튼을 선택하고 세부 정보 보기를 선택한 후 빌드 세부 정보를 선택합니다.

다음 섹션을 수정할 수 있습니다.

프로젝트 구성

프로젝트 구성 섹션에서 편집을 선택합니다. 변경이 완료되면 구성 업데이트를 선택하여 새 구성을 저장합니다.

다음 속성을 수정할 수 있습니다.

설명

선택적으로 빌드 프로젝트에 대한 설명을 입력하여 다른 사용자가 이 프로젝트의 용도를 이해하도록 도울 수 있습니다.

빌드 배지

프로젝트의 빌드 상태를 표시하고 삽입 가능하게 하려면 Enable build badge(빌드 배치 활성화)를 선택합니다. 자세한 내용은 빌드 배지 샘플 단원을 참조하십시오.

참고

소스 공급자가 Amazon S3인 경우 빌드 배지가 적용되지 않습니다.

동시 빌드 제한 활성화

이 프로젝트의 동시 빌드 수를 제한하려면 다음 단계를 수행합니다.

이 프로젝트에서 시작할 수 있는 동시 빌드 수 제한을 선택합니다.
동시 빌드 제한에 이 프로젝트에 허용되는 최대 동시 빌드 수를 입력합니다. 이 제한은 계정에 설정된 동시 빌드 제한보다 클 수 없습니다. 계정 제한보다 큰 숫자를 입력하려고 하면 오류 메시지가 표시됩니다.

현재 빌드 수가 이 한도 이하인 경우에만 새 빌드가 시작됩니다. 현재 빌드 수가 이 한도에 도달하면 새 빌드가 제한되고 실행되지 않습니다.

퍼블릭 빌드 액세스 활성화

AWS 계정에 액세스할 수 없는 사용자를 포함하여 모든 사람이 프로젝트의 빌드 결과를 사용할 수 있게 하려면 공개 빌드 액세스 활성화를 선택하고 빌드 결과를 공개할 것인지 확인합니다. 퍼블릭 빌드 프로젝트에는 다음과 같은 속성이 사용됩니다.

퍼블릭 빌드 서비스 역할

새 서비스 역할을 직접 CodeBuild 만들려면 새 서비스 역할을 선택하고, 기존 서비스 역할을 사용하려면 기존 서비스 역할을 선택합니다.

공개 빌드 서비스 역할을 사용하면 CodeBuild CloudWatch 로그를 읽고 프로젝트 빌드의 Amazon S3 아티팩트를 다운로드할 수 있습니다. 이 역할은 프로젝트의 빌드 로그와 아티팩트를 퍼블릭으로 지정하는 데 필요합니다.

서비스 역할

새 서비스 역할 또는 기존 서비스 역할의 이름을 입력합니다.

프로젝트의 빌드 결과를 프라이빗으로 설정하려면 퍼블릭 빌드 액세스 활성화를 선택 취소합니다.

자세한 내용은 공개 빌드 프로젝트 받기 URLs 단원을 참조하십시오.

주의

프로젝트의 빌드 결과를 퍼블릭으로 유지할 때는 다음에 유의해야 합니다.

프로젝트가 프라이빗일 때 실행된 빌드를 포함하여 프로젝트의 모든 빌드 결과, 로그, 아티팩트는 누구나 이용할 수 있습니다.
모든 빌드 로그와 아티팩트는 누구나 이용할 수 있습니다. 환경 변수, 소스 코드 및 기타 중요한 정보가 빌드 로그와 아티팩트에 출력되었을 수 있습니다. 빌드 로그에 출력되는 정보에 주의해야 합니다. 몇 가지 모범 사례는 다음과 같습니다.
- 민감한 값, 특히 AWS 액세스 IDs 키와 보안 액세스 키는 환경 변수에 저장하지 마십시오. Amazon EC2 Systems Manager 파라미터 스토어를 사용하거나 민감한 값을 저장하는 AWS Secrets Manager 것이 좋습니다.
- webhook를 최대한 안전하게 보호하려면 webhook 사용 모범 사례에 따라 빌드를 트리거할 수 있는 엔터티를 제한하고, buildspec을 프로젝트 자체에 저장하지 마세요.
악의적인 사용자는 퍼블릭 빌드를 사용하여 악성 아티팩트를 배포할 수 있습니다. 프로젝트 관리자는 모든 풀 요청을 검토하여 풀 요청이 합법적인 변경인지 확인하는 것이 좋습니다. 또한 체크섬으로 모든 아티팩트의 유효성을 검사하여 올바른 아티팩트가 다운로드되고 있는지 확인하는 것이 좋습니다.

추가 정보

태그에는 지원 AWS 서비스에서 사용할 태그의 이름과 값을 입력합니다. [Add row]를 사용하여 태그를 추가합니다. 최대 50개의 태그를 추가할 수 있습니다.

소스

소스 섹션에서 편집을 선택합니다. 변경이 완료되면 구성 업데이트를 선택하여 새 구성을 저장합니다.

다음 속성을 수정할 수 있습니다.

소스 공급자: 소스 코드 공급자 유형을 선택합니다. 다음 목록을 사용하여 소스 공급자에 알맞은 유형을 선택합니다.

참고
CodeBuild Bitbucket 서버는 지원하지 않습니다.

Amazon S3

버킷: 소스 코드가 포함된 입력 버킷의 이름을 선택합니다.
S3 객체 키 또는 S3 폴더: ZIP파일 이름 또는 소스 코드가 들어 있는 폴더의 경로를 입력합니다. S3 버킷의 모든 항목을 다운로드하려면 슬래시(/)를 입력합니다.
소스 버전: 입력 파일의 빌드를 나타내는 객체의 버전 ID를 입력합니다. 자세한 내용은 소스 버전 샘플 포함 AWS CodeBuild 단원을 참조하십시오.

CodeCommit

리포지토리: 사용할 리포지토리를 선택합니다.
참조 유형: 분기, Git 태그 또는 커밋 ID를 선택하여 소스 코드 버전을 지정합니다. 자세한 내용은 소스 버전 샘플 포함 AWS CodeBuild 단원을 참조하십시오.

참고
IDs커밋처럼 보이지 않는 Git 브랜치 이름 (예: 또는) 을 선택하는 것이 좋습니다. 811dd1ba1aba14473856cee38308caed7190c0d 5392f7 이렇게 하면 실제 커밋과 Git 체크아웃이 충돌하는 것을 방지할 수 있습니다.
Git clone 깊이: 이력이 지정된 커밋 수로 잘린 부분 복제를 생성하려면 선택합니다. 전체 복제가 필요할 경우 전체를 선택합니다.
Git 하위 모듈: 리포지토리에 Git 하위 모듈을 포함하려면 Use Git submodules(Git 하위 모듈 사용)를 선택합니다.

Bitbucket

자격 증명

기본 소스 자격 증명 또는 사용자 지정 소스 자격 증명을 선택하고 지침에 따라 기본 소스 자격 증명을 관리하거나 원본 자격 증명을 사용자 지정합니다.

연결 유형

연결할 CodeConnectionsOAuth, 앱 암호 또는 개인용 액세스 토큰을 선택합니다 CodeBuild.

Connection

지정한 연결 유형을 통해 연결하려면 Bitbucket 연결 또는 Secrets Manager 암호를 선택합니다.

리포지토리

내 Bitbucket 계정 또는 공용 리포지토리에서 리포지토리를 선택하고 리포지토리를 입력합니다. URL

소스 버전

분기, 커밋 ID, 태그 또는 참조와 커밋 ID를 입력합니다. 자세한 내용은 소스 버전 샘플 포함 AWS CodeBuild 단원을 참조하세요.

참고

IDs커밋처럼 보이지 않는 Git 브랜치 이름 (예: 또는) 을 선택하는 것이 좋습니다. 811dd1ba1aba14473856cee38308caed7190c0d 5392f7 이렇게 하면 실제 커밋과 Git 체크아웃이 충돌하는 것을 방지할 수 있습니다.

Git clone 깊이

Git clone 깊이를 선택하면 이력이 지정된 커밋 수로 잘린 부분 복제가 생성됩니다. 전체 복제가 필요할 경우 전체를 선택합니다.

Git 하위 모듈

리포지토리에 Git 하위 모듈을 포함하려면 Use Git submodules(Git 하위 모듈 사용)를 선택합니다.

빌드 상태

빌드 시작 및 완료 상태가 소스 공급자에게 보고되도록 하려면 빌드가 시작되고 완료될 때 소스 공급자에게 빌드 상태 보고를 선택합니다.

소스 공급자에게 빌드 상태를 보고하려면 소스 공급자와 연결된 사용자에게 리포지토리에 대한 쓰기 권한이 있어야 합니다. 사용자에게 쓰기 권한이 없는 경우 빌드 상태를 업데이트할 수 없습니다. 자세한 내용은 소스 공급자 액세스 단원을 참조하십시오.

상태 컨텍스트의 경우 Bitbucket 커밋 상태의 name 파라미터에 사용할 값을 입력합니다. 자세한 내용은 Bitbucket API설명서의 빌드를 참조하십시오.

URL타겟의 경우 Bitbucket 커밋 상태에 url 파라미터에 사용할 값을 입력합니다. 자세한 내용은 Bitbucket API설명서의 빌드를 참조하십시오.

Webhook에 의해 트리거된 빌드의 상태는 항상 소스 공급자에게 보고됩니다. 콘솔에서 시작된 빌드의 상태 또는 소스 공급자에게 API 호출이 보고되도록 하려면 이 설정을 선택해야 합니다.

프로젝트 빌드가 webhook에 의해 트리거되는 경우 이 설정의 변경 사항을 적용하려면 새 커밋을 리포지토리에 푸시해야 합니다.

코드 변경 사항이 이 리포지토리에 푸시될 때마다 소스 코드를 빌드하려면 기본 소스 웹후크 이벤트에서 코드 변경 사항이 이 리포지토리에 푸시될 때마다 재빌드를 선택합니다. CodeBuild webhook 및 필터 그룹에 대한 자세한 내용은 Bitbucket Webhook 이벤트 섹션을 참조하세요.

GitHub

자격 증명

연결 유형

연결할 GitHub 앱 또는 개인용 액세스 토큰을 선택합니다 CodeBuild. OAuth

Connection

지정한 GitHub 연결 유형을 통해 연결하려면 연결 또는 Secrets Manager 암호를 선택합니다.

리포지토리

내 GitHub 계정, 공용 리포지토리 또는 GitHub 범위가 지정된 웹후크에서 리포지토리를 선택하고 리포지토리를 입력합니다. URL

소스 버전

분기, 커밋 ID, 태그 또는 참조와 커밋 ID를 입력합니다. 자세한 내용은 소스 버전 샘플 포함 AWS CodeBuild 단원을 참조하세요.

참고

Git clone 깊이

Git clone 깊이를 선택하면 이력이 지정된 커밋 수로 잘린 부분 복제가 생성됩니다. 전체 복제가 필요할 경우 전체를 선택합니다.

Git 하위 모듈

리포지토리에 Git 하위 모듈을 포함하려면 Use Git submodules(Git 하위 모듈 사용)를 선택합니다.

빌드 상태

빌드 시작 및 완료 상태가 소스 공급자에게 보고되도록 하려면 빌드가 시작되고 완료될 때 소스 공급자에게 빌드 상태 보고를 선택합니다.

상태 컨텍스트의 경우 GitHub 커밋 상태의 context 파라미터에 사용할 값을 입력합니다. 자세한 내용은 GitHub 개발자 가이드의 커밋 상태 만들기를 참조하십시오.

URLTarget의 경우 GitHub 커밋 상태에 target_url 파라미터에 사용할 값을 입력합니다. 자세한 내용은 GitHub 개발자 가이드의 커밋 상태 만들기를 참조하십시오.

Webhook에 의해 트리거된 빌드의 상태는 항상 소스 공급자에게 보고됩니다. 콘솔에서 시작된 빌드의 상태 또는 소스 제공자에게 API 호출이 보고되도록 하려면 이 설정을 선택해야 합니다.

프로젝트 빌드가 webhook에 의해 트리거되는 경우 이 설정의 변경 사항을 적용하려면 새 커밋을 리포지토리에 푸시해야 합니다.

코드 변경 사항이 이 리포지토리에 푸시될 때마다 소스 코드를 빌드하려면 기본 소스 웹후크 이벤트에서 코드 변경 사항이 이 리포지토리에 푸시될 때마다 재빌드를 선택합니다. CodeBuild webhook 및 필터 그룹에 대한 자세한 내용은 GitHub 웹후크 이벤트 섹션을 참조하세요.

GitHub Enterprise Server

자격 증명

연결 유형

연결할 CodeConnections개인용 액세스 토큰을 선택합니다 CodeBuild.

Connection

지정한 연결 유형을 통해 연결하려면 GitHub 엔터프라이즈 연결 또는 Secrets Manager 암호를 선택합니다.

리포지토리

내 GitHub Enterprise 계정 또는 GitHub Enterprise 범위 웹훅에서 리포지토리를 선택하고 리포지토리를 입력합니다. URL

소스 버전

풀 요청, 분기, 커밋 ID, 태그 또는 참조와 커밋 ID를 입력합니다. 자세한 내용은 소스 버전 샘플 포함 AWS CodeBuild 단원을 참조하십시오.

참고

Git clone 깊이

Git clone 깊이를 선택하면 이력이 지정된 커밋 수로 잘린 부분 복제가 생성됩니다. 전체 복제가 필요할 경우 전체를 선택합니다.

Git 하위 모듈

리포지토리에 Git 하위 모듈을 포함하려면 Use Git submodules(Git 하위 모듈 사용)를 선택합니다.

빌드 상태

빌드 시작 및 완료 상태가 소스 공급자에게 보고되도록 하려면 빌드가 시작되고 완료될 때 소스 공급자에게 빌드 상태 보고를 선택합니다.

프로젝트 빌드가 webhook에 의해 트리거되는 경우 이 설정의 변경 사항을 적용하려면 새 커밋을 리포지토리에 푸시해야 합니다.

안전하지 않음 SSL

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

GitLab

자격 증명

연결 유형

CodeConnections연결하는 GitLab 데 사용됩니다 CodeBuild.

Connection

연결할 GitLab 연결을 선택합니다 CodeConnections.

리포지토리

사용할 리포지토리를 선택합니다.

소스 버전

풀 리퀘스트 ID, 브랜치, 커밋 ID, 태그 또는 참조와 커밋 ID를 입력합니다. 자세한 내용은 소스 버전 샘플 포함 AWS CodeBuild 단원을 참조하십시오.

참고

Git clone 깊이

Git clone 깊이를 선택하면 이력이 지정된 커밋 수로 잘린 부분 복제가 생성됩니다. 전체 복제가 필요할 경우 전체를 선택합니다.

빌드 상태

빌드 시작 및 완료 상태가 소스 공급자에게 보고되도록 하려면 빌드가 시작되고 완료될 때 소스 공급자에게 빌드 상태 보고를 선택합니다.

GitLab Self Managed

자격 증명

연결 유형

CodeConnections GitLab 셀프 매니지드를 연결하는 데 사용됩니다 CodeBuild.

Connection

연결할 GitLab 자체 관리형 연결을 선택합니다 CodeConnections.

리포지토리

사용할 리포지토리를 선택합니다.

소스 버전

풀 리퀘스트 ID, 브랜치, 커밋 ID, 태그 또는 참조와 커밋 ID를 입력합니다. 자세한 내용은 소스 버전 샘플 포함 AWS CodeBuild 단원을 참조하십시오.

참고

Git clone 깊이

Git clone 깊이를 선택하면 이력이 지정된 커밋 수로 잘린 부분 복제가 생성됩니다. 전체 복제가 필요할 경우 전체를 선택합니다.

빌드 상태

빌드 시작 및 완료 상태가 소스 공급자에게 보고되도록 하려면 빌드가 시작되고 완료될 때 소스 공급자에게 빌드 상태 보고를 선택합니다.

환경

환경 섹션에서 편집을 선택합니다. 변경이 완료되면 구성 업데이트를 선택하여 새 구성을 저장합니다.

다음 속성을 수정할 수 있습니다.

프로비저닝 모델

프로비저닝 모델을 변경하려면 프로비저닝 모델 변경을 선택하고 다음 중 하나를 수행하십시오.

에서 관리하는 온디맨드 플릿을 사용하려면 온디맨드를 선택합니다. AWS CodeBuild 온디맨드 플릿을 사용하면 빌드에 필요한 컴퓨팅 CodeBuild 기능을 제공합니다. 빌드가 완료되면 머신이 파괴됩니다. 온디맨드 플릿은 완전 관리형이며, 수요 급증을 처리할 수 있는 자동 규모 조정 기능이 포함되어 있습니다.
에서 관리하는 예약 용량 플릿을 사용하려면 예약 용량을 선택한 다음 플릿 이름을 선택합니다. AWS CodeBuild 예약 용량 플릿을 사용하면 빌드 환경을 위한 전용 인스턴스 세트를 구성할 수 있습니다. 이러한 머신은 유휴 상태로 유지되므로 빌드 또는 테스트를 즉시 처리하고 빌드 기간을 단축할 수 있습니다. 예약 용량 플릿을 사용하면 머신이 상시 가동되므로 프로비저닝하는 한 계속해서 비용이 발생합니다.

자세한 내용은 예약된 용량 플릿에서 빌드 실행을 참조하세요.

환경 이미지

빌드 이미지를 변경하려면 이미지 재정의를 선택하고 다음 중 하나를 수행합니다.

관리되는 AWS CodeBuild Docker 이미지를 사용하려면 관리 이미지를 선택한 다음 운영 체제, 런타임, 이미지 및 이미지 버전 중에서 선택합니다. 사용 가능한 경우 환경 유형에서 항목을 선택합니다.
다른 도커 이미지를 사용하려면 사용자 지정 이미지를 선택합니다. 환경 유형으로는 리눅스, 리눅스 ARM, 윈도우 중 하나를 선택합니다. GPU 기타 레지스트리를 선택한 경우 외부 레지스트리에 URL 대해 다음 형식을 사용하여 Docker Hub에 Docker 이미지의 이름과 태그를 입력합니다. docker repository/docker image name ECRAmazon을 선택하는 경우 Amazon ECR 리포지토리와 Amazon ECR 이미지를 사용하여 AWS 계정에서 Docker 이미지를 선택하십시오.
프라이빗 도커 이미지를 사용하려면 사용자 지정 이미지를 선택합니다. 환경 유형으로는 리눅스 ARM, 리눅스, 윈도우 중 하나를 선택합니다. GPU 이미지 레지스트리의 경우 기타 레지스트리를 선택한 다음 프라이빗 Docker 이미지의 자격 증명을 입력합니다. ARN 보안 인증은 Secrets Manager에서 생성됩니다. 자세한 내용은 AWS Secrets Manager사용 설명서의 AWS Secrets Manager 이란? 섹션을 참조하세요.

참고

CodeBuild 사용자 지정 Docker 이미지의 ENTRYPOINT 경우 를 재정의합니다.

서비스 역할

다음 중 하나를 수행합니다.

서비스 역할이 없는 경우 새 CodeBuild 서비스 역할을 선택합니다. 역할 이름에 새 역할의 이름을 입력합니다.
CodeBuild 서비스 역할이 있는 경우 기존 서비스 역할을 선택합니다. ARN역할에서 서비스 역할을 선택합니다.

참고

콘솔을 사용하여 빌드 프로젝트를 만들 때 동시에 CodeBuild 서비스 역할을 만들 수 있습니다. 기본적으로 역할은 해당 빌드 프로젝트에서만 작동합니다. 콘솔을 사용하여 이 서비스 역할을 다른 빌드 프로젝트와 연결하는 경우 다른 빌드 프로젝트에서 작동하도록 역할이 업데이트됩니다. 하나의 서비스 역할은 최대 10개의 빌드 프로젝트에서 작동할 수 있습니다.

추가 구성

제한 시간

5분에서 36시간 사이의 값을 지정합니다. 이 값을 지정한 후 완료되지 않으면 빌드가 CodeBuild 중지됩니다. [hours] 및 [minutes]가 비어 있는 경우 기본값인 60분이 사용됩니다.

권한 있음

Docker 이미지를 빌드하거나 빌드에 높은 권한을 부여하려면 이 플래그 활성화를 선택합니다. 이 빌드 프로젝트를 사용하여 Docker 이미지를 빌드하려는 경우에만 가능합니다. 그렇지 않으면 Docker 데몬과 상호 작용을 시도하는 모든 연결된 빌드가 실패합니다. 또한 빌드가 상호 작용할 수 있도록 Docker 데몬을 시작해야 합니다. 이를 수행하는 한 가지 방법은 다음 빌드 명령을 실행하여 빌드 사양의 install 단계에서 Docker 데몬을 초기화하는 것입니다. Docker 지원에서 제공하는 CodeBuild 빌드 환경 이미지를 선택한 경우에는 이 명령을 실행하지 마세요.

참고

기본적으로 Docker 데몬은 빌드가 아닌 경우 활성화됩니다. VPC Docker 컨테이너를 VPC 빌드에 사용하려면 Docker Docs 웹 사이트의 런타임 권한 및 Linux 기능을 참조하고 권한 모드를 활성화하세요. 또한 Windows는 권한 모드를 지원하지 않습니다.


- 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"

VPC

다음과 같은 작업을 수행하려는 CodeBuild 경우: VPC

VPC를 위해 사용할 VPC ID를 선택하십시오. CodeBuild
VPC서브넷의 경우 사용하는 리소스가 포함된 CodeBuild 서브넷을 선택합니다.
VPC보안 그룹의 경우, 의 리소스에 대한 액세스를 허용하는 데 CodeBuild 사용하는 보안 그룹을 선택합니다. VPCs

자세한 내용은 Amazon Virtual Private 클라우드와 AWS CodeBuild 함께 사용 단원을 참조하십시오.

컴퓨팅

사용 가능한 옵션 중 하나를 선택합니다.

환경 변수

사용할 빌드의 각 환경 변수에 대해 이름 및 값을 입력하고 유형을 선택합니다.

참고

CodeBuild 해당 AWS 지역의 환경 변수를 자동으로 설정합니다. buildspec.yml에 추가하지 않은 경우 다음 환경 변수를 설정해야 합니다.

AWS_ACCOUNT_ID
IMAGE_REPO_NAME
IMAGE_TAG

콘솔 및 AWS CLI 사용자는 환경 변수를 볼 수 있습니다. 환경 변수의 가시성에 대한 문제가 없다면 [Name] 및 [Value] 필드를 설정한 다음 [Type]을 [Plaintext]로 설정합니다.

AWS 액세스 키 ID, AWS 보안 액세스 키 또는 암호와 같은 민감한 값이 포함된 환경 변수를 Amazon EC2 Systems Manager 파라미터 스토어 또는 파라미터로 저장하는 것이 좋습니다 AWS Secrets Manager.

Amazon EC2 Systems Manager 파라미터 스토어를 사용하는 경우 유형에서 파라미터를 선택합니다. 이름에는 CodeBuild 참조할 식별자를 입력합니다. 값에는 Amazon EC2 Systems Manager 파라미터 스토어에 저장된 파라미터 이름을 입력합니다. 예를 들어 /CodeBuild/dockerLoginPassword라는 이름의 파라미터를 사용하여 유형에서 파라미터를 선택합니다. 이름에 LOGIN_PASSWORD을 입력합니다. 값에 /CodeBuild/dockerLoginPassword를 입력합니다.

중요

Amazon EC2 Systems Manager 파라미터 스토어를 사용하는 경우, 로 시작하는 파라미터 이름 /CodeBuild/ (예:/CodeBuild/dockerLoginPassword) 으로 파라미터를 저장하는 것이 좋습니다. CodeBuild 콘솔을 사용하여 Amazon EC2 Systems Manager에서 파라미터를 생성할 수 있습니다. 파라미터 생성을 선택하고 대화 상자에 표시되는 지시에 따릅니다. (이 대화 상자에서 KMS키에 대해 계정에 있는 ARN AWS KMS 키의 이름을 지정할 수 있습니다. Amazon EC2 Systems Manager는 이 키를 사용하여 저장 중에 파라미터 값을 암호화하고 검색 중에 이를 복호화합니다.) 콘솔을 사용하여 파라미터를 생성하는 경우 CodeBuild 콘솔은 저장되는 동안 파라미터 이름을 사용하여 /CodeBuild/ 해당 파라미터 이름을 시작합니다. 자세한 내용은 Amazon EC2Systems Manager 사용 설명서의 Systems Manager 파라미터 스토어 및 Systems Manager 파라미터 스토어 콘솔 안내를 참조하십시오.

빌드 프로젝트가 Amazon EC2 Systems Manager 파라미터 스토어에 저장된 파라미터를 참조하는 경우 빌드 프로젝트의 서비스 역할이 ssm:GetParameters 작업을 허용해야 합니다. 이전에 새 서비스 역할을 선택한 경우 빌드 프로젝트의 기본 서비스 역할에 이 작업을 CodeBuild 포함하십시오. Existing service role(기존 서비스 역할)을 선택한 경우에는 이 작업을 서비스 역할에 별도로 포함해야 합니다.

빌드 프로젝트가 Amazon EC2 Systems Manager Parameter Store에 저장된 파라미터로 /CodeBuild/ 시작되지 않는 파라미터를 참조하고 New service role (새 서비스 역할) 을 선택한 경우, 로 시작하지 않는 파라미터 이름에 대한 액세스를 허용하도록 해당 서비스 역할을 업데이트해야 /CodeBuild/ 합니다. 이는 서비스 역할이 /CodeBuild/로 시작하는 파라미터 이름에만 액세스할 수 있기 때문입니다.

새 서비스 역할을 선택하면 서비스 역할에 Amazon EC2 Systems Manager 파라미터 스토어의 /CodeBuild/ 네임스페이스 아래에 있는 모든 파라미터를 복호화할 수 있는 권한이 포함됩니다.

사용자가 설정한 환경 변수는 기존 환경 변수를 대체합니다. 예를 들어 도커 이미지에 값이 my_value인 MY_VAR이라는 환경 변수가 이미 포함되어 있는데, 사용자가 MY_VAR 환경 변수의 값을 other_value로 설정하면, my_value가 other_value로 바뀝니다. 마찬가지로, 도커 이미지에 값이 /usr/local/sbin:/usr/local/bin인 PATH라는 환경 변수가 이미 포함되어 있는데, 사용자가 PATH 환경 변수의 값을 $PATH:/usr/share/ant/bin으로 설정하면, /usr/local/sbin:/usr/local/bin이 $PATH:/usr/share/ant/bin 리터럴 값으로 바뀝니다.

CODEBUILD_로 시작하는 이름으로 환경 변수를 설정하지 마십시오. 이 접두사는 내부 전용으로 예약되어 있습니다.

여러 위치에서 동일한 이름의 환경 변수가 정의되는 경우, 다음과 같이 값이 결정됩니다.

시작 빌드 작업 호출의 값이 가장 높은 우선 순위를 갖습니다.
빌드 프로젝트 정의의 값이 다음 우선 순위를 갖습니다.
buildspec 선언의 값이 가장 낮은 우선 순위를 갖습니다.

Secrets Manager를 사용하는 경우 유형으로 Secrets Manager로 선택합니다. [Name] 에는 참조할 식별자를 입력합니다. CodeBuild 값에 secret-id:json-key:version-stage:version-id 패턴을 사용하여 reference-key를 입력합니다. 자세한 내용은 Secrets Manager reference-key in the buildspec file을 참조하세요.

중요

Secrets Manager를 사용하는 경우 이름이 /CodeBuild/로 시작하는 암호를 저장하는 것이 좋습니다(예: /CodeBuild/dockerLoginPassword). 자세한 내용은 AWS Secrets Manager사용 설명서의 AWS Secrets Manager 이란? 섹션을 참조하세요.

빌드 프로젝트가 Secrets Manager에 저장된 암호를 참조하는 경우 해당 빌드 프로젝트의 서비스 역할은 secretsmanager:GetSecretValue 작업을 허용해야 합니다. 이전에 새 서비스 역할을 선택한 경우 빌드 프로젝트의 기본 서비스 역할에 이 작업을 CodeBuild 포함시키십시오. Existing service role(기존 서비스 역할)을 선택한 경우에는 이 작업을 서비스 역할에 별도로 포함해야 합니다.

빌드 프로젝트가 /CodeBuild/로 시작되지 않는 보안 암호 이름으로 Secrets Manager에 저장된 암호를 참조하는 경우 새 서비스 역할을 선택하면 /CodeBuild/로 시작하지 않는 보안 암호 이름에 액세스할 수 있도록 해당 서비스 역할을 업데이트해야 합니다. 이는 서비스 역할이 /CodeBuild/로 시작하는 암호 이름에만 액세스할 수 있기 때문입니다.

새 서비스 역할을 선택하면 에 있는 /CodeBuild/ 네임스페이스의 모든 암호를 해독할 권한이 서비스 역할에 포함됩니다.

Buildspec

Buildspec 섹션에서 편집을 선택합니다. 변경이 완료되면 구성 업데이트를 선택하여 새 구성을 저장합니다.

다음 속성을 수정할 수 있습니다.

빌드 사양

다음 중 하나를 수행합니다.

소스 코드에 buildspec 파일이 있는 경우 Use a buildspec file(빌드 사양 파일 사용) 을 선택합니다. 기본적으로 소스 코드 루트 buildspec.yml 디렉터리에서 이름이 지정된 파일을 CodeBuild 찾습니다. buildspec 파일이 다른 이름이나 위치를 사용하는 경우 Buildspec 이름에 소스 루트에서의 경로를 입력합니다 (예: 또는. buildspec-two.yml configuration/buildspec.yml buildspec 파일이 S3 버킷에 있는 경우 해당 파일은 빌드 프로젝트와 동일한 리전에 있어야 합니다. AWS 이를 사용하여 빌드스펙 파일을 지정합니다 (예:). ARN arn:aws:s3:::<my-codebuild-sample2>/buildspec.yml
소스 코드에 buildspec 파일이 포함되어 있지 않거나, 소스 코드의 루트 디렉터리에 있는 buildspec.yml 파일의 build 단계에 지정된 것과 다른 빌드 명령 세트를 실행하려는 경우 빌드 명령 삽입을 선택합니다. 빌드 명령의 build 단계에서 실행하려는 명령을 입력합니다. 명령이 여러 개인 경우 각 명령을 &&로 구분합니다(예: mvn test && mvn package). 다른 구문에서 명령을 실행하려는 경우 또는 build 단계에 대해 특히 긴 명령 목록이 있는 경우에는 소스 코드 루트 디렉터리에 buildspec.yml 파일을 추가하고, 이 파일에 명령을 추가한 다음, 소스 코드 루트 디렉터리에서 buildspec.yml 사용을 선택합니다.

자세한 정보는 buildspec 참조 단원을 참조하십시오.

배치 구성

배치 구성 섹션에서 편집을 선택합니다. 변경이 완료되면 구성 업데이트를 선택하여 새 구성을 저장합니다. 자세한 내용은 빌드를 일괄적으로 실행합니다. 단원을 참조하십시오.

다음 속성을 수정할 수 있습니다.

배치 서비스 역할

배치 빌드에 대한 서비스 역할을 제공합니다.

다음 중 하나를 선택합니다.

배치 서비스 역할이 없는 경우 새 서비스 역할을 선택합니다. 서비스 역할에 새 역할의 이름을 입력합니다.
배치 서비스 역할이 있는 경우 기존 서비스 역할을 선택합니다. 서비스 역할에서 서비스 역할을 선택합니다.

배치 빌드는 배치 구성에 새로운 보안 역할을 도입합니다. 일괄 처리의 일부로 빌드를 실행하려면 사용자 대신StartBuild,StopBuild, RetryBuild 작업을 호출할 수 CodeBuild 있어야 하므로 이 새 역할이 필요합니다. 고객은 다음과 같은 두 가지 이유로 빌드에 사용하는 것과 동일한 역할이 아닌 새 역할을 사용해야 합니다.

빌드 역할 StartBuild, StopBuild 및 RetryBuild 권한을 부여하면 단일 빌드에서 buildspec을 통해 더 많은 빌드를 시작할 수 있습니다.
CodeBuild 배치 빌드는 일괄 빌드에 사용할 수 있는 빌드 및 컴퓨팅 유형의 수를 제한하는 제한을 제공합니다. 빌드 역할에 이러한 권한이 있는 경우 빌드 자체가 이러한 제한을 우회할 수 있습니다.

배치에 허용되는 컴퓨팅 유형

배치에 허용되는 컴퓨팅 유형을 선택합니다. 해당하는 항목을 모두 선택합니다.

배치에 허용되는 최대 빌드 수

배치에 허용되는 최대 빌드 수를 입력합니다. 이 제한을 초과하는 배치는 실패합니다.

배치 제한 시간

배치 빌드가 완료되는 최대 시간을 입력합니다.

아티팩트 결합

배치의 모든 아티팩트를 단일 위치로 결합을 선택하면 배치의 모든 아티팩트가 단일 위치로 결합됩니다.

배치 보고서 모드

배치 빌드에 대해 원하는 빌드 상태 보고서 모드를 선택합니다.

참고

이 필드는 프로젝트 소스가 Bitbucket 또는 GitHub Enterprise인 경우에만 사용할 수 있으며, 소스 아래에서 빌드 시작 및 종료를 선택하면 소스 공급자에게 빌드 상태를 보고할 수 있습니다. GitHub

빌드 집계: 배치의 모든 빌드 상태를 단일 상태 보고서로 통합하려면 선택합니다.
개별 빌드: 배치에 있는 모든 빌드의 빌드 상태를 별도로 보고하려면 선택합니다.

아티팩트

아티팩트 섹션에서 편집을 선택합니다. 변경이 완료되면 구성 업데이트를 선택하여 새 구성을 저장합니다.

다음 속성을 수정할 수 있습니다.

유형

다음 중 하나를 수행합니다.

빌드 출력 결과물을 생성하지 않으려면 [No artifacts]를 선택합니다. 빌드 테스트만 실행하거나 Docker 이미지를 Amazon ECR 리포지토리로 푸시하려는 경우 이 작업을 수행하는 것이 좋습니다.
S3 버킷에 빌드 출력을 저장하려면 Amazon S3를 선택하고 다음 작업을 수행합니다.
- 빌드 출력 ZIP 파일 또는 폴더에 프로젝트 이름을 사용하려면 이름을 비워 두십시오. 그렇지 않으면 이름을 입력합니다. (파일을 출력하고 싶은 ZIP 파일에 ZIP 파일 확장자를 지정하려면 ZIP 파일 이름 뒤에 포함해야 합니다.)
- buildspec 파일에 지정된 이름으로 콘솔에서 지정한 이름을 재정의하려는 경우 의미 체계 버전 관리 사용을 선택합니다. buildspec 파일의 이름은 빌드 시 계산되며 Shell 명령 언어를 사용합니다. 예를 들어 결과물 이름이 항상 고유하도록 날짜와 시간을 결과물 이름에 추가할 수 있습니다. 고유한 결과물 이름을 사용하면 결과물을 덮어쓰지 않을 수 있습니다. 자세한 내용은 buildspec 구문 단원을 참조하십시오.
- [Bucket name]에서 출력 버킷의 이름을 선택합니다.
- 이 절차의 앞부분에서 빌드 명령 삽입을 선택한 경우 출력 파일에 빌드 출력 파일 또는 폴더에 넣을 빌드의 ZIP 파일 위치를 입력합니다. 위치가 여러 개인 경우 각 위치를 쉼표로 구분합니다(예: appspec.yml, target/my-app.jar). 자세한 내용은 buildspec 구문의 files 설명을 참조하십시오.
- 빌드 아티팩트를 암호화하지 않으려면 Remove artifacts encryption(결과물 암호화 제거)을 선택합니다.

각각 원하는 보조 아티팩트 세트마다 다음과 같이 실행합니다.

Atrifact identifier(아티팩트 식별자)에서 128자 미만으로 영숫자와 밑줄만 포함된 값을 입력합니다.
Add artifact(아티팩트 추가)를 선택합니다.
이전 단계에 따라 보조 결과물을 구성합니다.
Save artifact(아티팩트 저장)를 선택합니다.

추가 구성

암호화 키

다음 중 하나를 수행합니다.

계정의 AWS 관리형 키 Amazon S3를 사용하여 빌드 출력 아티팩트를 암호화하려면 암호화 키를 비워 두십시오. 이 값이 기본값입니다.
고객 관리 키를 사용하여 빌드 출력 아티팩트를 암호화하려면 암호화 키에 고객 관리 키를 입력합니다. ARN arn:aws:kms:region-ID:account-ID:key/key-ID 형식을 사용합니다.

캐시 유형

Cache type(캐시 유형)에서 다음 중 하나를 선택합니다.

캐시를 사용하지 않으려면 [No cache]를 선택합니다.
Amazon S3 캐시를 사용하려면 Amazon S3를 선택하고 다음을 수행합니다.
- 버킷에서 캐시가 저장된 S3 버킷의 이름을 선택합니다.
- (선택 사항) 캐시 경로 접두사에 Amazon S3 경로 접두사를 입력합니다. Cache path prefix(캐시 경로 접두사) 값은 디렉터리 이름과 비슷합니다. 따라서 캐시를 버킷의 동일한 디렉터리에 저장할 수 있습니다.
  
  중요
  경로 접두사 끝에 후행 슬래시(/)를 추가하지 마십시오.
로컬 캐시를 사용하려면 로컬을 선택한 다음 하나 이상의 로컬 캐시 모드를 선택해야 합니다.

참고
Docker 계층 캐시 모드는 Linux에서만 사용할 수 있습니다. 이 모드를 선택할 경우 프로젝트를 권한이 있는 모드에서 실행해야 합니다.

캐시를 사용하면 빌드 환경의 재사용 가능한 특정 부분이 캐시에 저장되고 빌드 전반에서 사용되기 때문에 상당한 빌드 시간을 절약할 수 있습니다. buildspec 파일에 캐시를 지정하는 것에 대한 자세한 정보는 buildspec 구문 단원을 참조하십시오. 캐싱에 대한 자세한 정보는 캐시 빌드를 통한 성능 향상을 참조하십시오.

로그

로그 섹션에서 편집을 선택합니다. 변경이 완료되면 구성 업데이트를 선택하여 새 구성을 저장합니다.

다음 속성을 수정할 수 있습니다.

생성하려는 로그를 선택합니다. Amazon CloudWatch 로그, Amazon S3 로그 또는 둘 다를 생성할 수 있습니다.

CloudWatch

Amazon CloudWatch 로그 로그를 원하는 경우:

CloudWatch 로그: CloudWatch 로그를 선택합니다.
그룹 이름: Amazon CloudWatch Logs 로그 그룹 이름을 입력합니다.
스트림 이름: Amazon CloudWatch Logs 로그 스트림 이름을 입력합니다.

S3

Amazon S3 로그를 원할 경우:

S3 로그: S3 로그를 선택합니다.
버킷: 로그에 대한 S3 버킷 이름을 선택합니다.
경로 접두사: 로그의 접두사를 입력합니다.
S3 로그 암호화 비활성화: S3 로그를 암호화하지 않으려면 선택합니다.

빌드 프로젝트 설정 변경(AWS CLI)

with 사용에 대한 자세한 내용은 AWS CodeBuild를 참조하십시오명령줄 참조. AWS CLI

를 사용하여 CodeBuild 프로젝트를 AWS CLI업데이트하려면 업데이트된 속성이 포함된 JSON 파일을 만들고 해당 파일을 update-project명령에 전달합니다. 업데이트 파일에 포함되지 않은 속성은 변경되지 않습니다.

업데이트 JSON 파일에는 name 속성과 수정된 속성만 필요합니다. name 속성은 수정할 프로젝트를 식별합니다. 수정된 구조의 경우 해당 구조의 필수 파라미터도 포함되어야 합니다. 예를 들어, 프로젝트에 대한 환경을 수정하려면 environment/type 및 environment/computeType 속성이 필요합니다. 다음은 환경 이미지를 업데이트하는 예입니다.


{
  "name": "<project-name>",
  "environment": {
    "type": "LINUX_CONTAINER",
    "computeType": "BUILD_GENERAL1_SMALL",
    "image": "aws/codebuild/amazonlinux2-x86_64-standard:4.0"
  }
}

프로젝트의 현재 속성 값을 가져와야 하는 경우 batch-get-projects 명령을 사용하여 수정하려는 프로젝트의 현재 속성을 가져오고 결과를 파일에 기록합니다.


aws codebuild batch-get-projects --names "<project-name>" > project-info.json

The project-info.json 파일에는 프로젝트 배열이 포함되어 있으므로 프로젝트를 업데이트하는 데 직접 사용할 수는 없습니다. 하지만 수정하려는 속성은 다음에서 복사할 수 있습니다.project-info.json 수정하려는 속성의 기준으로 파일을 저장하여 업데이트 파일에 붙여넣습니다. 자세한 내용은 빌드 프로젝트 세부 정보 보기(AWS CLI) 단원을 참조하십시오.

에 설명된 대로 업데이트 JSON 파일을 빌드 프로젝트 생성(AWS CLI) 수정하고 결과를 저장합니다. 업데이트 JSON 파일 수정이 끝나면 update-project명령을 실행하여 업데이트 JSON 파일을 전달합니다.


aws codebuild update-project --cli-input-json file://<update-project-file>

성공하면 업데이트된 프로젝트가 출력에 JSON 나타납니다. 필수 파라미터가 누락된 경우 누락된 파라미터를 식별하는 오류 메시지가 출력에 표시됩니다. 예를 들어, environment/type 파라미터가 누락된 경우 표시되는 오류 메시지는 다음과 같습니다.


aws codebuild update-project --cli-input-json file://update-project.json

Parameter validation failed:
Missing required parameter in environment: "type"

빌드 프로젝트 설정 변경 (AWS SDKs)

AWS CodeBuild 와 함께 사용하는 방법에 대한 자세한 AWS SDKs 내용은 를 참조하십시오AWS SDK 및 도구 참조.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

알림 규칙 생성

다중 액세스 토큰