기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # Elastic Beanstalk Linux 플랫폼 확장 이 주제에서는 자체 명령, 스크립트, 소프트웨어 및 구성을 사용하여 Linux 플랫폼을 확장하는 방법을 설명합니다. 기본 프록시 서버 및 구성을 변경하기 위해 플랫폼을 확장해야 할 수 있습니다. 또는 플랫폼이 애플리케이션을 빌드하거나 시작하는 방법을 사용자 지정해야 할 수 있습니다. **Topics** + [ # Buildfile 및 Procfile ](platforms-linux-extend.build-proc.md) + [ # 플랫폼 후크 ](platforms-linux-extend.hooks.md) + [ # 구성 파일 ](platforms-linux-extend.config-files.md) + [ # 역방향 프록시 구성 ](platforms-linux-extend.proxy.md) + [ # 확장자가 있는 애플리케이션 예제 ](platforms-linux-extend.example.md) # Buildfile 및 Procfile 일부 플랫폼에서는 애플리케이션을 빌드하거나 준비하는 방법을 사용자 지정하고 애플리케이션을 실행하는 프로세스를 지정할 수 있습니다. 각 개별 플랫폼 주제에서는 플랫폼에서 지원하는 경우 *Buildfile* 및/또는 *Procfile*에 대해 구체적으로 설명되어 있습니다. [Elastic Beanstalk 플랫폼](concepts-all-platforms.md)에서 특정 플랫폼을 찾습니다. 모든 지원 플랫폼에서 구문 및 의미는 동일하며 이 페이지의 설명과 같습니다. 애플리케이션을 해당 언어로 빌드하여 실행하기 위한 이러한 파일의 구체적인 사용법은 개별 플랫폼 항목에 나와 있습니다. ## Buildfile 애플리케이션에 대한 사용자 지정 빌드 및 구성 명령을 지정하려면 애플리케이션 소스의 루트 디렉터리에 `Buildfile`이라는 파일을 배치합니다. 파일 이름은 대/소문자를 구분합니다. `Buildfile`에 대해 다음 구문을 사용합니다. ``` : ``` `Buildfile`의 명령은 `^[A-Za-z0-9_-]+:\s*[^\s].*$` 정규식과 일치해야 합니다. Elastic Beanstalk는 `Buildfile`을 통해 실행되는 애플리케이션을 모니터링하지 않습니다. 단기간 실행되고 작업 완료 후 종료되는 명령에는 `Buildfile`을 사용합니다. 종료하면 안 되는 장기 실행 애플리케이션 프로세스의 경우 [Procfile](#platforms-linux-extend.proc)을 사용합니다. `Buildfile`의 모든 경로는 소스 번들의 루트에 상대적입니다. 다음 `Buildfile` 예제에서 `build.sh`는 소스 번들의 루트에 위치한 셸 스크립트입니다. **Example Buildfile** ``` make: ./build.sh ``` 사용자 지정 빌드 단계를 제공하려는 경우 가장 간단한 명령 이외의 작업에는 `Buildfile` 대신 `predeploy` 플랫폼 후크를 사용하는 것이 좋습니다. 플랫폼 후크는 다양한 스크립트와 더 향상된 오류 처리를 허용합니다. 플랫폼 후크는 다음 섹션에서 설명합니다. ## Procfile 애플리케이션을 시작하고 실행하기 위한 사용자 지정 명령을 지정하려면 애플리케이션 소스의 루트 디렉터리에 `Procfile`이라는 파일을 배치합니다. 파일 이름은 대/소문자를 구분합니다. `Procfile`에 대해 다음 구문을 사용합니다. 하나 이상의 명령을 지정할 수 있습니다. ``` : : ... ``` `Procfile`의 각 줄은 `^[A-Za-z0-9_-]+:\s*[^\s].*$` 정규식과 일치해야 합니다. 종료하면 안 되는 장기 실행 애플리케이션 프로세스의 경우 `Procfile`을 사용합니다. Elastic Beanstalk는 프로세스가 `Procfile`에서 계속 실행될 것으로 기대합니다. Elastic Beanstalk는 이러한 프로세스를 모니터링하고 종료되는 프로세스를 다시 시작합니다. 단기 실행 프로세스의 경우 [Buildfile](#platforms-linux-extend.build)을 사용합니다. `Procfile`의 모든 경로는 소스 번들의 루트에 상대적입니다. 다음 예제 `Procfile`은 세 가지 프로세스를 정의합니다. 예제의 첫 줄에 있는 `web`은 *기본 웹 애플리케이션*입니다. **Example Procfile** ``` web: bin/myserver cache: bin/mycache foo: bin/fooapp ``` Elastic Beanstalk는 포트 5000의 주 웹 애플리케이션에 요청을 전달하도록 프록시 서버를 구성하며 이 포트 번호를 구성할 수 있습니다. `Procfile`의 일반적인 용도는 이 포트 번호를 애플리케이션에 명령 인수로 전달하는 것입니다. 프록시 구성에 대한 자세한 내용은 [역방향 프록시 구성](platforms-linux-extend.proxy.md) 단원을 참조하세요. Elastic Beanstalk는 로그 파일의 `Procfile` 프로세스에서 표준 출력 및 오류 스트림을 캡처합니다. Elastic Beanstalk는 프로세스의 이름을 따서 로그 파일의 이름을 지정하고 `/var/log`에 저장합니다 예를 들어 앞의 예제에서 `web` 프로세스는 `web-1.log` 및 `web-1.error.log`에 대해 각각 `stdout` 및 `stderr`라는 로그를 생성합니다. # 플랫폼 후크 플랫폼 후크는 환경의 플랫폼을 확장하도록 특별히 설계되었습니다. 플랫폼 후크는 애플리케이션 소스 코드의 일부로 배포되는 사용자 지정 스크립트 및 기타 실행 파일로서 다양한 인스턴스 프로비저닝 단계에서 Elastic Beanstalk에 의해 실행됩니다. **참고** Amazon Linux AMI 플랫폼 버전(이전 Amazon Linux 2)에서는 플랫폼 후크가 지원되지 않습니다. ## 애플리케이션 배포 플랫폼 후크 *애플리케이션 배포*는 배포할 새 소스 번들을 제공하거나 모든 환경 인스턴스를 종료하고 재생성해야 하는 구성 변경을 수행할 때 발생합니다. 애플리케이션 배포 중에 실행되는 플랫폼 후크를 제공하려면 소스 번들의 `.platform/hooks` 디렉터리 아래에 있는 다음 하위 디렉터리 중 하나에 파일을 배치합니다. + `prebuild` - 파일은 Elastic Beanstalk 플랫폼 엔진이 애플리케이션 소스 번들을 다운로드하고 추출한 후 애플리케이션과 웹 서버를 설정하고 구성하기 전에 실행됩니다. `prebuild` 파일은 구성 파일의 [commands](customize-containers-ec2.md#linux-commands) 섹션에 있는 명령을 실행한 후 `Buildfile` 명령을 실행하기 전에 실행됩니다. + `predeploy` - 파일은 Elastic Beanstalk 플랫폼 엔진이 애플리케이션 및 웹 서버를 설정하고 구성한 후 최종 런타임 위치에 배포하기 전에 실행됩니다. `predeploy` 파일은 구성 파일의 [container\$1commands](customize-containers-ec2.md#linux-container-commands) 섹션에 있는 명령을 실행한 후 `Procfile` 명령을 실행하기 전에 실행됩니다. + `postdeploy` - 파일은 Elastic Beanstalk 플랫폼 엔진이 애플리케이션 및 프록시 서버를 배포한 후에 실행됩니다. 이것이 마지막 배포 워크플로우 단계입니다. ## 구성 배포 플랫폼 후크 *구성 배포*는 환경 인스턴스를 다시 만들지 않고 단지 업데이트하는 구성 변경을 수행할 때 발생합니다. 다음 옵션 업데이트 시 구성 업데이트가 이루어집니다. + [환경 속성 및 플랫폼별 설정](environments-cfg-softwaresettings.md) + [정적 파일](environment-cfg-staticfiles.md) + [AWS X-Ray 데몬](environment-configuration-debugging.md) + [로그 저장 및 스트리밍](environments-cfg-logging.md) + 애플리케이션 포트(자세한 내용은 [역방향 프록시 구성](platforms-linux-extend.proxy.md) 참조) 구성 배포 중에 실행되는 후크를 제공하려면 소스 번들의 `.platform/confighooks` 디렉터리 아래에 후크를 배치합니다. 애플리케이션 배포 후크의 경우와 동일한 세 개의 하위 디렉터리가 적용됩니다. ## 플랫폼 후크에 대한 자세한 정보 후크 파일은 이진 파일 또는 해당 인터프리터 경로를 포함하는 `#!` 줄(`#!/bin/bash`)로 시작하는 스크립트 파일일 수 있습니다. 모든 파일에 실행 권한이 있어야 합니다. 후크 파일에 대한 실행 권한을 설정하려면 `chmod +x`를 사용합니다. 2022년 4월 29일 이후에 릴리스된 모든 Amazon Linux 2023 및 Amazon Linux 2 기반 플랫폼 버전의 경우 Elastic Beanstalk가 모든 플랫폼 후크 스크립트에 실행 권한을 자동으로 부여합니다. 이 경우 실행 권한을 수동으로 부여할 필요가 없습니다. 이러한 플랫폼 버전 목록은 *AWS Elastic Beanstalk 릴리스 정보 가이드*의 [2022년 4월 29일](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2022-04-29-linux.html#release-2022-04-29-linux.platforms) Linux 릴리스 정보를 참조하세요. Elastic Beanstalk는 파일 이름의 사전 순서에 따라 각 디렉터리의 파일을 실행합니다. 모든 파일은 `root` 사용자로 실행됩니다. 플랫폼 후크의 현재 작업 디렉터리(cwd)는 애플리케이션의 루트 디렉터리입니다. `prebuild` 및 `predeploy` 파일의 경우 애플리케이션 스테이징 디렉터리이고 `postdeploy` 파일의 경우 현재 애플리케이션 디렉터리입니다. 파일 중 하나가 실패하면(0이 아닌 종료 코드로 종료) 배포가 중단되고 실패합니다. Windows *캐리지 리턴/줄 바꿈*(CRLF) 줄 바꿈 문자가 포함된 경우 플랫폼 후크 텍스트 스크립트가 실패할 수 있습니다. 파일이 Windows 호스트에 저장된 후 Linux 서버로 전송된 경우 파일에 Windows CRLF 줄 바꿈이 포함될 수 있습니다. [2022년 12월 29일](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2022-12-29-linux.html) 이후에 릴리스된 플랫폼의 경우 Elastic Beanstalk는 플랫폼 후크 텍스트 파일에서 Windows CRLF 문자를 Linux *줄 바꿈*(LF) 줄 바꿈 문자로 자동 변환합니다. 애플리케이션이 이 날짜 이전에 릴리스된 Amazon Linux 2 플랫폼에서 실행되는 경우 Windows CRLF 문자를 Linux LF 문자로 변환해야 합니다. 이 작업을 수행하는 한 가지 방법은 스크립트 파일을 만들어 Linux 호스트에 저장하는 것입니다. 이러한 문자를 변환하는 도구는 인터넷에서도 찾아볼 수 있습니다. 후크 파일은 애플리케이션 옵션에서 정의한 모든 환경 속성 및 시스템 환경 변수 `HOME`, `PATH` 및 `PORT`에 액세스할 수 있습니다. 환경 변수 및 기타 구성 옵션의 값을 플랫폼 후크 스크립트로 가져오려는 경우 환경 인스턴스에서 Elastic Beanstalk가 제공하는 `get-config` 유틸리티를 사용할 수 있습니다. 자세한 내용은 [Elastic Beanstalk 환경을 위한 플랫폼 스크립트 도구](custom-platforms-scripts.md) 단원을 참조하십시오. # 구성 파일 애플리케이션 소스 코드의 `.ebextensions` 디렉터리에 [구성 파일](ebextensions.md)을 추가하여 Elastic Beanstalk 환경의 다양한 측면을 구성할 수 있습니다. 구성 파일을 사용하면 환경 인스턴스에서 소프트웨어 및 기타 파일을 사용자 지정하고 인스턴스에서 초기화 명령을 실행할 수 있습니다. 자세한 내용은 [Linux 서버에서 소프트웨어 사용자 지정](customize-containers-ec2.md)을(를) 참조하세요. 구성 파일을 사용하여 [구성 옵션](command-options.md)을 설정할 수도 있습니다. 플랫폼 동작을 제어하는 옵션에는 여러 가지가 있으며 이러한 옵션 중 일부는 [플랫폼에 따라 다릅니다](command-options-specific.md). Amazon Linux 2 및 Amazon Linux 2023 기반 플램폼의 경우 *Buildfile*, *Procfile* 및 *플랫폼 후크*를 사용하여 인스턴스 프로비저닝 중에 환경 인스턴스에서 사용자 지정 코드를 구성하고 실행하는 것이 좋습니다. 이러한 메커니즘은 이 페이지의 이전 섹션에 설명되어 있습니다. `.ebextensions` 구성 파일에서 명령과 컨테이너 명령을 계속 사용할 수 있지만 작업하기가 쉽지 않습니다. 예를 들어, YAML 파일 내에 명령 스크립트를 작성하는 것은 구문 관점에서 어려울 수 있습니다. AWS CloudFormation 리소스에 대한 참조가 필요한 스크립트에는 `.ebextensions` 구성 파일을 사용해야 합니다. # 역방향 프록시 구성 모든 Amazon Linux 2 및 Amazon Linux 2023 플랫폼 버전은 nginx를 기본 역방향 프록시 서버로 사용합니다. Tomcat, Node.js, PHP 및 Python 플랫폼은 Apache HTTPD도 대안으로 지원합니다. 이러한 플랫폼에서 Apache를 선택하려면 `aws:elasticbeanstalk:environment:proxy` 네임스페이스의 `ProxyServer` 옵션을 `apache`로 설정합니다. 모든 플랫폼에서는 이 단원에 설명된 것처럼 일관된 방식으로 프록시 서버를 구성할 수 있습니다. **참고** Amazon Linux AMI 플랫폼 버전(이전 Amazon Linux 2)에서는 프록시 서버를 다르게 구성해야 할 수 있습니다. 레거시 세부 정보는 이 가이드의 [해당 플랫폼 항목](concepts-all-platforms.md)에서 확인할 수 있습니다. Elastic Beanstalk는 환경의 루트 URL(예: `http://my-env.elasticbeanstalk.com`)에 있는 기본 웹 애플리케이션으로 웹 트래픽을 전달하도록 환경 인스턴스에서 프록시 서버를 구성합니다. 기본적으로 Elastic Beanstalk는 포트 80에서 수신되는 요청을 포트 5000의 기본 웹 애플리케이션에 전달하도록 프록시를 구성합니다. 다음 예제와 같이 구성 파일에서 [aws:elasticbeanstalk:application:environment](command-options-general.md#command-options-general-elasticbeanstalkapplicationenvironment) 네임스페이스를 사용하는 `PORT` 환경 속성을 설정하여 이 포트 번호를 구성할 수 있습니다. ``` option_settings: - namespace: aws:elasticbeanstalk:application:environment option_name: PORT value: ``` 애플리케이션의 환경 변수 설정에 대한 자세한 내용은 [옵션 설정](ebextensions-optionsettings.md)을 참조하십시오. 애플리케이션은 프록시에 구성된 포트에서 수신 대기해야 합니다. `PORT` 환경 속성을 사용하여 기본 포트를 변경하면 코드에서 `PORT` 환경 변수의 값을 읽어 해당 포트에 액세스할 수 있습니다. 예를 들어 Go에서 `os.Getenv("PORT")`를 호출하거나 Java에서 `System.getenv("PORT")`를 호출합니다. 여러 애플리케이션 프로세스로 트래픽을 보내도록 프록시를 구성하는 경우 여러 환경 속성을 구성하고 프록시 구성 및 애플리케이션 코드 모두에서 해당 값을 사용할 수 있습니다. 또 다른 옵션은 포트 값을 `Procfile`의 명령 인수로 프로세스에 전달하는 것입니다. 자세한 내용은 [Buildfile 및 Procfile](platforms-linux-extend.build-proc.md)을 참조하세요. ## nginx 구성 Elastic Beanstalk는 nginx를 기본 역방향 프록시로 사용하여 애플리케이션을 Elastic Load Balancing 로드 밸런서에 매핑합니다. Elastic Beanstalk는 확장하거나 자체 구성으로 완전히 재정의할 수 있는 기본 nginx 구성을 제공합니다. **참고** nginx `.conf` 구성 파일을 추가하거나 편집할 때는 UTF-8로 인코딩해야 합니다. Elastic Beanstalk의 기본 nginx 구성을 확장하려면 애플리케이션 소스 번들의 `.platform/nginx/conf.d/`라는 폴더에 `.conf` 구성 파일을 추가합니다. Elastic Beanstalk nginx 구성에는 이 폴더의 `.conf` 파일이 자동으로 포함됩니다. ``` ~/workspace/my-app/ |-- .platform | `-- nginx | `-- conf.d | `-- myconf.conf `-- other source files ``` `.platform/nginx/conf.d/`에 있는 구성 파일은 nginx 구성의 `http` 블록에 포함됩니다. 전역적으로 적용되는 구성에는 이 위치를 사용합니다. 기본 nginx `server` 블록 구성을 확장하려면 애플리케이션 소스 번들의 `.platform/nginx/conf.d/elasticbeanstalk/`라는 폴더에 `.conf` 구성 파일을 추가합니다. Elastic Beanstalk의 nginx 구성은 이 폴더에 있는 `.conf` 파일들을 `server` 블록 내에 포함합니다. ``` ~/workspace/my-app/ |-- .platform | `-- nginx | `-- conf.d | `-- elasticbeanstalk | `-- server.conf `-- other source files ``` 이 위치를 사용하여 추가 위치 블록, 사용자 지정 오류 페이지 또는 서버 수준 지시문 등 서버별 구성을 추가합니다. 다음 예제에서는 사용자 지정 위치 블록을 추가합니다. **Example .platform/nginx/conf.d/elasticbeanstalk/server.conf** ``` location /test { return 200 "Hello World!"; add_header Content-Type text/plain; } ``` Elastic Beanstalk의 기본 nginx 구성을 완전히 재정의하려면 `.platform/nginx/nginx.conf`의 소스 번들에 구성을 포함시킵니다. ``` ~/workspace/my-app/ |-- .platform | `-- nginx | `-- nginx.conf `-- other source files ``` Elastic Beanstalk의 nginx 구성을 재정의하는 경우 `nginx.conf`에 다음 줄을 추가하여 [Elastic Beanstalk의 향상된 상태 보고 및 모니터링](health-enhanced.md), 자동 애플리케이션 매핑 및 정적 파일에 대한 Elastic Beanstalk 구성을 가져옵니다. ``` include conf.d/elasticbeanstalk/*.conf; ``` ## Apache HTTPD 설정 Tomcat, Node.js, PHP, Python 플랫폼에서는 nginx에 대한 대안으로 Apache HTTPD 프록시 서버를 선택할 수 있습니다. 이는 기본값이 아닙니다. 다음 예제는 Apache HTTPD를 사용하도록 Elastic Beanstalk를 구성합니다. **Example .ebextensions/httpd-proxy.config** ``` option_settings: aws:elasticbeanstalk:environment:proxy: ProxyServer: apache ``` 추가 구성 파일을 사용하여 Elastic Beanstalk 기본 Apache 구성을 확장할 수 있습니다. 또는 Elastic Beanstalk 기본 Apache 구성을 완전히 재정의할 수 있습니다. Elastic Beanstalk의 기본 Apache 구성을 확장하려면 애플리케이션 소스 번들의 `.conf`라는 폴더에 `.platform/httpd/conf.d` 구성 파일을 추가합니다. Elastic Beanstalk의 Apache 구성에는 이 폴더의 `.conf` 파일이 자동으로 포함됩니다. ``` ~/workspace/my-app/ |-- .ebextensions | -- httpd-proxy.config |-- .platform | -- httpd | -- conf.d | -- port5000.conf | -- ssl.conf -- index.jsp ``` 예를 들어, 다음 Apache 2.4 구성은 포트 5000에 리스너를 추가합니다. **Example .platform/httpd/conf.d/port5000.conf** ``` listen 5000 Require all granted ProxyPass / http://localhost:8080/ retry=0 ProxyPassReverse / http://localhost:8080/ ProxyPreserveHost on ErrorLog /var/log/httpd/elasticbeanstalk-error_log ``` Elastic Beanstalk의 기본 Apache 구성을 완전히 재정의하려면 `.platform/httpd/conf/httpd.conf`의 소스 번들에 구성을 포함시킵니다. ``` ~/workspace/my-app/ |-- .ebextensions | -- httpd-proxy.config |-- .platform | `-- httpd | `-- conf | `-- httpd.conf `-- index.jsp ``` Elastic Beanstalk의 Apache 구성을 재정의하는 경우 `httpd.conf`에 다음 줄을 추가하여 [Elastic Beanstalk의 향상된 상태 보고 및 모니터링](health-enhanced.md), 자동 애플리케이션 매핑 및 정적 파일에 대한 Elastic Beanstalk 구성을 가져옵니다. ``` IncludeOptional conf.d/elasticbeanstalk/*.conf ``` # 확장자가 있는 애플리케이션 예제 다음 예제에서는 Elastic Beanstalk Amazon Linux 2 및 Amazon Linux 2023 플랫폼이 지원하는 여러 확장 기능이 있는 애플리케이션 소스 번들(`Procfile`, `.ebextensions` 구성 파일, 사용자 지정 후크 및 프록시 구성 파일)을 보여줍니다. ``` ~/my-app/ |-- web.jar |-- Procfile |-- readme.md |-- .ebextensions/ | |-- options.config # Option settings | `-- cloudwatch.config # Other .ebextensions sections, for example files and container commands `-- .platform/ |-- nginx/ # Proxy configuration | |-- nginx.conf | `-- conf.d/ | |-- custom.conf | `-- elasticbeanstalk/ | `-- server.conf |-- hooks/ # Application deployment hooks | |-- prebuild/ | | |-- 01_set_secrets.sh | | `-- 12_update_permissions.sh | |-- predeploy/ | | `-- 01_some_service_stop.sh | `-- postdeploy/ | |-- 01_set_tmp_file_permissions.sh | |-- 50_run_something_after_app_deployment.sh | `-- 99_some_service_start.sh `-- confighooks/ # Configuration deployment hooks |-- prebuild/ | `-- 01_set_secrets.sh |-- predeploy/ | `-- 01_some_service_stop.sh `-- postdeploy/ |-- 01_run_something_after_config_deployment.sh `-- 99_some_service_start.sh ``` **참고** Amazon Linux AMI 플랫폼 버전(이전 Amazon Linux 2)에서는 이러한 확장 중 일부가 지원되지 않습니다.