기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# CodeBuild용 사용 사례 기반 샘플
이러한 사용 사례 기반 샘플을 사용하여 AWS CodeBuild 사용을 실험할 수 있습니다.
[교차 서비스 샘플](cross-service-samples.md)
AWS CodeBuild를 실험할 교차 서비스 샘플 목록입니다.
[빌드 배지 샘플](sample-build-badges.md)
빌드 배지를 사용한 CodeBuild 설정 방법을 보여 줍니다.
[테스트 보고서 샘플](sample-test-report-cli.md)
AWS CLI를 사용하여 테스트 보고서를 작성하고, 실행하고, 결과를 봅니다.
[CodeBuild용 Docker 샘플](sample-docker-section.md)
사용자 지정 Docker 이미지를 사용하고, Amazon ECR의 리포지토리에 Docker 이미지를 게시하고, 프라이빗 레지스트리에서 Docker 이미지를 사용하는 방법을 보여줍니다.
[빌드 출력을 S3 버킷에서 호스팅 ](sample-disable-artifact-encryption.md)
S3 버킷에서 암호화되지 않은 빌드 아티팩트를 사용해 정적 웹사이트를 생성하는 방법을 보여줍니다.
[ 다중 입력 및 출력 샘플 ](sample-multi-in-out.md)
빌드 프로젝트에서 다중 입력 소스와 다중 출력 아티팩트를 사용하는 방법을 보여 줍니다.
[ 샘플의 병렬 테스트 실행 ](sample-parallel-test.md)
`codebuild-tests-run` CLI 명령을 사용하여 병렬 실행 환경 간에 테스트를 분할하고 실행하는 방법을 보여줍니다.
[ buildspec 파일 샘플의 런타임 버전 ](sample-runtime-versions.md)
buildspec 파일에서 런타임과 그 버전을 지정하는 방법을 보여줍니다.
[소스 버전 샘플](sample-source-version.md)
CodeBuild 빌드 프로젝트에서 소스의 특정 버전을 사용하는 방법을 보여 줍니다.
[CodeBuild용 타사 소스 리포지토리 샘플](sample-third-party-source.md)
CodeBuild를 사용하여 웹후크를 통해 BitBucket, GitHub Enterprise Server 및 GitHub pull 요청을 생성하는 방법을 보여줍니다.
[의미 체계 버전 관리를 사용하여 빌드 시 아티팩트 이름 설정](sample-buildspec-artifact-naming.md)
빌드 시 의미 체계 버전 관리를 사용해 아티팩트 이름을 생성하는 방법을 보여 줍니다.
# CodeBuild에 대한 교차 서비스 샘플
이러한 교차 서비스 샘플을 사용하여 AWS CodeBuild다음을 실험할 수 있습니다.
[Amazon ECR 샘플](sample-ecr.md)
Amazon ECR 리포지토리의 도커 이미지를 사용하여 Apache Maven을 사용하여 단일 JAR 파일을 생성합니다. 샘플 지침은 Docker 이미지를 생성하여 Amazon ECR에 푸시하고, Go 프로젝트를 생성하고, 프로젝트를 빌드하고, 프로젝트를 실행하고, CodeBuild가 Amazon ECR에 연결할 수 있는 권한을 설정하는 방법을 보여줍니다.
[Amazon EFS 샘플](sample-efs.md)
CodeBuild 프로젝트가 Amazon EFS 파일 시스템에 마운트 및 빌드하도록 buildspec 파일을 구성하는 방법을 보여 줍니다. 샘플 지침은 Amazon VPC를 생성하고, Amazon VPC에서 파일 시스템을 생성하고, Amazon VPC를 사용하는 프로젝트를 생성 및 빌드한 다음 생성된 프로젝트 파일 및 변수를 검토하는 방법을 보여줍니다.
[AWS CodePipeline 샘플](sample-codepipeline.md)
를 AWS CodePipeline 사용하여 배치 빌드와 여러 입력 소스 및 여러 출력 아티팩트가 포함된 빌드를 생성하는 방법을 보여줍니다. 이 섹션에는 별도의 아티팩트와 결합된 아티팩트를 사용하여 배치 빌드를 생성하는 파이프라인 구조를 보여주는 예제 JSON 파일이 포함되어 있습니다. 여러 입력 소스와 여러 출력 아티팩트가 있는 파이프라인 구조를 보여주는 추가 JSON 샘플이 제공됩니다.
[AWS Config 샘플](how-to-integrate-config.md)
설정 방법을 보여줍니다 AWS Config. 추적되는 CodeBuild 리소스를 나열하고 CodeBuild 프로젝트를 조회하는 방법을 설명합니다 AWS Config. 샘플 지침은와 통합하기 위한 사전 조건 AWS Config, 설정 단계 AWS Config, CodeBuild 프로젝트 및 데이터를 조회하는 단계를 보여줍니다 AWS Config.
[빌드 알림 샘플](sample-build-notifications.md)
Apache Maven을 사용하여 단일 JAR 파일을 생성합니다. Amazon SNS 주제 구독자에게 빌드 알림을 보냅니다. 샘플 지침은 CodeBuild가 Amazon SNS 및 CloudWatch와 통신할 수 있도록 권한을 설정하는 방법, Amazon SNS에서 CodeBuild 주제를 생성하고 식별하는 방법, 주제에 대한 수신자를 구독하는 방법, CloudWatch에서 규칙을 설정하는 방법을 보여줍니다.
# CodeBuild용 Amazon ECR 샘플
이 샘플에서는 Amazon Elastic Container Registry(Amazon ECR) 이미지 리포지토리에 있는 도커 이미지를 사용하여 샘플 Go 프로젝트를 빌드합니다.
**중요**
이 샘플을 실행하면 AWS 계정에 요금이 부과될 수 있습니다. 여기에는 Amazon S3, , AWS KMS CloudWatch Logs AWS CodeBuild 및 Amazon ECR과 관련된 AWS 리소스 및 작업에 대한 및 요금이 포함됩니다. 자세한 내용은 [CodeBuild 요금](https://aws.amazon.com/codebuild/pricing), [Amazon S3 요금](https://aws.amazon.com/s3/pricing), [AWS Key Management Service 요금](https://aws.amazon.com/kms/pricing), [Amazon CloudWatch 요금](https://aws.amazon.com/cloudwatch/pricing), [Amazon Elastic Container Registry 요금](https://aws.amazon.com/ecr/pricing)을 참조하세요.
**Topics**
+ [Amazon ECR 샘플 실행](#sample-ecr-running)
## Amazon ECR 샘플 실행
다음 지침에 따라 CodeBuild용 Amazon ECR 샘플을 실행합니다.
**이 샘플을 실행하려면**
1. Docker 이미지를 생성하고 Amazon ECR의 이미지 리포지토리에 푸시하려면, ['Amazon ECR에 Docker 이미지 게시' 샘플](sample-docker.md)의 ['Amazon ECR에 Docker 이미지 게시' 샘플 실행](sample-docker.md#sample-docker-running) 섹션에 있는 단계를 수행하세요.
1. Go 프로젝트 만들기:
1. 이 주제의 [Go 프로젝트 구조](#ecr-sample-go-project-file-structure) 및 [Go 프로젝트 파일](#sample-ecr-go-project-files) 섹션에 설명된 대로 파일을 생성한 다음 S3 입력 버킷 또는 AWS CodeCommit, GitHub 또는 Bitbucket 리포지토리에 업로드합니다.
**중요**
`(root directory name)`은 업로드하지 말고, `(root directory name)` 안에 있는 파일만 업로드하십시오.
S3 입력 버킷을 사용하고 있는 경우, 파일을 포함하는 ZIP 파일을 생성한 다음, 이를 입력 버킷에 업로드하십시오. `(root directory name)`을 ZIP 파일에 추가하지 말고, `(root directory name)` 안에 있는 파일만 추가하십시오.
1. 빌드 프로젝트를 생성하고, 빌드를 실행하고, 관련 빌드 정보를 확인합니다.
AWS CLI 를 사용하여 빌드 프로젝트를 생성하는 경우 `create-project` 명령에 대한 JSON 형식의 입력이 이와 비슷할 수 있습니다. (자리 표시자는 사용자의 값으로 바꾸십시오.)
```
{
"name": "sample-go-project",
"source": {
"type": "S3",
"location": "codebuild-region-ID-account-ID-input-bucket/GoSample.zip"
},
"artifacts": {
"type": "S3",
"location": "codebuild-region-ID-account-ID-output-bucket",
"packaging": "ZIP",
"name": "GoOutputArtifact.zip"
},
"environment": {
"type": "LINUX_CONTAINER",
"image": "aws/codebuild/standard:5.0",
"computeType": "BUILD_GENERAL1_SMALL"
},
"serviceRole": "arn:aws:iam::account-ID:role/role-name",
"encryptionKey": "arn:aws:kms:region-ID:account-ID:key/key-ID"
}
```
1. 빌드 출력 아티팩트를 가져오려면 S3 출력 버킷을 엽니다.
1. `GoOutputArtifact.zip` 파일을 로컬 컴퓨터나 인스턴스에 다운로드한 다음 파일의 내용을 추출합니다. 추출한 내용에서 `hello` 파일을 가져옵니다.
1. 다음 중 하나가 true인 경우가 도커 이미지를 빌드 환경으로 가져올 AWS CodeBuild 수 있도록 Amazon ECR의 이미지 리포지토리에 권한을 추가해야 합니다.
+ 프로젝트에서는 CodeBuild 보안 인증을 사용하여 Amazon ECR 이미지를 끌어옵니다. 이는 `ProjectEnvironment`의 `imagePullCredentialsType` 속성에 `CODEBUILD` 값으로 표시됩니다.
+ 프로젝트에서는 교차 계정 Amazon ECR 이미지를 사용합니다. 이 경우에는 프로젝트에서 서비스 역할을 사용하여 Amazon ECR 이미지를 끌어와야 합니다. 이 동작을 활성화하려면 `ProjectEnvironment`의 `imagePullCredentialsType` 속성을 `SERVICE_ROLE`로 설정합니다.
1. Amazon ECR 콘솔([https://console.aws.amazon.com/ecr/](https://console.aws.amazon.com/ecr/))을 엽니다.
1. 리포지토리 이름 목록에서 생성했거나 선택한 리포지토리의 이름을 선택합니다.
1. 탐색 창에서 **권한**을 선택하고, **편집**을 선택한 다음 **설명문 추가**를 선택합니다.
1. **Statement name(설명문 이름)**에 식별자(예: **CodeBuildAccess**)를 입력합니다.
1. **효과**에 대해 **허용**이 선택된 채로 둡니다. 이는 다른 AWS 계정으로의 액세스를 허용하겠다는 의미입니다.
1. **보안 주체**에 대해 다음 중 하나를 실시합니다.
+ 프로젝트에서 CodeBuild 보안 인증을 사용하여 Amazon ECR 이미지를 끌어오는 경우 **서비스 보안 주체**에 **codebuild.amazonaws.com**을 입력합니다.
+ 프로젝트에서 교차 계정 Amazon ECR 이미지를 사용할 경우에는 **AWS 계정 ID**에 액세스 권한을 부여할 AWS 계정의 ID를 입력합니다.
1. **All IAM entities(모든 IAM 엔터티)** 목록을 건너뜁니다.
1. **작업**은 가져오기 전용 작업인 **ecr:GetDownloadUrlForLayer**, **ecr:BatchGetImage** 및 **ecr:BatchCheckLayerAvailability**를 선택합니다.
1. **조건**에 다음을 추가합니다.
```
{
"StringEquals":{
"aws:SourceAccount":"",
"aws:SourceArn":"arn:aws:codebuild:::project/"
}
}
```
1. **저장**을 선택합니다.
이 정책이 **Permissions(권한)**에 표시됩니다. 보안 주체는 이 절차의 3단계에서 **보안 주체**에 입력한 내용입니다.
+ 프로젝트에서 CodeBuild 보안 인증을 사용하여 Amazon ECR 이미지를 끌어오는 경우 **서비스 보안 주체** 아래에 `"codebuild.amazonaws.com"`이 나타납니다.
+ 프로젝트에서 교차 계정 Amazon ECR 이미지를 사용하는 경우 액세스 권한을 부여하려는 AWS 계정의 ID가 **AWS 계정 IDs** 아래에 나타납니다.
다음 샘플 정책은 CodeBuild 보안 인증과 교차 계정 Amazon ECR 이미지를 모두 사용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CodeBuildAccessPrincipal",
"Effect": "Allow",
"Action": [
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"ecr:BatchCheckLayerAvailability"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:SourceArn": "arn:aws:codebuild:us-east-1:111122223333:project/MyProject",
"aws:SourceAccount": "111122223333"
}
}
},
{
"Sid": "CodeBuildAccessCrossAccount",
"Effect": "Allow",
"Action": [
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"ecr:BatchCheckLayerAvailability"
],
"Resource": "*"
}
]
}
```
------
+ 프로젝트에서 CodeBuild 보안 인증을 사용하고 CodeBuild 프로젝트에서 Amazon ECR 리포지토리에 대한 퍼블릭 액세스 권한을 갖도록 하려면 `Condition` 키를 생략하고 다음 샘플 정책을 추가할 수 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CodeBuildAccessPrincipal",
"Effect": "Allow",
"Resource": [
"arn:aws:codecommit:us-east-2:111122223333:MySharedDemoRepo"
],
"Action": [
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"ecr:BatchCheckLayerAvailability"
]
},
{
"Sid": "CodeBuildAccessCrossAccount",
"Effect": "Allow",
"Resource": [
"arn:aws:codecommit:us-east-2:111122223333:MySharedDemoRepo"
],
"Action": [
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"ecr:BatchCheckLayerAvailability"
]
}
]
}
```
------
1. 빌드 프로젝트를 생성하고, 빌드를 실행하고, 빌드 정보를 확인합니다.
AWS CLI 를 사용하여 빌드 프로젝트를 생성하는 경우 `create-project` 명령에 대한 JSON 형식의 입력이 이와 비슷할 수 있습니다. (자리 표시자는 사용자의 값으로 바꾸십시오.)
```
{
"name": "amazon-ecr-sample-project",
"source": {
"type": "S3",
"location": "codebuild-region-ID-account-ID-input-bucket/GoSample.zip"
},
"artifacts": {
"type": "S3",
"location": "codebuild-region-ID-account-ID-output-bucket",
"packaging": "ZIP",
"name": "GoOutputArtifact.zip"
},
"environment": {
"type": "LINUX_CONTAINER",
"image": "account-ID.dkr.ecr.region-ID.amazonaws.com/your-Amazon-ECR-repo-name:tag",
"computeType": "BUILD_GENERAL1_SMALL"
},
"serviceRole": "arn:aws:iam::account-ID:role/role-name",
"encryptionKey": "arn:aws:kms:region-ID:account-ID:key/key-ID"
}
```
1. 빌드 출력 아티팩트를 가져오려면 S3 출력 버킷을 엽니다.
1. `GoOutputArtifact.zip` 파일을 로컬 컴퓨터나 인스턴스에 다운로드한 다음 `GoOutputArtifact.zip` 파일의 내용을 추출합니다. 추출한 내용에서 `hello` 파일을 가져옵니다.
### Go 프로젝트 구조
이 샘플에서는 다음 디렉터리 구조를 가정합니다.
```
(root directory name)
├── buildspec.yml
└── hello.go
```
### Go 프로젝트 파일
이 샘플은 다음 파일을 사용합니다.
`buildspec.yml`(`(root directory name)`에 있음)
```
version: 0.2
phases:
install:
runtime-versions:
golang: 1.13
build:
commands:
- echo Build started on `date`
- echo Compiling the Go code
- go build hello.go
post_build:
commands:
- echo Build completed on `date`
artifacts:
files:
- hello
```
`hello.go`(`(root directory name)`에 있음)
```
package main
import "fmt"
func main() {
fmt.Println("hello world")
fmt.Println("1+1 =", 1+1)
fmt.Println("7.0/3.0 =", 7.0/3.0)
fmt.Println(true && false)
fmt.Println(true || false)
fmt.Println(!true)
}
```
# 용 Amazon Elastic File System 샘플 AWS CodeBuild
Amazon EC2 인스턴스에 대한 확장 가능한 공유 파일 서비스인 Amazon Elastic File System에서 AWS CodeBuild 빌드를 생성할 수 있습니다. Amazon EC2 Amazon EFS를 통한 스토리지 용량은 탄력적이므로 파일이 추가 및 제거될 때 확장되거나 축소됩니다. 또한 파일 시스템을 만들고 구성할 수 있는 간편한 웹 서비스 인터페이스를 제공합니다. 이 서비스는 모든 파일 스토리지 인프라를 관리하므로, 파일 시스템 구성을 배포하거나 패치를 적용하거나 유지 보수하는 데 신경을 쓸 필요가 없습니다. 자세한 내용은 Amazon Elastic File System 사용 설명서에서 [Amazon Elastic File System이란?](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html)을 참조하세요.**
이 예제는 Amazon EFS 파일 시스템에 Java 애플리케이션을 마운트 및 빌드하도록 CodeBuild 프로젝트를 구성하는 방법을 보여 줍니다. 시작하기 전에 S3 입력 버킷 또는 AWS CodeCommit GitHub, GitHub Enterprise Server 또는 Bitbucket 리포지토리에 업로드되는 Java 애플리케이션을 빌드할 준비가 되어 있어야 합니다.
파일 시스템에 전송되는 데이터는 암호화됩니다. 다른 이미지를 사용하여 전송 중인 데이터를 암호화하려면 [전송 중 데이터 암호화](https://docs.aws.amazon.com/efs/latest/ug/encryption-in-transit.html)를 참조하십시오.
**Topics**
+ [Amazon Elastic File System과 AWS CodeBuild 함께 사용](#sample-efs-high-level-steps)
+ [Amazon EFS 통합 문제 해결](sample-efs-troubleshooting.md)
## Amazon Elastic File System과 AWS CodeBuild 함께 사용
이 샘플에서는 Amazon EFS를와 함께 사용하는 데 필요한 4가지 상위 수준 단계를 다룹니다 AWS CodeBuild. 스크립트는 다음과 같습니다.
1. AWS 계정에서 Virtual Private Cloud(VPC)를 생성합니다.
1. 이 VPC를 사용하는 파일 시스템을 생성합니다.
1. VPC를 사용하는 CodeBuild 프로젝트를 생성하고 빌드합니다. CodeBuild 프로젝트는 다음을 사용하여 파일 시스템을 식별합니다.
+ 고유한 파일 시스템 식별자. 식별자는 빌드 프로젝트에서 파일 시스템을 지정할 때 선택합니다.
+ 파일 시스템 ID. Amazon EFS 콘솔에서 파일 시스템을 볼 때 ID가 표시됩니다.
+ 탑재 지점. 파일 시스템을 탑재하는 Docker 컨테이너에 있는 디렉터리입니다.
+ 탑재 옵션. 여기에는 파일 시스템을 탑재하는 방법에 대한 세부 정보가 포함됩니다.
1. 빌드 프로젝트를 검토하여 올바른 프로젝트 파일과 변수가 생성되었는지 확인합니다.
**참고**
Amazon EFS에서 생성한 파일 시스템은 Linux 플랫폼에서만 지원됩니다.
**Topics**
+ [1단계:를 사용하여 VPC 생성 CloudFormation](#sample-efs-create-vpc)
+ [2단계: VPC에서 Amazon Elastic File System 파일 시스템 생성](#sample-efs-create-efs)
+ [3단계: Amazon EFS에서 사용할 CodeBuild 프로젝트 생성](#sample-efs-create-acb)
+ [4단계: 빌드 프로젝트 검토](#sample-efs-summary)
### 1단계:를 사용하여 VPC 생성 CloudFormation
CloudFormation 템플릿을 사용하여 VPC를 생성합니다.
1. 의 지침에 따라 [CloudFormation VPC 템플릿](cloudformation-vpc-template.md)를 CloudFormation 사용하여 VPC를 생성합니다.
**참고**
이 CloudFormation 템플릿으로 생성된 VPC에는 프라이빗 서브넷 2개와 퍼블릭 서브넷 2개가 있습니다. AWS CodeBuild 을 사용하여 Amazon EFS에서 생성한 파일 시스템을 탑재할 때는 프라이빗 서브넷만 사용해야 합니다. 퍼블릭 서브넷 중 하나를 사용할 경우 빌드가 실패합니다.
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) Amazon VPC 콘솔을 엽니다.
1. 생성한 VPC를 선택합니다 CloudFormation.
1. **설명** 탭에 표시된 VPC의 이름과 ID를 기록해 둡니다. VPC 이름과 ID 모두 이 예제 뒷부분에서 AWS CodeBuild 프로젝트를 만들 때 필요합니다.
### 2단계: VPC에서 Amazon Elastic File System 파일 시스템 생성
이 예제를 위해 앞에서 만든 VPC를 사용하여 간단한 Amazon EFS 파일 시스템을 생성합니다.
1. 에 로그인 AWS Management Console 하고 [ https://console.aws.amazon.com/efs/](https://console.aws.amazon.com/efs/) Amazon EFS 콘솔을 엽니다.
1. **파일 시스템 생성**을 선택합니다.
1. 이 예제 앞부분에서 기록해 둔 VPC 이름을 **VPC**에서 선택합니다.
1. 가용 영역은 선택한 서브넷과 연결된 채로 둡니다.
1. **다음 단계**를 선택합니다.
1. **태그 추가**에서 기본 **이름** 키의 **값**에 Amazon EFS 파일 시스템의 이름을 입력합니다.
1. 기본 성능 및 처리량 모드로 선택한 **Bursting(버스팅)** 및 **범용** 모드를 그대로 두고 **다음 단계**를 선택합니다.
1. **클라이언트 액세스 구성**에서 **다음 단계**를 선택합니다.
1. **파일 시스템 생성**을 선택합니다.
1. (선택 사항) 전송 중 데이터를 암호화하는 정책을 Amazon EFS 파일 시스템에 추가하는 것이 좋습니다. Amazon EFS 콘솔에서 **파일 시스템 정책**을 선택하고 **편집**을 선택한 다음, **모든 클라이언트에 전송 중 암호화 적용**이라는 레이블이 붙은 상자를 선택하고 **저장**을 선택합니다.
### 3단계: Amazon EFS에서 사용할 CodeBuild 프로젝트 생성
이 샘플의 앞부분에서 생성한 VPC를 사용하는 AWS CodeBuild 프로젝트를 생성합니다. 빌드가 실행되면 이전에 생성된 Amazon EFS 파일 시스템을 탑재합니다. 그런 다음 Java 애플리케이션에서 생성된 .jar 파일을 파일 시스템의 탑재 지점 디렉터리에 저장합니다.
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.
1. 탐색 창에서 **빌드 프로젝트**를 선택한 후 **빌드 프로젝트 생성**을 선택합니다.
1. **프로젝트 이름**에 프로젝트의 이름을 입력합니다.
1. **소스 공급자**에서 빌드하려는 Java 애플리케이션을 포함하는 리포지토리를 선택합니다.
1. CodeBuild가 애플리케이션을 찾기 위해 사용하는 리포지토리 URL 등과 같은 정보를 입력합니다. 옵션은 소스 공급자마다 다릅니다. 자세한 내용은 [Choose source provider](create-project.md#create-project-source-provider) 단원을 참조하십시오.
1. **환경 이미지**에서 **관리형 이미지**를 선택합니다.
1. **운영 체제**에서 **Amazon Linux 2**를 선택합니다.
1. **런타임**에서 **표준**을 선택합니다.
1. **이미지**에서 **aws/codebuild/amazonlinux-x86\$164-standard:4.0**을 선택합니다.
1. **환경 유형**에서 **Linux**를 선택합니다.
1. **서비스 역할**에서 **새 서비스 역할**을 선택합니다. **역할 이름**에 CodeBuild가 생성할 역할 이름을 입력합니다.
1. **추가 구성**을 확장합니다.
1. **Docker 이미지를 빌드하거나 빌드에서 승격된 권한을 얻으려는 경우 이 플래그 활성화**를 선택합니다.
**참고**
기본적으로 비 VPC 빌드에는 Docker 데몬이 활성화됩니다. VPC 빌드에 Docker 컨테이너를 사용하려면 Docker Docs 웹 사이트의 [런타임 권한 및 Linux 기능](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)을 참조하고 권한 부여 모드를 활성화합니다. 또한 Windows는 권한 모드를 지원하지 않습니다.
1. **VPC**에서 VPC ID를 선택합니다.
1. **서브넷**에서 VPC에 연결된 프라이빗 서브넷을 한 개 이상 선택합니다. Amazon EFS 파일 시스템을 마운트하는 빌드에 프라이빗 서브넷을 사용해야 합니다. 퍼블릭 서브넷을 사용할 경우 빌드가 실패합니다.
1. **보안 그룹**에서 기본 보안 그룹을 선택합니다.
1. **파일 시스템**에 다음 정보를 입력합니다.
+ **식별자**에 고유한 파일 시스템 식별자를 입력합니다. 길이는 129자 미만이어야 하고 영숫자 문자와 밑줄만 사용할 수 있습니다. CodeBuild는 이 식별자를 사용하여 탄력적 파일 시스템을 식별하는 환경 변수를 생성합니다. 환경 변수 형식은 `CODEBUILD_`(대문자)입니다. 예를 들어 `my_efs`을 입력하면 환경 변수는 `CODEBUILD_MY_EFS`입니다.
+ **ID**에서 파일 시스템 ID를 선택합니다.
+ (선택 사항) 파일 시스템에 디렉터리를 입력합니다. CodeBuild는 이 디렉터리를 탑재합니다. **디렉터리 경로**를 비워 두면 CodeBuild에서 전체 파일 시스템을 탑재합니다. 경로는 파일 시스템의 루트와 관련이 있습니다.
+ **탑재 지점**에 파일 시스템을 탑재하는 빌드 컨테이너의 디렉터리 절대 경로를 입력합니다. 이 디렉터리가 없으면 CodeBuild에서 빌드 중에 생성됩니다.
+ (선택 사항) 탑재 옵션을 입력합니다. **탑재 옵션**을 비워 두면 CodeBuild에서는 기본 탑재 옵션을 사용합니다.
```
nfsvers=4.1
rsize=1048576
wsize=1048576
hard
timeo=600
retrans=2
```
자세한 내용은 Amazon Elastic File System 사용 설명서의 [권장되는 NFS 탑재 옵션](https://docs.aws.amazon.com/efs/latest/ug/mounting-fs-nfs-mount-settings.html)을 참조하세요.**
1. **빌드 사양**에서 **빌드 명령 삽입**을 선택한 후 **편집기로 전환**을 선택합니다.
1. 편집기에 다음 buildspec 명령을 입력합니다. 17단계에서 입력한 식별자로 ``를 바꿉니다. 대문자(예: `CODEBUILD_MY_EFS`)를 사용합니다.
```
version: 0.2
phases:
install:
runtime-versions:
java: corretto11
build:
commands:
- mvn compile -Dgpg.skip=true -Dmaven.repo.local=$CODEBUILD_
```
1. 기타 모든 설정에 대해 기본값을 사용하고 **빌드 프로젝트 생성**을 선택합니다. 빌드가 완료되면 프로젝트의 콘솔 페이지가 표시됩니다.
1. **빌드 시작**를 선택합니다.
### 4단계: 빌드 프로젝트 검토
AWS CodeBuild 프로젝트를 빌드한 후:
+ Amazon EFS 파일 시스템에 빌드된 Java 애플리케이션에서 생성된 .jar 파일을 탑재 지점 디렉터리에 저장합니다.
+ 파일 시스템을 식별하는 환경 변수는 프로젝트를 만들 때 입력한 파일 시스템 식별자를 사용하여 생성됩니다.
자세한 내용은 Amazon Elastic File System 사용 설명서에서 [파일 시스템 탑재](https://docs.aws.amazon.com/efs/latest/ug/mounting-fs.html)를 참조하세요.**
# Amazon EFS 통합 문제 해결
CodeBuild로 Amazon EFS를 설정할 때 발생할 수 있는 오류는 다음과 같습니다.
**Topics**
+ [CLIENT\$1ERROR: '127.0.0.1:/' 탑재에 실패했습니다. 권한이 거부되었습니다.](#sample-efs-troubleshooting.permission-denied)
+ [CLIENT\$1ERROR: '127.0.0.1:/' 탑재에 실패했습니다. 피어에서 연결을 재설정했습니다.](#sample-efs-troubleshooting.connection-reset)
+ [VPC\$1CLIENT\$1ERROR: 예상치 못한 EC2 오류: UnauthorizedOperation](#sample-efs-troubleshooting.unauthorized-operation)
## CLIENT\$1ERROR: '127.0.0.1:/' 탑재에 실패했습니다. 권한이 거부되었습니다.
CodeBuild로 Amazon EFS를 탑재하는 데는 IAM 인증이 지원되지 않습니다. 사용자 지정 Amazon EFS 파일 시스템 정책을 사용하는 경우 모든 IAM 보안 주체에 읽기 및 쓰기 액세스 권한을 부여해야 합니다. 예제:
```
"Principal": {
"AWS": "*"
}
```
## CLIENT\$1ERROR: '127.0.0.1:/' 탑재에 실패했습니다. 피어에서 연결을 재설정했습니다.
이 오류의 가능한 두 가지 원인은 다음과 같습니다.
+ CodeBuild VPC 서브넷은 Amazon EFS 탑재 대상과 다른 가용 영역에 있습니다. Amazon EFS 탑재 대상과 동일한 가용 영역에 VPC 서브넷을 추가하여 이 문제를 해결할 수 있습니다.
+ 보안 그룹에는 Amazon EFS와 통신할 권한이 없습니다. VPC(VPC의 기본 CIDR 블록 추가) 또는 보안 그룹 자체에서 들어오는 모든 트래픽을 허용하는 인바운드 규칙을 추가하여 이 문제를 해결할 수 있습니다.
## VPC\$1CLIENT\$1ERROR: 예상치 못한 EC2 오류: UnauthorizedOperation
이 오류는 CodeBuild 프로젝트의 VPC 구성에 있는 모든 서브넷이 퍼블릭 서브넷일 때 발생합니다. 네트워크 연결을 보장하려면 VPC에 프라이빗 서브넷이 하나 이상 있어야 합니다.
# AWS CodePipeline CodeBuild용 샘플
이 섹션에서는 CodePipeline과 CodeBuild 간의 샘플 통합에 대해 설명합니다.
| 샘플 | 설명 |
| --- | --- |
| [CodePipeline/CodeBuild 통합 및 배치 빌드 샘플](#sample-pipeline-batch) | 이 샘플은를 AWS CodePipeline 사용하여 배치 빌드를 사용하는 빌드 프로젝트를 생성하는 방법을 보여줍니다. |
| [CodePipeline/CodeBuild와 다중 입력 소스 및 출력 아티팩트 통합 샘플](#sample-pipeline-multi-input-output) | 이 샘플은를 AWS CodePipeline 사용하여 여러 입력 소스를 사용하여 여러 출력 아티팩트를 생성하는 빌드 프로젝트를 생성하는 방법을 보여줍니다. |
## CodePipeline/CodeBuild 통합 및 배치 빌드 샘플
AWS CodeBuild 는 배치 빌드를 지원합니다. 다음 샘플은를 AWS CodePipeline 사용하여 배치 빌드를 사용하는 빌드 프로젝트를 생성하는 방법을 보여줍니다.
파이프라인의 구조를 정의하는 JSON 형식 파일을 사용한 다음와 함께 사용하여 파이프라인 AWS CLI 을 생성할 수 있습니다. 자세한 내용은AWS CodePipeline 사용 설명서의 [AWS CodePipeline 파이프라인 구조 참조](https://docs.aws.amazon.com/codepipeline/latest/userguide/reference-pipeline-structure.html)를 참조하세요.**
### 개별 아티팩트를 사용한 배치 빌드
다음 JSON 파일을 별도의 아티팩트가 있는 배치 빌드를 생성하는 파이프라인 구조의 예로 사용하세요. CodePipeline에서 배치 빌드를 활성화하려면 `configuration` 객체의 `BatchEnabled` 파라미터를 `true`로 설정합니다.
```
{
"pipeline": {
"roleArn": "arn:aws:iam::account-id:role/my-AWS-CodePipeline-service-role-name",
"stages": [
{
"name": "Source",
"actions": [
{
"inputArtifacts": [],
"name": "Source1",
"actionTypeId": {
"category": "Source",
"owner": "AWS",
"version": "1",
"provider": "S3"
},
"outputArtifacts": [
{
"name": "source1"
}
],
"configuration": {
"S3Bucket": "",
"S3ObjectKey": "my-source-code-file-name.zip"
},
"runOrder": 1
},
{
"inputArtifacts": [],
"name": "Source2",
"actionTypeId": {
"category": "Source",
"owner": "AWS",
"version": "1",
"provider": "S3"
},
"outputArtifacts": [
{
"name": "source2"
}
],
"configuration": {
"S3Bucket": "",
"S3ObjectKey": "my-other-source-code-file-name.zip"
},
"runOrder": 1
}
]
},
{
"name": "Build",
"actions": [
{
"inputArtifacts": [
{
"name": "source1"
},
{
"name": "source2"
}
],
"name": "Build",
"actionTypeId": {
"category": "Build",
"owner": "AWS",
"version": "1",
"provider": "CodeBuild"
},
"outputArtifacts": [
{
"name": "build1"
},
{
"name": "build1_artifact1"
},
{
"name": "build1_artifact2"
},
{
"name": "build2_artifact1"
},
{
"name": "build2_artifact2"
}
],
"configuration": {
"ProjectName": "my-build-project-name",
"PrimarySource": "source1",
"BatchEnabled": "true"
},
"runOrder": 1
}
]
}
],
"artifactStore": {
"type": "S3",
"location": ""
},
"name": "my-pipeline-name",
"version": 1
}
}
```
다음은 이 파이프라인 구성과 함께 작동하는 CodeBuild buildspec 파일의 예입니다.
```
version: 0.2
batch:
build-list:
- identifier: build1
env:
compute-type: BUILD_GENERAL1_SMALL
- identifier: build2
env:
compute-type: BUILD_GENERAL1_MEDIUM
phases:
build:
commands:
- echo 'file' > output_file
artifacts:
files:
- output_file
secondary-artifacts:
artifact1:
files:
- output_file
artifact2:
files:
- output_file
```
파이프라인의 JSON 파일에서 지정하는 출력 아티팩트의 이름은 buildspec 파일에서 정의하는 빌드 및 아티팩트의 식별자와 일치해야 합니다. 구문은 기본 아티팩트의 경우 *buildIdentifier*이고 보조 아티팩트의 경우 *buildIdentifier*\$1*artifactIdentifier*입니다.
예를 들어 출력 아티팩트 이름 `build1`의 경우 CodeBuild는 `build1`의 기본 아티팩트를 `build1`의 위치에 업로드합니다. 출력 이름 `build1_artifact1`의 경우 CodeBuild는 `build1`의 보조 아티팩트 `artifact1`을 `build1_artifact1` 위치에 업로드하는 방식으로 진행됩니다. 출력 위치를 하나만 지정하는 경우 이름은 *buildIdentifier*입니다.
JSON 파일을 생성하였으면 이제 파이프라인을 만들 수 있습니다. AWS CLI 를 사용하여 **create-pipeline** 명령을 실행하고 파일을 `--cli-input-json` 파라미터에 전달합니다. 자세한 내용은AWS CodePipeline 사용 설명서의 [파이프라인 생성(CLI)](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-create.html#pipelines-create-cli)을 참조하세요.**
### 결합된 아티팩트를 사용한 배치 빌드
다음 JSON 파일을 결합된 아티팩트가 있는 배치 빌드를 생성하는 파이프라인 구조의 예로 사용하세요. CodePipeline에서 배치 빌드를 활성화하려면 `configuration` 객체의 `BatchEnabled` 파라미터를 `true`로 설정합니다. 빌드 아티팩트를 같은 위치에 결합하려면 `configuration` 객체의 `CombineArtifacts` 파라미터를 `true`로 설정합니다.
```
{
"pipeline": {
"roleArn": "arn:aws:iam::account-id:role/my-AWS-CodePipeline-service-role-name",
"stages": [
{
"name": "Source",
"actions": [
{
"inputArtifacts": [],
"name": "Source1",
"actionTypeId": {
"category": "Source",
"owner": "AWS",
"version": "1",
"provider": "S3"
},
"outputArtifacts": [
{
"name": "source1"
}
],
"configuration": {
"S3Bucket": "",
"S3ObjectKey": "my-source-code-file-name.zip"
},
"runOrder": 1
},
{
"inputArtifacts": [],
"name": "Source2",
"actionTypeId": {
"category": "Source",
"owner": "AWS",
"version": "1",
"provider": "S3"
},
"outputArtifacts": [
{
"name": "source2"
}
],
"configuration": {
"S3Bucket": "",
"S3ObjectKey": "my-other-source-code-file-name.zip"
},
"runOrder": 1
}
]
},
{
"name": "Build",
"actions": [
{
"inputArtifacts": [
{
"name": "source1"
},
{
"name": "source2"
}
],
"name": "Build",
"actionTypeId": {
"category": "Build",
"owner": "AWS",
"version": "1",
"provider": "CodeBuild"
},
"outputArtifacts": [
{
"name": "output1 "
}
],
"configuration": {
"ProjectName": "my-build-project-name",
"PrimarySource": "source1",
"BatchEnabled": "true",
"CombineArtifacts": "true"
},
"runOrder": 1
}
]
}
],
"artifactStore": {
"type": "S3",
"location": ""
},
"name": "my-pipeline-name",
"version": 1
}
}
```
다음은 이 파이프라인 구성과 함께 작동하는 CodeBuild buildspec 파일의 예입니다.
```
version: 0.2
batch:
build-list:
- identifier: build1
env:
compute-type: BUILD_GENERAL1_SMALL
- identifier: build2
env:
compute-type: BUILD_GENERAL1_MEDIUM
phases:
build:
commands:
- echo 'file' > output_file
artifacts:
files:
- output_file
```
배치 빌드에 대해 결합된 아티팩트가 활성화된 경우 출력은 하나만 허용됩니다. CodeBuild는 모든 빌드의 기본 아티팩트를 하나의 ZIP 파일로 결합합니다.
JSON 파일을 생성하였으면 이제 파이프라인을 만들 수 있습니다. AWS CLI 를 사용하여 **create-pipeline** 명령을 실행하고 파일을 `--cli-input-json` 파라미터에 전달합니다. 자세한 내용은AWS CodePipeline 사용 설명서의 [파이프라인 생성(CLI)](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-create.html#pipelines-create-cli)을 참조하세요.**
## CodePipeline/CodeBuild와 다중 입력 소스 및 출력 아티팩트 통합 샘플
AWS CodeBuild 프로젝트는 둘 이상의 입력 소스를 사용할 수 있습니다. 이에 따라 출력 아티팩트도 다수를 생성할 수 있습니다. 이 샘플은를 AWS CodePipeline 사용하여 여러 입력 소스를 사용하여 여러 출력 아티팩트를 생성하는 빌드 프로젝트를 생성하는 방법을 보여줍니다. 자세한 내용은 [다중 입력 소스 및 출력 아티팩트 샘플](sample-multi-in-out.md) 단원을 참조하십시오.
파이프라인의 구조를 정의하는 JSON 형식 파일을 사용한 다음와 함께 사용하여 파이프라인 AWS CLI 을 생성할 수 있습니다. 다음 JSON 파일을 입력 소스 1개 이상과 출력 아티팩트 1개 이상을 사용해 빌드를 생성하는 파이프라인 구조의 예로 사용합니다. 이번 샘플 후반에서 이 파일이 다중 입력 및 출력을 어떻게 지정하는지 확인할 수 있습니다. 자세한 내용은AWS CodePipeline 사용 설명서의 [CodePipeline 파이프라인 구조 참조](https://docs.aws.amazon.com/codepipeline/latest/userguide/reference-pipeline-structure.html)를 참조하세요.**
```
{
"pipeline": {
"roleArn": "arn:aws:iam::account-id:role/my-AWS-CodePipeline-service-role-name",
"stages": [
{
"name": "Source",
"actions": [
{
"inputArtifacts": [],
"name": "Source1",
"actionTypeId": {
"category": "Source",
"owner": "AWS",
"version": "1",
"provider": "S3"
},
"outputArtifacts": [
{
"name": "source1"
}
],
"configuration": {
"S3Bucket": "my-input-bucket-name",
"S3ObjectKey": "my-source-code-file-name.zip"
},
"runOrder": 1
},
{
"inputArtifacts": [],
"name": "Source2",
"actionTypeId": {
"category": "Source",
"owner": "AWS",
"version": "1",
"provider": "S3"
},
"outputArtifacts": [
{
"name": "source2"
}
],
"configuration": {
"S3Bucket": "my-other-input-bucket-name",
"S3ObjectKey": "my-other-source-code-file-name.zip"
},
"runOrder": 1
}
]
},
{
"name": "Build",
"actions": [
{
"inputArtifacts": [
{
"name": "source1"
},
{
"name": "source2"
}
],
"name": "Build",
"actionTypeId": {
"category": "Build",
"owner": "AWS",
"version": "1",
"provider": "AWS CodeBuild"
},
"outputArtifacts": [
{
"name": "artifact1"
},
{
"name": "artifact2"
}
],
"configuration": {
"ProjectName": "my-build-project-name",
"PrimarySource": "source1"
},
"runOrder": 1
}
]
}
],
"artifactStore": {
"type": "S3",
"location": "AWS-CodePipeline-internal-bucket-name"
},
"name": "my-pipeline-name",
"version": 1
}
}
```
위 JSON 파일에서,
+ 입력 소스 중 하나는 `PrimarySource`로 지정되어야 합니다. 이 소스는 CodeBuild가 buildspec 파일을 찾아서 실행하는 디렉터리를 말합니다. 키워드 `PrimarySource`는 JSON 파일 CodeBuild 단계의 `configuration` 섹션에서 기본 소스를 지정하는 데 사용됩니다.
+ 각 입력 소스는 자체 디렉터리에 설치됩니다. 이 디렉터리는 기본 소스의 경우 기본 제공 환경 변수 `$CODEBUILD_SRC_DIR`에, 기타 모든 소스의 경우 `$CODEBUILD_SRC_DIR_yourInputArtifactName`에 저장됩니다. 위 샘플의 파이프라인에서는 2개의 입력 소스 디렉터리가 `$CODEBUILD_SRC_DIR`과 `$CODEBUILD_SRC_DIR_source2`입니다. 자세한 내용은 [빌드 환경의 환경 변수](build-env-ref-env-vars.md) 단원을 참조하십시오.
+ 파이프라인의 JSON 파일에서 지정하는 출력 아티팩트의 이름은 buildspec 파일에서 정의하는 보조 아티팩트의 이름과 일치해야 합니다. 이 파이프라인에서 사용하는 buildspec 파일은 다음과 같습니다. 자세한 내용은 [buildspec 구문](build-spec-ref.md#build-spec-ref-syntax) 단원을 참조하십시오.
```
version: 0.2
phases:
build:
commands:
- touch source1_file
- cd $CODEBUILD_SRC_DIR_source2
- touch source2_file
artifacts:
files:
- '**/*'
secondary-artifacts:
artifact1:
base-directory: $CODEBUILD_SRC_DIR
files:
- source1_file
artifact2:
base-directory: $CODEBUILD_SRC_DIR_source2
files:
- source2_file
```
JSON 파일을 생성하였으면 이제 파이프라인을 만들 수 있습니다. AWS CLI 를 사용하여 **create-pipeline** 명령을 실행하고 파일을 `--cli-input-json` 파라미터에 전달합니다. 자세한 내용은AWS CodePipeline 사용 설명서의 [파이프라인 생성(CLI)](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-create.html#pipelines-create-cli)을 참조하세요.**
# AWS Config CodeBuild를 사용한 샘플
AWS Config 는 AWS 리소스 인벤토리와 이러한 리소스에 대한 구성 변경 기록을 제공합니다.는 AWS Config 이제를 AWS 리소스 AWS CodeBuild 로 지원하므로 서비스가 CodeBuild 프로젝트를 추적할 수 있습니다. 에 대한 자세한 내용은 *AWS Config 개발자 안내서*의 [란 무엇입니까 AWS Config?](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)를 AWS Config참조하세요.
AWS Config 콘솔의 리소스 **인벤토리** 페이지에서 CodeBuild 리소스에 대한 다음 정보를 볼 수 있습니다.
+ CodeBuild 구성 변경의 타임라인
+ 각 CodeBuild 프로젝트의 구성 세부 정보
+ 다른 AWS 리소스와의 관계.
+ CodeBuild 프로젝트의 변경 사항 목록
**Topics**
+ [에서 CodeBuild 사용 AWS Config](#how-to-integrate-config-run)
+ [3단계: AWS Config 콘솔에서 AWS CodeBuild 데이터 보기](#viewing-config-details)
## 에서 CodeBuild 사용 AWS Config
이 주제의 절차에서는 CodeBuild 프로젝트를 설정하고 AWS Config 조회하는 방법을 보여줍니다.
**Topics**
+ [사전 조건](#how-to-create-a-build-project)
+ [1단계: 설정 AWS Config](#setup-config)
+ [2단계: AWS CodeBuild 프로젝트 조회](#lookup-projects)
### 사전 조건
AWS CodeBuild 프로젝트를 생성합니다. 지침은 [빌드 프로젝트 생성](create-project.md) 섹션을 참조하세요.
### 1단계: 설정 AWS Config
+ [AWS Config 설정(콘솔)](https://docs.aws.amazon.com/config/latest/developerguide/gs-console.html)
+ [AWS Config 설정(AWS CLI)](https://docs.aws.amazon.com/config/latest/developerguide/gs-cli.html)
**참고**
설정을 완료한 후 AWS Config 콘솔에서 AWS CodeBuild 프로젝트를 보려면 최대 10분이 걸릴 수 있습니다.
### 2단계: AWS CodeBuild 프로젝트 조회
1. AWS Management Console에 로그인하고 [https://console.aws.amazon.com/config](https://console.aws.amazon.com/config) AWS Config 콘솔을 엽니다.
1. **리소스 인벤토리** 페이지의 **리소스 유형**에서 **AWS CodeBuild 프로젝트**를 선택합니다. 아래로 스크롤하여 **CodeBuild 프로젝트** 확인란을 선택합니다.
1. **Look up(조회)**을 선택합니다.
1. CodeBuild 프로젝트 목록을 추가한 후 **Config 타임라인** 열에서 CodeBuild 프로젝트 이름 링크를 선택합니다.
## 3단계: AWS Config 콘솔에서 AWS CodeBuild 데이터 보기
**리소스 인벤토리** 페이지에서 리소스를 조회할 때 AWS Config 타임라인을 선택하여 CodeBuild 프로젝트에 대한 세부 정보를 볼 수 있습니다. 리소스에 대한 세부 정보 페이지에서는 구성, 관계, 리소스 변경 사항 수에 대한 정보를 확인할 수 있습니다.
페이지 상단에 있는 블록을 타임라인이라고 합니다. 타임라인은 기록이 생성된 날짜와 시간을 표시합니다.
자세한 내용은 *AWS Config 개발자 안내서*[의 AWS Config 콘솔에서 구성 세부 정보 보기를](https://docs.aws.amazon.com/config/latest/developerguide/view-manage-resource-console.html) 참조하세요.
# CodeBuild의 빌드 알림 샘플
Amazon CloudWatch Events에는에 대한 지원이 내장되어 있습니다 AWS CodeBuild. CloudWatch Events는 AWS 리소스의 변경 사항을 설명하는 시스템 이벤트 스트림입니다. CloudWatch Events를 사용하여 관심 있는 이벤트를 수행할 자동 작업과 연결하는 선언적 규칙을 작성합니다. 이 샘플은 Amazon CloudWatch Events와 Amazon Simple Notification Service(SNS)를 사용하여 빌드가 성공하거나, 실패하거나, 한 빌드 단계에서 다른 빌드 단계로 진행하거나, 이러한 이벤트가 조합될 때마다 구독자에게 빌드 알림을 보냅니다.
**중요**
이 샘플을 실행하면 AWS 계정에 요금이 부과될 수 있습니다. 여기에는 CodeBuild 및 Amazon CloudWatch 및 Amazon SNS와 관련된 AWS 리소스 및 작업에 대해 발생할 수 있는 요금이 포함됩니다. 자세한 내용은 [CodeBuild 요금](https://aws.amazon.com/codebuild/pricing), [Amazon CloudWatch 요금](https://aws.amazon.com/cloudwatch/pricing) 및 [Amazon SNS 요금](https://aws.amazon.com/sns/pricing)을 참조하세요.
**Topics**
+ [빌드 알림 샘플 실행](#sample-build-notifications-running)
+ [빌드 알림 입력 형식 참조](sample-build-notifications-ref.md)
## 빌드 알림 샘플 실행
다음 절차에 따라 빌드 알림 샘플을 실행합니다.
**이 샘플을 실행하려면**
1. Amazon SNS에서 이 샘플에 사용할 주제를 설정하고 구독한 경우 4단계로 건너뜁니다. 그렇지 않으면 AWS 루트 계정 또는 관리자 사용자 대신 IAM 사용자를 사용하여 Amazon SNS로 작업하는 경우 사용자(또는 사용자가 연결된 IAM 그룹)에 다음 문(*\$1\$1\$1 BEGIN ADDING STATEMENT HERE \$1\$1\$1*과 *\$1\$1\$1 END ADDING STATEMENT HERE \$1\$1\$1* 사이)을 추가합니다. AWS 루트 계정을 사용하는 것은 권장되지 않습니다. 이 명령문을 사용하면 Amazon SNS의 주제로의 알림 전송을 보고, 생성하고, 구독하고, 테스트할 수 있습니다. 간결하게 나타내고 명령문 추가 위치를 알 수 있도록 줄임표(`...`)가 사용되었습니다. 어떤 명령문도 제거하지 않아야 하며, 이러한 줄임표는 기존 정책에 입력하지 않아야 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sns:CreateTopic",
"sns:GetTopicAttributes",
"sns:List*",
"sns:Publish",
"sns:SetTopicAttributes",
"sns:Subscribe"
],
"Resource": "*"
}
]
}
```
------
**참고**
이 정책을 수정하는 IAM 엔터티에는 정책을 수정하는 IAM의 권한이 있어야 합니다.
자세한 내용은 [고객 관리형 정책 편집](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-using.html#edit-managed-policy-console) 또는 IAM 사용 설명서의 [인라인 정책 작업(콘솔)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_inline-using.html#AddingPermissions_Console)에서 “그룹, 사용자 또는 역할에 대한 인라인 정책을 편집 또는 삭제하려면” 섹션을 참조하세요.**
1. Amazon SNS에서 주제를 생성하거나 식별합니다. CloudWatch Events를 AWS CodeBuild 사용하여 Amazon SNS를 통해이 주제에 빌드 알림을 보냅니다.
주제를 생성하려면 다음과 같이 합니다.
1. [https://console.aws.amazon.com/sns](https://console.aws.amazon.com/sns) Amazon SNS 콘솔을 엽니다.
1. **주제 생성**을 선택합니다.
1. **새로운 주제 생성**의 **주제 이름**에 주제 이름(예: **CodeBuildDemoTopic**)을 입력합니다. (다른 이름을 선택하는 경우 이 샘플 전체에서 해당 이름으로 바꿉니다.)
1. **주제 생성**을 선택합니다.
1. **주제 세부 정보: CodeBuildDemoTopic** 페이지에서 **주제 ARN** 값을 복사합니다. 다음 단계에서 이 값을 사용합니다.
![\[주제 ARN 값입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/topic-arn.png)
자세한 내용은 *Amazon SNS 개발자 안내서*의 [주제 생성](https://docs.aws.amazon.com/sns/latest/dg/CreateTopic.html)을 참조하세요.
1. 한 명 이상의 수신자가 주제를 구독하여 이메일 알림을 수신하게 합니다.
수신자가 주제를 구독하게 하려면 다음과 같이 합니다.
1. 이전 단계에서 Amazon SNS 콘솔을 연 상태에서 탐색 창에서 **구독**을 선택한 다음, **구독 생성**을 선택합니다.
1. **구독 생성**의 **주제 ARN**에 이전 단계에서 복사한 주제 ARN을 붙여 넣습니다.
1. **프로토콜**에서 **이메일**을 선택합니다.
1. **엔드포인트**에 수신자의 전체 이메일 주소를 입력합니다.
![\[구독 구성입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/create-subscription.png)
1. **구독 생성**을 선택합니다.
1. Amazon SNS가 수신자에게 구독 확인 이메일을 보냅니다. 수신자는 알림을 수신하려면 구독 확인 이메일에서 **구독 확인**을 선택해야 합니다. 수신자가 링크를 클릭한 후 구독에 성공하면 Amazon SNS가 해당 수신자의 웹 브라우저에 확인 메시지를 표시합니다.
자세한 내용은 *Amazon SNS 개발자 가이드*의 [주제 구독](https://docs.aws.amazon.com/sns/latest/dg/SubscribeTopic.html)을 참조하세요.
1. AWS 루트 계정 또는 관리자 사용자 대신 사용자를 사용하여 CloudWatch Events를 사용하는 경우 사용자(또는 사용자가 연결된 IAM 그룹)에 다음 문(*\$1\$1\$1 BEGIN ADDING STATEMENT HERE \$1\$1\$1*과 *\$1\$1\$1 END ADDING STATEMENT HERE \$1\$1\$1* 사이)을 추가합니다. AWS 루트 계정을 사용하는 것은 권장되지 않습니다. 이 명령문은 사용자가 CloudWatch Events에서 작업할 수 있도록 하는 데 사용됩니다. 간결하게 나타내고 명령문 추가 위치를 알 수 있도록 줄임표(`...`)가 사용되었습니다. 어떤 명령문도 제거하지 않아야 하며, 이러한 줄임표는 기존 정책에 입력하지 않아야 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"events:*",
"iam:PassRole"
],
"Resource": "arn:aws:iam::*:role/Service*"
}
]
}
```
------
**참고**
이 정책을 수정하는 IAM 엔터티에는 정책을 수정하는 IAM의 권한이 있어야 합니다.
자세한 내용은 [고객 관리형 정책 편집](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-using.html#edit-managed-policy-console) 또는 IAM 사용 설명서의 [인라인 정책 작업(콘솔)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_inline-using.html#AddingPermissions_Console)에서 “그룹, 사용자 또는 역할에 대한 인라인 정책을 편집 또는 삭제하려면” 섹션을 참조하세요.**
1. CloudWatch Events에서 규칙을 생성합니다. 이 작업을 수행하려면 [https://console.aws.amazon.com/cloudwatch](https://console.aws.amazon.com/cloudwatch)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창의 **이벤트**에서 **규칙**을 선택한 다음 **규칙 생성**을 선택합니다.
1. **1단계: 규칙 생성 페이지**에서 **이벤트 패턴** 및 **서비스별 이벤트와 일치시킬 이벤트 패턴 빌드**가 선택된 상태여야 합니다.
1. **서비스 이름**에서 **CodeBuild**를 선택합니다. **이벤트 유형**에서 **모든 이벤트**가 이미 선택된 상태여야 합니다.
1. **이벤트 패턴 미리 보기**에 다음 코드가 표시되어야 합니다.
```
{
"source": [
"aws.codebuild"
]
}
```
1. **편집**을 선택하여 **이벤트 패턴 미리 보기**를 다음 두 가지 규칙 패턴 중 하나로 교체합니다.
이 첫 번째 규칙 패턴은 빌드가 시작되거나 완료될 때 AWS CodeBuild에 지정된 빌드 프로젝트에 대해 이벤트를 트리거합니다.
```
{
"source": [
"aws.codebuild"
],
"detail-type": [
"CodeBuild Build State Change"
],
"detail": {
"build-status": [
"IN_PROGRESS",
"SUCCEEDED",
"FAILED",
"STOPPED"
],
"project-name": [
"my-demo-project-1",
"my-demo-project-2"
]
}
}
```
위의 규칙에서 다음과 같이 코드를 변경하세요.
+ 빌드가 시작되거나 완료될 때 이벤트를 트리거하려면 `build-status` 어레이에 표시된 모든 값을 그대로 두거나 `build-status` 어레이를 모두 제거합니다.
+ 빌드가 완료될 때만 이벤트를 트리거하려면 `build-status` 배열에서 `IN_PROGRESS`를 제거합니다.
+ 빌드가 시작될 때만 이벤트를 트리거하려면 `build-status` 배열에서 `IN_PROGRESS`를 제외한 모든 값을 제거합니다.
+ 모든 빌드 프로젝트에 대해 이벤트를 트리거하려면 `project-name` 배열을 모두 제거합니다.
+ 개별 빌드 프로젝트에 대해서만 이벤트를 트리거하려면 `project-name` 배열에 각 빌드 프로젝트의 이름을 지정합니다.
이 두 번째 규칙 패턴은 AWS CodeBuild에 지정된 빌드 프로젝트에 대해 빌드가 한 빌드 단계에서 다른 빌드 단계로 이동할 때마다 이벤트를 트리거합니다.
```
{
"source": [
"aws.codebuild"
],
"detail-type": [
"CodeBuild Build Phase Change"
],
"detail": {
"completed-phase": [
"SUBMITTED",
"PROVISIONING",
"DOWNLOAD_SOURCE",
"INSTALL",
"PRE_BUILD",
"BUILD",
"POST_BUILD",
"UPLOAD_ARTIFACTS",
"FINALIZING"
],
"completed-phase-status": [
"TIMED_OUT",
"STOPPED",
"FAILED",
"SUCCEEDED",
"FAULT",
"CLIENT_ERROR"
],
"project-name": [
"my-demo-project-1",
"my-demo-project-2"
]
}
}
```
위의 규칙에서 다음과 같이 코드를 변경하세요.
+ 모든 빌드 단계 변경(각 빌드에 대해 최대 9개의 알림을 보낼 수 있음)에 대해 이벤트를 트리거하려면 `completed-phase` 어레이에 표시된 모든 값을 그대로 두거나 `completed-phase` 어레이를 모두 제거합니다.
+ 개별 빌드 단계 변경에 대해서만 이벤트를 트리거하려면 이벤트를 트리거하지 않으려는 `completed-phase` 배열의 각 빌드 단계 이름을 제거합니다.
+ 모든 빌드 단계 상태 변경에 대한 이벤트를 트리거하려면 `completed-phase-status` 배열에 표시된 모든 값을 그대로 두거나 `completed-phase-status` 배열을 모두 제거합니다.
+ 개별 빌드 단계 상태 변경에 대해서만 이벤트를 트리거하려면 이벤트를 트리거하지 않으려는 `completed-phase-status` 배열의 각 빌드 단계 이름을 제거합니다.
+ 모든 빌드 프로젝트에 대한 이벤트를 트리거하려면 `project-name` 배열을 제거합니다.
+ 개별 빌드 프로젝트에 대한 이벤트만 트리거하려면 `project-name` 배열에 각 빌드 프로젝트의 이름을 지정합니다.
이벤트 패턴에 대한 자세한 내용은 Amazon EventBridge 사용 설명서에서 [이벤트 패턴](https://docs.aws.amazon.com/eventbridge/latest/userguide/filtering-examples-structure.html)을 참조하세요.
이벤트 패턴을 사용한 필터링에 대한 자세한 내용은 Amazon EventBridge 사용 설명서에서 [이벤트 패턴을 사용한 콘텐츠 기반 필터링](https://docs.aws.amazon.com/eventbridge/latest/userguide/content-filtering-with-event-patterns.html)을 참조하세요.
**참고**
빌드 상태 변경 및 빌드 단계 변경에 대한 이벤트를 트리거하려는 경우, 빌드 상태 변경에 대한 규칙 및 빌드 단계 변경을 위한 규칙이라는 두 가지 별도의 규칙을 생성해야 합니다. 두 가지 규칙을 단일 규칙으로 결합하려고 하면 결합된 해당 규칙으로 인해 예기치 않은 결과가 발생하거나 작업이 모두 중단될 수 있습니다.
코드 교체를 완료하면 **저장**을 선택합니다.
1. **대상(Targets)**에서 **대상 추가(Add target)**를 선택합니다.
1. 대상 목록에서 **SNS 주제**를 선택합니다.
1. **주제**에서 이전에 식별했거나 생성한 주제를 선택합니다.
1. **입력 구성**을 확장한 후 **입력 변환기**를 선택합니다.
1. **입력 경로** 상자에 다음 입력 경로 중 하나를 입력합니다.
`CodeBuild Build State Change`의 `detail-type` 값을 사용하는 규칙에 대해 다음을 입력합니다.
```
{"build-id":"$.detail.build-id","project-name":"$.detail.project-name","build-status":"$.detail.build-status"}
```
`CodeBuild Build Phase Change`의 `detail-type` 값을 사용하는 규칙에 대해 다음을 입력합니다.
```
{"build-id":"$.detail.build-id","project-name":"$.detail.project-name","completed-phase":"$.detail.completed-phase","completed-phase-status":"$.detail.completed-phase-status"}
```
다른 유형의 정보를 보려면 [빌드 알림 입력 형식 참조](sample-build-notifications-ref.md) 섹션을 참조하세요.
1. **입력 템플릿** 상자에 다음 입력 템플릿 중 하나를 입력합니다.
`CodeBuild Build State Change`의 `detail-type` 값을 사용하는 규칙에 대해 다음을 입력합니다.
```
"Build '' for build project '' has reached the build status of ''."
```
`CodeBuild Build Phase Change`의 `detail-type` 값을 사용하는 규칙에 대해 다음을 입력합니다.
```
"Build '' for build project '' has completed the build phase of '' with a status of ''."
```
1. **세부 정보 구성**을 선택합니다.
1. **2단계: 규칙 세부 정보 구성** 페이지에 이름 및 선택적인 설명을 입력합니다. **상태**에 대해 **사용**을 선택한 상태로 둡니다.
1. **규칙 생성**을 선택합니다.
1. 빌드 프로젝트를 생성하고, 빌드를 실행하고, 빌드 정보를 확인합니다.
1. CodeBuild에서 현재 빌드 알림을 성공적으로 보내고 있는지 확인합니다. 예를 들어 빌드 알림 이메일이 현재 받은 편지함에 있는지 확인합니다.
규칙의 동작을 변경하려면 CloudWatch 콘솔에서 변경하려는 규칙을 선택한 후 **작업**, **편집**을 차례로 선택합니다. 규칙을 변경하고 **구성 세부 정보**를 선택한 후 **규칙 업데이트**를 선택합니다.
규칙을 사용하여 빌드 알림을 보내는 것을 중지하려면 CloudWatch 콘솔에서 사용을 중지하려는 규칙을 선택한 후 **작업**, **비활성**을 차례로 선택합니다.
규칙을 모두 삭제하려면 CloudWatch 콘솔에서 삭제하려는 규칙을 선택한 후 **작업**, 삭제를 **차례**로 선택합니다.
# 빌드 알림 입력 형식 참조
CloudWatch는 JSON 형식으로 알림을 제공합니다.
빌드 상태 변경 알림은 다음 형식을 사용합니다.
```
{
"version": "0",
"id": "c030038d-8c4d-6141-9545-00ff7b7153EX",
"detail-type": "CodeBuild Build State Change",
"source": "aws.codebuild",
"account": "123456789012",
"time": "2017-09-01T16:14:28Z",
"region": "us-west-2",
"resources":[
"arn:aws:codebuild:us-west-2:123456789012:build/my-sample-project:8745a7a9-c340-456a-9166-edf953571bEX"
],
"detail":{
"build-status": "SUCCEEDED",
"project-name": "my-sample-project",
"build-id": "arn:aws:codebuild:us-west-2:123456789012:build/my-sample-project:8745a7a9-c340-456a-9166-edf953571bEX",
"additional-information": {
"artifact": {
"md5sum": "da9c44c8a9a3cd4b443126e823168fEX",
"sha256sum": "6ccc2ae1df9d155ba83c597051611c42d60e09c6329dcb14a312cecc0a8e39EX",
"location": "arn:aws:s3:::codebuild-123456789012-output-bucket/my-output-artifact.zip"
},
"environment": {
"image": "aws/codebuild/standard:5.0",
"privileged-mode": false,
"compute-type": "BUILD_GENERAL1_SMALL",
"type": "LINUX_CONTAINER",
"environment-variables": []
},
"timeout-in-minutes": 60,
"build-complete": true,
"initiator": "MyCodeBuildDemoUser",
"build-start-time": "Sep 1, 2017 4:12:29 PM",
"source": {
"location": "codebuild-123456789012-input-bucket/my-input-artifact.zip",
"type": "S3"
},
"logs": {
"group-name": "/aws/codebuild/my-sample-project",
"stream-name": "8745a7a9-c340-456a-9166-edf953571bEX",
"deep-link": "https://console.aws.amazon.com/cloudwatch/home?region=us-west-2#logEvent:group=/aws/codebuild/my-sample-project;stream=8745a7a9-c340-456a-9166-edf953571bEX"
},
"phases": [
{
"phase-context": [],
"start-time": "Sep 1, 2017 4:12:29 PM",
"end-time": "Sep 1, 2017 4:12:29 PM",
"duration-in-seconds": 0,
"phase-type": "SUBMITTED",
"phase-status": "SUCCEEDED"
},
{
"phase-context": [],
"start-time": "Sep 1, 2017 4:12:29 PM",
"end-time": "Sep 1, 2017 4:13:05 PM",
"duration-in-seconds": 36,
"phase-type": "PROVISIONING",
"phase-status": "SUCCEEDED"
},
{
"phase-context": [],
"start-time": "Sep 1, 2017 4:13:05 PM",
"end-time": "Sep 1, 2017 4:13:10 PM",
"duration-in-seconds": 4,
"phase-type": "DOWNLOAD_SOURCE",
"phase-status": "SUCCEEDED"
},
{
"phase-context": [],
"start-time": "Sep 1, 2017 4:13:10 PM",
"end-time": "Sep 1, 2017 4:13:10 PM",
"duration-in-seconds": 0,
"phase-type": "INSTALL",
"phase-status": "SUCCEEDED"
},
{
"phase-context": [],
"start-time": "Sep 1, 2017 4:13:10 PM",
"end-time": "Sep 1, 2017 4:13:10 PM",
"duration-in-seconds": 0,
"phase-type": "PRE_BUILD",
"phase-status": "SUCCEEDED"
},
{
"phase-context": [],
"start-time": "Sep 1, 2017 4:13:10 PM",
"end-time": "Sep 1, 2017 4:14:21 PM",
"duration-in-seconds": 70,
"phase-type": "BUILD",
"phase-status": "SUCCEEDED"
},
{
"phase-context": [],
"start-time": "Sep 1, 2017 4:14:21 PM",
"end-time": "Sep 1, 2017 4:14:21 PM",
"duration-in-seconds": 0,
"phase-type": "POST_BUILD",
"phase-status": "SUCCEEDED"
},
{
"phase-context": [],
"start-time": "Sep 1, 2017 4:14:21 PM",
"end-time": "Sep 1, 2017 4:14:21 PM",
"duration-in-seconds": 0,
"phase-type": "UPLOAD_ARTIFACTS",
"phase-status": "SUCCEEDED"
},
{
"phase-context": [],
"start-time": "Sep 1, 2017 4:14:21 PM",
"end-time": "Sep 1, 2017 4:14:26 PM",
"duration-in-seconds": 4,
"phase-type": "FINALIZING",
"phase-status": "SUCCEEDED"
},
{
"start-time": "Sep 1, 2017 4:14:26 PM",
"phase-type": "COMPLETED"
}
]
},
"current-phase": "COMPLETED",
"current-phase-context": "[]",
"version": "1"
}
}
```
빌드 단계 변경 알림은 다음 형식을 사용합니다.
```
{
"version": "0",
"id": "43ddc2bd-af76-9ca5-2dc7-b695e15adeEX",
"detail-type": "CodeBuild Build Phase Change",
"source": "aws.codebuild",
"account": "123456789012",
"time": "2017-09-01T16:14:21Z",
"region": "us-west-2",
"resources":[
"arn:aws:codebuild:us-west-2:123456789012:build/my-sample-project:8745a7a9-c340-456a-9166-edf953571bEX"
],
"detail":{
"completed-phase": "COMPLETED",
"project-name": "my-sample-project",
"build-id": "arn:aws:codebuild:us-west-2:123456789012:build/my-sample-project:8745a7a9-c340-456a-9166-edf953571bEX",
"completed-phase-context": "[]",
"additional-information": {
"artifact": {
"md5sum": "da9c44c8a9a3cd4b443126e823168fEX",
"sha256sum": "6ccc2ae1df9d155ba83c597051611c42d60e09c6329dcb14a312cecc0a8e39EX",
"location": "arn:aws:s3:::codebuild-123456789012-output-bucket/my-output-artifact.zip"
},
"environment": {
"image": "aws/codebuild/standard:5.0",
"privileged-mode": false,
"compute-type": "BUILD_GENERAL1_SMALL",
"type": "LINUX_CONTAINER",
"environment-variables": []
},
"timeout-in-minutes": 60,
"build-complete": true,
"initiator": "MyCodeBuildDemoUser",
"build-start-time": "Sep 1, 2017 4:12:29 PM",
"source": {
"location": "codebuild-123456789012-input-bucket/my-input-artifact.zip",
"type": "S3"
},
"logs": {
"group-name": "/aws/codebuild/my-sample-project",
"stream-name": "8745a7a9-c340-456a-9166-edf953571bEX",
"deep-link": "https://console.aws.amazon.com/cloudwatch/home?region=us-west-2#logEvent:group=/aws/codebuild/my-sample-project;stream=8745a7a9-c340-456a-9166-edf953571bEX"
},
"phases": [
{
"phase-context": [],
"start-time": "Sep 1, 2017 4:12:29 PM",
"end-time": "Sep 1, 2017 4:12:29 PM",
"duration-in-seconds": 0,
"phase-type": "SUBMITTED",
"phase-status": "SUCCEEDED"
},
{
"phase-context": [],
"start-time": "Sep 1, 2017 4:12:29 PM",
"end-time": "Sep 1, 2017 4:13:05 PM",
"duration-in-seconds": 36,
"phase-type": "PROVISIONING",
"phase-status": "SUCCEEDED"
},
{
"phase-context": [],
"start-time": "Sep 1, 2017 4:13:05 PM",
"end-time": "Sep 1, 2017 4:13:10 PM",
"duration-in-seconds": 4,
"phase-type": "DOWNLOAD_SOURCE",
"phase-status": "SUCCEEDED"
},
{
"phase-context": [],
"start-time": "Sep 1, 2017 4:13:10 PM",
"end-time": "Sep 1, 2017 4:13:10 PM",
"duration-in-seconds": 0,
"phase-type": "INSTALL",
"phase-status": "SUCCEEDED"
},
{
"phase-context": [],
"start-time": "Sep 1, 2017 4:13:10 PM",
"end-time": "Sep 1, 2017 4:13:10 PM",
"duration-in-seconds": 0,
"phase-type": "PRE_BUILD",
"phase-status": "SUCCEEDED"
},
{
"phase-context": [],
"start-time": "Sep 1, 2017 4:13:10 PM",
"end-time": "Sep 1, 2017 4:14:21 PM",
"duration-in-seconds": 70,
"phase-type": "BUILD",
"phase-status": "SUCCEEDED"
},
{
"phase-context": [],
"start-time": "Sep 1, 2017 4:14:21 PM",
"end-time": "Sep 1, 2017 4:14:21 PM",
"duration-in-seconds": 0,
"phase-type": "POST_BUILD",
"phase-status": "SUCCEEDED"
},
{
"phase-context": [],
"start-time": "Sep 1, 2017 4:14:21 PM",
"end-time": "Sep 1, 2017 4:14:21 PM",
"duration-in-seconds": 0,
"phase-type": "UPLOAD_ARTIFACTS",
"phase-status": "SUCCEEDED"
},
{
"phase-context": [],
"start-time": "Sep 1, 2017 4:14:21 PM",
"end-time": "Sep 1, 2017 4:14:26 PM",
"duration-in-seconds": 4,
"phase-type": "FINALIZING",
"phase-status": "SUCCEEDED"
},
{
"start-time": "Sep 1, 2017 4:14:26 PM",
"phase-type": "COMPLETED"
}
]
},
"completed-phase-status": "SUCCEEDED",
"completed-phase-duration-seconds": 4,
"version": "1",
"completed-phase-start": "Sep 1, 2017 4:14:21 PM",
"completed-phase-end": "Sep 1, 2017 4:14:26 PM"
}
}
```
# CodeBuild의 빌드 배지 샘플
AWS CodeBuild 는 이제 프로젝트의 최신 빌드 상태를 표시하는 동적으로 생성된 임베딩 가능한 이미지(*배지*)를 제공하는 빌드 배지 사용을 지원합니다. 이 이미지는 CodeBuild 프로젝트용으로 생성된 URL을 통해 공개적으로 액세스할 수 있습니다. 이를 통해 누구든지 CodeBuild 프로젝트의 상태를 볼 수 있습니다. 빌드 배지에는 보안 정보가 포함되어 있지 않으므로 인증이 필요하지 않습니다.
**Topics**
+ [활성화된 빌드 배지를 사용하여 빌드 프로젝트 생성](#sample-build-badges-request-running)
+ [AWS CodeBuild 빌드 배지 액세스](access-badges.md)
+ [CodeBuild 빌드 배지 게시](publish-badges.md)
+ [CodeBuild 배지 상태](badge-statuses.md)
## 활성화된 빌드 배지를 사용하여 빌드 프로젝트 생성
다음 절차 중 하나를 사용하여 빌드 배지가 활성화된 빌드 프로젝트를 생성합니다. AWS CLI 또는를 사용할 수 있습니다 AWS Management Console.
**활성화된 빌드 배지를 사용하여 빌드 프로젝트를 생성하려면(AWS CLI)**
+ 빌드 프로젝트 생성에 대한 자세한 내용은 [빌드 프로젝트 생성(AWS CLI)](create-project.md#create-project-cli) 섹션을 참조하십시오. AWS CodeBuild 프로젝트에 빌드 배지를 포함하려면 *badgeEnabled* 값을 `true`로 지정해야 합니다.
**활성화된 빌드 배지를 사용하여 빌드 프로젝트를 생성하려면(콘솔)**
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.
1. CodeBuild 정보 페이지가 나타나면 **빌드 프로젝트 생성**을 선택합니다. 그렇지 않을 경우, 탐색 창에서 **빌드**를 확장한 후 **빌드 프로젝트**를 선택하고 **빌드 프로젝트 생성**을 선택합니다.
1. **프로젝트 이름**에 이 빌드 프로젝트의 이름을 입력합니다. 빌드 프로젝트 이름은 각 AWS 계정에서 고유해야 합니다. 또한 선택에 따라 빌드 프로젝트에 대한 설명을 포함하여 다른 사용자가 이 프로젝트의 용도를 이해하도록 도울 수 있습니다.
1. **소스**의 **소스 공급자**에서, 소스 코드 공급자 유형을 선택한 다음, 다음 중 하나를 수행합니다.
**참고**
CodeBuild는 Amazon S3 소스 공급자에게 빌드 배지를 지원하지 않습니다. 는 아티팩트 전송에 Amazon S3를 AWS CodePipeline 사용하기 때문에 CodePipeline에서 생성된 파이프라인의 일부인 빌드 프로젝트에는 빌드 배지가 지원되지 않습니다.
+ **CodeCommit**을 선택한 후 **리포지토리**에서 해당 리포지토리의 이름을 선택합니다. 프로젝트의 빌드 상태를 표시하고 삽입 가능하게 하려면 **Enable build badge(빌드 배치 활성화)**를 선택합니다.
+ [**GitHub**]를 선택했다면, GitHub와 연결(다시 연결)하는 지침을 따르십시오. GitHub **애플리케이션 승인** 페이지의 **조직 액세스**에서 액세스 AWS CodeBuild 하려는 각 리포지토리 옆에 있는 액세스 **요청을** 선택합니다. **Authorize application(애플리케이션 권한 부여)**을 선택한 후 AWS CodeBuild 콘솔로 돌아가서 **리포지토리**에서 소스 코드를 포함하는 리포지토리의 이름을 선택합니다. 프로젝트의 빌드 상태를 표시하고 삽입 가능하게 하려면 **Enable build badge(빌드 배치 활성화)**를 선택합니다.
+ [**Bitbucket**]을 선택했다면, Bitbucket과 연결(다시 연결)하는 지침을 따르십시오. [**Confirm access to your account**] 페이지의 [**Organization access**]에서 [**Grant access**]를 선택합니다. **액세스 권한 부여**를 선택한 후 AWS CodeBuild 콘솔의 **리포지토리**에서 소스 코드가 포함된 리포지토리의 이름을 선택합니다. 프로젝트의 빌드 상태를 표시하고 삽입 가능하게 하려면 **Enable build badge(빌드 배치 활성화)**를 선택합니다.
**중요**
프로젝트 소스를 업데이트하면 프로젝트 빌드 배지의 정확성에 영향을 미칠 수 있습니다.
1. **환경**에서 다음과 같이 합니다.
[**Environment image**]에서 다음 중 하나를 수행합니다.
+ 에서 관리하는 도커 이미지를 사용하려면 **관리형 이미지를** AWS CodeBuild선택한 다음 **운영 체제**, **런타임**, **이미지**(Image) 및 **이미지 버전**에서 선택합니다. 사용 가능한 경우 **환경 유형**에서 항목을 선택합니다.
+ 다른 도커 이미지를 사용하려면 **사용자 지정 이미지**를 선택합니다. **환경 유형**에서 **ARM**, **Linux**, **Linux GPU** 또는 **Windows**를 선택합니다. **Other registry(다른 레지스트리)**를 선택한 경우 **External registry URL(외부 레지스트리 URL)**에 Docker Hub의 도커 이미지 이름 및 태그를 `docker repository/docker image name` 형식으로 입력합니다. **Amazon ECR**을 선택하는 경우 **Amazon ECR 리포지토리**와 **Amazon ECR 이미지를** 사용하여 AWS 계정에서 도커 이미지를 선택합니다.
+ 프라이빗 도커 이미지를 사용하려면 **사용자 지정 이미지**를 선택합니다. **환경 유형**에서 **ARM**, **Linux**, **Linux GPU** 또는 **Windows**를 선택합니다. **Image registry(이미지 레지스트리)**에서 **Other registry(다른 레지스트리)**를 선택한 다음 프라이빗 도커 이미지에 대한 보안 인증 정보의 ARN을 입력합니다. 보안 인증은 Secrets Manager에서 생성됩니다. 자세한 내용은 AWS Secrets Manager사용 설명서의 [AWS Secrets Manager 이란?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/) 섹션을 참조하세요.**
1. **서비스 역할**에서 다음 중 하나를 수행합니다.
+ CodeBuild 서비스 역할이 없는 경우 **새 서비스 역할**을 선택합니다. **역할 이름**에 새 역할의 이름을 입력합니다.
+ CodeBuild 서비스 역할이 있는 경우 **기존 서비스 역할**을 선택합니다. **역할 ARN**에서 서비스 역할을 선택합니다.
**참고**
콘솔을 사용하여 빌드 프로젝트를 생성하거나 업데이트하는 경우, 이와 동시에 CodeBuild 서비스 역할을 만들 수 있습니다. 기본적으로 역할은 해당 빌드 프로젝트에서만 작동합니다. 콘솔을 사용하여 이 서비스 역할을 다른 빌드 프로젝트와 연결하는 경우 다른 빌드 프로젝트에서 작동하도록 역할이 업데이트됩니다. 하나의 서비스 역할은 최대 10개의 빌드 프로젝트에서 작동할 수 있습니다.
1. **Buildspec**에서 다음 중 하나를 수행합니다.
+ **buildspec 파일 사용**을 선택하여 소스 코드 루트 디렉터리에 있는 buildspec.yml 파일을 사용합니다.
+ **빌드 명령 삽입**을 선택하여 콘솔에서 빌드 명령을 삽입합니다.
자세한 내용은 [buildspec 참조](build-spec-ref.md) 단원을 참조하십시오.
1. **결과물**의 **유형**에서 다음 중 하나를 수행합니다.
+ 빌드 출력 아티팩트를 생성하지 않으려면 **No artifacts(아티팩트 없음)**를 선택합니다.
+ S3 버킷에 빌드 출력을 저장하려면 **Amazon S3**를 선택하고 다음 작업을 수행합니다.
+ 빌드 출력 ZIP 파일이나 폴더에 프로젝트 이름을 사용하려는 경우 **이름**을 비워 둡니다. 그렇지 않으면 이름을 입력합니다. 기본적으로 결과물 이름은 프로젝트의 이름입니다. 다른 이름을 사용하려면 결과물 이름 상자에 해당 이름을 입력합니다. ZIP 파일을 출력하려면 zip 확장명을 포함시킵니다.
+ [**Bucket name**]에서 출력 버킷의 이름을 선택합니다.
+ 이 절차의 앞부분에서 **빌드 명령 삽입**을 선택한 경우 **출력 파일**에 빌드 출력 ZIP 파일 또는 폴더에 넣으려는 빌드의 파일 위치를 입력합니다. 위치가 여러 개인 경우 각 위치를 쉼표로 구분합니다(예: `appspec.yml, target/my-app.jar`). 자세한 내용은 [buildspec 구문](build-spec-ref.md#build-spec-ref-syntax)의 `files` 설명을 참조하십시오.
1. **추가 구성**을 확장하고 적절한 옵션을 선택합니다.
1. **빌드 프로젝트 생성**을 선택합니다. **검토** 페이지에서 **빌드 시작**을 선택하여 빌드를 실행합니다.
# AWS CodeBuild 빌드 배지 액세스
AWS CodeBuild 콘솔 또는를 사용하여 빌드 배지 AWS CLI 에 액세스할 수 있습니다.
+ CodeBuild 콘솔에서 빌드 프로젝트 목록에 있는 **이름** 열에서 빌드 프로젝트에 해당하는 링크를 선택합니다. **빌드 프로젝트: *project-name*** 페이지의 **구성**에서 **배지 URL 복사**를 선택합니다. 자세한 내용은 [빌드 프로젝트 세부 정보 보기(콘솔)](view-project-details.md#view-project-details-console) 단원을 참조하십시오.
+ 에서 `batch-get-projects` 명령을 AWS CLI실행합니다. 빌드 배지 URL은 출력의 프로젝트 환경 세부 정보 섹션에 포함됩니다. 자세한 내용은 [빌드 프로젝트 세부 정보 보기(AWS CLI)](view-project-details.md#view-project-details-cli) 단원을 참조하십시오.
빌드 배지 요청 URL은 일반적인 기본 분기로 생성되지만, 빌드를 실행하는 데 사용한 소스 리포지토리의 어떤 분기도 지정할 수 있습니다. 예제:
```
https://codebuild.us-east-1.amazon.com/badges?uuid=...&branch=
```
`branch` 파라미터를 배지 URL의 `tag` 파라미터를 대체하여 소스 리포지토리의 태그를 지정할 수도 있습니다. 예제:
```
https://codebuild.us-east-1.amazon.com/badges?uuid=...&tag=
```
# CodeBuild 빌드 배지 게시
마크다운 이미지의 빌드 배지 URL을 사용하여 마크다운 파일에 최신 빌드의 상태를 표시할 수 있습니다. 이 기능은 소스 리포지토리(예: GitHub 또는 CodeCommit) 의 readme.md 파일에 최신 빌드의 상태를 표시하는 데 유용합니다. 예제:
```
![]()
```
# CodeBuild 배지 상태
CodeBuild 빌드 배지는 다음 상태 중 하나를 가질 수 있습니다.
+ **PASSING** 특정 분기의 최신 빌드가 전달되었습니다.
+ **FAILING** 특정 분기의 최신 빌드가 시간 초과, 실패, 오류 또는 중지되었습니다.
+ **IN\$1PROGRESS** 특정 분기의 최신 빌드가 진행 중입니다.
+ **UNKNOWN** 프로젝트가 아직 특정 분기 또는 전부에 대한 빌드를 실행하지 않았습니다. 또한 배지 빌드 기능이 비활성화되었을 수 있습니다.
# '를 사용한 테스트 보고서 AWS CLI' 샘플
buildspec 파일에 지정한 테스트는 빌드 중에 실행됩니다. 이 샘플은를 사용하여 CodeBuild의 빌드에 테스트를 AWS CLI 통합하는 방법을 보여줍니다. JUnit을 사용하여 단위 테스트를 만들거나, 다른 도구를 사용하여 구성 테스트를 만들 수 있습니다. 그런 다음 테스트 결과를 평가하여 문제를 해결하거나 애플리케이션을 최적화할 수 있습니다.
CodeBuild API 또는 AWS CodeBuild 콘솔을 사용하여 테스트 결과에 액세스할 수 있습니다. 이 샘플에서는 테스트 결과를 S3 버킷으로 내보내도록 보고서를 구성하는 방법을 보여줍니다.
**Topics**
+ [테스트 보고서 샘플 실행](#sample-test-report-cli-run)
## 테스트 보고서 샘플 실행
다음 단계에 따라 테스트 보고서 샘플을 실행합니다.
**Topics**
+ [사전 조건](#sample-test-report-cli-prerequisites)
+ [1단계: 보고서 그룹 생성](#sample-test-report-cli-create-report)
+ [2단계: 보고서 그룹을 사용하여 프로젝트 구성](#sample-test-report-cli-create-project-with-report)
+ [3단계: 보고서 실행 및 결과 보기](#sample-test-report-cli-run-and-view-report-results)
### 사전 조건
+ 테스트 케이스를 만듭니다. 이 샘플은 샘플 테스트 보고서에 포함할 테스트 케이스가 있다는 것을 전제로 작성된 것입니다. buildspec 파일에서 테스트 파일의 위치를 지정합니다.
지원되는 테스트 보고서 파일 형식은 다음과 같습니다.
+ Cucumber JSON(.json)
+ JUnit XML(.xml)
+ NUnit XML(.xml)
+ NUnit3 XML(.xml)
+ TestNG XML(.xml)
+ Visual Studio TRX(.trx)
+ Visual Studio TRX XML(.xml)
이러한 형식 중 하나로 보고서 파일을 만들 수 있는 테스트 프레임워크로 테스트 케이스를 만듭니다(예: Surefire JUnit plugin, TestNG, Cucumber).
+ S3 버킷을 만들고 이름을 기록해 둡니다. 자세한 내용을 알아보려면 Amazon S3 사용 설명서의 [S3 버킷을 생성하는 방법](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-bucket.html)을 참조하세요.**
+ IAM 역할을 생성하고 해당 ARN을 기록해 둡니다. 빌드 프로젝트를 만들 때 ARN이 필요합니다.
+ 역할에 다음 권한이 없는 경우 권한을 추가합니다.
```
{
"Effect": "Allow",
"Resource": [
"*"
],
"Action": [
"codebuild:CreateReportGroup",
"codebuild:CreateReport",
"codebuild:UpdateReport",
"codebuild:BatchPutTestCases"
]
}
```
자세한 내용은 [테스트 보고 작업에 대한 권한](test-permissions.md#test-permissions-related-to-reporting) 단원을 참조하십시오.
### 1단계: 보고서 그룹 생성
1. `CreateReportGroupInput.json`이라는 이름의 파일을 만듭니다.
1. S3 버킷에 테스트 결과를 내보낼 폴더를 만듭니다.
1. 다음을 `CreateReportGroupInput.json`에 복사합니다. ``는 S3 버킷의 이름을 사용합니다. ``은 S3 버킷의 폴더 경로를 입력합니다.
```
{
"name": "",
"type": "TEST",
"exportConfig": {
"exportConfigType": "S3",
"s3Destination": {
"bucket": "",
"path": "",
"packaging": "NONE"
}
}
}
```
1. `CreateReportGroupInput.json`을 포함하는 디렉터리에서 다음 명령을 실행합니다.
```
aws codebuild create-report-group --cli-input-json file://CreateReportGroupInput.json
```
출력은 다음과 같습니다. `reportGroup`의 ARN을 기록해 둡니다. 이 보고서 그룹을 사용하는 프로젝트를 만들 때 사용합니다.
```
{
"reportGroup": {
"arn": "arn:aws:codebuild:us-west-2:123456789012:report-group/",
"name": "",
"type": "TEST",
"exportConfig": {
"exportConfigType": "S3",
"s3Destination": {
"bucket": "",
"path": "",
"packaging": "NONE",
"encryptionKey": "arn:aws:kms:us-west-2:123456789012:alias/aws/s3"
}
},
"created": 1570837165.885,
"lastModified": 1570837165.885
}
}
```
### 2단계: 보고서 그룹을 사용하여 프로젝트 구성
보고서를 실행하려면 먼저 보고서 그룹으로 구성된 CodeBuild 빌드 프로젝트를 만듭니다. 보고서 그룹에 지정된 테스트 케이스는 빌드를 실행할 때 실행됩니다.
1. 이름이 `buildspec.yml`인 buildspec 파일을 만듭니다
1. 다음 YAML을 `buildspec.yml` 파일의 템플릿으로 사용합니다. 테스트를 실행하는 명령이 포함되어야 합니다. `reports` 섹션에서는 테스트 케이스 결과가 포함된 파일을 지정합니다. 이러한 파일에는 CodeBuild로 액세스할 수 있는 테스트 결과가 저장됩니다. 작성되고 30일 후에 만료됩니다. 이러한 파일은 S3 버킷으로 내보내는 원시 테스트 케이스 결과 파일과 다릅니다.
```
version: 0.2
phases:
install:
runtime-versions:
java: openjdk8
build:
commands:
- echo Running tests
-
reports:
: #test file information
files:
- ''
base-directory: ''
discard-paths: false #do not remove file paths from test result files
```
**참고**
기존 보고서 그룹의 ARN 대신, 생성되지 않은 보고서 그룹의 이름을 지정할 수도 있습니다. ARN 대신 이름을 지정하면 CodeBuild에서 빌드를 실행할 때 보고서 그룹을 만듭니다. 이름에는 프로젝트 이름과 buildspec 파일에 지정한 이름이 `project-name-report-group-name` 형식으로 포함되어 있습니다. 자세한 내용은 [테스트 보고서 생성](report-create.md) 및 [보고서 그룹 이름 지정](test-report-group-naming.md) 섹션을 참조하세요.
1. `project.json`이라는 이름의 파일을 만듭니다. 이 파일에는 **create-project** 명령에 대한 입력이 들어 있습니다.
1. 다음 JSON을 `project.json`에 복사합니다. `source`는 소스 파일이 들어있는 저장소의 유형과 위치를 입력합니다. `serviceRole`은 사용 중인 역할의 ARN을 지정합니다.
```
{
"name": "test-report-project",
"description": "sample-test-report-project",
"source": {
"type": "CODECOMMIT|CODEPIPELINE|GITHUB|S3|BITBUCKET|GITHUB_ENTERPRISE|NO_SOURCE",
"location": ""
},
"artifacts": {
"type": "NO_ARTIFACTS"
},
"cache": {
"type": "NO_CACHE"
},
"environment": {
"type": "LINUX_CONTAINER",
"image": "aws/codebuild/standard:5.0",
"computeType": "small"
},
"serviceRole": "arn:aws:iam:::role/service-role/"
}
```
1. `project.json`을 포함하는 디렉터리에서 다음 명령을 실행합니다. 이렇게 하면 이름이 `test-project`인 프로젝트가 생성됩니다.
```
aws codebuild create-project --cli-input-json file://project.json
```
### 3단계: 보고서 실행 및 결과 보기
이 섹션에서는 이전에 만든 프로젝트의 빌드를 실행합니다. 빌드 프로세스 중에 CodeBuild에서는 테스트 케이스의 결과가 포함된 보고서를 생성합니다. 보고서는 지정한 보고서 그룹에 포함되어 있습니다.
1. 빌드를 시작하려면 다음 명령을 실행합니다. `test-report-project`는 위에서 만든 빌드 프로젝트의 이름입니다. 출력에 나타나는 빌드 ID를 기록해 둡니다.
```
aws codebuild start-build --project-name test-report-project
```
1. 다음 명령을 실행하여 보고서의 ARN을 포함하여 빌드에 대한 정보를 가져옵니다. ``은 빌드 ID를 지정합니다. 출력의 `reportArns` 속성에 보고서 ARN을 기록해 둡니다.
```
aws codebuild batch-get-builds --ids
```
1. 보고서에 대한 세부 정보를 가져오려면 다음 명령을 실행합니다. ``은 보고서 ARN을 지정합니다.
```
aws codebuild batch-get-reports --report-arns
```
출력은 다음과 같습니다. 이 샘플 출력은 성공했거나, 실패했거나, 건너뛰었거나, 오류가 발생했거나, 알 수 없는 상태를 반환하는 테스트 수를 보여 줍니다.
```
{
"reports": [
{
"status": "FAILED",
"reportGroupArn": "",
"name": "",
"created": 1573324770.154,
"exportConfig": {
"exportConfigType": "S3",
"s3Destination": {
"bucket": "",
"path": "",
"packaging": "NONE",
"encryptionKey": ""
}
},
"expired": 1575916770.0,
"truncated": false,
"executionId": "arn:aws:codebuild:us-west-2:123456789012:build/:2c254862-ddf6-4831-a53f-6839a73829c1",
"type": "TEST",
"arn": "",
"testSummary": {
"durationInNanoSeconds": 6657770,
"total": 11,
"statusCounts": {
"FAILED": 3,
"SKIPPED": 7,
"ERROR": 0,
"SUCCEEDED": 1,
"UNKNOWN": 0
}
}
}
],
"reportsNotFound": []
}
```
1. 보고서의 테스트 케이스에 대한 정보를 나열하려면 다음 명령을 실행합니다. ``은 보고서의 ARN을 지정합니다. 선택 사항인 `--filter` 매개변수의 경우 하나의 상태 결과(`SUCCEEDED`, `FAILED`, `SKIPPED`, `ERROR` 또는 `UNKNOWN`)를 지정할 수 있습니다.
```
aws codebuild describe-test-cases \
--report-arn \
--filter status=SUCCEEDED|FAILED|SKIPPED|ERROR|UNKNOWN
```
출력은 다음과 같습니다.
```
{
"testCases": [
{
"status": "FAILED",
"name": "Test case 1",
"expired": 1575916770.0,
"reportArn": "",
"prefix": "Cucumber tests for agent",
"message": "A test message",
"durationInNanoSeconds": 1540540,
"testRawDataPath": ""
},
{
"status": "SUCCEEDED",
"name": "Test case 2",
"expired": 1575916770.0,
"reportArn": "",
"prefix": "Cucumber tests for agent",
"message": "A test message",
"durationInNanoSeconds": 1540540,
"testRawDataPath": ""
}
]
}
```
# CodeBuild용 Docker 샘플
이 섹션에서는 Docker와 간의 샘플 통합에 대해 설명합니다 AWS CodeBuild.
| 샘플 | 설명 |
| --- | --- |
| [CodeBuild용 Docker 사용자 지정 이미지 샘플](sample-docker-custom-image.md) | 이 샘플은 CodeBuild 및 사용자 지정 Docker 빌드 이미지(Docker Hub의 `docker:dind`)를 사용하여 Docker 이미지를 빌드하고 실행합니다. |
| [CodeBuild용 Docker 이미지 빌드 서버 샘플](sample-docker-server.md) | 이 샘플은 Docker 빌드를 관리형 이미지 빌드 서버로 오프로드합니다. |
| [CodeBuild용 Windows Docker 빌드 샘플](sample-windows-docker-custom-image.md) | 이 샘플은 CodeBuild를 사용하여 Windows Docker 이미지를 빌드하고 실행합니다. |
| [CodeBuild용 'Amazon ECR 이미지 리포지토리에 Docker 이미지 게시' 샘플](sample-docker.md) | 이 샘플은 빌드 출력으로 도커 이미지를 생산한 다음 도커 이미지를 Amazon Elastic Container Registry(Amazon ECR) 이미지 리포지토리에 푸시합니다. |
| [CodeBuild용 AWS Secrets Manager 샘플이 포함된 프라이빗 레지스트리](sample-private-registry.md) | 이 샘플에서는 CodeBuild 실행 시간 환경으로서 프라이빗 레지스트리에 저장되는 Docker 이미지를 사용하는 방법을 보여줍니다. |
# CodeBuild용 Docker 사용자 지정 이미지 샘플
다음 샘플은 및 사용자 지정 Docker 빌드 이미지(`docker:dind`Docker Hub의 )를 사용하여 Docker 이미지를 빌드 AWS CodeBuild 하고 실행합니다.
대신, Docker 지원을 통해 CodeBuild에서 제공하는 빌드 이미지를 사용하여 도커 이미지를 빌드하는 방법을 알아보려면 ['Amazon ECR에 Docker 이미지 게시' 샘플](sample-docker.md) 섹션을 참조하세요.
**중요**
이 샘플을 실행하면 AWS 계정에 요금이 부과될 수 있습니다. 여기에는 CodeBuild와 Amazon S3 및 CloudWatch Logs와 관련된 AWS 리소스 AWS KMS및 작업에 대해 발생할 수 있는 요금이 포함됩니다. 자세한 내용은 [CodeBuild 요금](https://aws.amazon.com/codebuild/pricing), [Amazon S3 요금](https://aws.amazon.com/s3/pricing), [AWS Key Management Service 요금](https://aws.amazon.com/kms/pricing) 및 [Amazon CloudWatch 요금](https://aws.amazon.com/cloudwatch/pricing)을 참조하세요.
**Topics**
+ [사용자 지정 이미지 샘플의 Docker 실행](#sample-docker-custom-image-running)
## 사용자 지정 이미지 샘플의 Docker 실행
다음 절차에 따라 사용자 지정 이미지 샘플에서 Docker를 실행합니다. 이 샘플에 대한 자세한 내용은 [CodeBuild용 Docker 사용자 지정 이미지 샘플](#sample-docker-custom-image) 섹션을 참조하세요.
**사용자 지정 이미지 샘플에서 Docker를 실행하려면**
1. 이 주제의 [디렉터리 구조](#sample-docker-custom-image-dir) 및 [파일](#sample-docker-custom-image-files) 섹션에 설명된 대로 파일을 생성한 다음 S3 입력 버킷 또는 AWS CodeCommit, GitHub 또는 Bitbucket 리포지토리에 업로드합니다.
**중요**
`(root directory name)`은 업로드하지 말고, `(root directory name)` 안에 있는 파일만 업로드하십시오.
S3 입력 버킷을 사용하고 있는 경우, 파일을 포함하는 ZIP 파일을 생성한 다음, 이를 입력 버킷에 업로드하십시오. `(root directory name)`을 ZIP 파일에 추가하지 말고, `(root directory name)` 안에 있는 파일만 추가하십시오.
1. 빌드 프로젝트를 생성하고, 빌드를 실행하고, 관련 빌드 정보를 확인합니다.
AWS CLI 를 사용하여 빌드 프로젝트를 생성하는 경우 `create-project` 명령에 대한 JSON 형식의 입력이 이와 비슷할 수 있습니다. (자리 표시자는 사용자의 값으로 바꾸십시오.)
```
{
"name": "sample-docker-custom-image-project",
"source": {
"type": "S3",
"location": "codebuild-region-ID-account-ID-input-bucket/DockerCustomImageSample.zip"
},
"artifacts": {
"type": "NO_ARTIFACTS"
},
"environment": {
"type": "LINUX_CONTAINER",
"image": "docker:dind",
"computeType": "BUILD_GENERAL1_SMALL",
"privilegedMode": false
},
"serviceRole": "arn:aws:iam::account-ID:role/role-name",
"encryptionKey": "arn:aws:kms:region-ID:account-ID:key/key-ID"
}
```
**참고**
기본적으로 비 VPC 빌드에는 Docker 데몬이 활성화됩니다. VPC 빌드에 Docker 컨테이너를 사용하려면 Docker Docs 웹 사이트의 [런타임 권한 및 Linux 기능](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)을 참조하고 권한 부여 모드를 활성화합니다. 또한 Windows는 권한 모드를 지원하지 않습니다.
1. 빌드 결과를 확인하려면 빌드 로그에서 `Hello, World!` 문자열에 대해 찾아보십시오. 자세한 내용은 [빌드 세부 정보 보기](view-build-details.md) 단원을 참조하십시오.
### 디렉터리 구조
이 샘플에서는 다음 디렉터리 구조를 가정합니다.
```
(root directory name)
├── buildspec.yml
└── Dockerfile
```
### 파일
이 샘플에 사용되는 운영 체제의 기본 이미지는 Ubuntu입니다. 샘플은 이러한 파일을 사용합니다.
`buildspec.yml`(`(root directory name)`에 있음)
```
version: 0.2
phases:
pre_build:
commands:
- docker build -t helloworld .
build:
commands:
- docker images
- docker run helloworld echo "Hello, World!"
```
`Dockerfile`(`(root directory name)`에 있음)
```
FROM maven:3.3.9-jdk-8
RUN echo "Hello World"
```
# CodeBuild용 Docker 이미지 빌드 서버 샘플
다음 샘플은 Docker 빌드를 관리형 이미지 빌드 서버로 오프로드합니다. 이 샘플을 조정하여 CodeBuild 프로젝트 구성에서 전용 관리형 Docker 이미지 빌드 서버를 프로비저닝할 수 있습니다. 프로젝트에 대해 빌드가 적극적으로 실행되는 동안 프로비저닝된 인스턴스가 활성화되고 빌드가 실행되지 않으면 인스턴스가 중지됩니다. 프로비저닝된 인스턴스는 재활용되기 전에 최대 1개월 동안 저장됩니다. 자세한 내용은 [CodeBuild Docker 서버 기능](https://aws.amazon.com/blogs//aws/accelerate-ci-cd-pipelines-with-the-new-aws-codebuild-docker-server-capability)을 참조하세요.
**중요**
이 샘플을 실행하면 AWS 계정에 요금이 부과될 수 있습니다. 여기에는 CodeBuild와 Amazon S3 및 CloudWatch Logs와 관련된 AWS 리소스 AWS KMS및 작업에 대해 발생할 수 있는 요금이 포함됩니다. 자세한 내용은 [CodeBuild 요금](https://aws.amazon.com/codebuild/pricing), [Amazon S3 요금](https://aws.amazon.com/s3/pricing), [AWS Key Management Service 요금](https://aws.amazon.com/kms/pricing) 및 [Amazon CloudWatch 요금](https://aws.amazon.com/cloudwatch/pricing)을 참조하세요.
**Topics**
+ [Docker 서버 구성](#sample-docker-server-running)
## Docker 서버 구성
다음 절차에 따라 Docker 워크로드를 관리하고 Docker 이미지 계층을 저장하는 CodeBuild 프로젝트의 전용 컴퓨팅 환경을 프로비저닝합니다.
**Docker 서버를 구성하려면**
1. 이 주제의 [디렉터리 구조](#sample-docker-server-dir) 및 [파일](#sample-docker-server-files) 섹션에 설명된 대로 파일을 생성한 다음 S3 입력 버킷 또는 AWS CodeCommit, GitHub 또는 Bitbucket 리포지토리에 업로드합니다.
**중요**
`(root directory name)`은 업로드하지 말고, `(root directory name)` 안에 있는 파일만 업로드하십시오.
S3 입력 버킷을 사용하고 있는 경우, 파일을 포함하는 ZIP 파일을 생성한 다음, 이를 입력 버킷에 업로드하십시오. `(root directory name)`을 ZIP 파일에 추가하지 말고, `(root directory name)` 안에 있는 파일만 추가하십시오.
1. 빌드 프로젝트를 생성하고, 빌드를 실행하고, 관련 빌드 정보를 확인합니다.
1. 콘솔의 **환경** 섹션에서 **추가 구성**을 선택하고 **Docker 서버 구성**으로 이동한 다음 **이 프로젝트에 대해 Docker 서버 활성화**를 선택합니다. 그런 다음 **Docker 서버 컴퓨팅 유형**을 선택하고 **레지스트리 자격 증명**을 제공할 수 있습니다.
1. AWS CLI 를 사용하여 빌드 프로젝트를 생성하는 경우 `create-project` 명령에 대한 JSON 형식의 입력은 이와 비슷할 수 있습니다. (자리 표시자는 사용자의 값으로 바꾸십시오.)
```
{
"name": "sample-docker-custom-image-project",
"source": {
"type": "S3",
"location": "codebuild-region-ID-account-ID-input-bucket/DockerServerSample.zip"
},
"artifacts": {
"type": "NO_ARTIFACTS"
},
"environment": {
"type": "LINUX_CONTAINER",
"image": "aws/codebuild/amazonlinux-x86_64-standard:5.0",
"computeType": "BUILD_GENERAL1_LARGE",
"dockerServer": [
{
"computeType": "BUILD_GENERAL1_LARGE",
"securityGroupIds": [ "security-groups-ID" ]
}
]
},
"serviceRole": "arn:aws:iam::account-ID:role/role-name"
}
```
**참고**
Docker 서버에 대해 구성된 보안 그룹은 프로젝트에 구성된 VPC의 수신 네트워크 트래픽을 허용해야 합니다. 포트 9876에서 수신을 허용해야 합니다.
1. 빌드 결과를 확인하려면 빌드 로그에서 `Hello, World!` 문자열에 대해 찾아보십시오. 자세한 내용은 [빌드 세부 정보 보기](view-build-details.md) 단원을 참조하십시오.
### 디렉터리 구조
이 샘플에서는 다음 디렉터리 구조를 가정합니다.
```
(root directory name)
├── buildspec.yml
└── Dockerfile
```
### 파일
이 샘플에 사용되는 운영 체제의 기본 이미지는 Ubuntu입니다. 샘플은 이러한 파일을 사용합니다.
`buildspec.yml`(`(root directory name)`에 있음)
```
version: 0.2
phases:
build:
commands:
- docker buildx build -t helloworld --load .
- docker run helloworld echo "Hello, World!"
```
`Dockerfile`(`(root directory name)`에 있음)
```
FROM public.ecr.aws/amazonlinux/amazonlinux:latest
RUN echo "Hello World"
```
# CodeBuild용 Windows Docker 빌드 샘플
다음 샘플은 CodeBuild를 사용하여 Windows Docker 이미지를 빌드하고 실행합니다.
**Topics**
+ [Windows Docker 빌드 샘플 실행](#sample-windows-docker-build-running)
## Windows Docker 빌드 샘플 실행
다음 절차에 따라 Windows Docker 빌드를 실행합니다.
**Windows Docker 빌드 샘플을 실행하려면**
1. 이 주제의 [디렉터리 구조](#sample-windows-docker-custom-image-dir) 및 [파일](#sample-windows-docker-custom-image-files) 섹션에 설명된 대로 파일을 생성한 다음 S3 입력 버킷 또는 AWS CodeCommit, GitHub 또는 Bitbucket 리포지토리에 업로드합니다.
**중요**
`(root directory name)`은 업로드하지 말고, `(root directory name)` 안에 있는 파일만 업로드하십시오.
S3 입력 버킷을 사용하고 있는 경우, 파일을 포함하는 ZIP 파일을 생성한 다음, 이를 입력 버킷에 업로드하십시오. `(root directory name)`을 ZIP 파일에 추가하지 말고, `(root directory name)` 안에 있는 파일만 추가하십시오.
1. `WINDOWS_EC2` 플릿을 생성합니다.
를 사용하여 AWS CLI 플릿을 생성하는 경우 `create-fleet` 명령에 대한 JSON 형식의 입력은 이와 비슷할 수 있습니다. (자리 표시자는 사용자의 값으로 바꾸십시오.)
```
{
"name": "fleet-name",
"baseCapacity": 1,
"environmentType": "WINDOWS_EC2",
"computeType": "BUILD_GENERAL1_MEDIUM"
}
```
1. 빌드 프로젝트를 생성하고, 빌드를 실행하고, 관련 빌드 정보를 확인합니다.
AWS CLI 를 사용하여 빌드 프로젝트를 생성하는 경우 `create-project` 명령에 대한 JSON 형식의 입력이 이와 비슷할 수 있습니다. (자리 표시자는 사용자의 값으로 바꾸십시오.)
```
{
"name": "project-name",
"source": {
"type": "S3",
"location": "bucket-name/DockerImageSample.zip"
},
"artifacts": {
"type": "NO_ARTIFACTS"
},
"environment": {
"type": "WINDOWS_EC2",
"image": "Windows",
"computeType": "BUILD_GENERAL1_MEDIUM",
"fleet": {
"fleetArn": "fleet-arn"
}
},
"serviceRole": "arn:aws:iam::account-ID:role/role-name"
}
```
1. 빌드 결과를 확인하려면 빌드 로그에서 `Hello, World!` 문자열에 대해 찾아보십시오. 자세한 내용은 [빌드 세부 정보 보기](view-build-details.md) 단원을 참조하십시오.
### 디렉터리 구조
이 샘플에서는 다음 디렉터리 구조를 가정합니다.
```
(root directory name)
├── buildspec.yml
└── Dockerfile
```
### 파일
이 샘플에 사용되는 운영 체제의 기본 이미지는 `mcr.microsoft.com/windows/servercore:ltsc2022`입니다. 샘플은 이러한 파일을 사용합니다.
`buildspec.yml`(`(root directory name)`에 있음)
```
version: 0.2
phases:
pre_build:
commands:
- docker build -t helloworld .
build:
commands:
- docker images
- docker run helloworld powershell -Command "Write-Host 'Hello World!'"
```
`Dockerfile`(`(root directory name)`에 있음)
```
FROM mcr.microsoft.com/windows/servercore:ltsc2022
RUN powershell -Command "Write-Host 'Hello World'"
```
# CodeBuild용 'Amazon ECR 이미지 리포지토리에 Docker 이미지 게시' 샘플
이 샘플은 빌드 출력으로 도커 이미지를 생산한 다음 도커 이미지를 Amazon Elastic Container Registry(Amazon ECR) 이미지 리포지토리에 푸시합니다. 이 샘플을 응용하여 도커 이미지를 Docker Hub에 푸시할 수도 있습니다. 자세한 내용은 ['Docker 이미지를 Amazon ECR에 게시' 샘플을 조정하여 Docker Hub로 푸시](sample-docker-docker-hub.md) 단원을 참조하십시오.
사용자 지정 도커 빌드 이미지(도커 허브의 `docker:dind`)를 사용하여 도커 이미지를 빌드하는 방법을 알아보려면 [도커 사용자 지정 이미지 샘플](sample-docker-custom-image.md) 단원을 참조하십시오.
이 샘플은 `golang:1.12`를 참조하여 테스트됩니다.
이 샘플에서는 도커 이미지를 빌드 출력으로 생성하는 새로운 다단계 Docker 빌드 기능을 사용합니다. 그런 다음, 도커 이미지를 Amazon ECR 이미지 리포지토리로 푸시합니다. 다단계 도커 이미지 빌드는 최종 도커 이미지의 크기를 줄이는 데 도움이 됩니다. 자세한 내용은 [Use multi-stage builds with Docker](https://docs.docker.com/engine/userguide/eng-image/multistage-build/)를 참조하십시오.
**중요**
이 샘플을 실행하면 AWS 계정에 요금이 부과될 수 있습니다. 여기에는 Amazon S3, , AWS KMS CloudWatch Logs AWS CodeBuild 및 Amazon ECR과 관련된 AWS 리소스 및 작업에 대한 및 요금이 포함됩니다. 자세한 내용은 [CodeBuild 요금](https://aws.amazon.com/codebuild/pricing), [Amazon S3 요금](https://aws.amazon.com/s3/pricing), [AWS Key Management Service 요금](https://aws.amazon.com/kms/pricing), [Amazon CloudWatch 요금](https://aws.amazon.com/cloudwatch/pricing), [Amazon Elastic Container Registry 요금](https://aws.amazon.com/ecr/pricing)을 참조하세요.
**Topics**
+ ['Amazon ECR에 Docker 이미지 게시' 샘플 실행](#sample-docker-running)
+ ['Docker 이미지를 Amazon ECR에 게시' 샘플을 조정하여 Docker Hub로 푸시](sample-docker-docker-hub.md)
## 'Amazon ECR에 Docker 이미지 게시' 샘플 실행
다음 절차에 따라 Amazon ECR에 Docker 이미지를 게시하는 샘플을 실행합니다. 이 샘플에 대한 자세한 내용은 [CodeBuild용 'Amazon ECR 이미지 리포지토리에 Docker 이미지 게시' 샘플](#sample-docker) 섹션을 참조하세요.
**이 샘플을 실행하려면**
1. Amazon ECR에 사용할 이미지 리포지토리가 이미 있으면 3단계로 이동하세요. 그렇지 않으면 AWS 루트 계정 또는 관리자 사용자 대신 사용자를 사용하여 Amazon ECR로 작업하는 경우이 문(*\$1\$1\$1 BEGIN ADDING STATEMENT HERE \$1\$1\$1과 **\$1\$1\$1 END ADDING STATEMENT HERE \$1\$1\$1* 사이)을 사용자(또는 사용자가 연결된 IAM 그룹)에 추가합니다. AWS 루트 계정을 사용하는 것은 권장되지 않습니다.이 문을 사용하면 Docker 이미지를 저장하기 위한 Amazon ECR 리포지토리를 생성할 수 있습니다. 간결하게 나타내고 명령문 추가 위치를 알 수 있도록 줄임표(`...`)가 사용되었습니다. 어떤 명령문도 제거하지 않아야 하며, 이러한 줄임표는 정책에 입력하지 않아야 합니다. 자세한 내용은 사용 설명서의 [AWS Management Console을 사용한 인라인 정책 작업](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_inline-using.html#AddingPermissions_Console)을 참조하세요.**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:CreateRepository"
],
"Resource": "*"
}
]
}
```
------
**참고**
이 정책을 수정하는 IAM 엔터티에는 정책을 수정하는 IAM의 권한이 있어야 합니다.
1. Amazon ECR에서 이미지 리포지토리를 생성합니다. 빌드 환경을 생성하고 빌드를 실행하는 리전과 동일한 AWS 리전에 리포지토리를 생성해야 합니다. 자세한 내용은 Amazon VPC 사용 설명서의 [리포지토리 생성](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-create.html)을 참조하세요.** 이 리포지토리의 이름은 이 절차의 뒷부분에서 지정하는 리포지토리 이름(`IMAGE_REPO_NAME` 환경 변수에 의해 표시됨)과 일치해야 합니다. Amazon ECR 리포지토리 정책이 CodeBuild 서비스 IAM 역할에 대한 이미지 푸시 액세스를 허용하는지 확인합니다.
1. AWS CodeBuild 서비스 역할에 연결한 정책에이 문(*\$1\$1\$1 BEGIN ADDING STATEMENT HERE \$1\$1\$1*와 *\$1\$1\$1 END ADDING STATEMENT HERE \$1\$1\$1* 사이)을 추가합니다. 다음 명령문을 사용하면 CodeBuild가 도커 이미지를 Amazon ECR 리포지토리에 업로드할 수 있습니다. 간결하게 나타내고 명령문 추가 위치를 알 수 있도록 줄임표(`...`)가 사용되었습니다. 어떤 명령문도 제거하지 않아야 하며, 이러한 줄임표는 정책에 입력하지 않아야 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:BatchCheckLayerAvailability",
"ecr:CompleteLayerUpload",
"ecr:GetAuthorizationToken",
"ecr:InitiateLayerUpload",
"ecr:PutImage",
"ecr:UploadLayerPart"
],
"Resource": "*"
}
]
}
```
------
**참고**
이 정책을 수정하는 IAM 엔터티에는 정책을 수정하는 IAM의 권한이 있어야 합니다.
1. 이 주제의 [디렉터리 구조](#sample-docker-dir) 및 [파일](#sample-docker-files) 섹션에 설명된 대로 파일을 생성한 다음 S3 입력 버킷 또는 AWS CodeCommit, GitHub 또는 Bitbucket 리포지토리에 업로드합니다. 자세한 내용은AWS CodePipeline 사용 설명서의 [이미지 정의 파일 참조](https://docs.aws.amazon.com/codepipeline/latest/userguide/file-reference.html)를 참조하세요.**
**중요**
`(root directory name)`은 업로드하지 말고, `(root directory name)` 안에 있는 파일만 업로드하십시오.
S3 입력 버킷을 사용하고 있는 경우, 파일을 포함하는 ZIP 파일을 생성한 다음, 이를 입력 버킷에 업로드하십시오. `(root directory name)`을 ZIP 파일에 추가하지 말고, `(root directory name)` 안에 있는 파일만 추가하십시오.
1. 빌드 프로젝트를 생성하고, 빌드를 실행하고, 빌드 정보를 확인합니다.
콘솔을 사용하여 프로젝트를 생성할 경우:
1. [**Operating system**]에서 [**Ubuntu**]를 선택합니다.
1. **실행 시간**에서 **표준**을 선택합니다.
1. **이미지**에서 **aws/codebuild/standard:5.0**을 선택합니다.
1. 다음 환경 변수를 추가합니다.
+ *region-ID* 값이 있는 AWS\$1DEFAULT\$1REGION
+ *account-ID* 값이 있는 AWS\$1ACCOUNT\$1ID
+ 최신 값이 있는 IMAGE\$1TAG
+ *Amazon-ECR-repo-name* 값이 있는 IMAGE\$1REPO\$1NAME
AWS CLI 를 사용하여 빌드 프로젝트를 생성하는 경우 `create-project` 명령에 대한 JSON 형식의 입력이 이와 비슷할 수 있습니다. (자리 표시자는 사용자의 값으로 바꾸십시오.)
```
{
"name": "sample-docker-project",
"source": {
"type": "S3",
"location": "codebuild-region-ID-account-ID-input-bucket/DockerSample.zip"
},
"artifacts": {
"type": "NO_ARTIFACTS"
},
"environment": {
"type": "LINUX_CONTAINER",
"image": "aws/codebuild/standard:5.0",
"computeType": "BUILD_GENERAL1_SMALL",
"environmentVariables": [
{
"name": "AWS_DEFAULT_REGION",
"value": "region-ID"
},
{
"name": "AWS_ACCOUNT_ID",
"value": "account-ID"
},
{
"name": "IMAGE_REPO_NAME",
"value": "Amazon-ECR-repo-name"
},
{
"name": "IMAGE_TAG",
"value": "latest"
}
],
},
"serviceRole": "arn:aws:iam::account-ID:role/role-name",
"encryptionKey": "arn:aws:kms:region-ID:account-ID:key/key-ID"
}
```
1. CodeBuild가 리포지토리에 도커 이미지를 성공적으로 푸시했는지 확인합니다.
1. Amazon ECR 콘솔([https://console.aws.amazon.com/ecr/](https://console.aws.amazon.com/ecr/))을 엽니다.
1. 리포지토리 이름을 선택합니다. **Image tag(이미지 태그)** 열에 이미지가 있어야 합니다.
### 디렉터리 구조
이 샘플에서는 다음 디렉터리 구조를 가정합니다.
```
(root directory name)
├── buildspec.yml
└── Dockerfile
```
### 파일
이 샘플은 다음 파일을 사용합니다.
`buildspec.yml`(`(root directory name)`에 있음)
```
version: 0.2
phases:
pre_build:
commands:
- echo Logging in to Amazon ECR...
- aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com
build:
commands:
- echo Build started on `date`
- echo Building the Docker image...
- docker build -t $IMAGE_REPO_NAME:$IMAGE_TAG .
- docker tag $IMAGE_REPO_NAME:$IMAGE_TAG $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME:$IMAGE_TAG
post_build:
commands:
- echo Build completed on `date`
- echo Pushing the Docker image...
- docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME:$IMAGE_TAG
```
`Dockerfile`(`(root directory name)`에 있음)
```
FROM golang:1.12-alpine AS build
#Install git
RUN apk add --no-cache git
#Get the hello world package from a GitHub repository
RUN go get github.com/golang/example/hello
WORKDIR /go/src/github.com/golang/example/hello
# Build the project and send the output to /bin/HelloWorld
RUN go build -o /bin/HelloWorld
FROM golang:1.12-alpine
#Copy the build's output binary from the previous build container
COPY --from=build /bin/HelloWorld /bin/HelloWorld
ENTRYPOINT ["/bin/HelloWorld"]
```
**참고**
CodeBuild는 사용자 지정 도커 이미지에 대해 `ENTRYPOINT`를 재정의합니다.
# 'Docker 이미지를 Amazon ECR에 게시' 샘플을 조정하여 Docker Hub로 푸시
Amazon ECR 대신 Docker 이미지가 Docker Hub로 푸시되도록 'Docker 이미지를 Amazon ECR에 게시' 샘플을 조정하려면 샘플의 코드를 편집합니다. 샘플에 대한 자세한 내용은 [CodeBuild용 'Amazon ECR 이미지 리포지토리에 Docker 이미지 게시' 샘플](sample-docker.md) 및 ['Amazon ECR에 Docker 이미지 게시' 샘플 실행](sample-docker.md#sample-docker-running) 섹션을 참조하세요.
**참고**
17.06 이전의 도커 버전을 사용하는 경우 `--no-include-email` 옵션을 제거합니다.
1. `buildspec.yml` 파일 내의 다음 Amazon ECR 특정 코드 행을 바꿉니다.
```
...
pre_build:
commands:
- echo Logging in to Amazon ECR...
- aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com
build:
commands:
- echo Build started on `date`
- echo Building the Docker image...
- docker build -t $IMAGE_REPO_NAME:$IMAGE_TAG .
- docker tag $IMAGE_REPO_NAME:$IMAGE_TAG $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME:$IMAGE_TAG
post_build:
commands:
- echo Build completed on `date`
- echo Pushing the Docker image...
- docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME:$IMAGE_TAG
...
```
다음 도커 허브 관련 코드 행으로 바꿉니다.
```
...
pre_build:
commands:
- echo Logging in to Docker Hub...
# Type the command to log in to your Docker Hub account here.
build:
commands:
- echo Build started on `date`
- echo Building the Docker image...
- docker build -t $IMAGE_REPO_NAME:$IMAGE_TAG .
- docker tag $IMAGE_REPO_NAME:$IMAGE_TAG $IMAGE_REPO_NAME:$IMAGE_TAG
post_build:
commands:
- echo Build completed on `date`
- echo Pushing the Docker image...
- docker push $IMAGE_REPO_NAME:$IMAGE_TAG
...
```
1. 편집된 코드를 S3 입력 버킷 또는 AWS CodeCommit, GitHub 또는 Bitbucket 리포지토리에 업로드합니다.
**중요**
`(root directory name)`은 업로드하지 말고, `(root directory name)` 안에 있는 파일만 업로드하십시오.
S3 입력 버킷을 사용하고 있는 경우, 파일을 포함하는 ZIP 파일을 생성한 다음, 이를 입력 버킷에 업로드하십시오. `(root directory name)`을 ZIP 파일에 추가하지 말고, `(root directory name)` 안에 있는 파일만 추가하십시오.
1. `create-project` 명령에 대한 JSON 형식 입력에서 다음 코드 행을 바꿉니다.
```
...
"environmentVariables": [
{
"name": "AWS_DEFAULT_REGION",
"value": "region-ID"
},
{
"name": "AWS_ACCOUNT_ID",
"value": "account-ID"
},
{
"name": "IMAGE_REPO_NAME",
"value": "Amazon-ECR-repo-name"
},
{
"name": "IMAGE_TAG",
"value": "latest"
}
]
...
```
다음 코드 행으로 바꿉니다.
```
...
"environmentVariables": [
{
"name": "IMAGE_REPO_NAME",
"value": "your-Docker-Hub-repo-name"
},
{
"name": "IMAGE_TAG",
"value": "latest"
}
]
...
```
1. 빌드 환경을 생성하고, 빌드를 실행하고, 관련 빌드 정보를 확인합니다.
1. 가 도커 이미지를 리포지토리에 AWS CodeBuild 성공적으로 푸시했는지 확인합니다. Docker Hub에 로그인하고, 리포지토리로 이동한 다음 [**Tags**] 탭을 선택합니다. `latest` 태그에 가장 최근의 [**Last Updated**] 값이 포함되어 있어야 합니다.
# CodeBuild용 AWS Secrets Manager 샘플이 포함된 프라이빗 레지스트리
이 샘플은 프라이빗 레지스트리에 AWS CodeBuild 런타임 환경으로 저장된 Docker 이미지를 사용하는 방법을 보여줍니다. 프라이빗 레지스트리의 보안 인증은 AWS Secrets Manager에 저장됩니다. 프라이빗 레지스트리는 모두 CodeBuild와 함께 작동합니다. 이 샘플은 Docker Hub를 사용합니다.
**참고**
보안 암호는 작업에 표시되며 파일에 기록될 때 가려지지 않습니다.
**Topics**
+ [프라이빗 레지스트리 샘플 요구 사항](#sample-private-registry-requirements)
+ [프라이빗 레지스트리로 CodeBuild 프로젝트 생성](private-registry-sample-create-project.md)
+ [자체 호스팅 러너에 대한 프라이빗 레지스트리 자격 증명 구성](private-registry-sample-configure-runners.md)
## 프라이빗 레지스트리 샘플 요구 사항
에서 프라이빗 레지스트리를 사용하려면 다음이 있어야 AWS CodeBuild합니다.
+ Docker Hub 보안 인증을 저장하는 Secrets Manager 보안 암호. 보안 인증은 프라이빗 리포지토리 액세스에 사용합니다.
**참고**
생성한 보안 암호에 대해 요금이 청구됩니다.
+ 프라이빗 리포지토리 또는 계정
+ Secrets Manager 보안 암호 액세스 권한을 부여하는 CodeBuild 서비스 역할의 IAM 정책
다음 단계를 따라 해당 리소스를 만든 다음, 프라이빗 레지스트리에 저장된 도커 이미지를 사용하여 CodeBuild 빌드 프로젝트를 생성합니다.
# 프라이빗 레지스트리로 CodeBuild 프로젝트 생성
1. 프리 프라이빗 리포지토리 생성 방법에 대한 자세한 내용은 [Docker Hub의 리포지토리](https://docs.docker.com/docker-hub/repos/)를 참조하십시오. 또한 터미널에서 다음 명령을 실행하여 이미지를 가져오고, 이미지의 ID를 확보하고, 새 리포지토리로 푸시할 수 있습니다.
```
docker pull amazonlinux
docker images amazonlinux --format {{.ID}}
docker tag image-id your-username/repository-name:tag
docker login
docker push your-username/repository-name
```
1. *AWS Secrets Manager 사용 설명서*의 [AWS Secrets Manager 보안 암호 생성](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) 단계를 따릅니다.
1. 3단계의 **보안 암호 유형 선택**에서 **다른 유형의 보안 암호**를 선택합니다.
1. **키/값 페어**에서 Docker Hub 사용자 이름에 대한 키-값 페어와 Docker Hub 암호에 대한 키-값 페어를 하나씩 생성합니다.
1. [AWS Secrets Manager 보안 암호 생성](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html)의 단계를 계속 따릅니다.
1. 키는 Docker Hub 보안 인증에 해당하므로 5단계의 **자동 교체 구성** 페이지에서 이 옵션을 끕니다.
1. [AWS Secrets Manager 보안 암호 생성](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html)의 단계에 따라 완료합니다.
자세한 내용은 [AWS Secrets Manager란 무엇입니까?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/)를 참조하세요.
1. 콘솔에서 AWS CodeBuild 프로젝트를 생성하면 CodeBuild가 필요한 권한을 연결합니다. 이외의 AWS KMS 키를 사용하는 경우 서비스 역할에 추가`DefaultEncryptionKey`해야 합니다. 자세한 내용은 IAM 사용 설명서의 [역할 수정(콘솔)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_modify.html#roles-managingrole-editing-console)을 참조하세요.**
Secrets Manager에서 서비스 역할이 작동하려면 최소한 `secretsmanager:GetSecretValue` 권한이 있어야 합니다.
![\[서비스 역할 구성입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/private-registry-sample-iam.png)
1. 콘솔을 사용하여 환경이 프라이빗 레지스트리에 저장되는 프로젝트를 생성하려면 프로젝트를 생성하면서 다음을 수행합니다. 자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 단원을 참조하세요.
**참고**
VPC에 프라이빗 레지스트리가 있는 경우 퍼블릭 인터넷 액세스가 가능해야 합니다. CodeBuild는 VPC의 프라이빗 IP 주소에서 이미지를 끌어올 수 없습니다.
1. **환경 이미지**에서 **사용자 지정 이미지**를 선택합니다.
1. **환경 유형**에서 **Linux** 또는 **Windows**를 선택합니다.
1. **이미지 레지스트리**의 경우 **다른 레지스트리**를 선택합니다.
1. **외부 레지스트리 URL**에 이미지 위치를 입력하고 **레지스트리 보안 인증 - 선택 사항**에 Secrets Manager 보안 인증의 ARN 또는 이름을 입력합니다.
**참고**
현재 리전에 보안 인증이 없을 경우 ARN을 사용해야 합니다. 다른 리전에 있는 보안 인증의 이름은 사용할 수 없습니다.
# 자체 호스팅 러너에 대한 프라이빗 레지스트리 자격 증명 구성
다음 지침에 따라 자체 호스팅 러너에 대한 레지스트리 자격 증명을 구성합니다.
**참고**
이러한 자격 증명은 이미지가 프라이빗 레지스트리의 자격 증명으로 재정의되는 경우에만 사용됩니다.
------
#### [ AWS Management Console ]
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.
1. 빌드 프로젝트를 생성하거나 기존 프로젝트를 선택합니다. 자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 및 [빌드 프로젝트 설정 변경(콘솔)](change-project.md#change-project-console) 섹션을 참조하세요.
1. **환경**에서 **추가 구성**을 선택합니다.
1. **추가 구성**에서 **레지스트리 자격 증명 - 선택** 사항으로에서 보안 암호의 이름 또는 ARN AWS Secrets Manager 을 입력합니다.
![\[레지스트리 자격 증명 구성입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/registry-credential.png)
------
#### [ AWS CLI ]
1. 새 프로젝트를 생성하려면 **create-project** 명령을 실행합니다.
```
aws codebuild create-project \
--name project-name \
--source type=source-type,location=source-location \
--environment "type=environment-type,image=image,computeType=compute-type,registryCredential={credentialProvider=SECRETS_MANAGER,credential=secret-name-or-arn},imagePullCredentialsType=CODEBUILD|SERVICE_ROLE" \
--artifacts type=artifacts-type \
--service-role arn:aws:iam::account-ID:role/service-role/service-role-name
```
1. 기존 프로젝트를 업데이트하려면 **update-project** 명령을 실행합니다.
```
aws codebuild update-project \
--name project-name \
--environment "type=environment-type,image=image,computeType=compute-type,registryCredential={credentialProvider=SECRETS_MANAGER,credential=secret-name-or-arn}"
```
------
# 빌드 출력을 S3 버킷에서 호스팅하여 정적 웹사이트 생성
빌드의 아티팩트 암호화를 비활성화할 수 있습니다. 이렇게 하면 웹 사이트를 호스팅하도록 구성된 위치에 아티팩트를 게시할 수 있습니다. (암호화된 아티팩트는 게시할 수 없습니다.) 이 샘플에서는 Webhook를 사용해 빌드를 트리거한 후 웹사이트를 구성하는 S3 버킷에 아티팩트를 게시하는 방법에 대해서 설명합니다.
1. [정적 웹사이트 설정](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HostingWebsiteOnS3Setup.html)의 지침을 따라 웹사이트처럼 작동하도록 S3 버킷을 구성합니다.
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.
1. CodeBuild 정보 페이지가 나타나면 **빌드 프로젝트 생성**을 선택합니다. 그렇지 않을 경우, 탐색 창에서 **빌드**를 확장한 후 **빌드 프로젝트**를 선택하고 **빌드 프로젝트 생성**을 선택합니다.
1. **프로젝트 이름**에 이 빌드 프로젝트의 이름을 입력합니다. 빌드 프로젝트 이름은 각 AWS 계정에서 고유해야 합니다. 또한 선택에 따라 빌드 프로젝트에 대한 설명을 포함하여 다른 사용자가 이 프로젝트의 용도를 이해하도록 도울 수 있습니다.
1. **소스**의 **소스 공급자**에서 **GitHub**를 선택합니다. GitHub와 연결(다시 연결)하는 지침을 따르고 **승인**을 선택합니다.
**Webhook**에서 **코드 변경이 이 리포지토리로 푸시될 때마다 다시 빌드**를 선택합니다. 이 확인란은 **내 GitHub 계정의 리포지토리**를 선택한 경우에만 선택할 수 있습니다.
![\[웹후크 구성입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/webhook.png)
1. **환경**에서 다음과 같이 합니다.
[**Environment image**]에서 다음 중 하나를 수행합니다.
+ 에서 관리하는 도커 이미지를 사용하려면 **관리형 이미지를** AWS CodeBuild선택한 다음 **운영 체제**, **런타임**, **이미지**(Image) 및 **이미지 버전**에서 선택합니다. 사용 가능한 경우 **환경 유형**에서 항목을 선택합니다.
+ 다른 도커 이미지를 사용하려면 **사용자 지정 이미지**를 선택합니다. **환경 유형**에서 **ARM**, **Linux**, **Linux GPU** 또는 **Windows**를 선택합니다. **Other registry(다른 레지스트리)**를 선택한 경우 **External registry URL(외부 레지스트리 URL)**에 Docker Hub의 도커 이미지 이름 및 태그를 `docker repository/docker image name` 형식으로 입력합니다. **Amazon ECR**을 선택하는 경우 **Amazon ECR 리포지토리**와 **Amazon ECR 이미지를** 사용하여 AWS 계정에서 도커 이미지를 선택합니다.
+ 프라이빗 도커 이미지를 사용하려면 **사용자 지정 이미지**를 선택합니다. **환경 유형**에서 **ARM**, **Linux**, **Linux GPU** 또는 **Windows**를 선택합니다. **Image registry(이미지 레지스트리)**에서 **Other registry(다른 레지스트리)**를 선택한 다음 프라이빗 도커 이미지에 대한 보안 인증 정보의 ARN을 입력합니다. 보안 인증은 Secrets Manager에서 생성됩니다. 자세한 내용은 AWS Secrets Manager사용 설명서의 [AWS Secrets Manager 이란?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/) 섹션을 참조하세요.**
1. **서비스 역할**에서 다음 중 하나를 수행합니다.
+ CodeBuild 서비스 역할이 없는 경우 **새 서비스 역할**을 선택합니다. **역할 이름**에 새 역할의 이름을 입력합니다.
+ CodeBuild 서비스 역할이 있는 경우 **기존 서비스 역할**을 선택합니다. **역할 ARN**에서 서비스 역할을 선택합니다.
**참고**
콘솔을 사용하여 빌드 프로젝트를 생성하거나 업데이트하는 경우, 이와 동시에 CodeBuild 서비스 역할을 만들 수 있습니다. 기본적으로 역할은 해당 빌드 프로젝트에서만 작동합니다. 콘솔을 사용하여 이 서비스 역할을 다른 빌드 프로젝트와 연결하는 경우 다른 빌드 프로젝트에서 작동하도록 역할이 업데이트됩니다. 하나의 서비스 역할은 최대 10개의 빌드 프로젝트에서 작동할 수 있습니다.
1. **Buildspec**에서 다음 중 하나를 수행합니다.
+ **buildspec 파일 사용**을 선택하여 소스 코드 루트 디렉터리에 있는 buildspec.yml 파일을 사용합니다.
+ **빌드 명령 삽입**을 선택하여 콘솔에서 빌드 명령을 삽입합니다.
자세한 내용은 [buildspec 참조](build-spec-ref.md) 단원을 참조하십시오.
1. **아티팩트**의 **유형**에서 **Amazon S3**를 선택하여 빌드 출력을 S3 버킷에 저장합니다.
1. **버킷 이름**에서 1단계에서 웹사이트처럼 작동하도록 구성한 S3 버킷의 이름을 선택합니다.
1. **환경**에서 **빌드 명령 삽입**을 선택한 경우 **출력 파일**에 대해 출력 버킷에 넣으려는 빌드의 파일 위치를 입력합니다. 위치가 두 개 이상인 경우 쉼표를 사용하여 각 위치를 구분합니다(예: **appspec.yml, target/my-app.jar**). 자세한 내용은 [Artifacts reference-key in the buildspec file](build-spec-ref.md#artifacts-build-spec) 단원을 참조하십시오.
1. **아티팩트 암호화 비활성화**를 선택합니다.
1. **추가 구성**을 확장하고 적절한 옵션을 선택합니다.
1. **빌드 프로젝트 생성**을 선택합니다. 빌드 프로젝트 페이지의 **빌드 기록**에서 **빌드 시작**을 선택하여 빌드를 실행합니다.
1. (선택 사항) *Amazon S3 Developer Guide*에 [예제: Amazon CloudFront를 이용해 웹 사이트 속도 높이기](https://docs.aws.amazon.com/AmazonS3/latest/userguide/website-hosting-cloudfront-walkthrough.html)의 지침을 따르세요.
# 다중 입력 소스 및 출력 아티팩트 샘플
입력 소스 1개 이상과 출력 결과물 세트 1개 이상을 사용해 AWS CodeBuild 빌드 프로젝트를 만들 수 있습니다. 이번 샘플은 아래와 같은 빌드 프로젝트를 설정하는 방법에 대한 내용입니다.
+ 유형에 따라 여러 가지 소스와 리포지토리를 사용합니다.
+ 단일 빌드에서 다수의 S3 버킷에 빌드 아티팩트를 게시합니다.
다음 샘플에서는 빌드 프로젝트를 생성하여 빌드를 실행하는 데 사용합니다. 또한 빌드 프로젝트의 buildspec 파일을 사용해 소스 1개 이상을 포함시키고, 아티팩트 세트 1개 이상을 생성하는 방법에 대해서 설명합니다.
CodeBuild에 대한 다중 소스 입력을 사용해 다중 출력 아티팩트를 생성하는 파이프라인을 만드는 방법은 [CodePipeline/CodeBuild와 다중 입력 소스 및 출력 아티팩트 통합 샘플](sample-codepipeline.md#sample-pipeline-multi-input-output) 섹션을 참조하세요.
**Topics**
+ [여러 입력 및 출력으로 빌드 프로젝트 생성](sample-multi-in-out-create.md)
+ [소스 없이 빌드 프로젝트 생성](no-source.md)
# 여러 입력 및 출력으로 빌드 프로젝트 생성
다음 절차에 따라 여러 입력 및 출력이 있는 빌드 프로젝트를 생성합니다.
**여러 입력 및 출력으로 빌드 프로젝트를 생성하려면**
1. 소스를 1개 이상의 S3 버킷, CodeCommit, GitHub, GitHub Enterprise Server 또는 Bitbucket 리포지토리에 업로드합니다.
1. 기본 소스로 사용할 소스를 선택합니다. 기본 소스란 CodeBuild가 buildspec 파일을 찾아서 실행하는 소스를 말합니다.
1. 빌드 프로젝트를 생성합니다. 자세한 내용은 [에서 빌드 프로젝트 생성AWS CodeBuild](create-project.md) 섹션을 참조하세요.
1. 빌드 프로젝트를 생성하고, 빌드를 실행하고, 빌드에 대한 정보를 가져옵니다.
1. AWS CLI를 사용하여 빌드 프로젝트를 생성하는 경우, `create-project` 명령에 JSON 형식으로 입력하면 다음과 같은 모습이 될 수 있습니다.
```
{
"name": "sample-project",
"source": {
"type": "S3",
"location": ""
},
"secondarySources": [
{
"type": "CODECOMMIT",
"location": "https://git-codecommit.us-west-2.amazonaws.com/v1/repos/repo",
"sourceIdentifier": "source1"
},
{
"type": "GITHUB",
"location": "https://github.com/awslabs/aws-codebuild-jenkins-plugin",
"sourceIdentifier": "source2"
}
],
"secondaryArtifacts": [ss
{
"type": "S3",
"location": "",
"artifactIdentifier": "artifact1"
},
{
"type": "S3",
"location": "",
"artifactIdentifier": "artifact2"
}
],
"environment": {
"type": "LINUX_CONTAINER",
"image": "aws/codebuild/standard:5.0",
"computeType": "BUILD_GENERAL1_SMALL"
},
"serviceRole": "arn:aws:iam::account-ID:role/role-name",
"encryptionKey": "arn:aws:kms:region-ID:account-ID:key/key-ID"
}
```
기본 소스는 `source` 속성에서 정의됩니다. 그 밖에 다른 소스는 보조 소스라고 불리며, `secondarySources`에 표시됩니다. 보조 소스는 모두 자체 디렉터리에 설치됩니다. 이 디렉터리는 내장 환경 변수인 `CODEBUILD_SRC_DIR_sourceIdentifer`에 저장됩니다. 자세한 내용은 [빌드 환경의 환경 변수](build-env-ref-env-vars.md) 섹션을 참조하세요.
`secondaryArtifacts` 속성에는 아티팩트 정의 목록이 포함됩니다. 이러한 아티팩트는 `secondary-artifacts` 블록 내에 중첩되는 buildspec 파일의 `artifacts` 블록을 사용합니다.
buildspec 파일의 보조 아티팩트는 아티팩트와 동일한 구조를 가지고 있지만 아티팩트 식별자로 구분됩니다.
**참고**
[CodeBuild API](https://docs.aws.amazon.com/codebuild/latest/APIReference/)에서는 보조 아티팩트의 `artifactIdentifier`가 `CreateProject` 및 `UpdateProject`에서 반드시 필요한 속성입니다. 보조 아티팩트를 참조할 때 사용해야 합니다.
앞서 얘기한 JSON 형식의 입력을 사용하면 프로젝트의 buildspec 파일은 다음과 같은 모습이 될 수 있습니다.
```
version: 0.2
phases:
install:
runtime-versions:
java: openjdk11
build:
commands:
- cd $CODEBUILD_SRC_DIR_source1
- touch file1
- cd $CODEBUILD_SRC_DIR_source2
- touch file2
artifacts:
files:
- '**.*'
secondary-artifacts:
artifact1:
base-directory: $CODEBUILD_SRC_DIR_source1
files:
- file1
artifact2:
base-directory: $CODEBUILD_SRC_DIR_source2
files:
- file2
```
기본 속성의 버전은 API를 사용해 `sourceVersion`의 `StartBuild` 속성에서 재정의할 수 있습니다. 보조 소스 버전을 1개 이상 재정의할 때는 `secondarySourceVersionOverride` 속성을 사용하십시오.
`start-build`에서 AWS CLI 명령에 JSON 형식으로 입력하면 다음과 같은 모습이 될 수 있습니다.
```
{
"projectName": "sample-project",
"secondarySourcesVersionOverride": [
{
"sourceIdentifier": "source1",
"sourceVersion": "codecommit-branch"
},
{
"sourceIdentifier": "source2",
"sourceVersion": "github-branch"
},
]
}
```
# 소스 없이 빌드 프로젝트 생성
소스를 구성할 때 **NO\$1SOURCE** 소스 유형을 선택하여 CodeBuild 프로젝트를 구성할 수 있습니다. 소스 유형이 **NO\$1SOURCE**일 경우, 프로젝트에 소스가 없으므로 buildspec 파일을 지정할 수 없습니다. 대신에 `buildspec` CLI 명령에 대한 JSON 형식 입력의 `create-project` 속성 내 YAML 형식 buildspec 문자열 지정이 필요합니다. 값이 다음과 같을 것입니다.
```
{
"name": "project-name",
"source": {
"type": "NO_SOURCE",
"buildspec": "version: 0.2\n\nphases:\n build:\n commands:\n - command"
},
"environment": {
"type": "LINUX_CONTAINER",
"image": "aws/codebuild/standard:5.0",
"computeType": "BUILD_GENERAL1_SMALL",
},
"serviceRole": "arn:aws:iam::account-ID:role/role-name",
"encryptionKey": "arn:aws:kms:region-ID:account-ID:key/key-ID"
}
```
자세한 내용은 [빌드 프로젝트 생성(AWS CLI)](create-project.md#create-project-cli) 섹션을 참조하세요.
# CodeBuild용 buildspec 파일 샘플의 런타임 버전
Amazon Linux 2(AL2) 표준 이미지 버전 1.0 이상 또는 Ubuntu 표준 이미지 버전 2.0 이상을 사용하는 경우 buildspec 파일의 `runtime-versions` 섹션에서 하나 이상의 런타임을 지정할 수 있습니다. 다음 샘플은 프로젝트 런타임 변경, 둘 이상의 런타임 지정, 다른 런타임에 종속되는 런타임 지정 방법을 보여줍니다. 지원되는 런타임에 대한 자세한 내용은 [CodeBuild가 제공하는 도커 이미지](build-env-ref-available.md) 단원을 참조하십시오.
**참고**
빌드 컨테이너에서 도커를 사용할 경우에는 권한이 있는 모드에서 빌드가 실행되어야 합니다. 자세한 내용은 [수동으로 AWS CodeBuild 빌드 실행](run-build.md) 및 [에서 빌드 프로젝트 생성AWS CodeBuild](create-project.md) 섹션을 참조하세요.
**Topics**
+ [buildspec 파일의 런타임 버전 업데이트](sample-runtime-update-version.md)
+ [런타임 2개 지정](sample-runtime-two-major-version-runtimes.md)
# buildspec 파일의 런타임 버전 업데이트
buildspec 파일의 `runtime-versions` 섹션을 업데이트하여 프로젝트에서 사용되는 런타임을 새 버전으로 수정할 수 있습니다. 다음 예제는 Java 버전 8 및 11을 지정하는 방법을 보여 줍니다.
+ Java 버전 8을 지정하는 `runtime-versions` 부분:
```
phases:
install:
runtime-versions:
java: corretto8
```
+ Java 버전 11을 지정하는 `runtime-versions` 부분:
```
phases:
install:
runtime-versions:
java: corretto11
```
다음 예제는 Ubuntu 표준 이미지 5.0 또는 Amazon Linux 2 표준 이미지 3.0을 사용하여 Python의 다양한 버전을 지정하는 방법을 보여 줍니다.
+ Python 버전 3.7을 지정하는 `runtime-versions` 섹션:
```
phases:
install:
runtime-versions:
python: 3.7
```
+ Python 버전 3.8을 지정하는 `runtime-versions` 섹션:
```
phases:
install:
runtime-versions:
python: 3.8
```
이 샘플은 Java 버전 8 런타임으로 시작해서 이후 Java 버전 10 런타임으로 업데이트되는 프로젝트를 보여줍니다.
1. Maven을 다운로드하고 설치합니다. 자세한 정보는 Apache Maven 웹 사이트의 [Downloading Apache Maven](https://maven.apache.org/download.cgi) 및 [Installing Apache Maven](https://maven.apache.org/install.html) 단원을 참조하십시오.
1. 로컬 컴퓨터나 인스턴스의 빈 디렉터리로 전환한 다음, 아래 Maven 명령을 실행합니다.
```
mvn archetype:generate "-DgroupId=com.mycompany.app" "-DartifactId=ROOT" "-DarchetypeArtifactId=maven-archetype-webapp" "-DinteractiveMode=false"
```
성공하면 다음 디렉터리 구조 및 파일이 생성됩니다.
```
.
└── ROOT
├── pom.xml
└── src
└── main
├── resources
└── webapp
├── WEB-INF
│ └── web.xml
└── index.jsp
```
1. 다음 콘텐츠를 가진 `buildspec.yml`이라는 파일을 생성합니다: 파일을 ` (root directory name)/my-web-app` 디렉터리에 저장합니다.
```
version: 0.2
phases:
install:
runtime-versions:
java: corretto8
build:
commands:
- java -version
- mvn package
artifacts:
files:
- '**/*'
base-directory: 'target/my-web-app'
```
buildspec 파일에서
+ `runtime-versions` 부분은 해당 프로젝트에서 Java 런타임 버전 8을 사용하도록 지정합니다.
+ `- java -version` 명령은 빌드할 때 프로젝트에서 사용하는 Java 버전을 표시합니다.
파일 구조가 아래와 같이 나타날 것입니다.
```
(root directory name)
└── my-web-app
├── src
│ ├── main
│ ├── resources
│ └── webapp
│ └── WEB-INF
│ └── web.xml
│ └── index.jsp
├── buildspec.yml
└── pom.xml
```
1. `my-web-app` 디렉터리의 내용을 S3 입력 버킷이나 CodeCommit, GitHub 또는 Bitbucket 리포지토리에 업로드합니다.
**중요**
`(root directory name)` 또는 `(root directory name)/my-web-app`은 업로드하지 말고, `(root directory name)/my-web-app` 안에 있는 디렉터리 및 파일만 업로드하십시오.
S3 입력 버킷을 사용하고 있는 경우, 디렉터리 구조 및 파일을 포함하는 ZIP 파일을 생성한 다음, 이를 입력 버킷에 업로드합니다. `(root directory name)` 또는 `(root directory name)/my-web-app`을 ZIP 파일에 추가하지 말고, `(root directory name)/my-web-app` 안에 있는 디렉터리 및 파일만 추가하십시오.
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.
1. 빌드 프로젝트를 생성합니다. 자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 및 [빌드 실행(콘솔)](run-build-console.md) 섹션을 참조하세요. 다음 설정을 제외하고 모든 설정을 기본값 그대로 둡니다.
+ **환경**:
+ **환경 이미지**에서 **이미지 관리**를 선택합니다.
+ **운영 체제**에서 **Amazon Linux 2**를 선택합니다.
+ **런타임**에서 **표준**을 선택합니다.
+ **이미지**의 경우 **aws/codebuild/amazonlinux-x86\$164-standard:4.0**을 선택합니다.
1. **빌드 시작**를 선택합니다.
1. **Build configuration(빌드 구성)**에서 기본값을 적용한 다음 **빌드 시작**을 선택합니다.
1. 빌드가 완료되면 **빌드 로그** 탭에서 빌드 출력을 확인합니다. 다음과 유사한 출력 화면이 표시되어야 합니다.
```
[Container] Date Time Phase is DOWNLOAD_SOURCE
[Container] Date Time CODEBUILD_SRC_DIR=/codebuild/output/src460614277/src
[Container] Date Time YAML location is /codebuild/output/src460614277/src/buildspec.yml
[Container] Date Time Processing environment variables
[Container] Date Time Selecting 'java' runtime version 'corretto8' based on manual selections...
[Container] Date Time Running command echo "Installing Java version 8 ..."
Installing Java version 8 ...
[Container] Date Time Running command export JAVA_HOME="$JAVA_8_HOME"
[Container] Date Time Running command export JRE_HOME="$JRE_8_HOME"
[Container] Date Time Running command export JDK_HOME="$JDK_8_HOME"
[Container] Date Time Running command for tool_path in "$JAVA_8_HOME"/bin/* "$JRE_8_HOME"/bin/*;
```
1. Java 버전 11의 `runtime-versions` 부분 업데이트:
```
install:
runtime-versions:
java: corretto11
```
1. 변경을 저장한 후 빌드를 다시 실행하고 빌드 출력을 확인합니다. Java 설치 버전이 11인지 확인해야 합니다. 다음과 유사한 출력 화면이 표시되어야 합니다.
```
[Container] Date Time Phase is DOWNLOAD_SOURCE
[Container] Date Time CODEBUILD_SRC_DIR=/codebuild/output/src460614277/src
[Container] Date Time YAML location is /codebuild/output/src460614277/src/buildspec.yml
[Container] Date Time Processing environment variables
[Container] Date Time Selecting 'java' runtime version 'corretto11' based on manual selections...
Installing Java version 11 ...
[Container] Date Time Running command export JAVA_HOME="$JAVA_11_HOME"
[Container] Date Time Running command export JRE_HOME="$JRE_11_HOME"
[Container] Date Time Running command export JDK_HOME="$JDK_11_HOME"
[Container] Date Time Running command for tool_path in "$JAVA_11_HOME"/bin/* "$JRE_11_HOME"/bin/*;
```
# 런타임 2개 지정
동일한 CodeBuild 빌드 프로젝트에서 둘 이상의 런타임을 지정할 수 있습니다. 이 샘플은 두 개의 소스 파일을 사용하는데 하나는 Go 런타임을 사용하고, 다른 하나는 Node.js 런타임을 사용합니다.
1. `my-source`이라는 디렉터리를 생성합니다.
1. `my-source` 디렉터리 안에 이름이 `golang-app`인 디렉터리를 생성합니다.
1. 다음 콘텐츠를 가진 `hello.go`이라는 파일을 생성합니다: 파일을 `golang-app` 디렉터리에 저장합니다.
```
package main
import "fmt"
func main() {
fmt.Println("hello world from golang")
fmt.Println("1+1 =", 1+1)
fmt.Println("7.0/3.0 =", 7.0/3.0)
fmt.Println(true && false)
fmt.Println(true || false)
fmt.Println(!true)
fmt.Println("good bye from golang")
}
```
1. `my-source` 디렉터리 안에 이름이 `nodejs-app`인 디렉터리를 생성합니다. `golang-app` 디렉터리와 레벨이 같아야 합니다.
1. 다음 콘텐츠를 가진 `index.js`이라는 파일을 생성합니다: 파일을 `nodejs-app` 디렉터리에 저장합니다.
```
console.log("hello world from nodejs");
console.log("1+1 =" + (1+1));
console.log("7.0/3.0 =" + 7.0/3.0);
console.log(true && false);
console.log(true || false);
console.log(!true);
console.log("good bye from nodejs");
```
1. 다음 콘텐츠를 가진 `package.json`이라는 파일을 생성합니다: 파일을 `nodejs-app` 디렉터리에 저장합니다.
```
{
"name": "mycompany-app",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"run some tests here\""
},
"author": "",
"license": "ISC"
}
```
1. 다음 콘텐츠를 가진 `buildspec.yml`이라는 파일을 생성합니다: `my-source` 디렉터리에, `nodejs-app` 및 `golang-app` 디렉터리와 같은 레벨에 파일을 저장합니다. `runtime-versions` 섹션은 Node.js 버전 12 및 Go 버전 1.13 런타임을 지정합니다.
```
version: 0.2
phases:
install:
runtime-versions:
golang: 1.13
nodejs: 12
build:
commands:
- echo Building the Go code...
- cd $CODEBUILD_SRC_DIR/golang-app
- go build hello.go
- echo Building the Node code...
- cd $CODEBUILD_SRC_DIR/nodejs-app
- npm run test
artifacts:
secondary-artifacts:
golang_artifacts:
base-directory: golang-app
files:
- hello
nodejs_artifacts:
base-directory: nodejs-app
files:
- index.js
- package.json
```
1. 파일 구조가 아래와 같이 나타날 것입니다.
```
my-source
├── golang-app
│ └── hello.go
├── nodejs.app
│ ├── index.js
│ └── package.json
└── buildspec.yml
```
1. `my-source` 디렉터리의 내용을 S3 입력 버킷이나 CodeCommit, GitHub 또는 Bitbucket 리포지토리에 업로드합니다.
**중요**
S3 입력 버킷을 사용하고 있는 경우, 디렉터리 구조 및 파일을 포함하는 ZIP 파일을 생성한 다음, 이를 입력 버킷에 업로드합니다. `my-source`를 ZIP 파일에 추가하지 말고, `my-source`에 있는 디렉터리와 파일만 추가하십시오.
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.
1. 빌드 프로젝트를 생성합니다. 자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 및 [빌드 실행(콘솔)](run-build-console.md) 섹션을 참조하세요. 다음 설정을 제외하고 모든 설정을 기본값 그대로 둡니다.
+ **환경**:
+ **환경 이미지**에서 **이미지 관리**를 선택합니다.
+ **운영 체제**에서 **Amazon Linux 2**를 선택합니다.
+ **런타임**에서 **표준**을 선택합니다.
+ **이미지**의 경우 **aws/codebuild/amazonlinux-x86\$164-standard:4.0**을 선택합니다.
1. **빌드 프로젝트 생성**을 선택합니다.
1. **빌드 시작**를 선택합니다.
1. **Build configuration(빌드 구성)**에서 기본값을 적용한 다음 **빌드 시작**을 선택합니다.
1. 빌드가 완료되면 **빌드 로그** 탭에서 빌드 출력을 확인합니다. 다음과 유사한 출력 화면이 표시되어야 합니다. Go 및 Node.js 런타임의 출력을 보여줍니다. Go 및 Node.js 애플리케이션의 출력도 보여줍니다.
```
[Container] Date Time Processing environment variables
[Container] Date Time Selecting 'golang' runtime version '1.13' based on manual selections...
[Container] Date Time Selecting 'nodejs' runtime version '12' based on manual selections...
[Container] Date Time Running command echo "Installing Go version 1.13 ..."
Installing Go version 1.13 ...
[Container] Date Time Running command echo "Installing Node.js version 12 ..."
Installing Node.js version 12 ...
[Container] Date Time Running command n $NODE_12_VERSION
installed : v12.20.1 (with npm 6.14.10)
[Container] Date Time Moving to directory /codebuild/output/src819694850/src
[Container] Date Time Registering with agent
[Container] Date Time Phases found in YAML: 2
[Container] Date Time INSTALL: 0 commands
[Container] Date Time BUILD: 1 commands
[Container] Date Time Phase complete: DOWNLOAD_SOURCE State: SUCCEEDED
[Container] Date Time Phase context status code: Message:
[Container] Date Time Entering phase INSTALL
[Container] Date Time Phase complete: INSTALL State: SUCCEEDED
[Container] Date Time Phase context status code: Message:
[Container] Date Time Entering phase PRE_BUILD
[Container] Date Time Phase complete: PRE_BUILD State: SUCCEEDED
[Container] Date Time Phase context status code: Message:
[Container] Date Time Entering phase BUILD
[Container] Date Time Running command echo Building the Go code...
Building the Go code...
[Container] Date Time Running command cd $CODEBUILD_SRC_DIR/golang-app
[Container] Date Time Running command go build hello.go
[Container] Date Time Running command echo Building the Node code...
Building the Node code...
[Container] Date Time Running command cd $CODEBUILD_SRC_DIR/nodejs-app
[Container] Date Time Running command npm run test
> mycompany-app@1.0.0 test /codebuild/output/src924084119/src/nodejs-app
> echo "run some tests here"
run some tests here
```
# 를 사용한 소스 버전 샘플 AWS CodeBuild
이 샘플은 커밋 ID 외의 형식(커밋 SHA라고 함)을 사용하여 소스 버전을 지정하는 방법을 입증합니다. 다음 방법으로 소스 버전을 지정할 수 있습니다.
+ Amazon S3 소스 공급자의 경우 빌드 입력 ZIP 파일을 나타내는 객체의 버전 ID를 사용합니다.
+ CodeCommit의 경우 Bitbucket, GitHub 및 GitHub Enterprise Server는 다음 중 하나를 사용합니다.
+ 풀 요청 참조로서 풀 요청(예: `refs/pull/1/head`).
+ 브랜치 이름으로 브랜치합니다.
+ 커밋 ID.
+ 태그.
+ 참조 및 커밋 ID. 참조는 다음 중 하나일 수 있습니다.
+ 태그(예: `refs/tags/mytagv1.0^{full-commit-SHA}`).
+ 브랜치(예: `refs/heads/mydevbranch^{full-commit-SHA}`).
+ 풀 요청(예: `refs/pull/1/head^{full-commit-SHA}`).
+ GitLab 및 GitLab Self Managed의 경우 다음 중 하나를 사용합니다.
+ 브랜치 이름으로 브랜치합니다.
+ 커밋 ID.
+ 태그.
**참고**
리포지토리가 GitHub 또는 GitHub Enterprise Server인 경우에만 풀 요청 소스 버전을 지정할 수 있습니다.
참조 및 커밋 ID를 사용하여 버전을 지정하는 경우 빌드의 `DOWNLOAD_SOURCE` 단계는 버전만을 제공하는 경우보다 더 빠릅니다. 그 이유는 참조 추가 시 CodeBuild가 커밋을 찾기 위해 전체 리포지토리를 다운로드할 필요가 없기 때문입니다.
+ 커밋 ID(예: `12345678901234567890123467890123456789`)만을 사용하여 소스 버전을 지정할 수 있습니다. 이 경우 CodeBuild는 버전을 찾기 위해 전체 리포지토리를 다운로드해야 합니다.
+ 다음 형식으로 참조 및 커밋 ID를 사용하여 소스 버전을 지정할 수 있습니다. `refs/heads/branchname^{full-commit-SHA}`(예: `refs/heads/main^{12345678901234567890123467890123456789}`). 이 경우 CodeBuild는 버전을 찾기 위해 지정한 분기만 다운로드합니다.
**참고**
또한 빌드의 `DOWNLOAD_SOURCE` 단계를 촉진하기 위해 **Git clone depth**를 낮은 값으로 설정할 수 있습니다. CodeBuild는 더 적은 수의 리포지토리 버전을 다운로드합니다.
**Topics**
+ [커밋 ID를 사용하여 GitHub 리포지토리 버전 지정](sample-source-version-github.md)
+ [참조 및 커밋 ID를 사용하여 GitHub 리포지토리 버전 지정](sample-source-version-github-ref.md)
# 커밋 ID를 사용하여 GitHub 리포지토리 버전 지정
커밋 ID(예: `12345678901234567890123467890123456789`)만을 사용하여 소스 버전을 지정할 수 있습니다. 이 경우 CodeBuild는 버전을 찾기 위해 전체 리포지토리를 다운로드해야 합니다.
**커밋 ID를 사용하여 GitHub 리포지토리 버전을 지정하려면**
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.
1. 빌드 프로젝트를 생성합니다. 자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 및 [빌드 실행(콘솔)](run-build-console.md) 섹션을 참조하세요. 다음 설정을 제외하고 모든 설정을 기본값 그대로 둡니다.
+ **소스**에서 다음과 같이 합니다.
+ **소스 공급자**에서 **GitHub**를 선택합니다. GitHub에 연결되어 있지 않은 경우 연결 지침을 따릅니다.
+ **리포지토리**에서 **퍼블릭 리포지토리**를 선택합니다.
+ **리포지토리 URL**에 **https://github.com/aws/aws-sdk-ruby.git**을 입력합니다.
+ **환경**에서 다음과 같이 합니다.
+ **환경 이미지**에서 **이미지 관리**를 선택합니다.
+ **운영 체제**에서 **Amazon Linux 2**를 선택합니다.
+ **런타임**에서 **표준**을 선택합니다.
+ **이미지**의 경우 **aws/codebuild/amazonlinux-x86\$164-standard:4.0**을 선택합니다.
1. **빌드 사양**에서 **빌드 명령 삽입**을 선택한 후 **편집기로 전환**을 선택합니다.
1. **빌드 명령**에서 자리표시자 텍스트를 다음으로 바꿉니다.
```
version: 0.2
phases:
install:
runtime-versions:
ruby: 2.6
build:
commands:
- echo $CODEBUILD_RESOLVED_SOURCE_VERSION
```
Ubuntu 표준 이미지 2.0 사용 시 `runtime-versions` 섹션이 필요합니다. 여기서 Ruby 버전 2.6 런타임이 지정되지만, 모든 런타임을 사용할 수 있습니다. `echo` 명령은 `CODEBUILD_RESOLVED_SOURCE_VERSION` 환경 변수에 저장된 소스 코드 버전을 표시합니다.
1. **Build configuration(빌드 구성)**에서 기본값을 적용한 다음 **빌드 시작**을 선택합니다.
1. **소스 버전**에 **046e8b67481d53bdc86c3f6affdd5d1afae6d369**를 입력합니다. 이는 `https://github.com/aws/aws-sdk-ruby.git` 리포지토리의 커밋 SHA입니다.
1. **빌드 시작**를 선택합니다.
1. 빌드 완료 시 다음과 같은 모양이어야 합니다.
+ **빌드 로그** 탭에서 프로젝트의 어떤 버전이 사용되었습니다. 다음 예를 참고하세요
```
[Container] Date Time Running command echo $CODEBUILD_RESOLVED_SOURCE_VERSION
046e8b67481d53bdc86c3f6affdd5d1afae6d369
[Container] Date Time Phase complete: BUILD State: SUCCEEDED
```
+ **환경 변수** 탭에서 **Resolved source version(해결된 소스 버전)**이 빌드 생성에 사용된 커밋 ID와 일치합니다.
+ **단계 세부 정보** 탭에서 `DOWNLOAD_SOURCE` 단계의 기간입니다.
# 참조 및 커밋 ID를 사용하여 GitHub 리포지토리 버전 지정
다음 형식으로 참조 및 커밋 ID를 사용하여 소스 버전을 지정할 수 있습니다. `refs/heads/branchname^{full-commit-SHA}`(예: `refs/heads/main^{12345678901234567890123467890123456789}`). 이 경우 CodeBuild는 버전을 찾기 위해 지정한 분기만 다운로드합니다.
**참조 및 커밋 ID를 사용하여 GitHub 리포지토리 버전을 지정하려면**
1. [커밋 ID를 사용하여 GitHub 리포지토리 버전 지정](sample-source-version-github.md)의 단계를 수행하세요.
1. 왼쪽 탐색 창에서 **빌드 프로젝트**를 선택한 후 이전에 생성된 프로젝트를 선택합니다.
1. **빌드 시작**를 선택합니다.
1. **소스 버전**에 **refs/heads/main^\$1046e8b67481d53bdc86c3f6affdd5d1afae6d369\$1**를 입력합니다. 이는 `refs/heads/branchname^{full-commit-SHA}` 형식의 브랜치 및 커밋 ID와 동일합니다.
1. **빌드 시작**를 선택합니다.
1. 빌드 완료 시 다음과 같은 모양이어야 합니다.
+ **빌드 로그** 탭에서 프로젝트의 어떤 버전이 사용되었습니다. 다음 예를 참고하세요
```
[Container] Date Time Running command echo $CODEBUILD_RESOLVED_SOURCE_VERSION
046e8b67481d53bdc86c3f6affdd5d1afae6d369
[Container] Date Time Phase complete: BUILD State: SUCCEEDED
```
+ **환경 변수** 탭에서 **Resolved source version(해결된 소스 버전)**이 빌드 생성에 사용된 커밋 ID와 일치합니다.
+ **단계 세부 정보** 탭에서 `DOWNLOAD_SOURCE` 단계의 기간은 커밋 ID만을 사용하여 소스 버전을 지정했을 때의 기간보다 짧아야 합니다.
# CodeBuild용 타사 소스 리포지토리 샘플
이 섹션에서는 타사 소스 리포지토리와 CodeBuild 간의 샘플 통합에 대해 설명합니다.
| 샘플 | 설명 |
| --- | --- |
| BitBucket pull 요청 및 웹후크 필터 샘플 – [CodeBuild용 'Bitbucket pull 요청 및 웹후크 필터' 샘플 실행](sample-bitbucket-pull-request.md) 참조 | 이 샘플에서는 Bitbucket 리포지토리를 사용하여 풀 요청을 생성하는 방법을 보여줍니다. 또한 Bitbucket webhook를 통해 CodeBuild를 트리거하여 프로젝트 빌드를 생성하는 방법을 보여줍니다. |
| GitHub Enterprise Server 샘플 – [CodeBuild용 GitHub Enterprise Server 샘플 실행](sample-github-enterprise.md) 참조 | 이 샘플에서는 GitHub Enterprise Server 리포지토리에 인증서가 설치되어 있을 때 CodeBuild 프로젝트를 설정하는 방법을 보여 줍니다. 또한 코드 변경이 GitHub Enterprise Server 리포지토리로 푸시될 때마다 CodeBuild가 다시 빌드되도록 Webhook를 활성화하는 방법도 보여줍니다. |
| GitHub pull 요청 및 웹후크 필터 샘플 – [CodeBuild용 GitHub pull 요청 및 웹후크 필터 샘플 실행](sample-github-pull-request.md) 참조 | 이 샘플에서는 GitHub Enterprise Server 리포지토리를 사용하여 pull 요청을 생성하는 방법을 보여줍니다. 또한 코드 변경이 GitHub Enterprise Server 리포지토리로 푸시될 때마다 CodeBuild가 다시 빌드되도록 Webhook를 활성화하는 방법도 보여줍니다. |
# CodeBuild용 'Bitbucket pull 요청 및 웹후크 필터' 샘플 실행
AWS CodeBuild 는 소스 리포지토리가 Bitbucket일 때 웹후크를 지원합니다. 즉, 소스 코드가 Bitbucket 리포지토리에 저장된 CodeBuild 빌드 프로젝트의 경우, Webhook는 코드 변경이 리포지토리에 푸시될 때마다 소스 코드를 다시 빌드하는 데 사용할 수 있습니다. 자세한 내용은 [Bitbucket Webhook 이벤트](bitbucket-webhook.md) 단원을 참조하십시오.
이 샘플에서는 Bitbucket 리포지토리를 사용하여 풀 요청을 생성하는 방법을 보여줍니다. 또한 Bitbucket webhook를 통해 CodeBuild를 트리거하여 프로젝트 빌드를 생성하는 방법을 보여줍니다.
**참고**
Webhook를 사용할 때 사용자가 예상치 못한 빌드를 트리거할 수 있습니다. 이 위험을 줄이려면 [webhook 사용 모범 사례](webhooks.md#webhook-best-practices) 섹션을 참조하세요.
**Topics**
+ [사전 조건](#sample-bitbucket-pull-request-prerequisites)
+ [1단계: Bitbucket을 사용하여 빌드 프로젝트 생성 및 웹후크 활성화](#sample-bitbucket-pull-request-create)
+ [2단계: Bitbucket 웹후크를 사용하여 빌드 트리거](#sample-bitbucket-pull-request-trigger)
## 사전 조건
이 샘플을 실행하려면 AWS CodeBuild 프로젝트를 Bitbucket 계정에 연결해야 합니다.
**참고**
CodeBuild에서 Bitbucket으로 권한을 업데이트했습니다. 이전에 프로젝트를 Bitbucket에 연결했지만 지금 Bitbucket 연결 오류를 수신한 경우 다시 연결하여 CodeBuild에 webhook 관리 권한을 부여해야 합니다.
## 1단계: Bitbucket을 사용하여 빌드 프로젝트 생성 및 웹후크 활성화
다음 단계에서는 Bitbucket을 소스 리포지토리로 사용하여 AWS CodeBuild 프로젝트를 생성하고 웹후크를 활성화하는 방법을 설명합니다.
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.
1. CodeBuild 정보 페이지가 나타나면 **빌드 프로젝트 생성**을 선택합니다. 그렇지 않을 경우, 탐색 창에서 **빌드**를 확장한 후 **빌드 프로젝트**를 선택하고 **빌드 프로젝트 생성**을 선택합니다.
1. **빌드 프로젝트 생성**을 선택합니다.
1. **프로젝트 구성**에서 다음과 같이 합니다.
**프로젝트 이름**
이 빌드 프로젝트의 이름을 입력합니다. 빌드 프로젝트 이름은 각 AWS 계정에서 고유해야 합니다. 또한 선택에 따라 빌드 프로젝트에 대한 설명을 포함하여 다른 사용자가 이 프로젝트의 용도를 이해하도록 도울 수 있습니다.
1. **소스**에서 다음과 같이 합니다.
**소스 공급자**
**Bitbucket**을 선택합니다. Bitbucket과 연결(다시 연결)하는 지침을 따르고 **승인**을 선택합니다.
**리포지토리**
**내 Bitbucket 계정의 리포지토리**를 선택합니다.
이전에 Bitbucket 계정에 연결한 적이 없으면 Bitbucket 사용자 이름과 앱 암호를 입력하고 **Bitbucket 보안 인증 저장**을 선택합니다.
**Bitbucket 리포지토리**
Bitbucket 리포지토리의 URL을 입력합니다.
1. **기본 소스 webhook 이벤트**에서 다음을 선택합니다.
**참고**
**기본 소스 webhook 이벤트** 섹션은 이전 단계에서 **Bitbucket 계정의 리포지토리**를 선택한 경우에만 표시됩니다.
1. 프로젝트를 생성할 때 **코드 변경이 이 리포지토리로 푸시될 때마다 다시 빌드**를 선택합니다.
1. **이벤트 유형**에서 하나 이상의 이벤트를 선택합니다.
1. 이벤트가 빌드를 트리거할 때를 필터링하려면 **Start a build under these conditions(다음 조건에서 빌드를 시작)**에서 하나 이상의 선택적 필터를 추가합니다.
1. 이벤트가 트리거되지 않을 때를 필터링하려면 **Don't start a build under these conditions(다음 조건에서 빌드를 시작하지 않음)**에서 하나 이상의 선택적 필터를 추가합니다.
1. 필요한 경우 **필터 그룹 추가**를 선택하여 다른 필터 그룹을 추가합니다.
Bitbucket webhook 이벤트 유형 및 필터에 대한 자세한 내용은 [Bitbucket Webhook 이벤트](bitbucket-webhook.md) 섹션을 참조하세요.
1. **환경**에서 다음과 같이 합니다.
**환경 이미지**
다음 중 하나를 선택합니다.
다음에서 관리하는 Docker 이미지를 사용하려면 AWS CodeBuild:
**관리형 이미지**를 선택한 후 **운영 체제**, **런타임**, **이미지** 및 **이미지 버전**에서 옵션을 선택합니다. 사용 가능한 경우 **환경 유형**에서 항목을 선택합니다.
다른 도커 이미지를 사용하려면:
**사용자 지정 이미지**를 선택합니다. **환경 유형**에서 **ARM**, **Linux**, **Linux GPU** 또는 **Windows**를 선택합니다. **Other registry(다른 레지스트리)**를 선택한 경우 **External registry URL(외부 레지스트리 URL)**에 Docker Hub의 도커 이미지 이름 및 태그를 `docker repository/docker image name` 형식으로 입력합니다. **Amazon ECR**을 선택하는 경우 **Amazon ECR 리포지토리**와 **Amazon ECR 이미지를** 사용하여 AWS 계정에서 도커 이미지를 선택합니다.
프라이빗 도커 이미지를 사용하려면:
**사용자 지정 이미지**를 선택합니다. **환경 유형**에서 **ARM**, **Linux**, **Linux GPU** 또는 **Windows**를 선택합니다. **Image registry(이미지 레지스트리)**에서 **Other registry(다른 레지스트리)**를 선택한 다음 프라이빗 도커 이미지에 대한 보안 인증 정보의 ARN을 입력합니다. 보안 인증은 Secrets Manager에서 생성됩니다. 자세한 내용은 *AWS Secrets Manager 사용 설명서*의 [What Is AWS Secrets Manager?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/)를 참조하세요.
**서비스 역할**
다음 중 하나를 선택합니다.
+ CodeBuild 서비스 역할이 없는 경우 **새 서비스 역할**을 선택합니다. **역할 이름**에 새 역할의 이름을 입력합니다.
+ CodeBuild 서비스 역할이 있는 경우 **기존 서비스 역할**을 선택합니다. **역할 ARN**에서 서비스 역할을 선택합니다.
콘솔을 사용하여 빌드 프로젝트를 생성하거나 업데이트하는 경우, 이와 동시에 CodeBuild 서비스 역할을 만들 수 있습니다. 기본적으로 역할은 해당 빌드 프로젝트에서만 작동합니다. 콘솔을 사용하여 이 서비스 역할을 다른 빌드 프로젝트와 연결하는 경우 다른 빌드 프로젝트에서 작동하도록 역할이 업데이트됩니다. 하나의 서비스 역할은 최대 10개의 빌드 프로젝트에서 작동할 수 있습니다.
1. **Buildspec**에서 다음 중 하나를 수행합니다.
+ **buildspec 파일 사용**을 선택하여 소스 코드 루트 디렉터리에 있는 buildspec.yml 파일을 사용합니다.
+ **빌드 명령 삽입**을 선택하여 콘솔에서 빌드 명령을 삽입합니다.
자세한 내용은 [buildspec 참조](build-spec-ref.md) 단원을 참조하십시오.
1. **결과물**에서 다음과 같이 합니다.
**유형**
다음 중 하나를 선택합니다.
+ 빌드 출력 아티팩트를 생성하지 않으려면 **No artifacts(아티팩트 없음)**를 선택합니다.
+ S3 버킷에 빌드 출력을 저장하려면 **Amazon S3**를 선택하고 다음 작업을 수행합니다.
+ 빌드 출력 ZIP 파일이나 폴더에 프로젝트 이름을 사용하려는 경우 **이름**을 비워 둡니다. 그렇지 않으면 이름을 입력합니다. 기본적으로 결과물 이름은 프로젝트의 이름입니다. 다른 이름을 사용하려면 결과물 이름 상자에 해당 이름을 입력합니다. ZIP 파일을 출력하려면 zip 확장명을 포함시킵니다.
+ [**Bucket name**]에서 출력 버킷의 이름을 선택합니다.
+ 이 절차의 앞부분에서 **빌드 명령 삽입**을 선택한 경우 **출력 파일**에 빌드 출력 ZIP 파일 또는 폴더에 넣으려는 빌드의 파일 위치를 입력합니다. 위치가 여러 개인 경우 각 위치를 쉼표로 구분합니다(예: `appspec.yml, target/my-app.jar`). 자세한 내용은 [buildspec 구문](build-spec-ref.md#build-spec-ref-syntax)의 `files` 설명을 참조하십시오.
**추가 구성**
**Additional configuration(추가 구성)**을 확장하고 옵션을 적절하게 설정합니다.
1. **빌드 프로젝트 생성**을 선택합니다. **검토** 페이지에서 **빌드 시작**을 선택하여 빌드를 실행합니다.
## 2단계: Bitbucket 웹후크를 사용하여 빌드 트리거
Bitbucket 웹후크를 사용하는 프로젝트의 경우 Bitbucket 리포지토리가 소스 코드의 변경을 감지하면 빌드를 AWS CodeBuild 생성합니다.
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.
1. 탐색 창에서 **빌드 프로젝트**를 선택한 다음 webhook에서 Bitbucket 리포지토리와 연결된 프로젝트를 선택합니다. Bitbucket webhook 프로젝트 생성에 대한 자세한 내용은 [1단계: Bitbucket을 사용하여 빌드 프로젝트 생성 및 웹후크 활성화](#sample-bitbucket-pull-request-create) 섹션을 참조하세요.
1. 프로젝트의 Bitbucket 리포지토리에서 코드를 변경합니다.
1. Bitbucket 리포지토리에서 풀 요청을 생성합니다. 자세한 내용은 [API 요청 생성](https://www.atlassian.com/git/tutorials/making-a-pull-request)을 참조하십시오.
1. Bitbucket Webhook 페이지에서 **View request(요청 보기)**를 선택하여 최신 이벤트 목록을 봅니다.
1. **세부 정보 보기**를 선택하여 CodeBuild에서 반환되는 응답에 대한 세부 정보를 확인합니다. 값이 다음과 같을 것입니다.
```
"response":"Webhook received and build started: https://us-east-1.console.aws.amazon.com/codebuild/home..."
"statusCode":200
```
1. Bitbucket 풀 요청 페이지로 이동하여 빌드 상태를 확인합니다.
# CodeBuild용 GitHub Enterprise Server 샘플 실행
AWS CodeBuild 는 GitHub Enterprise Server를 소스 리포지토리로 지원합니다. 이 샘플에서는 GitHub Enterprise Server 리포지토리에 인증서가 설치되어 있을 때 CodeBuild 프로젝트를 설정하는 방법을 보여 줍니다. 또한 코드 변경이 GitHub Enterprise Server 리포지토리로 푸시될 때마다 CodeBuild가 다시 빌드되도록 Webhook를 활성화하는 방법도 보여줍니다.
**Topics**
+ [사전 조건](#sample-github-enterprise-prerequisites)
+ [1단계: GitHub Enterprise Server를 사용하여 빌드 프로젝트 생성 및 웹후크 활성화](#sample-github-enterprise-running)
## 사전 조건
1. CodeBuild 프로젝트에 대한 개인 액세스 토큰을 생성합니다. GitHub Enterprise 사용자를 생성하고 이 사용자를 위한 개인 액세스 토큰을 생성하는 것이 좋습니다. 이 토큰을 CodeBuild 프로젝트를 생성할 때 사용할 수 있도록 클립보드에 복사합니다. 자세한 내용은 GitHub Help 웹 사이트의 [Creating a personal access token for the command line](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/)을 참조하십시오.
개인 액세스 토큰을 생성할 때 정의에 **리포지토리** 범위를 포함시킵니다.
![\[정의의 repo 범위입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/scopes.png)
1. GitHub Enterprise Server에서 인증서를 다운로드합니다. CodeBuild는 인증서를 사용하여 리포지토리에 신뢰할 수 있는 SSL 연결을 만듭니다.
**Linux/macOS 클라이언트:**
터미널 창에서 다음 명령을 실행합니다.
```
echo -n | openssl s_client -connect HOST:PORTNUMBER \
| sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /folder/filename.pem
```
명령에서 자리 표시자를 다음 값으로 바꿉니다.
*HOST*. GitHub Enterprise Server 리포지토리의 IP 주소입니다.
*PORTNUMBER*. 연결에 사용하는 포트 번호입니다(예: 443).
*folder*. 인증서를 다운로드한 폴더입니다.
*filename*. 인증서 파일의 파일 이름입니다.
**중요**
인증서를 .pem 파일로 저장합니다.
**Windows 클라이언트:**
브라우저를 사용하여 GitHub Enterprise Server에서 인증서를 다운로드합니다. 사이트의 인증서 세부 정보를 보려면 자물쇠 아이콘을 선택합니다. 인증서를 내보내는 방법에 대한 자세한 내용은 브라우저 설명서를 참조하십시오.
**중요**
인증서를 .pem 파일로 저장합니다.
1. S3 버킷으로 인증서 파일을 업로드합니다. S3 버킷을 생성하는 방법에 대한 자세한 내용은 [S3 버킷을 생성하려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket.html)를 참조하십시오. S3 버킷으로 객체를 업로드하는 방법에 대한 자세한 내용은 [버킷에 파일 및 폴더를 업로드하려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html)를 참조하십시오.
**참고**
이 버킷은 빌드와 동일한 AWS 리전에 있어야 합니다. 예를 들어, CodeBuild가 미국 동부(오하이오) 리전에서 빌드를 실행하도록 명령을 지정하는 경우, 버킷도 미국 동부(오하이오) 리전에 있어야 합니다.
## 1단계: GitHub Enterprise Server를 사용하여 빌드 프로젝트 생성 및 웹후크 활성화
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.
1. CodeBuild 정보 페이지가 나타나면 **빌드 프로젝트 생성**을 선택합니다. 그렇지 않을 경우, 탐색 창에서 **빌드**를 확장한 후 **빌드 프로젝트**를 선택하고 **빌드 프로젝트 생성**을 선택합니다.
1. **프로젝트 이름**에 이 빌드 프로젝트의 이름을 입력합니다. 빌드 프로젝트 이름은 각 AWS 계정에서 고유해야 합니다. 또한 선택에 따라 빌드 프로젝트에 대한 설명을 포함하여 다른 사용자가 이 프로젝트의 용도를 이해하도록 도울 수 있습니다.
1. **소스**의 **소스 공급자**에서 **GitHub Enterprise Server**를 선택합니다.
+ **계정 자격 증명 관리**를 선택한 다음 **개인 액세스 토큰**을 선택합니다. **서비스**에서 **Secrets Manager(권장)**를 선택하고 보안 암호를 구성합니다. 그런 다음 **GitHub Enterprise 개인 액세스 토큰**에서 개인 액세스 토큰을 입력하고 **저장**을 선택합니다.
+ **리포지토리 URL**에 리포지토리 이름을 포함하여 리포지토리에 대한 경로를 입력합니다.
+ **추가 구성**을 확장합니다.
+ 코드 변경이 이 리포지토리로 푸시될 때마다 다시 빌드하려면 **코드 변경이 이 리포지토리로 푸시될 때마다 다시 빌드**를 선택합니다.
+ GitHub Enterprise Server 프로젝트 리포지토리에 연결되어 있는 동안 SSL 경고를 무시하려면 **안전하지 않은 SSL 활성화**를 선택합니다.
**참고**
**Enable insecure SSL(안전하지 않은 SSL 활성화)**는 테스트 용도로만 사용하는 것이 좋습니다. 프로덕션 환경에 사용하면 안 됩니다.
![\[GitHub Enterprise Server 프로젝트 리포지토리 구성입니다.\]](http://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/images/github-enterprise.png)
1. **환경**에서 다음과 같이 합니다.
[**Environment image**]에서 다음 중 하나를 수행합니다.
+ 에서 관리하는 도커 이미지를 사용하려면 **관리형 이미지를** AWS CodeBuild선택한 다음 **운영 체제**, **런타임**, **이미지**(Image) 및 **이미지 버전**에서 선택합니다. 사용 가능한 경우 **환경 유형**에서 항목을 선택합니다.
+ 다른 도커 이미지를 사용하려면 **사용자 지정 이미지**를 선택합니다. **환경 유형**에서 **ARM**, **Linux**, **Linux GPU** 또는 **Windows**를 선택합니다. **Other registry(다른 레지스트리)**를 선택한 경우 **External registry URL(외부 레지스트리 URL)**에 Docker Hub의 도커 이미지 이름 및 태그를 `docker repository/docker image name` 형식으로 입력합니다. **Amazon ECR**을 선택하는 경우 **Amazon ECR 리포지토리**와 **Amazon ECR 이미지를** 사용하여 AWS 계정에서 도커 이미지를 선택합니다.
+ 프라이빗 도커 이미지를 사용하려면 **사용자 지정 이미지**를 선택합니다. **환경 유형**에서 **ARM**, **Linux**, **Linux GPU** 또는 **Windows**를 선택합니다. **Image registry(이미지 레지스트리)**에서 **Other registry(다른 레지스트리)**를 선택한 다음 프라이빗 도커 이미지에 대한 보안 인증 정보의 ARN을 입력합니다. 보안 인증은 Secrets Manager에서 생성됩니다. 자세한 내용은 AWS Secrets Manager사용 설명서의 [AWS Secrets Manager 이란?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/) 섹션을 참조하세요.**
1. **서비스 역할**에서 다음 중 하나를 수행합니다.
+ CodeBuild 서비스 역할이 없는 경우 **새 서비스 역할**을 선택합니다. **역할 이름**에 새 역할의 이름을 입력합니다.
+ CodeBuild 서비스 역할이 있는 경우 **기존 서비스 역할**을 선택합니다. **역할 ARN**에서 서비스 역할을 선택합니다.
**참고**
콘솔을 사용하여 빌드 프로젝트를 생성하거나 업데이트하는 경우, 이와 동시에 CodeBuild 서비스 역할을 만들 수 있습니다. 기본적으로 역할은 해당 빌드 프로젝트에서만 작동합니다. 콘솔을 사용하여 이 서비스 역할을 다른 빌드 프로젝트와 연결하는 경우 다른 빌드 프로젝트에서 작동하도록 역할이 업데이트됩니다. 하나의 서비스 역할은 최대 10개의 빌드 프로젝트에서 작동할 수 있습니다.
1. **추가 구성**을 확장합니다.
CodeBuild를 사용하여 VPC에서 작업을 수행하려는 경우:
+ **VPC**에서 CodeBuild가 사용하는 VPC ID를 선택합니다.
+ **VPC 서브넷**에서 CodeBuild가 사용하는 리소스가 포함된 서브넷을 선택합니다.
+ **VPC 보안 그룹**에서 CodeBuild가 VPC의 리소스에 대한 액세스를 허용하기 위해 사용하는 보안 그룹을 선택합니다.
자세한 내용은 [Amazon Virtual Private Cloud AWS CodeBuild 와 함께 사용](vpc-support.md) 단원을 참조하십시오.
1. **Buildspec**에서 다음 중 하나를 수행합니다.
+ **buildspec 파일 사용**을 선택하여 소스 코드 루트 디렉터리에 있는 buildspec.yml 파일을 사용합니다.
+ **빌드 명령 삽입**을 선택하여 콘솔에서 빌드 명령을 삽입합니다.
자세한 내용은 [buildspec 참조](build-spec-ref.md) 단원을 참조하십시오.
1. **결과물**의 **유형**에서 다음 중 하나를 수행합니다.
+ 빌드 출력 아티팩트를 생성하지 않으려면 **No artifacts(아티팩트 없음)**를 선택합니다.
+ S3 버킷에 빌드 출력을 저장하려면 **Amazon S3**를 선택하고 다음 작업을 수행합니다.
+ 빌드 출력 ZIP 파일이나 폴더에 프로젝트 이름을 사용하려는 경우 **이름**을 비워 둡니다. 그렇지 않으면 이름을 입력합니다. 기본적으로 결과물 이름은 프로젝트의 이름입니다. 다른 이름을 사용하려면 결과물 이름 상자에 해당 이름을 입력합니다. ZIP 파일을 출력하려면 zip 확장명을 포함시킵니다.
+ [**Bucket name**]에서 출력 버킷의 이름을 선택합니다.
+ 이 절차의 앞부분에서 **빌드 명령 삽입**을 선택한 경우 **출력 파일**에 빌드 출력 ZIP 파일 또는 폴더에 넣으려는 빌드의 파일 위치를 입력합니다. 위치가 여러 개인 경우 각 위치를 쉼표로 구분합니다(예: `appspec.yml, target/my-app.jar`). 자세한 내용은 [buildspec 구문](build-spec-ref.md#build-spec-ref-syntax)의 `files` 설명을 참조하십시오.
1. **Cache type(캐시 유형)**에서 다음 중 하나를 선택합니다.
+ 캐시를 사용하지 않으려면 [**No cache**]를 선택합니다.
+ Amazon S3 캐시를 사용하려면 **Amazon S3**를 선택하고 다음을 수행합니다.
+ **버킷**에서 캐시가 저장된 S3 버킷의 이름을 선택합니다.
+ (선택 사항) **캐시 경로 접두사**에 Amazon S3 경로 접두사를 입력합니다. **Cache path prefix(캐시 경로 접두사)** 값은 디렉터리 이름과 비슷합니다. 따라서 캐시를 버킷의 동일한 디렉터리에 저장할 수 있습니다.
**중요**
경로 접두사 끝에 후행 슬래시(/)를 추가하지 마십시오.
+ 로컬 캐시를 사용하려면 **로컬**을 선택한 다음 하나 이상의 로컬 캐시 모드를 선택해야 합니다.
**참고**
Docker 계층 캐시 모드는 Linux에서만 사용할 수 있습니다. 이 모드를 선택할 경우 프로젝트를 권한이 있는 모드에서 실행해야 합니다.
캐시를 사용하면 빌드 환경의 재사용 가능한 특정 부분이 캐시에 저장되고 빌드 전반에서 사용되기 때문에 상당한 빌드 시간을 절약할 수 있습니다. buildspec 파일에 캐시를 지정하는 것에 대한 자세한 정보는 [buildspec 구문](build-spec-ref.md#build-spec-ref-syntax) 단원을 참조하십시오. 캐싱에 대한 자세한 정보는 [성능을 개선하기 위한 캐시 빌드](build-caching.md)을 참조하십시오.
1. **빌드 프로젝트 생성**을 선택합니다. 빌드 프로젝트 페이지에서 **빌드 시작**을 선택합니다.
# CodeBuild용 GitHub pull 요청 및 웹후크 필터 샘플 실행
AWS CodeBuild 는 소스 리포지토리가 GitHub인 경우 웹후크를 지원합니다. 즉, 소스 코드가 GitHub 리포지토리에 저장된 CodeBuild 빌드 프로젝트의 경우, Webhook는 코드 변경이 리포지토리에 푸시될 때마다 소스 코드를 다시 빌드하는 데 사용할 수 있습니다. CodeBuild 샘플은 [AWS CodeBuild 샘플](https://github.com/aws-samples/aws-codebuild-samples)을 참조하세요.
**참고**
Webhook를 사용할 때 사용자가 예상치 못한 빌드를 트리거할 수 있습니다. 이 위험을 줄이려면 [webhook 사용 모범 사례](webhooks.md#webhook-best-practices) 섹션을 참조하세요.
**Topics**
+ [1단계: GitHub로 빌드 프로젝트 생성 및 웹후크 활성화](#sample-github-pull-request-running)
+ [2단계: 웹후크가 활성화되어 있는지 확인](#verification-checks)
## 1단계: GitHub로 빌드 프로젝트 생성 및 웹후크 활성화
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.
1. CodeBuild 정보 페이지가 나타나면 **빌드 프로젝트 생성**을 선택합니다. 그렇지 않을 경우, 탐색 창에서 **빌드**를 확장한 후 **빌드 프로젝트**를 선택하고 **빌드 프로젝트 생성**을 선택합니다.
1. **빌드 프로젝트 생성**을 선택합니다.
1. **프로젝트 구성**에서 다음과 같이 합니다.
**프로젝트 이름**
이 빌드 프로젝트의 이름을 입력합니다. 빌드 프로젝트 이름은 각 AWS 계정에서 고유해야 합니다. 또한 선택에 따라 빌드 프로젝트에 대한 설명을 포함하여 다른 사용자가 이 프로젝트의 용도를 이해하도록 도울 수 있습니다.
1. **소스**에서 다음과 같이 합니다.
**소스 공급자**
**GitHub**를 선택하세요. GitHub와 연결(다시 연결)하는 지침을 따르고 **승인**을 선택합니다.
**리포지토리**
**내 GitHub 계정의 리포지토리**를 선택합니다.
**GitHub 리포지토리**
GitHub 리포지토리의 URL을 입력합니다.
1. **기본 소스 webhook 이벤트**에서 다음을 선택합니다.
**참고**
**기본 소스 webhook 이벤트** 섹션은 이전 단계에서 **내 GitHub 계정의 리포지토리**를 선택한 경우에만 표시됩니다.
1. 프로젝트를 생성할 때 **코드 변경이 이 리포지토리로 푸시될 때마다 다시 빌드**를 선택합니다.
1. **이벤트 유형**에서 하나 이상의 이벤트를 선택합니다.
1. 이벤트가 빌드를 트리거할 때를 필터링하려면 **Start a build under these conditions(다음 조건에서 빌드를 시작)**에서 하나 이상의 선택적 필터를 추가합니다.
1. 이벤트가 트리거되지 않을 때를 필터링하려면 **Don't start a build under these conditions(다음 조건에서 빌드를 시작하지 않음)**에서 하나 이상의 선택적 필터를 추가합니다.
1. 필요한 경우 **필터 그룹 추가**를 선택하여 다른 필터 그룹을 추가합니다.
GitHub Webhook 이벤트 유형 및 필터에 대한 자세한 내용은 [GitHub Webhook 이벤트](github-webhook.md) 섹션을 참조하세요.
1. **환경**에서 다음과 같이 합니다.
**환경 이미지**
다음 중 하나를 선택합니다.
다음에서 관리하는 Docker 이미지를 사용하려면 AWS CodeBuild:
**관리형 이미지**를 선택한 후 **운영 체제**, **런타임**, **이미지** 및 **이미지 버전**에서 옵션을 선택합니다. 사용 가능한 경우 **환경 유형**에서 항목을 선택합니다.
다른 도커 이미지를 사용하려면:
**사용자 지정 이미지**를 선택합니다. **환경 유형**에서 **ARM**, **Linux**, **Linux GPU** 또는 **Windows**를 선택합니다. **Other registry(다른 레지스트리)**를 선택한 경우 **External registry URL(외부 레지스트리 URL)**에 Docker Hub의 도커 이미지 이름 및 태그를 `docker repository/docker image name` 형식으로 입력합니다. **Amazon ECR**을 선택하는 경우 **Amazon ECR 리포지토리** 및 **Amazon ECR 이미지**를 사용하여 AWS 계정의 Docker 이미지를 선택합니다.
프라이빗 도커 이미지를 사용하려면:
**사용자 지정 이미지**를 선택합니다. **환경 유형**에서 **ARM**, **Linux**, **Linux GPU** 또는 **Windows**를 선택합니다. **Image registry(이미지 레지스트리)**에서 **Other registry(다른 레지스트리)**를 선택한 다음 프라이빗 도커 이미지에 대한 보안 인증 정보의 ARN을 입력합니다. 보안 인증은 Secrets Manager에서 생성됩니다. 자세한 내용은 *AWS Secrets Manager 사용 설명서*의 [What Is AWS Secrets Manager?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/)를 참조하세요.
**서비스 역할**
다음 중 하나를 선택합니다.
+ CodeBuild 서비스 역할이 없는 경우 **새 서비스 역할**을 선택합니다. **역할 이름**에 새 역할의 이름을 입력합니다.
+ CodeBuild 서비스 역할이 있는 경우 **기존 서비스 역할**을 선택합니다. **역할 ARN**에서 서비스 역할을 선택합니다.
콘솔을 사용하여 빌드 프로젝트를 생성하거나 업데이트하는 경우, 이와 동시에 CodeBuild 서비스 역할을 만들 수 있습니다. 기본적으로 역할은 해당 빌드 프로젝트에서만 작동합니다. 콘솔을 사용하여 이 서비스 역할을 다른 빌드 프로젝트와 연결하는 경우 다른 빌드 프로젝트에서 작동하도록 역할이 업데이트됩니다. 하나의 서비스 역할은 최대 10개의 빌드 프로젝트에서 작동할 수 있습니다.
1. **Buildspec**에서 다음 중 하나를 수행합니다.
+ **buildspec 파일 사용**을 선택하여 소스 코드 루트 디렉터리에 있는 buildspec.yml 파일을 사용합니다.
+ **빌드 명령 삽입**을 선택하여 콘솔에서 빌드 명령을 삽입합니다.
자세한 내용은 [buildspec 참조](build-spec-ref.md) 단원을 참조하십시오.
1. **결과물**에서 다음과 같이 합니다.
**유형**
다음 중 하나를 선택합니다.
+ 빌드 출력 아티팩트를 생성하지 않으려면 **No artifacts(아티팩트 없음)**를 선택합니다.
+ S3 버킷에 빌드 출력을 저장하려면 **Amazon S3**를 선택하고 다음 작업을 수행합니다.
+ 빌드 출력 ZIP 파일이나 폴더에 프로젝트 이름을 사용하려는 경우 **이름**을 비워 둡니다. 그렇지 않으면 이름을 입력합니다. 기본적으로 결과물 이름은 프로젝트의 이름입니다. 다른 이름을 사용하려면 결과물 이름 상자에 해당 이름을 입력합니다. ZIP 파일을 출력하려면 zip 확장명을 포함시킵니다.
+ [**Bucket name**]에서 출력 버킷의 이름을 선택합니다.
+ 이 절차의 앞부분에서 **빌드 명령 삽입**을 선택한 경우 **출력 파일**에 빌드 출력 ZIP 파일 또는 폴더에 넣으려는 빌드의 파일 위치를 입력합니다. 위치가 여러 개인 경우 각 위치를 쉼표로 구분합니다(예: `appspec.yml, target/my-app.jar`). 자세한 내용은 [buildspec 구문](build-spec-ref.md#build-spec-ref-syntax)의 `files` 설명을 참조하십시오.
**추가 구성**
**Additional configuration(추가 구성)**을 확장하고 옵션을 적절하게 설정합니다.
1. **빌드 프로젝트 생성**을 선택합니다. **검토** 페이지에서 **빌드 시작**을 선택하여 빌드를 실행합니다.
## 2단계: 웹후크가 활성화되어 있는지 확인
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.
1. 탐색 창에서 **프로젝트 빌드**를 선택합니다.
1. 다음 중 하나를 수행하세요.
+ webhook를 검증하려는 빌드 프로젝트의 링크를 선택한 후 **빌드 세부 정보**를 선택합니다.
+ webhook를 검증하려는 빌드 프로젝트 옆에 있는 라디오 버튼을 선택하고 **세부 정보 보기**를 선택한 후 **빌드 세부 정보**를 선택합니다.
1. **기본 소스 webhook 이벤트**에서 **Webhook** URL 링크를 선택합니다.
1. GitHub 리포지토리의 **설정** 페이지에 있는 **웹후크**에서 **Pull 요청** 및 **Push**가 선택되었는지 확인합니다.
1. GitHub 프로필 설정의 **개인 설정**, **애플리케이션**, **승인된 OAuth 앱에서** 선택한 AWS 리전에 액세스할 수 있는 권한이 애플리케이션에 부여되었음을 확인할 수 있습니다.
# 자습서: 인증서 스토리지에 S3를 사용하여 CodeBuild에서 Fastlane을 사용한 Apple 코드 서명
[fastlane](https://docs.fastlane.tools/)은 iOS 및 Android 앱의 베타 배포 및 릴리스를 자동화하는 오픈 소스 자동화 도구로 널리 사용됩니다. 스크린샷 생성, 코드 서명 처리, 애플리케이션 릴리스와 같은 모든 지루한 작업을 처리합니다.
## 사전 조건
이 자습서를 완료하려면 먼저 다음과 같은 사전 조건을 설정해야 합니다.
+ 의 경우 AWS 계정
+ [Apple 개발자 계정](https://developer.apple.com/)
+ 인증서를 저장하기 위한 S3 버킷
+ 프로젝트에 설치된 fastlane - fastlane 설치 [가이드](https://docs.fastlane.tools/getting-started/ios/setup/)
## 1단계: 로컬 시스템에서 S3를 사용하여 Fastlane Match 설정
[Fastlane Match](https://docs.fastlane.tools/actions/match/)는 [Fastlane 도구](https://fastlane.tools/) 중 하나이며 로컬 개발 환경과 CodeBuild 모두에서 코드 서명을 위한 원활한 구성을 지원합니다. Fastlane Match는 모든 코드 서명 인증서와 프로비저닝 프로필을 Git 리포지토리/S3 버킷/Google 클라우드 스토리지에 저장하고, 필요한 경우 필요한 인증서와 프로필을 다운로드하여 설치합니다.
이 예제 구성에서는 Amazon S3 버킷을 설정하고 스토리지에 사용합니다.
****
1. 프로젝트에서 일치 항목 초기화:
```
fastlane match init
```
1. 메시지가 표시되면 스토리지 모드로 S3를 선택합니다.
1. S3를 사용하도록 `*Matchfile*`을 업데이트합니다.
```
storage_mode("s3")
s3_bucket("your-s3-bucket-name")
s3_region("your-aws-region")
type("appstore") # The default type, can be: appstore, adhoc, enterprise or development
```
## 2단계: Fastfile 설정
다음 경로로 `Fastfile`을 생성하거나 업데이트합니다.
CodeBuild에서는 앱을 빌드하고 서명할 때마다 Fastlane Match를 실행해야 합니다. 이를 수행하는 가장 쉬운 방법은 앱을 빌드하는 경로에 `match` 작업을 추가하는 것입니다.
```
default_platform(:ios)
platform :ios do
before_all do
setup_ci
end
desc "Build and sign the app"
lane :build do
match(type: "appstore", readonly: true)
gym(
scheme: "YourScheme",
export_method: "app-store"
)
end
end
```
**참고**
일치 작업이 올바르게 작동하려면 `Fastfile`의 `before_all `섹션에 `setup_ci`를 추가해야 합니다. 이렇게 하면 적절한 권한이 있는 임시 Fastlane 키체인이 사용됩니다. 이를 사용하지 않으면 빌드 실패 또는 일관되지 않은 결과가 표시될 수 있습니다.
## 3단계: `fastlane match` 명령을 실행하여 각 인증서 및 프로필 생성
지정된 유형(예: 개발, 앱 스토어, 임시, 엔터프라이즈)에 대한 fastlane match 명령은 원격 스토어에서 사용할 수 없는 경우 인증서와 프로필을 생성합니다. 인증서와 프로필은 fastlane에서 S3에 저장합니다.
```
bundle exec fastlane match appstore
```
명령 실행은 대화식으로 이루어지며 fastlane은 인증서 복호화를 위한 암호 설정을 요청합니다.
## 4단계: 프로젝트에 대한 애플리케이션 파일 생성
프로젝트에 적합한 애플리케이션 파일을 생성하거나 추가합니다.
****
1. 프로젝트 빌드 요구 사항에 따라 [Gymfile](http://docs.fastlane.tools/actions/gym/#gymfile), [Appfile](http://docs.fastlane.tools/advanced/Appfile/), [Snapfile](http://docs.fastlane.tools/actions/snapshot/#snapfile), [Deliverfile](http://docs.fastlane.tools/actions/deliver/#editing-the-deliverfile)을 생성하거나 추가합니다.
1. 원격 리포지토리에 변경 사항을 커밋합니다.
## 5단계: Secrets Manager에서 환경 변수 생성
fastlane 세션 쿠키 및 일치하는 암호를 저장하기 위한 보안 암호 2개를 생성합니다. Secrets Manager에서 보안 암호를 생성하는 방법에 대한 자세한 내용은 [AWS Secrets Manager 보안 암호 생성](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html)을 참조하세요.
****
1. 다음과 같이 fastlane 세션 쿠키에 액세스합니다.
1. 보안 암호 키 - `FASTLANE_SESSION`
1. 보안 암호 값 - 로컬 시스템에서 다음 명령을 실행하여 생성된 세션 쿠키입니다.
**참고**
이 값은 `~/.fastlane/spaceship/my_appleid_username/cookie` 로컬 파일에서 인증 후 사용할 수 있습니다.
```
fastlane spaceauth -u
```
1. Fastlane Match 암호 - Fastlane Match가 S3 버킷에 저장된 인증서와 프로필을 해독하도록 하려면 일치 설정 단계에서 구성한 암호화 암호를 CodeBuild 프로젝트의 환경 변수에 추가해야 합니다.
1. 보안 암호 키 - `MATCH_PASSWORD`
1. 보안 암호 값 - *<암호를 일치시켜 인증서 해독>* 3단계에서 인증서를 생성하는 동안 암호가 설정됩니다.
**참고**
Secrets Manager에서 위의 보안 암호를 생성할 때는 `/CodeBuild/` 접두사를 사용하여 보안 암호 이름을 지정해야 합니다.
## 6단계: 컴퓨팅 플릿 생성
프로젝트의 컴퓨팅 플릿을 생성합니다.
****
1. 콘솔에서 CodeBuild로 이동하여 새 컴퓨팅 플릿을 생성합니다.
1. 'macOS'를 운영 체제로 선택하고 적절한 컴퓨팅 유형과 이미지를 선택합니다.
## 7단계: CodeBuild에서 프로젝트 생성
CodeBuild에서 프로젝트를 생성합니다.
****
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.
1. 빌드 프로젝트를 생성합니다. 자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 및 [빌드 실행(콘솔)](run-build-console.md) 섹션을 참조하세요.
1. 소스 공급자(예: GitHub, CodeCommit)를 설정합니다. 이는 iOS 프로젝트 소스 리포지토리이며 인증서 리포지토리가 아닙니다.
1. **환경**에서 다음과 같이 합니다.
+ **예약 용량**을 선택합니다.
+ **플릿**에서 위에서 생성한 플릿을 선택합니다.
+ CodeBuild가 자동으로 생성할 서비스 역할의 이름을 입력합니다.
+ 아래 환경 변수를 제공합니다.
+ 이름: `MATCH_PASSWORD`, 값: **, 유형: Secrets Manager(MATCH\$1PASSWORD의 경우 5단계에서 생성된 보안 암호 ARN)
+ 이름: `FASTLANE_SESSION`, 값: **, 유형: Secrets Manager(FASTLANE\$1SESSION의 경우 5단계에서 생성된 보안 암호 ARN)
1. **Buildspec**에서 다음을 추가합니다.
```
version: 0.2
phases:
install:
commands:
- gem install bundler
- bundle install
build:
commands:
- echo "Building and signing the app..."
- bundle exec fastlane build
post_build:
commands:
- echo "Build completed on date"
artifacts:
files:
- '*/.ipa'
name: app-$(date +%Y-%m-%d)
```
## 8단계: IAM 역할 구성
프로젝트가 생성되면 CodeBuild 프로젝트의 서비스 역할에 인증서가 포함된 S3 버킷에 액세스할 수 있는 권한이 있는지 확인합니다. 다음 정책을 역할에 추가하세요.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:ListBucket"
],
"Resource": "arn:aws:s3:::your-s3-bucket-name"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::your-s3-bucket-name/*"
}
]
}
```
------
## 9단계: 빌드 실행
빌드를 실행합니다. CodeBuild에서 빌드 상태 및 로그를 검토할 수 있습니다.
작업이 완료되면 작업 로그를 볼 수 있습니다.
## 문제 해결
+ 인증서 가져오기에 문제가 발생하면 S3 액세스를 위해 IAM 권한이 올바르게 설정되었는지 확인합니다.
+ 인증서 복호화에 문제가 발생하면 MATCH\$1PASSWORD 환경 변수에서 올바른 암호를 설정해야 합니다.
+ 코드 서명 문제의 경우 Apple Developer 계정에 필요한 인증서 및 프로필이 있고 Xcode 프로젝트의 번들 식별자가 프로비저닝 프로필의 번들 식별자와 일치하는지 확인합니다.
## 보안 고려 사항
다음은 이 자습서의 보안 고려 사항입니다.
+ S3 버킷에 저장 데이터 암호화를 비롯한 적절한 보안 설정이 있는지 확인합니다. 특히 버킷에 퍼블릭 액세스 권한이 없는지 확인하고 액세스 권한이 필요한 CodeBuild 및 시스템으로만 액세스를 제한합니다.
+ 를 사용하여 MATCH\$1PASSWORD 및 FASTLANE\$1SESSION과 같은 민감한 정보를 AWS Secrets Manager 저장하는 것이 좋습니다.
이 샘플은 인증서 스토리지용 Amazon S3를 통해 CodeBuild에서 Fastlane을 사용하여 iOS 코드 서명을 위한 설정을 제공합니다. 특정 프로젝트 요구 사항 및 CodeBuild 환경에 따라 일부 단계를 조정해야 할 수 있습니다. 이 접근 방식은 AWS 서비스를 활용하여 AWS 에코시스템 내에서 보안 및 통합을 강화합니다.
# 자습서: 인증서 스토리지에 GitHub를 사용하여 CodeBuild에서 Fastlane을 사용한 Apple 코드 서명
[fastlane](https://docs.fastlane.tools/)은 iOS 및 Android 앱의 베타 배포 및 릴리스를 자동화하는 오픈 소스 자동화 도구로 널리 사용됩니다. 스크린샷 생성, 코드 서명 처리, 애플리케이션 릴리스와 같은 모든 지루한 작업을 처리합니다.
이 샘플은 GitHub를 인증서 및 프로비저닝 프로필의 스토리지로 사용하여 Mac 플릿에서 실행되는 CodeBuild 프로젝트에서 Fastlane을 사용하여 Apple 코드 서명을 설정하는 방법을 보여줍니다.
## 사전 조건
이 자습서를 완료하려면 먼저 다음과 같은 사전 조건을 설정해야 합니다.
+ 의 경우 AWS 계정
+ [Apple 개발자 계정](https://developer.apple.com/)
+ 인증서를 저장하기 위한 프라이빗 GitHub 리포지토리
+ 프로젝트에 설치된 fastlane - fastlane 설치 [가이드](https://docs.fastlane.tools/getting-started/ios/setup/)
## 1단계: 로컬 시스템에서 GitHub를 사용하여 Fastlane Match 설정
[Fastlane Match](https://docs.fastlane.tools/actions/match/)는 [Fastlane 도구](https://fastlane.tools/) 중 하나이며 로컬 개발 환경과 CodeBuild 모두에서 코드 서명을 위한 원활한 구성을 지원합니다. Fastlane Match는 모든 코드 서명 인증서와 프로비저닝 프로필을 Git 리포지토리/S3 버킷/Google 클라우드 스토리지에 저장하고, 필요한 경우 필요한 인증서와 프로필을 다운로드하여 설치합니다.
이 예제 구성에서는 스토리지용 Git 리포지토리를 설정하고 사용합니다.
****
1. 프로젝트에서 일치 항목 초기화:
```
fastlane match init
```
1. 메시지가 표시되면 GitHub를 스토리지 모드로 선택합니다.
1. GitHub를 사용하도록 `*Matchfile*`을 업데이트합니다.
```
git_url("https://github.com/your-username/your-certificate-repo.git")
storage_mode("git")
type("development") # The default type, can be: appstore, adhoc, enterprise or development
```
**참고**
fastlane이 성공적으로 인증하고 복제할 수 있도록 Git 리포지토리에 HTTPS URL을 입력해야 합니다. 그렇지 않으면 일치 항목을 사용하려고 할 때 인증 오류가 표시될 수 있습니다.
## 2단계: Fastfile 설정
다음 경로로 `Fastfile`을 생성하거나 업데이트합니다.
CodeBuild에서는 앱을 빌드하고 서명할 때마다 Fastlane Match를 실행해야 합니다. 이를 수행하는 가장 쉬운 방법은 앱을 빌드하는 경로에 `match` 작업을 추가하는 것입니다.
```
default_platform(:ios)
platform :ios do
before_all do
setup_ci
end
desc "Build and sign the app"
lane :build do
match(type: "appstore", readonly: true)
gym(
scheme: "YourScheme",
export_method: "app-store"
)
end
end
```
**참고**
일치 작업이 올바르게 작동하려면 `Fastfile`의 `before_all `섹션에 `setup_ci`를 추가해야 합니다. 이렇게 하면 적절한 권한이 있는 임시 Fastlane 키체인이 사용됩니다. 이를 사용하지 않으면 빌드 실패 또는 일관되지 않은 결과가 표시될 수 있습니다.
## 3단계: `fastlane match` 명령을 실행하여 각 인증서 및 프로필 생성
지정된 유형(예: 개발, 앱 스토어, 임시, 엔터프라이즈)에 대한 fastlane match 명령은 원격 스토어에서 사용할 수 없는 경우 인증서와 프로필을 생성합니다. 인증서와 프로필은 fastlane에서 GitHub에 저장합니다.
```
bundle exec fastlane match appstore
```
명령 실행은 대화식으로 이루어지며 fastlane은 인증서 복호화를 위한 암호 설정을 요청합니다.
## 4단계: 프로젝트에 대한 애플리케이션 파일 생성
프로젝트에 적합한 애플리케이션 파일을 생성하거나 추가합니다.
****
1. 프로젝트 빌드 요구 사항에 따라 [Gymfile](http://docs.fastlane.tools/actions/gym/#gymfile), [Appfile](http://docs.fastlane.tools/advanced/Appfile/), [Snapfile](http://docs.fastlane.tools/actions/snapshot/#snapfile), [Deliverfile](http://docs.fastlane.tools/actions/deliver/#editing-the-deliverfile)을 생성하거나 추가합니다.
1. 원격 리포지토리에 변경 사항을 커밋합니다.
## 5단계: Secrets Manager에서 환경 변수 생성
fastlane 세션 쿠키 및 일치하는 암호를 저장하기 위한 보안 암호 3개를 생성합니다. Secrets Manager에서 보안 암호를 생성하는 방법에 대한 자세한 내용은 [AWS Secrets Manager 보안 암호 생성](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html)을 참조하세요.
****
1. 다음과 같이 fastlane 세션 쿠키에 액세스합니다.
1. 보안 암호 키 - `FASTLANE_SESSION`
1. 보안 암호 값 - 로컬 시스템에서 다음 명령을 실행하여 생성된 세션 쿠키입니다.
**참고**
이 값은 `~/.fastlane/spaceship/my_appleid_username/cookie` 로컬 파일에서 인증 후 사용할 수 있습니다.
```
fastlane spaceauth -u
```
1. Fastlane Match 암호 - Fastlane Match가 Git 리포지토리에 저장된 인증서와 프로필을 해독하도록 하려면 일치 설정 단계에서 구성한 암호화 암호를 CodeBuild 프로젝트의 환경 변수에 추가해야 합니다.
1. 보안 암호 키 - `MATCH_PASSWORD`
1. 보안 암호 값 - `` 3단계에서 인증서를 생성하는 동안 암호가 설정됩니다.
1. Fastlane `MATCH_GIT_BASIC_AUTHORIZATION` - *일치*에 대한 기본 권한 부여를 설정합니다.
1. 보안 암호 키:
`MATCH_GIT_BASIC_AUTHORIZATION`
1. 보안 암호 값 - 값은 `username:password` 형식의 사용자 이름 및 개인 액세스 토큰(PAT)의 base64 인코딩 문자열이어야 합니다. 다음 명령을 사용하여 생성할 수 있습니다.
```
echo -n your_github_username:your_personal_access_token | base64
```
GitHub 콘솔의 **프로필 > 설정 > 개발자 설정 > 개인 액세스 토큰**에서 PAT를 생성할 수 있습니다. 자세한 내용은 [https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens) 가이드를 참조하세요.
**참고**
Secrets Manager에서 위의 보안 암호를 생성할 때는 `/CodeBuild/` 접두사를 사용하여 보안 암호 이름을 지정해야 합니다.
## 6단계: 컴퓨팅 플릿 생성
프로젝트의 컴퓨팅 플릿을 생성합니다.
****
1. 콘솔에서 CodeBuild로 이동하여 새 컴퓨팅 플릿을 생성합니다.
1. `macOS`를 운영 체제로 선택하고 적절한 컴퓨팅 유형과 이미지를 선택합니다.
## 7단계: CodeBuild에서 프로젝트 생성
CodeBuild에서 프로젝트를 생성합니다.
****
1. [https://console.aws.amazon.com/codesuite/codebuild/home](https://console.aws.amazon.com/codesuite/codebuild/home) AWS CodeBuild 콘솔을 엽니다.
1. 빌드 프로젝트를 생성합니다. 자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 및 [빌드 실행(콘솔)](run-build-console.md) 섹션을 참조하세요.
1. 소스 공급자(예: GitHub, CodeCommit)를 설정합니다. 이는 iOS 프로젝트 소스 리포지토리이며 인증서 리포지토리가 아닙니다.
1. **환경**에서 다음과 같이 합니다.
+ **예약 용량**을 선택합니다.
+ **플릿**에서 위에서 생성한 플릿을 선택합니다.
+ CodeBuild가 자동으로 생성할 서비스 역할의 이름을 입력합니다.
+ 아래 환경 변수를 제공합니다.
+ 이름: `MATCH_PASSWORD`, 값: **, 유형: Secrets Manager(MATCH\$1PASSWORD의 경우 5단계에서 생성된 보안 암호 ARN)
+ 이름: `FASTLANE_SESSION`, 값: **, 유형: Secrets Manager(FASTLANE\$1SESSION의 경우 5단계에서 생성된 보안 암호 ARN)
+ 이름: `MATCH_GIT_BASIC_AUTHORIZATION`, 값: **, 유형: Secrets Manager Secrets ARN(`MATCH_GIT_BASIC_AUTHORIZATION`의 경우 5단계에서 생성됨)
1. **Buildspec**에서 다음을 추가합니다.
```
version: 0.2
phases:
install:
commands:
- gem install bundler
- bundle install
build:
commands:
- echo "Building and signing the app..."
- bundle exec fastlane build
post_build:
commands:
- echo "Build completed on date"
artifacts:
files:
- '*/.ipa'
name: app-$(date +%Y-%m-%d)
```
## 8단계: 빌드 실행
빌드를 실행합니다. CodeBuild에서 빌드 상태 및 로그를 검토할 수 있습니다.
작업이 완료되면 작업 로그를 볼 수 있습니다.
## 문제 해결
+ GitHub 리포지토리에 액세스하는 데 문제가 발생하면 개인 액세스 토큰과 MATCH\$1GIT\$1BASIC\$1AUTHORIZATION 환경 변수를 다시 확인합니다.
+ 인증서 복호화에 문제가 발생하면 MATCH\$1PASSWORD 환경 변수에서 올바른 암호를 설정해야 합니다.
+ 코드 서명 문제의 경우 Apple Developer 계정에 필요한 인증서 및 프로필이 있고 Xcode 프로젝트의 번들 식별자가 프로비저닝 프로필의 번들 식별자와 일치하는지 확인합니다.
## 보안 고려 사항
다음은 이 자습서의 보안 고려 사항입니다.
+ 인증서용 GitHub 리포지토리를 비공개로 유지하고 액세스를 정기적으로 감사합니다.
+ 를 사용하여 MATCH\$1PASSWORD 및 FASTLANE\$1SESSION과 같은 민감한 정보를 AWS Secrets Manager 저장하는 것이 좋습니다.
이 샘플은 인증서 스토리지용 GitHub를 통해 CodeBuild에서 Fastlane을 사용하여 iOS 코드 서명을 위한 설정을 제공합니다. 특정 프로젝트 요구 사항 및 CodeBuild 환경에 따라 일부 단계를 조정해야 할 수 있습니다. 이 접근 방식은 AWS 서비스를 활용하여 AWS 에코시스템 내에서 보안 및 통합을 강화합니다.
# 의미 체계 버전 관리를 사용하여 빌드 시 아티팩트 이름 설정
이번 샘플에는 빌드 시 생성되는 아티팩트 이름을 지정하는 방법에 대한 buildspec 파일 예제가 포함되어 있습니다. buildspec 파일에서 지정하는 이름에 Shell 명령과 환경 변수를 포함시켜 고유성을 유지할 수 있습니다. 또한 buildspec 파일에서 지정하는 이름은 프로젝트 생성 시 콘솔에 입력하는 이름을 재정의합니다.
여러 차례 빌드하는 경우 buildspec 파일에서 지정한 아티팩트 이름을 사용하면 출력 아티팩트 파일 이름의 고유성을 유지할 수 있습니다. 예를 들어 빌드 시 날짜와 타임스탬프를 사용해 아티팩트 이름에 삽입할 수 있습니다.
콘솔에서 입력한 아티팩트 이름을 buildspec 파일의 이름으로 재정의하고 싶다면 다음과 같이 실행하십시오.
1. 아티팩트 이름을 buildspec 파일의 이름으로 재정의하도록 빌드 프로젝트를 설정합니다.
+ 콘솔을 사용하여 빌드 프로젝트를 생성하는 경우 **의미 체계 버전 관리 사용**을 선택합니다. 자세한 내용은 [빌드 프로젝트 만들기(콘솔)](create-project.md#create-project-console) 섹션을 참조하세요.
+ AWS CLI를 사용하는 경우에는 `overrideArtifactName`로 전달되는 JSON 형식의 파일에서 `create-project`을 true로 설정하십시오. 자세한 내용은 [빌드 프로젝트 생성(AWS CLI)](create-project.md#create-project-cli) 섹션을 참조하세요.
+ AWS CodeBuild API를 사용하는 경우에는 프로젝트가 생성 또는 업데이트되거나, 빌드가 시작될 때 `overrideArtifactName` 객체에서 `ProjectArtifacts` 플래그를 설정하십시오.
1. buildspec 파일에서 이름을 지정합니다. 아래 buildspec 파일 샘플을 참고하십시오.
아래 Linux 예제는 빌드가 생성된 날짜를 포함시켜 아티팩트 이름을 지정하는 방법을 보여 줍니다.
```
version: 0.2
phases:
build:
commands:
- rspec HelloWorld_spec.rb
artifacts:
files:
- '**/*'
name: myname-$(date +%Y-%m-%d)
```
아래 Linux 예제는 CodeBuild 환경 변수를 사용하여 아티팩트 이름을 지정하는 방법을 보여 줍니다. 자세한 내용은 [빌드 환경의 환경 변수](build-env-ref-env-vars.md) 섹션을 참조하세요.
```
version: 0.2
phases:
build:
commands:
- rspec HelloWorld_spec.rb
artifacts:
files:
- '**/*'
name: myname-$AWS_REGION
```
아래 Windows 예제는 빌드가 생성된 날짜와 시간을 포함시켜 아티팩트 이름을 지정하는 방법에 대한 설명입니다.
```
version: 0.2
env:
variables:
TEST_ENV_VARIABLE: myArtifactName
phases:
build:
commands:
- cd samples/helloworld
- dotnet restore
- dotnet run
artifacts:
files:
- '**/*'
name: $Env:TEST_ENV_VARIABLE-$(Get-Date -UFormat "%Y%m%d-%H%M%S")
```
아래 Windows 예제는 buildspec 파일에서 선언한 변수와 CodeBuild 환경 변수를 사용하여 아티팩트 이름을 지정하는 방법을 보여 줍니다. 자세한 내용은 [빌드 환경의 환경 변수](build-env-ref-env-vars.md) 섹션을 참조하세요.
```
version: 0.2
env:
variables:
TEST_ENV_VARIABLE: myArtifactName
phases:
build:
commands:
- cd samples/helloworld
- dotnet restore
- dotnet run
artifacts:
files:
- '**/*'
name: $Env:TEST_ENV_VARIABLE-$Env:AWS_REGION
```
자세한 내용은 [CodeBuild의 빌드 사양 참조](build-spec-ref.md) 섹션을 참조하세요.