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

# Beanstalk 클러스터 환경을 위한 컨테이너 이미지 빌드
<a name="beanstalk-cluster-app-versions"></a>

Beanstalk 클러스터 환경은 컨테이너 이미지에서 애플리케이션을 실행합니다. Beanstalk Standard와 마찬가지로 *애플리케이션 버전이* 환경에 배포됩니다. Beanstalk 클러스터 환경에서 애플리케이션 버전은 Elastic Beanstalk가 있는 그대로 실행하는 이미지 또는 Elastic Beanstalk가 이미지에 빌드하는 소스를 제공합니다. 이 주제에서는 Beanstalk 클러스터 환경과 관련된 사전 조건, 생성 경로, 처리 상태 및 삭제 동작을 모두 다룹니다. 배포, 태그 지정 및 버전 할당량은 일반 생성 및 삭제 절차와 마찬가지로 두 모드 모두에서 동일한 방식으로 작동합니다. [애플리케이션 버전 관리](applications-versions.md) 및 [애플리케이션 버전 태그 지정](applications-versions-tagging.md) 섹션을 참조하세요.

Beanstalk 클러스터 배포의 경우 두 멤버 중 정확히 하나를 `ImageConfiguration` 포함하는를 사용하여 애플리케이션 버전을 생성합니다.는 이미 빌드된 컨테이너 이미지를 `Source` 식별하고 Elastic Beanstalk가 소스 번들에서 이미지를 빌드하는 방법을 `Build` 지정합니다. Elastic Beanstalk는가 두 멤버를 모두 `ImageConfiguration` 제공하는 `CreateApplicationVersion` 요청이나 둘 다 제공하지 않는 요청, `ImageConfiguration.Source` 및를 모두 제공하는 요청`SourceBundle`, Beanstalk Standard용 AWS CodeBuild 애플리케이션 버전을 구성하는 `BuildConfiguration` 파라미터`ImageConfiguration`와 결합하는 요청을 거부합니다. 다음 섹션에서는 각 경로에 대해 설명합니다.

## 사전 조건
<a name="beanstalk-cluster-app-versions-prerequisites"></a>

이 주제의 예제에서는를 사용합니다 AWS CLI. 명령을 실행하기 전에 설치 및 구성합니다. 명령은 AWS CLI 구성에서 계정과 AWS 리전을 사용합니다. [시작하기 전 준비 사항](beanstalk-cluster-getting-started.md#beanstalk-cluster-getting-started-prerequisites)을(를) 참조하세요.

다음 리소스를 준비하고 액세스합니다.
+ 소스 빌드의 경우에 `CodeBuildServiceRole` 필요한 입니다`ImageConfiguration.Build`. Elastic Beanstalk 콘솔에서 로 생성하는 환경의 *이미지 빌드 역할*입니다`aws-elasticbeanstalk-eks-image-build-role`. 신뢰할 수 있는 서비스 및 정책과 역할 경계는 [사용자가 제공하는 역할](beanstalk-cluster-permissions.md#beanstalk-cluster-permissions-customer-roles) 및 섹션을 참조하세요[Beanstalk 클러스터에 대한 권한](beanstalk-cluster-permissions.md).
+ 의 경우 이미 레지스트리로 푸시된 `ImageConfiguration.Source`컨테이너 이미지입니다. 환경에서 사용하는 노드 역할은 이미지를 가져올 수 있어야 합니다. [사용자가 제공하는 역할](beanstalk-cluster-permissions.md#beanstalk-cluster-permissions-customer-roles)을(를) 참조하세요.
+ 소스 빌드의 경우 `SourceBundle`, 애플리케이션 소스가 포함된 Amazon S3 객체입니다. 에 설명된 대로 아카이브를 생성하고 계정의 Amazon S3 버킷에 [Elastic Beanstalk 애플리케이션 소스 번들 생성](applications-sourcebundle.md)업로드한 다음 버킷과 객체 키를 `S3Bucket` 및 로 전달합니다`S3Key`. 빌드를 시작하려면 `Process` `true`로 설정합니다. 그렇지 않으면 버전은 로 유지됩니다`UNPROCESSED`.

## 컨테이너 이미지 입력
<a name="beanstalk-cluster-app-versions-image"></a>

이미 빌드되어 레지스트리로 푸시된 컨테이너 이미지의 `Source` 멤버를 `ImageConfiguration`에 제공합니다. Elastic Beanstalk는 빌드 단계 없이 이미지를 실행합니다. `Source` 에는 이미지를 가리키는 단일 필드 `Uri`가 있습니다. 이미지는 Amazon Elastic Container Registry(Amazon ECR) 또는 인증되지 않은 풀을 허용하는 모든 레지스트리에 있을 수 있습니다. 프라이빗 이미지의 경우 Amazon ECR을 사용합니다. 환경의 노드 역할이 인증합니다. 제공된 이미지에서 생성된 애플리케이션 버전에는 빌드가 필요하지 않으므로 Elastic Beanstalk`UNPROCESSED`는 상태와 함께 이를 기록하고 Beanstalk 클러스터 환경에 배포할 준비가 되었습니다.

Elastic Beanstalk는 태그 이름을 지정하든 다이제스트 이름을 지정하든 관계없이 URI를 제공하는 그대로 기록합니다. Elastic Beanstalk가 빌드하는 이미지는 다이제스트에 의해 기록됩니다.

별도의 파이프라인이 이미지를 빌드하거나 이전 애플리케이션 버전에서 생성된 이미지가 배포될 때이 셰이프를 사용합니다. Elastic Beanstalk가 이미지를 빌드하도록 하려면 다음에 설명된 대로 소스 번들과 `Build` 멤버를 제공합니다.

## Elastic Beanstalk가 빌드할 소스 제공
<a name="beanstalk-cluster-app-versions-source"></a>

Elastic Beanstalk가 애플리케이션 소스에서 컨테이너 이미지를 빌드해야 하는 `SourceBundle` 경우를 제공합니다. 는 Amazon Simple Storage Service(Amazon S3)의 소스 아카이브를 `S3Bucket` 및 라는 두 개의 필드로 `SourceBundle` 식별합니다`S3Key`. 소스 번들에는 Elastic Beanstalk`ImageConfiguration`가 소스를 이미지로 변환하는 방법을 지정하는 `Build` 멤버가 있는 도 필요합니다. `CreateApplicationVersion` 요청`true`에서를 `Process` 로 설정하여 빌드를 시작합니다. 에서는를 AWS CLI사용합니다`--process`. 이 설정을 생략하면 소스 기반 애플리케이션 버전이 그대로 유지`UNPROCESSED`되고 빌드가 시작되지 않습니다. 처리가 시작되면 Elastic Beanstalk는 이미지를 빌드하여 계정의 Amazon Elastic Container Registry로 푸시합니다. Docker 및 buildpack 빌드 유형과 해당 설정은 섹션을 참조하세요[빌드 구성](#beanstalk-cluster-app-versions-buildconfig).

**참고**  
macOS에서 소스 디렉터리 `zip -X -r ../my-app.zip .` 내에서를 사용하여 소스 아카이브를 생성합니다. Finder의 **Compress** 명령은 `__MACOSX` 메타데이터 항목을 추가하며, buildpack 빌드는를 사용하여 해당 항목 중 하나에 실패하여 생성하지 않은 파일의 `zip: not a valid zip file`이름을 지정할 수 있습니다.

빌드가 실행되는 동안 애플리케이션 버전은 상태를 보고합니다`BUILDING`. 이미지가 빌드되고 푸시되면 로 이동하고 빌드`PROCESSED`가 성공하지 않으면 `FAILED` 로 이동합니다.

## 빌드 구성
<a name="beanstalk-cluster-app-versions-buildconfig"></a>

의 `Build` 멤버는 소스 번들과 `ImageConfiguration` 함께 제공되며 Elastic Beanstalk가 이미지를 빌드하는 방법을 제어합니다. 다음에 설명된 빌드 유형과 함께 다음 필드를 포함합니다.
+ `CodeBuildServiceRole`: AWS CodeBuild가 계정에서 빌드를 실행하기 위해 수임하는 IAM 역할입니다. 이 필드는 소스 빌드에 필요합니다.
+ `ComputeType`, 빌드 컴퓨팅의 선택적 크기: `BUILD_GENERAL1_SMALL``BUILD_GENERAL1_MEDIUM`, 또는 `BUILD_GENERAL1_LARGE`. 생략하면 Elastic Beanstalk에서를 사용합니다`BUILD_GENERAL1_MEDIUM`.
+ `TimeoutInMinutes`: Elastic Beanstalk가 완료되지 않은 빌드를 중지하는 선택적 분 수입니다. 값은 \~일 수 있습니다`5``480`. 생략하면 Elastic Beanstalk는 `60` 분 단위를 사용합니다.

`Build` 멤버는 `Type` 필드를 통해 다음 두 가지 빌드 유형 중 하나를 선택합니다.
+ `docker`, Elastic Beanstalk는 소스의 Dockerfile에서 이미지를 빌드합니다. 를 Dockerfile의 경로`DockerfileLocation`로 설정합니다. Dockerfile을 생략하면 Elastic Beanstalk가 소스의 루트`Dockerfile`에서를 사용합니다.
+ `buildpack`, Elastic Beanstalk는 Cloud Native Buildpacks를 사용하여 이미지를 빌드합니다. 예를 들어 빌드에서 사용하는 빌더 이미지`Buildpack`로 설정합니다. `paketobuildpacks/builder-jammy-base`Elastic Beanstalk는 값을 빌드 축어적으로 전달합니다. buildpack 빌드에는 빌더가 필요합니다. Elastic Beanstalk는 사용자를 대신하여 이를 감지하지 않으며, 빌더 세트가 없는 buildpack 빌드는 실패합니다.

`Architecture` 필드는 이미지의 대상 CPU 아키텍처를 `amd64` 또는 로 설정합니다`arm64`. 생략하면 Elastic Beanstalk는를 빌드합니다`amd64`. 환경 `arch` 설정과 동일한 아키텍처를 구축합니다. 기본값은 입니다`amd64`. 한 아키텍처용으로 빌드된 이미지는 다른 아키텍처에서는 실행되지 않습니다. `arch`의 경우 [Beanstalk 클러스터 환경의 구성 옵션](command-options-general-eks.md) 섹션을 참조하세요.

## 처리 상태 검사 및 모니터링
<a name="beanstalk-cluster-app-versions-processing"></a>

Elastic Beanstalk가 이미지를 빌드하는 `BUILDING` 동안 소스 기반 버전이 보고합니다. 를 보고한 후에만 배포합니다`PROCESSED`. 상태가 이면 빌드가 성공하지 못하여 버전을 배포할 수 없음을 `FAILED` 의미합니다. 상태가 이면 `CreateApplicationVersion` 요청이를 생략한 경우와 같이 처리가 시작되지 않았음을 `UNPROCESSED` 의미합니다`Process`. 제공된 이미지에서 생성된 애플리케이션 버전도를 보고`UNPROCESSED`하지만 이미지에 빌드가 필요하지 않으므로 배포할 준비가 되었습니다.

애플리케이션 버전에 대한 설명은 이미지 상태를 두 개의 멤버인 `ImageSource` 및 로 보고합니다`ImageBuildConfiguration`. 소스 기반 버전의 경우 `ImageSource`는 빌드 설정을 `ImageBuildConfiguration` 에코하며 버전이를 보고하는 동안에는 존재하지 않습니다`BUILDING`. 빌드가 성공하면는 빌드가 생성하고 푸시한 이미지의 다이제스트 고정 URI를 `ImageSource` 반환합니다.

를 사용하여 소스 기반 버전의 처리 상태를 확인합니다`DescribeApplicationVersions`. `CreateApplicationVersion` 요청 직전에 기록된 타임스탬프`operation_start`로 설정합니다. 다음 이벤트 쿼리는 이를 사용하여 이벤트 범위를 빌드로 지정합니다.

```
$ aws elasticbeanstalk describe-application-versions \
    --application-name my-app \
    --version-labels v1-build \
    --query 'ApplicationVersions[0].Status' \
    --output text
```

버전이 터미널 상태에 도달할 때까지이 명령을 반복합니다.는 빌드가 계속 실행 중임을 `BUILDING` 의미합니다. 를 보고한 후에만 버전을 배포합니다. `FAILED` 또는 `PROCESSED`상태는 버전을 배포할 수 없음을 `UNPROCESSED` 의미합니다.

소스 기반 버전의 경우 `PROCESSED` 상태 및 이미지 빌드 완료 이벤트는 Elastic Beanstalk가 이미지를 빌드하고 기록했음을 확인합니다. 특정 버전의 이벤트를 검색하여 터미널 장애를 아직 실행 중인 빌드와 구분합니다.

```
$ aws elasticbeanstalk describe-events \
    --application-name my-app \
    --version-label v1-build \
    --start-time "$operation_start" \
    --max-items 20
```

버전이에 도달하면 `--severity ERROR`를 `FAILED`추가하여 실패 이벤트를 검색합니다. 이벤트는 소스 다운로드, 역할 가정, Amazon ECR 인증, 이미지 빌드 또는 푸시 실패와 같은 실패를 구분합니다.

```
$ aws elasticbeanstalk describe-events \
    --application-name my-app \
    --version-label v1-build \
    --severity ERROR \
    --start-time "$operation_start" \
    --max-items 20
```

이벤트는 실패한 단계를 식별합니다. 빌드 자체가 실패한 이유를 확인하려면 소스 기반 버전이 보고하는 `BuildArn`를 사용합니다.이는 빌드를 실행한 AWS CodeBuild 실행을 식별합니다. 다음 명령으로 전달하여 빌드의 상태와 로그 위치를 가져옵니다.

```
$ aws codebuild batch-get-builds \
    --ids {{build-arn}} \
    --query 'builds[0].{status:buildStatus,logGroup:logs.groupName,logStream:logs.streamName}'
```

응답에는 Amazon CloudWatch 콘솔에서 빌드의 로그 스트림을 여`logs.deepLink`는 도 포함됩니다.

이벤트로 식별되는 소스 위치, 빌드 구성 또는 역할 구성을 수정합니다. 새 레이블을 사용하여 새 애플리케이션 버전을 생성하고를 로 `Process` 설정한 다음 `true`로 폴링합니다`PROCESSED`. 에 버전을 배포하지 마십시오`FAILED`. 처리 성공은 애플리케이션 버전에서 이미지를 사용할 수 있다는 것만 증명하며 환경 배포는 확인하지 않습니다.

## 샘플 애플리케이션
<a name="beanstalk-cluster-app-versions-sample"></a>

Beanstalk 클러스터 환경을 생성할 때 애플리케이션 버전은 선택 사항입니다. `CreateEnvironment`가 버전 레이블 없이(또는 빈 레이블로) 호출되면 Elastic Beanstalk는 샘플 애플리케이션을 배포하여 실행 중인 환경을 제공합니다. Elastic Beanstalk는 사전 빌드된 컨테이너 이미지로 샘플을 백업하므로 배포 시 빌드 단계가 필요하지 않습니다. 샘플 애플리케이션은 고객 애플리케이션으로 선택하거나 구성할 수 없습니다. 버전 레이블이 지정되지 않은 경우 Elastic Beanstalk가 배포합니다. 애플리케이션을 배포하려면이 주제에 설명된 대로 애플리케이션 버전을 생성하고 버전 레이블을에 전달합니다`CreateEnvironment`. 환경 생성은 섹션을 참조하세요[Beanstalk 클러스터 시작하기](beanstalk-cluster-getting-started.md).

## 예제
<a name="beanstalk-cluster-app-versions-example"></a>

다음 `CreateApplicationVersion` 요청은 기존 컨테이너 이미지를 제공합니다. Elastic Beanstalk는 빌드 없이 이미지를 있는 그대로 실행합니다.

```
aws elasticbeanstalk create-application-version \
  --application-name my-app \
  --version-label v1-image \
  --image-configuration Source={Uri=111122223333.dkr.ecr.us-east-1.amazonaws.com/my-app:v1}
```

대신 다음 요청은 Amazon S3의 소스 번들과 `arm64` 아키텍처용 Dockerfile에서 이미지를 빌드하는 빌드 구성을 제공합니다. 이 이미지를 실행하려면 환경의 `arch` 옵션`arm64`도 로 설정합니다.

```
operation_start=$(date -u +%Y-%m-%dT%H:%M:%SZ)
aws elasticbeanstalk create-application-version \
  --application-name my-app \
  --version-label v1-build \
  --process \
  --source-bundle S3Bucket=my-source-bucket,S3Key=my-app/v1.zip \
  --image-configuration '{
    "Build": {
      "Type": "docker",
      "DockerfileLocation": "Dockerfile",
      "Architecture": "arm64",
      "CodeBuildServiceRole": "arn:aws:iam::111122223333:role/my-build-role",
      "ComputeType": "BUILD_GENERAL1_SMALL",
      "TimeoutInMinutes": 30
    }
  }'
```

다음 요청은 Dockerfile 대신 Cloud Native Buildpacks를 사용하여 이미지를 빌드합니다. 소스에는 Dockerfile이 필요하지 않으며, 빌더는 이미지 어셈블 방식을 결정합니다. 요청은를 생략`Architecture`하므로 Elastic Beanstalk는를 빌드합니다`amd64`.

```
operation_start=$(date -u +%Y-%m-%dT%H:%M:%SZ)
aws elasticbeanstalk create-application-version \
  --application-name my-app \
  --version-label v1-buildpack \
  --process \
  --source-bundle S3Bucket=my-source-bucket,S3Key=my-app/v1.zip \
  --image-configuration '{
    "Build": {
      "Type": "buildpack",
      "Buildpack": "paketobuildpacks/builder-jammy-base",
      "CodeBuildServiceRole": "arn:aws:iam::111122223333:role/my-build-role"
    }
  }'
```

소스 번들 빌드가에 도달하면 Beanstalk Standard 애플리케이션 버전과 `UpdateEnvironment`마찬가지로 버전 레이블을 `CreateEnvironment` 또는에 전달하여 이러한 버전을 Beanstalk 클러스터 환경에 `PROCESSED`배포합니다. 이를 실행하는 환경을 구성하려면 섹션을 참조하세요[Elastic Beanstalk 환경 구성](customize-containers.md).

## 애플리케이션 버전 삭제 및 복구
<a name="beanstalk-cluster-app-versions-delete"></a>

애플리케이션 버전 수명 주기 정책은 Beanstalk 클러스터 애플리케이션 버전을 삭제하지 않습니다. `DeleteApplicationVersion`를 사용하여 애플리케이션 버전 레코드를 제거합니다. Elastic Beanstalk는 버전이 인 동안 요청을 거부합니다. 삭제하기 전에 터미널 처리 상태를 `BUILDING`기다립니다.

Beanstalk 클러스터 애플리케이션 버전의 경우 `DeleteSourceBundle` 옵션은 Amazon S3에서 소스 번들을 삭제하지 않습니다. 소스-객체 보존은 별도로 관리됩니다.

`DeleteApplicationVersion`는 Elastic Beanstalk 애플리케이션 버전 레코드를 제거합니다. 를 통해 제공된 이미지`ImageConfiguration.Source`, 소스 빌드에서 생성된 이미지 또는 이미지가 포함된 Amazon ECR 리포지토리는 삭제되지 않습니다. 제공한 이미지의 보존을 관리합니다. Elastic Beanstalk는 소스 빌드용 Amazon ECR 리포지토리를 생성할 때 해당 리포지토리에 수명 주기 정책을 적용합니다. 하나의 애플리케이션 버전을 삭제해도 즉각적인 이미지 또는 리포지토리 정리는 수행되지 않습니다.

`FAILED` 상태의 소스 기반 버전은 배포할 수 없습니다. 소스 또는 빌드 구성을 수정하고 새 버전 레이블`CreateApplicationVersion`을 사용하여를 호출하고를 로 `Process` 설정합니다`true`. 실패한 버전의 레이블을 재사용하려면 먼저를 떠난 후 버전 레코드를 삭제`BUILDING`한 다음 수정된 버전을 생성합니다.