기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 애플리케이션 서버 계층 **중요** 이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요. **참고** 이들 계층은 Chef 11 및 이전 Linux 기반 스택에서만 사용할 수 있습니다. OpsWorks Stacks는 "애플리케이션"에 정적 웹 페이지가 포함된 여러 애플리케이션 서버를 지원합니다. 각 서버 유형에는 별도의 OpsWorks Stacks 계층이 있으며, 각 계층의 인스턴스에 애플리케이션 서버 및 관련 패키지를 설치하고 앱을 배포하는 등의 작업을 처리하는 내장 레시피가 있습니다. 예를 들어 Java 앱 서버 계층은 Apache, Tomcat, OpenJDK를 비롯한 여러 패키지를 설치하고 각 계층의 인스턴스에 Java 앱을 배포합니다. 애플리케이션 서버 계층을 사용하는 기본적 절차는 다음과 같습니다. 1. 사용 가능한 **앱 서버** 계층 유형 중 하나를 [생성](workinglayers-basics-create.md)합니다. 1. 계층에 [하나 이상의 인스턴스를 추가](workinginstances-add.md)합니다. 1. 앱을 생성해 인스턴스에 배포합니다. 자세한 내용은 [앱](workingapps.md) 섹션을 참조하세요. 1. (선택 사항) 계층에 여러 인스턴스가 있는 경우, 수신 트래픽을 인스턴스에 분산하는 로드 밸런서를 추가할 수 있습니다. 자세한 내용은 [HAProxy OpsWorks 스택 계층](layers-haproxy.md) 섹션을 참조하세요. **Topics** + [AWS Flow(Ruby) 계층](workinglayers-awsflow.md) + [Java 앱 서버 OpsWorks 스택 계층](layers-java.md) + [Node.js 앱 서버 OpsWorks 스택 계층](workinglayers-node.md) + [PHP 앱 서버 OpsWorks 스택 계층](workinglayers-php.md) + [Rails 앱 서버 OpsWorks 스택 계층](workinglayers-rails.md) + [정적 웹 서버 OpsWorks 스택 계층](workinglayers-static.md) # AWS Flow(Ruby) 계층 **중요** 이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요. **참고** 이 계층은 Linux 기반 스택에서만 사용할 수 있습니다. AWS Flow(Ruby) 계층은 [Amazon SWF](https://docs.aws.amazon.com/amazonswf/latest/developerguide/swf-welcome.html) 활동 및 워크플로 작업자를 호스팅하는 인스턴스에 대한 청사진을 제공하는 OpsWorks Stacks 계층입니다. 작업자는 Amazon SWF의 모든 이점을 제공하면서 분산 비동기 애플리케이션을 구현하는 프로세스를 단순화하는 프로그래밍 프레임워크인 [AWS Flow Framework for Ruby](https://docs.aws.amazon.com/amazonswf/latest/awsrbflowguide/welcome.html)를 사용하여 구현됩니다. 이 프레임워크는 비즈니스 프로세스, 미디어 인코딩, 장기 실행 작업, 백그라운드 프로세싱 등 다양한 시나리오를 처리하는 애플리케이션을 구현하는 데 이상적입니다. AWS Flow(Ruby) 계층에는 다음 구성 설정이 포함됩니다. **RubyGems 버전** 프레임워크의 Gem 버전. **Bundler 버전** [Bundler](http://bundler.io/) 버전. **EC2 인스턴스 프로파일** 계층의 인스턴스가 사용할 사용자 정의 Amazon EC2 인스턴스 프로파일. 이 프로파일은 계층의 인스턴스에서 실행되는 애플리케이션에게 Amazon SWF에 액세스할 수 있는 권한을 부여해야 합니다. 계정에 적절한 프로필이 없는 경우 **SWF 액세스 권한이 있는 새** 프로필을 선택하여 OpsWorks Stacks가 프로필을 업데이트하도록 하거나 [IAM 콘솔](https://console.aws.amazon.com/iam/)을 사용하여 직접 업데이트할 수 있습니다. 그러면 이후의 모든 AWS Flow 계층에 업데이트된 프로파일을 사용할 수 있습니다. 다음은 IAM 콘솔을 사용해 프로파일을 생성하는 방법에 대한 간략한 설명입니다. 자세한 내용은 [Identity and Access Management in Amazon Simple Workflow Service](https://docs.aws.amazon.com/amazonswf/latest/developerguide/swf-dev-iam.html)를 참조하세요. **AWS Flow(Ruby) 인스턴스용 프로파일 생성** 1. IAM 콘솔([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/))을 엽니다. 1. 탐색 창에서 **정책**을 선택하고 **정책 생성**을 선택하여 새 고객 관리형 정책을 생성합니다. 1. **서비스**에서 **SWF**를 선택합니다. 1. **활동**에서 **모든 SWF 활동(swf:\$1)**을 선택합니다. 1. **Amazon 리소스 이름(ARN)**에 작업자가 액세스할 수 있는 Amazon SWF 도메인을 지정하는 ARN을 입력합니다. 모든 도메인에 액세스하도록 하려면 **All resources**를 선택합니다. 1. **다음**을 선택합니다. 1. 정책을 식별하는 태그를 입력할 수도 있습니다. 1. **다음**을 선택합니다. 1. 모두 마쳤으면 **정책 생성**을 선택합니다. 1. 탐색 창에서 **역할**을 선택한 후 **역할 생성**을 선택합니다. 1. 역할 이름을 지정하고 **Next Step**을 클릭합니다. 역할이 생성된 이후에는 역할의 이름을 바꿀 수 없습니다. 1. **AWS 서비스**와 **EC2**를 차례대로 선택합니다. 1. **다음**을 선택합니다. 1. **권한 정책** 목록에서 이전에 생성한 정책을 선택합니다. 1. **다음**을 선택합니다. 1. 역할 이름을 입력하고 **역할 생성**을 선택합니다. 역할이 생성된 이후에는 역할의 이름을 바꿀 수 없습니다. 1. OpsWorks Stacks에서 AWS Flow(Ruby) 계층을 생성할 때이 프로파일을 지정합니다. # Java 앱 서버 OpsWorks 스택 계층 **중요** 이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요. **참고** 이 계층은 Linux 기반 스택에서만 사용할 수 있습니다. Java 앱 서버 계층은 Java 애플리케이션 서버 역할을 하는 인스턴스에 대한 블루프린트를 제공하는 OpsWorks Stacks 계층입니다. 이 계층은 [Apache Tomcat 7.0](http://tomcat.apache.org/) 및 [Open JDK 7](http://openjdk.java.net/)을 기반으로 합니다. OpsWorks Stacks는 Java 커넥터 라이브러리도 설치하므로 Java 앱이 JDBC `DataSource` 객체를 사용하여 백엔드 데이터 스토어에 연결할 수 있습니다. **설치**: Tomcat이 `/usr/share/tomcat7`에 설치됩니다. [**계층 추가**] 페이지는 다음 구성 옵션을 제공합니다. **Java VM 옵션** 이 설정을 사용하여 사용자 지정 Java VM 옵션을 지정할 수 있습니다. 기본 옵션은 없습니다. 예를 들어 공통 옵션 세트는 `-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC`입니다. **Java VM 옵션을** 사용하는 경우 유효한 옵션 세트를 전달해야 합니다. OpsWorks Stacks는 문자열을 검증하지 않습니다. 유효하지 않은 옵션을 전달하려고 하면 일반적으로 Tomcat 서버가 시작하지 못해 설정이 실패합니다. 이런 현상이 발생하는 경우, 인스턴스의 설정 Chef 로그에서 상세 정보를 검사할 수 있습니다. Chef 로그를 보고 해석하는 방법에 대한 자세한 정보는 [Chef 로그](troubleshoot-debug-log.md) 단원을 참조하세요. **사용자 지정 보안 그룹** 이 설정은 내장 OpsWorks Stacks 보안 그룹을 계층에 자동으로 연결하지 않도록 선택한 경우에 나타납니다. 계층에 어떤 보안 그룹을 연결할지 지정해야 합니다. 자세한 내용은 [새 스택 생성](workingstacks-creating.md) 섹션을 참조하세요. **Elastic Load Balancer** Elastic Load Balancing 로드 밸런서를 어떤 계층의 인스턴스에도 연결할 수 있습니다. 자세한 내용은 [Elastic Load Balancing 계층](layers-elb.md) 섹션을 참조하세요. 사용자 지정 JSON 또는 사용자 지정 속성 파일을 사용하여 다른 구성 설정을 지정할 수 있습니다. 자세한 내용은 [사용자 지정 구성](layers-java-config.md) 섹션을 참조하세요. **중요** Java 애플리케이션이 SSL을 사용하는 경우, 가능하다면 SSLv3를 비활성화하여 [CVE-2014-3566](http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566)에 설명된 취약성을 해결하는 것이 좋습니다. 자세한 내용은 [Apache 서버에서 SSLv3 비활성화](#layers-java-sslv3) 섹션을 참조하세요. **Topics** + [Apache 서버에서 SSLv3 비활성화](#layers-java-sslv3) + [사용자 지정 구성](layers-java-config.md) + [Java 앱 배포](layers-java-deploy.md) ## Apache 서버에서 SSLv3 비활성화 SSLv3를 비활성화하려면 Apache 서버 `ssl.conf` 파일의 `SSLProtocol` 설정을 수정해야 합니다. 이렇게 하려면 Java 앱 서버 계층의 설치 레시피가 `ssl.conf`을 생성하는 데 사용하는 내장 [apache2 쿡북의](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.10/apache2) `ssl.conf.erb` 템플릿 파일을 재정의해야 합니다. 세부 사항은 계층의 인스턴스에 대해 지정하는 운영 체제에 따라 다릅니다. 다음은 Amazon Linux 및 Ubuntu 시스템에 필요한 수정을 요약한 것입니다. Red Hat Enterprise Linux(RHEL) 시스템의 경우, SSLv3가 자동으로 비활성화됩니다. 내장 템플릿을 재정의하는 방법에 대한 자세한 정보는 [사용자 지정 템플릿 사용 ](workingcookbook-template-override.md)를 참조하세요. **Amazon Linux** 이러한 운영 체제의 `ssl.conf.erb` 파일은 `apache2` 쿡북의 `apache2/templates/default/mods` 디렉터리에 있습니다. 다음은 내장 파일의 관련 부분을 보여 줍니다. ``` ... #SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL # enable only secure protocols: SSLv3 and TLSv1.2, but not SSLv2 SSLProtocol all -SSLv2 ``` 다음과 같이 `ssl.conf.erb`를 재정의하고 `SSLProtocol` 설정을 수정합니다. ``` ... #SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL # enable only secure protocols: SSLv3 and TLSv1.2, but not SSLv2 SSLProtocol all -SSLv3 -SSLv2 ``` **Ubuntu 14.04 LTS** 이 운영 체제의 `ssl.conf.erb` 파일은 `apache2` 쿡북의 `apache2/templates/ubuntu-14.04/mods` 디렉터리에 있습니다. 다음은 내장 파일의 관련 부분을 보여 줍니다. ``` ... # The protocols to enable. # Available values: all, SSLv3, TLSv1.2 # SSL v2 is no longer supported SSLProtocol all ... ``` 이 설정을 다음으로 변경합니다. ``` ... # The protocols to enable. # Available values: all, SSLv3, TLSv1.2 # SSL v2 is no longer supported SSLProtocol all -SSLv3 -SSLv2 ... ``` # 사용자 지정 구성 **중요** 이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요. OpsWorks Stacks는 추가 구성 설정을 `opsworks_java` 네임스페이스에 있는 기본 제공 속성으로 노출합니다. 사용자 지정 JSON 또는 사용자 지정 속성 파일을 사용하여 내장 속성을 재정의하고 사용자 지정 값을 지정할 수 있습니다. 예를 들어 JVM 및 Tomcat 버전은 내장 `jvm_version` 및 `java_app_server_version` 속성으로 표시되며, 둘 다 7로 설정됩니다. 사용자 지정 JSON 또는 사용자 지정 속성 파일을 사용하여 둘 중 하나 또는 둘 모두를 6으로 설정할 수 있습니다. 다음 예제에서는 사용자 지정 JSON을 사용하여 두 속성 모두를 6으로 설정합니다. ``` { "opsworks_java": { "jvm_version": 6, "java_app_server_version" : 6 } } ``` 자세한 내용은 [사용자 지정 JSON 사용](workingstacks-json.md) 섹션을 참조하세요. 사용자 지정 구성의 또 다른 예제는 `use_custom_pkg_location`, `custom_pkg_location_url_debian`, `custom_pkg_location_url_rhel` 속성을 재정의하여 사용자 지정 JDK를 설치하는 것입니다. **참고** 내장 쿡북을 재정의하는 경우, 이러한 구성 요소를 직접 업데이트해야 합니다. 속성과 속성 재정의 방법에 대한 자세한 정보는 [속성 재정의](workingcookbook-attributes.md) 단원을 참조하세요. 내장 속성의 목록은 [opsworks\$1java 속성](attributes-recipes-java.md)를 참조하세요. # Java 앱 배포 **중요** 이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요. 다음 주제에서는 Java 앱 서버 계층의 인스턴스에 앱을 배포하는 방법을 설명합니다. 예제는 JSP 앱용이지만 다른 유형의 Java 앱 설치에도 기본적으로 동일한 절차를 사용할 수 있습니다. 지원되는 모든 리포지토리에서 JSP 페이지를 배포할 수 있습니다. WAR 파일을 배포하려는 경우 OpsWorks Stacks는 Git 또는 Subversion 리포지토리가 아닌 Amazon S3 또는 HTTP 아카이브에서 배포된 WAR 파일을 자동으로 추출합니다. WAR 파일에 Git 또는 하위 버전을 사용하려면 다음 중 하나를 수행할 수 있습니다. + 추출된 아카이브를 리포지토리에 저장합니다. + 리포지토리에 WAR 파일을 저장하고 다음 예제의 설명처럼 Chef 배포 후크를 사용하여 아카이브를 추출합니다. Chef 배포 후크를 사용하여 배포 4단계 중 어느 단계에서나 사용자 제공 Ruby 애플리케이션을 인스턴스에서 실행할 수 있습니다. 애플리케이션 이름이 단계를 결정합니다. 다음은 Git 또는 하위 버전 리포지토리에서 배포된 WAR 파일을 추출하는 `before_migrate.rb`라는 Ruby 애플리케이션의 예제입니다. 이 이름은 애플리케이션을 Checkout 배포 후크에 연결하므로 코드가 검사 후 마이그레이션 전에 배포 작업이 시작될 때 애플리케이션이 실행됩니다. 이 예제를 사용하는 방법에 대한 자세한 정보는 [Chef 배포 후크 사용](workingcookbook-extend-hooks.md)를 참조하세요. ``` ::Dir.glob(::File.join(release_path, '*.war')) do |archive_file| execute "unzip_#{archive_file}" do command "unzip #{archive_file}" cwd release_path end end ``` **참고** JSP 앱에 업데이트를 배포하면 Tomcat이 업데이트를 인식하지 못하고 기존 앱 버전을 계속 실행할 수 있습니다. 예를 들어 JSP 페이지만 포함된 .zip 파일로 앱을 배포하는 경우, 이런 현상이 생길 수 있습니다. Tomcat이 가장 최근에 배포된 버전을 실행하도록 하려면 `web.xml` 파일이 포함된 WEB-INF 디렉터리가 프로젝트의 루트 디렉터리에 포함되어야 합니다. `web.xml` 파일에는 다양한 콘텐츠가 포함될 수 있지만 Tomcat이 업데이트를 인식하고 현재 배포된 앱 버전을 실행하도록 하는 데는 다음으로 충분합니다. 각 업데이트의 버전을 변경할 필요는 없습니다. Tomcat은 버전이 변경되지 않은 경우에도 업데이트를 인식합니다. ``` appVersion 0.1 ``` **Topics** + [JSP 앱 배포](#layers-java-deploy-jsp) + [백엔드 데이터베이스를 사용하여 JSP 앱 배포](#layers-java-deploy-jsp-db) ## JSP 앱 배포 JSP 앱을 배포하려면 이름 및 리포지토리 정보를 지정합니다. 필요한 경우, 도메인 및 SSL 설정도 지정할 수 있습니다. 앱을 생성하는 방법에 대한 자세한 정보는 [앱 추가](workingapps-creating.md) 단원을 참조하세요. 다음 절차에서는 퍼블릭 Amazon S3 아카이브에서 간단한 JSP 페이지를 생성하고 배포하는 방법을 살펴봅니다. 프라이빗 Amazon S3 아카이브 등 다른 리포지토리 유형을 사용하는 방법에 대해서는 [애플리케이션 소스](workingapps-creating.md#workingapps-creating-source) 단원을 참조하세요. 다음 예제는 단순히 일부 시스템 정보를 표시하는 JSP 페이지를 보여 줍니다. ``` <%@ page import="java.net.InetAddress" %> <% java.util.Date date = new java.util.Date(); InetAddress inetAddress = InetAddress.getLocalHost(); %> The time is <% out.println( date ); out.println("
Your server's hostname is "+inetAddress.getHostName()); %>
``` **참고** 다음 절차에서는 스택 생성, 계층에 인스턴스 추가 등등의 기본적 내용에 이미 익숙하다고 가정합니다. OpsWorks Stacks를 처음 사용하는 경우 먼저 단원을 참조하십시오[Chef 11 Linux 스택 시작하기](gettingstarted.md). **Amazon S3 아카이브에서 JSP 페이지를 배포하려면** 1. Java 앱 서버 계층으로 [스택을 생성하고](workingstacks-creating.md), 해당 계층에 [연중무휴 인스턴스를 추가한](workinginstances-add.md) 다음 [시작하세요](workinginstances-starting.md). 1. 코드를 `simplejsp.jsp` 파일에 복사하고 이 파일을 `simplejsp` 폴더에 저장한 다음 이 폴더의 `.zip` 아카이브를 생성합니다. 이름은 임의적이므로, 원하는 파일 또는 폴더 이름은 어떤 것이든 사용할 수 있습니다. 또한 gzip, bzip2, tarball 또는 Java WAR 파일을 비롯하여 다른 아카이브 유형을 사용할 수도 있습니다. OpsWorks Stacks는 압축되지 않은 tarball을 지원하지 않습니다. 여러 JSP 페이지를 배포하려면 배포하려는 페이지를 동일한 아카이브에 저장합니다. 1. 이 아카이브를 Amazon S3 버킷에 업로드하고 이 파일을 퍼블릭으로 설정합니다. 나중에 사용하기 위해 파일의 URL를 복사해 둡니다. 버킷 생성 및 파일 업로드 방법에 대한 자세한 내용은 [Amazon Simple Storage Service 시작하기](https://docs.aws.amazon.com/AmazonS3/latest/gsg/GetStartedWithS3.html)를 참조하세요. 1. 스택에 [앱을 추가](workingapps-creating.md#workingapps-creating-general)하고 다음 설정을 지정합니다. + **명칭** – `SimpleJSP` + **앱 유형** – `Java` + **리포지토리 유형** – `Http Archive` + **리포지토리 URL** - 아카이브 파일의 Amazon S3 URL. 나머지 설정에 대해서는 기본값을 사용하고 [**앱 추가**]를 클릭하여 앱을 생성합니다. 1. [앱을 Java 앱 서버 인스턴스에 배포합니다](workingapps-deploying.md). 이제 앱의 URL로 이동하여 앱을 볼 수 있습니다. 도메인을 지정하지 않았다면 인스턴스의 퍼블릭 IP 주소나 퍼블릭 DNS 이름을 사용하여 URL을 생성할 수 있습니다. 인스턴스의 퍼블릭 IP 주소 또는 퍼블릭 DNS 이름을 가져오려면 OpsWorks Stacks 콘솔로 이동하여 인스턴스 페이지에서 **인스턴스** 이름을 클릭하여 세부 정보 페이지를 엽니다. 나머지 URL은 앱의 짧은 이름, 즉 OpsWorks Stacks가 앱을 생성할 때 지정한 앱 이름에서 생성하는 소문자 이름에 따라 달라집니다. 예를 들어 SimpleJSP의 짧은 이름은 simplejsp입니다. 앱의 짧은 이름은 앱의 세부 정보 페이지에서 가져올 수 있습니다. + 짧은 이름이 `root`인 경우, `http://public_DNS/appname.jsp` 또는 `http://public_IP/appname.jsp`을 사용할 수 있습니다. + 그렇지 않으면 `http://public_DNS/app_shortname/appname.jsp` 또는 `http://public_IP/app_shortname/appname.jsp`을 사용할 수 있습니다. 앱에 도메인을 지정한 경우, URL은 `http://domain/appname.jsp`입니다. 예제의 URL은 `http://192.0.2.0/simplejsp/simplejsp.jsp`와 비슷합니다. 같은 인스턴스에 여러 앱을 배포하려면 `root`를 짧은 이름으로 사용해선 안 됩니다. 이 경우, URL 충돌로 앱이 정상 작동하지 않습니다. 대신 앱마다 각기 다른 도메인 이름을 할당하세요. ## 백엔드 데이터베이스를 사용하여 JSP 앱 배포 JSP 페이지는 JDBC `DataSource` 객체를 사용하여 백엔드 데이터베이스에 연결할 수 있습니다. 이러한 앱은 이전 섹션의 절차와 연결을 설정하는 추가 단계를 사용하여 생성 및 배포할 수 있습니다. 다음 JSP 페이지는 `DataSource` 객체에 연결하는 방법을 보여 줍니다. ``` DB Access <%@ page language="java" import="java.sql.*,javax.naming.*,javax.sql.*" %> <% StringBuffer output = new StringBuffer(); DataSource ds = null; Connection con = null; Statement stmt = null; ResultSet rs = null; try { Context initCtx = new InitialContext(); ds = (DataSource) initCtx.lookup("java:comp/env/jdbc/mydb"); con = ds.getConnection(); output.append("Databases found:
"); stmt = con.createStatement(); rs = stmt.executeQuery("show databases"); while (rs.next()) { output.append(rs.getString(1)); output.append("
"); } } catch (Exception e) { output.append("Exception: "); output.append(e.getMessage()); output.append("
"); } finally { try { if (rs != null) { rs.close(); } if (stmt != null) { stmt.close(); } if (con != null) { con.close(); } } catch (Exception e) { output.append("Exception (during close of connection): "); output.append(e.getMessage()); output.append("
"); } } %> <%= output.toString() %> ``` OpsWorks Stacks는 `DataSource` 객체를 생성 및 초기화하고, 논리적 이름에 바인딩하고, Java 이름 지정 및 디렉터리 인터페이스(JNDI) 이름 지정 서비스에 이름을 등록합니다. 완전한 논리적 이름은 `java:comp/env/user-assigned-name`입니다. 다음에서 설명하는 것처럼 사용자 지정 JSON 속성을 스택 구성 및 배포 속성에 추가함으로써 이름의 사용자 할당 부분을 지정하여 `['opsworks_java']['datasources']` 속성을 정의해야 합니다. **MySQL 데이터베이스에 연결하는 JSP 페이지를 배포하려면** 1. Java 앱 서버 계층으로 [스택을 만들고](workingstacks-creating.md) 각 계층에 [연중무휴 인스턴스를 추가한](workinginstances-add.md) 다음 [시작합니다](workinginstances-starting.md). 1. 데이터베이스 계층을 스택에 추가합니다. 세부적인 사항은 사용하는 데이터베이스에 따라 달라집니다. 예를 들어 MySQL 인스턴스를 사용하려면 [스택에 MySQL 계층을 추가하고](workinglayers-db-mysql.md), 이 계층에 [24/7 인스턴스를 추가한](workinginstances-add.md) 다음 [해당 인스턴스를 시작합니다](workinginstances-starting.md#workinginstances-starting-start). 예를 들어 Amazon RDS(MySQL) 인스턴스를 시작하려면, + 인스턴스의 MySQL 데이터베이스 엔진을 지정합니다. + **AWS-OpsWorks-DB-Master-Server(*security\$1group\$1id*)** 및 **AWS-OpsWorks-Java-App-Server(*security\$1group\$1id*)** 보안 그룹을 인스턴스에 할당합니다. OpsWorks Stacks는 리전에서 첫 번째 스택을 생성할 때 이러한 보안 그룹을 생성합니다. + `simplejspdb`라는 데이터베이스를 생성합니다. + 마스터 사용자 이름 및 암호에는 Tomcat 오류를 일으킬 수 있는 `&` 또는 기타 문자가 포함되면 안 됩니다. 특히, 시작 중에 Tomcat은 마스터 암호 및 사용자 이름이 포함된 XML 파일인 웹 앱 컨텍스트 파일을 구문 분석해야 합니다. 문자열 중 하나에 `&` 문자가 포함되어 있으면 XML 구문 분석기는 이 문자를 형식이 잘못된 XML 엔터티로 취급하여 구문 분석 예외가 발생해 Tomcat이 시작되지 않습니다. 웹 앱 컨텍스트 파일에 대한 자세한 정보는 [tomcat::context](create-custom-configure.md#create-custom-configure-context) 단원을 참조하세요. + [MySQL 드라이버를 Java 앱 서버 계층에 추가합니다](workingapps-connectdb.md). + 스택에 [RDS 인스턴스를 등록](workinglayers-db-rds.md#workinglayers-db-rds-register)합니다. OpsWorks Stacks에서 Amazon RDS 인스턴스를 사용하는 방법에 대한 자세한 내용은 섹션을 참조하세요[Amazon RDS 서비스 계층](workinglayers-db-rds.md). 1. 예제 코드를 `simplejspdb.jsp` 파일에 복사하고 이 파일을 `simplejspdb` 폴더에 저장한 다음 이 폴더의 `.zip` 아카이브를 생성합니다. 이름은 임의적이므로, 원하는 파일 또는 폴더 이름은 어떤 것이든 사용할 수 있습니다. 또한 gzip, bzip2 또는 tarball을 비롯하여 다른 아카이브 유형을 사용할 수도 있습니다. 여러 JSP 페이지를 배포하려면 배포하려는 페이지를 동일한 아카이브에 저장합니다. 다른 리포지토리 유형에서 앱을 배포하는 방법은 [애플리케이션 소스](workingapps-creating.md#workingapps-creating-source) 단원을 참조하세요. 1. 이 아카이브를 Amazon S3 버킷에 업로드하고 이 파일을 퍼블릭으로 설정합니다. 나중에 사용하기 위해 파일의 URL를 복사해 둡니다. 버킷 생성 및 파일 업로드 방법에 대한 자세한 내용은 [Amazon Simple Storage Service 시작하기](https://docs.aws.amazon.com/AmazonS3/latest/gsg/GetStartedWithS3.html)를 참조하세요. 1. 스택에 [앱을 추가](workingapps-creating.md#workingapps-creating-general)하고 다음 설정을 지정합니다. + **명칭** – `SimpleJSPDB` + **앱 유형** – `Java` + **데이터 소스 유형** - **OpsWorks**(MySQL 인스턴스의 경우) 또는 **RDS**(Amazon RDS 인스턴스의 경우). + **데이터베이스 인스턴스** - 앞서 생성한 MySQL 인스턴스(이름: **db-master1(mysql)**) 또는 Amazon RDS 인스턴스(이름: ***DB\$1instance\$1name* (mysql)**). + **데이터베이스 이름** – `simplejspdb`. + **리포지토리 유형** – `Http Archive` + **리포지토리 URL** - 아카이브 파일의 Amazon S3 URL. 나머지 설정에 대해서는 기본값을 사용하고 [**앱 추가**]를 클릭하여 앱을 생성합니다. 1. 스택 구성 속성에 다음 사용자 지정 JSON 속성을 추가합니다. 여기서 simplejspdb는 앱의 짧은 이름입니다. ``` { "opsworks_java": { "datasources": { "simplejspdb": "jdbc/mydb" } } } ``` OpsWorks Stacks는이 매핑을 사용하여 필요한 데이터베이스 정보가 포함된 컨텍스트 파일을 생성합니다. 스택 구성 속성에 사용자 지정 JSON 속성을 추가하는 방법은 [사용자 지정 JSON 사용](workingstacks-json.md) 단원을 참조하세요. 1. [앱을 Java 앱 서버 인스턴스에 배포합니다](workingapps-deploying.md). 이제 앱의 URL을 사용하여 앱을 볼 수 있습니다. URL 생성 방법에 대한 설명은 [JSP 앱 배포](#layers-java-deploy-jsp)를 참조하세요. 예제의 URL은 `http://192.0.2.0/simplejspdb/simplejspdb.jsp`와 비슷합니다. **참고** `datasources` 속성에는 여러 속성이 포함될 수 있습니다. 각 속성은 앱의 짧은 이름으로 명명되며, 논리적 이름의 적절한 사용자 할당 부분으로 설정됩니다. 앱이 여러 개인 경우에는 별도의 논리적 이름을 사용할 수 있으며, 다음과 비슷한 사용자 지정 JSON이 필요합니다. ``` { "opsworks_java": { "datasources": { "myjavaapp": "jdbc/myappdb", "simplejsp": "jdbc/myjspdb", ... } } } ``` # Node.js 앱 서버 OpsWorks 스택 계층 **중요** 이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요. **참고** 이 계층은 Linux 기반 스택에서만 사용할 수 있습니다. Node.js 앱 서버 계층은 [Node.js](http://nodejs.org/) 애플리케이션 서버로 작동하는 인스턴스에 대한 청사진을 제공하는 OpsWorks Stacks 계층입니다. OpsWorks Stacks는 [Express](http://expressjs.com/)도 설치하므로 계층의 인스턴스는 표준 애플리케이션과 Express 애플리케이션을 모두 지원합니다. **설치**: Node.js가 `/usr/local/bin/node`에 설치됩니다. [**계층 추가**] 페이지는 다음 구성 옵션을 제공합니다. **Node.js 버전** 현재 지원되는 버전의 목록은 [OpsWorks Stacks 운영 체제](workinginstances-os.md) 단원을 참조하세요. **사용자 지정 보안 그룹** 이 설정은 내장 OpsWorks Stacks 보안 그룹을 계층에 자동으로 연결하지 않도록 선택한 경우에 나타납니다. 계층에 어떤 보안 그룹을 연결할지 지정해야 합니다. 자세한 내용은 [새 스택 생성](workingstacks-creating.md) 섹션을 참조하세요. **Elastic Load Balancer** Elastic Load Balancing 로드 밸런서를 어떤 계층의 인스턴스에도 연결할 수 있습니다. **중요** Node.js 애플리케이션이 SSL을 사용하는 경우, 가능하다면 SSLv3를 비활성화하여 [CVE-2015-8027](http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-8027)에 설명된 취약성을 해결하는 것이 좋습니다. 그러려면 [**Node.js 버전**]을 `0.12.9`로 설정해야 합니다. ## Node.js 앱 배포 OpsWorks Stacks를 위한 간단한 Node.js 애플리케이션을 구현하여 스택에 배포하는 방법의 자세한 안내는 [첫 번째 Node.js 스택 생성](gettingstarted-node.md) 단원을 참조하세요. 일반적으로 OpsWorks Stacks용 Node.js 애플리케이션이 충족해야 하는 조건은 다음과 같습니다. + 메인 파일의 이름은 `server.js`여야 하며, 배포된 애플리케이션이 루트 디렉터리에 상주해야 합니다. + [Express](http://expressjs.com/) 앱은 애플리케이션의 루트 디렉터리에 `package.json` 파일을 포함해야 합니다. + 기본적으로 이 애플리케이션은 포트 80(HTTP) 또는 포트 443(HTTPS)에서 수신해야 합니다. 다른 포트에서도 수신이 가능하지만 Node.js 앱 서버 계층의 내장 보안 그룹인 **AWS-OpsWorks-nodejs-App-Server**는 포트 80, 443, 22(SSH)로의 인바운드 사용자 트래픽을 허용합니다. 다른 포트로의 인바운드 사용자 트래픽을 허용하려면 적절한 인바운드 규칙을 사용하여 [보안 그룹을 생성하고](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) [Node.js 앱 서버 계층에 할당합니다](workinglayers-basics-edit.md#workinglayers-basics-edit-security). 내장 보안 그룹을 편집하여 인바운드 규칙을 수정하지 마십시오. 스택을 생성할 때마다 OpsWorks Stacks는 기본 제공 보안 그룹을 표준 설정으로 덮어쓰므로 변경 사항이 손실됩니다. **참고** OpsWorks Stacks는 PORT 환경 변수를 80(기본값) 또는 443(SSL을 활성화한 경우)으로 설정하므로 다음 코드를 사용하여 요청을 수신할 수 있습니다. ``` app.listen(process.env.PORT); ``` [SSL을 지원하도록 Node.js 앱을 구성하는](workingapps-creating.md#workingapps-creating-domain-ssl) 경우 키와 인증서를 지정해야 합니다. OpsWorks Stacks는 다음과 같이 각 애플리케이션 서버 인스턴스의 데이터를 `/srv/www/app_shortname/shared/config` 디렉터리에 별도의 파일로 저장합니다. + `ssl.crt` – SSL 인증서입니다. + `ssl.key` – SSL 키입니다. + `ssl.ca` – 체인 인증서(지정한 경우). 애플리케이션은 이러한 파일에서 SSL 키와 인증서를 가져올 수 있습니다. # PHP 앱 서버 OpsWorks 스택 계층 **중요** 이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요. **참고** 이 계층은 Linux 기반 스택에서만 사용할 수 있습니다. PHP 앱 서버 계층은 PHP 애플리케이션 서버로 작동하는 인스턴스에 대한 청사진을 제공하는 OpsWorks Stacks 계층입니다. PHP 앱 서버 계층은 `mod_php`가 있는 [Apache2](http://httpd.apache.org/)를 기반으로 하며 표준 구성 옵션은 없습니다. PHP 및 Apache 버전은 계층의 인스턴스에 대해 지정하는 [운영 체제](workinginstances-os.md)에 따라 달라집니다. | 운영 체제 | PHP 버전 | Apache 버전 | | --- | --- | --- | | Amazon Linux 2018.03 | 5.3 | 2.2 | | Amazon Linux 2017.09 | 5.3 | 2.2 | | Amazon Linux 2017.03 | 5.3 | 2.2 | | Amazon Linux 2016.09 | 5.3 | 2.2 | | Amazon Linux 2016.03 | 5.3 | 2.2 | | Amazon Linux 2015.09 | 5.3 | 2.2 | | Amazon Linux 2015.03 | 5.3 | 2.2 | | Amazon Linux 2014.09 | 5.3 | 2.2 | | Ubuntu 14.04 LTS | 5.5 | 2.4 | **Installation**: OpsWorks Stacks는 인스턴스의 패키지 설치 관리자를 사용하여 기본 위치에 Apache2 및 `mod_php`를 설치합니다. 설치에 대한 자세한 정보는 [Apache](http://httpd.apache.org/)를 참조하세요. [**계층 추가**] 페이지는 다음 구성 옵션을 제공합니다. **사용자 지정 보안 그룹** 이 설정은 내장 OpsWorks Stacks 보안 그룹을 계층에 자동으로 연결하지 않도록 선택한 경우에 나타납니다. 계층에 어떤 보안 그룹을 연결할지 지정해야 합니다. 자세한 내용은 [새 스택 생성](workingstacks-creating.md) 섹션을 참조하세요. **Elastic Load Balancer** Elastic Load Balancing 로드 밸런서를 어떤 계층의 인스턴스에도 연결할 수 있습니다. 사용자 지정 JSON 또는 사용자 지정 속성 파일을 사용하여 일부 Apache 구성 설정을 수정할 수 있습니다. 자세한 내용은 [속성 재정의](workingcookbook-attributes.md) 섹션을 참조하세요. 재정의할 수 있는 Apache 속성의 목록은 [apache2 속성](attributes-recipes-apache.md) 단원을 참조하세요. PHP 앱을 백엔드 데이터베이스에 연결하는 방법 등 PHP 앱을 배포하는 방법의 예제는 [Chef 11 Linux 스택 시작하기](gettingstarted.md)를 참조하세요. **중요** PHP 애플리케이션이 SSL을 사용하는 경우, 가능하다면 SSLv3를 비활성화하여 [CVE-2014-3566](http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566)에 설명된 취약성을 해결하는 것이 좋습니다. 그러려면 Apache 서버의 `SSLProtocol` 파일에서 `ssl.conf`설정을 수정해야 합니다. 이 설정을 수정하는 방법에 대한 자세한 정보는 [Apache 서버에서 SSLv3 비활성화](layers-java.md#layers-java-sslv3)를 참조하세요. # Rails 앱 서버 OpsWorks 스택 계층 **중요** 이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요. **참고** 이 계층은 Linux 기반 스택에서만 사용할 수 있습니다. Rails 앱 서버 계층은 Rails 애플리케이션 서버로 작동하는 인스턴스에 대한 블루프린트를 제공하는 OpsWorks Stacks 계층입니다. **Installation**: OpsWorks Stacks는 인스턴스의 패키지 설치 관리자를 사용하여 기본 위치에 서버 패키지를 설치합니다. Apache/Passenger 설치에 대한 자세한 정보는 [Phusion Passenger](https://www.phusionpassenger.com/)를 참조하세요. 로깅에 대한 자세한 정보는 [로그 파일](http://httpd.apache.org/docs/2.2/logs.html) 단원을 참조하세요. Nginx/Unicorn 설치에 대한 자세한 정보는 [Unicorn](http://unicorn.bogomips.org/) 단원을 참조하세요. [**계층 추가**] 페이지는 모두가 선택 사항인 다음 구성 옵션을 제공합니다. **Ruby 버전** 애플리케이션이 사용할 Ruby 버전. 기본값은 2.3입니다. [`[:opsworks][:ruby_version]`](workingcookbook-attributes.md) 속성을 재정의하면 선호하는 Ruby 버전을 지정할 수도 있습니다. OpsWorks Stacks는 레시피와 인스턴스 에이전트에서 사용할 별도의 Ruby 패키지를 설치합니다. 자세한 내용은 [Ruby 버전](workingcookbook-ruby.md) 단원을 참조하십시오. **Rails 스택** 기본 Rails 스택은 [Phusion Passenger](https://www.phusionpassenger.com/)가 있는 [Apache2](http://httpd.apache.org/)입니다. [Nginx](http://nginx.org/en/)를 [유니콘](http://unicorn.bogomips.org/)과 함께 사용할 수도 있습니다. Nginx와 Unicorn을 사용하는 경우, 다음 예제에서처럼 앱의 Gemfile에 unicorn gem을 추가해야 합니다. ``` source 'https://rubygems.org' gem 'rails', '3.2.15' ... # Use unicorn as the app server gem 'unicorn' ... ``` **Passenger 버전** Apache2/Passenger를 지정한 경우, Passenger 버전을 지정해야 합니다. 기본값은 5.0.28입니다. **Rubygems 버전** 기본 [Rubygems](http://rubygems.org/) 버전은 2.5.1입니다. **Bundler 설치 및 관리** [Bundler](http://gembundler.com/) 설치 및 관리 여부를 선택할 수 있도록 해 줍니다. 기본 값은 [**예**]입니다. **Bundler 버전** 기본 Bundler 버전은 1.12.5입니다. **사용자 지정 보안 그룹** 이 설정은 내장 OpsWorks Stacks 보안 그룹을 계층에 자동으로 연결하지 않도록 선택한 경우에 나타납니다. 계층에 어떤 보안 그룹을 연결할지 지정해야 합니다. 자세한 내용은 [새 스택 생성](workingstacks-creating.md) 섹션을 참조하세요. **Elastic Load Balancer** Elastic Load Balancing 로드 밸런서를 어떤 계층의 인스턴스에도 연결할 수 있습니다. 사용자 지정 JSON 또는 사용자 지정 속성 파일을 사용하여 일부 구성 설정을 수정할 수 있습니다. 자세한 내용은 [속성 재정의](workingcookbook-attributes.md) 섹션을 참조하세요. 재정의할 수 있는 Apache, Nginx, Phusion Passenger 및 Unicorn 속성 목록은 [내장 쿡북 속성](attributes-recipes.md)를 참조하세요. **중요** Ruby on Rails 애플리케이션이 SSL을 사용하는 경우, 가능하다면 SSLv3를 비활성화하여 [CVE-2014-3566](http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566)에 설명된 취약성을 해결하는 것이 좋습니다. 자세한 내용은 [Rails 서버에 대해 SSLv3 비활성화](#workinglayers-rails-sslv3) 섹션을 참조하세요. **Topics** + [Rails 서버에 대해 SSLv3 비활성화](#workinglayers-rails-sslv3) + [데이터베이스에 연결](#workinglayers-rails-db) + [Ruby on Rails 앱 배포](#workinglayers-rails-deploy) ## Rails 서버에 대해 SSLv3 비활성화 Rails 서버에 대해 SSLv3를 비활성화하려면 계층의 **Ruby Version(Ruby 버전)** 설정을 2.1로 업데이트합니다. 그러면 애플리케이션이 사용하는 버전으로 Ruby 2.1.4 이상이 설치됩니다. + 계층의 **Ruby 버전** 설정을 2.1 이상으로 업데이트합니다. + Rails 스택의 구성 파일을 다음과 같이 업데이트합니다. **Phusion Passenger 포함 Apache** Apache 서버 `SSLProtocol` 파일의 `ssl.conf` 설정을 [Apache 서버에서 SSLv3 비활성화](layers-java.md#layers-java-sslv3)의 설명에 따라 업데이트합니다. **Unicorn 포함 Nginx** Nginx 서버의 `ssl_protocols` 파일에 명시적인 `nginx.conf` 명령을 추가합니다. SSLv3를 비활성화하려면 Rails 앱 서버 계층의 설정 레시피가 `nginx.conf`을 생성하는 데 사용하는 내장 [nginx 쿡북의](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.10/nginx) `nginx.conf.erb` 템플릿 파일을 재정의하고 다음 지시문을 추가합니다. ``` ssl_protocols TLSv1.2; ``` `nginx.conf`를 구성하는 방법에 대한 자세한 정보는 [HTTPS 서버 구성](http://nginx.org/en/docs/http/configuring_https_servers.html) 단원을 참조하세요. 내장 템플릿을 재정의하는 방법에 대한 자세한 정보는 [사용자 지정 템플릿 사용 ](workingcookbook-template-override.md)를 참조하세요. ## 데이터베이스에 연결 앱을 배포하면 OpsWorks Stacks는 앱 [`deploy` 속성](workingcookbook-json.md#workingcookbook-json-deploy)의 정보를 사용하여 새 `database.yml` 파일을 생성합니다. [MySQL 또는 Amazon RDS 인스턴스를 앱에 연결](workingapps-creating.md#workingapps-creating-data)하면 OpsWorks Stacks는 속성에 연결 정보를 추가하여에 올바른 연결 데이터가 `deploy` `database.yml` 자동으로 포함됩니다. 앱에 연결된 데이터베이스가 없는 경우 기본적으로 OpsWorks Stacks는 `deploy` 속성에 연결 정보를 추가하지 않으며를 생성하지 않습니다`database.yml`. 다른 데이터베이스를 사용하려는 경우, 사용자 지정 JSON을 사용하여 앱의 `deploy` 속성에 연결 정보와 함께 데이터베이스 속성을 추가할 수 있습니다. 속성은 모두 아래에 있습니다`["deploy"]["appshortname"]["database"]`. 여기서 *appshortname*은 OpsWorks Stacks가 앱 이름에서 생성하는 앱의 짧은 이름입니다. 사용자 지정 JSON에서 지정하는 값은 기본 설정을 재정의합니다. 자세한 내용은 [앱 추가](workingapps-creating.md) 단원을 참조하십시오. OpsWorks Stacks는 다음 [`[:...][:database]`](attributes-json-deploy.md#attributes-json-deploy-app-db) 속성 값을에 통합합니다`database.yml`. 필수 속성은 특정 데이터베이스에 따라 다르지만 `host` 속성이 있어야 합니다. 그렇지 않으면 OpsWorks Stacks가를 생성하지 않습니다`database.yml`. + `[:adapter] (String)` - `mysql`과 같은 데이터베이스 어댑터. + `[:database]`(문자열) - 데이터베이스 이름. + `[:encoding]`(문자열) - 일반적으로 `utf8`로 설정되는 인코딩. + `[:host]`(문자열) - `railsexample.cdlqlk5uwd0k.us-west-2.rds.amazonaws.com`과 같은 호스트 URL. + `[:reconnect]`(Boolean) - 연결이 더 이상 존재하지 않는 경우, 애플리케이션이 다시 연결해야 하는지 여부. + `[:password]`(문자열) - 데이터베이스 암호. + `[:port]` (번호). - 데이터베이스 포트 숫자. 이 속성을 사용하여 기본 포트 번호를 재정의합니다(기본 포트 번호는 어댑터에 의해 설정). + `[:username]`(문자열) - 데이터베이스 사용자 이름. 다음 예제는 짧은 이름이 *myapp*인 앱의 사용자 지정 JSON을 보여 줍니다. ``` { "deploy" : { "myapp" : { "database" : { "adapter" : "adapter", "database" : "databasename", "host" : "host", "password" : "password", "port" : portnumber "reconnect" : true/false, "username" : "username" } } } } ``` 사용자 지정 JSON을 지정하는 방법에 대해서는 [사용자 지정 JSON 사용](workingstacks-json.md) 단원을 참조하세요. `database.yml`(`database.yml.erb`) 생성에 사용되는 템플릿을 보려면 [내장 쿡북 리포지토리](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.4/rails/templates/default)로 이동하세요. ## Ruby on Rails 앱 배포 지원되는 모든 리포지토리에서 Ruby on Rails 앱을 배포할 수 있습니다. 다음은 Apache/Passenger Rails 스택을 실행하는 서버에 예제 Ruby on Rails 앱을 배포하는 방법을 보여 줍니다. 예제 코드는 퍼블릭 GitHub 리포지토리에 저장되지만 기본 절차는 지원되는 다른 리포지토리와 동일합니다. 앱을 생성하고 배포하는 방법에 대한 자세한 정보는 [앱](workingapps.md) 단원을 참조하세요. 방대한 주석이 포함된 예제 코드를 보려면 [https://github.com/awslabs/opsworks-demo-rails-photo-share-app](https://github.com/awslabs/opsworks-demo-rails-photo-share-app)으로 이동합니다. **GitHub 리포지토리에서 Ruby on Rails 앱을 배포하려면** 1. Apache/Passenger를 Rails 스택으로 하는 Rails 앱 서버 계층을 사용하여 [스택을 생성하고](workingstacks-creating.md), 해당 계층에 [연중무휴 인스턴스를 추가한](workinginstances-add.md) 다음 [시작합니다](workinginstances-starting.md). 1. 인스턴스가 온라인 상태가 되면 스택에 [앱을 추가](workingapps-creating.md#workingapps-creating-general)하고 다음 설정을 지정합니다. + **이름** - 선호하는 모든 이름을 지정할 수 있습니다. 이 예제에서는 `PhotoPoll`을 사용합니다. OpsWorks Stacks는이 이름을 표시용으로 사용하고 내부용으로 짧은 이름을 생성하고 [스택 구성 및 배포 속성](workingcookbook-json.md)에서 앱을 식별합니다. 예를 들어 PhotoPoll의 짧은 이름은 photopoll입니다. + **앱 유형** – **Ruby on Rails**. + ** Rails 환경** - 사용 가능한 환경은 애플리케이션에서 결정합니다. 예제에서 사용되는 앱에는 **development**, **test** 및 **production**, 이렇게 세 가지 환경이 있습니다. 이 예제에서는 환경을 **development**로 설정합니다. 각 환경에 대한 설명은 예제 코드를 참조하세요. + **리포지토리 유형** - 지원되는 모든 리포지토리 유형. 이 예제에서는 `Git`를 지정합니다. + **리포지토리 URL** - 배포할 코드를 가져와야 하는 리포지토리. 이 예제에서는 URL을 **git://github.com/awslabs/opsworks-demo-rails-photo-share-app**으로 설정합니다. 나머지 설정에 대해서는 기본값을 사용하고 [**앱 추가**]를 클릭하여 앱을 생성합니다. 1. [앱을 Rails 앱 서버 인스턴스에 배포합니다.](workingapps-deploying.md) 1. 배포를 마치면 **인스턴스** 페이지로 이동해 Rails 앱 서버 인스턴스의 퍼블릭 IP 주소를 클릭합니다. 다음과 같은 모양이어야 합니다. ![\[Congratulatory message for deploying first app with AWS OpsWorks, with stylized logo.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/rails_example.png) # 정적 웹 서버 OpsWorks 스택 계층 **중요** 이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요. **참고** 이 계층은 Linux 기반 스택에서만 사용할 수 있습니다. 정적 웹 서버 계층은 인스턴스가 클라이언트 측 OpsWorks 스크립팅을 포함할 수 있는 정적 HTML 페이지를 제공하기 위한 템플릿을 제공하는 Stacks 계층입니다. 이 계층은 [Nginx](http://nginx.org/en/)를 기반으로 합니다. **설치**: Nginx가 `/usr/sbin/nginx`에 설치됩니다. [**계층 추가**] 페이지는 다음 구성 옵션을 제공합니다. **사용자 지정 보안 그룹** 이 설정은 내장 OpsWorks Stacks 보안 그룹을 계층에 자동으로 연결하지 않도록 선택한 경우에 나타납니다. 계층에 어떤 보안 그룹을 연결할지 지정해야 합니다. 자세한 내용은 [새 스택 생성](workingstacks-creating.md) 섹션을 참조하세요. **Elastic Load Balancer** Elastic Load Balancing 로드 밸런서를 어떤 계층의 인스턴스에도 연결할 수 있습니다. 사용자 지정 JSON 또는 사용자 지정 속성 파일을 사용하여 일부 Nginx 구성 설정을 수정할 수 있습니다. 자세한 내용은 [속성 재정의](workingcookbook-attributes.md) 섹션을 참조하세요. 재정의할 수 있는 Apache 속성의 목록은 [nginx 속성](attributes-recipes-nginx.md) 단원을 참조하세요. **중요** 웹 애플리케이션이 SSL을 사용하는 경우, 가능하다면 SSLv3를 비활성화하여 [CVE-2014-3566](http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566)에 설명된 취약성을 해결하는 것이 좋습니다. SSLv3를 비활성화하려면 Nginx 서버의 `nginx.conf` 파일을 수정해야 합니다. 이렇게 하려면 Rails 앱 서버 계층의 설정 레시피가 `nginx.conf`을 생성하는 데 사용하는 내장 [nginx 쿡북의](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.10/nginx) `nginx.conf.erb` 템플릿 파일을 재정의하고 다음 지시문을 추가하세요. ``` ssl_protocols TLSv1.2; ``` `nginx.conf`를 구성하는 방법에 대한 자세한 정보는 [HTTPS 서버 구성](http://nginx.org/en/docs/http/configuring_https_servers.html) 단원을 참조하세요. 내장 템플릿을 재정의하는 방법에 대한 자세한 정보는 [사용자 지정 템플릿 사용 ](workingcookbook-template-override.md)를 참조하세요.