Elastic Beanstalk Docker 환경 구성 - AWS Elastic Beanstalk

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

Elastic Beanstalk Docker 환경 구성

이 장에서는 ECS 관리형 Docker 플랫폼 브랜치를 포함하여 지원되는 모든 Docker 플랫폼 브랜치에 대한 추가 구성 정보를 설명합니다. 특정 플랫폼 브랜치 또는 플랫폼 브랜치 구성 요소가 섹션에서 식별되지 않는 한 지원되는 도커 및 ECS 관리형 도커 플랫폼을 실행하는 모든 환경에 적용됩니다.

참고

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

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

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

Elastic Beanstalk 콘솔에서 Docker 환경을 구성하려면
  1. Elastic Beanstalk 콘솔을 열고 리전 목록에서를 선택합니다 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(AmazonEC2) 인스턴스에서 환경 구성 설정을 지정할 수 있습니다. 환경 속성은 키-값 페어로 애플리케이션에 전달됩니다. 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=1LOG_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 Compose를 사용한 Docker 컨테이너 사용자 지정 로깅

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

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

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

서비스의 로그 파일을 다시 검색 가능한 테일 파일 및 번들 로그로 구성하려면
  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}는 Elastic Beanstalk에서 값이 로 설정한 환경 변수입니다/var/log/eb-docker/containers.

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

도커 이미지

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을 사용하여 자체 이미지를 빌드할 수도 있습니다. 세부 정보는 도커파일을 사용하여 사용자 지정 이미지 빌드 단원을 참조하십시오. ECS 관리형 Docker 플랫폼은이 기능을 지원하지 않습니다.

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

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

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

예를 들어 다음 구성 파일은 마이너 버전 업데이트와 패치 버전 업데이트 모두에 대해 UTC 매주 화요일 오전 9시에 관리형 플랫폼 업데이트를 활성화하므로 도커 버전 전체에서 관리형 업데이트를 허용합니다.

예 .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의 Docker 구성AMI(이전 Amazon Linux 2)

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에서 성능을 개선하기 위해 AMIElastic Beanstalk는 Docker 환경의 Amazon EC2 인스턴스에 대해 두 개의 Amazon EBS 스토리지 볼륨을 구성합니다. 모든 Elastic Beanstalk 환경에 대해 프로비저닝된 루트 볼륨 외에도, Docker 환경의 이미지 스토리지에 대해 xvdcz라는 12GB 볼륨이 프로비저닝됩니다.

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

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

예 .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는 환경의 모든 인스턴스를 새 구성을 실행하는 인스턴스로 바꿉니다. 세부 정보는 구성 변경 단원을 참조하십시오.