Docker 환경 구성 - AWS Elastic Beanstalk
Docker 환경에서 소프트웨어 구성컨테이너의 환경 변수 참조환경 변수에 보간 기능 사용 (Docker Compose)향상된 상태 보고를 위한 로그 생성(Docker Compose)Docker 컨테이너 사용자 지정 로깅(Docker Compose)Docker 이미지Docker 환경을 위한 관리형 업데이트 구성Docker 구성 네임스페이스Amazon Linux AMI(이전 Amazon Linux 2)에서 Docker 구성

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

Docker 환경 구성

Elastic Beanstalk Docker 환경의 동작을 구성하는 방법에는 여러 가지가 있습니다.

참고

Elastic Beanstalk 환경에서 Amazon Linux AMI Docker 플랫폼 버전(이전 Amazon Linux 2)을 사용하는 경우 Amazon Linux AMI(이전 Amazon Linux 2)에서 Docker 구성의 추가 정보를 읽어 보십시오.

Docker 환경에서 소프트웨어 구성

Elastic Beanstalk 콘솔을 사용하여 환경의 인스턴스에서 실행되는 소프트웨어를 구성할 수 있습니다.

Elastic Beanstalk 콘솔에서 Docker 환경을 구성하려면

  1. Elastic Beanstalk 콘솔을 연 다음 리전(Regions) 목록에서 해당 AWS 리전을 선택합니다.

  2. 탐색 창에서 환경을 선택한 다음 목록에서 환경 이름을 선택합니다.

    참고

    여러개의 환경을 보유한 경우 검색 창을 통해 환경 목록을 필터링합니다.

  3. 탐색 창에서 구성을 선택합니다.

  4. 업데이트, 모니터링 및 로깅 구성 범주에서 편집을 선택합니다.

  5. 필요한 구성을 변경합니다.

  6. 변경 사항을 저장하려면 페이지 하단에서 적용을 선택합니다.

모든 환경에서 소프트웨어 설정을 구성하는 방법에 대한 자세한 내용은 환경 속성 및 기타 소프트웨어 설정 단원을 참조하십시오. 다음 섹션에서는 Docker 관련 정보를 다룹니다.

컨테이너 옵션

컨테이너 옵션 섹션에는 플랫폼별 옵션이 있습니다. Docker 환경에서는 환경에 NGINX 프록시 서버를 포함할지 여부를 선택할 수 있습니다.

Docker Compose를 사용하는 환경

Docker Compose를 사용하여 Docker 환경을 관리하는 경우 Elastic Beanstalk은 프록시 서버를 컨테이너로 실행한다고 가정합니다. 따라서 프록시 서버 설정의 기본값은 없음이며 Elastic Beanstalk는 NGINX 구성을 제공하지 않습니다.

참고

NGINX를 프록시 서버로 선택하더라도 Docker Compose를 사용하는 환경에서는 이 설정이 무시됩니다. 프록시 서버 설정의 기본값은 없음입니다.

Docker Compose를 사용하는 Amazon Linux 2 플랫폼의 Docker에 대해 NGINX 웹 서버 프록시가 비활성화되어 있으므로 확장 상태 보고를 위한 로그 생성 지침을 따라야 합니다. 자세한 내용은 향상된 상태 보고를 위한 로그 생성(Docker Compose) 섹션을 참조하세요.

환경 속성 및 환경 변수

환경 속성 섹션에서는 애플리케이션을 실행하는 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스의 환경 속성 설정을 지정할 수 있습니다. 환경 속성은 카-값 페어로 애플리케이션에 전달됩니다. Docker 환경에서 Elastic Beanstalk는 환경 속성을 컨테이너에 환경 변수로 전달합니다.

컨테이너에서 실행되는 애플리케이션 코드는 환경 변수를 이름으로 참조하여 해당 값을 읽을 수 있습니다. 이러한 환경 변수를 읽는 소스 코드는 프로그래밍 학습에 따라 다릅니다. 각 플랫폼 항목에서 Elastic Beanstalk 관리형 플랫폼이 지원하는 프로그래밍 언어로 환경 변수 값을 읽는 방법에 대한 지침을 확인할 수 있습니다. 이러한 항목에 대한 링크 목록은 환경 속성 및 기타 소프트웨어 설정 단원을 참조하십시오.

Docker Compose를 사용하는 환경

Docker Compose를 사용하여 Docker 환경을 관리하는 경우 컨테이너의 환경 변수를 검색하려면 몇 가지 추가 구성을 해야 합니다. 컨테이너에서 실행 중인 실행 파일이 이러한 환경 변수에 액세스하려면 docker-compose.yml에서 해당 변수를 참조해야 합니다. 자세한 정보는 컨테이너의 환경 변수 참조을(를) 참조하세요.

컨테이너의 환경 변수 참조

Amazon Linux 2 Docker 플랫폼에서 Docker Compose 도구를 사용하는 경우 Elastic Beanstalk는 애플리케이션 프로젝트의 루트 디렉터리에 .env라는 Docker Compose 환경 파일을 생성합니다. 이 파일에는 Elastic Beanstalk에 대해 구성한 환경 변수가 저장됩니다.

참고

애플리케이션 번들에 .env 파일을 포함시키면 Elastic Beanstalk에서 .env 파일을 생성하지 않습니다.

컨테이너가 Elastic Beanstalk에서 정의한 환경 변수를 참조하려면 이러한 구성 방법 중 하나 또는 둘 모두 따라야 합니다.

  • Elastic Beanstalk에서 생성한 .env 파일을 env_file 파일의 docker-compose.yml 구성 옵션에 추가합니다.

  • docker-compose.yml 파일에서 환경 변수를 직접 정의합니다.

다음 파일은 예제를 제공합니다. 샘플 docker-compose.yml 파일은 두 가지 접근 방식을 모두 보여줍니다.

  • 환경 속성 DEBUG_LEVEL=1 및 LOG_LEVEL=error를 정의하면 Elastic Beanstalk에 다음 .env 파일이 생성됩니다.

    DEBUG_LEVEL=1
LOG_LEVEL=error

  • 이 docker-compose.yml 파일에서 env_file 구성 옵션은 .env 파일을 가리키며 DEBUG=1 파일에서 직접 docker-compose.yml 환경 변수를 정의합니다.

    services:
  web:
    build: .
    environment:
      - DEBUG=1
    env_file:
      - .env
주의

  • 두 파일 모두에서 동일한 환경 변수를 설정하면 docker-compose.yml 파일에 정의된 변수가 .env 파일에 정의된 변수보다 우선순위가 높습니다.

  • 공백이 문자열에 추가되지 않도록 등호(=)와 변수에 할당된 값 사이에 공백을 두지 않도록 주의하십시오.

Docker Compose의 환경 변수에 대한 자세한 내용은 Compose의 환경 변수를 참조하십시오.

환경 변수에 보간 기능 사용 (Docker Compose)

2023년 7월 28일 플랫폼 릴리스부터 Docker Amazon Linux 2플랫폼 브랜치는 Docker Compose 보간 기능을 제공합니다. 이 기능을 사용하면 Compose 파일의 값을 변수로 설정하여 런타임에 보간할 수 있습니다. 이 기능에 대한 자세한 내용은 Docker 설명서 웹사이트의 보간(Interpolation)을 참조하십시오.

중요

사용자 애플리케이션에 이 기능을 사용하려면 플랫폼 후크를 사용하는 방식을 구현해야 합니다.

이는 플랫폼 엔진에 구현된 완화 조치로 인해 필요한 것입니다. 고객이 새로운 보간 기능에 대해 잘 모르거나 기존 애플리케이션이 $ 문자가 포함된 환경 변수를 사용하는 경우, 이 완화 조치는 이전 버전과의 하위 호환성을 보장합니다. 업데이트된 플랫폼 엔진은 기본적으로 $ 문자를 $$ 문자로 대체하여 보간을 피합니다.

다음은 보간 기능을 사용할 수 있도록 설정할 수 있는 플랫폼 후크 스크립트의 예시입니다.

#!/bin/bash

: '
example data format in .env file
key1=value1
key2=value2
'
envfile="/var/app/staging/.env"
tempfile=$(mktemp)

while IFS= read -r line; do
  # split each env var string at '='
  split_str=(${line//=/ })
  if [ ${#split_str[@]} -eq 2 ]; then
    # replace '$$' with '$'
    replaced_str=${split_str[1]//\$\$/\$}
    # update the value of env var using ${replaced_str}
    line="${split_str[0]}=${replaced_str}"
  fi
  # append the updated env var to the tempfile
  echo "${line}" ≫"${tempfile}"
done < "${envfile}"
# replace the original .env file with the tempfile
mv "${tempfile}" "${envfile}"

플랫폼 후크는 다음 두 디렉토리에 모두 배치합니다.

  • .platform/confighooks/predeploy/

  • .platform/hooks/predeploy/

자세한 내용은 이 설명서 Linux 플랫폼 확장 항목의 플랫폼 후크을(를) 참조하십시오.

향상된 상태 보고를 위한 로그 생성(Docker Compose)

Elastic Beanstalk 상태 에이전트는 Elastic Beanstalk 환경에 대한 운영 체제 및 애플리케이션 상태 측정치를 제공합니다. 특정 형식으로 정보를 릴레이하는 웹 서버 로그 형식을 사용합니다.

Elastic Beanstalk에서는 웹 서버 프록시를 컨테이너로 실행한다고 가정합니다. 결과적으로 Docker Compose를 실행하는 Docker 환경에서 NGINX 웹 서버 프록시가 비활성화됩니다. Elastic Beanstalk 상태 에이전트가 사용하는 위치 및 형식에 로그를 기록하도록 서버를 구성해야 합니다. 이렇게 하면 웹 서버 프록시가 비활성화되어 있더라도 향상된 상태 보고 기능을 최대한 활용할 수 있습니다.

작업 방법에 대한 지침은 웹 서버 로그 구성 단원을 참조하십시오.

Docker 컨테이너 사용자 지정 로깅(Docker Compose)

문제를 효율적으로 해결하고 컨테이너화된 서비스를 모니터링하기 위해 환경 관리 콘솔 또는 EB CLI를 통해 Elastic Beanstalk에서 인스턴스 로그를 요청할 수 있습니다. 인스턴스 로그는 번들 로그와 테일 로그로 구성되며, 서로 통합되고 패키징되어 로그 및 최근 이벤트를 효율적이고 간단한 방법으로 볼 수 있습니다.

Elastic Beanstalk는 docker-compose.yml 파일에 정의된 각 서비스마다 하나씩 컨테이너 인스턴스에 로그 디렉터리를 /var/log/eb-docker/containers/<service name>에 생성합니다. Amazon Linux 2 Docker 플랫폼에서 Docker Compose 기능을 사용하는 경우 이러한 디렉터리를 로그가 작성된 컨테이너 파일 구조 내의 위치에 탑재할 수 있습니다. 로그 데이터를 기록하기 위해 로그 디렉터리를 탑재할 때 Elastic Beanstalk는 이러한 디렉터리에서 로그 데이터를 수집할 수 있습니다.

애플리케이션이 Docker Compose를 사용하지 않는 Docker 플랫폼에 있는 경우 Docker 컨테이너 사용자 지정 로깅(Docker Compose)에 명시된 표준 절차를 수행할 수 있습니다.

서비스의 로그 파일을 다시 검색 가능한 테일 파일 및 번들 로그로 구성하려면

  1. docker-compose.yml 파일을 편집합니다.

  2. 서비스에 대한 volumes 키 아래에 바인드 탑재를 다음과 같이 추가하십시오.

    "${EB_LOG_BASE_DIR}/<service name>:<log directory inside container>

    아래 샘플 docker-compose.yml 파일에서:

    • nginx-proxy는 <service name>입니다.

    • /var/log/nginx는 <log directory inside container>입니다.

    services:
  nginx-proxy:
    image: "nginx"
    volumes:
      - "${EB_LOG_BASE_DIR}/nginx-proxy:/var/log/nginx"

  • var/log/nginx 디렉터리에는 컨테이너의 nginx-proxy 서비스에 대한 로그가 포함되어 있으며 호스트의 /var/log/eb-docker/containers/nginx-proxy 디렉터리에 매핑됩니다.

  • 이 디렉터리의 모든 로그는 이제 Elastic Beanstalk의 요청 인스턴스 로그 기능을 통해 번들 및 테일 로그로 검색할 수 있습니다.

주의

  • ${EB_LOG_BASE_DIR}은 /var/log/eb-docker/containers 값으로 Elastic Beanstalk에서 설정된 환경 변수입니다.

  • Elastic Beanstalk는 /var/log/eb-docker/containers/<service name> 파일의 각 서비스에 대한 docker-compose.yml 디렉터리를 자동으로 생성합니다.

Docker 이미지

Elastic Beanstalk의 Docker 및 ECS 관리형 Docker 플랫폼 브랜치는 퍼블릭 또는 프라이빗 온라인 이미지 리포지토리에 저장된 Docker 이미지를 사용하도록 지원합니다.

Dockerrun.aws.json에 이미지를 이름으로 지정합니다. 다음 규칙에 유의하십시오.

  • Docker Hub 공식 리포지토리 안의 이미지는 단일 이름을 사용합니다(예: ubuntu 또는 mongo).

  • Docker Hub의 다른 리포지토리에 저장된 이미지는 조직 이름으로 한정됩니다(예: amazon/amazon-ecs-agent).

  • 다른 온라인 리포지토리의 이미지는 도메인 이름(예: quay.io/assemblyline/ubuntu 또는 account-id.dkr.ecr.us-east-2.amazonaws.com/ubuntu:trusty)으로도 제한됩니다.

Docker 플랫폼을 사용하는 환경의 경우에 한해 환경을 생성하는 동안 Dockerfile을 사용하여 자체 이미지를 빌드할 수도 있습니다. 세부 정보는 도커파일을 사용하여 사용자 지정 이미지 빌드 단원을 참조하십시오. 멀티컨테이너 Docker 플랫폼은 이 기능을 지원하지 않습니다.

Amazon Elastic Container Registry(Amazon ECR)를 사용하여 AWS에 사용자 지정 Docker 이미지를 저장할 수 있습니다. Amazon ECR에 Docker 이미지를 저장하면 Elastic Beanstalk는 환경의 인스턴스 프로파일을 사용하여 Amazon ECR 레지스트리에 자동으로 인증하므로, 인증 파일을 생성하고 이를 Amazon Simple Storage Service(Amazon S3)에 업로드할 필요가 없습니다.

그러나 환경의 인스턴스 프로파일에 권한을 추가하여 Amazon ECR 리포지토리의 이미지에 액세스할 권한이 있는 인스턴스를 제공해야 합니다. AmazonEC2ContainerRegistryReadOnly 관리형 정책을 인스턴스 프로파일에 연결하여 계정의 모든 Amazon ECR 리포지토리에 읽기 전용 액세스 권한을 제공하거나, 다음 템플릿을 사용하여 사용자 정의 정책을 만들어 단일 리포지토리에 액세스 권한을 부여할 수 있습니다.

{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Sid": "AllowEbAuth",
        "Effect": "Allow",
        "Action": [
          "ecr:GetAuthorizationToken"
        ],
        "Resource": [
          "*"
        ]
      },
      {
        "Sid": "AllowPull",
        "Effect": "Allow",
        "Resource": [
          "arn:aws:ecr:us-east-2:account-id:repository/repository-name"
        ],
        "Action": [
          "ecr:GetAuthorizationToken",
          "ecr:BatchCheckLayerAvailability",
          "ecr:GetDownloadUrlForLayer",
          "ecr:GetRepositoryPolicy",
          "ecr:DescribeRepositories",
          "ecr:ListImages",
          "ecr:BatchGetImage"
        ]
      }
    ]
  }

위 정책의 Amazon 리소스 이름(ARN)을 리포지토리의 ARN으로 바꿉니다.

Dockerrun.aws.json 파일에서 이미지를 URL로 참조합니다. Docker 플랫폼의 경우 URL은 Image 정의로 이동됩니다.

  "Image": {
      "Name": "account-id.dkr.ecr.us-east-2.amazonaws.com/repository-name:latest",
      "Update": "true"
    },

멀티컨테이너 Docker 플랫폼의 경우, 컨테이너 정의 객체에서 image 키를 사용합니다.

"containerDefinitions": [
        {
        "name": "my-image",
        "image": "account-id.dkr.ecr.us-east-2.amazonaws.com/repository-name:latest",

온라인 레지스트리에서 호스팅하는 프라이빗 리포지토리의 도커 이미지를 사용하려면 레지스트리를 사용하여 인증하는 데 필요한 정보가 들어 있는 인증 파일을 제공해야 합니다.

docker login 명령으로 인증 파일을 생성합니다. 도커 허브의 리포지토리의 경우, docker login을 실행합니다:

$ docker login

다른 레지스트리의 경우, 레지스트리 서버의 URL을 포함시킵니다.

$ docker login registry-server-url
참고

Elastic Beanstalk 환경에서 Amazon Linux AMI Docker 플랫폼 버전(이전 Amazon Linux 2)을 사용하는 경우 Amazon Linux AMI(이전 Amazon Linux 2)에서 Docker 구성의 추가 정보를 읽어 보십시오.

인증 파일의 .dockercfg 복사본을 안전한 Amazon S3 버킷에 업로드합니다. Amazon S3 버킷은 이를 사용 중인 환경과 동일한 AWS 리전에 호스팅되어야 합니다. Elastic Beanstalk는 다른 리전에 호스팅된 Amazon S3 버킷에서 파일을 다운로드할 수 없습니다. 인스턴스 프로파일의 IAM 역할에 s3:GetObject 작업에 대한 권한을 부여합니다. 자세한 내용은 Elastic Beanstalk 인스턴스 프로파일 관리 단원을 참조하십시오.

Authentication 파일의 authentication(v1) 또는 Dockerrun.aws.json(v2) 파라미터에 Amazon S3 버킷 정보를 포함시킵니다.

Docker 환경의 Dockerrun.aws.json 형식에 대한 자세한 내용은 도커 구성 단원을 참조하세요. 멀티컨테이너 환경은 ECS 관리형 도커 구성을(를) 참조하세요.

인증 파일에 대한 자세한 내용은 도커 허브에서의 이미지 저장과 도커 웹 사이트의 docker login을 참조하십시오.

Docker 환경을 위한 관리형 업데이트 구성

관리형 플랫폼 업데이트를 통해 일정에 따라 최신 플랫폼 버전으로 자동으로 업데이트하도록 환경을 구성할 수 있습니다.

Docker 환경의 경우, 새 플랫폼 버전에 신규 Docker 버전이 포함되어 있다면 여러 Docker 버전에서 자동 플랫폼 업데이트가 이루어지도록 할지 여부를 결정할 수 있습니다. Elastic Beanstalk는 Docker 플랫폼 버전 2.9.0 이상을 실행하는 환경에서 업데이트할 때 Docker 버전에서 관리형 플랫폼 업데이트를 지원합니다. 새 플랫폼 버전에 신규 Docker 버전이 포함되어 있는 경우 Elastic Beanstalk에서는 마이너 업데이트 버전 번호를 높입니다. 그러므로 여러 Docker 버전에 걸쳐 관리형 플랫폼 업데이트를 허용하려면 마이너 버전과 패치 버전 업데이트 모두에 대해 관리형 플랫폼 업데이트를 활성화하십시오. 여러 Docker 버전에 걸친 관리형 플랫폼 업데이트를 금지하려면 패치 버전 업데이트에 대해서만 관리형 플랫폼 업데이트를 활성화하십시오.

예를 들어, 다음 구성 파일에서는 매주 화요일 오전 9시(UTC)에 마이너 버전과 패치 버전 업데이트에 대해 관리형 플랫폼 업데이트를 활성화하여 여러 Docker 버전들에 걸쳐 관리형 업데이트가 진행되도록 허용합니다.

예 .ebextensions/managed-platform-update.config
option_settings:
  aws:elasticbeanstalk:managedactions:
    ManagedActionsEnabled: true
    PreferredStartTime: "Tue:09:00"
  aws:elasticbeanstalk:managedactions:platformupdate:
    UpdateLevel: minor

Docker 플랫폼 버전 2.9.0 이하를 실행하는 환경의 경우 Elastic Beanstalk에서는 새 플랫폼 버전에 신규 Docker 버전이 포함되어 있다면 관리형 플랫폼 업데이트를 절대 수행하지 않습니다.

Docker 구성 네임스페이스

구성 파일을 사용하여 구성 옵션을 설정하고 배포 중 다른 인스턴스 구성 작업을 수행할 수 있습니다. 구성 옵션은 Elastic Beanstalk 서비스 또는 사용 중인 플랫폼에서 정의할 수 있으며 네임스페이스로 구성됩니다.

참고

이 정보는 Docker Compose를 실행하지 않는 Docker 환경에만 적용됩니다. 이 옵션에는 Docker Compose를 실행하는 Docker 환경에서 다른 동작을 수행합니다. Docker Compose를 사용하는 프록시 서비스에 대한 자세한 내용은 컨테이너 옵션 단원을 참조하십시오.

Docker 플랫폼에서는 모든 Elastic Beanstalk 환경에 대해 지원되는 옵션 이외에도 다음 네임스페이스의 옵션을 지원합니다.

  • aws:elasticbeanstalk:environment:proxy – 사용자 환경에 맞는 프록시 서버를 선택합니다. Docker는 Nginx 실행을 지원하거나 프록시 서버를 지원하지 않습니다.

다음 예제 구성 파일은 프록시 서버를 실행하지 않도록 Docker 환경을 구성합니다.

예 .ebextensions/docker-settings.config
option_settings:
  aws:elasticbeanstalk:environment:proxy:
    ProxyServer: none

Amazon Linux AMI(이전 Amazon Linux 2)에서 Docker 구성

Elastic Beanstalk Docker 환경에서 Amazon Linux AMI 플랫폼 버전(이전 Amazon Linux 2)을 사용하는 경우 이 단원의 추가 정보를 읽어 보십시오.

이 정보는 프라이빗 리포지토리의 이미지를 사용 중인 사용자를 위한 것입니다. Docker 버전 1.7부터 docker login 명령은 인증 파일의 이름과 해당 파일의 형식을 변경했습니다. Amazon Linux AMI Docker 플랫폼 버전(이전 Amazon Linux 2)에는 이전 ~/.dockercfg 형식 구성 파일이 필요합니다.

Docker 버전 1.7 이상부터 docker login 명령은 ~/.docker/config.json에 다음 형식으로 인증 파일을 생성합니다.

{
    "auths":{
      "server":{
        "auth":"key"
      }
    }
  }

Docker 버전 1.6.2 이하에서 docker login 명령은 ~/.dockercfg에 다음 형식으로 인증 파일을 생성합니다.

{
    "server" :
    {
      "auth" : "auth_token",
      "email" : "email"
    }
  }

config.json 파일을 변환하려면 외부 auths 키를 제거하고, email 키를 추가하고, 이전 형식과 일치하도록 JSON 문서를 병합합니다.

Amazon Linux 2 Docker 플랫폼 버전에서 Elastic Beanstalk는 새로운 인증 파일 이름과 형식을 사용합니다. Amazon Linux 2 Docker 플랫폼 버전을 사용하는 경우, 어떠한 변환도 없이 docker login 명령이 생성하는 인증 파일을 사용할 수 있습니다.

Amazon Linux AMI에서의 성능 향상을 위해 Elastic Beanstalk는 Docker 환경의 Amazon EC2 인스턴스에 대해 2개의 Amazon EBS 스토리지 볼륨을 구성합니다. 모든 Elastic Beanstalk 환경에 대해 프로비저닝된 루트 볼륨 외에도, Docker 환경의 이미지 스토리지에 대해 xvdcz라는 12GB 볼륨이 프로비저닝됩니다.

Docker 이미지를 위한 더 많은 스토리지 공간이 필요하거나 IOPS를 높여야 하는 경우, aws:autoscaling:launchconfiguration 네임스페이스의 BlockDeviceMapping 구성 옵션을 사용하여 이미지 스토리지 볼륨을 사용자 지정할 수 있습니다.

예를 들어, 다음 구성 파일은 500의 프로비저닝된 IOPS로 스토리지 볼륨의 크기를 100GB로 늘립니다.

예 .ebextensions/blockdevice-xvdcz.config
option_settings:
  aws:autoscaling:launchconfiguration:
    BlockDeviceMappings: /dev/xvdcz=:100::io1:500

BlockDeviceMappings 옵션을 사용하여 애플리케이션의 볼륨을 추가로 구성하는 경우, 생성되었는지 확인할 수 있도록 xvdcz에 대한 매핑을 포함시켜야 합니다. 다음 예제에서는 기본 설정을 사용하는 이미지 스토리지 볼륨인 xvdcz와 추가로 24GB 애플리케이션 볼륨인 sdh라는 두 개의 볼륨을 구성합니다.

예 .ebextensions/blockdevice-sdh.config
option_settings:
  aws:autoscaling:launchconfiguration:
    BlockDeviceMappings: /dev/xvdcz=:12:true:gp2,/dev/sdh=:24
참고

이 네임스페이스의 설정을 변경하면 Elastic Beanstalk는 환경의 모든 인스턴스를 새 구성을 실행하는 인스턴스로 바꿉니다. 세부 정보는 구성 변경 단원을 참조하십시오.