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

# OpsWorks Stacks의 이전 Chef 버전 지원
<a name="previous-chef-versions"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

이 섹션에서는 이전 Chef 버전의 OpsWorks Stacks 설명서에 대한 간략한 개요를 제공합니다.

[Linux용 Chef 11.10 및 이전 버전](chef-11-linux.md)  
Linux 스택용 Chef OpsWorks 11.10, 11.4 및 0.9에 대한 Stacks 지원에 대한 설명서를 제공합니다.

# Linux용 Chef 11.10 및 이전 버전
<a name="chef-11-linux"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

이 섹션에서는 Linux용 Chef OpsWorks 11.10, 11.4 및 0.9용 Stacks 설명서에 대한 간략한 개요를 제공합니다.

[Chef 11 Linux 스택 시작하기](gettingstarted.md)  
간단하지만 실용적인 PHP 애플리케이션 서버 스택을 생성하는 방법을 안내합니다.

[첫 번째 Node.js 스택 생성](gettingstarted-node.md)  
Node.js 애플리케이션 서버를 지원하는 Linux 스택을 생성하고 간단한 애플리케이션을 배포하는 방법을 설명합니다.

[OpsWorks 스택 사용자 지정](customizing.md)  
특정 요구 사항에 맞게 OpsWorks Stacks를 사용자 지정하는 방법을 설명합니다.

[쿡북 101](cookbooks-101.md)  
 OpsWorks Stacks 인스턴스에 대한 레시피를 구현하는 방법을 설명합니다.

[계층 로드 밸런싱](best-server-load-balancing.md)  
사용 가능한 OpsWorks Stacks 로드 밸런싱 옵션을 사용하는 방법을 설명합니다.

[VPC에서 스택 실행](workingstacks-vpc.md)  
가상 프라이빗 클라우드에서 스택을 생성하고 실행하는 방법을 설명합니다.

[Chef Server에서 마이그레이션](best-practices-server-migrate.md)  
Chef Server에서 OpsWorks Stacks로 마이그레이션하기 위한 지침을 제공합니다.

[OpsWorks Stacks 계층 참조](layers.md)  
사용 가능한 OpsWorks Stacks 기본 제공 계층을 설명합니다.

[쿡북 구성 요소](workingcookbook-installingcustom-components.md)  
세 표준 쿡북 구성 요소인 속성, 템플릿 및 레시피를 설명합니다.

[스택 구성 및 배포 속성: Linux](attributes-json-linux.md)  
Linux용 스택 구성과 배포 속성을 설명합니다.

[내장 쿡북 속성](attributes-recipes.md)  
내장 레시피 속성을 사용하여 설치된 소프트웨어의 구성을 제어하는 방법을 설명합니다.

[Linux용 Chef 11.10 및 이전 버전 문제 해결](troubleshooting-chef-11-linux.md)  
 OpsWorks Stacks에서 다양한 문제를 해결하기 위한 접근 방식을 설명합니다.

# Chef 11 Linux 스택 시작하기
<a name="gettingstarted"></a>

**중요**  
이 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를 시작하는 방법을 설명합니다. Chef 12 Linux 스택 시작하기에 대한 자세한 정보는 [시작하기: Linux](gettingstarted-linux.md) 단원을 참조하세요. Chef 12 Windows 스택 시작하기에 대한 자세한 정보는 [시작하기: Windows](gettingstarted-windows.md) 단원을 참조하세요.

클라우드 기반 애플리케이션에는 일반적으로 애플리케이션 서버, 데이터베이스 서버 등과 같은 관련 리소스 그룹이 필요하며 이러한 리소스를 공동으로 생성하고 관리해야 합니다. 이러한 인스턴스의 모음을 *스택*이라고 합니다. 다음은 간단한 애플리케이션 스택의 예입니다.

![\[Diagram showing users connecting to app servers via internet and load balancer, with a shared database.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/php_walkthrough_arch.png)


기본 아키텍처는 다음과 같이 구성됩니다.
+ 사용자로부터 트래픽을 수신하여 애플리케이션 서버 간에 고르게 분산하는 로드 밸런서 1개
+ 트래픽을 처리하는 데 필요한 만큼의 애플리케이션 서버 인스턴스 집합
+ 애플리케이션 서버에 백엔드 데이터 스토어를 제공하기 위한 데이터베이스 서버

또한, 일반적으로 애플리케이션을 애플리케이션 서버에 배포하고 스택을 모니터링하는 등의 기능이 필요합니다.

OpsWorks Stacks는 스택과 관련 애플리케이션 및 리소스를 생성하고 관리하는 간단하고 간단한 방법을 제공합니다. 이 장에서는 다이어그램에서 애플리케이션 서버 스택을 생성하는 프로세스를 단계별로 안내하여 OpsWorks Stacks의 기본 사항과 더욱 정교한 기능을 소개합니다. OpsWorks Stacks가 따르기 쉽게 만드는 증분 개발 모델을 사용합니다. 기본 스택을 설정하고 올바르게 작동하면 전체 기능을 구현할 때까지 구성 요소를 추가합니다.
+ [1단계: 사전 조건 완료](gettingstarted-prerequisites.md)에서는 이 안내서를 시작하기 위해 필요한 사전 준비를 설명합니다.
+ [2단계: 간단한 애플리케이션 서버 스택 생성 - Chef 11](gettingstarted-simple.md)에서는 단일 애플리케이션 서버로 구성된 최소 스택을 생성하는 방법을 설명합니다.
+ [3단계; 백엔드 데이터 스토어 추가](gettingstarted-db.md)에서는 데이터베이스 서버를 추가하고 애플리케이션 서버에 연결하는 방법을 설명합니다.
+ [4단계: MyStack 확장](gettingstarted-scale.md)에서는 증가하는 로드를 처리하기 위해 더 많은 애플리케이션 서버와 수신 트래픽을 분배할 로드 밸런서를 추가하여 스택을 확장하는 방법을 설명합니다.

**Topics**
+ [1단계: 사전 조건 완료](gettingstarted-prerequisites.md)
+ [2단계: 간단한 애플리케이션 서버 스택 생성 - Chef 11](gettingstarted-simple.md)
+ [3단계; 백엔드 데이터 스토어 추가](gettingstarted-db.md)
+ [4단계: MyStack 확장](gettingstarted-scale.md)
+ [5단계: MyStack 삭제](gettingstarted-delete.md)

# 1단계: 사전 조건 완료
<a name="gettingstarted-prerequisites"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

안내서를 시작하기 전에 다음 설정 단계를 완료합니다. 이러한 설정 단계에는 AWS 계정 가입, 관리 사용자 생성, OpsWorks Stacks에 액세스 권한 할당이 포함됩니다.

이미 [OpsWorks Stacks 시작하기](gettingstarted_intro.md) 안내서 중 하나를 마쳤다면 이 안내서의 사전 조건을 충족한 것이며, [2단계: 간단한 애플리케이션 서버 스택 생성 - Chef 11](gettingstarted-simple.md)으 단원으로 건너뛸 수 있습니다.

**Topics**
+ [에 가입 AWS 계정](#sign-up-for-aws)
+ [관리자 액세스 권한이 있는 사용자 생성](#create-an-admin)
+ [사용자에게 서비스 액세스 권한 할당](#gettingstarted-prerequisites-permissions)

## 에 가입 AWS 계정
<a name="sign-up-for-aws"></a>

이 없는 경우 다음 단계를 AWS 계정완료하여 생성합니다.

**에 가입하려면 AWS 계정**

1. [https://portal.aws.amazon.com/billing/signup](https://portal.aws.amazon.com/billing/signup)을 엽니다.

1. 온라인 지시 사항을 따르세요.

   등록 절차 중 전화 또는 텍스트 메시지를 받고 전화 키패드로 확인 코드를 입력하는 과정이 있습니다.

   에 가입하면 AWS 계정*AWS 계정 루트 사용자*이 생성됩니다. 루트 사용자에게는 계정의 모든 AWS 서비스 및 리소스에 액세스할 권한이 있습니다. 보안 모범 사례는 사용자에게 관리 액세스 권한을 할당하고, 루트 사용자만 사용하여 [루트 사용자 액세스 권한이 필요한 작업](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)을 수행하는 것입니다.

AWS 는 가입 프로세스가 완료된 후 확인 이메일을 보냅니다. 언제든지 [https://aws.amazon.com/](https://aws.amazon.com/)으로 이동하고 **내 계정**을 선택하여 현재 계정 활동을 확인하고 계정을 관리할 수 있습니다.

## 관리자 액세스 권한이 있는 사용자 생성
<a name="create-an-admin"></a>

에 가입한 후 일상적인 작업에 루트 사용자를 사용하지 않도록 관리 사용자를 AWS 계정보호 AWS IAM Identity Center, AWS 계정 루트 사용자활성화 및 생성합니다.

**보안 AWS 계정 루트 사용자**

1.  **루트 사용자를** 선택하고 AWS 계정 이메일 주소를 입력하여 계정 소유자[AWS Management Console](https://console.aws.amazon.com/)로에 로그인합니다. 다음 페이지에서 비밀번호를 입력합니다.

   루트 사용자를 사용하여 로그인하는 데 도움이 필요하면 *AWS Sign-In 사용 설명서*의 [루트 사용자로 로그인](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial)을 참조하세요.

1. 루트 사용자의 다중 인증(MFA)을 활성화합니다.

   지침은 *IAM 사용 설명서*의 [AWS 계정 루트 사용자(콘솔)에 대한 가상 MFA 디바이스 활성화를 참조하세요](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html).

**관리자 액세스 권한이 있는 사용자 생성**

1. IAM Identity Center를 활성화합니다.

   지침은 *AWS IAM Identity Center 사용 설명서*의 [AWS IAM Identity Center설정](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-set-up-for-idc.html)을 참조하세요.

1. IAM Identity Center에서 사용자에게 관리 액세스 권한을 부여합니다.

   를 자격 증명 소스 IAM Identity Center 디렉터리 로 사용하는 방법에 대한 자습서는 사용 *AWS IAM Identity Center 설명서*[의 기본값으로 사용자 액세스 구성을 IAM Identity Center 디렉터리](https://docs.aws.amazon.com/singlesignon/latest/userguide/quick-start-default-idc.html) 참조하세요.

**관리 액세스 권한이 있는 사용자로 로그인**
+ IAM IDentity Center 사용자로 로그인하려면 IAM Identity Center 사용자를 생성할 때 이메일 주소로 전송된 로그인 URL을 사용합니다.

  IAM Identity Center 사용자를 사용하여 로그인하는 데 도움이 필요하면 *AWS Sign-In 사용 설명서*[의 AWS 액세스 포털에 로그인](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html)을 참조하세요.

**추가 사용자에게 액세스 권한 할당**

1. IAM Identity Center에서 최소 권한 적용 모범 사례를 따르는 권한 세트를 생성합니다.

   지침은 *AWS IAM Identity Center 사용 설명서*의 [Create a permission set](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-started-create-a-permission-set.html)를 참조하세요.

1. 사용자를 그룹에 할당하고, 그룹에 Single Sign-On 액세스 권한을 할당합니다.

   지침은 *AWS IAM Identity Center 사용 설명서*의 [그룹 추가](https://docs.aws.amazon.com/singlesignon/latest/userguide/addgroups.html)를 참조하세요.

## 사용자에게 서비스 액세스 권한 할당
<a name="gettingstarted-prerequisites-permissions"></a>

역할 또는 사용자에게 `AWSOpsWorks_FullAccess` 및 `AmazonS3FullAccess` 권한을 추가하여 OpsWorks Stacks 서비스(및 OpsWorks Stacks가 의존하는 관련 서비스)에 대한 액세스를 활성화합니다.

권한 추가에 대한 자세한 내용은 [IAM 자격 증명 권한 추가(콘솔)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console)를 참조하세요.

이제 모든 설정 단계를 마쳤으므로 [이 안내서를 시작](gettingstarted-simple.md)할 수 있습니다.

# 2단계: 간단한 애플리케이션 서버 스택 생성 - Chef 11
<a name="gettingstarted-simple"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

기본 애플리케이션 서버 스택은 사용자 요청을 수신하기 위한 퍼블릭 IP 주소를 가진 단일 애플리케이션 서버 인스턴스로 구성됩니다. 애플리케이션 코드 및 관련 파일은 별도의 리포지토리에 저장되다가 서버로 배포됩니다. 다음 다이어그램은 이러한 스택을 보여줍니다.

![\[Diagram showing application server stack with users, internet, and AWS components.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/php_walkthrough_arch_2.png)


스택은 다음 구성 요소를 갖습니다.
+ *계층* - 인스턴스의 그룹을 나타내며 인스턴스 그룹을 어떻게 구성할지를 지정합니다.

  이 예제에서 계층은 PHP 앱 서버 인스턴스의 그룹을 나타냅니다.
+ Amazon EC2 *인스턴스*를 나타내는 인스턴스입니다.

  이 예제에서 인스턴스는 PHP 앱 서버를 실행하도록 구성됩니다. 계층에는 원하는 수의 인스턴스가 있을 수 있습니다. OpsWorks 스택은 다른 여러 앱 서버도 지원합니다. 자세한 내용은 [애플리케이션 서버 계층](workinglayers-servers.md) 단원을 참조하십시오.
+ *앱* - 애플리케이션 서버에 애플리케이션을 설치하는 데 필요한 정보를 포함합니다.

  코드는 원격 리포지토리(예: Git 리포지토리 또는 Amazon S3 버킷)에 저장됩니다.

다음 섹션에서는 OpsWorks Stacks 콘솔을 사용하여 스택을 생성하고 애플리케이션을 배포하는 방법을 설명합니다. CloudFormation 템플릿을 사용하여 스택을 프로비저닝할 수도 있습니다. 이 항목에서 설명하는 스택을 프로비저닝하는 템플릿 예제는 [AWS OpsWorks 조각](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-opsworks.html)을 참조하세요.

**Topics**
+ [2.1 단계: 스택 생성 - Chef 11](gettingstarted-simple-stack.md)
+ [2.2단계: PHP 앱 서버 계층 추가 - Chef 11](gettingstarted-simple-layer.md)
+ [2.3단계: PHP 앱 서버 계층에 인스턴스 추가 - Chef 11](gettingstarted-simple-instance.md)
+ [2.4단계: 앱 생성 및 배포 - Chef 11](gettingstarted-simple-app.md)

# 2.1 단계: 스택 생성 - Chef 11
<a name="gettingstarted-simple-stack"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

인스턴스 및 기타 리소스의 컨테이너 역할을 하는 스택을 생성하여 OpsWorks Stacks 프로젝트를 시작합니다. 스택 구성은 AWS 리전, 기본 운영 체제 등 스택의 모든 인스턴스가 공유하는 일부 기본 설정을 지정합니다.

**참고**  
이 페이지에서는 Chef 11 스택을 생성하는 방법을 설명합니다. Chef 12 스택을 생성하는 방법에 대한 자세한 정보는 [스택 생성](https://docs.aws.amazon.com/opsworks/latest/userguide/gettingstarted-intro-create-stack.html) 단원을 참조하세요.

이 페이지에서는 Chef 11에서 스택을 생성하는 방법을 설명합니다.

**새 스택을 생성하려면**

1. 

**stack 추가**

   [OpsWorks Stacks 콘솔](https://console.aws.amazon.com/opsworks/)에 로그인합니다. 계정에 기존 스택이 없는 경우에는 [**AWS OpsWorks 시작하기**] 페이지가 표시되는데 [**첫 번째 스택 추가**]를 클릭합니다. 그렇지 않으면 계정의 OpsWorks 스택을 나열하는 Stacks 대시보드가 표시됩니다. **스택 추가**를 클릭합니다.  
![\[스택이 없는 경우 OpsWorks Stacks 콘솔에 첫 번째 실행 페이지가 표시되고, 그렇지 않으면 계정의 모든 스택 목록이 표시됩니다.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/firstrun.png)

1. 

**스택 구성**

   [**스택 추가**] 페이지에서 [**Chef 11 스택**]을 선택하고 다음 설정을 지정합니다.  
**스택 이름**  
스택의 이름을 입력합니다. 이 이름에는 영숫자(a-z, A-Z 및 0-9) 및 하이픈(-)을 사용할 수 있습니다. 이 연습에서 사용되는 예제 스택의 이름은 **MyStack**입니다.  
**리전**  
스택 리전으로 미국 서부(오레곤)를 선택합니다.

   다른 설정에 대해서는 기본값을 수락하고 [**스택 추가**]를 클릭합니다. 다양한 스택 설정에 대한 자세한 정보는 [새 스택 생성](workingstacks-creating.md) 단원을 참조하세요.

# 2.2단계: PHP 앱 서버 계층 추가 - Chef 11
<a name="gettingstarted-simple-layer"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

스택은 기본적으로 인스턴스의 컨테이너이지만 인스턴스를 스택에 직접 추가하는 것은 아닙니다. 관련된 인스턴스의 그룹을 나타내는 계층을 추가한 후 인스턴스를 계층에 추가합니다.

계층은 기본적으로 OpsWorks Stacks가 동일한 구성으로 Amazon EC2 인스턴스 세트를 생성하는 데 사용하는 블루프린트입니다. 관련된 인스턴스의 그룹 각각에 대해 하나의 계층을 스택에 추가합니다. OpsWorks Stacks에는 MySQL 데이터베이스 서버 또는 PHP 애플리케이션 서버와 같은 표준 소프트웨어 패키지를 실행하는 인스턴스 그룹을 나타내는 기본 제공 계층 세트가 포함되어 있습니다. 또한 사용자가 특정 요구 사항에 맞춰 부분적으로 또는 완전히 사용자 지정된 계층을 생성할 수 있습니다. 자세한 내용은 [OpsWorks 스택 사용자 지정](customizing.md) 섹션을 참조하세요.

MyStack에는 PHP 애플리케이션 서버로 작동하는 인스턴스의 그룹을 나타내는 내장 PHP 앱 서버 계층 하나가 포함되어 있습니다. 내장 계층에 대한 설명을 포함하여 자세한 정보는 [계층](workinglayers.md) 단원을 참조하세요.

**MyStack에 PHP 앱 서버 계층을 추가하려면**

1. 

**계층 추가 페이지 열기**

   스택 생성을 완료하면 OpsWorks 스택에 **스택** 페이지가 표시됩니다. [**계층 추가**]를 클릭하여 첫 번째 계층을 추가합니다.  
![\[MyStack interface showing layers and instances sections with options to add components.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/gs2a.png)

1. 

**계층 유형 지정 및 계층 구성**

   **계층 유형** 상자에서 **PHP 앱 서버**를 선택하고 기본 **Elastic Load Balancer** 설정을 수락한 다음 **계층 추가**를 클릭합니다. 계층을 생성한 후에는 [계층을 편집](workinglayers-basics-edit.md)하여 EBS 볼륨 구성과 같은 다른 속성을 지정할 수 있습니다.  
![\[Add layer interface showing PHP App Server layer type selection and Elastic Load Balancer option.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/gs3.png)

# 2.3단계: PHP 앱 서버 계층에 인스턴스 추가 - Chef 11
<a name="gettingstarted-simple-instance"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

 OpsWorks Stacks 인스턴스는 특정 Amazon EC2 인스턴스를 나타냅니다.
+ 인스턴스의 구성은 Amazon EC2 운영 체제 및 크기와 같은 일부 기본 설정을 지정하며, 실행은 되지만 그다지 많은 역할을 수행하지는 않습니다.
+ 인스턴스의 계층은 설치할 패키지, 인스턴스가 탄력적 IP 주소를 갖는지 여부 등을 결정하여 인스턴스에 기능을 추가합니다.

OpsWorks Stacks는 서비스와 상호 작용하는 각 인스턴스에 에이전트를 설치합니다. 인스턴스에 계층의 기능을 추가하기 위해 OpsWorks Stacks는 에이전트에게 [Chef 레시피](http://docs.chef.io/recipes.html)라는 작은 애플리케이션을 실행하도록 지시합니다.이 레시피는 애플리케이션 및 패키지를 설치하고 구성 파일을 생성하는 등의 작업을 수행할 수 있습니다. OpsWorks Stacks는 인스턴스 [수명 주기의](workingcookbook-events.md) 주요 지점에서 레시피를 실행합니다. 예를 들어 OpsWorks는 인스턴스가 소프트웨어 설치와 같은 작업을 처리하기 위해 부팅을 완료하면 설정 레시피를 실행하고, 사용자가 코드 및 관련 파일을 설치하기 위해 앱을 배포할 때 Deploy 레시피를 실행합니다.

**참고**  
레시피의 작동 방식에 대해 궁금한 점이 있는 경우 모든 OpsWorks Stacks 기본 제공 레시피는 퍼블릭 GitHub 리포지토리인 [OpsWorks 쿡북에 있습니다](https://github.com/aws/opsworks-cookbooks). 또한 자체 사용자 지정 레시피를 생성하고, 나중에 설명하는 것처럼 OpsWorks Stacks가 이러한 레시피를 실행하게 할 수 있습니다.

MyStack에 PHP 애플리케이션 서버를 추가하려면 이전 단계에서 생성한 PHP 앱 서버 계층에 인스턴스를 추가합니다.

**PHP 앱 서버 계층에 인스턴스를 추가하려면**

1. 

**인스턴스 추가 열기**

   계층 추가를 완료하면 OpsWorks Stacks에 **계층 페이지가** 표시됩니다. 탐색 창에서 **인스턴스**를 클릭한 다음 **PHP 앱 서버**에서 **인스턴스 추가**를 클릭합니다.

1. 

**인스턴스 구성**

   각 인스턴스에는 OpsWorks Stacks에서 생성한 기본 호스트 이름이 있습니다. 이 예제에서 OpsWorks Stacks는 계층의 짧은 이름에 숫자를 추가하기만 하면 됩니다. 스택 생성 시 지정한 몇 가지 기본 설정(예: 가용 영역 또는 운영 체제) 재정의를 비롯하여 각 인스턴스를 개별적으로 구성할 수 있습니다. 이 연습의 경우 기본 설정을 수락하고 [**인스턴스 추가**]를 클릭하여 계층에 인스턴스를 추가합니다. 자세한 내용은 [인스턴스](workinginstances.md) 섹션을 참조하세요.  
![\[Form for adding a new PHP App Server instance with hostname, size, and subnet options.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/gs7.png)

1. 

**인스턴스 시작**

   지금까지 인스턴스의 구성을 지정했습니다. 실행 중인 Amazon EC2 인스턴스를 생성하려면 인스턴스를 시작해야 합니다. 그런 다음 OpsWorks Stacks는 구성 설정을 사용하여 지정된 가용 영역에서 Amazon EC2 인스턴스를 시작합니다. 자세한 인스턴스 시작 방법은 인스턴스의 *조정 유형*에 따라 다릅니다. 이전 단계에서는 기본 조정 유형인 *24/7*을 사용하여 인스턴스를 생성했습니다. 이 조정 유형은 수동으로 시작해야 하며 시작되면 수동으로 중지될 때까지 실행됩니다. OpsWorks Stacks가 일정 또는 현재 로드에 따라 자동으로 시작하고 중지하는 시간 기반 및 로드 기반 조정 유형을 생성할 수도 있습니다. 자세한 내용은 [시간 기반 또는 로드 기반 인스턴스를 사용하여 로드 관리](workinginstances-autoscaling.md) 단원을 참조하십시오.

   **PHP 앱 서버의** **php-app1**로 이동한 다음 행의 **작업** 열에서 **시작**을 클릭하여 인스턴스를 시작합니다.  
![\[PHP App Server instance list showing php-app1 stopped with start and delete options.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/gs8.png)

1. 

**시작 중 인스턴스의 상태 모니터링**

   Amazon EC2 인스턴스를 부팅하고 패키지를 설치하는 데는 일반적으로 몇 분 가량 소요됩니다. 시작 프로세스가 진행되는 동안 인스턴스의 [**상태**] 필드에 다음 값이 차례로 표시됩니다.

   1. **요청됨** - OpsWorks Stacks가 Amazon EC2 서비스를 호출하여 Amazon EC2 인스턴스를 생성했습니다.

   1. **pending** - OpsWorks Stacks가 Amazon EC2 인스턴스가 시작될 때까지 기다리고 있습니다.

   1. **booting** - Amazon EC2 인스턴스가 부팅 중입니다.

   1. **running\$1setup** - OpsWorks Stacks 에이전트가 패키지 구성 및 설치와 같은 작업을 처리하는 계층의 Setup 레시피와 인스턴스에 앱을 배포하는 Deploy 레시피를 실행하고 있습니다.

   1. **online** - 인스턴스를 사용할 준비가 되었습니다.

   php-app1이 온라인 상태가 되면 [**인스턴스**] 페이지의 모양은 다음과 같아야 합니다.  
![\[PHP App Server instance table showing php-app1 online with details like size and IP address.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/gs9.png)

   이 페이지는 스택의 모든 인스턴스에 대한 간단한 요약으로 시작합니다. 이제 이 페이지에 온라인 인스턴스가 하나 표시됩니다. php-app1 [**작업**] 열에서 인스턴스를 중지하는 [**중지**]가 [**시작**] 및 [**삭제**]로 바뀝니다.

# 2.4단계: 앱 생성 및 배포 - Chef 11
<a name="gettingstarted-simple-app"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

MyStack을 보다 유용하게 만들려면 PHP 앱 서버 인스턴스에 앱을 배포해야 합니다. 앱의 코드 및 관련 파일은 리포지토리(예: Git)에 저장합니다. 이러한 파일을 애플리케이션 서버로 보내기 위해서는 두 단계가 필요합니다.

**참고**  
이 섹션에서 설명하는 절차는 Chef 11 스택에 적용됩니다. Chef 12 스택에서 계층에 앱을 추가하는 방법에 대한 자세한 정보는 [앱 추가](workingapps-creating.md) 단원을 참조하세요.

1. 앱을 생성합니다.

   앱에는 OpsWorks 리포지토리에서 코드 및 관련 파일을 다운로드하는 데 필요한 정보가 포함되어 있습니다. 앱의 도메인과 같은 추가 정보를 지정할 수도 있습니다.

1. 애플리케이션 서버에 앱을 배포합니다.

   앱을 배포하면 OpsWorks Stacks가 배포 수명 주기 이벤트를 트리거합니다. 그러면 에이전트가 파일을 적절한 디렉터리로 다운로드하고 서버 구성, 서비스 재시작 등의 관련 작업을 수행하는 인스턴스의 Deploy 레시피를 실행합니다.

**참고**  
새 인스턴스를 생성하면 OpsWorks Stacks가 인스턴스에 기존 앱을 자동으로 배포합니다. 하지만 새 앱을 생성하거나 기존 앱을 업데이트하는 경우에는 수동으로 모든 기존 인스턴스에 앱을 배포하거나 업데이트해야 합니다.

이 단계는 수동으로 예제 앱을 퍼블릭 Git 리포지토리에서 애플리케이션 서버로 배포하는 방법을 보여줍니다. 애플리케이션을 검사하려면 [https://github.com/amazonwebservices/opsworks-demo-php-simple-app](https://github.com/amazonwebservices/opsworks-demo-php-simple-app)으로 이동하세요. 이 예제에서 사용되는 애플리케이션은 version1 브랜치에 있습니다. OpsWorks Stacks는 다른 여러 리포지토리 유형도 지원합니다. 자세한 내용은 [애플리케이션 소스](workingapps-creating.md#workingapps-creating-source) 단원을 참조하십시오.

**앱을 생성 및 배포하려면**

1. 

**앱 페이지 열기**

   탐색 창에서 [**앱**]을 클릭한 다음 [**앱**] 페이지에서 [**앱 추가**]를 클릭합니다.  
![\[Apps page showing no apps and an "Add an app" button with a brief description.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/gs13.png)

1. 

**앱 구성**

   [**앱**] 페이지에서 다음 값을 지정합니다.  
**이름**  
 OpsWorks Stacks가 표시 목적으로 사용하는 앱의 이름입니다. 예제 앱의 이름은 입니다**SimplePHPApp**. OpsWorks 스택은 또한이 예제에 대해 짧은 이름인 Simplephpapp을 생성합니다.이 이름은 나중에 설명하듯이 내부적으로 그리고 Deploy 레시피에 의해 사용됩니다.  
**Type**  
앱을 배포할 위치를 결정하는 앱 유형. 이 예제에서는 PHP 앱 서버 인스턴스에 앱을 배포하는 **PHP**를 사용합니다.  
**데이터 소스 유형**  
연결된 데이터베이스 서버. 지금은 [**없음**]을 선택합니다. 데이터베이스 서버에 대해서는 [3단계; 백엔드 데이터 스토어 추가](gettingstarted-db.md) 단원에서 소개합니다.  
**리포지토리 유형**  
앱의 리포지토리 유형. 이 예제의 앱은 **Git** 리포지토리에 저장됩니다.  
**리포지토리 URL**  
앱의 리포지토리 URL. 예제 URL은 **git://github.com/awslabs/opsworks-demo-php-simple-app.git**입니다.  
**브랜치/개정**  
앱의 브랜치 또는 버전. 연습의 이 부분에서는 **version1** 브랜치를 사용합니다.

   나머지 설정에 대해서는 기본값을 유지하고 [**앱 추가**]를 클릭합니다. 자세한 내용은 [앱 추가](workingapps-creating.md) 섹션을 참조하세요.  
![\[Add App form with settings for name, type, document root, data sources, and application source.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/gs14.png)

1. 

**배포 페이지 열기**

   서버에 코드를 설치하려면 앱을 *배포*해야 합니다. 이렇게 하려면 단순 PHPApp **작업** 열에서 **배포**를 클릭합니다.  
![\[Apps table showing SimplePHPApp with deploy, edit, and delete options in the Actions column.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/gs15.png)

1. 

**앱 배포**

   앱을 배포하면 에이전트는 애플리케이션을 다운로드하여 구성하는 Deploy 레시피를 PHP 앱 서버 인스턴스에서 실행합니다.

   [**명령**]은 이미 [**배포**]로 설정되어 있어야 합니다. 다른 설정은 기본값으로 유지하고 [**배포**]를 클릭하여 앱을 배포합니다.  
![\[Deploy app interface with settings for SimplePHPApp and instance selection options.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/gs16.png)

   배포가 완료되면 **배포** 페이지에 **성공** **상태**가 표시되고 **php-app1** 옆에 녹색 확인 표시가 나타납니다.

1. 

**SimplePHPApp 실행**

   이제 SimplePHPApp이 설치되어 실행할 준비가 되었습니다. 이 앱을 실행하려면 탐색 창에서 [**인스턴스**]를 클릭하여 [**인스턴스**]로 이동합니다. 그런 다음 php-app1 인스턴스의 퍼블릭 IP 주소를 클릭합니다.  
![\[PHP App Server instance details showing hostname, status, size, and public IP address.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/gs20.png)

   브라우저에 다음과 같은 페이지가 표시되어야 합니다.  
![\[Confirmation page for a simple PHP application running on AWS 클라우드 with PHP version 5.3.20.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/gs21.png)

**참고**  
이 연습에서는 사용자가 다음 섹션으로 이동하여 최종적으로 단일 세션에서 전체 연습을 완료하는 것으로 가정합니다. 원하는 경우 언제든지 OpsWorks Stacks에 로그인하고 스택을 열어 중지했다가 나중에 계속할 수 있습니다. 단, 사용하는 AWS 리소스(예: 온라인 인스턴스)에 대해 요금이 부과됩니다. 불필요한 요금이 부과되지 않도록 인스턴스를 중지할 수 있습니다. 그러면 해당하는 EC2 인스턴스가 종료됩니다. 계속할 준비가 되었을 때 인스턴스를 다시 시작할 수 있습니다.

# 3단계; 백엔드 데이터 스토어 추가
<a name="gettingstarted-db"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

[2.1 단계: 스택 생성 - Chef 11](gettingstarted-simple-stack.md)에서는 PHP 애플리케이션을 서비스하는 스택을 생성하는 방법을 설명했습니다. 하지만 이 애플리케이션을 일부 정적 텍스트를 표시하는 수준의 매우 간단한 애플리케이션이었습니다. 프로덕션 애플리케이션은 흔히 백엔드 데이터 스토어를 사용하며 다음과 비슷한 스택 구성을 보입니다.

![\[AWS OpsWorks stack architecture diagram showing PHP app, MySQL, and user interactions.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/php_walkthrough_arch_3.png)


이 섹션에서는 MyStack을 확장하여 백엔드 MySQL 데이터베이스 서버를 포함시키는 방법을 보여줍니다. 하지만 단순히 MySQL 서버를 스택에 추가하는 것보다는 많은 작업이 필요합니다. 또한 데이터베이스 서버와 제대로 통신하도록 앱을 구성해야 합니다. OpsWorks Stacks는이 작업을 대신 수행하지 않으므로 해당 작업을 처리하기 위해 일부 사용자 지정 레시피를 구현해야 합니다.

**Topics**
+ [3.1단계; 백엔드 데이터베이스 추가](gettingstarted-db-db.md)
+ [3.2단계: SimplePHPApp 업데이트](gettingstarted-db-update.md)
+ [간단한 차이: OpsWorks 쿡북, 레시피 및 스택 속성](gettingstarted-db-recipes.md)
+ [3.3단계: MyStack에 사용자 지정 쿡북 추가](gettingstarted-db-cookbooks.md)
+ [3.4단계: 레시피 실행](gettingstarted-db-lifecycle.md)
+ [3.5단계: SimplePHPApp 버전 2 배포](gettingstarted-db-deploy.md)
+ [3.6단계: SimplePHPApp 실행](gettingstarted-db-run.md)

# 3.1단계; 백엔드 데이터베이스 추가
<a name="gettingstarted-db-db"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

새로운 버전의 SimplePHPApp은 데이터를 백엔드 데이터베이스에 저장합니다. OpsWorks Stacks는 두 가지 유형의 데이터베이스 서버를 지원합니다.
+ [MySQL OpsWorks Stacks 계층](workinglayers-db-mysql.md)은 MySQL 데이터베이스 마스터를 호스팅하는 Amazon EC2 인스턴스를 생성하기 위한 청사진입니다.
+ Amazon RDS 서비스 계층은 [Amazon RDS 인스턴스](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html)를 스택으로 통합하는 방법을 제공합니다.

Amazon DynamoDB와 같은 다른 데이터베이스를 사용할 수도 있으며, [MongoDB](http://www.mongodb.org/)와 같은 데이터베이스를 지원하는 사용자 지정 계층을 생성할 수도 있습니다. 자세한 내용은 [백엔드 데이터 스토어 사용](customizing-rds.md) 섹션을 참조하세요.

이 예제에서는 MySQL 계층을 사용합니다.

**MyStack에 MySQL 계층을 추가하려면**

1. [**계층**] 페이지에서 [**\$1 계층**]을 클릭합니다.

1. [**계층 추가**] 페이지에서 [**계층 유형**]에 대해 [**MySQL**]을 선택하고, 기본 설정을 수락하고, [**계층 추가**]를 클릭합니다.  
![\[Add Layer interface for MySQL with options to set 루트 사용자 password and apply to all instances.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/gsb3.png)

**MySQL 계층에 인스턴스를 추가하려면**

1. [**계층**] 페이지의 [**MySQL**] 행에서 [**인스턴스 추가**]를 클릭합니다.

1. [**인스턴스**] 페이지의 [**MySQL**]에서 [**인스턴스 추가**]를 클릭합니다.

1. 기본값을 수락하고 [**인스턴스 추가**]를 클릭하되 아직 시작하지는 마십시오.

**참고**  
OpsWorks Stacks는이 예제에서 앱의 짧은 이름인 simplephpapp을 사용하여 라는 데이터베이스를 자동으로 생성합니다. [Chef 레시피](http://docs.chef.io/recipes.html)를 사용하여 데이터베이스와 상호 작용하려면 이 이름이 필요합니다.

# 3.2단계: SimplePHPApp 업데이트
<a name="gettingstarted-db-update"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

시작하려면 백엔드 데이터 스토어를 사용하는 새 버전의 SimplePHPApp이 필요합니다. OpsWorks Stacks에서는 애플리케이션을 업데이트하기가 쉽습니다. Git 또는 하위 버전 리포지토리를 사용하는 경우 각 앱 버전마다 다른 리포지토리 브랜치를 지정할 수 있습니다. 예제 앱에서는 백엔드 데이터베이스를 사용하는 앱 버전을 Git 리포지토리의 version2 브랜치에 저장합니다. 앱 구성을 업데이트하여 새 브랜치를 지정하고 앱을 재배포하기만 하면 됩니다.

**SimplePHPApp을 업데이트하려면**

1. 

**이 앱의 편집 페이지를 엽니다.**

   탐색 창에서 **앱**을 클릭한 다음 **SimplePhpApp** 행의 **작업** 열에서 **편집**을 클릭합니다.

1. 

**앱의 구성을 업데이트합니다.**

   다음 설정을 변경합니다.  
**브랜치/개정**  
이 설정은 앱의 리포지토리 브랜치를 나타냅니다. SimplePHPApp의 첫 번째 버전은 데이터베이스에 연결하지 않습니다. 앱의 데이터베이스 지원 버전을 사용하려면 이 값을 **version2**로 설정합니다.  
[**문서 루트**]  
이 설정은 앱의 루트 폴더를 지정합니다. SimplePHPApp의 첫 번째 버전에서는 기본 설정을 사용했습니다. 즉, `index.php`를 서버의 표준 루트 폴더(PHP의 경우 `/srv/www`)에 설치했습니다. 여기서 이름만 지정하고 선행 '/'는 지정하지 않는 하위 폴더를 지정하면OpsWorks 스택이 표준 폴더 경로에 추가합니다. SimplePHPApp의 버전 2는 `/srv/www/web`에 저장되어야 하므로 **문서 루트**를 **web**으로 설정합니다.  
**데이터 원본 유형**  
이 설정은 데이터베이스 서버를 앱과 연결합니다. 이 예제에서는 이전 단계에서 생성한 MySQL 인스턴스를 사용하므로 **데이터 원본 유형**을 OpsWorks로, **데이터베이스 인스턴스**를 이전 단계에서 생성한 인스턴스인 **db-master1(mysql)**로 설정합니다. **데이터베이스 이름을** 비워 둡니다. OpsWorks Stacks는 앱의 짧은 이름인 simplephpapp을 사용하여 라는 이름의 서버에 데이터베이스를 생성합니다.

   [**저장**]을 클릭하여 새로운 구성을 저장합니다.  
![\[Add App form with settings for SimplePHP application and OpsWorks data source.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/gsb2.png)

1. MySQL 인스턴스를 시작합니다.

앱을 업데이트하면 시작 시 OpsWorks Stacks가 새 앱 서버 인스턴스에 새 앱 버전을 자동으로 배포합니다. 그러나 OpsWorks Stacks는 기존 서버 인스턴스에 새 앱 버전을 자동으로 배포하지 않으므로에 설명된 대로 수동으로 배포해야 합니다[2.4단계: 앱 생성 및 배포 - Chef 11](gettingstarted-simple-app.md). 이제 업데이트된 SimplePHPApp을 배포할 수 있지만, 이 예제에서는 약간 기다리는 것이 좋습니다.

# 간단한 차이: OpsWorks 쿡북, 레시피 및 스택 속성
<a name="gettingstarted-db-recipes"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

이제 앱 및 데이터베이스 서버는 생성되었지만 사용할 준비가 되려면 아직 많은 작업이 필요합니다. 여전히 데이터베이스를 설정하고 앱의 연결 설정을 구성해야 합니다. OpsWorks Stacks는 이러한 작업을 자동으로 처리하지 않지만 Chef 쿡북, 레시피 및 동적 속성을 지원합니다. 한 쌍의 레시피, 즉 데이터베이스를 설정하는 레시피와 앱의 연결 설정을 구성하는 레시피를 구현하고 Stacks에서 자동으로 실행하도록 OpsWorks 할 수 있습니다.

필요한 레시피가 포함된 phpapp 쿡북이 이미 구현되어 사용 가능한 상태입니다. 원할 경우 [3.3단계: MyStack에 사용자 지정 쿡북 추가](gettingstarted-db-cookbooks.md) 섹션으 단원으로 건너뛸 수 있습니다. 자세히 알아보기를 원할 경우 이 섹션에서 쿡북 및 레시피에 대한 배경 지식을 제공하고 레시피가 작동하는 방식을 설명합니다. 쿡북 자체에 대해 알아보려면 [phpapp cookbook](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/phpapp) 단원을 참조하세요.

**Topics**
+ [레시피와 속성](#gettingstarted-db-recipes-attributes)
+ [데이터베이스 설정](#gettingstarted-db-recipes-dbsetup)
+ [데이터베이스에 애플리케이션 연결](#gettingstarted-db-recipes-appsetup)

## 레시피와 속성
<a name="gettingstarted-db-recipes-attributes"></a>

Chef 레시피는 기본적으로 패키지 설치, 구성 파일 생성, shell 명령 실행 등 인스턴스에 대한 작업을 수행하는 특수한 Ruby 애플리케이션입니다. 관련된 레시피의 그룹은 *쿡북*으로 구성됩니다. 여기에는 구성 파일을 생성하기 위한 템플릿과 같은 지원 파일도 포함됩니다.

OpsWorks Stacks에는 내장 계층을 지원하는 쿡북 세트가 있습니다. 인스턴스에 대한 사용자 지정 작업을 수행하기 위해 자체 레시피로 구성된 사용자 지정 쿡북을 생성할 수도 있습니다. 이 주제에서는 레시피를 간략히 소개하고 레시피를 사용하여 데이터베이스를 설정하고 앱의 연결 설정을 구성하는 방법을 살펴봅니다. 쿡북 및 레시피에 대한 자세한 정보는 [쿡북과 레시피](workingcookbook.md) 또는 [OpsWorks 스택 사용자 지정](customizing.md) 단원을 참조하세요.

레시피는 일반적으로 Chef *속성*을 입력 데이터로 사용합니다.
+ 일부 속성은 Chef에 의해 정의되며 운영 체제와 같이 인스턴스에 대한 기본 정보를 제공합니다.
+ OpsWorks Stacks는 계층 구성과 같은 스택과 앱 리포지토리와 같은 배포된 앱에 대한 정보를 포함하는 속성 세트를 정의합니다.

  [사용자 지정 JSON](workingstacks-json.md)을 스택 또는 배포에 할당하여 여기에 사용자 지정 속성을 추가할 수 있습니다.
+ 또한 쿡북에서 쿡북 고유 속성을 정의할 수 있습니다.

  phpapp 쿡북 속성은 `attributes/default.rb`에서 정의됩니다.

 OpsWorks Stacks 속성의 전체 목록은 [스택 구성 및 배포 속성: Linux](attributes-json-linux.md) 및 섹션을 참조하세요[내장 쿡북 속성](attributes-recipes.md). 자세한 내용은 [속성 재정의](workingcookbook-attributes.md) 단원을 참조하십시오.

속성은 계층 구조로 구성되며, JSON 객체로 표현될 수 있습니다.

다음과 같이 Chef 노드 구문을 사용하여 이 데이터를 애플리케이션에 통합합니다.

```
[:deploy][:simplephpapp][:database][:username]
```

`deploy` 노드에는 앱의 데이터베이스, Git 리포지토리 등에 대한 정보를 포함하는 단일 앱 노드 `simplephpapp`이 있습니다. 예제는 데이터베이스 사용자 이름의 값을 나타냅니다. 이 값은 `root`로 확인됩니다.

## 데이터베이스 설정
<a name="gettingstarted-db-recipes-dbsetup"></a>

MySQL 계층의 내장 설정 레시피는 앱의 짧은 이름으로 명명된 데이터베이스를 자동으로 생성합니다. 그러므로 이 예제를 위해 simplephpapp이라는 데이터베이스가 이미 생성되어 있습니다. 하지만 앱이 데이터를 저장할 테이블을 생성하여 설정을 마쳐야 합니다. 테이블을 수동으로 생성할 수 있지만 더 좋은 방법은 작업을 처리하기 위해 사용자 지정 레시피를 구현하고 OpsWorks Stacks에서 실행하도록 하는 것입니다. 이 섹션에서는 어떻게 레시피 `dbsetup.rb`가 구현되는지 설명합니다. Stacks가 레시피를 실행하도록 OpsWorks 하는 절차는 나중에 설명합니다.

리포지토리의 레시피를 보려면 [db설정.rb](https://github.com/amazonwebservices/opsworks-example-cookbooks/blob/master/phpapp/recipes/dbsetup.rb)를 참조하세요. 다음 예제는 `dbsetup.rb` 코드를 보여줍니다.

`execute`는 지정된 명령을 실행하는 *Chef 리소스*입니다. 여기서는 테이블을 생성하는 MySQL 명령입니다. `not_if` 명령은 지정된 테이블이 이미 존재할 경우 명령이 실행되지 않게 합니다. Chef 리소스에 대한 자세한 정보는 [About Resources and Providers](https://docs.chef.io/resource.html)를 참조하세요.

레시피는 앞서 설명한 노드 구문을 사용하여 속성 값을 명령 문자열에 삽입합니다. 예를 들어 다음 레시피는 데이터베이스의 사용자 이름을 삽입합니다.

```
#{deploy[:database][:username]}
```

약간은 퍼즐 같은 이 코드를 풀어 보겠습니다.
+ 각 반복에서, `deploy`는 현재 앱 노드로 설정됩니다. 따라서 `[:deploy][:app_name]`으로 확인됩니다. 이 예제에서는 `[:deploy][:simplephpapp]`으로 확인됩니다.
+ 앞서 제시한 배포 속성 값을 사용하여 전체 노드가 `root`로 확인됩니다.
+ 노드를 \$1\$1 \$1로 묶어 문자열에 삽입합니다.

다른 노드도 대부분 비슷한 방식으로 확인됩니다. `#{node[:phpapp][:dbtable]}`은 예외입니다. 이 노드는 사용자 지정 쿡북의 속성 파일에 의해 정의되며 테이블 이름 `urler`로 확인됩니다. 따라서 MySQL 인스턴스에 실행되는 실제 명령은 다음과 같습니다.

```
"/usr/bin/mysql 
    -uroot
    -pvjud1hw5v8
    simplephpapp
    -e'CREATE TABLE urler(
       id INT UNSIGNED NOT NULL AUTO_INCREMENT,
       author VARCHAR(63) NOT NULL,
       message TEXT,
       PRIMARY KEY (id))'
"
```

이 명령은 배포 속성의 자격 증명 및 데이터베이스 이름을 사용하여 id, author 및 message 필드를 포함하는 테이블 `urler`을 생성합니다.

## 데이터베이스에 애플리케이션 연결
<a name="gettingstarted-db-recipes-appsetup"></a>

퍼즐의 두 번째 부분은 테이블에 액세스하기 위해 데이터베이스 암호 같은 연결 정보가 필요한 애플리케이션입니다. SimplePHPApp은 작업 파일이 `app.php` 하나뿐입니다. `index.php`가 수행하는 작업은 `app.php`를 로드하는 것 뿐입니다.

`app.php`에는 데이터베이스 연결을 처리하는 `db-connect.php`가 포함됩니다. 하지만 이 파일은 리포지토리에 없습니다. `db-connect.php`를 미리 생성할 수는 없습니다. 이 파일은 특정 인스턴스를 기반으로 데이터베이스를 정의하기 때문입니다. 그 대신, `appsetup.rb` 레시피가 배포 속성의 연결 데이터를 사용하여 `db-connect.php`를 생성합니다.

리포지토리의 레시피를 보려면 [app설정.rb](https://github.com/amazonwebservices/opsworks-example-cookbooks/blob/master/phpapp/recipes/appsetup.rb)를 참조하세요. 다음 예제는 `appsetup.rb` 코드를 보여줍니다.

`dbsetup.rb`처럼, `appsetup.rb`는 `deploy` 노드에 있는 앱을 반복합니다. 다시 말하지만 단순한 phappapp일 뿐입니다. 이 레시피는 `script` 리소스 및 `template` 리소스를 포함하는 코드 블록을 실행합니다.

이 `script` 리소스는 PHP 애플리케이션용 종속성 관리자인 [Composer](http://www.getcomposer.org)를 설치합니다. 그런 다음 Composer의 `install` 명령을 실행하여 샘플 애플리케이션의 종속 파일을 앱의 루트 디렉터리에 설치합니다.

`template` 리소스는 `db-connect.php`를 생성하여 `/srv/www/simplephpapp/current`에 저장합니다. 다음 사항에 유의하세요.
+ 이 레시피는 조건문을 사용하여 인스턴스의 운영 체제에 따라 달라지는 파일 소유자를 지정합니다.
+ `only_if` 명령은 Chef에게 지정된 디렉터리가 존재하는 경우에만 템플릿을 생성하도록 지시합니다.

`template` 리소스는 연결된 파일과 기본적으로 콘텐츠 및 구조가 동일한 템플릿에서 작동하지만 다양한 데이터 값을 위한 자리 표시자를 포함합니다. `source` 파라미터는 phpapp 쿡북의 `db-connect.php.erb` 디렉터리에 위치하는 템플릿 `templates/default`를 지정하며 다음을 포함합니다.

Chef가 템플릿을 처리할 때 `<%= =>` 자리 표시자를 템플릿 리소스 해당 변수의 값으로 바꿉니다. 이들 값은 배포 속성에서 가져온 것입니다. 생성된 파일은 다음과 같습니다.

# 3.3단계: MyStack에 사용자 지정 쿡북 추가
<a name="gettingstarted-db-cookbooks"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

사용자 지정 쿡북은 리포지토리에 앱과 거의 마찬가지로 저장합니다. 각 스택은 일련의 사용자 지정 쿡북으로 구성된 리포지토리를 가질 수 있습니다. 그런 다음 Stacks에 스택의 인스턴스에 사용자 지정 OpsWorks 쿡북을 설치하도록 지시합니다.

1. 탐색 창에서 [**스택**]을 클릭하여 현재 스택에 대한 페이지를 표시합니다.

1. [**스택 설정**]을 클릭하고 [**편집**]을 클릭합니다.

1. 스택 구성을 다음과 같이 수정합니다.
   + **사용자 지정 Chef 쿡북 사용** – **예**
   + **Repository type** - **Git**
   + **리포지토리 URL** – **git://github.com/amazonwebservices/opsworks-example-cookbooks.git**

1. [**저장**]을 클릭하여 스택 구성을 업데이트합니다.  
![\[Configuration options for custom Chef cookbooks with Git repository settings.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/gsb6.png)

OpsWorks 그런 다음 Stacks는 스택의 모든 인스턴스에 쿡북 리포지토리의 콘텐츠를 설치합니다. 새 인스턴스를 생성하면 OpsWorks Stacks가 쿡북 리포지토리를 자동으로 설치합니다.

**참고**  
쿡북을 업데이트하거나 리포지토리에 새 쿡북을 추가해야 하는 경우 스택 설정을 터치하지 않고도 쿡북을 추가할 수 있습니다. OpsWorks Stacks는 업데이트된 쿡북을 모든 새 인스턴스에 자동으로 설치합니다. 그러나 OpsWorks Stacks는 스택의 온라인 인스턴스에 업데이트된 쿡북을 자동으로 설치하지 않습니다. 스택 명령을 실행하여 OpsWorks 쿡북을 업데이트하도록 `Update Cookbooks` Stacks에 명시적으로 지시해야 합니다. 자세한 내용은 [스택 명령 실행](workingstacks-commands.md) 단원을 참조하십시오.

# 3.4단계: 레시피 실행
<a name="gettingstarted-db-lifecycle"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

사용자 지정 쿡북이 준비되었으면 적절한 인스턴스에서 레시피를 실행해야 합니다. 레시피를 [수동으로 실행](workingcookbook-manual.md)할 수 있습니다. 하지만 일반적으로 레시피는 인스턴스의 수명 주기에서 인스턴스 부팅 후 또는 앱 배포 시와 같은 예측 가능한 시점에 실행해야 합니다. 이 섹션에서는 훨씬 더 간단한 접근 방식을 설명합니다. OpsWorks Stacks가 적절한 시간에 자동으로 실행하도록 합니다.

OpsWorks Stacks는 실행 중인 레시피를 단순화하는 수명 [주기 이벤트](workingcookbook-events.md) 세트를 지원합니다. 예를 들어 설정 이벤트는 인스턴스 부팅이 완료된 후 발생하고, Deploy 이벤트는 앱을 배포할 때 발생합니다. 각 계층에는 각 수명 주기 이벤트에 연결된 내장 레시피 세트가 있습니다. 인스턴스에서 수명 주기 이벤트가 발생하면 에이전트가 인스턴스의 각 계층에서 연결된 레시피를 실행합니다. Stacks가 사용자 지정 레시피를 자동으로 실행하도록 OpsWorks 하려면 해당 계층의 적절한 수명 주기 이벤트에 추가하면 기본 제공 레시피가 완료된 후 에이전트가 레시피를 실행합니다.

이 예제에서는 두 개의 레시피를 실행해야 합니다. 즉 MySQL 인스턴스에서 `dbsetup.rb`, PHP 앱 서버 인스턴스에서 `appsetup.rb`를 실행합니다.

**참고**  
콘솔에서 *cookbook\$1name*::*recipe\$1name* 형식을 사용하여 레시피를 지정합니다. 여기서 *recipe\$1name*에는 .rb 확장자가 포함되지 않습니다. 예를 들어 `dbsetup.rb`를 **phpapp::dbsetup**으로 참조합니다.

**수명 주기 이벤트에 사용자 지정 레시피를 할당하려면**

1. **계층** 페이지에서 MySQL에 대해 **레시피**를 클릭하고 **편집**을 클릭합니다.

1.  **사용자 지정 Chef 레시피** 섹션에서 **배포**에 [**phpapp::dbsetup**](gettingstarted-db-recipes.md#gettingstarted-db-recipes-dbsetup)를 입력합니다.  
![\[Custom Chef recipes section with Repository URL and three configuration steps.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/gsb6a.png)

1. [**\$1**] 아이콘을 클릭하여 이벤트에 레시피를 할당하고 [**저장**]을 클릭하여 새 계층 구성을 저장합니다.

1. **계층** 페이지로 돌아가 해당 절차를 반복하여 **phpapp::appsetup**을 **PHP 앱 서버** 계층의 **배포** 이벤트에 할당합니다.

# 3.5단계: SimplePHPApp 버전 2 배포
<a name="gettingstarted-db-deploy"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

마지막 단계는 새 버전의 SimplePHPApp을 배포하는 것입니다.

**SimplePHPApp을 배포하려면**

1. **앱** 페이지의 **SimplePHPApp** 앱의 **작업**에서 **배포**를 클릭합니다.  
![\[Apps page showing SimplePHPApp with deploy, edit, and delete options in the Actions column.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/gsb6aa.png)

1. 기본값을 수락하고 [**배포**]를 클릭합니다.  
![\[Deploy App interface with settings for SimplePHPApp and instance selection options.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/gs17a.png)

   **앱 배포** 페이지에서 **배포**를 클릭하면 배포 수명 주기 이벤트가 트리거되어 에이전트에게 배포 레시피를 실행하도록 알립니다. 기본적으로 스택의 모든 인스턴스에서 이 이벤트를 트리거합니다. 내장 Deploy 레시피는 앱 유형에 적절한 인스턴스(이 경우에는 PHP 앱 서버 인스턴스)에만 앱을 배포합니다. 그러나 일반적으로 다른 인스턴스에서 Deploy 이벤트를 트리거하여 앱 배포에 응답하도록 하는 데에도 유용합니다. 이 경우에는 MySQL 인스턴스에서도 Deploy를 트리거하여 데이터베이스를 설정하려고 할 수도 있습니다.

   다음 사항에 유의하세요.
   + PHP 앱 서버 인스턴스의 에이전트는 계층의 내장 레시피를 실행하고 뒤이어 앱의 데이터베이스 연결을 구성하는 `appsetup.rb`를 실행합니다.
   + MySQL 인스턴스의 에이전트는 어떠한 것도 설치하지 않지만 `dbsetup.rb`를 실행하여 urler 테이블을 생성합니다.

   배포가 완료되면 **배포** 페이지의 **상태**가 **성공**으로 변경됩니다.

# 3.6단계: SimplePHPApp 실행
<a name="gettingstarted-db-run"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

배포 상태가 [**성공**]으로 전환되면 다음과 같이 새 SimplePHPApp 버전을 실행할 수 있습니다.

**SimplePHPApp을 실행하려면**

1. [**인스턴스**] 페이지의 [**php-app1**] 행에서 퍼블릭 IP 주소를 클릭합니다.

   브라우저에 다음 페이지가 표시되어야 합니다.  
![\[Text input field labeled "Your Thoughts" with a "Share Your Thought" button above.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/gsb7.png)

1. **생각 공유하기**를 클릭하고 **생각**에는 **Hello world\$1**을 입력하고 **이름**에는 이름을 입력하세요. 그런 다음 [**의견 제출**]을 클릭하여 데이터베이스에 메시지를 추가합니다.  
![\[Form with success message, text input fields for thought and name, and submit buttons.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/gsb8.png)

1. [**뒤로 이동**]을 클릭하여 데이터베이스의 메시지를 모두 확인합니다.

# 4단계: MyStack 확장
<a name="gettingstarted-scale"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

현재 MyStack은 애플리케이션 서버가 하나뿐입니다. 프로덕션 스택에서는 수신 트래픽을 처리하기 위한 애플리케이션 서버 여러 개와 수신 트래픽을 애플리케이션 서버 간에 균일하게 분산시킬 로드 밸런서가 필요할 수 있습니다. 아키텍처는 다음과 같습니다.

![\[AWS OpsWorks stack architecture with load balancer, application servers, and RDS instance.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/php_walkthrough_arch_4.png)


OpsWorks 스택을 사용하면 스택을 쉽게 확장할 수 있습니다. 이 섹션에서는 MyStack에 두 번째 24/7 PHP 앱 서버 인스턴스를 추가하고 두 인스턴스 모두 Elastic Load Balancing 로드 밸런서 뒤에 배치하여 스택을 확장하는 기본적인 방법을 설명합니다. 절차를 쉽게 확장하여 임의의 수의 24/7 인스턴스를 추가하거나 시간 기반 또는 로드 기반 인스턴스를 사용하여 OpsWorks Stacks가 스택을 자동으로 확장하도록 할 수 있습니다. 자세한 내용은 [시간 기반 또는 로드 기반 인스턴스를 사용하여 로드 관리](workinginstances-autoscaling.md) 단원을 참조하십시오.

# 4.1단계: 로드 밸런서 추가
<a name="gettingstarted-scale-elb"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

Elastic Load Balancing은 수신 애플리케이션 트래픽을 여러 Amazon EC2 인스턴스에 자동으로 분산하는 AWS 서비스입니다. 트래픽을 분산하는 것에 더하여 Elastic Load Balancing은 다음 기능을 수행합니다.
+ 비정상 Amazon EC2 인스턴스를 탐지합니다.

  또한 비정상 인스턴스가 복원될 때까지 트래픽을 나머지 정상 인스턴스로 다시 라우팅합니다.
+ 수신 트래픽에 맞춰 요청 처리 용량을 자동으로 조정합니다.

**참고**  
로드 밸런서는 두 가지 목적을 충족할 수 있습니다. 명백한 목적은 애플리케이션 서버 간에 로드를 평활화하는 것입니다. 또한 대부분의 사이트에서는 애플리케이션 서버 및 데이터베이스를 직접 사용자 액세스로부터 격리하기를 선호합니다. OpsWorks Stacks를 사용하면 다음과 같이 퍼블릭 및 프라이빗 서브넷이 있는 Virtual Private Cloud(VPC)에서 스택을 실행하여이 작업을 수행할 수 있습니다.  
애플리케이션 서버 및 데이터베이스를 프라이빗 서브넷에 배치합니다. 그러면 VPC 내 다른 인스턴스는 이들에 액세스할 수 있지만 사용자는 액세스할 수 없습니다.
사용자 트래픽을 퍼블릭 서브넷의 로드 밸런서로 보냅니다. 그러면 로드 밸런서가 프라이빗 서브넷의 애플리케이션 서버로 트래픽을 전달하고 응답을 사용자에게 반환합니다.
자세한 내용은 [VPC에서 스택 실행](workingstacks-vpc.md) 단원을 참조하십시오. 이 연습의 예제를 VPC에서 실행하도록 확장하는 CloudFormation 템플릿의 경우 [`OpsWorksVPCtemplates.zip` 파일을](samples/OpsWorksVPCtemplates.zip) 다운로드합니다.

Elastic Load Balancing은 종종 계층으로 불리지만 다른 내장 계층과는 약간 다르게 작동합니다. 계층을 생성하고 여기에 인스턴스를 추가하는 대신 Amazon EC2 콘솔을 사용하여 Elastic Load Balancing 로드 밸런서를 생성한 다음 기존 계층 중 하나, 일반적으로 애플리케이션 서버 계층에 연결합니다. 그런 다음 OpsWorks Stacks는 계층의 기존 인스턴스를 서비스에 등록하고 새 인스턴스를 자동으로 추가합니다. 다음 절차에서는 로드 밸런서를 MyStack의 PHP 앱 서버 계층에 추가하는 방법을 설명합니다.

**참고**  
OpsWorks Stacks는 Application Load Balancer를 지원하지 않습니다. Classic Load Balancer는 OpsWorks Stacks에서만 사용할 수 있습니다.

**PHP 앱 서버 계층에 로드 밸런서를 연결하려면**

1. Amazon EC2 콘솔을 사용하여 MyStack의 새 로드 밸런서를 생성합니다. 사용자 계정에서 EC2 Classic을 지원하는지 여부에 따라 세부 정보가 달라집니다. 자세한 내용은 [Elastic Load Balancing 시작하기](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/load-balancer-getting-started.html)를 참조하세요. [**로드 밸런서 생성**] 마법사를 실행하면 다음과 같이 로드 밸런서를 구성합니다.  
**로드 밸런서 정의**  
Stacks 콘솔에서 쉽게 찾을 수 있도록 로드 OpsWorks 밸런서에 PHP-LB와 같이 쉽게 알아볼 수 있는 이름을 할당합니다. [**계속**]을 선택하여 나머지 설정에 대해서는 기본값을 수락합니다.  
[**LB 내부 생성**] 메뉴에서 서브넷이 하나 이상 있는 VPC를 선택한 경우 로드 밸런서를 통해 트래픽을 라우트하려는 각 가용 영역의 서브넷을 선택해야 합니다.  
**보안 그룹 할당**  
사용자 계정에서 기본 VPC를 지원하는 경우 마법사에 이 페이지가 표시되어 로드 밸런서의 보안 그룹을 확인합니다. EC2 Classic의 경우에는 이 페이지가 표시되지 않습니다.  
이 연습에서는 [**기본 VPC 보안 그룹**]을 선택합니다.  
**보안 설정을 구성합니다**  
**로드 밸런서 정의 페이지**에서 **로드 밸런서 프로토콜**로 **HTTPS**를 선택한 경우 이 페이지에서 인증서, 암호 및 SSL 프로토콜 설정을 구성하세요. 이 연습에서는 기본값을 수락하고 [**상태 검사 구성**]을 선택합니다.  
**상태 확인 구성**  
ping 경로를 **/**로 설정하고 나머지 설정에 대해 기본값을 수락합니다.  
**EC2 인스턴스 추가**  
**계속**을 선택합니다. OpsWorks 스택은 로드 밸런서에 인스턴스를 자동으로 등록합니다.  
**태그 추가**  
찾은 도움말에 태그를 추가합니다. 각 태그는 키-값 페어입니다. 예를 들어 이 연습에서는 **Description**을 키로 **Test LB**를 값으로 지정할 수 있습니다.  
**검토**  
선택 항목을 검토하고 [**만들기**]를 선택한 다음 [**닫기**]를 선택합니다. 그러면 로드 밸런서가 시작됩니다.

1. 계정이 기본 VPC를 지원하는 경우 로드 밸런서를 시작한 후 로드 밸런서의 보안 그룹에 적절한 수신 규칙이 있는지 확인해야 합니다. 기본 규칙은 어떠한 인바운드 트래픽도 허용하지 않습니다.

   1. Amazon EC2 탐색 창에서 **보안 그룹**을 선택합니다.

   1. [**기본 VPC 보안 그룹**]을 선택합니다.

   1. **인바운드** 탭에서 **편집**을 선택합니다.

   1. 이 연습에서는 **Source**를 **Anywhere**로 설정합니다. 그러면 로드 밸런서에 모든 IP 주소에서의 수신 트래픽을 허용하도록 지시합니다.

1.  OpsWorks Stacks 콘솔로 돌아갑니다. [**계층**] 페이지에서 계층의 [**네트워크**] 링크를 클릭한 다음 [**편집**]을 클릭합니다.

1. [**Elastic Load Balancing**]에서 1단계에서 생성한 로드 밸런서를 선택한 다음 [**저장**]을 선택합니다.  
![\[Dropdown menu for Elastic Load Balancer selection with options "Available ELBs" and "None".\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/elb_select.png)

   로드 밸런서를 계층에 연결한 후 OpsWorks Stacks는 계층의 현재 인스턴스를 자동으로 등록하고 온라인 상태가 되면 새 인스턴스를 추가합니다.

1. [**계층**] 페이지에서 로드 밸런서의 이름을 클릭하여 로드 밸런서의 세부정보 페이지를 엽니다. 등록이 완료되고 인스턴스가 상태 확인을 통과하면 OpsWorks Stacks는 로드 밸런서 페이지의 인스턴스 옆에 녹색 확인 표시를 표시합니다.  
![\[Elastic Load Balancing details page showing one EC2 instance in US-west-2a with InService status.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/elb_properties3.png)

이제 로드 밸런서로 요청을 전송하여 SimplePHPApp을 실행할 수 있습니다.

**로드 밸런서를 통해 SimplePHPApp을 실행하려면**

1. 아직 열지 않은 경우 로드 밸런서의 세부 정보 페이지를 엽니다.

1. 속성 페이지에서 인스턴스의 상태 확인 상태를 확인하고 로드 밸런서의 DNS 이름을 클릭하여 SimplePHPApp을 실행합니다. 로드 밸런서는 PHP 앱 서버 인스턴스에 요청을 전달하고 응답을 반환합니다. 이 응답은 PHP 앱 서버 인스턴스의 퍼블릭 IP 주소를 클릭했을 때 얻는 응답과 정확히 동일해야 합니다.  
![\[Elastic Load Balancing settings showing DNS name for PHP-LB in US West region.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/elb_properties2.png)

**참고**  
OpsWorks 또한 Stacks는 HAProxy 로드 밸런서를 지원하므로 일부 애플리케이션에는 이점이 있을 수 있습니다. 자세한 내용은 [HAProxy OpsWorks 스택 계층](layers-haproxy.md) 단원을 참조하십시오.

# 4.2단계: PHP 앱 서버 인스턴스 추가
<a name="gettingstarted-scale-instances"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

이재 로드 밸런서가 설치되었으므로 PHP 앱 서버 계층에 더 많은 인스턴스를 추가하여 스택을 확장할 수 있습니다. 사용자 관점에서 작업은 심리스합니다. 새 PHP 앱 서버 인스턴스가 온라인 상태가 될 때마다 OpsWorks Stacks는 자동으로 이를 로드 밸런서에 등록하고 SimplePHPApp을 배포하므로 서버가 수신 트래픽 처리를 즉시 시작할 수 있습니다. 간략한 설명을 위해 이 항목에PHP 앱 서버서는 인스턴스 하나를 추가하는 방법을 설명하지만, 동일한 접근 방식을 사용하여 원하는 만큼 인스턴스를 추가할 수 있습니다.

**PHP 앱 서버 계층에 다른 인스턴스를 추가하려면**

1. 인스턴스 페이지의 **PHP 앱 서버**에서 **\$1 인스턴스**를 클릭합니다.

1. 기본 설정을 수락하고 [**인스턴스 추가**]를 클릭합니다.

1. [**시작**]을 클릭하여 인스턴스를 시작합니다.

# 4.3단계: MyStack 모니터링
<a name="gettingstarted-scale-monitor"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

OpsWorks Stacks는 Amazon CloudWatch를 사용하여 스택에 대한 지표를 제공하고 사용자의 편의를 위해 **모니터링** 페이지에 이를 요약합니다. 전체 스택, 지정된 계층 또는 지정된 인스턴스에 대한 측정치를 볼 수 있습니다.

**MyStack을 모니터링하려면**

1. 탐색 창에서 [**모니터링**]을 클릭합니다. 그러면 각 계층에 대한 평균 측정치와 함께 일련의 그래프가 표시됩니다. [**CPU 시스템**], [**사용 메모리**] 및 [**로드**]에 대한 메뉴를 사용해 여러 가지 관련 측정치를 표시할 수 있습니다.  
![\[Monitoring dashboard showing CPU, memory, load, and process metrics over time for system layers.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/monitor_stack.png)

1. [**PHP 앱 서버**]를 클릭하면 계층의 각 인스턴스에 대한 측정치가 표시됩니다.  
![\[Dashboard showing CPU, memory, load, and processes metrics for Layer PHP App Server over time.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/monitor_layer.png)

1. [**php-app1**]를 클릭하면 해당 인스턴스에 대한 측정치가 표시됩니다. 슬라이드를 이동하면 특정 시점에 대한 측정치를 볼 수 있습니다.  
![\[Dashboard showing CPU, memory, load, and process metrics for a PHP application instance.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/monitor_instance.png)

**참고**  
OpsWorks 또한 Stacks는 Ganglia 모니터링 서버를 지원하므로 일부 애플리케이션에는 이점이 있을 수 있습니다. 자세한 내용은 [Ganglia 계층](workinglayers-ganglia.md) 단원을 참조하십시오.

# 5단계: MyStack 삭제
<a name="gettingstarted-delete"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

Amazon EC2 인스턴스와 같은 AWS 리소스를 사용하기 시작하는 순간부터 사용량에 따라 요금이 부과됩니다. 잠시 동안 사용하지 않을 경우 원치 않는 요금이 발생하지 않도록 인스턴스를 중지해야 합니다. 스택이 더 이상 필요하지 않으면 삭제할 수 있습니다.

**MyStack을 삭제하려면**

1. 

**모든 인스턴스 중지**

   [**인스턴스**] 페이지에서 [**모든 인스턴스 중지**]를 클릭하고, 작업을 확인하라는 메시지가 표시되면 [**중지**]를 클릭합니다.  
![\[Confirmation dialog asking if user wants to stop the stack, warning about data loss.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/gse1.png)

   **중지**를 클릭하면 OpsWorks Stacks는 연결된 Amazon EC2 인스턴스를 종료하지만 탄력적 IP 주소 또는 Amazon EBS 볼륨과 같은 연결된 리소스는 종료하지 않습니다.

1. 

**모든 인스턴스 삭제**

   인스턴스를 종료하면 연결된 Amazon EC2 인스턴스만 종료됩니다. 인스턴스가 중지됨 상태가 된 뒤에는 각각의 인스턴스를 삭제해야 합니다. **PHP 앱 서버** 계층의 php-app1 인스턴스의 **작업** 열에서 **삭제**를 클릭합니다.  
![\[PHP App Server table showing two instances with status, size, and actions including delete option.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/gse2.png)

   OpsWorks 그러면 Stacks가 삭제 확인을 요청하고 종속 리소스를 표시합니다. 이러한 리소스 중 일부 또는 전부를 유지하도록 설정할 수 있습니다. 이 예에는 종속 리소스가 없으므로 [**삭제**]를 클릭하기만 하면 됩니다.

   php-app2 및 [**MySQL**] 인스턴스인 db-master1에 대해 이 프로세스를 반복합니다. db-master1에는 연결된 Amazon Elastic Block Store 볼륨이 기본적으로 선택되어 있습니다. 선택된 상태로 두면 이 볼륨이 인스턴스와 함께 삭제됩니다.

1. 

**계층 삭제**

   [**계층**] 페이지에서 [**삭제**]를 클릭한 다음 [**삭제**]를 클릭하여 확인합니다.  
![\[PHP App Server layer with options for General Settings, Recipes, Network, EBS Volumes, and Security.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/gse4.png)

   **MySQL** 계층에 대해 이 프로세스를 반복합니다.

1. 

**앱 삭제**

   **앱** 페이지에서 **SimplePHPapp** 앱의 **작업** 열에서 **삭제**를 클릭한 다음 **삭제**를 클릭하여 확인합니다.  
![\[Confirmation dialog for deleting SimplePHPApp, warning of configuration loss.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/gse5.png)

1. 

**MyStack 삭제**

   [**스택**] 페이지에서 [**스택 삭제**]를 클릭한 다음 [**삭제**]를 클릭하여 확인합니다.  
![\[Confirmation dialog for deleting MyStack, warning of settings loss with Cancel and Delete options.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/gse6.png)

이 연습을 마칩니다.

# 첫 번째 Node.js 스택 생성
<a name="gettingstarted-node"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

이 예제는 Node.js 애플리케이션 서버를 지원하는 Linux 스택을 생성하고 간단한 애플리케이션을 배포하는 방법을 설명합니다. 스택의 구성 요소는 다음과 같습니다.
+ 두 개의 인스턴스가 있는 [Node.js 앱 서버 계층](workinglayers-node.md)
+ 애플리케이션 서버 인스턴스 간에 트래픽을 분산하는 [Elastic Load Balancing 로드 밸런서](layers-elb.md)
+ 백엔드 데이터베이스를 제공하는 [Amazon Relational Database Service(RDS) 서비스 계층](#gettingstarted-node-next)

**Topics**
+ [사전 조건](#gettingstarted-node-start)
+ [애플리케이션 구형](#gettingstarted-node-app)
+ [데이터베이스 서버 및 로드 밸런서 생성](#gettingstarted-node-create-db)
+ [스택 생성](#gettingstarted-node-stack)
+ [애플리케이션 배포](#gettingstarted-node-deploy)
+ [다음 단계](#gettingstarted-node-next)

## 사전 조건
<a name="gettingstarted-node-start"></a>

이 연습에서는 다음과 같이 가정합니다.
+ AWS 계정과 OpsWorks Stacks 사용 방법에 대한 기본적인 이해가 있습니다.

   OpsWorks Stacks 또는 AWS를 처음 사용하는 경우의 입문 자습서를 완료하여 기본 사항을 알아봅니다[Chef 11 Linux 스택 시작하기](gettingstarted.md).
+ Node.js 애플리케이션 구현 방법에 대한 기본적인 이해가 있습니다.

  Node.js가 생소하다면 [Node: Up and Running](http://chimera.labs.oreilly.com/books/1234000001808/index.html)과 같은 입문용 자습서를 완료하여 기본 사항에 대해 알아보십시오.
+ 이 예제를 사용할 AWS 리전에서 이미 하나 이상의 스택이 생성되어 있습니다.

  리전에서 첫 번째 스택을 생성하면 OpsWorks Stacks는 각 계층 유형에 대해 Amazon Elastic Compute Cloud(Amazon EC2) 보안 그룹을 생성합니다. Amazon RDS 데이터베이스(DB) 인스턴스를 생성하려면 이러한 보안 그룹이 필요합니다. OpsWorks Stacks를 처음 사용하는 경우의 자습서를 따를 때와 동일한 리전을이 예제에 사용하는 것이 좋습니다[Chef 11 Linux 스택 시작하기](gettingstarted.md). 새 리전을 사용하려면 리전에서 새 스택을 생성합니다. 스택이 계층 또는 인스턴스를 포함할 필요는 없습니다. 스택을 생성하는 즉시 OpsWorks Stacks는 보안 그룹 세트를 리전에 자동으로 추가합니다.
+ [기본 VPC](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-supported-platforms.html)에서 스택을 생성합니다.

  이 연습에서 EC2-Classic을 사용할 수 있지만 일부 세부 내용이 약간 다릅니다. 예를 들어 EC2-Classic에서는 서브넷 대신 인스턴스의 가용 영역(AZ)을 지정합니다.
+ IAM 사용자에게는 OpsWorks Stacks에 대한 전체 액세스 권한이 있습니다.

  보안상의 이유로 이 연습에서 계정의 루트 자격 증명은 사용하지 않는 것이 좋습니다. 대신 OpsWorks Stacks 전체 액세스 권한이 있는 사용자를 생성하고 OpsWorks Stacks에서 해당 자격 증명을 사용합니다. 자세한 내용은 [ 관리 사용자 생성](opsworks-security-users-manage-admin.md) 단원을 참조하십시오.

## 애플리케이션 구형
<a name="gettingstarted-node-app"></a>

이 안내에서는 Amazon RDS DB 인스턴스에 연결하고 인스턴스의 데이터베이스를 나열하는 간단한 [Express](http://expressjs.com/) 애플리케이션을 사용합니다.

애플리케이션을 구현하려면 워크스테이션의 편리한 위치에 `nodedb`라는 디렉터리를 생성하고 다음 세 파일을 이 디렉터리에 추가합니다.

**Topics**
+ [패키지 설명자](#w2ab1c14c71b9c11c13b8)
+ [레이아웃 파일](#w2ab1c14c71b9c11c13c10)
+ [코드 파일](#w2ab1c14c71b9c11c13c12)

### 패키지 설명자
<a name="w2ab1c14c71b9c11c13b8"></a>

애플리케이션의 패키지 설명자를 생성하려면 다음 콘텐츠가 포함된 `package.json`이라는 파일을 `nodedb` 디렉터리에 추가합니다. `package.json`은 Express 애플리케이션에 필요하며 애플리케이션의 루트 디렉터리에 위치해야 합니다.

```
{
  "name": "Nodejs-DB",
  "description": "Node.js example application",
  "version": "0.0.1",
  "dependencies": {
    "express": "*",
    "ejs": "*",
    "mysql": "*"
  }
}
```

이 `package.json` 예제는 최소한으로 구성되어 있습니다. 필수 `name` 및 `version` 속성을 정의하고 종속 패키지를 나열합니다.
+ `express`는 [Express](http://expressjs.com/) 패키지를 참조합니다.
+ `ejs`는 애플리케이션이 텍스트를 HTML 레이아웃 파일에 삽입할 때 사용하는 [EJS](http://www.embeddedjs.com/) 패키지를 참조합니다.
+ `mysql`은 애플리케이션이 RDS 인스턴스에 연결할 때 사용하는 [node-mysql](https://github.com/felixge/node-mysql) 패키지를 참조합니다.

패키지 설명자에 대한 자세한 정보는 [package.json](https://docs.npmjs.com/cli/v9/configuring-npm/package-json) 단원을 참조하세요.

### 레이아웃 파일
<a name="w2ab1c14c71b9c11c13c10"></a>

애플리케이션의 레이아웃 파일을 생성하려면 `views` 디렉터리에 `nodedb` 디렉터리를 추가하고, 콘텐츠가 포함된 `views`이라는 파일을 `index.html`에 추가합니다.

```
<!DOCTYPE html>
<html>
<head>
  <title>AWS Opsworks Node.js Example</title>
</head>
<body>
  <h1>AWS OpsWorks Node.js Example</h1>
    <p>Amazon RDS Endpoint: <i><%= hostname %></i></p>
    <p>User: <i><%= username %></i></p>
    <p>Password: <i><%= password %></i></p>
    <p>Port: <i><%= port %></i></p>
    <p>Database: <i><%= database %></i></p>

    <p>Connection: <%= connectionerror %></p>
    <p>Databases: <%= databases %></p>
</body>
</html>
```

이 예제에서는 레이아웃 파일이 Amazon RDS로부터의 일부 데이터를 표시하는 간단한 HTML 문서입니다. 각 `<%= ... =>` 요소는 이 다음에 생성할 애플리케이션의 코드 파일에서 정의되는 변수의 값을 나타냅니다.

### 코드 파일
<a name="w2ab1c14c71b9c11c13c12"></a>

애플리케이션의 코드 파일을 생성하려면 다음 콘텐츠가 포함된 `server.js` 파일을 `nodedb` 디렉터리에 추가합니다.

**중요**  
 OpsWorks Stacks를 사용하면 Node.js 애플리케이션의 기본 코드 파일의 이름을 `server.js` 지정하고 애플리케이션의 루트 폴더에 위치해야 합니다.

```
var express = require('express');
var mysql = require('mysql');
var dbconfig = require('opsworks'); //[1] Include database connection data
var app = express();
var outputString = "";

app.engine('html', require('ejs').renderFile);

//[2] Get database connection data
app.locals.hostname = dbconfig.db['host'];
app.locals.username = dbconfig.db['username'];
app.locals.password = dbconfig.db['password'];
app.locals.port = dbconfig.db['port'];
app.locals.database = dbconfig.db['database'];
app.locals.connectionerror = 'successful';
app.locals.databases = '';

//[3] Connect to the Amazon RDS instance
var connection = mysql.createConnection({
    host: dbconfig.db['host'],
    user: dbconfig.db['username'],
    password: dbconfig.db['password'],
    port: dbconfig.db['port'],
    database: dbconfig.db['database']
});

connection.connect(function(err)
{
    if (err) {
        app.locals.connectionerror = err.stack;
        return;
    }
});

// [4] Query the database
connection.query('SHOW DATABASES', function (err, results) {
    if (err) {
        app.locals.databases = err.stack;
    }
    
    if (results) {
        for (var i in results) {
            outputString = outputString + results[i].Database + ', ';
        }
        app.locals.databases = outputString.slice(0, outputString.length-2);
    }
});

connection.end();

app.get('/', function(req, res) {
    res.render('./index.html');
});

app.use(express.static('public'));

//[5] Listen for incoming requests
app.listen(process.env.PORT);
```

이 예제는 데이터베이스 연결 정보를 표시하며 데이터베이스 서버에 쿼리하여 서버의 데이터베이스 를 표시합니다. 손쉽게 이를 일반화하여 필요에 따라 데이터베이스와 상호 작용할 수 있습니다. 다음 참고 사항은 이전 코드에서 번호가 매겨진 주석 단원을 참조합니다.

**[1] Include database connection data**  
이 `require` 문은 데이터베이스 연결 데이터를 포함시킵니다. 나중에 설명하듯이, 데이터베이스에 데이터베이스 인스턴스를 앱에 연결하면 OpsWorks Stacks는 연결 데이터를 라는 파일에 넣습니다. `opsworks.js`이 파일은 다음과 비슷합니다.  

```
exports.db = {
  "host":"nodeexample.cdlqlk5uwd0k.us-west-2.rds.amazonaws.com",
  "database":"nodeexampledb",
  "port":3306,
  "username":"opsworksuser",
  "password":"your_pwd",
  "reconnect":true,
  "data_source_provider":"rds",
  "type":"mysql"}
```
`opsworks.js`는 애플리케이션의 `shared/config` 디렉터리인 `/srv/www/app_shortname/shared/config`에 있습니다. 그러나 OpsWorks Stacks는 애플리케이션의 루트 디렉터리`opsworks.js`에에 symlink를 배치하므로 만 사용하여 객체를 포함할 수 있습니다`require 'opsworks'`.

**[2] Get database connection data**  
이 문 세트는 `db` 객체에서 `app.locals` 속성 세트로 값을 할당하여 `opsworks.js`의 연결 데이터를 표시합니다. 각 속성은 `index.html` 파일 내 <%= ... %> 요소 중 하나에 매핑됩니다. 렌더링된 문서에서는 <%= ... %> 요소가 해당 속성 값으로 바뀝니다.

**[3] Connect to the Amazon RDS instance**  
이 예제는 `node-mysql`을 사용하여 데이터베이스에 액세스합니다. 데이터베이스에 연결하려면 연결 데이터를 `connection`에 전달하여 `createConnection` 객체를 생성한 후 `connection.connect`를 호출하여 연결을 설정합니다.

**[4] Query the database**  
연결이 설정되면 이 예제가 `connection.query`를 호출하여 데이터베이스를 쿼리합니다. 이 예제는 단순히 서버의 데이터베이스 이름을 쿼리합니다. `query`가 데이터베이스 이름이 `Database` 속성에 할당된 `results` 객체를 데이터베이스마다 하나씩 반환합니다. 이 예제는 이름을 연결하여 그 결과를 렌더링된 HTML 페이지에 목록을 표시하는 `app.locals.databases,`에 할당합니다.  
이 예제에는 RDS 인스턴스를 생성할 때 지정된 `nodeexampledb` 데이터베이스와 Amazon RDS가 자동으로 생성한 4개의 데이터베이스 등 5개의 데이터베이스가 있습니다.

**[5] Listen for incoming requests**  
이 마지막 문은 지정된 포트에서 수신 요청을 수신 대기합니다. 명시적 포트 값을 지정할 필요는 없습니다. 스택에 앱을 추가할 때 애플리케이션이 HTTP 또는 HTTPS 요청을 지원하는지 여부를 지정합니다. 그러면 OpsWorks Stacks는 `PORT` 환경 변수를 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는 기본 제공 보안 그룹을 표준 설정으로 덮어쓰므로 변경 사항이 손실됩니다.

**참고**  
연결된 앱을 [생성](workingapps-creating.md#workingapps-creating-environment) 또는 [업데이트](workingapps-editing.md)할 때 애플리케이션에 사용자 지정 환경 변수를 연결할 수 있습니다. 또한 사용자 지정 JSON과 사용자 지정 레시피를 사용하여 데이터를 애플리케이션으로 전달할 수도 있습니다. 자세한 내용은 [애플리케이션으로 데이터 전달](apps-data.md) 섹션을 참조하세요.

## 데이터베이스 서버 및 로드 밸런서 생성
<a name="gettingstarted-node-create-db"></a>

이 예제는 Amazon RDS 데이터베이스 서버 및 Elastic Load Balancing 로드 밸런서 인스턴스를 사용합니다. 각 인스턴스를 별도로 생성한 후 스택으로 가져와야 합니다. 이 섹션에서는 새 데이터베이스 및 로드 밸런서 인스턴스를 생성하는 방법을 설명합니다. 기존 인스턴스를 대신 사용할 수 있지만 인스턴스를 올바로 구성할 수 있도록 절차를 끝까지 읽는 것이 좋습니다.

다음 절차는 이 예제에는 충분한, 최소한으로 구성된 RDS DB 인스턴스를 생성하는 방법을 설명합니다. 자세한 내용은 [Amazon RDS 사용 설명서](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html)를 참조하세요.

**RDS DB 인스턴스를 생성하려면**

1. 

**콘솔을 엽니다.**

   [Amazon RDS 콘솔](https://console.aws.amazon.com/rds/)을 열고 지역을 미국 서부(오레곤)로 설정합니다. 탐색 창에서 [**RDS 대시보드**]를 선택한 다음 [**DB 인스턴스 시작**]을 선택합니다.

1. 

**데이터베이스 엔진을 지정합니다.**

   데이터베이스 엔진으로 [**MySQL 커뮤니티 에디션**]을 선택합니다.

1. 

**다중 AZ 배포를 거부합니다.**

   [**아니요, 이 인스턴스...**]를 선택한 다음, [**다음**]을 선택합니다. 이 예제에는 다중 AZ 배포가 필요 없습니다.

1. 

**기본 설정을 구성합니다.**

   [**DB 인스턴스 세부 정보**] 페이지에서 다음 설정을 지정합니다.
   + [**DB 인스턴스 클래스**]: [**db.t2.micro**]
   + [**다중 AZ 배포**]: [**No**]
   + **할당된 스토리지**: **5** GB
   + **DB 인스턴스 식별자**: **nodeexample**
   + **마스터 사용자 이름**: **opsworksuser**.
   + **Master Password:**: 선택한 암호

   나중에 사용하기 위해 인스턴스 식별자, 사용자 이름 및 암호를 적어 두고 다른 옵션에 대해서는 기본 설정을 수락한 다음 [**다음**]을 선택합니다.

1. 

**고급 설정을 구성합니다.**

   [**고급 설정 구성**] 페이지에서 다음 설정을 지정합니다.
   + **데이터베이스 이름**: **nodeexampledb**
   + [**DB 보안 그룹**]: [**AWS-OpsWorks-DB-Master-Server**]
**참고**  
[**AWS-OpsWorks-DB-Master-Server**] 보안 그룹에서는 스택의 인스턴스만 데이터베이스에 액세스하도록 허용합니다. 데이터베이스에 직접 액세스하려면 적절한 인바운드 규칙을 사용하여 RDS DB 인스턴스에 추가 보안 그룹을 연결합니다. 자세한 내용은 [Amazon RDS 보안 그룹](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.RDSSecurityGroups.html)을 참조하세요. 또한 VPC에 인스턴스를 배치하여 액세스를 제어할 수도 있습니다. 자세한 내용은 [VPC에서 스택 실행](workingstacks-vpc.md) 섹션을 참조하세요.

   나중에 사용하기 위해 데이터베이스 이름을 적어 두고 다른 설정에 대해서는 기본값을 수락한 다음 [**DB 인스턴스 시작**]을 선택합니다.

다음 절차는 이 예제를 위한 Elastic Load Balancing 로드 밸런서를 생성하는 방법을 설명합니다. 자세한 내용은 [Elastic Load Balancing 사용 설명서](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elastic-load-balancing.html)를 참조하세요.

**로드 밸런서를 생성하려면**

1. 

**Amazon EC2 콘솔을 엽니다.**

   [Amazon EC2 콘솔](https://console.aws.amazon.com/ec2/)을 열고 리전이 미국 서부(오레곤)로 설정되어 있는지 확인합니다. 탐색 창에서 [**로드 밸런서**]를 선택한 다음 [**로드 밸런서 만들기**]를 선택합니다.

1. 

**로드 밸런서를 정의합니다.**

   [**로드 밸런서 정의**] 페이지에서 다음 설정을 지정하세요.
   + **명칭** – **Node-LB**
   + **LB 내부 생성** – **내 기본 VPC**

   다른 옵션에 대해서는 기본 설정을 수락하고 [**다음**]을 선택합니다.

1. 

**보안 그룹을 할당합니다.**

   [**보안 그룹 할당**] 페이지에서 다음 그룹을 지정합니다.
   + **기본 VPC 보안 그룹**
   + **AWS-OpsWorks-nodejs-App-Server**

   **다음**을 선택합니다. [**보안 설정 구성**] 페이지에서 [**다음**]을 선택합니다. 이 예제에는 보안 리스너가 필요 없습니다.

1. 

**상태 확인을 구성합니다.**

   **상태 확인 구성** 페이지에서 **Ping 경로**를 **/**로 설정하고 다른 설정에 대해서는 기본값을 수락합니다. **다음**을 선택합니다. [**EC2 인스턴스 추가**] 페이지에서 [**다음**]을 선택합니다. **태그 추가 페이지에서 검토 및 생성을 선택합니다. 스택은 로드 **밸런서에 EC2 인스턴스를 추가하는 작업을 처리하므로이 예제에서는 태그가 필요하지 않습니다. **** OpsWorks 

1. 

**로드 밸런서를 생성합니다.**

   [**검토**] 페이지에서 [**만들기**]를 선택하여 로드 밸런서를 생성합니다.

## 스택 생성
<a name="gettingstarted-node-stack"></a>

이제 스택을 생성하는 데 필요한 모든 구성 요소가 준비되었습니다.

**스택을 생성하는 방법**

1. 

**OpsWorks Stacks 콘솔에 로그인합니다.**

   [OpsWorks Stacks 콘솔](https://console.aws.amazon.com/opsworks/)에 로그인한 다음 **스택 추가**를 선택합니다.

1. 

**스택을 생성합니다.**

   새 스택을 생성하려면 [**Chef 11 스택**]을 선택하고 다음 설정을 지정합니다.
   +  – **NodeStack**
   + **리전** – **미국 서부(오레곤)**

     스택은 모든 AWS 리전에서 생성할 수 있지만 자습서의 경우 미국 서부(오레곤)를 선택하는 것이 좋습니다.

   [**스택 추가**]를 선택합니다. 스택 구성 설정에 대한 자세한 정보는 [새 스택 생성](workingstacks-creating.md) 단원을 참조하세요.

1. 

**연결된 로드 밸런서와 함께 Node.js 앱 서버 계층을 추가합니다.**

   [**NodeStack**] 페이지에서 [**계층 추가**]를 선택하고 다음 설정을 지정합니다.
   + **계층 유형** — **Node.js 앱 서버**
   + **탄력적 로드 밸런서** - **노드-LB**

   다른 설정에 대해서는 기본값을 수락하고 [**계층 추가**]를 선택합니다.

1. 

**인스턴스를 계층에 추가하고 시작합니다.**

   탐색 창에서 [**인스턴스**]를 선택하고 다음과 같이 Rails 앱 서버 계층에 인스턴스 2개를 추가합니다.

   1. **Node.js 앱 서버**에서 **인스턴스 추가**를 선택합니다.

      [**크기**]를 [**t2.micro**]로 설정하고, 다른 설정에 대해서는 기본값을 수락하고 [**인스턴스 추가**]를 선택합니다.

   1. [**\$1인스턴스**]를 선택한 다음 두 번째 **t2.micro** 인스턴스를 다른 서브넷의 계층에 추가합니다.

      이렇게 하면 해당 인스턴스가 다른 AZ(가용 영역)에 배치됩니다.

   1. [**인스턴스 추가**]를 선택합니다.

   1. 두 인스턴스를 모두 시작하려면 [**모든 인스턴스 시작**]을 선택합니다.

   이 계층에 Elastic Load Balancing 로드 밸런서를 할당했습니다. 인스턴스가 온라인 상태가 되거나 온라인 상태가 되면 OpsWorks Stacks는 로드 밸런서에 인스턴스를 자동으로 등록하거나 등록 취소합니다.
**참고**  
프로덕션 스택의 경우 다중 AZ에 애플리케이션 서버 인스턴스를 배포하는 것이 좋습니다. 사용자가 AZ에 연결할 수 없는 경우 로드 밸런서가 나머지 영역의 인스턴스로 수신 트래픽을 라우트하므로 사이트가 계속해서 작동합니다.

1. 

**스택에 RDS DB 인스턴스를 등록합니다.**

   탐색 창에서 [**리소스**]를 선택하고 다음과 같이 스택에 RDS DB 인스턴스를 등록합니다.

   1. [**RDS**] 탭을 선택한 다음 [**미등록 RDS DB 표시**] 인스턴스를 선택합니다.

   1. [**nodeexampledb**] 인스턴스를 선택하고 다음 설정을 지정합니다.
      + **사용자** - 인스턴스를 생성할 때 지정한 마스터 사용자 이름입니다(이 예제에서는). **opsworksuser**.
      + **암호** - 인스턴스를 생성할 때 지정한 마스터 암호입니다.

   1. **스택에 등록**을 선택하여 스택에 RDS DB 인스턴스를 [Amazon RDS 서비스 계층](workinglayers-db-rds.md)으로 추가합니다.
**주의**  
OpsWorks Stacks는 **사용자** 또는 **암호** 값을 검증하지 않고 단순히 애플리케이션에 전달합니다. 이러한 값을 잘못 입력하면 애플리케이션이 데이터베이스에 연결할 수 없습니다.

   [스택에 등록](workinglayers-db-rds.md)을 선택하여 스택에 RDS DB 인스턴스를 **Amazon RDS 서비스 계층**으로 추가합니다.

## 애플리케이션 배포
<a name="gettingstarted-node-deploy"></a>

애플리케이션은 원격 리포지토리에 저장해야 합니다. 배포 시 OpsWorks Stacks는 코드 및 관련 파일을 리포지토리에서 애플리케이션 서버 인스턴스로 배포합니다. 편의를 위해 이 예제는 리포지토리로 퍼블릭 Amazon Simple Storage Service(S3) 아카이브를 사용하지만, Git 및 하위 버전을 비롯해 다수의 다른 리포지토리 유형을 사용할 수 있습니다. 자세한 내용은 [애플리케이션 소스](workingapps-creating.md#workingapps-creating-source) 섹션을 참조하세요.

**애플리케이션을 배포하려면**

1. 

**애플리케이션을 아카이브 파일에 패키지로 포함합니다.**

   `.zip` 디렉터리와 하위 디렉터리 nodedb.zip의 `nodedb` 아카이브를 생성합니다. 또한 gzip, bzip2 및 tarball을 비롯하여 다른 아카이브 파일 유형을 사용할 수도 있습니다. OpsWorks Stacks는 압축되지 않은 tarball을 지원하지 않습니다. 자세한 내용은 [애플리케이션 소스](workingapps-creating.md#workingapps-creating-source) 단원을 참조하십시오.

1. 

**Amazon S3로 아카이브 파일을 업로드합니다.**

   `nodedb.zip`을 Amazon S3 버킷에 업로드하고, 이 파일을 퍼블릭으로 지정한 다음 나중에 사용하기 위해 파일의 URL을 복사해 둡니다. 버킷 생성 및 파일 업로드 방법에 대한 자세한 내용은 [Amazon Simple Storage Service 시작하기](https://docs.aws.amazon.com/AmazonS3/latest/gsg/GetStartedWithS3.html)를 참조하세요.
**참고**  
OpsWorks Stacks는 Amazon S3 버킷에서 프라이빗 파일을 배포할 수도 있지만 간소화를 위해이 예제에서는 퍼블릭 파일을 사용합니다. 자세한 내용은 [애플리케이션 소스](workingapps-creating.md#workingapps-creating-source) 단원을 참조하십시오.

1. 

**OpsWorks Stacks 앱을 생성합니다.**

    OpsWorks Stacks 콘솔로 돌아가서 탐색 창에서 **앱을** 선택한 다음 **앱 추가를** 선택합니다. 다음 설정을 지정합니다.
   + **이름** – `NodeDB`.

     이 문자열은 앱의 표시 이름입니다. 대부분의 경우 OpsWorks Stacks가 모든 문자를 소문자로 변환하고 구두점을 제거하여 표시 이름에서 생성하는 앱의 짧은 이름이 필요합니다. 이 예제에서 짧은 이름은 `nodedb`입니다. 앱을 생성한 후 앱의 짧은 이름을 확인하려면 [**앱**] 페이지에서 앱을 선택하여 앱의 세부 정보 페이지를 표시합니다.
   + **유형** – `Node.js`.
   + **데이터 소스 유형** – `RDS`.
   + **데이터베이스 인스턴스** - 앞서 등록한 Amazon RDS DB 인스턴스를 선택합니다.
   + **데이터베이스 이름** - 앞서 생성한 데이터베이스 이름을 지정합니다. 이 예제에서는 `nodeexampledb`입니다.
   + **리포지토리 유형** – `Http Archive`.

     이 리포지토리 유형은 퍼블릭 Amazon S3 파일에 사용해야 합니다. `S3 Archive` 유형은 프라이빗 아카이브에만 사용됩니다.
   + **리포지토리 URL** - 아카이브 파일의 Amazon S3 URL.

   나머지 설정에 대해서는 기본값을 사용하고 [**앱 추가**]를 클릭하여 앱을 생성합니다.

1. 

**앱을 배포합니다.**

   **앱** 페이지로 이동한 다음 NodeDB 앱의 **작업** 열에서 **배포**를 선택합니다. 그런 다음 **배포**를 선택하여 앱을 서버 인스턴스에 배포합니다. OpsWorks Stacks는 각 인스턴스에서 Deploy 레시피를 실행하여 리포지토리에서 애플리케이션을 다운로드하고 서버를 다시 시작합니다. 각 인스턴스에 녹색 확인 표시가 나타나고 [**상태**]가 [**성공**]이면 배포가 완료되고 애플리케이션이 요청 처리를 시작할 준비가 된 것입니다.
**참고**  
배포에 실패한 경우 **로그** 열에서 **표시**를 선택하여 배포의 Chef 로그를 표시합니다. 맨 아래 근처에 오류 정보가 표시되어 있습니다.

1. 

**애플리케이션을 엽니다.**

   애플리케이션을 열려면 [**계층**]를 선택하고 로드 밸런서를 선택한 다음 로드 밸런서의 DNS 이름을 선택합니다. 그러면 로드 밸런서로 HTTP 요청이 전송됩니다. 다음과 같은 내용이 표시되어야 합니다.  
![\[AWS OpsWorks Node.js example showing RDS endpoint, user credentials, and database details.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/node_walkthrough.png)

**참고**  
OpsWorks Stacks는 설정 중에 새 인스턴스에 앱을 자동으로 배포합니다. 수동 배포는 온라인 인스턴스에서만 필요합니다. 자세한 내용은 [앱 배포](workingapps-deploying.md) 섹션을 참조하세요. 보다 복잡한 배포 전략을 비롯해 배포에 대한 전반적인 설명은 [앱과 쿡북의 관리 및 배포](best-deploy.md) 단원을 참조하세요.

## 다음 단계
<a name="gettingstarted-node-next"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

이 연습에서는 간단한 Node.js 애플리케이션 서버 스택을 설정하는 기본 사항을 살펴보았습니다. 아래는 다음 단계에 대한 몇 가지 제안입니다.

**Node.js 내장 쿡북 살펴보기**  
인스턴스 구성 방법을 자세히 알아보려면 Stacks가 소프트웨어를 설치 및 구성하는 데 사용하는 레시피와 관련 파일이 포함된 계층의 내장 [쿡북인 opsworks\$1nodejs](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.10/opsworks_nodejs)와 Stacks가 앱을 배포하는 데 사용하는 레시피가 포함된 내장 배포 OpsWorks [쿡북](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.10/deploy)을 참조하세요. OpsWorks 

**서버 구성 사용자 지정**  
이 예제 스택은 매우 기본적입니다. 프로덕션용으로 사용하려면 스택을 사용자 지정해야 할 것입니다. 자세한 내용은 [OpsWorks 스택 사용자 지정](customizing.md) 섹션을 참조하세요.

**SSL 지원을 추가**  
앱에 대한 SSL 지원을 활성화하고 앱을 생성할 때 OpsWorks Stacks에 적절한 인증서를 제공할 수 있습니다. 그러면 OpsWorks Stacks가 해당 디렉터리에 인증서를 설치합니다. 자세한 내용은 [SSL 사용](workingsecurity-ssl.md) 단원을 참조하십시오.

**인 메모리 데이터 캐싱을 추가**  
프로덕션 수준 사이트에서 Redis 또는 Memcache와 같은 인 메모리 키-값 저장소에 데이터를 캐시하여 성능을 개선하는 경우가 종종 있습니다. 둘 중 하나를 OpsWorks Stacks 스택과 함께 사용할 수 있습니다. 자세한 내용은 [ElastiCache Redis](other-services-redis.md) 및 [Memcached](workinglayers-mem.md) 섹션을 참조하세요.

**보다 복잡한 배포 전략을 사용**  
이 예제에서는 모든 인스턴스를 동시에 업데이트하는 간단한 앱 배포 전략을 사용했습니다. 이 접근 방식은 간단하고 빠르지만 오류의 여지가 없습니다. 배포가 실패하거나 업데이트에 문제가 있을 경우 프로덕션 스택의 모든 인스턴스가 영향을 받을 수 있으므로 문제를 해결할 때까지는 사이트가 중단 또는 비활성화될 수 있습니다. 배포 전략에 대한 자세한 정보는 [앱과 쿡북의 관리 및 배포](best-deploy.md) 단원을 참조하세요.

**Node.js 앱 서버 계층을 확장하세요.**  
다양한 방법으로 계층을 확장할 수 있습니다. 예를 들어 인스턴스에서 스크립트를 실행하는 레시피를 구현하거나 앱 배포를 사용자 지정하기 위한 Chef 배포 후크를 구현할 수 있습니다. 자세한 내용은 [계층 확장](workingcookbook-extend.md) 섹션을 참조하세요.

**환경 변수를 정의**  
연결된 앱의 환경 변수를 정의하여 애플리케이션에 데이터를 전달할 수 있습니다. 앱을 배포할 때 OpsWorks Stacks는 사용자가 앱에서 액세스할 수 있도록 해당 변수를 내보냅니다. 자세한 내용은 [환경 변수 사용](apps-environment-vars.md) 단원을 참조하십시오.

# OpsWorks 스택 사용자 지정
<a name="customizing"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

OpsWorks Stacks 내장 계층은 다양한 용도로 충분한 표준 기능을 제공합니다. 하지만 다음과 같은 상황을 마주할 수 있습니다.
+ 내장 계층의 표준 구성이 적당하지만 이상적이지는 않아 특정 요구 사항에 맞게 최적화하기를 원할 경우

  예를 들어 최대 worker 프로세스 수 또는 `keepalivetimeout` 값과 같은 설정에 자체 값을 지정하여 Static Web Server 계층의 Nginx 서버 구성을 조정할 수 있습니다.
+ 내장 계층의 기능이 훌륭하지만 추가 패키지를 설치하거나 몇몇 사용자 지정 설치 스크립트를 실행하여 확장하기를 원할 경우

  예를 들어 Redis 서버도 설치하여 PHP 앱 서버 계층을 확장할 수 있습니다.
+ 내장 계층으로 처리할 수 없는 요구 사항이 있는 경우

  예를 들어 OpsWorks Stacks에는 일부 인기 있는 데이터베이스 서버에 대한 기본 제공 계층이 포함되어 있지 않습니다. 계층의 인스턴스에 이러한 서버를 설치하는 사용자 지정 계층을 생성할 수 있습니다.
+ 사용자 지정 계층만 지원하는 Windows 스택을 실행하는 경우

OpsWorks Stacks는 특정 요구 사항에 맞게 계층을 사용자 지정하는 다양한 방법을 제공합니다. 다음 예제는 복잡성 및 파워가 증가하는 순서로 나열되어 있습니다.

**참고**  
일부 접근 방식은 Linux 스택에서만 작동합니다. 자세한 정보는 이하의 주제를 참조하세요.
+ 사용자 지정 JSON을 사용하여 기본 OpsWorks Stacks 설정을 재정의합니다.
+ 기본 스택 설정을 재정의하는 속성 파일을 사용하여 사용자 지정 Chef OpsWorks 쿡북을 구현합니다.
+ 기본 Stacks 템플릿을 재정의하거나 확장하는 템플릿을 사용하여 사용자 지정 Chef OpsWorks 쿡북을 구현합니다.
+ shell 스크립트를 실행하는 간단한 레시피를 사용하여 사용자 지정 Chef 쿡북을 구현합니다.
+ 디렉터리 구성, 패키지 설치, 구성 파일 생성, 앱 배포 등의 작업을 수행하는 레시피를 사용하여 사용자 지정 Chef 쿡북을 구현합니다.

스택의 Chef 버전 및 운영 체제에 따라 레시피를 재정의할 수도 있습니다.
+ Chef 0.9 및 11.4 스택에서는 동일한 쿡북 및 레시피 이름의 사용자 지정 레시피를 구현하여 내장 레시피를 재정의할 수 없습니다.

  각 수명 주기 이벤트에 대해 OpsWorks Stacks는 항상 기본 제공 레시피를 먼저 실행한 다음 사용자 지정 레시피를 실행합니다. 이러한 Chef 버전은 동일한 쿡북 및 레시피 이름을 두 번 실행하지 않으므로 내장 레시피가 우선 순위를 가져 사용자 지정 레시피를 실행되지 않습니다.
+ Chef 11.10 스택에서는 내장 레시피를 재정의할 수 있습니다.

  자세한 내용은 [쿡북 설치 및 우선 순위](workingcookbook-chef11-10.md#workingcookbook-chef11-10-override) 섹션을 참조하세요.
+ Windows 스택에서는 내장 레시피를 재정의할 수 없습니다.

   OpsWorks Stacks가 Windows 스택용 Chef 실행을 처리하는 방식에서는 내장 레시피를 재정의할 수 없습니다.

**참고**  
많은 기법이 사용자 지정 쿡북을 사용하기 때문에 쿡북 구현에 익숙하지 않은 [쿡북과 레시피](workingcookbook.md) 경우 먼저를 읽어야 합니다. [쿡북 기본 사항](cookbooks-101-basics.md)에서는 사용자 지정 쿡북 구현에 대한 자세한 자습서를 제공하고 Stacks 인스턴스용 OpsWorks 쿡북을 구현하는 방법에 대한 몇 가지 세부 정보를 [OpsWorks 스택용 쿡북 구현](cookbooks-101-opsworks.md) 다룹니다.

**Topics**
+ [속성을 재정의하여 OpsWorks 스택 구성 사용자 지정](workingcookbook-attributes.md)
+ [사용자 지정 템플릿을 사용하여 OpsWorks 스택 구성 파일 확장](workingcookbook-template-override.md)
+ [계층 확장](workingcookbook-extend.md)
+ [사용자 지정 Tomcat 서버 계층 생성](create-custom.md)
+ [스택 구성 및 배포 속성](workingcookbook-json.md)

# 속성을 재정의하여 OpsWorks 스택 구성 사용자 지정
<a name="workingcookbook-attributes"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
Windows 스택 및 Chef 12 Linux 스택의 경우 OpsWorks Stacks는 기본 제공 레시피 및 사용자 지정 레시피에 별도의 Chef 실행을 사용합니다. 즉, 이 섹션에 설명된 기법을 사용해서는 Windows 스택과 Chef 12 Linux 스택의 내장 속성을 재정의할 수 없습니다.

레시피와 템플릿은 계층 구성 또는 애플리케이션 서버 설정 같은 인스턴스 또는 스택별 정보를 다양한 Chef 속성에 의존합니다. 이들 속성에는 몇 가지 소스가 있습니다.
+ **사용자 지정 JSON** - 필요한 경우, 스택을 생성, 업데이트 또는 복제하거나 앱을 배포할 때 사용자 지정 JSON 속성을 지정할 수 있습니다.
+ **스택 구성 속성** -OpsWorks 스택은 콘솔 설정을 통해 지정하는 정보를 포함하여 스택 구성 정보를 보유하도록 이러한 속성을 정의합니다.
+ **배포 속성** — AWS OpsWorks는 Deploy 이벤트의 배포 관련 속성을 정의합니다.
+ **쿡북 속성** - 내장 쿡북과 사용자 지정 쿡북은 일반적으로 애플리케이션 서버 구성 설정 등 쿡북별 값을 나타내는 속성이 포함된 [속성 파일](workingcookbook-installingcustom-components-attributes.md)을 포함하고 있습니다.
+ **Chef** - Chef의 [Ohai 도구](http://docs.chef.io/resource_ohai.html)는 CPU 유형과 설치된 메모리 같은 다양한 시스템 구성 설정을 나타내는 속성을 정의합니다.

스택 구성 및 배포 속성과 내장 쿡북 속성의 완전한 목록은 [스택 구성 및 배포 속성: Linux](attributes-json-linux.md) 및 [내장 쿡북 속성](attributes-recipes.md)를 참조하세요. Ohai 속성에 대한 자세한 정보는 [Ohai](https://docs.chef.io/ohai.html)를 참조하세요.

배포 또는 구성과 같은 [수명 주기 이벤트](workingcookbook-events.md)가 발생하거나 `execute_recipes` 또는 `update_packages`같은 [스택 명령](workingstacks-commands.md)을 실행하면 OpsWorks Stacks는 다음을 수행합니다. 
+ 해당 명령을 각각의 해당 인스턴스의 에이전트에 전송합니다.

  이 에이전트는 적절한 레시피를 실행합니다. 예를 들어 Deploy 이벤트의 경우, 에이전트는 내장 Deploy 레시피를 실행한 다음 사용자 지정 Deploy 레시피를 실행합니다.
+ 사용자 지정 JSON 및 배포 속성을 스택 구성 속성에 병합하고 인스턴스에 설치합니다.

사용자 지정 JSON의 속성, 스택 구성 및 배포 속성, 쿡북 속성 및 Ohai 속성은 레시피에 속성 값을 제공하는 *노드 객체*에 병합됩니다. 인스턴스는 사용자 지정 JSON을 비롯한 스택 구성 속성에 관한 한 기본적으로 상태 비저장입니다. 배포 또는 스택 명령을 실행하면 연결된 레시피는 명령과 함께 다운로드된 스택 구성 속성을 사용합니다.

**Topics**
+ [속성 우선 순위](workingcookbook-attributes-precedence.md)
+ [사용자 지정 JSON을 사용한 속성 재정의](workingcookbook-json-override.md)
+ [사용자 지정 OpsWorks 쿡북 속성을 사용하여 스택 속성 재정의](workingcookbook-cookbook-attributes.md)

# 속성 우선 순위
<a name="workingcookbook-attributes-precedence"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

속성이 고유하게 정의되는 경우, Chef는 해당 속성을 노드 객체에 단순히 통합합니다. 하지만 모든 속성 소스는 어떤 속성도 정의할 수 있으므로 동일한 속성이 값이 각기 다른 여러 정의를 가질 수 있습니다. 예를 들어 내장 `apache2` 쿡북은 `node[:apache][:keepalive]`를 정의하지만 사용자 지정 JSON 또는 사용자 지정 쿡북에서도 해당 속성을 정의할 수 있습니다. 한 속성에 여러 정의가 있는 경우, 이 정의들은 뒤에 설명하는 순서대로 평가되며, 노드 객체는 우선 순위가 가장 높은 정의를 수신합니다.

속성은 다음과 같이 정의됩니다.

```
node.type[:attribute][:sub_attribute][:...]=value
```

속성에 여러 정의가 있는 경우 유형에 따라 우선 순위가 있는 정의가 결정되고 해당 정의가 노드 객체에 통합됩니다. OpsWorks Stacks는 다음 속성 유형을 사용합니다.
+ **default** - 이것은 가장 일반적인 유형이며, 기본적으로 "속성이 아직 정의되지 않았다면 이 값을 사용하라"는 뜻입니다. 속성의 모든 정의가 `default` 유형인 경우, 평가 순서에서 첫 번째 정의가 우선하며 후속 값들은 무시됩니다. Stacks는 모든 스택 구성 및 배포 속성 OpsWorks 정의를 `default` 유형으로 설정합니다.
+ **normal** - 이 유형의 속성은 모든 `default` 속성 또는 평가 순서에서 앞서 정의된 `normal` 속성을 재정의합니다. 예를 들어 첫 번째 속성이 내장 쿡북의 속성이고 `default` 유형을 가지고 있으며 두 번째는 사용자가 정의한 속성으로 `normal` 유형을 가지고 있다면 두 번째 속성이 우선합니다.
+ **set** - 이전의 쿡북에서 볼 수 있는 사용되지 않는 유형입니다. 이 유형은 같은 우선 순위를 갖는 `normal`로 대체되었습니다.

Chef는 다른 모든 속성 정의에 우선하는 `automatic` 유형을 비롯한 몇 가지 추가 속성 유형을 지원합니다. Chef의 Ohai 도구에 의해 생성되는 속성 정의는 모두 `automatic` 유형이므로 사실상 읽기 전용입니다. 이는 일반적으로 문제가 되지 않습니다. 재정의할 이유가 없고 OpsWorks Stacks의 속성과 별개이기 때문입니다. 다만 사용자 지정 쿡북 속성의 이름을 지정할 때는 Ohai 속성과 구별되도록 주의해야 합니다. 자세한 정보는 [속성 정보](http://docs.chef.io/attributes.html)를 참조하세요.

**참고**  
Ohai 도구는 명령줄에서 실행할 수 있는 실행 파일입니다. 인스턴스의 Ohai 속성을 나열하려면 인스턴스에 로그인하고 터미널 창에서 `ohai`를 실행합니다. 매우 긴 출력이 생성되므로 유의하세요.

다음은 다양한 속성 정의를 노드 객체에 통합하는 단계입니다.

1. 모든 사용자 지정 스택 구성 속성을 스택 구성 및 배포 속성에 병합합니다.

   스택이나 특정 배포에 대해 사용자 지정 JSON 속성을 설정할 수 있습니다. 사용자 지정 JSON 속성은 평가 순서에서 첫 번째이며 사실상 `normal` 유형입니다. 사용자 지정 JSON에서 하나 이상의 스택 구성 속성도 정의되는 경우, 사용자 지정 JSON 값이 우선합니다. 그렇지 않으면 OpsWorks Stacks는 단순히 사용자 지정 JSON 속성을 스택 구성에 통합합니다.

1. 모든 배포 사용자 지정 JSON 속성을 스택 구성 및 배포 속성에 병합합니다.

   배포 사용자 지정 JSON 속성도 사실상 `normal` 유형이므로 내장 및 사용자 지정 스택 구성 JSON과 내장 배포 JSON보다 우선합니다.

1. 스택 구성 및 배포 속성을 인스턴스의 노드 객체에 병합합니다.

1. 인스턴스의 내장 쿡북 속성을 노드 객체에 병합합니다.

   내장 쿡북 속성은 모두 `default` 유형입니다. 일반적으로 사용자 지정 JSON으로 정의했기 때문에 스택 구성 및 배포 속성에도 하나 이상의 내장 쿡북 속성이 정의된 경우 스택 구성 정의가 내장 쿡북 정의보다 우선합니다. 다른 모든 내장 쿡북 속성은 단순히 노드 객체에 통합됩니다.

1. 인스턴스의 사용자 지정 쿡북 속성을 노드 객체에 병합합니다.

   사용자 지정 쿡북 속성은 일반적으로 `normal` 또는 `default` 유형입니다. 고유한 속성은 노드 객체에 통합됩니다. 1\$13단계에서 사용자 지정 쿡북 속성도 정의한 경우(일반적으로 사용자 지정 JSON으로 정의했기 때문에) 우선 순위는 사용자 지정 쿡북 속성 유형에 따라 달라집니다.
   + 1-3단계에서 정의된 속성은 사용자 지정 쿡북 `default` 속성보다 우선합니다.
   + 사용자 지정 쿡북 `normal` 속성은 1-3단계의 정의보다 우선합니다.

**중요**  
사용자 지정 쿡북 `default` 속성을 사용하여 스택 구성 또는 내장 쿡북 속성을 재정의하지 마십시오. 사용자 지정 쿡북 속성은 마지막으로 평가되기 때문에 `default` 속성은 우선 순위가 가장 낮으며 아무것도 재정의할 수 없습니다.

# 사용자 지정 JSON을 사용한 속성 재정의
<a name="workingcookbook-json-override"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
 OpsWorks Stacks는 Windows 스택의 Chef 실행을 Linux 스택의 경우와 다르게 처리하기 때문에 Windows 스택의 경우이 섹션에서 설명하는 기술을 사용할 수 없습니다.

Stacks 속성을 재정의하는 가장 간단한 방법은 기본 제공 및 사용자 지정 OpsWorks 쿡북 속성뿐만 아니라 스택 구성 및 배포 속성보다 우선하는 사용자 지정 JSON으로 정의하는 것입니다`default`. 자세한 내용은 [속성 우선 순위](workingcookbook-attributes-precedence.md) 단원을 참조하십시오.

**중요**  
스택 구성 및 배포 속성을 재정의할 때는 주의해야 합니다. 예를 들어 `opsworks` 네임스페이스에서 속성을 재정의하면 내장 속성을 방해할 수 있습니다. 자세한 내용은 [스택 구성 및 배포 속성](workingcookbook-json.md) 섹션을 참조하세요.

사용자 지정 JSON을 사용하여 고유한 속성을 정의할 수도 있습니다(일반적으로 데이터를 사용자 지정 레시피에 전달하기 위해). 속성은 노드 객체에 통합되며, 레시피는 표준 Chef 노드 구문을 사용하여 속성 단원을 참조할 수 있습니다.

## 사용자 지정 JSON 지정 방법
<a name="workingcookbook-json-override-specify"></a>

사용자 지정 JSON을 사용하여 속성 값을 재정의하려면 먼저 속성의 정규화된 속성 이름을 확인해야 합니다. 그런 다음 재정의하려는 속성을 포함한 JSON 객체를 생성하고 선호하는 값으로 설정합니다. 편의상 [스택 구성 및 배포 속성: Linux](attributes-json-linux.md) 및 [내장 쿡북 속성](attributes-recipes.md) 문서에는 일반적으로 사용되는 스택 구성, 배포 및 내장 쿡북 속성과 그 정규화된 이름이 나와 있습니다.

객체의 상위-하위 관계는 적절한 정규화된 Chef 노드와 일치해야 합니다. 예를 들어 다음과 같은 Apache 속성을 변경하려 한다고 가정하겠습니다.
+ 노드가 `node[:apache][:keepalivetimeout]`이고 `3` 기본값을 가진 [`keepalivetimeout`](attributes-recipes-apache.md#attributes-recipes-apache-keep-timeout) 속성입니다.
+ 노드가 `node[:apache][:logrotate][:schedule]`이고 `"daily"` 기본값을 가진 `logrotate` [`schedule`](attributes-recipes-apache.md#attributes-recipes-apache-log-schedule) 속성입니다.

이 속성들을 재정의하고 값을 각각 `5`와 `"weekly"`로 설정하려면 다음 사용자 지정 JSON을 사용합니다.

```
{
  "apache" : {
    "keepalivetimeout" : 5,
    "logrotate" : {
       "schedule" : "weekly"
    }
  }
}
```

## 사용자 지정 JSON을 지정할 시기
<a name="workingcookbook-json-override-when"></a>

다음 작업에 사용자 지정 JSON 구조를 지정할 수 있습니다.
+ [새 스택 생성](workingstacks-creating.md)
+ [스택 업데이트](workingstacks-edit.md)
+ [스택 명령 실행](workingstacks-edit.md)
+ [스택 복제](workingstacks-cloning.md)
+ [앱 배포](workingapps-deploying.md)

각 작업에 대해 OpsWorks Stacks는 사용자 지정 JSON 속성을 스택 구성 및 배포 속성과 병합하고 인스턴스로 전송하여 노드 객체에 병합합니다. 다만 다음을 참고하세요.
+ 스택을 생성, 복제 또는 업데이트할 때 사용자 지정 JSON을 지정하는 경우, 속성은 모든 후속 수명 주기 이벤트 및 스택 명령의 스택 구성 및 배포 속성에 병합됩니다.
+ 배포를 위해 사용자 지정 JSON을 지정하는 경우, 속성은 해당 이벤트의 스택 구성 및 배포 속성에만 병합됩니다.

  후속 배포에 이러한 사용자 지정 속성을 사용하려면 사용자 지정 JSON을 다시 명시적으로 지정해야 합니다.

속성은 레시피에 의해 사용될 때 인스턴스에만 영향을 미친다는 점을 명심해야 합니다. 속성 값을 재정의해도 해당 속성 단원을 참조하는 후속 레시피가 없다면 변경은 효과가 없습니다. 연결된 레시피가 실행되기 전에 사용자 지정 JSON을 전송하거나 적절한 레시피를 다시 실행해야 합니다.

## 사용자 지정 JSON 모범 사례
<a name="workingcookbook-json-override-best"></a>

사용자 지정 JSON을 사용하여 모든 OpsWorks Stacks 속성을 재정의할 수 있지만 정보를 수동으로 입력하는 것은 다소 번거롭고 어떤 종류의 소스 제어도 하지 않습니다. 사용자 지정 JSON은 다음과 같은 용도로 가장 잘 활용할 수 있습니다.
+ 소수의 속성만 재정의하고 그 밖에는 사용자 지정 쿡북을 사용할 필요가 없을 때.

  사용자 지정 JSON을 사용하면 단지 2가지 속성을 재정의하기 위해 쿡북 리포지토리를 설정하고 유지 관리하는 부담을 피할 수 있습니다.
+ 암호 또는 인증 키 같은 중요한 값.

  쿡북 속성은 리포지토리에 저장되므로 중요한 정보가 침해될 위험이 있습니다. 그 대신 더미 값으로 기본값을 정의하고 사용자 지정 JSON을 사용하여 실제 값을 설정하세요.
+ 값은 다양할 것으로 예상됩니다.

  예를 들어 권장되는 관행은 프로덕션 스택을 별도의 개발 및 스테이징 스택으로 지원하는 것입니다. 이 스택들이 지불을 받는 애플리케이션을 지원한다고 가정해 보십시오. 사용자 지정 JSON을 사용하여 지불 엔드포인트를 지정하는 경우, 스테이징 스택에 테스트 URL을 지정할 수 있습니다. 업데이트된 스택을 프로덕션 스택으로 마이그레이션할 준비가 되면 같은 쿡북을 사용하고 사용자 지정 JSON을 사용하여 지불 엔드포인트를 프로덕션 URL로 설정할 수 있습니다.
+ 특정 스택 또는 배포 명령에 고유한 값.

# 사용자 지정 OpsWorks 쿡북 속성을 사용하여 스택 속성 재정의
<a name="workingcookbook-cookbook-attributes"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
Windows 스택의 경우 OpsWorks Stacks는 기본 제공 레시피와 사용자 지정 레시피에 별도의 Chef 실행을 사용합니다. 즉, 이 섹션에 설명된 기법을 사용해서는 Windows 스택의 내장 속성을 재정의할 수 없습니다.

사용자 지정 JSON은 Stacks 스택 구성 및 내장 OpsWorks 쿡북 속성을 재정의하는 편리한 방법이지만 몇 가지 제한이 있습니다. 특히 사용 시마다 사용자 지정 JSON을 수동으로 입력해야 하므로 정의를 관리할 확실한 방법이 없습니다. 더 좋은 방법은 사용자 지정 쿡북 속성 파일을 사용하여 내장 속성을 재정의하는 것입니다. 이렇게 하면 소스 제어 아래에 정의를 배치할 수 있습니다.

사용자 지정 속성 파일을 사용하여 OpsWorks Stacks 정의를 재정의하는 절차는 간단합니다.

**Stacks 속성 OpsWorks 정의를 재정의하려면**

1. [쿡북과 레시피](workingcookbook.md) 단원의 설명에 따라 쿡북 리포지토리를 설정합니다.

1. 재정의할 속성이 포함된 내장 쿡북과 같은 이름으로 쿡북을 생성합니다. 예를 들어 Apache 속성을 재정의하려면 쿡북의 이름을 apache2로 지정해야 합니다.

1. 쿡북에 `attributes` 폴더를 추가하고 `customize.rb` 폴더에 파일을 추가합니다.

1. 재정의할 내장 쿡북의 속성별로 이 파일에 속성 정의를 추가하고 원하는 값으로 설정합니다. 속성은 `normal` 유형 이상이어야 하며 해당 OpsWorks Stacks 속성과 노드 이름이 정확히 동일해야 합니다. 노드 이름을 포함한 OpsWorks Stacks 속성의 자세한 목록은 [스택 구성 및 배포 속성: Linux](attributes-json-linux.md) 및 섹션을 참조하세요[내장 쿡북 속성](attributes-recipes.md). 속성 및 속성 파일에 대한 자세한 정보는 [속성 파일 정보](http://docs.chef.io/attributes.html)를 참조하세요.
**중요**  
 OpsWorks Stacks 속성을 재정의하려면 속성`normal`이 유형이어야 합니다. `default` 유형에는 우선 순위가 없습니다. 예를 들어, `customize.rb` 파일에 `default[:apache][:keepalivetimeout] = 5` 속성 정의가 있어도 내장된 `apache.rb` 속성 파일의 해당 속성이 먼저 평가되면 그 속성이 우선 적용됩니다. 자세한 내용은 [속성 재정의](workingcookbook-attributes.md) 섹션을 참조하세요.

1. 재정의할 속성이 포함된 각 내장 쿡북에 대해 2 - 4단계를 반복합니다.

1. 스택에 대해 사용자 지정 쿡북을 활성화하고 Stacks가 OpsWorks 쿡북을 스택의 인스턴스에 다운로드하는 데 필요한 정보를 제공합니다. 자세한 내용은 [사용자 지정 쿡북 설치](workingcookbook-installingcustom-enable.md) 단원을 참조하십시오.

**참고**  
이 절차에 대한 완전한 안내는 [내장 속성 재정의](cookbooks-101-opsworks-attributes.md) 단원을 참조하세요.

이제 후속 수명 주기 이벤트, 배포 명령 및 스택 명령에 사용되는 노드 객체에 OpsWorks Stacks 값 대신 속성 정의가 포함됩니다.

예를 들어 `keepalivetimeout`에서 설명한 내장 `logrotate schedule` 및 [사용자 지정 JSON 지정 방법](workingcookbook-json-override.md#workingcookbook-json-override-specify) 설정을 재정의하려면 `apache2`apache 쿡북을 리포지토리에 추가하고 `customize.rb` 파일을 다음 콘텐츠와 함께 쿡북의 `attributes` 폴더에 추가합니다.

```
normal[:apache][:keepalivetimeout] = 5
normal[:apache][:logrotate][:schedule] = 'weekly'
```

**중요**  
연결된 내장 속성 파일의 사본을 수정하여 OpsWorks Stacks 속성을 재정의해서는 안 됩니다. 예를 들어 `apache.rb`를 `apache2/attributes` 폴더에 복사하고 일부 설정을 수정하는 경우, 기본적으로 내장 파일의 모든 속성이 재정의됩니다. 레시피는 사본의 속성 정의를 사용하고 내장 파일은 무시합니다. OpsWorks Stacks가 나중에 내장 속성을 수정하는 경우, 수동으로 사본을 업데이트하지 않는 한 레시피는 변경 사항에 액세스하지 못합니다.  
이런 상황을 피하기 위해 모든 내장 쿡북에는 `customize.rb` 명령을 통해 모든 모듈에 필요한 빈 `include_attribute` 속성이 포함되어 있습니다. `customize.rb` 사본의 속성을 재정의하면 이러한 특정 속성에만 영향을 미칠 수 있습니다. 레시피는 그 밖의 모든 속성 값을 내장 속성 파일에서 가져오며, 재정의하지 않은 속성의 현재 값을 자동으로 가져옵니다.  
이 방법은 쿡북 리포지토리의 속성 수를 적게 유지하도록 도움으로써 유지 관리 부담이 줄어들고 향후 업그레이드 관리가 쉬워집니다.

# 사용자 지정 템플릿을 사용하여 OpsWorks 스택 구성 파일 확장
<a name="workingcookbook-template-override"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
 OpsWorks Stacks는 Windows 스택의 Chef 실행을 Linux 스택의 경우와 다르게 처리하기 때문에 Windows 스택의 경우이 섹션에서 설명하는 기술을 사용할 수 없습니다.

OpsWorks Stacks는 템플릿을 사용하여 일반적으로 많은 설정의 속성에 의존하는 구성 파일과 같은 파일을 생성합니다. 사용자 지정 JSON 또는 사용자 지정 OpsWorks 쿡북 속성을 사용하여 Stacks 정의를 재정의하는 경우 기본 설정이 OpsWorks Stacks 설정 대신 구성 파일에 통합됩니다. 그러나 OpsWorks Stacks는 가능한 모든 구성 설정에 대한 속성을 반드시 지정하지는 않습니다. 일부 설정의 기본값을 수락하고 템플릿에서 직접 다른 설정을 하드코딩합니다. 해당하는 Stacks 속성이 없는 경우 사용자 지정 JSON 또는 사용자 지정 OpsWorks 쿡북 속성을 사용하여 기본 설정을 지정할 수 없습니다.

사용자 지정 템플릿을 생성해 추가 구성 설정을 포함하도록 구성 파일을 확장할 수 있습니다. 그런 다음 필요한 구성 설정이나 그 밖의 콘텐츠를 파일에 추가하고 하드코딩된 설정을 재정의할 수 있습니다. 템플릿에 대한 자세한 정보는 [템플릿](workingcookbook-installingcustom-components-templates.md) 단원을 참조하세요.

**참고**  
opsworks-agent.monitrc.erb를 *제외*한 어떤 내장 템플릿도 재정의할 수 있습니다.

**사용자 지정 템플릿을 생성하려면**

1. 내장 쿡북과 동일한 구조 및 디렉터리 이름으로 쿡북을 생성합니다. 그런 다음 해당 디렉터리에서 사용자 지정하려는 내장 템플릿과 동일한 이름을 가진 템플릿 파일을 만듭니다. 예를 들어 사용자 지정 템플릿을 사용하여 Apache `httpd.conf` 구성 파일을 확장하려는 경우 리포지토리에서 `apache2` 쿡북을 구현해야 하고 템플릿 파일은 `apache2/templates/default/apache.conf.erb`여야 합니다. 정확히 동일한 이름을 사용하면 OpsWorks Stacks가 사용자 지정 템플릿을 인식하고 기본 제공 템플릿 대신 사용할 수 있습니다.

   [내장 쿡북의 GitHub 리포지토리](https://github.com/aws/opsworks-cookbooks)에서 쿡북으로 내장 템플릿 파일을 복사한 다음 필요에 따라 수정하는 것이 가장 간단합니다.
**중요**  
사용자 지정하려는 템플릿 파일을 제외하고는 내장 쿡북에서 어떠한 파일도 복사하지 마십시오. 다른 유형의 쿡북 파일(예: 레시피)을 복사하면 중복 Chef 리소스가 생성되어 오류가 발생할 수 있습니다.

   또한 쿡북에는 사용자 지정 속성, 레시피 및 관련 파일이 포함될 수 있지만 파일 이름이 내장 파일 이름과 중복되면 안 됩니다.

1. 템플릿 파일을 사용자 지정하여 요구 사항을 충족하는 구성 파일을 생성합니다. 설정을 더 추가하고, 기존 설정을 삭제하고, 하드코딩된 설정을 대체하는 등의 작업을 수행할 수 있습니다.

1. 아직 수행하지 않은 경우에는 스택 설정을 편집해 사용자 지정 쿡북을 사용하고 쿡북 리포지토리를 지정할 수 있습니다. 자세한 내용은 [사용자 지정 쿡북 설치](workingcookbook-installingcustom-enable.md) 섹션을 참조하세요.

**참고**  
이 절차에 대한 완전한 안내는 [내장 템플릿 재정의](cookbooks-101-opsworks-templates.md) 단원을 참조하세요.

템플릿을 재정의하기 위해 레시피를 구현하거나 [계층 구성에 레시피를 추가할](workingcookbook-assigningcustom.md) 필요가 없습니다. OpsWorks Stacks는 항상 기본 제공 레시피를 실행합니다. 구성 파일을 생성하는 레시피를 실행할 때는 내장 템플릿 대신 사용자 지정 템플릿을 자동으로 사용합니다.

**참고**  
 OpsWorks Stacks가 기본 제공 템플릿을 변경하면 사용자 지정 템플릿이 동기화되지 않아 더 이상 제대로 작동하지 않을 수 있습니다. 예를 들어 템플릿이 종속 파일을 참조하고 파일 이름이 변경된다고 가정해 보겠습니다. OpsWorks Stacks는 이러한 변경을 자주 수행하지 않으며 템플릿이 변경되면 변경 사항을 나열하고 새 버전으로 업그레이드할 수 있는 옵션을 제공합니다. Stacks OpsWorks 리포지토리에서 변경 사항을 모니터링하고 필요에 따라 템플릿을 수동으로 업데이트해야 합니다.

# 계층 확장
<a name="workingcookbook-extend"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

 OpsWorks Stacks 속성 수정 또는 템플릿 사용자 지정으로 처리할 수 있는 것 이상으로 내장 계층을 사용자 지정해야 할 경우가 가끔 있습니다. 예를 들어 symlink를 생성하거나 파일 또는 폴더 모드를 설정하거나 추가 패키지를 설치하는 등의 작업이 필요하다고 가정해 봅시다. 최소 기능 이상을 제공하려면 사용자 지정 계층을 확장해야 합니다. 이 경우 사용자 지정 작업을 처리하기 위한 레시피로 하나 이상의 사용자 지정 쿡북을 구현해야 합니다. 이 항목에서는 레시피를 사용하여 계층을 확장하는 방법을 예시합니다.

Chef를 처음 사용하는 경우 먼저 다양한 일반적인 작업을 수행하기 위한 쿡북을 구현하는 기본적인 방법을 소개하는 [쿡북 101](cookbooks-101.md) 섹션을 읽어야 합니다. 사용자 지정 계층을 구현하는 방법의 상세한 예는 [사용자 지정 Tomcat 서버 계층 생성](create-custom.md) 단원을 참조하세요.

**Topics**
+ [레시피를 사용하여 스크립트 실행](workingcookbook-extend-scripts.md)
+ [Chef 배포 후크 사용](workingcookbook-extend-hooks.md)
+ [Linux 인스턴스에서 Cron 작업 실행](workingcookbook-extend-cron.md)
+ [Linux 인스턴스에서 패키지 설치 및 구성](workingcookbook-extend-package.md)

# 레시피를 사용하여 스크립트 실행
<a name="workingcookbook-extend-scripts"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

필요한 사용자 지정 작업을 수행하는 스크립트가 이미 있는 경우 가장 간편하게 계층을 확장하는 방법은 종종 스크립트를 실행하기 위한 간단한 레시피를 구현하는 것입니다. 그런 다음 레시피를 적절한 수명 주기 이벤트(일반적으로 설정 또는 Deploy)에 할당하거나 `execute_recipes` 스택 명령을 사용하여 수동으로 레시피를 실행할 수 있습니다.

다음 예제는 Linux 인스턴스에서 shell 스크립트를 실행하지만, Windows PowerShell 스크립트 등 다른 유형의 스크립트에도 동일한 접근 방식을 사용할 수 있습니다.

```
cookbook_file "/tmp/lib-installer.sh" do
  source "lib-installer.sh"
  mode 0755
end

execute "install my lib" do
  command "sh /tmp/lib-installer.sh"
end
```

`cookbook_file` 리소스는 쿡북의 `files` 디렉터리 내 하위 디렉터리에 저장된 파일을 나타내며, 파일을 인스턴스의 지정된 위치로 전송합니다. 이 예제에서는 shell 스크립트 `lib-installer.sh`를 인스턴스의 `/tmp` 디렉터리로 전송하고 파일의 모드를 `0755`로 설정합니다. 자세한 정보는 [cookbook\$1file](https://docs.chef.io/chef/resources.html#cookbook-file) 단원을 참조하세요.

`execute` 리소스는 명령을 나타냅니다(예: shell 명령). 이 예제에서는 `lib-installer.sh`를 실행합니다. 자세한 정보는 [실행](https://docs.chef.io/chef/resources.html#execute)을 참조하세요.

또한 스크립트를 레시피에 통합하여 레시피를 실행할 수도 있습니다. 다음 예제는 bash 스크립트를 실행하지만 Chef는 Csh, Perl, Python 및 Ruby도 지원합니다.

```
script "install_something" do
  interpreter "bash"
  user "root"
  cwd "/tmp"
  code <<-EOH
    #insert bash script
  EOH
end
```

`script` 리소스는 스크립트를 나타냅니다. 예제에서는 bash 인터프리터를 지정하고, 사용자를 `"root"`로 설정하고, 작업 디렉터리를 `/tmp`로 설정합니다. 그런 다음 `code` 블록의 bash 스크립트를 실행합니다. 이 스크립트는 필요한 만큼 많은 줄을 포함할 수 있습니다. 자세한 정보는 [script](https://docs.chef.io/chef/resources.html#script)를 참조하세요.

레시피를 사용하여 스크립트를 실행하는 방법에 대한 자세한 정보는 [예제 7: 명령 및 스크립트 실행](cookbooks-101-basics-commands.md) 단원을 참조하세요. Windows 인스턴스에서 PowerShell을 실행하는 방법에 대한 예제는 [Windows PowerShell 스크립트 실행](cookbooks-101-opsworks-opsworks-powershell.md) 단원을 참조하세요.

# Chef 배포 후크 사용
<a name="workingcookbook-extend-hooks"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

필요한 작업을 수행하기 위한 사용자 지정 레시피를 구현하고 적절한 계층의 설정 이벤트에 레시피를 할당하여 배포를 사용자 지정할 수 있습니다. 대안적이고 때로는 더 간단한 접근 방식(특히 다른 목적으로 쿡북을 구현할 필요가 없는 경우)은 Chef 배포 후크를 사용하여 사용자 지정 코드를 실행하는 것입니다. 또한 사용자 지정 Deploy 레시피는 내장 레시피가 배포를 이미 완료한 후에 실행됩니다. 배포 후크를 사용하면 배포 도중(예를 들어 앱의 코드가 리포지토리에서 체크아웃되었지만 Apache가 재시작되기 전) 상호 작용이 가능합니다.

Chef는 앱을 4개 단계로 배포합니다.
+ **체크아웃** - 리포지토리에서 파일을 다운로드합니다.
+ **마이그레이션** -필요에 따라 마이그레이션을 실행합니다.
+ **Symlink** - symlink를 생성합니다.
+ **재시작** - 애플리케이션을 다시 시작합니다.

Chef 배포 후크는 각 단계 완료 후 선택적으로 사용자 제공 Ruby 애플리케이션을 실행하여 배포를 간편하게 사용자 지정할 수 있는 방법을 제공합니다. 배포 후크를 사용하려면 Ruby 애플리케이션을 하나 이상 구현하여 앱의 `/deploy` 디렉터리에 배치합니다. (앱에 `/deploy` 디렉터리가 없으면 `APP_ROOT` 수준에서 디렉터리를 생성하세요.) 애플리케이션은 다음 이름 중 하나를 가져야 합니다. 이 이름은 실행 시점을 결정합니다.
+ `before_migrate.rb`는 체크아웃 단계 완료 후, 마이그레이션 단계 전에 실행됩니다.
+ `before_symlink.rb`는 마이그레이션 단계 완료 후, Symlink 단계 전에 실행됩니다.
+ `before_restart.rb`는 Symlink 단계 완료 후, 재시작 단계 전에 실행됩니다.
+ `after_restart.rb`는 재시작 단계가 완료된 후에 실행됩니다.

Chef 배포 후크는 레시피와 마찬가지로 표준 노드 구문을 사용하여 노드 객체에 액세스할 수 있습니다. 또한 배포 후크는 사용자가 지정한 모든 [앱 환경 변수](workingapps-creating.md#workingapps-creating-environment)의 값에 액세스할 수 있습니다. 그러나 `ENV["VARIABLE_NAME"]` 대신 `new_resource.environment["VARIABLE_NAME"] `을 사용하여 변수 값에 액세스해야 합니다.

# Linux 인스턴스에서 Cron 작업 실행
<a name="workingcookbook-extend-cron"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

Linux cron 작업은 cron 데몬이 지정된 일정으로 하나 이상의 명령을 실행하도록 지시합니다. 예를 들어 스택이 PHP 전자 상거래 애플리케이션을 지원한다고 가정하겠습니다. 서버가 매주 지정된 시간에 판매 보고서를 전송하도록 cron 작업을 설정할 수 있습니다. Cron에 대한 자세한 내용은 Wikipedia에서 [cron](http://en.wikipedia.org/wiki/Cron)을 참조하세요. Linux 기반 컴퓨터 또는 인스턴스에서 cron을 직접 실행하는 방법에 대한 자세한 정보는 Indiana University 지식 기반 웹 사이트에서 [What are cron and crontab, and how do I use them?](https://kb.iu.edu/d/afiz) 단원을 참조하세요.

SSH로 `cron` 작업에 연결하고 `crontab` 항목을 편집하여 개별 Linux 기반 인스턴스에서 cron 작업을 수동으로 설정할 수는 있지만, OpsWorks Stacks의 주된 장점 중 하나는 전체 인스턴스 계층에서 작업을 실행하도록 지시할 수 있다는 점입니다. 다음 절차에서는 PHP 앱 서버 계층의 인스턴스에서 `cron` 작업을 설정하는 방법을 설명하지만, 어떤 계층에서도 동일한 접근 방식을 사용할 수 있습니다.

**계층의 인스턴스에 대한 `cron` 작업을 설정하려면**

1. 이 작업을 설정하는 `cron` 리소스가 포함된 레시피를 사용하여 쿡북을 구현합니다. 이 예제에서는 레시피의 이름이 `cronjob.rb`라고 가정하고, 자세한 구현 정보는 뒤에서 설명합니다. 쿡북 및 레시피에 대한 자세한 내용은 [쿡북과 레시피](workingcookbook.md) 단원을 참조하세요.

1. 스택에 쿡북을 설치합니다. 자세한 내용은 [사용자 지정 쿡북 설치](workingcookbook-installingcustom-enable.md) 단원을 참조하십시오.

1.  OpsWorks Stacks가 다음 수명 주기 이벤트에 할당하여 계층의 인스턴스에서 레시피를 자동으로 실행하도록 합니다. 자세한 내용은 [자동으로 레시피 실행](workingcookbook-assigningcustom.md) 단원을 참조하십시오.
   + **설정** -이 이벤트에 할당`cronjob.rb`하면 OpsWorks Stacks가 모든 새 인스턴스에서 레시피를 실행하도록 지시합니다.
   + **배포** - `cronjob.rb`이 이벤트에 할당하면 앱을 계층에 배포하거나 재배포할 때 OpsWorks Stacks가 모든 온라인 인스턴스에서 레시피를 실행하도록 지시합니다.

   `Execute Recipes` 스택 명령을 사용하여 온라인 인스턴스에서 레시피를 수동으로 실행할 수도 있습니다. 자세한 내용은 [스택 명령 실행](workingstacks-commands.md) 섹션을 참조하세요.

다음은 서버로부터 판매 데이터를 수집하여 보고서를 전송하는 사용자 구현 PHP 애플리케이션을 매주 한 번 실행하도록 cron 작업을 설정하는 `cronjob.rb` 예제입니다. Cron 리소스를 사용하는 방법의 추가 예제는 [cron](https://docs.chef.io/chef/resources.html#cron)을 참조하세요.

```
cron "job_name" do
  hour "1"
  minute "10"
  weekday "6"
  command "cd /srv/www/myapp/current && php .lib/mailing.php"
end
```

`cron`은 `cron` 작업을 나타내는 Chef 리소스입니다. OpsWorks Stacks가 인스턴스에서 레시피를 실행하면 연결된 공급자가 작업 설정의 세부 정보를 처리합니다.
+ `job_name`은 `cron` 작업의 사용자 정의 이름입니다(예: `weekly report`).
+ `hour`/`minute`/`weekday`는 명령을 실행할 시점을 지정합니다. 이 예제는 명령을 매주 토요일 오전 1시 10분에 실행합니다.
+ `command`는 실행할 명령을 지정합니다.

  이 예제는 2개의 명령을 실행합니다. 첫 번째 명령은 `/srv/www/myapp/current` 디렉터리로 이동합니다. 두 번째 명령은 판매 데이터를 수집하고 보고서를 전송하는 사용자 구현 `mailing.php` 애플리케이션을 실행합니다.

**참고**  
`bundle` 명령은 기본적으로 `cron` 작업에 사용되지 않습니다. 그 이유는 OpsWorks Stacks가 `/usr/local/bin` 디렉터리에 번들러를 설치하기 때문입니다. `bundle` 작업에서 `cron`을 사용하려면 명시적으로 `/usr/local/bin` 경로를 cron 작업에 추가해야 합니다. 또한 `cron` 작업에서 \$1PATH 환경 변수가 확장되지 않을 수 있으므로, \$1PATH 변수의 확장에 의존하지 않고 필요한 경로 정보를 모두 명시적으로 추가하는 것이 모범 사례입니다. 다음 예제는 `cron` 작업에서 `bundle`을 사용하는 두 가지 방법을 보여줍니다.  

```
cron "my first task" do
  path "/usr/local/bin"
  minute "*/10"
  command "cd /srv/www/myapp/current && bundle exec my_command"
end
```

```
cron_env = {"PATH" => "/usr/local/bin"}
cron "my second task" do
  environment cron_env
  minute "*/10"
  command "cd /srv/www/myapp/current && /usr/local/bin/bundle exec my_command"
end
```

스택에 여러 애플리케이션 서버가 있는 경우 PHP 앱 서버 계층의 수명 주기 이벤트에 `cronjob.rb`를 할당하는 접근 방식은 이상적이지 않을 수 있습니다. 예를 들어 레시피가 계층의 모든 인스턴스에서 실행되므로 여러 보고서가 전송됩니다. 이보다 나은 접근 방식은 사용자 지정 계층을 사용하여 한 서버만 보고서를 전송하도록 하는 것입니다.

**계층의 인스턴스 중 하나에서만 레시피를 실행하려면**

1. 예를 들어, PHPAdmin이라는 사용자 지정 계층을 만들고 이 계층의 설정 및 Deploy 이벤트에 `cronjob.rb`를 할당합니다. 사용자 지정 계층에서 반드시 많은 레시피를 실행할 필요는 없습니다. 이 경우, PHPAdmin은 인스턴스에서 사용자 지정 레시피 하나를 실행하기만 하면 됩니다.

1. PHP 앱 서버 인스턴스 중 하나를 AdminLayer에 할당합니다. 인스턴스가 둘 이상의 계층에 속하는 경우 OpsWorks Stacks는 각 계층의 내장 및 사용자 지정 레시피를 실행합니다.

인스턴스 하나만 PHP 앱 서버 및 PHPAdmin 계층에 속하므로 `cronjob.rb`는 해당 인스턴스에서만 실행되고, 따라서 하나의 보고서만 전송됩니다.

# Linux 인스턴스에서 패키지 설치 및 구성
<a name="workingcookbook-extend-package"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

내장 계층은 특정 패키지만 지원합니다. 자세한 내용은 [계층](workinglayers.md) 섹션을 참조하세요. 연결된 설정, 구성 및 배포 작업을 처리할 사용자 지정 레시피를 구현하여 Redis 서버와 같은 다른 패키지를 설치할 수 있습니다. 경우에 따라서는 내장 계층을 확장하여 패키지를 계층의 표준 패키지와 함께 인스턴스에 설치하도록 하는 것이 최선의 접근 방식입니다. 예를 들어 PHP 애플리케이션을 지원하는 스택이 있고 Redis 서버를 포함시키기를 원할 경우 PHP 앱 서버 계층을 확장하고 계층의 인스턴스에서 PHP 애플리케이션 서버 이외에 Redis 서버를 구성할 수 있습니다.

일반적으로 패키지 설치 레시피는 다음과 같은 작업을 수행합니다.
+ 하나 이상의 디렉터리를 생성하고 각각 모드를 설정
+ 템플릿에서 구성 파일을 생성
+ 설치 관리자를 실행하여 인스턴스에 패키지를 설치
+ 하나 이상의 서비스를 시작

Tomcat 서버를 설치하는 방법의 예제는 [사용자 지정 Tomcat 서버 계층 생성](create-custom.md) 단원을 참조하세요. 이 항목에서는 사용자 지정 Redis 계층을 설정하는 방법을 설명하지만, 동일한 코드를 사용하여 내장 계층에서 Redis를 설치하고 구성할 수 있습니다. 다른 패키지를 설치하는 방법에 대한 예는 내장된 쿡북 [(https://github.com/aws/opsworks-cookbooks)](https://github.com/aws/opsworks-cookbooks)을 참조하세요.

# 사용자 지정 Tomcat 서버 계층 생성
<a name="create-custom"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이 항목에서는 Linux 스택용 사용자 지정 계층을 구성하는 방법을 설명합니다. 하지만 기본 원칙 및 일부 코드(특히 앱 배포 섹션)를 수정하면 Windows 스택용 사용자 지정 계층도 구현할 수 있습니다.

 OpsWorks Stacks 인스턴스에서 비표준 패키지를 사용하는 가장 간단한 방법은 [기존 계층을 확장하는 것입니다](workingcookbook-extend-package.md). 하지만 이 접근 방식은 계층이 인스턴스에 표준 및 비표준 패키지를 모두 설치하고 실행하므로 항상 바람직한 것은 아닙니다. 약간 까다롭지만 더 강력한 접근 방식은 사용자 지정 계층을 구현하는 것입니다. 이는 다음을 비롯해 계층의 인스턴스에 대해 거의 완벽한 제어를 제공합니다.
+ 설치될 패키지
+ 패키지가 구성되는 방법
+ 리포지토리에서 인스턴스로 앱을 배포하는 방법

콘솔 또는 API를 사용하여 [사용자 지정 계층](workinglayers-custom.md) 섹션에 설명된 대로 다른 계층과 거의 똑같이 사용자 지정 계층을 생성하고 관리합니다. 하지만 사용자 지정 계층의 내장 레시피는 Ganglia 클라이언트를 설치하여 Ganglia 마스터로 측정치를 보고하는 것과 같은 매우 기본적인 일부 작업만 수행합니다. 사용자 지정 계층의 인스턴스가 최소 기능 이상을 발휘하게 하려면 패키지 설치와 구성, 앱 배포 등의 작업을 처리하도록 Chef 레시피 및 관련 파일을 포함하는 하나 이상의 사용자 지정 쿡북을 구현해야 합니다. 하지만 모든 것을 처음부터 구현해야 하는 것은 아닙니다. 예를 들어 애플리케이션을 표준 리포지토리 중 하나에 저장하는 경우 내장 deploy 레시피를 사용하여 계층의 인스턴스에 애플리케이션을 설치하는 작업을 대부분 처리할 수 있습니다.

**참고**  
Chef를 처음 사용하는 경우 먼저 다양한 일반적인 작업을 수행하기 위한 쿡북을 구현하는 기본적인 방법을 소개하는 [쿡북 101](cookbooks-101.md) 섹션을 읽어야 합니다.

다음 안내서에서는 Tomcat 애플리케이션 서버를 지원하는 사용자 지정 계층을 구현하는 방법을 설명합니다. 이 계층은 Tomcat이라는 사용자 지정 쿡북을 기반으로 하며, 패키지 설치, 배포 등을 처리하는 레시피를 포함합니다. 이 안내서는 Tomcat 쿡북에서 발췌된 코드를 포함하고 있습니다. 전체 쿡북은 [GitHub 리포지토리](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/tomcat)에서 다운로드할 수 있습니다. [Opscode Chef](http://www.opscode.com/chef/)에 대해 잘 알지 못하는 경우 먼저 [쿡북과 레시피](workingcookbook.md) 섹션을 읽어야 합니다.

**참고**  
OpsWorks Stacks에는 프로덕션용 전체 기능을 갖춘 [Java 앱 서버 계층](layers-java.md)이 포함되어 있습니다. Tomcat 쿡북은 사용자 지정 계층을 구현하는 방법을 예시하는 것이 목적이므로 SSL과 같은 기능을 포함하지 않는 제한적 버전의 Tomcat만 지원합니다. 전체 기능을 제공하는 구현의 예는 내장 [opsworks\$1java](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.10/opsworks_java) 쿡북 단원을 참조하세요.

Tomcat 쿡북은 인스턴스가 다음과 같은 특성을 갖는 사용자 지정 계층을 지원합니다.
+ Apache 프런트 엔드를 포함하는 Tomcat Java 애플리케이션 서버를 지원함
+ 애플리케이션이 JDBC `DataSource` 객체를 사용하여 백 엔드 데이터 스토어로 사용되는 별도의 MySQL 인스턴스에 연결하는 것을 허용하도록 Tomcat이 구성됨

이 프로젝트의 쿡북에는 다수의 주요 구성 요소가 포함됩니다.
+ [속성 파일](create-custom-attributes.md)은 다양한 레시피가 사용하는 구성 파일을 포함하고 있습니다.
+ [설정 레시피](create-custom-setup.md)는 계층의 설정 [수명 주기 이벤트](workingcookbook-events.md)에 할당됩니다. 이 레시피는 인스턴스 부팅 후 실행되며 패키지 설치, 구성 파일 생성과 같은 작업을 수행합니다.
+ [Configure 레시피](create-custom-configure.md)는 계층의 Configure 수명 주기 이벤트에 할당됩니다. 스택의 구성이 변경된 후(주로 인스턴스가 온라인 상태가 되거나 오프라인 상태가 될 때) 실행되며 필요한 구성 변경을 모두 처리합니다.
+ [Deploy 레시피](create-custom-deploy.md)는 계층의 Deploy 수명 주기 이벤트에 할당됩니다. 이 레시피는 설정 레시피 이후 또한 사용자가 수동으로 앱을 배포하여 코드 및 관련 파일을 계층의 인스턴스에 설치할 때 실행되며, 서비스 재시작과 같은 관련 작업을 처리합니다.

마지막 섹션 [스택 생성 및 애플리케이션 실행](create-custom-stack.md)에서는 Tomcat 쿡북을 기반으로 한 사용자 지정 계층을 포함하는 스택을 생성하는 방법과 별도의 MySQL 계층에 속하는 인스턴스에서 실행되는 MySQL 데이터베이스로부터 데이터를 표시하는 간단한 JSP 애플리케이션을 배포하고 실행하는 방법을 설명합니다.

**참고**  
Tomcat 쿡북 레시피는 일부 OpsWorks Stacks 내장 레시피에 따라 달라집니다. 각 레시피의 출처를 명확히 하기 위해 이 항목에서는 Chef *cookbookname*::*recipename* 규칙을 사용하여 레시피를 식별합니다.

**Topics**
+ [속성 파일](create-custom-attributes.md)
+ [설정 레시피](create-custom-setup.md)
+ [Configure 레시피](create-custom-configure.md)
+ [Deploy 레시피](create-custom-deploy.md)
+ [스택 생성 및 애플리케이션 실행](create-custom-stack.md)

# 속성 파일
<a name="create-custom-attributes"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

레시피에 대해 알아보기 전에 먼저 Tomcat 쿡북의 속성 파일을 살펴보는 것이 유용합니다. 이 파일에는 레시피가 사용하는 다양한 구성 설정이 들어 있습니다. 속성은 필수는 아닙니다. 레시피 또는 템플릿에서 이들 값을 하드코딩할 수도 있습니다. 그러나 속성을 사용하여 구성 설정을 정의하는 경우 OpsWorks Stacks 콘솔 또는 API를 사용하여 설정을 변경할 때마다 레시피 또는 템플릿 코드를 다시 작성하는 것보다 더 간단하고 유연한 사용자 지정 JSON 속성을 정의하여 값을 수정할 수 있습니다. 이 접근 방식을 사용하면 예를 들어 여러 스택에 동일한 쿡북을 사용하되 각 스택마다 Tomcat 서버를 다르게 구성할 수 있습니다. 속성과 속성 재정의 방법에 대한 자세한 정보는 [속성 재정의](workingcookbook-attributes.md) 단원을 참조하세요.

다음 예제는 Tomcat 쿡북의 `default.rb` 디렉터리에 위치하는 전체 속성 파일 `attributes`입니다.

```
default['tomcat']['base_version'] = 6
default['tomcat']['port'] = 8080
default['tomcat']['secure_port'] = 8443
default['tomcat']['ajp_port'] = 8009
default['tomcat']['shutdown_port'] = 8005
default['tomcat']['uri_encoding'] = 'UTF-8'
default['tomcat']['unpack_wars'] = true
default['tomcat']['auto_deploy'] = true
case node[:platform]
when 'centos', 'redhat', 'fedora', 'amazon'
  default['tomcat']['java_opts'] = ''
when 'debian', 'ubuntu'
  default['tomcat']['java_opts'] = '-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC'
end
default['tomcat']['catalina_base_dir'] = "/etc/tomcat#{node['tomcat']['base_version']}"
default['tomcat']['webapps_base_dir'] = "/var/lib/tomcat#{node['tomcat']['base_version']}/webapps"
default['tomcat']['lib_dir'] = "/usr/share/tomcat#{node['tomcat']['base_version']}/lib"
default['tomcat']['java_dir'] = '/usr/share/java'
default['tomcat']['mysql_connector_jar'] = 'mysql-connector-java.jar'
default['tomcat']['apache_tomcat_bind_mod'] = 'proxy_http' # or: 'proxy_ajp'
default['tomcat']['apache_tomcat_bind_config'] = 'tomcat_bind.conf'
default['tomcat']['apache_tomcat_bind_path'] = '/tc/'
default['tomcat']['webapps_dir_entries_to_delete'] = %w(config log public tmp)
case node[:platform]
when 'centos', 'redhat', 'fedora', 'amazon'
  default['tomcat']['user'] = 'tomcat'
  default['tomcat']['group'] = 'tomcat'
  default['tomcat']['system_env_dir'] = '/etc/sysconfig'
when 'debian', 'ubuntu'
  default['tomcat']['user'] = "tomcat#{node['tomcat']['base_version']}"
  default['tomcat']['group'] = "tomcat#{node['tomcat']['base_version']}"
  default['tomcat']['system_env_dir'] = '/etc/default'
end
```

설정 자체에 대해서는 나중에 관련 섹션에서 설명합니다. 다음 참고 사항은 전반적으로 적용됩니다.
+ 노드 정의는 모두 `default` 유형이므로 [사용자 지정 JSON 속성](workingcookbook-json-override.md)으로 재정의할 수 있습니다.
+ 파일은 `case` 문을 사용하여 인스턴스의 운영 체제에 따라 일부 속성 값을 조건적으로 설정합니다.

  `platform` 노드는 Chef의 Ohai 도구에 의해 생성되며 인스턴스의 운영 체제를 표시합니다.

# 설정 레시피
<a name="create-custom-setup"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

설정 레시피는 계층의 설정 [수명 주기](workingcookbook-events.md) 이벤트에 할당되고 인스턴스 부팅 후 실행됩니다. 이 레시피는 패키지 설치, 구성 파일 생성, 서비스 시작과 같은 작업을 수행합니다. Setup 레시피 실행이 완료되면 OpsWorks Stacks는 [Deploy 레시피](create-custom-deploy.md)를 실행하여 앱을 새 인스턴스에 배포합니다.

**Topics**
+ [tomcat::설정](#create-custom-setup-setup)
+ [tomcat::install](#create-custom-setup-install)
+ [tomcat::service](#create-custom-setup-service)
+ [tomcat::container\$1config](#create-custom-setup-config)
+ [tomcat::apache\$1tomcat\$1bind](#create-custom-setup-bind)

## tomcat::설정
<a name="create-custom-setup-setup"></a>

`tomcat::setup` 레시피는 계층의 설정 수명 주기 이벤트에 할당됩니다.

```
include_recipe 'tomcat::install'
include_recipe 'tomcat::service'

service 'tomcat' do
  action :enable
end

# for EBS-backed instances we rely on autofs
bash '(re-)start autofs earlier' do
  user 'root'
  code <<-EOC
    service autofs restart
  EOC
  notifies :restart, resources(:service => 'tomcat')
end

include_recipe 'tomcat::container_config'
include_recipe 'apache2'
include_recipe 'tomcat::apache_tomcat_bind'
```

`tomcat::setup` 레시피는 대체로 메타 레시피입니다. Tomcat 및 관련 패키지를 설치하고 구성하는 세부 작업을 대부분 처리하는 일련의 종속 레시피가 포함됩니다. `tomcat::setup`의 첫 번째 부분은 다음 레시피를 실행합니다(각 레시피에 대해서는 나중에 설명).
+ [tomcat::install](#create-custom-setup-install) 레시피는 Tomcat 서버 패키지를 설치합니다.
+ [tomcat::service](#create-custom-setup-service) 레시피는 Tomcat 서비스를 설정합니다.

`tomcat::setup`의 중간 부분은 Tomcat 서비스를 활성화하고 시작합니다.
+ Chef [서비스 리소스](https://docs.chef.io/chef/resources.html#service)는 부팅 시 Tomcat 서비스를 활성화합니다.
+ Chef [bash 리소스](https://docs.chef.io/chef/resources.html#bash)는 Bash 스크립트를 실행하여 Amazon EBS 지원 인스턴스에 필요한 autofs 대몬(daemon)을 시작합니다. 그런 다음 이 리소스는 `service` 리소스에 Tomcat 서비스를 재시작하라고 알립니다.

  자세한 정보는 [autofs](https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/s2-nfs-config-autofs.html)(Amazon Linux) 또는 [Autofs](https://help.ubuntu.com/community/Autofs)(Ubuntu)를 참조하세요.

`tomcat::setup`의 마지막 부분은 구성 파일을 생성하고 프런트 엔드 Apache 서버를 설치하고 구성합니다.
+ [tomcat::container\$1config](#create-custom-setup-config) 레시피는 구성 파일을 생성합니다.
+ `apache2` 레시피(의 약어`apache2::default`)는 Apache 서버를 설치하고 구성하는 OpsWorks Stacks 기본 제공 레시피입니다.
+ [tomcat::apache\$1tomcat\$1bind](#create-custom-setup-bind) 레시피는 Apache 서버가 Tomcat 서버의 프런트 엔드로 기능하도록 구성합니다.

**참고**  
내장 레시피를 사용하여 일부 필요한 작업을 수행하면 시간과 노력을 아낄 수 있는 경우가 자주 있습니다. 이 레시피는 처음부터 Apache를 구현하는 것이 아니라 내장 `apache2::default` 레시피를 사용하여 Apache를 설치합니다. 내장 레시피를 사용하는 방법의 또 하나의 예는 [Deploy 레시피](create-custom-deploy.md) 단원을 참조하세요.

다음 섹션에서는 Tomcat 쿡북의 설정 레시피에 대해 보다 자세히 설명합니다. `apache2` 레시피에 대한 자세한 정보는 [opsworks-cookbooks/apache2](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.4/apache2)를 참조하세요.

## tomcat::install
<a name="create-custom-setup-install"></a>

`tomcat::install `레시피는 Tomcat 서버, OpenJDK, 그리고 MySQL 서버 연결을 처리하는 Java 커넥터 라이브러리를 설치합니다.

```
tomcat_pkgs = value_for_platform(
  ['debian', 'ubuntu'] => {
    'default' => ["tomcat#{node['tomcat']['base_version']}", 'libtcnative-1', 'libmysql-java']
  },
  ['centos', 'redhat', 'fedora', 'amazon'] => {
    'default' => ["tomcat#{node['tomcat']['base_version']}", 'tomcat-native', 'mysql-connector-java']
  },
  'default' => ["tomcat#{node['tomcat']['base_version']}"]
)

tomcat_pkgs.each do |pkg|
  package pkg do
    action :install
  end
end

link ::File.join(node['tomcat']['lib_dir'], node['tomcat']['mysql_connector_jar']) do
  to ::File.join(node['tomcat']['java_dir'], node['tomcat']['mysql_connector_jar'])
  action :create
end

# remove the ROOT webapp, if it got installed by default
include_recipe 'tomcat::remove_root_webapp'
```

이 레시피가 수행하는 작업은 다음과 같습니다.

1. 인스턴스의 운영 체제에 따라 설치할 패키지의 목록을 생성합니다.

1. 목록의 각 패키지를 설치합니다.

   Chef [패키지 리소스](https://docs.chef.io/chef/resources.html#id146)는 Amazon Linux의 경우 `yum`와 Ubuntu의 경우 `apt-get`인 적절한 공급자를 사용하여 설치를 처리합니다. 패키지 공급자가 OpenJDK를 Tomcat 종속성으로 설치하지만, MySQL 커넥터 라이브러리는 명시적으로 설치되어야 합니다.

1. Chef [링크 리소스](https://docs.chef.io/chef/resources.html#link)를 사용하여 Tomcat 서버의 라이브러리 디렉터리에서 JDK 내 MySQL 커넥터 라이브러리에 대한 symlink를 생성합니다.

   기본 속성 값을 사용할 경우 Tomcat 라이브러리 디렉터리는 `/usr/share/tomcat6/lib`이고, MySQL 커넥터 라이브러리(`mysql-connector-java.jar`)는 `/usr/share/java/`에 위치합니다.

`tomcat::remove_root_webapp` 레시피는 ROOT 웹 애플리케이션(기본적으로 `/var/lib/tomcat6/webapps/ROOT`)을 제거하여 일부 보안 문제를 방지합니다.

```
ruby_block 'remove the ROOT webapp' do
  block do
    ::FileUtils.rm_rf(::File.join(node['tomcat']['webapps_base_dir'], 'ROOT'), :secure => true)
  end
  only_if { ::File.exists?(::File.join(node['tomcat']['webapps_base_dir'], 'ROOT')) && !::File.symlink?(::File.join(node['tomcat']['webapps_base_dir'], 'ROOT')) }
end
```

`only_if` 문은 파일이 존재하는 경우에만 레시피가 파일을 제거하도록 합니다.

**참고**  
Tomcat 버전은 `['tomcat']['base_version']` 속성에 의해 지정되는데, 속성 파일에서 6으로 설정되어 있습니다. Tomcat 7을 설치하려면 사용자 지정 JSON 속성을 사용하여 속성을 재정의할 수 있습니다. [스택 설정을 편집](workingstacks-edit.md)하고 다음 JSON을 [**사용자 지정 Chef JSON**] 상자에 입력하거나 기존의 사용자 지정 JSON에 추가하면 됩니다.  

```
{
  'tomcat' : {
    'base_version' : 7
  }
}
```
사용자 지정 JSON 속성은 기본 속성을 재정의하고 Tomcat 버전을 7로 설정합니다. 속성 재정의에 대한 자세한 정보는 [속성 재정의](workingcookbook-attributes.md) 단원을 참조하세요.

## tomcat::service
<a name="create-custom-setup-service"></a>

`tomcat::service` 레시피는 Tomcat 서비스 정의를 생성합니다.

```
service 'tomcat' do
  service_name "tomcat#{node['tomcat']['base_version']}"

  case node[:platform]
  when 'centos', 'redhat', 'fedora', 'amazon'
    supports :restart => true, :reload => true, :status => true
  when 'debian', 'ubuntu'
    supports :restart => true, :reload => false, :status => true
  end

  action :nothing
end
```

이 레시피는 Chef [서비스 리소스](https://docs.chef.io/chef/resources.html#service)를 사용하여 Tomcat 서비스 이름(기본적으로 tomcat6)을 지정하고 `supports` 속성을 설정하여 Chef가 운영 체제별로 서비스의 restart, reload 및 status 명령을 관리하는 방법을 정의합니다.
+ `true`는 Chef가 init 스크립트 또는 그 밖의 서비스 공급자를 사용하여 명령을 실행할 수 있음을 나타냅니다.
+ `false`는 Chef가 다른 수단을 사용하여 명령을 실행하려 시도해야 함을 나타냅니다.

`action`은 `:nothing`로 설정됩니다. 각 수명 주기 이벤트에 대해 OpsWorks Stacks는 [Chef 실행](https://docs.chef.io/chef_client_overview.html#the-chef-client-run)을 시작하여 적절한 레시피 세트를 실행합니다. Tomcat 쿡북은 레시피가 서비스 정의를 생성하지만 서비스를 재시작하지는 않는 일반 패턴을 따릅니다. Chef 실행의 다른 레시피가 일반적으로 구성 파일을 생성하는 데 사용된 `notifies` 리소스에 `template` 명령을 포함시켜 재시작을 처리합니다. 알림은 서비스를 재시작하는 편리한 방법입니다. 구성이 변경된 경우에만 서비스를 재시작하기 때문입니다. 또한 Chef 실행에 특정 서비스에 대한 재시작 알림이 여러 개일 경우 Chef는 서비스를 한 번만 재시작합니다. 이 방법은 완전히 작동하지 않는 서비스를 재시작하려고 시도할 때 발생할 수 있는 문제를 방지하기 위한 것으로, 이 문제는 Tomcat 오류의 일반적인 원인입니다.

 Tomcat 서비스는 재시작 알림을 사용하는 모든 Chef 실행에 대해 정의되어야 합니다. `tomcat::service`는 여러 레시피에 포함되어 서비스가 모든 Chef 실행에 대해 정의되도록 합니다. Chef 실행에 `tomcat::service` 인스턴스가 여러 번 포함되더라도 Chef는 포함 횟수와 상관없이 Chef 실행당 한 번만 레시피를 실행하므로 페널티는 없습니다.

## tomcat::container\$1config
<a name="create-custom-setup-config"></a>

`tomcat::container_config` 레시피는 쿡북 템플릿 파일에서 구성 파일을 생성합니다.

```
include_recipe 'tomcat::service'

template 'tomcat environment configuration' do
  path ::File.join(node['tomcat']['system_env_dir'], "tomcat#{node['tomcat']['base_version']}")
  source 'tomcat_env_config.erb'
  owner 'root'
  group 'root'
  mode 0644
  backup false
  notifies :restart, resources(:service => 'tomcat')
end

template 'tomcat server configuration' do
  path ::File.join(node['tomcat']['catalina_base_dir'], 'server.xml')
  source 'server.xml.erb'
  owner 'root'
  group 'root'
  mode 0644
  backup false
  notifies :restart, resources(:service => 'tomcat')
end
```

이 레시피는 먼저 `tomcat::service`를 호출합니다. 필요할 경우 이 레시피가 서비스를 정의합니다. 레시피의 대부분은 2개의 [템플릿 리소스](https://docs.chef.io/chef/resources.html#template)로 구성되는데, 각각 쿡북의 템플릿 파일 중 하나에서 구성 파일을 생성하고, 파일 속성을 설정하고, Chef에 서비스를 재시작하라고 알립니다.

### Tomcat 환경 구성 파일
<a name="create-custom-setup-config-env"></a>

첫 번째 `template` 리소스는 `tomcat_env_config.erb` 템플릿 파일을 사용하여 Tomcat 환경 구성 파일을 생성합니다. 이 파일은 `JAVA_HOME`과 같은 환경 변수를 설정하는 데 사용됩니다. 기본 파일 이름은 `template` 리소스의 인수입니다. `tomcat::container_config`는 `path` 속성을 사용하여 기본값을 재정의하고 구성 파일을 `/etc/sysconfig/tomcat6`(Amazon Linux) 또는 `/etc/default/tomcat6` (Ubuntu)로 명명합니다. 또한 `template` 리소스는 파일의 소유자, 그룹 및 모드 설정을 지정하고 Chef에게 백업 파일을 생성하지 않도록 지시합니다.

소스 코드를 보면 실제로 세 버전의 `tomcat_env_config.erb`가 각각 `templates` 디렉터리의 서로 다른 하위 디렉터리에 위치합니다. `ubuntu` 및 `amazon` 디렉터리에는 해당 운영 체제용 템플릿이 들어 있습니다. `default` 폴더에는 명령줄 하나로 구성된 더미 템플릿이 들어 있습니다. 이 템플릿은 지원되지 않는 운영 체제를 사용하는 인스턴스에서 이 레시피를 실행하려고 시도할 경우에만 사용됩니다. `tomcat::container_config` 레시피는 사용할 `tomcat_env_config.erb`를 지정할 필요가 없습니다. Chef가 [File Specificity](http://docs.chef.io/templates.html#file-specificity)에 기술된 규칙에 따라 인스턴스의 운영 체제에 적합한 디렉터리를 선택합니다.

이 예제의 `tomcat_env_config.erb` 파일은 대부분 주석으로 구성되어 있습니다. 추가 환경 변수를 설정하려면 해당 줄의 주석 처리를 해제하고 원하는 값을 제공하면 됩니다.

**참고**  
변경될 수 있는 구성 설정은 템플릿에서 하드코딩하는 것보다는 속성으로 정의해야 합니다. 그러면 설정을 변경하기 위해 템플릿을 재작성할 필요 없이 속성을 재정의하기만 하면 됩니다.

Amazon Linux 템플릿은 다음 코드에 나와 있듯이 하나의 환경 변수만 설정합니다.

```
...
# Use JAVA_OPTS to set java.library.path for libtcnative.so
#JAVA_OPTS="-Djava.library.path=/usr/lib"

JAVA_OPTS="${JAVA_OPTS} <%= node['tomcat']['java_opts'] %>"

# What user should run tomcat
#TOMCAT_USER="tomcat"
...
```

JAVA\$1OPTS를 사용하여 라이브러리 경로와 같은 Java 옵션을 지정할 수 있습니다. 기본 속성 값을 사용할 경우 템플릿은 Amazon Linux에 대해 어떤 Java 옵션도 설정하지 않습니다. `['tomcat']['java_opts']` 속성을 재정의하여(예를 들어 사용자 지정 JSON 속성을 사용하여) 자체 Java 옵션을 설정할 수 있습니다. 예제는 [스택 생성](create-custom-stack.md#create-custom-stack-stack) 섹션을 참조하세요.

Ubuntu 템플릿은 다음 템플릿 코드에 나와 있듯이 여러 환경 변수를 설정합니다.

```
# Run Tomcat as this user ID. Not setting this or leaving it blank will use the
# default of tomcat<%= node['tomcat']['base_version'] %>.
TOMCAT<%= node['tomcat']['base_version'] %>_USER=tomcat<%= node['tomcat']['base_version'] %>
...
# Run Tomcat as this group ID. Not setting this or leaving it blank will use
# the default of tomcat<%= node['tomcat']['base_version'] %>.
TOMCAT<%= node['tomcat']['base_version'] %>_GROUP=tomcat<%= node['tomcat']['base_version'] %>
...
JAVA_OPTS="<%= node['tomcat']['java_opts'] %>"

<% if node['tomcat']['base_version'].to_i < 7 -%>
# Unset LC_ALL to prevent user environment executing the init script from
# influencing servlet behavior.  See Debian bug #645221
unset LC_ALL
<% end -%>
```

기본 속성 값을 사용하면 템플릿은 다음과 같이 Ubuntu 환경 변수를 설정합니다.
+ `TOMCAT6_USER` 및 `TOMCAT6_GROUP`(Tomcat 사용자 및 그룹을 표시)이 모두 `tomcat6`으로 설정됩니다.

  ['tomcat']['base\$1version']을 `tomcat7`로 설정할 경우 변수 이름이 `TOMCAT7_USER` 및 `TOMCAT7_GROUP`로 확인되고, 모두 `tomcat7`로 설정됩니다.
+ `JAVA_OPTS`가 `-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC`로 설정됩니다.
  + `-Djava.awt.headless`를 `true`로 설정하면 그래픽 엔진에게 인스턴스가 헤드리스이고 콘솔이 없음을 알려줍니다. 이는 일부 그래픽 애플리케이션의 동작 오류를 해결합니다.
  + `-Xmx128m`은 JVM이 적절한 메모리 리소스를 사용하도록 지정합니다(이 예제에서는 128MB).
  + `-XX:+UseConcMarkSweepGC`는 동시 마크 스윕 가비지 수집을 지정합니다. 이는 가비지 수집으로 유발되는 일시 중지를 제한하는 데 도움이 됩니다.

    자세한 정보는 [Concurrent Mark Sweep Collector Enhancements](http://docs.oracle.com/javase/6/docs/technotes/guides/vm/cms-6.html)를 참조하세요.
+ Tomcat 버전이 7 미만일 경우 템플릿이 `LC_ALL`을 설정 해제합니다. 이는 Ubuntu 버그를 해결합니다.

**참고**  
기본 속성을 사용할 경우 이러한 환경 변수 중 일부가 기본값으로 설정됩니다. 하지만 명시적으로 환경 변수를 속성으로 설정하면 사용자 지정 JSON 속성을 정의하여 기본 속성을 재정의하고 사용자 지정 값을 제공할 수 있습니다. 속성 재정의에 대한 자세한 정보는 [속성 재정의](workingcookbook-attributes.md) 단원을 참조하세요.

전체 템플릿 파일은 [source code](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/tomcat)를 참조하세요.

### Server.xml 구성 파일
<a name="create-custom-setup-config-server"></a>

두 번째 `template` 리소스는 `server.xml.erb`를 사용하여 서블릿/JSP 컨테이너를 구성하는 [`system.xml` 구성 파일](http://tomcat.apache.org/tomcat-7.0-doc/config/)을 생성합니다. `server.xml.erb`에는 운영 체제별 설정이 없으므로 `template` 디렉터리의 `default` 하위 디렉터리에 위치합니다.

템플릿은 표준 설정을 사용하지만 Tomcat 6 또는 Tomcat 7에 대해 `system.xml` 파일을 생성할 수 있습니다. 예를 들어 템플릿의 서버 섹션에서 발췌된 다음 코드는 리스너를 지정된 버전에 따라 적절하게 구성합니다.

```
<% if node['tomcat']['base_version'].to_i > 6 -%>
  <!-- Security listener. Documentation at /docs/config/listeners.html
  <Listener className="org.apache.catalina.security.SecurityListener" />
  -->
<% end -%>
  <!--APR library loader. Documentation at /docs/apr.html -->
  <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
  <!--Initialize Jasper prior to webapps are loaded. Documentation at /docs/jasper-howto.html -->
  <Listener className="org.apache.catalina.core.JasperListener" />
  <!-- Prevent memory leaks due to use of particular java/javax APIs-->
  <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
<% if node['tomcat']['base_version'].to_i < 7 -%>
  <!-- JMX Support for the Tomcat server. Documentation at /docs/non-existent.html -->
  <Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" />
<% end -%>
  <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<% if node['tomcat']['base_version'].to_i > 6 -%>
  <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
<% end -%>
```

템플릿은 하드코딩된 설정 대신 속성을 사용합니다. 따라서 사용자 지정 JSON 속성을 정의하여 간편하게 설정을 변경할 수 있습니다. 예제:

```
<Connector port="<%= node['tomcat']['port'] %>" protocol="HTTP/1.1"
           connectionTimeout="20000"
           URIEncoding="<%= node['tomcat']['uri_encoding'] %>"
           redirectPort="<%= node['tomcat']['secure_port'] %>" />
```

자세한 정보는 [source code](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/tomcat)를 참조하세요.

## tomcat::apache\$1tomcat\$1bind
<a name="create-custom-setup-bind"></a>

`tomcat::apache_tomcat_bind` 레시피는 Apache 서버가 Tomcat의 프런트 엔드로 동작하여 수신 요청을 수신하고, 요청을 Tomcat으로 전달하고, 응답을 클라이언트로 반환하도록 설정합니다. 이 예제에서는 [mod\$1proxy](https://httpd.apache.org/docs/2.2/mod/mod_proxy.html)를 Apache 프록시/게이트웨이로 사용합니다.

```
execute 'enable mod_proxy for apache-tomcat binding' do
  command '/usr/sbin/a2enmod proxy'
  not_if do
    ::File.symlink?(::File.join(node['apache']['dir'], 'mods-enabled', 'proxy.load')) || node['tomcat']['apache_tomcat_bind_mod'] !~ /\Aproxy/
  end
end

execute 'enable module for apache-tomcat binding' do
  command "/usr/sbin/a2enmod #{node['tomcat']['apache_tomcat_bind_mod']}"
  not_if {::File.symlink?(::File.join(node['apache']['dir'], 'mods-enabled', "#{node['tomcat']['apache_tomcat_bind_mod']}.load"))}
end

include_recipe 'apache2::service'

template 'tomcat thru apache binding' do
  path ::File.join(node['apache']['dir'], 'conf.d', node['tomcat']['apache_tomcat_bind_config'])
  source 'apache_tomcat_bind.conf.erb'
  owner 'root'
  group 'root'
  mode 0644
  backup false
  notifies :restart, resources(:service => 'apache2')
end
```

`mod_proxy`를 활성화하려면 `proxy` 모듈과 프로토콜 기반 모듈을 활성화해야 합니다. 프로토콜 모듈에는 두 가지 옵션을 사용할 수 있습니다.
+ HTTP: `proxy_http`
+ [Apache JServ Protocol](http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html)(AJP): `proxy_ajp`

  AJP는 내부 Tomcat 프로토콜입니다.

레시피의 두 [실행 리소스](https://docs.chef.io/chef/resources.html#execute)가 모두 `a2enmod` 명령을 실행합니다. 따라서 필요한 symlink를 생성하여 지정된 모듈을 활성화할 수 있습니다.
+ 첫 번째 `execute` 리소스는 `proxy` 모듈을 활성화합니다.
+ 두 번째 `execute` 리소스는 프로토콜 모듈을 활성화합니다. 이 모듈은 기본적으로 `proxy_http`로 설정됩니다.

  AJP를 사용할 경우 사용자 지정 JSON을 정의하여 `apache_tomcat_bind_mod` 속성을 재정의하고 `proxy_ajp`로 설정할 수 있습니다.

`apache2::service` 레시피는 Apache 서비스를 정의하는 OpsWorks Stacks 기본 제공 레시피입니다. 자세한 내용은 OpsWorks Stacks GitHub 리포지토리의 [레시피](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.4/apache2/recipes/service.rb)를 참조하세요.

`template` 리소스는 `apache_tomcat_bind.conf.erb`를 사용하여 구성 파일을 생성하며, 이 파일의 기본 이름은 `tomcat_bind.conf`입니다. 그리고 리소스는 이 구성 파일을 `['apache']['dir']/.conf.d` 디렉터리에 저장합니다. `['apache']['dir']` 속성은 내장된 `apache2` 속성 파일에 정의되어 있으며, 기본적으로 `/etc/httpd`(Amazon Linux) 또는 `/etc/apache2`(Ubuntu)로 설정됩니다. `template` 리소스가 구성 파일을 생성하거나 변경할 경우 `notifies` 명령이 Apache 서비스 재시작을 예약합니다.

```
<% if node['tomcat']['apache_tomcat_bind_mod'] == 'proxy_ajp' -%>
ProxyPass <%= node['tomcat']['apache_tomcat_bind_path'] %> ajp://localhost:<%= node['tomcat']['ajp_port'] %>/
ProxyPassReverse <%= node['tomcat']['apache_tomcat_bind_path'] %> ajp://localhost:<%= node['tomcat']['ajp_port'] %>/
<% else %>
ProxyPass <%= node['tomcat']['apache_tomcat_bind_path'] %> http://localhost:<%= node['tomcat']['port'] %>/
ProxyPassReverse <%= node['tomcat']['apache_tomcat_bind_path'] %> http://localhost:<%= node['tomcat']['port'] %>/
<% end -%>
```

템플릿은 [ProxyPass](https://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypass) 및 [ProxyPassReverse](https://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypassreverse) 명령을 사용하여 Apache와 Tomcat 간에 트래픽을 전달하는 데 사용되는 포트를 구성합니다. 두 서버는 동일한 인스턴스에서 실행되므로 localhost URL을 사용할 수 있으며 모두 기본적으로 `http://localhost:8080`으로 설정됩니다.

# Configure 레시피
<a name="create-custom-configure"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 서비스 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

Configure 레시피는 계층의 Configure [수명 주기](workingcookbook-events.md) 이벤트에 할당됩니다. 이 이벤트는 특정 인스턴스가 온라인 상태로 전환되거나 해제될 때마다 스택의 모든 인스턴스에서 발생합니다. 변경 사항에 대응하여 적절히 인스턴스의 구성을 조정하려면 Configure 레시피를 사용합니다. Configure 레시피를 구현할 때 스택 구성 변경이 이 계층과 관계가 없는 인스턴스도 포함할 수 있다는 점을 염두에 두어야 합니다. 이 레시피는 적절히 대응할 수 있어야 합니다. 이는 경우에 따라 아무 작업도 하지 않음을 의미하기도 합니다.

## tomcat::configure
<a name="create-custom-configure-configure"></a>

`tomcat::configure` 레시피는 계층의 Configure 수명 주기 이벤트를 위한 것입니다.

```
include_recipe 'tomcat::context'
# Optional: Trigger a Tomcat restart in case of a configure event, if relevant
# settings in custom JSON have changed (e.g. java_opts/JAVA_OPTS):
#include_recipe 'tomcat::container_config'
```

`tomcat::configure` 레시피는 기본적으로 두 개의 종속 레시피를 실행하는 메타 레시피입니다.

1. `tomcat::context` 레시피는 웹 앱 컨텍스트 구성 파일을 생성합니다.

   이 파일은 애플리케이션이 MySQL 인스턴스와 통신하는 데 사용하는 JDBC 리소스를 구성합니다. 이에 대해서는 다음 섹션에서 설명합니다. Configure 이벤트에 대응하여 이 레시피를 실행할 경우 데이터베이스 계층이 변경되었을 때 웹 앱 컨텍스트 구성 파일을 업데이트할 수 있습니다.

1. `tomcat::container_config` 설정 레시피가 다시 실행되어 컨테이너 구성 변경 사항을 캡처합니다.

이 예제에서는 `include`의 `tomcat::container_config`가 코멘트 아웃됩니다. 사용자 지정 JSON을 사용하여 Tomcat 설정을 수정하려는 경우 이 주석을 제거할 수 있습니다. 그런 다음 Configure 수명 주기 이벤트가 `tomcat::container_config`를 실행합니다. 이는 Tomcat 관련 구성 파일을 업데이트하고([tomcat::container\$1config](create-custom-setup.md#create-custom-setup-config) 섹션 참조) Tomcat 서비스를 재시작합니다.

## tomcat::context
<a name="create-custom-configure-context"></a>

Tomcat 쿡북은 애플리케이션이 [J2EE DataSource](http://docs.oracle.com/javase/tutorial/jdbc/basics/sqldatasources.html) 객체를 사용하여 별도의 인스턴스에서 실행될 수 있는 MySQL 데이터베이스 서버에 액세스하도록 설정합니다. Tomcat에서는 각 애플리케이션에 대해 웹 엡 컨텍스트 구성 파일을 생성 및 설치하여 연결을 활성화할 수 있습니다. 이 파일은 애플리케이션과 애플리케이션이 데이터베이스와 통신하는 데 사용할 JDBC 리소스 간의 관계를 정의합니다. 자세한 정보는 [The Context Container](http://tomcat.apache.org/tomcat-7.0-doc/config/context.html)를 참조하세요.

`tomcat::context` 레시피의 주된 목적은 이 구성 파일을 생성하는 것입니다.

```
include_recipe 'tomcat::service'

node[:deploy].each do |application, deploy|
  context_name = deploy[:document_root].blank? ? application : deploy[:document_root]

  template "context file for #{application} (context name: #{context_name})" do
    path ::File.join(node['tomcat']['catalina_base_dir'], 'Catalina', 'localhost', "#{context_name}.xml")
    source 'webapp_context.xml.erb'
    owner node['tomcat']['user']
    group node['tomcat']['group']
    mode 0640
    backup false
    only_if { node['datasources'][context_name] }
    variables(:resource_name => node['datasources'][context_name], :webapp_name => application)
    notifies :restart, resources(:service => 'tomcat')
  end
end
```

Tomcat OpsWorks 쿡북 속성 외에도이 레시피는 [Stacks가 구성 이벤트와 함께 설치하는 스택 구성 및 배포 속성을](workingcookbook-json.md) 사용합니다. OpsWorks Stacks 서비스는 레시피가 일반적으로 데이터 백을 사용하거나 각 인스턴스에 속성을 검색하여 얻는 정보를 포함하는 속성을 각 인스턴스의 노드 객체에 추가합니다. 이러한 속성에는 스택 구성, 배포된 앱, 사용자가 포함시키기 원하는 사용자 지정 데이터에 대한 세부 정보가 포함됩니다. 레시피는 표준 Chef 노드 구문을 사용하여 스택 구성 및 배포 속성에서 데이터를 가져옵니다. 자세한 내용은 [스택 구성 및 배포 속성](workingcookbook-json.md) 섹션을 참조하세요. Chef 11.10 스택에서는 Chef 검색을 사용하여 스택 구성 및 배포 데이터를 가져올 수도 있습니다. 자세한 내용은 [Chef 검색 사용](workingcookbook-chef11-10.md#workingcookbook-chef11-10-search) 단원을 참조하십시오.

`deploy` 속성은 콘솔 또는 API를 통해 정의되거나 OpsWorks Stacks 서비스에 의해 생성되는 배포 관련 속성을 포함하는 `[:deploy]` 네임스페이스를 나타냅니다. `deploy` 속성에는 배포된 각 앱마다 앱의 짧은 이름으로 명명된 속성이 하나씩 포함됩니다. 각각의 앱 속성에는 문서 루트(`[:deploy][:appname][:document_root]`)와 같이 앱의 특성을 정의하는 속성 세트가 포함됩니다.

`context` 레시피는 먼저 [tomcat::service](create-custom-setup.md#create-custom-setup-service)를 호출하여 서비스가 이 Chef 실행에 대해 정의되도록 합니다. 그런 다음 구성 파일의 이름(`context_name` 확장명 제외)을 표시하는 `.xml` 변수를 정의합니다. 기본 문서 루트를 사용하는 경우, `context_name`이 앱의 짧은 이름으로 설정됩니다. 그렇지 않은 경우 지정된 문서 루트로 설정됩니다. [스택 생성 및 애플리케이션 실행](create-custom-stack.md) 섹션에 설명된 예제는 문서 루트를 `"ROOT"`로 설정합니다. 따라서 컨텍스트는 ROOT이고 구성 파일 이름은 `ROOT.xml`입니다.

이 레시피는 배포된 앱의 목록이 많은 부분을 차지하며, 각 앱에 대해 `webapp_context.xml.erb` 템플릿을 사용하여 컨텍스트 구성 파일을 생성합니다. 예제는 앱을 하나만 배포하지만 `deploy` 속성의 정의는 앱 수와 상관없이 이를 앱 목록으로 처리하도록 요구합니다.

`webapp_context.xml.erb` 템플릿은 운영 체제를 구별하지 않으므로 `templates` 디렉터리의 `default` 하위 디렉터리에 위치합니다.

이 레시피는 다음과 같이 구성 파일을 생성합니다.
+ 기본 속성 값을 사용할 경우 구성 파일 이름은 `context_name.xml`로 설정되고 `/etc/tomcat6/Catalina/localhost/` 디렉터리에 설치됩니다.

  스택 구성 속성의 `['datasources']` 노드에는 각각 연결된 애플리케이션이 데이터베이스와 통신하는 데 사용할 JDBC 데이터 리소스에 컨텍스트 이름을 매핑하는 속성이 하나 이상 포함됩니다. 노드 및 그 콘텐츠는 [스택 생성 및 애플리케이션 실행](create-custom-stack.md) 섹션에 설명된 대로 스택을 생성할 때 사용자 지정 JSON을 통해 정의됩니다. 예제에는 ROOT 컨텍스트 이름을 jdbc/mydb라는 JDBC 리소스와 연결하는 속성 하나가 있습니다.
+ 기본 속성 값을 사용하면 파일의 사용자 및 그룹 모두 Tomcat 패키지에 의해 설정됩니다. `tomcat`(Amazon Linux) 또는 `tomcat6`(Ubuntu).
+ `template` 리소스는 `['datasources']` 노드가 존재하고 `context_name` 속성을 포함하는 경우에만 구성 파일을 생성합니다.
+ `template` 리소스는 `resource_name` 및 `webapp_name`, 두 개의 변수를 정의합니다.

  `resource_name`은 `context_name`과 연결된 리소스 이름으로 설정되고, `webapp_name`은 앱의 짧은 이름으로 설정됩니다.
+ 템플릿 리소스는 Tomcat 서비스를 재시작하여 변경 사항을 로드하고 활성화합니다.

`webapp_context.xml.erb` 템플릿은 자체 속성 세트를 갖는 `Context` 요소를 포함하는 `Resource` 요소로 구성됩니다.

`Resource` 속성은 컨텍스트 구성의 특성을 정의합니다.
+ **name** - JDBC 리소스 이름. `tomcat::context`에서 정의된 `resource_name` 값으로 설정됩니다.

  예제에서는 리소스 이름이 jdbc/mydb로 설정됩니다.
+ **auth** 및 **type** - 이들은 JDBC `DataSource` 연결의 표준 설정입니다.
+ **maxActive**, **maxIdle** 및 **maxWait** - 최대 활성 연결 수, 최대 유휴 연결 수 및 연결이 반환되기까지 최대 대기 시간.
+ **username** 및 **password** - 데이터베이스의 사용자 이름 및 암호. `deploy` 속성에서 가져옵니다.
+ **driverClassName** - JDBC 드라이버의 클래스 이름. MySQL 드라이버로 설정됩니다.
+ **url** - 연결 URL.

  접두사는 데이터베이스에 따라 다릅니다. MySQL의 경우 `jdbc:mysql`, Postgres의 경우 `jdbc:postgresql`, SQL Server의 경우 `jdbc:sqlserver`로 설정되어야 합니다. 예제에서는 URL을 `jdbc:mysql://host_IP_Address:3306:simplejsp`로 설정합니다. 여기서 *simplejsp*는 앱의 짧은 이름입니다.
+ **factory** - `DataSource` 팩토리. MySQL 데이터베이스의 경우 필수입니다.

이 구성 파일에 대한 자세한 정보는 Tomcat wiki의 [Using DataSources](http://wiki.apache.org/tomcat/UsingDataSources) 항목 단원을 참조하세요.

# Deploy 레시피
<a name="create-custom-deploy"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 서비스 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

Deploy 레시피는 계층의 Deploy [수명 주기](workingcookbook-events.md) 이벤트에 할당됩니다. 이벤트를 지정된 인스턴스로만 선택적으로 제한할 수 있지만 일반적으로 앱을 배포할 때마다 스택의 모든 인스턴스에서 발생합니다. OpsWorks 스택은 Setup 레시피가 완료된 후 새 인스턴스에서 Deploy 레시피도 실행합니다. Deploy 레시피의 주된 목적은 코드와 관련 파일을 리포지토리에서 애플리케이션 서버 계층의 인스턴스에 배포하는 것입니다. 하지만 다른 계층에서도 Deploy 레시피를 실행하는 경우가 종종 있습니다. 그러면 예를 들어 해당 계층의 인스턴스가 구성을 업데이트하여 새로 개발된 앱을 수용할 수 있습니다. Deploy 레시피를 구현할 때 Deploy 이벤트가 반드시 앱이 인스턴스에 배포되는 것을 의미하지는 않음을 염두에 두어야 합니다. 단지 인스턴스가 필요한 업데이트를 할 수 있도록 스택 내 다른 인스턴스에 앱이 배포되고 있다는 알림일 수도 있습니다. 이 레시피는 적절히 대응할 수 있어야 합니다. 이는 아무 작업도 하지 않음을 의미하기도 합니다.

OpsWorks Stacks는 표준 앱 유형의 앱을 해당 내장 애플리케이션 서버 계층에 자동으로 배포합니다. 앱을 사용자 지정 계층에 배포하려면 앱의 파일을 리포지토리에서 인스턴스 내 적절한 위치로 다운로드하는 사용자 지정 Deploy 레시피를 구현해야 합니다. 하지만 내장 [배포 쿡북](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.4/deploy)을 사용하여 배포의 일부 측면을 처리함으로써 작성할 코드의 양을 줄일 수도 있습니다. 예를 들어 파일을 지원되는 리포지토리 중 하나에 저장할 경우 내장 쿡북이 리포지토리에서 계층의 인스턴스로 파일을 다운로드하는 세부 작업을 처리할 수 있습니다.

`tomcat::deploy` 레시피는 Deploy 수명 주기 이벤트에 할당됩니다.

```
include_recipe 'deploy'

node[:deploy].each do |application, deploy|
  opsworks_deploy_dir do
    user deploy[:user]
    group deploy[:group]
    path deploy[:deploy_to]
  end

  opsworks_deploy do
    deploy_data deploy
    app application
  end
...
```

`tomcat::deploy` 레시피는 애플리케이션에 고유하지 않은 배포에 대해 내장 배포 쿡북을 사용합니다. `deploy` 레시피(내장 `deploy::default` 레시피의 약칭)는 `deploy` 속성의 데이터를 기반으로 사용자, 그룹 등을 설정하는 세부 작업을 처리하는 내장 레시피입니다.

이 레시피는 두 개의 내장 Chef 정의 `opsworks_deploy_dir` 및 `opworks_deploy`를 사용하여 애플리케이션을 설치합니다.

`opsworks_deploy_dir` 정의는 앱의 배포 JSON에 포함된 데이터를 기반으로 디렉터리 구조를 설정합니다. 정의는 기본적으로 리소스 정의를 패키징하는 편리한 방법으로, `definitions` 디렉터리에 위치합니다. 레시피는 사용자 정의를 리소스와 거의 비슷하게 사용할 수 있지만, 정의 자체에는 연결된 공급자가 없고 정의에 포함된 리소스만 있습니다. 레시피에서 변수를 정의할 수 있습니다. 그러면 해당 변수가 기본 리소스 정의로 전달됩니다. `tomcat::deploy` 레시피는 배포 JSON의 데이터를 기반으로 `user`, `group` 및 `path` 변수를 설정합니다. 이들 변수는 정의의 디렉터리를 관리하는 [디렉터리 리소스](https://docs.chef.io/chef/resources.html#directory)로 전달됩니다.

**참고**  
배포된 앱의 사용자 및 그룹은 `[:opsworks][:deploy_user][:user]` 및 `[:opsworks][:deploy_user][:group]` 속성을 통해 결정되며, 각 속성은 [내장 배포 쿡북의 `deploy.rb` 속성 파일](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.4/deploy/attributes/deploy.rb)에서 정의됩니다. `[:opsworks][:deploy_user][:user]`의 기본값은 `deploy`입니다. `[:opsworks][:deploy_user][:group]`의 기본값은 인스턴스의 운영 체제에 따라 다릅니다.  
Ubuntu 인스턴스의 경우, 기본 그룹은 `www-data`입니다.
Nginx와 Unicorn을 사용하는 Rails 앱 서버 계층에 속하는 Amazon Linux 인스턴스의 경우, 기본 그룹은 `nginx`입니다.
다른 모든 Amazon Linux 인스턴스의 경우, 기본 그룹은 `apache`입니다.
사용자 지정 JSON 또는 사용자 지정 속성 파일을 사용하여 해당 속성을 재정의하면 설정을 변경할 수 있습니다. 자세한 내용은 [속성 재정의](workingcookbook-attributes.md) 섹션을 참조하세요.

다른 정의 `opsworks_deploy`는 `deploy` 속성에 포함된 데이터를 기반으로 앱의 코드와 관련 파일을 리포지토리에서 체크아웃하고 인스턴스에 배포하는 세부 작업을 처리합니다. 모든 앱 유형에서 이 정의를 사용할 수 있습니다. 디렉터리 이름과 같은 배포 세부 정보는 콘솔 또는 API를 통해 지정되며 `deploy` 속성에 포함됩니다. 하지만 `opsworks_deploy`는 Git, 하위 버전, S3 및 HTTP 등 네 개의 [지원되는 리포지토리 유형](workingcookbook-installingcustom-repo.md)에서만 사용할 수 있습니다. 다른 리포지토리 유형을 사용하려면 이 코드를 직접 구현해야 합니다.

앱의 파일은 Tomcat `webapps` 디렉터리에 설치합니다. 일반적인 방법은 파일을 `webapps`에 직접 복사하는 것입니다. 그러나 OpsWorks Stacks 배포는 인스턴스에 최대 5개의 앱 버전을 유지하도록 설계되었으므로 필요한 경우 이전 버전으로 롤백할 수 있습니다. 따라서 OpsWorks Stacks는 다음을 수행합니다.

1. 이름에 타임스탬프가 포함된 고유 디렉터리(예: `/srv/www/my_1st_jsp/releases/20130731141527`)에 앱을 배포합니다.

1. 이 고유 디렉터리에 대한 symlink를 생성하고 `current`로 명명합니다(예: `/srv/www/my_1st_jsp/current`).

1. 이미 존재하지 않으면 `webapps` 디렉터리에서 2단계에서 생성된 `current` symlink까지의 symlink를 생성합니다.

이전 버전으로 롤백해야 할 경우 `current` symlink를 해당하는 타임스탬프가 있는 고유 디렉터리를 가리키도록 수정합니다(예를 들어 `/srv/www/my_1st_jsp/current`의 링크 대상 변경).

`tomcat::deploy`의 중간 부분은 symlink를 설정합니다.

```
  ...
  current_dir = ::File.join(deploy[:deploy_to], 'current')
  webapp_dir = ::File.join(node['tomcat']['webapps_base_dir'], deploy[:document_root].blank? ? application : deploy[:document_root])

  # opsworks_deploy creates some stub dirs, which are not needed for typical webapps
  ruby_block "remove unnecessary directory entries in #{current_dir}" do
    block do
      node['tomcat']['webapps_dir_entries_to_delete'].each do |dir_entry|
        ::FileUtils.rm_rf(::File.join(current_dir, dir_entry), :secure => true)
      end
    end
  end

  link webapp_dir do
    to current_dir
    action :create
  end
  ...
```

이 레시피는 먼저 두 개의 변수 `current_dir` 및 `webapp_dir`을 생성하여 각각 `current` 및 `webapp` 디렉터리를 표시합니다. 그런 다음 `link` 리소스를 사용하여 `webapp_dir`를 `current_dir`에 링크합니다. OpsWorks Stacks `deploy::default` 레시피는이 예제에 필요하지 않은 일부 스텁 디렉터리를 생성하므로 발췌문의 중간 부분이 이를 제거합니다.

`tomcat::deploy`의 마지막 부분은 필요할 경우 Tomcat 서비스를 재시작합니다.

```
  ...
  include_recipe 'tomcat::service'

  execute 'trigger tomcat service restart' do
    command '/bin/true'
    not_if { node['tomcat']['auto_deploy'].to_s == 'true' }
    notifies :restart, resources(:service => 'tomcat')
  end
end

include_recipe 'tomcat::context'
```

이 레시피는 먼저 `tomcat::service`를 실행하여 서비스가 이 Chef 실행에 대해 정의되도록 합니다. 그런 다음 [실행 리소스](https://docs.chef.io/chef/resources.html#execute)를 사용하여 `['tomcat']['auto_deploy']`가 `'true'`로 설정된 경우에만 서비스를 재시작하라고 알립니다. 그렇지 않은 경우에는 Tomcat이 `webapps` 디렉터리의 변경 사항을 수신 대기합니다. 그러므로 명시적 Tomcat 서비스 재시작은 필요하지 않습니다.

**참고**  
`execute` 리소스가 실제로는 아무 것도 실행하지 않습니다. `/bin/true`는 단지 성공 코드를 반환하는 더미 shell 스크립트입니다. 여기서는 단지 재시작 알림을 생성하는 간편한 방법으로 사용됩니다. 앞서 언급한 대로, 알림을 사용하면 서비스가 너무 빈번히 재시작되지 않습니다.

마지막으로, `tomcat::deploy`는 `tomcat::context`를 실행합니다. 이는 백 엔드 데이터베이스가 변경된 경우 웹 앱 컨텍스트 구성 파일을 업데이트합니다.

# 스택 생성 및 애플리케이션 실행
<a name="create-custom-stack"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 서비스 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

이 섹션은 SimpleJSP라는 간단한 Java 서버 페이지(JSP) 애플리케이션을 실행하는 기본적인 스택 설정을 구현하기 위해 Tomcat 쿡북을 사용하는 방법을 보여줍니다. 스택은 TomCustom이라는 Tomcat 기반 사용자 지정 계층과 MySQL 계층으로 구성됩니다. SimpleJSP는 TomCustom에 배포되고 MySQL 데이터베이스로부터 일부 정보를 표시합니다. OpsWorks Stacks 사용 방법의 기본 사항에 익숙하지 않은 경우 먼저를 읽어야 합니다[Chef 11 Linux 스택 시작하기](gettingstarted.md).

## SimpleJSP 애플리케이션
<a name="create-custom-stack-jsp"></a>

SimpleJSP 애플리케이션은 데이터베이스 연결을 설정하고 스택의 MySQL 데이터베이스에서 데이터를 검색하는 방법의 기초를 보여줍니다.

```
<html>
  <head>
    <title>DB Access</title>
  </head>
  <body>
    <%@ 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:<br>");
        stmt = con.createStatement();
        rs = stmt.executeQuery("show databases");
        while (rs.next()) {
          output.append(rs.getString(1));
          output.append("<br>");
        }
      }
      catch (Exception e) {
        output.append("Exception: ");
        output.append(e.getMessage());
        output.append("<br>");
      }
      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("<br>");
        }
      }
    %>
    <%= output.toString() %>
  </body>
</html>
```

SimpleJSP는 `DataSource` 객체를 사용하여 MySQL 데이터베이스와 통신합니다. Tomcat은 [웹 앱 컨텍스트 구성 파일](create-custom-configure.md#create-custom-configure-context)의 데이터를 사용하여 `DataSource` 객체를 생성 및 초기화하고 논리적 이름에 바인딩합니다. 그런 다음 이 논리적 이름을 Java Naming and Directory Interface(JNDI) 이름 서비스에 등록합니다. `DataSource` 객체의 인스턴스를 가져오려면 `InitialContext` 객체를 생성하고 리소스의 논리적 이름을 객체의 `lookup` 메서드로 전달합니다. 이 메서드가 해당 객체를 검색합니다. SimpleJSP 예제의 논리적 이름 `java:comp/env/jdbc/mydb`는 다음 요소로 구성됩니다.
+ 이름의 나머지 부분과 콜론(:)으로 구분되는 루트 네임스페이스 `java`.
+ 슬래시(/)로 구분되는 추가 네임스페이스.

  Tomcat은 자동으로 리소스를 `comp/env` 네임스페이스에 추가합니다.
+ 웹 앱 컨텍스트 구성 파일에서 정의되고 슬래시로 네임스페이스와 구분되는 리소스 이름.

  이 예제에서는 리소스 이름이 `jdbc/mydb`입니다.

데이터베이스와 연결을 설정하기 위해 SimpleJSP는 다음을 수행합니다.

1. `DataSource` 객체의 `getConnection` 메서드를 호출합니다. 이 메서드는 `Connection` 객체를 반환홥니다.

1. `Connection` 객체의 `createStatement` 메서드를 호출하여 데이터베이스와 통신하는 데 사용할 `Statement` 객체를 생성합니다.

1. `Statement` 메서드를 호출하여 데이터베이스와 통신합니다.

   SimpleJSP는 `executeQuery`를 호출하여 서버의 데이터베이스를 나열하는 SHOW DATABASES 쿼리를 실행합니다.

`executeQuery` 메서드는 쿼리 결과를 포함하는 `ResultSet` 객체를 반환합니다. SimpleJSP는 반환된 `ResultSet` 객체에서 데이터베이스 이름을 가져오고 이들을 연결하여 출력 문자열을 생성합니다. 마지막으로 예제는 `ResultSet`, `Statement` 및 `Connection` 객체를 닫습니다. JSP 및 JDBC에 대한 자세한 정보는 각각 [JavaServer Pages Technology](http://docs.oracle.com/javaee/5/tutorial/doc/bnagx.html) 및 [JDBC Basics](http://docs.oracle.com/javase/tutorial/jdbc/basics/)를 참조하세요.

SimpleJSP를 스택에서 사용하려면 리포지토리에 배치해야 합니다. 지원되는 리포지토리를 모두 사용할 수 있지만, 다음 섹션에서 설명하는 예제 스택에서 SimpleJSP를 사용하려면 퍼블릭 S3 아카이브에 배치해야 합니다. 다른 표준 리포지토리를 사용하는 방법에 대한 자세한 정보는 [쿡북 리포지토리](workingcookbook-installingcustom-repo.md) 단원을 참조하세요.

**S3 아카이브 리포지토리에 SimpleJSP를 저장하려면**

1. 예제 코드를 `simplejsp.jsp` 파일에 복사한 다음 이 파일을 `simplejsp` 디렉터리에 저장합니다.

1. `simplejsp` 디렉터리의 `.zip` 아카이브를 생성합니다.

1. 퍼블릭 Amazon S3 버킷을 만들고, `simplejsp.zip`을 이 버킷에 업로드하고, 이 파일을 퍼블릭으로 설정합니다.

   이 작업을 수행하는 방법에 대한 자세한 설명은 [Amazon Simple Storage Service 시작하기](https://docs.aws.amazon.com/AmazonS3/latest/gsg/GetStartedWithS3.html)를 참조하세요.

## 스택 생성
<a name="create-custom-stack-stack"></a>

SimpleJSP를 실행하려면 다음 계층이 포함된 스택이 필요합니다.
+ 백 엔드 MySQL 서버를 지원하는 MySQL 계층.
+ Tomcat 쿡북을 사용하여 Tomcat 서버 인스턴스를 지원하는 사용자 지정 계층.

**스택을 생성하는 방법**

1.  OpsWorks 스택 대시보드에서 **스택 추가**를 클릭하여 새 스택을 생성하고 **고급 >>**를 클릭하여 모든 옵션을 표시합니다. 다음과 같이 스택을 구성합니다.
   + **이름** - 사용자 정의 스택 이름. 이 예에서는 TomStack을 사용합니다.
   + **사용자 지정 Chef 쿡북 사용** - 토글을 **예**로 설정합니다. 그러면 몇 가지 추가 옵션이 표시됩니다.
   + **리포지토리 유형** - Git
   + **리포지토리 URL** – `git://github.com/amazonwebservices/opsworks-example-cookbooks.git`.
   + **Custom Chef JSON** - 다음 JSON을 추가합니다.

     ```
     {
       "tomcat": {
         "base_version": 7,
         "java_opts": "-Djava.awt.headless=true -Xmx256m"
       },
       "datasources": {
         "ROOT": "jdbc/mydb"
       }
     }
     ```

   나머지 옵션의 경우 기본값을 수락할 수 있습니다.

   사용자 지정 JSON에서는 다음 작업을 수행합니다.
   + Tomcat 쿡북의 `['base_version']` 속성을 재정의해 Tomcat 버전을 7로 설정합니다. 기본값은 6입니다.
   + Tomcat 쿡북의 `['java_opts']` 속성을 재정의해 인스턴스가 헤드리스가 되도록 지정하고 JVM 최대 힙 크기를 256MB로 설정합니다. 기본값은 Amazon Linux를 실행하는 인스턴스에 대해 옵션을 설정하지 않는 것입니다.
   + `['datasources]` 속성 값을 지정합니다. 이 속성 값은 [tomcat::context](create-custom-configure.md#create-custom-configure-context) 단원에서 설명하는 것처럼 JDBC 리소스 이름(jdbc/mydb)을 웹 앱 컨텍스트 이름(ROOT)에 할당합니다.

     이 마지막 속성에는 기본값이 없습니다. 따라서 사용자 지정 JSON을 사용하여 값을 설정해야 합니다.  
![\[Configuration Management interface showing Chef version options and custom JSON input field.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/tom_add_stack.png)

1. [**계층 추가**]를 클릭합니다. [**계층 유형**]으로 **MySQL**을 선택합니다. 그런 다음 [**계층 추가**]를 클릭합니다.

1. 탐색 창에서 [**인스턴스**]를 클릭한 다음 [**인스턴스 추가**]를 클릭합니다. **인스턴스 추가**를 클릭하고 기본값을 수락합니다. 인스턴스에 해당하는 라인에서 [**시작**]을 클릭합니다.

1. [**계층**] 페이지로 돌아가 [**\$1 계층**]을 클릭하여 계층을 추가합니다. **Layer type(계층 유형)**으로 **사용자 지정**을 클릭합니다. 이 예제에서는 계층 이름 및 짧은 이름으로 각각 **TomCustom** 및 **tomcustom**을 사용합니다.  
![\[Add Layer form with Custom layer type, Name, and Short name fields for creating a customized layer.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/tom_add_custom_layer.png)

1. [**계층**] 페이지에서 사용자 지정 계층으로 [**레시피**]를 클릭하고 [**편집**]을 클릭합니다. [**사용자 지정 Chef 레시피**]에서 다음과 같이 계층의 수명 주기 이벤트에 Tomcat 쿡북 레시피를 할당합니다.
   + **설정**에 **tomcat::setup**을 입력하고 **\$1**를 클릭합니다.
   + **구성**에 **tomcat::configure**을 입력하고 **\$1**를 클릭합니다.
   + **배포**에 **tomcat::deploy**를 입력하고 **\$1**를 클릭합니다. 그런 다음 **저장**을 클릭합니다.

     .  
![\[Custom Chef Recipes interface showing setup, configure, and deploy steps with options.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/tom_events.png)

1. 탐색 창에서 [**앱**]을 클릭한 다음 [**앱 추가**]를 클릭합니다. 다음 옵션을 지정하고 [**앱 추가**]를 클릭합니다.
   + **이름** - 앱의 이름입니다. 예제에서는 SimpleJSP를 사용하며 OpsWorks Stacks에서 생성된 짧은 이름은 simplejsp입니다.
   + **앱 유형** - 이 옵션은 **기타**로 설정합니다.

     OpsWorks Stacks는 연결된 서버 인스턴스에 표준 앱 유형을 자동으로 배포합니다. **앱 유형**을 기타로 설정하면 OpsWorks Stacks에서는 Deploy 레시피를 실행하고 이 레시피에 따라 배포가 처리되도록 합니다.
   + [**문서 루트**] - 이 옵션은 **ROOT**으로 설정합니다.

     [**문서 루트**] 값은 컨텍스트 이름을 지정합니다.
   + **리포지토리 유형** - 이 옵션은 **S3 아카이브**로 설정합니다.
   + **리포지토리 URL** - 이 옵션은 앞에서 생성한 앱의 Amazon S3 URL로 설정합니다.

   다른 옵션에는 기본 설정을 사용합니다.  
![\[Application settings form with fields for name, app type, document root, and source details.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/tom_app.png)

1. **인스턴스** 페이지를 사용하여 TomCustom 계층에 인스턴스를 추가하고 시작합니다. OpsWorks 스택은 Setup 레시피가 완료된 후 새 인스턴스에서 Deploy 레시피를 자동으로 실행하므로 인스턴스를 시작하면 SimpleJSP도 배포됩니다.

1. TomCustom 인스턴스가 온라인 상태이면 [**인스턴스**] 페이지에서 인스턴스 이름을 클릭하여 세부 정보를 확인합니다. 퍼블릭 IP 주소를 복사합니다. 그런 다음 URL을 http://*publicIP*/tc/*appname.jsp* 형식으로 구성합니다. 예를 들어, 이 URL은 **http://50.218.191.172/tc/simplejsp.jsp**와 같습니다.
**참고**  
Tomcat에 요청을 전달하는 Apache URL은 기본 `['tomcat']['apache_tomcat_bind_path']` 속성이 `/tc/`로 설정되어 있습니다. SimpleJSP 문서 루트는 특수값인 `ROOT`로 설정되어 있으며 `/`로 해석됩니다. 따라서 URL은 ".../tc/simplejsp.jsp"입니다.

1. 이전 단계의 URL을 브라우저에 붙여 넣습니다. 다음과 같은 모양이어야 합니다.

   ```
   Databases found:
   information_schema
   simplejsp
   test
   ```
**참고**  
스택에 MySQL 인스턴스가 있는 경우 OpsWorks Stacks는 앱의 짧은 이름으로 이름이 지정된 각 앱에 대한 데이터베이스를 자동으로 생성합니다.

# 스택 구성 및 배포 속성
<a name="workingcookbook-json"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 서비스 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

 OpsWorks Stacks가 인스턴스에서 예를 들어 수명 주기 배포 이벤트에 대한 응답으로 배포 명령과 같은 명령을 실행하면 스택의 현재 구성을 설명하는 속성 집합이 인스턴스의 노드 객체에 추가됩니다. 배포 이벤트 및 [레시피 스택 명령 실행](workingstacks-commands.md)의 경우 OpsWorks Stacks는 몇 가지 추가 배포 정보를 제공하는 배포 속성을 설치합니다. 노드 객체에 대한 자세한 정보는 [속성 재정의](workingcookbook-attributes.md) 단원을 참조하세요. 정규화된 도메인 이름을 포함하여 일반적으로 사용되는 스택 구성 및 배포 속성의 목록은 [스택 구성 및 배포 속성: Linux](attributes-json-linux.md) 및 [내장 쿡북 속성](attributes-recipes.md)를 참조하세요.

**참고**  
Linux 스택에서는 에이전트 CLI의 [get\$1json 명령](agent-json.md)을 사용하여 JSON 객체로 형식 지정된 이러한 속성의 완전한 목록을 가져올 수 있습니다.

다음 섹션에서는 다음으로 구성된 간단한 스택의 Configure 이벤트 및 Deploy 이벤트에 연결된 속성을 보여 줍니다.
+ 두 개의 인스턴스가 있는 PHP 앱 서버 계층
+ 1개의 인스턴스가 포함된 HAProxy 계층

예제는 PHP 앱 서버 인스턴스 중 하나인 **php-app1**의 예제입니다. 편의상 속성은 JSON 객체로 형식이 지정되어 있습니다. 객체의 구조는 속성의 정규화된 이름에 매핑됩니다. 예를 들어 `node[:opsworks][:ruby_version]` 속성은 다음과 같이 JSON 표시로 나타납니다.

```
{
  "opsworks": {
    ...
    "ruby_version": "1.8.7",
    ...
  }
}
```

**Topics**
+ [Configure 속성](#workingcookbook-json-configure)
+ [배포 속성](#workingcookbook-json-deploy)

## Configure 속성
<a name="workingcookbook-json-configure"></a>

다음 JSON 객체는 인스턴스가 온라인 상태가 되거나 오프라인 상태가 될 때 스택의 모든 인스턴스에서 발생하는 Configure 이벤트의 속성을 보여 줍니다. 속성에는 내장 스택 구성 속성과 이벤트 전에 스택에 대해 구성된 [사용자 지정 JSON 속성](workingstacks-json.md)(이 예제에는 없음)이 포함됩니다. 속성은 길이를 위해 편집되었습니다. 다양한 속성에 대한 상세한 설명은 [스택 구성 및 배포 속성: Linux](attributes-json-linux.md) 및 [내장 쿡북 속성](attributes-recipes.md)를 참조하세요.

```
{
  "opsworks": {
    "layers": {
      "php-app": {
        "id": "4a2a56c8-f909-4b39-81f8-556536d20648",
        "instances": {
          "php-app2": {
            "elastic_ip": null,
            "region": "us-west-2",
            "booted_at": "2013-02-26T20:41:10+00:00",
            "ip": "192.0.2.0",
            "aws_instance_id": "i-34037f06",
            "availability_zone": "us-west-2a",
            "instance_type": "c1.medium",
            "private_dns_name": "ip-10-252-0-203.us-west-2.compute.internal",
            "private_ip": "10.252.0.203",
            "created_at": "2013-02-26T20:39:39+00:00",
            "status": "online",
            "backends": 8,
            "public_dns_name": "ec2-192-0-2-0.us-west-2.compute.amazonaws.com"
          },
          "php-app1": {
            ...
          }
        },
        "name": "PHP Application Server"
      },
      "lb": {
        "id": "15c86142-d836-4191-860f-f4d310440f14",
        "instances": {
          "lb1": {
           ...
          }
        },
        "name": "Load Balancer"
      }
    },
    "agent_version": "104",
    "applications": [

    ],
    "stack": {
      "name": "MyStack"
    },
    "ruby_version": "1.8.7",
    "sent_at": 1361911623,
    "ruby_stack": "ruby_enterprise",
    "instance": {
      "layers": [
        "php-app"
      ],
      "region": "us-west-2",
      "ip": "192.0.2.0",
      "id": "45ef378d-b87c-42be-a1b9-b67c48edafd4",
      "aws_instance_id": "i-32037f00",
      "availability_zone": "us-west-2a",
      "private_dns_name": "ip-10-252-84-253.us-west-2.compute.internal",
      "instance_type": "c1.medium",
      "hostname": "php-app1",
      "private_ip": "10.252.84.253",
      "backends": 8,
      "architecture": "i386",
      "public_dns_name": "ec2-192-0-2-0.us-west-2.compute.amazonaws.com"
    },
    "activity": "configure",
    "rails_stack": {
      "name": null
    },
    "deployment": null,
    "valid_client_activities": [
      "reboot",
      "stop",
      "setup",
      "configure",
      "update_dependencies",
      "install_dependencies",
      "update_custom_cookbooks",
      "execute_recipes"
    ]
  },
  "opsworks_custom_cookbooks": {
    "recipes": [

    ],
    "enabled": false
  },
  "recipes": [
    "opsworks_custom_cookbooks::load",
    "opsworks_ganglia::configure-client",
    "ssh_users",
    "agent_version",
    "mod_php5_apache2::php",
    "php::configure",
    "opsworks_stack_state_sync",
    "opsworks_custom_cookbooks::execute",
    "test_suite",
    "opsworks_cleanup"
  ],
  "opsworks_rubygems": {
    "version": "1.8.24"
  },
  "ssh_users": {
  },
  "opsworks_bundler": {
    "manage_package": null,
    "version": "1.0.10"
  },
  "deploy": {
  }
}
```

대부분의 정보는 흔히 네임스페이스라고 하는 `opsworks` 속성 아래에 있습니다. 다음 목록은 주요 속성을 설명합니다.
+ `layers` 속성 - 각각 스택의 계층 중 하나의 구성을 설명하는 속성의 집합.

  계층은 짧은 이름(이 예제의 경우, `php-app` 및 `lb`)으로 식별됩니다. 기타 계층의 짧은 이름에 대한 자세한 정보는 [OpsWorks Stacks 계층 참조](layers.md)를 참조하세요.
+ `instances` 속성 - 모든 계층에는 인스턴스의 짧은 이름으로 명명된, 계층의 온라인 인스턴스 각각의 속성을 포함하는 `instances` 요소가 있습니다.

  PHP 앱 서버 계층에는 `php-app1`과 `php-app2`라는 2개의 인스턴스가 있습니다. HAProxy 계층에는 1개의 인스턴스(`lb1`)가 있습니다.
**참고**  
`instances` 요소에는 특정 스택 및 배포 속성이 생성될 때 온라인 상태인 인스턴스만이 포함됩니다.
+ 인스턴스 속성 - 각각의 인스턴스 속성에는 인스턴스의 프라이빗 IP 주소와 프라이빗 DNS 이름 등 인스턴스를 특징짓는 속성 집합이 포함됩니다. 간결하게 하기 위해 예제에서는 `php-app2` 속성만 자세히 표시합니다. 나머지 속성에 포함된 정보도 비슷합니다.
+ `applications` – 배포된 앱의 목록(이 예제에서는 사용되지 않음).
+ `stack` - 스택 이름(이 예제에서는 `MyStack`).
+ `instance` - 이 속성들이 설치되는 인스턴스(이 예제에서는 `php-app1`). 레시피는 이 속성을 사용하여 인스턴스의 퍼블릭 IP 주소 등 레시피가 실행되고 있는 인스턴스에 대한 정보를 얻을 수 있습니다.
+ `activity` – 속성을 생성한 활동(이 예제에서는 Configure 이벤트).
+ `rails_stack` – Rails 앱 서버 계층을 포함하는 스택의 Rails 스택.
+ `deployment` – 이 속성들이 배포에 연결되어 있는지 여부. 이 예제에서는 Configure 이벤트에 연결되므로 `null`로 설정되어 있습니다.
+ `valid_client_activities` – 유효한 클라이언트 활동의 목록.

`opsworks` 속성 뒤에는 다음을 포함한 그 밖의 몇몇 최상위 속성이 옵니다.
+ `opsworks_custom_cookbooks` – 사용자 지정 쿡북이 활성화되었는지 여부. 활성화된 경우, 이 속성에는 사용자 지정 레시피 목록이 포함됩니다.
+ `recipes` – 이 활동에 의해 실행된 레시피.
+ `opsworks_rubygems` – 인스턴스의 RubyGems 버전.
+ `ssh_users` – SSH 사용자 목록(이 예제에는 없음).
+ `opsworks_bundler` – bundler 버전 및 활성화 여부.
+ `deploy` – 배포 활동에 대한 정보(이 예제에는 없음).

## 배포 속성
<a name="workingcookbook-json-deploy"></a>

Deploy 이벤트 또는 [레시피 실행 스택 명령](workingstacks-commands.md)의 속성은 내장 스택 구성 및 배포 속성과 사용자 지정 스택 또는 배포 속성(이 예제에는 없음)으로 구성됩니다. 다음 JSON 객체는 SimplePHP 앱을 스택의 PHP 인스턴스에 배포한 배포 이벤트에 연결된 [**php-app1**]의 속성을 보여 줍니다. 객체 대부분은 앞 섹션에서 설명한 Configure 이벤트의 속성과 비슷한 스택 구성 속성으로 구성되므로 예제에서는 주로 배포에 고유한 속성에 집중합니다. 다양한 속성에 대한 상세한 설명은 [스택 구성 및 배포 속성: Linux](attributes-json-linux.md) 및 [내장 쿡북 속성](attributes-recipes.md)를 참조하세요.

```
{
   ...
  "opsworks": {
    ...
    "activity": "deploy",
    "applications": [
      {
        "slug_name": "simplephp",
        "name": "SimplePHP",
        "application_type": "php"
      }
    ],
    "deployment": "5e6242d7-8111-40ee-bddb-00de064ab18f",
    ...
  },
  ...
{
  "ssh_users": {
  },
  "deploy": {
    "simplephpapp": {
      "application": "simplephpapp",
      "application_type": "php",
      "environment_variables": {
        "USER_ID": "168424",
        "USER_KEY": "somepassword"
      },
      "auto_bundle_on_deploy": true,
      "deploy_to": "/srv/www/simplephpapp",
      "deploying_user": "arn:aws:iam::123456789012:user/guysm",
      "document_root": null,
      "domains": [
        "simplephpapp"
      ],
      "migrate": false,
      "mounted_at": null,
      "rails_env": null,
      "restart_command": "echo 'restarting app'",
      "sleep_before_restart": 0,
      "ssl_support": false,
      "ssl_certificate": null,
      "ssl_certificate_key": null,
      "ssl_certificate_ca": null,
      "scm": {
        "scm_type": "git",
        "repository": "git://github.com/amazonwebservices/opsworks-demo-php-simple-app.git",
        "revision": "version1",
        "ssh_key": null,
        "user": null,
        "password": null
      },
      "symlink_before_migrate": {
        "config/opsworks.php": "opsworks.php"
      },
      "symlinks": {
      },
      "database": {
      },
      "memcached": {
        "host": null,
        "port": 11211
      },
      "stack": {
        "needs_reload": false
      }
    }
  },
}
```

`opsworks` 속성은 앞 섹션의 예제와 대체로 동일합니다. 다음 섹션들은 배포와 가장 관련이 깊습니다.
+ `activity` – 이 속성들과 연결된 이벤트(이 예제에서는 Deploy 이벤트).
+ `applications` – 앱의 이름, 슬러그 이름, 유형을 제공하는 각 앱의 속성 집합을 포함합니다.

  슬러그 이름은 OpsWorks Stacks가 앱 이름에서 생성하는 앱의 짧은 이름입니다. SimplePHP의 슬러그 이름은 simplephp입니다.
+ `deployment` – 배포를 고유하게 식별하는 배포 ID.

`deploy` 속성은 배포 중인 앱에 대한 정보를 포함합니다. 예를 들어 내장 Deploy 레시피는 `deploy` 속성의 데이터를 사용하여 적절한 디렉터리에 파일을 설치하고 데이터베이스 연결 파일을 생성합니다. `deploy` 속성에는 배포된 각 앱마다 앱의 짧은 이름으로 명명된 속성이 하나씩 포함됩니다. 각 앱 속성은 다음 속성을 포함합니다.
+ `environment_variables` – 앱에 대해 정의한 환경 변수를 포함합니다. 자세한 내용은 [환경 변수](workingapps-creating.md#workingapps-creating-environment) 섹션을 참조하세요.
+ `domains` – 기본적으로 도메인은 앱의 짧은 이름입니다(이 예제에서는 simplephpapp). 사용자 지정 도메인을 할당한 경우, 여기에 도메인도 표시됩니다. 자세한 내용은 [사용자 지정 도메인 사용](workingapps-domains.md) 섹션을 참조하세요.
+ `application` – 앱의 짧은 이름.
+ `scm` – 이 요소에는 앱의 리포지토리(이 예제에서는 Git 리포지토리)에서 앱의 파일을 다운로드하는 데 필요한 정보가 포함됩니다.
+ `database` – 데이터베이스 정보(스택에 데이터베이스 계층이 포함된 경우)
+ `document_root` - 문서 루트. 이 예제에서는 `null`로 설정되어 루트가 공개되어 있음을 나타냅니다.
+ `ssl_certificate_ca`, `ssl_support`, `ssl_certificate_key` – 앱에 SSL 지원이 있는지 여부를 나타냅니다. SSL 지원이 있는 경우, `ssl_certificate_key` 및 `ssl_certificate_ca` 속성은 해당 인증서로 설정됩니다.
+ `deploy_to` – 앱의 루트 디렉터리.

# 쿡북 101
<a name="cookbooks-101"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 서비스 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

프로덕션 수준 OpsWorks Stacks 스택에는 일반적으로 일부 [사용자 지정](customizing.md)이 필요합니다. 즉, 하나 이상의 레시피, 속성 파일 또는 템플릿 파일을 사용하여 사용자 지정 Chef 쿡북을 구현하는 경우가 많습니다. 이 주제는 Stacks용 쿡북 구현에 대한 OpsWorks 자습서 소개입니다.

Stacks가 OpsWorks 쿡북을 사용하는 방법에 대한 자세한 내용은 단원을 참조하십시오[쿡북과 레시피](workingcookbook.md). Chef 레시피를 구현하고 테스트하는 방법에 대한 자세한 정보는 [Chef를 사용한 인프라 테스트 드라이브, 2판](https://www.amazon.com/Test-Driven-Infrastructure-Chef-Behavior-Driven-Development/dp/1449372201/ref=sr_1_fkmr0_1?ie=UTF8&qid=1405556803&sr=8-1-fkmr0&keywords=Test-Driven+Infrastructure+with+Chef%2C+2nd+Edition) 단원을 참조하세요.

이 자습서의 예제는 다음 두 부분으로 나뉩니다.
+  [쿡북 기본 사항](cookbooks-101-basics.md)는 Chef에 익숙하지 않은 사용자를 위한 예제 안내서입니다. 경험이 많은 Chef 사용자는 이 섹션을 건너뛰어도 됩니다.

  이 예제는 패키지 설치 또는 디렉터리 생성 등 일반적인 작업을 수행하기 위해 쿡북을 구현하는 방법의 기초를 안내합니다. 프로세스를 간단히 하기 위해 [Vagrant](http://docs.vagrantup.com/v2/)와 [Test Kitchen](http://kitchen.ci/)이라는 유용한 도구 2개를 사용하여 예제 대부분을 가상 머신에서 로컬로 실행하게 됩니다. [쿡북 기본 사항](cookbooks-101-basics.md)를 시작하기에 앞서 이들 도구의 설치 및 사용 방법을 배우기 위해 먼저 [Vagrant와 Test Kitchen](#cookbooks-101-tools)를 읽어야 합니다. Test Kitchen은 아직 Windows를 지원하지 않기 때문에 예제는 모두 Linux용이며 Windows에 맞게 조정하는 방법을 알려주는 참고가 포함되어 있습니다.
+ [OpsWorks 스택용 쿡북 구현](cookbooks-101-opsworks.md) 에서는 Windows 스택용 OpsWorks 를 포함하여 Stacks용 레시피를 구현하는 방법을 설명합니다.

  Berkshelf를 사용하여 외부 쿡북을 관리하는 방법 등 몇 가지 고급 s도 포함되어 있습니다. 예제는 [쿡북 기본 사항](cookbooks-101-basics.md)의 예제처럼 Chef가 처음인 사용자들을 위해 작성되었습니다. 그러나 OpsWorks Stacks는 Chef 서버와 약간 다르게 작동하므로 숙련된 Chef 사용자는 최소한이 섹션을 읽어보는 것이 좋습니다.



## Vagrant와 Test Kitchen
<a name="cookbooks-101-tools"></a>

Linux 인스턴스용 레시피 작업을 하는 경우, Vagrant와 Test Kitchen은 학습과 초기 개발 및 테스트에 매우 유용한 도구입니다. 이것은 Vagrant와 Test Kitchen을 간략히 설명하고 기본적인 도구 사용 방법을 시작하고 익힐 수 있는 설치 지침과 안내서를 제공합니다. Vagrant는 Windows를 지원하지만 Test Kitchen은 지원하지 않으므로 이 도구들의 경우, Linux 예제만 나와 있습니다.



### Vagrant
<a name="cookbooks-101-tools-vagrant"></a>

[Vagrant](http://docs.vagrantup.com/v2/)는 가상 머신에서 코드를 실행하고 테스트할 수 있는 일관된 환경을 제공합니다. Vagrant 박스라고 하는 다양한 환경을 지원하며, 각 환경은 구성된 운영 체제를 나타냅니다. OpsWorks Stacks의 경우 관심 환경은 Ubuntu, Amazon 또는 Red Hat Enterprise Linux(RHEL) 배포를 기반으로 하므로 예제에서는 주로 라는 Vagrant 상자를 사용합니다`opscode-ubuntu-12.04`.

Vagrant는 Linux, Windows, Macintosh 시스템에서 사용 가능하므로 원하는 워크스테이션을 사용하여 지원되는 어떤 운영 체제에서도 레시피를 구현하고 테스트할 수 있습니다. 이 장의 예제는 Ubuntu Linux 시스템에서 작성되었지만 Windows 또는 Macintosh 시스템에도 간단히 적용할 수 있습니다.

Vagrant는 기본적으로 가상화 공급자용 래퍼입니다. 대부분의 예제는 [VirtualBox](https://www.virtualbox.org/) 공급자를 사용합니다. VirtualBox는 무료이며 Linux, Windows, Macintosh 시스템에서 사용할 수 있습니다. 아직 시스템에 VirtualBox이 설치되어 있지 않은 경우, Vagrant 안내서에 설치 지침이 나와 있습니다. VirtualBox에서 Ubuntu 기반 환경을 실행할 수 있지만 Amazon Linux는 Amazon EC2 인스턴스에만 사용할 수 있습니다. 다만 CentOS와 같은 유사한 운영 체제는 VirtualBox에서 실행할 수 있어 초기 개발과 테스트에 유용합니다.

다른 공급자에 대해서는 [Vagrant](http://docs.vagrantup.com/v2/) 설명서를 참조하세요. 특히 `vagrant-aws` 플러그인 공급자를 사용하면 Amazon EC2 인스턴스에 Vagrant를 사용할 수 있습니다. 이 공급자는 Amazon EC2 인스턴스에서만 사용할 수 있는 Amazon Linux에서 레시피를 테스트하는 데 특히 유용합니다. `vagrant-aws` 공급자는 무료이지만 AWS 계정이 있어야 하며, 사용하는 AWS 리소스에 대한 요금을 지불해야 합니다.

이 시점에서 워크스테이션에 Vagrant를 설치하는 방법을 설명하고 Vagrant의 기본적 사용 방법을 알려 주는 Vagrant [시작하기 안내서](http://docs.vagrantup.com/v2/getting-started/index.html)를 읽어야 합니다. 이 장의 예제는 Git 리포지토리를 사용하지 않기 때문에 원한다면 안내서에서 해당 부분은 생략해도 됩니다.

### Test Kitchen
<a name="cookbooks-101-tools-test-kitchen"></a>

[Test Kitchen](http://kitchen.ci/)은 Vagrant에서 쿡북을 실행하고 테스트하는 프로세스를 간소화합니다. 실제로는 직접 Vagrant를 사용할 일은 거의 없습니다. 다음을 비롯한 대부분의 일반적 작업은 Test Kitchen이 수행합니다.
+ Vagrant에서 인스턴스 시작.
+ 쿡북을 인스턴스로 이전.
+ 인스턴스에서 쿡북의 레시피 실행.
+ 인스턴스에서 쿡북의 레시피 테스트.
+ SSH를 사용하여 인스턴스에 로그인.

Test Kitchen gem을 직접 설치하는 대신 [Chef DK](https://www.chef.io/downloads)를 설치하는 것이 좋습니다. 이 패키지에는 Chef 외에도 Test Kitchen, [Berkshelf](http://berkshelf.com/), [ChefSpec](https://docs.chef.io/chefspec.html) 및 유용한 그 밖의 몇 가지 도구가 포함되어 있습니다.

이 시점에서 Test Kitchen을 사용하여 레시피를 실행하고 테스트하는 방법을 알려 주는 Test Kitchen [시작하기 안내서](http://kitchen.ci/)를 읽어야 합니다.

**참고**  
이 장의 예제에서는 레시피를 실행하는 편리한 방법으로 Test Kitchen을 사용합니다. 원한다면 예제에 대해 알아야 할 모든 내용을 다루고 있는 수동으로 확인(Manually Verifying) 섹션을 마친 다음 시작하기 안내서를 중단해도 됩니다. 하지만 Test Kitchen은 일차적으로 [bash automated test system(BATS)](https://github.com/sstephenson/bats) 같은 테스트 프레임워크를 지원하는 테스트 플랫폼입니다. 일정 시점이 되면 안내서의 나머지 부분을 끝마쳐 Test Kitchen을 사용해 레시피를 테스트하는 방법을 배워야 합니다.

# 쿡북 기본 사항
<a name="cookbooks-101-basics"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 서비스 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

쿡북을 사용하여 다양한 작업을 수행할 수 있습니다. 다음 주제에서는 사용자가 Chef를 처음 사용하는 것으로 가정하며, 일부 공통 작업 수행에 쿡북을 사용하는 방법을 설명합니다. Test Kitchen은 아직 Windows를 지원하지 않기 때문에 예제는 모두 Linux용이며 Windows에 맞게 조정하는 방법을 알려주는 참고가 포함되어 있습니다. Chef가 처음인 경우, Windows 작업을 하게 되더라도 이 예제를 끝까지 살펴보는 것이 좋습니다. 이 주제의 예제 대부분은 예제에서 언급하는 몇 가지 적당한 변경을 거치면 Windows 인스턴스에서도 사용할 수 있습니다. 모든 예제는 가상 머신에서 실행되므로 Linux 컴퓨터가 없어도 됩니다. 평소 사용하는 워크스테이션에 Vagrant와 Test Kitchen을 설치하세요.

**참고**  
이러한 레시피를 Windows 인스턴스에서 실행하는 가장 간단한 방법은 Windows 스택을 생성하고 스택의 인스턴스 중 하나에서 레시피를 실행하는 것입니다. OpsWorks Stacks Windows 인스턴스에서 레시피를 실행하는 방법에 대한 자세한 내용은 섹션을 참조하세요[Windows 인스턴스에서 레시피 실행](cookbooks-101-opsworks-opsworks-windows.md).

계속하기 전에 Vagrant와 Test Kitchen을 설치하고 시작하기 안내서를 마치십시오. 자세한 내용은 [Vagrant와 Test Kitchen](cookbooks-101.md#cookbooks-101-tools) 섹션을 참조하세요.

**Topics**
+ [레시피 구조](cookbooks-101-basics-structure.md)
+ [예제 1: 패키지 설치](cookbooks-101-basics-packages.md)
+ [예제 2: 사용자 관리](cookbooks-101-basics-users.md)
+ [예제 3: 디렉터리 생성](cookbooks-101-basics-directories.md)
+ [예제 4: 레시피에 흐름 제어 추가](cookbooks-101-basics-ruby.md)
+ [예제 5: 속성 사용](cookbooks-101-basics-attributes.md)
+ [예제 6: 파일 생성](cookbooks-101-basics-files.md)
+ [예제 7: 명령 및 스크립트 실행](cookbooks-101-basics-commands.md)
+ [예제 8: 서비스 관리](cookbooks-101-basics-services.md)
+ [예제 9: Amazon EC2 인스턴스 사용](cookbooks-101-basics-ec2.md)
+ [다음 단계](cookbooks-101-basics-next.md)

# 레시피 구조
<a name="cookbooks-101-basics-structure"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 서비스 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

쿡북은 기본적으로 인스턴스에서 다양한 작업을 수행할 수 있는 *레시피*의 집합입니다. 레시피를 구현하는 방법을 명확히 알려면 간단한 예를 살펴보는 것이 도움이 됩니다. 다음은 내장 [HAProxy 계층](layers-haproxy.md)의 설정 레시피입니다. 지금은 전체적인 구조에 집중하고 세부적인 사항에 너무 신경 쓰지 마십시오. 세부적인 내용은 이후 예제에서 다룹니다.

```
package 'haproxy' do
  action :install
end

if platform?('debian','ubuntu')
  template '/etc/default/haproxy' do
    source 'haproxy-default.erb'
    owner 'root'
    group 'root'
    mode 0644
  end
end

include_recipe 'haproxy::service'

service 'haproxy' do
  action [:enable, :start]
end

template '/etc/haproxy/haproxy.cfg' do
  source 'haproxy.cfg.erb'
  owner 'root'
  group 'root'
  mode 0644
  notifies :restart, "service[haproxy]"
end
```

**참고**  
이 예제 및 다른 작업 레시피와 관련 파일의 예제는 [OpsWorks Stacks 내장 레시피](https://github.com/aws/opsworks-cookbooks)를 참조하세요.

이 예제는 다음 섹션에서 설명하는 주요 레시피 요소를 집중적으로 다룹니다.

**Topics**
+ [리소스](#cookbooks-101-basics-structure-resources)
+ [흐름 제어](#cookbooks-101-basics-structure-ruby)
+ [포함된 레시피](#cookbooks-101-basics-structure-include)

## 리소스
<a name="cookbooks-101-basics-structure-resources"></a>

레시피는 주로 Chef *리소스* 집합으로 구성됩니다. 각각의 리소스는 설치할 패키지나 시작할 서비스 같은 인스턴스 최종 상태의 특정 측면을 지정합니다. 예제에는 다음 4개의 리소스가 있습니다.
+ 설치된 패키지를 나타내는 `package` 리소스입니다. 이 예시에서는 [HAProxy 서버](http://haproxy.1wt.eu/)입니다.
+ 이 예제에서 HAProxy 서비스에 해당하는 서비스를 나타내는 `service` 리소스.
+ 이 예제에서 2개의 HAProxy 구성 파일에 해당하는, 지정된 템플릿에서 생성할 파일을 나타내는 2개의 `template` 리소스.

리소스는 인스턴스 상태를 지정하는 선언적 방법을 제공합니다. 백그라운드에서는 각각의 리소스에 패키지 설치, 디렉터리 생성 및 구성, 서비스 시작 등등의 필요한 작업을 수행하는 연결된 *공급자*가 있습니다. 작업의 세부 사항이 특정 운영 체제에 따라 다른 경우, 리소스는 여러 개의 공급자를 가지며 시스템에 적합한 공급자를 사용합니다. 예를 들어 Red Hat Linux 시스템에서 `package` 공급자는 `yum`을 사용하여 패키지를 설치합니다. Ubuntu Linux 시스템에서 `package` 공급자는 `apt-get`을 사용합니다.

다음과 같은 일반적 형식을 사용하여 Ruby 코드 블록으로 리소스를 구현합니다.

```
resource_type "resource_name" do
  attribute1 'value1'
  attribute2 'value2'
  ...
  action :action_name
  notifies : action 'resource'
end
```

요소는 다음과 같습니다.

**리소스 유형**  
(필수) 예제에는 세 가지 리소스 형식(`package`, `service`, `template`)이 포함됩니다.

**리소스 이름**  
(필수) 이름은 특정 리소스를 식별하며, 경우에 따라 속성 중 하나의 기본값으로 사용됩니다. 예제에서 `package`는 `haproxy`라는 이름의 패키지 리소스를 나타내며, 첫 번째 `template` 리소스는 `/etc/default/haproxy`라는 이름의 구성 파일을 나타냅니다.

**속성**  
(선택 사항) 속성은 리소스 구성을 지정하며, 리소스 유형 및 리소스 구성 방법에 따라 달라집니다.  
+ 예제의 `template` 리소스는 생성된 파일의 원본, 소유자, 그룹, 모드를 지정하는 속성 세트를 명시적으로 정의합니다.
+ 예제의 `package` 및 `service` 리소스는 어떤 속성도 명시적으로 정의하지 않습니다.

  리소스 이름은 일반적으로 필수 속성의 기본값이며, 필요한 전부인 경우도 있습니다. 예를 들어 리소스 이름은 `package` 리소스의 `package_name` 속성에 대한 기본값이며, 이것이 유일한 필수 속성입니다.
가드 속성이라고 하는 몇 가지 특화된 속성도 있는데, 리소스 공급자가 언제 작업을 수행할지 지정합니다. 예를 들어 `only_if` 속성은 지정된 조건이 충족되는 경우에만 작업을 수행하라고 리소스 공급자에게 명령합니다. HAProxy 레시피는 가드 속성을 사용하지 않지만 다음 몇 가지 예제에서는 가드 속성을 사용합니다.

**작업 및 알림**  
(선택 사항) 작업 및 알림은 공급자가 수행할 작업을 지정합니다.  
+ `action`은 설치 또는 생성 등 지정된 작업을 하도록 공급자에게 명령합니다.

  각 리소스에는 특정 리소스에 따라 달라지는 작업 세트가 있으며, 이 중 하나는 기본 작업입니다. 예제에서 `package` 리소스의 작업은 `install`인데, 공급자에게 패키지를 설치하라고 명령합니다. 첫 번째 `template` 리소스에는 `action` 요소가 없기 때문에 공급자는 기본 `create` 작업을 수행합니다.
+ `notifies`는 다른 리소스의 공급자에게 작업을 수행할 것을 명령하지만 리소스의 상태가 변경된 경우에 한합니다.

  `notifies`는 일반적으로 `template` 및 `file` 같은 리소스와 함께 사용되어 구성 파일 수정 후 서비스 재시작 같은 작업을 수행합니다. 리소스에는 기본 알림이 없습니다. 알림을 원하는 경우, 리소스에 명시적인 `notifies` 요소가 있어야 합니다. HAProxy 레시피에서 두 번째 `template` 리소스는 연결된 구성 파일이 변경된 경우, haproxy `service` 리소스에 HAProxy 서비스를 다시 시작하라고 알립니다.

리소스가 운영 체제에 따라 달라지는 경우가 있습니다.
+ 일부 리소스는 Linux 또는 Windows 시스템에서만 사용할 수 있습니다.

  예를 들어 [패키지](https://docs.chef.io/chef/resources.html#package)는 Linux 시스템에 패키지를 설치하고, [windows\$1package](https://docs.chef.io/chef/resources.html#windows-package)는 Windows 시스템에 패키지를 설치합니다.
+ 일부 리소스는 어떤 운영 체제에도 사용할 수 있지만 특정 시스템에 고유한 속성을 가지고 있습니다.

  예를 들어 [파일](https://docs.chef.io/chef/resources.html#file) 리소스는 Linux 시스템이나 Windows 시스템에서 사용할 수 있지만 구성 권한에 대한 속성을 별도로 가지고 있습니다.

각 리소스의 사용 가능한 속성, 작업, 알림을 포함한 표준 리소스에 대한 설명은 [리소스 및 공급자에 대하여](https://docs.chef.io/resource.html)를 참조하세요.

## 흐름 제어
<a name="cookbooks-101-basics-structure-ruby"></a>

레시피는 Ruby 애플리케이션이므로 Ruby 제어 구조를 사용하여 흐름 제어를 레시피에 통합할 수 있습니다. 예를 들어 Ruby 조건부 논리를 사용하여 레시피가 시스템에 따라 다르게 동작하도록 할 수 있습니다. HAProxy 레시피에 포함된 `if` 블록은 레시피가 Debian 또는 Ubuntu 시스템에서 실행되는 경우에만 `template` 리소스를 사용하여 구성 파일을 생성합니다.

다른 일반적 시나리오는 루프를 사용하여 하나의 리소스를 상이한 속성 설정으로 여러 번 실행하는 것입니다. 예를 들어 루프를 사용해 `directory` 리소스를 서로 다른 디렉터리 이름으로 여러 번 실행하여 디렉터리 집합을 생성할 수 있습니다.

**참고**  
Ruby에 익숙하지 않다면 대부분의 레시피에 대해 알아야 할 내용을 다루고 있는 [Just Enough Ruby for Chef](https://docs.chef.io/just_enough_ruby_for_chef.html)를 참조하세요.

## 포함된 레시피
<a name="cookbooks-101-basics-structure-include"></a>

`include_recipe`는 코드의 다른 레시피를 포함하며, 레시피를 모듈화하여 여러 레시피에서 같은 코드를 다시 사용할 수 있도록 해 줍니다. 호스트 레시피 실행 시 Chef는 호스트 레시피를 실행하기 전에 각각의 `include_recipe` 요소를 지정된 레시피의 코드로 대체합니다. 표준 Chef `cookbook_name::recipe_name` 구문을 사용하여 포함된 레시피를 식별합니다. 여기서 `recipe_name`에는 `.rb` 확장명이 생략되어 있습니다. 예제에는 HAProxy 서비스를 나타내는 하나의 레시피인 `haproxy::service`가 포함됩니다.

**참고**  
Chef 11.10 이후 버전에서 실행되는 레시피에서 `include_recipe`를 사용하여 다른 쿡북의 레시피를 포함시키려면 `depends` 문을 사용하여 쿡북의 `metadata.rb` 파일에서 종속성을 선언해야 합니다. 자세한 내용은 [레시피 구현: Chef 11.10](workingcookbook-chef11-10.md) 섹션을 참조하세요.

# 예제 1: 패키지 설치
<a name="cookbooks-101-basics-packages"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 서비스 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

패키지 설치는 가장 일반적인 레시피 용도 중 하나이며, 패키지에 따라서는 아주 간단할 수 있습니다. 예를 들어 다음 레시피는 Linux 시스템에 Git를 설치합니다.

```
package 'git' do
  action :install
end
```

[`package`리소스](https://docs.chef.io/chef/resources.html#package)는 패키지 설치를 처리합니다. 이 예제에서는 아무 속성도 지정할 필요가 없습니다. 리소스 이름은 패키지를 식별하는 `package_name` 속성의 기본값입니다. `install` 작업은 공급자에게 패키지를 설치하라고 명령합니다. `install` 리소스의 기본 작업인 `package`을 건너뛰면 코드를 더욱 간단하게 만들 수 있습니다. 레시피를 실행할 때 Chef는 적절한 공급자를 사용하여 패키지를 설치합니다. 예제에 사용할 Ubuntu 시스템에서는 공급자가 `apt-get`을 호출하여 Git를 설치합니다.

**참고**  
Windows 시스템에 소프트웨어를 설치하려면 약간 다른 절차가 필요합니다. 자세한 내용은 [Windows 소프트웨어 설치](cookbooks-101-opsworks-install-software.md) 섹션을 참조하세요.

Test Kitchen을 사용하여 Vagrant에서 이 레시피를 실행하려면 먼저 쿡북을 설정한 다음 Test Kitchen을 초기화하고 구성해야 합니다. 다음은 Linux 시스템용이지만 Windows 및 Macintosh 시스템과 절차는 기본적으로 비슷합니다. 먼저 Terminal 창을 엽니다. 이 장의 모든 예제는 명령줄 도구를 사용합니다.

**쿡북을 준비하려면**

1. 홈 디렉터리에서 `opsworks_cookbooks`라는 하위 디렉터리를 만듭니다. 이 디렉터리에는 이 장의 모든 쿡북이 저장됩니다. 그런 다음 이 쿡북의 하위 디렉터리로 `installpkg`를 만들고 이 디렉터리로 이동합니다.

1. `installpkg`에서 다음 코드가 포함된 `metadata.rb`라는 파일을 만듭니다.

   ```
   name "installpkg"
   version "0.1.0"
   ```

   간단한 설명을 위해 이 장의 예제에서는 쿡북 이름 및 버전만 지정하지만, `metadata.rb`에 다양한 쿡북 메타데이터를 넣을 수 있습니다. 자세한 정보는 [About Cookbook Metadata](http://docs.chef.io/cookbook_repo.html#about-cookbook-metadata)를 참조하세요.
**참고**  
Test Kitchen에서는 `metadata.rb` 파일의 데이터를 사용하여 기본 구성 파일을 만듭니다. 그러므로 Test Kitchen을 초기화하기 전에 이 파일을 만드십시오.

1. `installpkg`에서 `kitchen init`를 실행합니다. 이 코드는 Test Kitchen을 초기화하고 기본 Vagrant 드라이버를 설치합니다.

1. `kitchen init` 명령은 `installpkg`에 YAML 구성 파일 `.kitchen.yml`을 만듭니다. 즐겨찾는 텍스트 편집기에서 파일을 엽니다. `.kitchen.yml` 파일에는 레시피를 실행할 시스템을 지정하는 `platforms` 섹션이 포함되어 있습니다. Test Kitchen은 인스턴스를 생성하고 지정된 레시피를 각 플랫폼에서 실행합니다.
**참고**  
기본적으로 Test Kitchen은 한 번에 한 플랫폼에서 레시피를 실행합니다. 인스턴스를 생성하는 명령에 `-p` 인수를 추가하면 Test Kitchen은 모든 플랫폼에서 동시에 레시피를 실행합니다.

   이 예제에서는 플랫폼 하나로 충분하므로 `.kitchen.yml` 플랫폼을 빼고 `centos-6.4`을 편집합니다. `.kitchen.yml` 파일은 이제 다음과 같아야 합니다.

   ```
   ---
   driver:
     name: vagrant
   
   provisioner:
     name: chef_solo
   
   platforms:
     - name: ubuntu-12.04
   
   suites:
     - name: default
       run_list:
         - recipe[installpkg::default]
       attributes:
   ```

   Test Kitchen은 `.kitchen.yml` 실행 목록에 있는 레시피만 실행합니다. `[cookbook_name::recipe_name]` 형식을 사용하여 레시피를 식별합니다. 여기서 *recipe\$1name*은 `.rb` 확장명을 제외한 이름입니다. 처음에 `.kitchen.yml` 실행 목록에는 쿡북의 기본 레시피 `installpkg::default`가 포함되어 있습니다. 이 레시피가 구현하려는 레시피이므로 실행 목록을 수정할 필요가 없습니다.

1. `installpkg`의 하위 디렉터리로 `recipes`를 만듭니다.

   쿡북에 레시피가 포함되어 있는 경우 (대부분 그렇죠) 해당 레시피는 `recipes` 하위 디렉터리에 있어야 합니다. 

이제 레시피를 쿡북에 추가하고 Test Kitchen을 사용하여 인스턴스에서 레시피를 실행할 수 있습니다.

**레시피를 실행하려면**

1. 이 단원의 시작 부분에 나온 Git 설치 예제 코드가 포함된 `default.rb` 파일을 만들어 `recipes` 하위 디렉터리에 저장합니다.

1. `installpkg` 디렉터리에서 `kitchen converge`를 실행합니다. 이 명령은 Vagrant에서 새 Ubuntu 인스턴스를 시작하고 인스턴스에 쿡북을 복사하고, Chef 실행을 시작하여 `.kitchen.yml` 실행 목록에서 레시피를 실행합니다.

1. 레시피가 성공적으로 실행되었는지 확인하려면 인스턴스에 대한 SSH 연결을 여는 `kitchen login`을 실행합니다. 그런 다음 `git --version`을 실행하여 Git가 성공적으로 설치되었는지 확인합니다. 워크스테이션으로 돌아가려면 `exit`를 실행합니다.

1. 다 마치면 `kitchen destroy`를 실행해 인스턴스를 종료하세요. 다음 예제에서는 다른 쿡북을 사용합니다.

이 예제는 시작하기에는 좋은 방법이었지만 유독 단순합니다. 다른 패키지는 설치하기가 더 복잡할 수 있습니다. 이 경우, 다음 방법 일부 또는 전부를 수행해야 할 수 있습니다.
+ 사용자를 생성하고 구성합니다.
+ 데이터, 로그 등을 위한 하나 이상의 디렉터리를 생성합니다.
+ 하나 이상의 구성 파일을 설치합니다.
+ 운영 체제에 따라 서로 다른 패키지 이름이나 속성 값을 지정합니다.
+ 서비스를 시작한 다음 필요하다면 다시 시작합니다.

다음 예제에서는 이러한 문제를 해결하는 방법과 그 밖의 몇 가지 유용한 작업을 설명합니다.

# 예제 2: 사용자 관리
<a name="cookbooks-101-basics-users"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 서비스 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

또 다른 간단한 작업은 인스턴스에서의 사용자 관리입니다. 다음 레시피는 Linux 인스턴스에 새 사용자를 추가합니다.

```
user "myuser" do
  home "/home/newuser"
  shell "/bin/bash"
end
```

[user](https://docs.chef.io/chef/resources.html#user) 리소스를 사용하여 Linux 시스템과 Windows 시스템에서 사용자를 관리할 수 있습니다(단, 일부 속성은 하나의 시스템에만 적용됩니다). 이 예제는 `myuser`라는 이름의 사용자를 생성하고 홈 디렉터리 및 셸을 지정합니다. 지정된 작업이 없기 때문에 리소스는 기본 `create` 작업을 사용합니다. `user`에 속성을 추가하여 암호나 그룹 ID 같은 다양한 다른 설정을 지정할 수 있습니다. 사용자 설정 수정이나 사용자 삭제 같은 관련된 사용자 관리 작업에 `user`를 사용할 수도 있습니다. 자세한 정보는 [user](https://docs.chef.io/chef/resources.html#user)를 참조하세요.

**레시피를 실행하려면**

1. `opsworks_cookbooks` 안에 `newuser` 하위 디렉터리를 만들고 그 디렉터리로 이동합니다.

1. 다음 코드가 포함된 `metadata.rb` 파일을 만든 다음 이 파일을 `newuser`에 저장합니다.

   ```
   name "newuser"
   version "0.1.0"
   ```

1. [예제 1: 패키지 설치](cookbooks-101-basics-packages.md) 단원에서 설명하는 대로 Test Kitchen을 초기화 및 구성하고 `recipes` 디렉터리 내에서 `newuser` 디렉터리를 추가합니다.

1.  예제 레시피가 포함된 `default.rb` 파일을 쿡북의 `recipes` 디렉터리에 추가합니다.

1. `kitchen converge`를 실행하여 레시피를 실행합니다.

1. `kitchen login`을 사용하여 인스턴스에 로그인하고 `cat /etc/passwd`를 실행하여 새 사용자가 존재하는지 확인합니다. `myuser` 사용자는 파일의 맨 아래에 있어야 합니다.

# 예제 3: 디렉터리 생성
<a name="cookbooks-101-basics-directories"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 서비스 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

인스턴스에 패키지를 생성할 때 일부 구성 파일을 생성해 적절한 디렉터리에 넣어야 하는 경우가 많습니다. 하지만 이런 디렉터리가 아직 없을 수 있습니다. 데이터, 로그 파일 등을 위한 디렉터리를 생성해야 할 수도 있습니다. 예를 들어 대부분의 예제에 사용하는 Ubuntu 시스템을 처음 부팅하면 `/srv` 디렉터리에 하위 디렉터리가 없습니다. 애플리케이션 서버를 설치하는 경우, `/srv/www/` 디렉터리 이외에 데이터 파일, 로그 등을 저장하기 위한 몇몇 하위 디렉터리가 필요할 것입니다. 다음 레시피는 인스턴스에 `/srv/www/`를 생성합니다.

```
directory "/srv/www/" do
  mode 0755
  owner 'root'
  group 'root'
  action :create
end
```

[`directory` 리소스](https://docs.chef.io/chef/resources.html#directory)를 사용하여 Linux 시스템과 Windows 시스템에서 디렉터리를 생성하고 구성할 수 있습니다. 단, 일부 속성은 서로 다르게 사용됩니다. 리소스 이름은 리소스의 `path` 속성에 대한 기본값이므로 이 예제에서는 `/srv/www/`를 생성하고 이 디렉터리의 `mode`, `owner` 및 `group` 속성을 지정합니다.

**레시피를 실행하려면**

1. `opsworks_cookbooks` 안에 `createdir` 하위 디렉터리를 만들고 그 디렉터리로 이동합니다.

1. [예제 1: 패키지 설치](cookbooks-101-basics-packages.md) 단원에서 설명하는 대로 Test Kitchen을 초기화 및 구성하고 `recipes` 디렉터리 내에서 `createdir` 디렉터리를 추가합니다.

1.  레시피 코드가 포함된 `default.rb` 파일을 쿡북의 `recipes` 디렉터리에 추가합니다.

1. `kitchen converge`를 실행하여 레시피를 실행합니다.

1. `kitchen login`을 실행하고, `/srv`로 이동하여 여기에 `www` 하위 디렉터리가 있는지 확인합니다.

1. `exit`를 실행하여 워크스테이션으로 돌아가되 인스턴스를 실행 중인 상태로 둡니다.

**참고**  
인스턴스에서 홈 디렉터리에 관련된 디렉터리를 생성하려면 `#{ENV['HOME']}`을 사용하여 홈 디렉터리를 나타냅니다. 예를 들어 다음은 `~/shared` 디렉터리를 생성합니다.  

```
directory "#{ENV['HOME']}/shared" do
  ...
end
```

`/srv/www/shared`와 같이 더 깊이 중첩된 디렉터리를 만들려 한다고 가정해 봅시다. 앞의 레시피를 다음과 같이 수정할 수 있습니다.

```
directory "/srv/www/shared" do
  mode 0755
  owner 'root'
  group 'root'
  action :create
end
```

**레시피를 실행하려면**

1.  `default.rb`의 코드를 이전 레시피로 바꿉니다.

1. `kitchen converge` 디렉터리에서 `createdir`를 실행합니다.

1. 해당 디렉터리가 생성되었는지 확인하려면 `kitchen login`을 실행하고 `/srv/www`로 이동하여 여기에 `shared` 하위 디렉터리가 있는지 확인합니다.

1. `kitchen destroy`를 실행하여 인스턴스를 종료합니다.

`kitchen converge` 명령이 훨씬 빠르게 실행되는 것을 알 수 있습니다. 그 이유는 인스턴스가 이미 실행되고 있어서 인스턴스를 부팅하고 Chef를 설치하는 등의 작업이 필요 없기 때문입니다. Test Kitchen은 업데이트된 쿡북을 인스턴스에 복사하고 Chef 실행을 시작하면 됩니다.

이제 `kitchen converge`를 다시 실행하면 새로운 인스턴스에서 레시피가 실행됩니다. 이제 다음과 같은 결과를 보게 됩니다.

```
Chef Client failed. 0 resources updated in 1.908125788 seconds       
[2014-06-20T20:54:26+00:00] ERROR: directory[/srv/www/shared] (createdir::default line 1) had an error: Chef::Exceptions::EnclosingDirectoryDoesNotExist: Parent directory /srv/www does not exist, cannot create /srv/www/shared       
[2014-06-20T20:54:26+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)       
>>>>>> Converge failed on instance <default-ubuntu-1204>.
>>>>>> Please see .kitchen/logs/default-ubuntu-1204.log for more details
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: SSH exited (1) for command: [sudo -E chef-solo --config /tmp/kitchen/solo.rb --json-attributes /tmp/kitchen/dna.json  --log_level info]
>>>>>> ----------------------
```

어떻게 된 걸까요? 문제는 기본적으로 `directory` 리소스가 한 번에 한 디렉터리만 생성할 수 있고 디렉터리의 체인은 생성할 수 없다는 것입니다. 앞에서 레시피가 작동했던 이유는 인스턴스에서 제일 먼저 실행한 레시피가 이미 `/srv/www`를 생성했기 때문에 `/srv/www/shared` 생성으로 하나의 하위 디렉터리만 생성됐기 때문입니다.

**참고**  
`kitchen converge`를 실행할 때는 레시피를 새 인스턴스에서 실행하는지 기존 인스턴스에서 실행하는지 알아야 합니다. 결과가 상이할 수 있습니다.

하위 디렉터리 체인을 생성하려면 `recursive` 속성을 `directory`에 추가하고 `true`로 설정합니다. 다음 레시피는 깨끗한 인스턴스에 `/srv/www/shared` 디렉터리를 생성합니다.

```
directory "/srv/www/shared" do
  mode 0755
  owner 'root'
  group 'root'
  recursive true
  action :create
end
```

# 예제 4: 레시피에 흐름 제어 추가
<a name="cookbooks-101-basics-ruby"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 서비스 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

일부 레시피는 일련의 Chef 리소스에 불과합니다. 이 경우, 레시피를 실행하면 레시피는 단순히 각각의 리소스 공급자를 순차적으로 실행합니다. 하지만 보다 복잡한 실행 경로가 있으면 유용한 경우가 많습니다. 다음은 두 가지 일반적인 시나리오입니다.
+ 레시피가 같은 리소스를 서로 다른 속성 설정으로 여러 번 실행하도록 하려는 경우.
+ 운영 체제에 따라 서로 다른 속성 설정을 사용하려는 경우.

이러한 시나리오는 Ruby 제어 구조를 레시피에 통합하여 해결할 수 있습니다. 이 섹션에서는 [예제 3: 디렉터리 생성](cookbooks-101-basics-directories.md)의 레시피를 수정하여 두 가지 시나리오를 모두 해결하는 방법을 살펴봅니다.

**Topics**
+ [반복](#cookbooks-101-basics-ruby-iteration)
+ [조건부 논리](#cookbooks-101-basics-ruby-conditional)

## 반복
<a name="cookbooks-101-basics-ruby-iteration"></a>

[예제 3: 디렉터리 생성](cookbooks-101-basics-directories.md)에서는 `directory` 리소스를 사용하여 디렉터리 또는 디렉터리 체인을 생성하는 방법을 살펴봤습니다. 하지만 `/srv/www/config`와 `/srv/www/shared`라는 2개의 별도의 디렉터리를 생성하려 한다고 가정해 봅시다. 각 디렉터리마다 별도의 디렉터리 리소스를 구성할 수도 있지만 아주 많은 디렉터리를 생성하려는 경우, 이 방법은 번거로울 수 있습니다. 다음 레시피는 이 작업을 처리하는 보다 간단한 방법을 보여 줍니다.

```
[ "/srv/www/config", "/srv/www/shared" ].each do |path|
  directory path do
    mode 0755
    owner 'root'
    group 'root'
    recursive true
    action :create
  end
end
```

이 레시피는 각 하위 디렉터리에 별도의 디렉터리 리소스를 사용하는 대신 하위 디렉터리 경로가 포함된 문자열 모음을 사용합니다. Ruby `each` 메서드는 첫 번째 모음 요소부터 시작하여 각 모음 요소에 한 번씩 리소스를 실행합니다. 요소의 값은 리소스에서 `path` 변수에 의해 표시되며, 이 경우에는 디렉터리 경로를 나타냅니다. 이 예제를 쉽게 조정하여 얼마든지 많은 하위 디렉터리를 생성할 수 있습니다.

**레시피를 실행하려면**

1. `createdir` 디렉터리를 그대로 열어 두고, 다음 여러 예제에 이 쿡북을 사용합니다.

1. 아직 실행하지 않은 경우 `kitchen destroy`를 실행합니다. 그러면 깨끗한 인스턴스로 시작할 수 있습니다.

1. `default.rb`의 코드를 이 예제로 바꾸고 `kitchen converge`를 실행합니다.

1. 인스턴스에 로그인합니다. 그러면 `/srv`에 새로 생성된 디렉터리가 있습니다.

해시 테이블을 사용하여 각 반복에 2개의 값을 지정할 수 있습니다. 다음 레시피는 각각 다른 모드로 `/srv/www/config`와 `/srv/www/shared`를 생성합니다.

```
{ "/srv/www/config" => 0644, "/srv/www/shared" => 0755 }.each do |path, mode_value|
  directory path do
    mode mode_value
    owner 'root'
    group 'root'
    recursive true
    action :create
  end
end
```

**레시피를 실행하려면**

1. 아직 실행하지 않은 경우 `kitchen destroy`를 실행합니다. 그러면 깨끗한 인스턴스로 시작할 수 있습니다.

1. `default.rb`의 코드를 이 예제로 바꾸고 `kitchen converge`를 실행합니다.

1. 인스턴스에 로그인합니다. 그러면 `/srv`에 지정된 모드로 새로 생성된 디렉터리가 있습니다.

**참고**  
OpsWorks Stacks 레시피는 일반적으로이 접근 방식을 사용하여 기본적으로 큰 해시 테이블인 [스택 구성 및 배포 JSON](workingcookbook-json.md)에서 값을 추출하고 리소스에 삽입합니다. 예제는 [Deploy 레시피](create-custom-deploy.md) 섹션을 참조하세요.

## 조건부 논리
<a name="cookbooks-101-basics-ruby-conditional"></a>

Ruby 조건부 논리를 사용하여 여러 실행 분기를 생성할 수도 있습니다. 다음 레시피는 `if-elsif-else` 로직을 사용하여 이전 예제를 확장하므로 `/srv/www/shared`라는 이름의 하위 디렉터리를 생성하지만 Debian 및 Ubuntu 시스템에서만 가능합니다. 다른 모든 시스템의 경우, Test Kitchen 출력에 표시되는 오류 메시지를 로깅합니다.

```
if platform?("debian", "ubuntu")
  directory "/srv/www/shared" do
    mode 0755
    owner 'root'
    group 'root'
    recursive true
    action :create
  end
else
  log "Unsupported system"
end
```

**예제 레시피를 실행하려면**

1. 인스턴스가 여전히 실행 중인 경우 `kitchen destroy`를 실행하여 종료합니다.

1. `default.rb`의 코드를 이 예제 코드로 바꿉니다.

1. `.kitchen.yml`을 편집하여 CentOS 6.4 시스템을 플랫폼 목록에 추가합니다. 파일의 `platforms` 섹션은 다음과 같아야 합니다.

   ```
   ...
   platforms:
     - name: ubuntu-12.04
     - name: centos-6.4
   ...
   ```

1. `kitchen converge`를 실행합니다. 이 코드는 인스턴스를 생성하고 각 플랫폼에 대해 `.kitchen.yml`의 레시피를 순서대로 실행합니다.
**참고**  
인스턴스를 하나만 수렴하려는 경우 인스턴스 이름을 파라미터로 추가합니다. 예를 들어, Ubuntu 플랫폼에서만 레시피를 수렴하려면 `kitchen converge default-ubuntu-1204`를 실행합니다. 플랫폼 이름을 모르는 경우에는 `kitchen list`를 실행하면 됩니다.

Test Kitchen 출력의 CentOS 부분에 다음과 같은 로그 메시지가 표시되어야 합니다.

```
...
Converging 1 resources
Recipe: createdir::default
* log[Unsupported system] action write[2014-06-23T19:10:30+00:00] INFO: Processing log[Unsupported system] action write (createdir::default line 12)
[2014-06-23T19:10:30+00:00] INFO: Unsupported system
       
[2014-06-23T19:10:30+00:00] INFO: Chef Run complete in 0.004972162 seconds
```

이제 인스턴스에 로그인하여 디렉터리가 생성되었는지 여부를 확인할 수 있습니다. 다만 지금은 `kitchen login`을 실행할 수 없습니다. 플랫폼 이름(예: `kitchen login default-ubuntu-1204`)을 추가하여 어떤 인스턴스인지 지정해야 합니다.

**참고**  
Test Kitchen 명령이 인스턴스 이름을 받는 경우, 완전한 이름을 입력할 필요가 없습니다. Test Kitchen은 인스턴스 이름을 Ruby 정규식으로 취급하므로 고유한 일치를 제공하기에 충분한 문자만 있으면 됩니다. 예를 들어 `kitchen converge ub`를 실행하여 Ubuntu 인스턴스만 수렴하거나 `kitchen login 64`를 실행하여 CentOS 인스턴스에 로그인할 수 있습니다.

아마도 지금 시점에서 의문은 어떻게 레시피가 어느 플랫폼에서 실행 중인지 아느냐일 것입니다. Chef는 플랫폼을 포함한 시스템 데이터를 수집하는 모든 실행에 대해 [Ohai](https://docs.chef.io/ohai.html)라는 도구를 실행하며, 이를 *노드 객체*라고 하는 구조에서 속성 집합으로 나타냅니다. Chef `platform?` 메서드는 괄호로 묶인 시스템들을 Ohai 플랫폼 값과 비교하고 그중 하나가 일치하면 true를 반환합니다.

`node['attribute_name']`을 사용하면 코드에서 직접 노드 속성의 값 단원을 참조할 수 있습니다. 예를 들어 플랫폼 값은 `node['platform']`으로 나타냅니다. 가령 이전 예제를 다음과 같이 작성했을 수 있습니다.

```
if node[:platform] == 'debian' or node[:platform] == 'ubuntu'
  directory "/srv/www/shared" do
    mode 0755
    owner 'root'
    group 'root'
    recursive true
    action :create
  end
else
  log "Unsupported system"
end
```

레시피에 조건부 논리를 포함시키는 일반적 이유는 Linux 제품군마다 가끔 패키지, 디렉터리 등에 사용되는 이름이 다르다는 점을 감안하기 위해서입니다. 예를 들어 Apache 패키지 이름은 CentOS 시스템에서는 `httpd`이고 Ubuntu 시스템에서는 `apache2`입니다.

시스템에 따라 다른 문자열만이 필요한 경우, Chef [http://docs.chef.io/dsl_recipe.html#value-for-platform](http://docs.chef.io/dsl_recipe.html#value-for-platform) 메서드가 `if-elsif-else`보다 간단한 해법입니다. 다음 레시피는 CentOS 시스템에 `/srv/www/shared` 디렉터리, Ubuntu 시스템에 `/srv/www/data` 디렉터리, 그 밖의 모든 시스템에 `/srv/www/config` 디렉터리를 생성합니다.

```
data_dir = value_for_platform(
  "centos" => { "default" => "/srv/www/shared" },
  "ubuntu" => { "default" => "/srv/www/data" },
  "default" => "/srv/www/config"
)
directory data_dir do
  mode 0755
  owner 'root'
  group 'root'
  recursive true
  action :create
end
```

`value_for_platform`은 `data_dir`에 적절한 경로를 할당하며, `directory` 리소스는 이 값을 사용하여 디렉터리를 생성합니다.

**예제 레시피를 실행하려면**

1. 인스턴스가 여전히 실행 중인 경우 `kitchen destroy`를 실행하여 종료합니다.

1. `default.rb`의 코드를 이 예제 코드로 바꿉니다.

1. `kitchen converge`를 실행한 다음 각 인스턴스에 로그인하여 해당 디렉터리가 있는지 확인합니다.

# 예제 5: 속성 사용
<a name="cookbooks-101-basics-attributes"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 서비스 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

앞 섹션의 레시피는 플랫폼 이외의 모든 것에 하드코딩된 값을 사용했습니다. 이 방법은 예컨대 둘 이상의 레시피에 동일한 값을 사용하려는 경우, 불편할 수 있습니다. 쿡북에 속성 파일을 포함시키면 레시피와 별도로 값을 정의할 수 있습니다.

속성 파일은 하나 이상의 속성에 값을 할당하는 Ruby 애플리케이션입니다. 속성 파일은 쿡북의 `attributes` 폴더에 있어야 합니다. Chef는 속성을 노드 객체에 통합하며, 모든 레시피는 속성 단원을 참조하여 속성 값을 사용할 수 있습니다. 이 주제에서는 [반복](cookbooks-101-basics-ruby.md#cookbooks-101-basics-ruby-iteration)의 레시피를 수정하여 속성을 사용하는 방법을 살펴봅니다. 다음은 참조용 원래 레시피입니다.

```
[ "/srv/www/config", "/srv/www/shared" ].each do |path|
  directory path do
    mode 0755
    owner 'root'
    group 'root'
    recursive true
    action :create
  end
end
```

다음은 하위 디렉터리 이름, 모드, 소유자 및 그룹 값에 대해 속성을 정의합니다.

```
default['createdir']['shared_dir'] = 'shared'
default['createdir']['config_dir'] = 'config'
default['createdir']['mode'] = 0755
default['createdir']['owner'] = 'root'
default['createdir']['group'] = 'root'
```

다음 사항에 유의하세요.
+ 각 정의는 *속성 유형*으로 시작합니다.

  속성이 여러 번 정의된 경우(아마도 다른 속성 파일에서) 속성 유형에 따라 속성의 우선 순위가 지정되며, 이에 따라 노드 개체에 통합되는 정의가 결정됩니다. 자세한 내용은 [속성 우선 순위](workingcookbook-attributes-precedence.md) 섹션을 참조하세요. 이 예제의 모든 정의는 이 목적에 일반적인 유형인 `default` 속성 유형을 가지고 있습니다.
+ 속성에는 중첩된 이름이 있습니다.

  기본적으로 노드 객체는 임의로 깊이 중첩될 수 있는 해시 테이블이므로 속성 이름은 중첩이 가능하고 일반적으로 중첩됩니다. 이 속성 파일은 쿡북 이름인 `createdir`이 있는 중첩된 이름을 첫 번째 요소로 사용하는 표준 관행을 따릅니다.

createdir을 속성의 첫 번째 요소로 사용하는 이유는 Chef 실행 시 Chef가 모든 쿡북의 속성을 노드 객체에 통합하기 때문입니다. Stacks를 사용하면 노드 객체에는 정의한 속성 외에도 내장 OpsWorks 쿡북의 많은 속성이 포함됩니다. [https://github.com/aws/opsworks-cookbooks](https://github.com/aws/opsworks-cookbooks) 속성 이름에 쿡북 이름을 포함시키면 특히 속성이 `port` 또는 `user` 같은 이름을 가지고 있는 경우, 다른 쿡북의 속성과의 이름 충돌 위험이 줄어듭니다. 속성 값을 재정의하려는 경우가 아니라면 속성 이름을 [`[:apache2][:user]`](attributes-recipes-apache.md#attributes-recipes-apache-user)와 같이 명명하지 마십시오. 자세한 내용은 [사용자 지정 쿡북 속성 사용](workingcookbook-cookbook-attributes.md) 섹션을 참조하세요.

다음 예제는 하드코딩된 값 대신 속성을 사용하여 원래 레시피를 보여 줍니다.

```
[ "/srv/www/#{node['createdir']['shared_dir']}", "/srv/www/#{node['createdir']['config_dir']}" ].each do |path|
  directory path do
    mode node['createdir']['mode']
    owner node['createdir']['owner']
    group node['createdir']['group']
    recursive true
    action :create
  end
end
```

**참고**  
속성 값을 문자열에 통합하려면 `#{}`으로 묶습니다. 이전 예제에서 `#{node['createdir']['shared_dir']}`은 "shared"를 "/srv/www/"에 추가합니다.

**레시피를 실행하려면**

1. `kitchen destroy`를 실행하여 깨끗한 인스턴스로 시작합니다.

1. `recipes/default.rb`의 코드를 이전 레시피 예제로 바꿉니다.

1. `createdir`의 하위 디렉터리로 `attributes`를 만들고 속성 정의가 포함된 `default.rb` 파일을 추가합니다.

1. `.kitchen.yml`을 편집하여 플랫폼 목록에서 CentOS를 제거합니다.

1. `kitchen converge`를 실행한 다음 인스턴스에 로그인하여 `/srv/www/shared` 및 `/srv/www/config` 디렉터리가 있는지 확인합니다.

**참고**  
 OpsWorks Stacks를 사용하면 값을 속성으로 정의하면 추가 이점이 있습니다. 사용자 [지정 JSON](workingstacks-json.md)을 사용하여 스택별 또는 배포별로 해당 값을 재정의할 수 있습니다. 이는 다음을 비롯한 다양한 목적에 유용할 수 있습니다.  
쿡북을 수정할 필요 없이 구성 설정이나 사용자 이름 등 레시피의 동작을 사용자 지정할 수 있습니다.  
예를 들어 서로 다른 스택에 같은 쿡북을 사용하고 사용자 지정 JSON을 사용하여 특정 스택의 주요 구성 설정을 지정할 수 있습니다. 이렇게 하면 쿡북을 수정하거나 스택마다 다른 쿡북을 사용하는 데 드는 시간과 노력이 줄어듭니다.
데이터베이스 암호와 같이 잠재적으로 중요한 정보를 쿡북 리포지토리에 넣지 않아도 됩니다.  
그 대신 속성을 사용하여 기본값을 정의한 다음 사용자 지정 JSON을 사용하여 해당 값을 실제 값으로 재정의합니다.
사용자 지정 JSON을 사용하여 속성을 재정의하는 방법에 대한 자세한 정보는 [속성 재정의](workingcookbook-attributes.md) 단원을 참조하세요.

속성 파일은 다소 간단한 Ruby 애플리케이션이기 때문에 `default.rb`로 명명됩니다. 즉, 예컨대 조건부 논리를 사용하여 운영 체제를 기반으로 속성 값을 지정할 수 있습니다. [조건부 논리](cookbooks-101-basics-ruby.md#cookbooks-101-basics-ruby-conditional)에서는 레시피의 다양한 Linux 제품군에 다양한 하위 디렉터리 이름을 지정했습니다. 속성 파일이 있으면 그 대신 조건부 논리를 속성 파일에 넣을 수 있습니다.

다음 속성 파일은 `value_for_platform`을 사용하여 운영 체제에 따라 다른 `['shared_dir']` 속성 값을 지정합니다. 다른 조건의 경우, Ruby `if-elsif-else` 논리 또는 `case` 문을 사용할 수 있습니다.

```
data_dir = value_for_platform(
  "centos" => { "default" => "shared" },
  "ubuntu" => { "default" => "data" },
  "default" => "user_data"
)
default['createdir']['shared_dir'] = data_dir
default['createdir']['config_dir'] = "config"
default['createdir']['mode'] = 0755
default['createdir']['owner'] = 'root'
default['createdir']['group'] = 'root'
```

**레시피를 실행하려면**

1. `kitchen destroy`를 실행하여 깨끗한 인스턴스로 시작합니다.

1. `attributes/default.rb`의 코드를 이전 예제로 바꿉니다.

1. `.kitchen.yml` 단원에서 설명한 대로 [조건부 논리](cookbooks-101-basics-ruby.md#cookbooks-101-basics-ruby-conditional)을 편집하여 플랫폼 섹션에 CentOS 플랫폼을 추가합니다.

1. `kitchen converge`를 실행한 다음 인스턴스에 로그인하여 디렉터리가 있는지 확인합니다.

다 마치면 `kitchen destroy`를 실행해 인스턴스를 종료하세요. 다음 예제는 새 쿡북을 사용합니다.

# 예제 6: 파일 생성
<a name="cookbooks-101-basics-files"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 서비스 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

디렉터리를 생성한 후 구성 파일, 데이터 파일 등으로 디렉터리를 채워야 하는 경우가 많습니다. 이 주제에서는 인스턴스에 파일을 설치하는 두 가지 방법을 살펴봅니다.

**Topics**
+ [쿡북에서 파일 설치](#cookbooks-101-basics-files-cookbook_file)
+ [템플릿에서 파일 생성](#cookbooks-101-basics-files-template)

## 쿡북에서 파일 설치
<a name="cookbooks-101-basics-files-cookbook_file"></a>

인스턴스에 파일을 설치하는 가장 간단한 방법은 [https://docs.chef.io/chef/resources.html#cookbook-file](https://docs.chef.io/chef/resources.html#cookbook-file) 리소스를 사용하는 것입니다. 이 방법은 Linux와 Windows 시스템 모두 쿡북에서 파일을 인스턴스의 지정된 위치로 복사합니다. 이 예제는 [예제 3: 디렉터리 생성](cookbooks-101-basics-directories.md) 단원의 레시피를 확장해 디렉터리 생성 후 데이터 파일을 `/srv/www/shared`에 추가합니다. 다음은 참조용 원래 레시피입니다.

```
directory "/srv/www/shared" do
  mode 0755
  owner 'root'
  group 'root'
  recursive true
  action :create
end
```

**쿡북을 설정하려면**

1. `opsworks_cookbooks` 디렉터리 안에 `createfile` 하위 디렉터리를 만들고 그 디렉터리로 이동합니다.

1. `createfile`에 다음 콘텐츠가 포함된 `metadata.rb` 파일을 추가합니다.

   ```
   name "createfile"
   version "0.1.0"
   ```

1. [예제 1: 패키지 설치](cookbooks-101-basics-packages.md) 단원에서 설명하는 대로 Test Kitchen을 초기화 및 구성하고 `platforms` 목록에서 CentOS를 제거합니다.

1. `recipes` 하위 디렉터리를 `createfile`에 추가합니다.

설치할 파일에는 다음 JSON 데이터가 포함됩니다.

```
{
  "my_name" : "myname",
  "your_name" : "yourname",
  "a_number" : 42,
  "a_boolean" : true
}
```

**데이터 파일을 설정하려면**

1. `files` 하위 디렉터리는 `createfile`에, `default` 하위 디렉터리는 `files`에 추가합니다. `cookbook_file`을 사용하여 설치한 모든 파일은 `files`의 하위 디렉터리에 있어야 하며, 예를 들어 이 예에서는 `files/default`입니다.
**참고**  
시스템마다 다른 파일을 지정하려면 시스템의 이름을 딴 하위 폴더(예: `files/ubuntu`)에 각 시스템별 파일을 저장할 수 있습니다. `cookbook_file` 리소스는 해당하는 시스템별 파일이 있는 경우 복사하고 없는 경우 `default` 파일을 사용합니다. 자세한 정보는 [cookbook\$1file](https://docs.chef.io/chef/resources.html#cookbook-file) 단원을 참조하세요.

1. 이전 예제의 JSON을 사용하여 `example_data.json` 파일을 만들어 `files/default`에 추가합니다.

다음 레시피는 `example_data.json`을 지정된 위치로 복사합니다.

```
directory "/srv/www/shared" do
  mode 0755
  owner 'root'
  group 'root'
  recursive true
  action :create
end

cookbook_file "/srv/www/shared/example_data.json" do
  source "example_data.json"
  mode 0644
  action :create_if_missing
end
```

디렉터리 리소스가 `/srv/www/shared`를 생성한 후 `cookbook_file` 리소스가 `example_data.json`을 해당 디렉터리로 복사하고 파일의 사용자, 그룹, 모드도 설정합니다.

**참고**  
`cookbook_file` 리소스는 `create_if_missing`이라는 새로운 작업을 도입합니다. `create` 작업도 사용할 수 있지만 이 작업은 기존 파일을 덮어씁니다. 아무것도 덮어쓰지 않으려면 아직 존재하지 않는 경우에 한해 `create_if_missing`을 설치하는 `example_data.json`을 사용하세요.

**레시피를 실행하려면**

1. `kitchen destroy`를 실행하여 깨끗한 인스턴스로 시작합니다.

1. 이전 레시피가 포함된 `default.rb` 파일을 만든 다음 이 파일을 `recipes`에 저장합니다.

1. `kitchen converge`를 실행한 다음 인스턴스에 로그인하여 `/srv/www/shared` 디렉터리에 `example_data.json`이 포함되어 있는지 확인합니다.

## 템플릿에서 파일 생성
<a name="cookbooks-101-basics-files-template"></a>

`cookbook_file` 리소스는 일부 목적에는 유용하지만 쿡북에 있는 파일이라면 무엇이든 설치합니다. [https://docs.chef.io/chef/resources.html#template](https://docs.chef.io/chef/resources.html#template) 리소스는 템플릿에서 동적으로 파일을 생성함으로써 Windows 또는 Linux 인스턴스에 파일을 설치하는 보다 유연한 방법을 제공합니다. 그러면 실행 시간에 파일의 콘텐츠의 세부 정보를 확인하고 필요에 따라 변경할 수 있습니다. 예를 들어 인스턴스를 시작할 때는 구성 파일이 특정 설정을 갖고 나중에 스택에 더 많은 인스턴스를 추가할 때 이 설정을 수정하기를 원할 수 있습니다.

이 예제는 `createfile` 리소스를 사용하여 약간 수정된 `template` 버전을 설치하도록 `example_data.json` 쿡북을 수정합니다.

설치된 파일은 다음과 같이 보입니다.

```
{
  "my_name" : "myname",
  "your_name" : "yourname",
  "a_number" : 42,
  "a_boolean" : true,
  "a_string" : "some string",
  "platform" : "ubuntu"
}
```

템플릿 리소스는 일반적으로 속성 파일과 함께 사용되므로 예제에서는 속성 파일을 사용하여 다음 값을 지정합니다.

```
default['createfile']['my_name'] = 'myname'
default['createfile']['your_name'] = 'yourname'
default['createfile']['install_file'] = true
```

**쿡북을 설정하려면**

1. `createfile` 쿡북의 `files` 디렉터리와 포함된 내용을 모두 삭제합니다.

1. `attributes` 하위 디렉터리를 `createfile`에 추가하고, `default.rb` 파일을 이전 속성 정의가 포함된 `attributes`에 추가합니다.

템플릿은 기본적으로 콘텐츠 일부가 자리 표시자에 의해 표시되는 최종 파일의 사본인 `.erb` 파일입니다. `template` 리소스는 파일을 생성할 때 템플릿의 콘텐츠를 지정된 파일에 복사하고 자리 표시자를 할당된 값으로 덮어씁니다. 다음은 `example_data.json`에 대한 템플릿입니다.

```
{
  "my_name" : "<%= node['createfile']['my_name'] %>",
  "your_name" : "<%= node['createfile']['your_name'] %>",
  "a_number" : 42,
  "a_boolean" : <%= @a_boolean_var %>,
  "a_string" : "<%= @a_string_var %>",
  "platform" : "<%= node['platform'] %>"
}
```

`<%=...%>` 값은 자리 표시자입니다.
+ `<%=node[...]%>`은 노드 속성 값을 나타냅니다.

  이 예제에서 "your\$1name" 값은 쿡북 속성 파일의 속성 값 중 하나를 나타내는 자리 표시자입니다.
+ `<%=@...%>`는 간략히 설명한 것처럼 템플릿 리소스에서 정의되는 변수의 값을 나타냅니다.

**템플릿 파일을 생성하려면**

1. `templates` 하위 디렉터리는 `createfile` 쿡북에, `default` 하위 디렉터리는 `templates`에 추가합니다.
**참고**  
`templates` 디렉터리는 `files` 디렉터리처럼 작동합니다. 시스템별 템플릿은 시스템 이름을 딴 하위 디렉터리(예: `ubuntu`)에 저장할 수 있습니다. `template` 리소스는 해당하는 시스템별 템플릿이 있는 경우 사용하고 없는 경우 `default` 템플릿을 사용합니다.

1. `example_data.json.erb`라는 파일을 만들어 `templates/default` 디렉터리에 저장합니다. 템플릿 이름은 임의적이지만 일반적으로 파일 이름에 확장명을 포함해 `.erb`를 추가하여 템플릿 이름을 생성합니다.

다음 레시피는 `template` 리소스를 사용하여 `/srv/www/shared/example_data.json`을 생성합니다.

```
directory "/srv/www/shared" do
  mode 0755
  owner 'root'
  group 'root'
  recursive true
  action :create
end

template "/srv/www/shared/example_data.json" do
  source "example_data.json.erb"
  mode 0644
  variables(
    :a_boolean_var => true,
    :a_string_var => "some string"
  )
  only_if {node['createfile']['install_file']}
end
```

`template` 리소스는 템플릿에서 `example_data.json`을 생성하여 `/srv/www/shared`에 설치합니다.
+ 템플릿 이름 `/srv/www/shared/example_data.json`은 설치된 파일의 경로와 이름을 지정합니다.
+ `source` 속성은 파일 생성에 사용되는 템플릿을 지정합니다.
+ `mode` 속성은 설치된 파일의 모드를 지정합니다.
+ 리소스는 `a_boolean_var`와 `a_string_var`라는 두 가지 변수를 정의합니다.

  리소스는 `example_data.json`을 생성할 때 템플릿의 변수 자리 표시자를 리소스의 해당 값으로 덮어씁니다.
+ `only_if` *guard* 속성은 `['createfile']['install_file']`이 `true`로 설정되는 경우에만 파일을 생성하라고 리소스에 명령합니다.

**레시피를 실행하려면**

1. `kitchen destroy`를 실행하여 깨끗한 인스턴스로 시작합니다.

1. `recipes/default.rb`의 코드를 이전 예제로 바꿉니다.

1. `kitchen converge`를 실행한 다음 인스턴스에 로그인하여 파일이 `/srv/www/shared` 디렉터리에 있고 올바른 콘텐츠를 포함하고 있는지 확인합니다.

다 마치면 `kitchen destroy`를 실행해 인스턴스를 종료하세요. 다음 섹션에서는 새 쿡북을 사용합니다.

# 예제 7: 명령 및 스크립트 실행
<a name="cookbooks-101-basics-commands"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 서비스 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

Chef 리소스는 인스턴스에서 다양한 작업을 처리할 수 있지만 경우에 따라 셸 명령이나 스크립트를 사용하는 것이 좋습니다. 예를 들어 특정 작업을 수행하는 데 사용하는 스크립트가 이미 있고 새 코드를 구현하는 것보다 이 스크립트를 계속 사용하는 것이 더 쉬울 수 있습니다. 이 섹션에서는 인스턴스에서 명령 또는 스크립트를 실행하는 방법을 살펴봅니다.

**Topics**
+ [명령 실행](#cookbooks-101-basics-commands-script)
+ [스크립트 실행](#cookbooks-101-basics-commands-execute)

## 명령 실행
<a name="cookbooks-101-basics-commands-script"></a>

[https://docs.chef.io/chef/resources.html#script](https://docs.chef.io/chef/resources.html#script) 리소스는 하나 이상의 명령을 실행합니다. 이 리소스는 csh, bash, Perl, Python 및 Ruby 명령 인터프리터를 지원하므로 적절한 인터프리터가 설치되어 있다면 Linux 또는 Windows 시스템에서 사용할 수 있습니다. 이 주제에서는 Linux 인스턴스에서 간단한 bash 명령을 실행하는 방법을 살펴봅니다. Chef는 Windows에서 스크립트를 실행하기 위해 [powershell\$1script](https://docs.chef.io/chef/resources.html#powershell-script) 및 [batch](https://docs.chef.io/chef/resources.html#batch) 리소스도 지원합니다. 자세한 내용은 [Windows PowerShell 스크립트 실행](cookbooks-101-opsworks-opsworks-powershell.md) 섹션을 참조하세요.

**시작하려면**

1. `opsworks_cookbooks` 디렉터리 안에 `script` 하위 디렉터리를 만들고 그 디렉터리로 이동합니다.

1. `script`에 다음 콘텐츠가 포함된 `metadata.rb` 파일을 추가합니다.

   ```
   name "script"
   version "0.1.0"
   ```

1. [예제 1: 패키지 설치](cookbooks-101-basics-packages.md) 단원에서 설명하는 대로 Test Kitchen을 초기화 및 구성하고 `platforms` 목록에서 CentOS를 제거합니다.

1. `script` 안에 `recipes` 디렉터리를 만듭니다.

`script` 리소스 자체를 사용하여 명령을 실행할 수도 있지만 Chef는 인터프리터에 대해 명명되는 리소스의 명령 인터프리터별 버전 집합도 지원합니다. 다음 레시피는 [https://docs.chef.io/chef/resources.html#bash](https://docs.chef.io/chef/resources.html#bash) 리소스를 사용하여 간단한 bash 스크립트를 실행합니다.

```
bash "install_something" do
  user "root"
  cwd "/tmp"
  code <<-EOH
    touch somefile
  EOH
  not_if do
    File.exists?("/tmp/somefile")
  end
end
```

`bash` 리소스는 다음과 같이 구성됩니다.
+ bash 리소스는 `code` 블록에서 명령을 실행하는 기본 작업인 `run`을 사용합니다.

  이 예제에는 `touch somefile`이라는 명령 하나만 있지만 `code` 블록에는 여러 명령이 포함될 수 있습니다.
+ `user` 속성은 명령을 실행하는 사용자를 지정합니다.
+ `cwd` 속성은 작업 디렉터리를 지정합니다.

  이 예제에서는 `touch`가 `/tmp` 디렉터리에 파일을 생성합니다.
+ `not_if` guard 속성은 이 파일이 이미 존재하는 경우, 리소스에게 아무 작업도 하지 말라고 명령합니다.

**레시피를 실행하려면**

1. 이전 예제 코드가 포함된 `default.rb` 파일을 만든 다음 이 파일을 `recipes`에 저장합니다.

1. `kitchen converge`를 실행한 다음 인스턴스에 로그인하여 `/tmp` 디렉터리에 이 파일이 포함되어 있는지 확인합니다.

## 스크립트 실행
<a name="cookbooks-101-basics-commands-execute"></a>

`script` 리소스는 특히 하나 또는 두 개의 명령만 실행해야 하는 경우에 편리하지만 대체로 스크립트를 파일에 저장하고 파일을 실행하는 것이 더 좋습니다. [https://docs.chef.io/chef/resources.html#execute](https://docs.chef.io/chef/resources.html#execute) 리소스는 Linux 또는 Windows에서 스크립트 파일을 포함한 지정된 실행 파일을 실행합니다. 이 주제에서는 `script`를 사용하여 간단한 셸 스크립트를 실행하도록 앞의 예제의 `execute` 쿡북을 수정합니다. 더 복잡한 스크립트나 다른 실행 파일 유형까지 예제를 쉽게 확장할 수 있습니다.

**스크립트 파일을 설정하려면**

1. `files` 하위 디렉터리는 `script`에, `default` 하위 디렉터리는 `files`에 추가합니다.

1. 다음 코드가 포함된 `touchfile`이라는 파일을 만들어 `files/default`에 추가합니다. 이 예제에서는 일반적인 Bash 인터프리터 라인이 사용되지만 필요한 경우 사용자의 셸 환경에서 작동하는 인터프리터를 대체합니다.

   ```
   #!/usr/bin/env bash
   touch somefile
   ```

   스크립트 파일은 명령을 제한 없이 포함할 수 있습니다. 편의를 위해 이 예제 스크립트에는 `touch` 명령만 있습니다.

다음 레시피는 스크립트를 실행합니다.

```
cookbook_file "/tmp/touchfile" do
  source "touchfile"
  mode 0755
end

execute "touchfile" do
  user "root"
  cwd "/tmp"
  command "./touchfile"
end
```

`cookbook_file` 리소스는 스크립트 파일을 `/tmp`에 복사하고 파일을 실행 파일로 만들도록 모드를 설정합니다. 그런 다음 `execute` 리소스가 다음과 같이 파일을 실행합니다.
+ `user` 속성은 명령의 사용자(이 예제에서는 `root`)를 지정합니다.
+ `cwd` 속성은 작업 디렉터리(이 예제에서는 `/tmp`)를 지정합니다.
+ `command` 속성은 작업 디렉터리에 위치한 실행할 스크립트(이 예제에서는 `touchfile`)를 지정합니다.

**레시피를 실행하려면**

1. `recipes/default.rb`의 코드를 이전 예제로 바꿉니다.

1. `kitchen converge`를 실행한 다음 인스턴스에 로그인하여 `/tmp` 디렉터리에 모드가 0755로 설정된 스크립트 파일과 `somefile` 디렉터리 파일이 있는지 확인합니다.

다 마치면 `kitchen destroy`를 실행해 인스턴스를 종료하세요. 다음 섹션에서는 새 쿡북을 사용합니다.

# 예제 8: 서비스 관리
<a name="cookbooks-101-basics-services"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 서비스 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

애플리케이션 서버와 같은 패키지에는 일반적으로 시작, 중지, 재시작해야 하는 연결된 서비스가 있습니다. 예를 들어 패키지를 설치한 후 또는 인스턴스 부팅이 완료된 후에 Tomcat 서비스를 시작하고 구성 파일을 수정할 때마다 서비스를 다시 시작해야 합니다. 이 주제에서는 Tomcat 애플리케이션 서버를 예제로 사용하여 Linux 인스턴스에서 서비스를 관리하는 방법의 기초를 살펴봅니다. 서비스 리소스는 Windows 인스턴스에서와 거의 비슷한 방식으로 작동하지만 세부적으로는 몇 가지 차이점이 있습니다. 자세한 내용은 [https://docs.chef.io/chef/resources.html#service](https://docs.chef.io/chef/resources.html#service) 단원을 참조하십시오.

**참고**  
예제에서는 `service` 리소스 사용 방법의 기초를 보여 주기에 충분한 정도로만 Tomcat을 최소 설치합니다. 기능이 더 많은 Tomcat 서버를 위한 레시피 구현 방법의 예제는 [사용자 지정 Tomcat 서버 계층 생성](create-custom.md) 단원을 참조하세요.

**Topics**
+ [서비스 정의 및 시작](#cookbooks-101-basics-services-service)
+ [notifies를 사용하여 서비스 시작 또는 재시작](#cookbooks-101-basics-services-notifies)

## 서비스 정의 및 시작
<a name="cookbooks-101-basics-services-service"></a>

이 섹션에서는 서비스를 정의하고 시작하는 방법의 기초를 살펴봅니다.

**시작하려면**

1. `opsworks_cookbooks` 디렉터리 안에 `tomcat` 디렉터리를 만들고 그 디렉터리로 이동합니다.

1. `tomcat`에 다음 콘텐츠가 포함된 `metadata.rb` 파일을 추가합니다.

   ```
   name "tomcat"
   version "0.1.0"
   ```

1. [예제 1: 패키지 설치](cookbooks-101-basics-packages.md) 단원에서 설명하는 대로 Test Kitchen을 초기화 및 구성하고 `platforms` 목록에서 CentOS를 제거합니다.

1. `recipes` 하위 디렉터리를 `tomcat`에 추가합니다.

[https://docs.chef.io/chef/resources.html#service](https://docs.chef.io/chef/resources.html#service) 리소스를 사용하여 서비스를 관리합니다. 다음의 기본 레시피는 Tomcat을 설치하고 서비스를 시작합니다.

```
execute "install_updates" do
  command "apt-get update"
end

package "tomcat7" do
    action :install
end

include_recipe 'tomcat::service'

service 'tomcat' do
  action :start
end
```

이 레시피는 다음 작업을 수행합니다.
+ `execute` 리소스는 `apt-get update`를 실행하여 최신 시스템 업데이트를 설치합니다.

  이 예제에서 사용하는 Ubuntu 인스턴스의 경우, Tomcat을 설치하기 전에 업데이트를 설치해야 합니다. 다른 시스템은 요구 사항이 다를 수 있습니다.
+ `package` 리소스는 Tomcat 7을 설치합니다.
+ 포함된 `tomcat::service` 레시피는 서비스를 정의하며, 나중에 설명합니다.
+ `service` 리소스는 Tomcat 서비스를 시작합니다.

  이 리소스를 사용하여 서비스 중단 및 재시작 같은 다른 명령을 실행할 수도 있습니다.

다음 예제는 `tomcat::service` 레시피를 보여 줍니다.

```
service 'tomcat' do
  service_name "tomcat7"
  supports :restart => true, :reload => false, :status => true
  action :nothing
end
```

이 레시피는 다음과 같이 Tomcat 서비스 정의를 생성합니다.
+ 리소스 이름인 `tomcat`은 다른 레시피가 서비스를 참조하는 데 사용합니다.

  예를 들어 `default.rb`는 서비스를 시작하기 위해 `tomcat` 단원을 참조합니다.
+ `service_name` 리소스는 서비스 이름을 지정합니다.

  인스턴스에서 서비스를 나열할 때 Tomcat 서비스는 tomcat7으로 명명됩니다.
+ `supports`는 Chef가 서비스의 `restart`, `reload` 및 `status` 명령을 관리하는 방법을 지정합니다.
  + `true`는 Chef가 init 스크립트 또는 그 밖의 서비스 공급자를 사용하여 명령을 실행할 수 있음을 나타냅니다.
  + `false`는 Chef가 다른 수단을 사용하여 명령을 실행하려 시도해야 함을 나타냅니다.

`action`이 `:nothing`으로 설정되어 있어 아무 작업도 하지 말라고 리소스에게 명령한다는 점에 유의하세요. 서비스 리소스는 `start` 및 `restart`와 같은 작업을 지원합니다. 하지만 이 쿡북은 아무 작업도 하지 않는 서비스 정의를 사용하고 다른 곳에서 서비스를 시작하거나 다시 시작하는 표준 관행에 따릅니다. 서비스를 시작하거나 다시 시작하는 각각의 레시피는 먼저 서비스를 정의해야 하므로 가장 간단한 방법은 서비스 정의를 별도의 레시피에 넣고 필요에 따라 다른 레시피에 포함시키는 것입니다.

**참고**  
간단히 하기 위해 이 예제의 기본 레시피는 서비스 정의를 실행한 후 `service` 리소스를 사용하여 서비스를 시작합니다. 프로덕션 구현은 일반적으로 뒤에서 설명하는 것처럼 `notifies`를 사용하여 서비스를 시작하거나 다시 시작합니다.

**레시피를 실행하려면**

1. 기본 레시피 예제가 포함된 `default.rb` 파일을 만든 다음 이 파일을 `recipes`에 저장합니다.

1. 서비스 정의 예제가 포함된 `service.rb` 파일을 만든 다음 이 파일을 `recipes`에 저장합니다.

1. `kitchen converge`를 실행한 다음 인스턴스에 로그인하고 다음 명령을 실행해서 서비스가 실행 중인지 확인하세요.

   ```
   sudo service tomcat7 status
   ```

**참고**  
`service.rb`를 `default.rb`와 별도로 실행한 경우, `.kitchen.yml`을 편집하여 `tomcat::service`를 실행 목록에 추가해야 합니다. 다만 레시피를 포함시키면 레시피가 실행되기 전에 그 코드가 상위 레시피에 통합됩니다. 따라서 `service.rb`는 `default.rb`의 일부이며 별도의 실행 목록 항목이 필요하지 않습니다.

## notifies를 사용하여 서비스 시작 또는 재시작
<a name="cookbooks-101-basics-services-notifies"></a>

프로덕션 구현은 일반적으로 서비스를 시작하거나 다시 시작하는 데 `service`를 사용하지 않습니다. 그 대신 몇몇 리소스에 `notifies`를 추가합니다. 예를 들어 구성 파일을 수정한 후 서비스를 다시 시작하려면 연결된 `notifies` 리소스에 `template`를 포함시킵니다. `notifies`를 사용하면 `service` 리소스를 사용하여 명시적으로 서비스를 다시 시작하는 방법에 비해 다음과 같은 장점이 있습니다.
+ `notifies` 요소는 연결된 구성 파일이 변경된 경우에만 서비스를 다시 시작하므로 불필요한 서비스 재시작을 초래할 위험이 없습니다.
+ Chef는 실행에 얼마나 많은 `notifies`가 포함되는지에 상관없이 각 실행이 끝날 때 많아야 한 번 서비스를 다시 시작합니다.

  예를 들어 Chef 실행에는 각각 서로 다른 구성 파일을 수정하고 파일이 변경된 경우 서비스를 다시 시작해야 하는 여러 개의 템플릿 리소스가 포함될 수 있습니다. 하지만 사용자는 일반적으로 Chef 실행이 끝날 때 한 번만 서비스를 다시 시작하려 합니다. 그렇지 않다면 이전의 재시작으로 완전히 작동하지 않아 오류를 발생시킬 수 있는 서비스를 다시 시작하려 시도할 수 있습니다.

이 예제는 `tomcat::default`를 사용하여 서비스를 다시 시작하는 `template` 리소스를 포함하도록 `notifies`를 수정합니다. 현실적 예에서는 Tomcat 구성 파일 중 하나의 사용자 지정 버전을 생성하는 템플릿 리소스를 사용하겠지만 과정이 길고 복잡합니다. 간단히 하기 위해 이 예제는 [템플릿에서 파일 생성](cookbooks-101-basics-files.md#cookbooks-101-basics-files-template)의 템플릿 리소스를 사용합니다. 이 리소스는 Tomcat과 아무 관련이 없지만 `notifies` 사용 방법을 간단히 보여 줍니다. 템플릿을 사용해 Tomcat 구성 파일을 생성하는 방법의 예제는 [설정 레시피](create-custom-setup.md) 단원을 참조하세요.

**쿡북을 설정하려면**

1. `templates` 하위 디렉터리는 `tomcat`에, `default` 하위 디렉터리는 `templates`에 추가합니다.

1. `example_data.json.erb` 쿡북에서 `createfile` 디렉터리로 `templates/default` 템플릿을 복사합니다.

1. `attributes`에 `tomcat` 하위 디렉터리를 추가합니다.

1. `default.rb` 쿡북에서 `createfile` 디렉터리로 `attributes` 속성 파일을 복사합니다.

다음 레시피는 `notifies`를 사용하여 Tomcat 서비스를 다시 시작합니다.

```
execute "install_updates" do
  command "apt-get update"
end

package "tomcat7" do
    action :install
end

include_recipe 'tomcat::service'

service 'tomcat' do
  action :enable
end

directory "/srv/www/shared" do
  mode 0755
  owner 'root'
  group 'root'
  recursive true
  action :create
end

template "/srv/www/shared/example_data.json" do
  source "example_data.json.erb"
  mode 0644
  variables(
    :a_boolean_var => true,
    :a_string_var => "some string"
  )
  only_if {node['createfile']['install_file']}
  notifies :restart, resources(:service => 'tomcat')
end
```

이 예제는 [템플릿에서 파일 생성](cookbooks-101-basics-files.md#cookbooks-101-basics-files-template)의 레시피를 이전 섹션의 레시피에 병합하며, 다음과 같은 두 가지 중요한 변경이 있습니다.
+ `service` 리소스는 그대로 있지만 이제는 약간 다른 용도로 사용됩니다.

  `:enable` 작업은 부팅 시 Tomcat 서비스를 활성화합니다.
+ 이제 템플릿 리소스에는 `notifies`이 변경된 경우, Tomcat 서비스를 다시 시작하는 `example_data.json`가 포함됩니다.

  이로써 서비스는 Tomcat이 처음 설치될 때 시작되고 구성 파일 변경 후마다 다시 시작됩니다.

**레시피를 실행하려면**

1. `kitchen destroy`를 실행하여 깨끗한 인스턴스로 시작합니다.

1. `default.rb`의 코드를 이전 예제로 바꿉니다.

1. `kitchen converge`를 실행한 다음 인스턴스에 로그인하여 서비스가 실행 중인지 확인합니다.

**참고**  
서비스를 다시 시작하고 싶지만 레시피에 `template` 등 `notifies`를 지원하는 리소스가 없는 경우, 그 대신 더미 `execute` 리소스를 사용할 수 있습니다. 예제  

```
execute 'trigger tomcat service restart' do
  command 'bin/true'
  notifies :restart, resources(:service => 'tomcat')
end
```
`execute` 리소스는 `command`를 실행하는 방법으로만 사용한다 하더라도 `notifies` 속성이 있어야 합니다. 이 예제에서는 단순히 성공 코드를 반환하는 셸 명령인 `/bin/true`를 실행함으로써 이러한 요구를 해결합니다.

# 예제 9: Amazon EC2 인스턴스 사용
<a name="cookbooks-101-basics-ec2"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 서비스 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

지금까지는 VirtualBox에서 로컬로 인스턴스를 실행했습니다. 이 방법이 빠르고 쉽기는 하지만 결국은 Amazon EC2 인스턴스에서 레시피를 테스트해야 합니다. 특히 Amazon Linux에서 레시피를 실행하려면 Amazon EC2에서만 가능합니다. 예비 구현 및 테스트를 위해 CentOS 같은 비슷한 시스템을 사용할 수 있지만 Amazon Linux에서 레시피를 완전히 테스트하는 유일한 방법은 Amazon EC2 인스턴스를 사용하는 것입니다.

이 주제에서는 Amazon EC2 인스턴스에서 레시피를 실행하는 방법을 살펴봅니다. 다음 두 가지 차이점만 제외하고 Test Kitchen과 Vagrant도 앞 섹션과 거의 같은 방법으로 사용합니다.
+ 드라이버가 Vagrant 대신 [https://rubygems.org/gems/kitchen-ec2](https://rubygems.org/gems/kitchen-ec2)입니다.
+ Amazon EC2 인스턴스를 시작하는 데 필요한 정보를 사용하여 쿡북의 `.kitchen.yml` 파일을 구성해야 합니다.

**참고**  
대안적 방법은 `vagrant-aws` Vagrant 플러그인을 사용하는 것입니다. 자세한 정보는 [Vagrant AWS 공급자](https://github.com/mitchellh/vagrant-aws)를 참조하세요.

Amazon EC2 인스턴스를 생성하려면 AWS 자격 증명이 필요합니다. AWS 계정이 없는 경우, 다음과 같이 계정을 얻을 수 있습니다.

## 에 가입 AWS 계정
<a name="sign-up-for-aws"></a>

이 없는 경우 다음 단계를 AWS 계정완료하여 생성합니다.

**에 가입하려면 AWS 계정**

1. [https://portal.aws.amazon.com/billing/signup](https://portal.aws.amazon.com/billing/signup)을 엽니다.

1. 온라인 지시 사항을 따르세요.

   등록 절차 중 전화 또는 텍스트 메시지를 받고 전화 키패드로 확인 코드를 입력하는 과정이 있습니다.

   에 가입하면 AWS 계정*AWS 계정 루트 사용자*이 생성됩니다. 루트 사용자에게는 계정의 모든 AWS 서비스 및 리소스에 액세스할 권한이 있습니다. 보안 모범 사례는 사용자에게 관리 액세스 권한을 할당하고, 루트 사용자만 사용하여 [루트 사용자 액세스 권한이 필요한 작업](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)을 수행하는 것입니다.

AWS 는 가입 프로세스가 완료된 후 확인 이메일을 보냅니다. 언제든지 [https://aws.amazon.com/](https://aws.amazon.com/)으로 이동하고 **내 계정**을 선택하여 현재 계정 활동을 확인하고 계정을 관리할 수 있습니다.

## 관리자 액세스 권한이 있는 사용자 생성
<a name="create-an-admin"></a>

에 가입한 후 일상적인 작업에 루트 사용자를 사용하지 않도록 관리 사용자를 AWS 계정보호 AWS IAM Identity Center, AWS 계정 루트 사용자활성화 및 생성합니다.

**보안 AWS 계정 루트 사용자**

1.  **루트 사용자를** 선택하고 AWS 계정 이메일 주소를 입력하여 계정 소유자[AWS Management Console](https://console.aws.amazon.com/)로에 로그인합니다. 다음 페이지에서 비밀번호를 입력합니다.

   루트 사용자를 사용하여 로그인하는 데 도움이 필요하면 *AWS Sign-In 사용 설명서*의 [루트 사용자로 로그인](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial)을 참조하세요.

1. 루트 사용자의 다중 인증(MFA)을 활성화합니다.

   지침은 *IAM 사용 설명서*의 [AWS 계정 루트 사용자(콘솔)에 대한 가상 MFA 디바이스 활성화를 참조하세요](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html).

**관리자 액세스 권한이 있는 사용자 생성**

1. IAM Identity Center를 활성화합니다.

   지침은 *AWS IAM Identity Center 사용 설명서*의 [AWS IAM Identity Center설정](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-set-up-for-idc.html)을 참조하세요.

1. IAM Identity Center에서 사용자에게 관리 액세스 권한을 부여합니다.

   를 자격 증명 소스 IAM Identity Center 디렉터리 로 사용하는 방법에 대한 자습서는 사용 *AWS IAM Identity Center 설명서*[의 기본값으로 사용자 액세스 구성을 IAM Identity Center 디렉터리](https://docs.aws.amazon.com/singlesignon/latest/userguide/quick-start-default-idc.html) 참조하세요.

**관리 액세스 권한이 있는 사용자로 로그인**
+ IAM IDentity Center 사용자로 로그인하려면 IAM Identity Center 사용자를 생성할 때 이메일 주소로 전송된 로그인 URL을 사용합니다.

  IAM Identity Center 사용자를 사용하여 로그인하는 데 도움이 필요하면 *AWS Sign-In 사용 설명서*[의 AWS 액세스 포털에 로그인](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html)을 참조하세요.

**추가 사용자에게 액세스 권한 할당**

1. IAM Identity Center에서 최소 권한 적용 모범 사례를 따르는 권한 세트를 생성합니다.

   지침은 *AWS IAM Identity Center 사용 설명서*의 [Create a permission set](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-started-create-a-permission-set.html)를 참조하세요.

1. 사용자를 그룹에 할당하고, 그룹에 Single Sign-On 액세스 권한을 할당합니다.

   지침은 *AWS IAM Identity Center 사용 설명서*의 [그룹 추가](https://docs.aws.amazon.com/singlesignon/latest/userguide/addgroups.html)를 참조하세요.

Amazon EC2에 액세스할 수 있는 권한이 있는 [IAM 사용자를 생성하고](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html) 사용자의 액세스 및 보안 키를 워크스테이션의 안전한 위치에 저장해야 합니다. Test Kitchen은 이 자격 증명을 사용하여 인스턴스를 생성합니다. Test Kitchen에 자격 증명을 제공하는 선호되는 방법은 워크스테이션에서 다음 환경 변수에 키를 할당하는 것입니다.

**주의**  
IAM 사용자는 장기 자격 증명을 가지므로 보안 위험이 있습니다. 이 위험을 줄이려면 이러한 사용자에게 작업을 수행하는 데 필요한 권한만 제공하고 더 이상 필요하지 않을 경우 이러한 사용자를 제거하는 것이 좋습니다.
+ AWS\$1ACCESS\$1KEY - 사용자의 액세스 키로,와 비슷합니다AKIAIOSFODNN7EXAMPLE.
+ AWS\$1SECRET\$1KEY - 사용자의 보안 키로,와 비슷합니다wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY.

이 방법은 예컨대 자격 증명이 포함된 프로젝트를 퍼블릭 리포지토리에 업로드함으로써 뜻하지 않게 계정이 침해될 가능성을 줄입니다.

**쿡북을 설정하려면**

1. `kitchen-ec2` 드라이버를 사용하려면 시스템에 `ruby-dev` 패키지가 설치되어 있어야 합니다. 다음 예제 명령은 `aptitude`를 사용하여 Ubuntu 시스템에 패키지를 설치하는 방법을 보여줍니다.

   ```
   sudo aptitude install ruby1.9.1-dev 
   ```

1. `kitchen-ec2` 드라이버는 다음과 같이 설치할 수 있는 Gem입니다.

   ```
   gem install kitchen-ec2
   ```

   워크스테이션에 따라 이 명령에는 `sudo`가 필요할 수 있습니다. 또는 Ruby 환경 관리자(예: [RVM](https://rvm.io/))를 사용할 수도 있습니다. 이 절차는 `kitchen-ec2` 드라이버 버전 0.8.0에서 테스트했으나 최신 버전이 있습니다. [특정 버전](https://rubygems.org/gems/kitchen-ec2/versions)을 설치하려면 `gem install kitchen-ec2 -v <version number>`를 실행합니다.

1. Test Kitchen이 인스턴스에 연결하는 데 사용할 수 있는 Amazon EC2 SSH 키 페어를 지정해야 합니다. Amazon EC2 키 페어가 없는 경우 이러한 키 페어를 생성하는 방법은 [Amazon EC2 키 페어](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)를 참조하세요. 키 페어는 인스턴스와 동일한 AWS 리전에 속해야 합니다. 이 예에서는 미국 서부(캘리포니아 북부)를 사용합니다.

   키 페어를 선택한 후에는 `opsworks_cookbooks`의 하위 디렉터리로 `ec2_keys`를 만들고 해당 키 페어의 프라이빗 키(`.pem`) 파일을 이 하위 디렉터리에 복사합니다. 프라이빗 키는 시스템의 모든 위치에 저장할 수 있지만 `ec2_keys`에 저장하면 코드가 간소화되어 편리합니다.

1. `createdir-ec2`의 하위 디렉터리 `opsworks_cookbooks`를 만들고 그 디렉터리로 이동합니다.

1. `createdir-ec2`에 다음 콘텐츠가 포함된 `metadata.rb` 파일을 추가합니다.

   ```
   name "createdir-ec2"
   version "0.1.0"
   ```

1. [예제 1: 패키지 설치](cookbooks-101-basics-packages.md) 단원에서 설명하는 대로 Test Kitchen을 초기화합니다. 다음 단원에서는 `.kitchen.yml`을 구성하는 방법에 대해 설명합니다. 이 파일은 Amazon EC2 인스턴스의 경우 훨씬 더 복잡합니다.

1. `recipes` 하위 디렉터리를 `createdir-ec2`에 추가합니다.

## Amazon EC2용 .kitchen.yml 구성
<a name="w2ab1c14c71b9c15c17c31c37"></a>

`kitchen-ec2` 드라이버가 적절히 구성된 Amazon EC2 인스턴스를 시작하는 데 필요한 정보를 사용하여 `.kitchen.yml`을 구성합니다. 다음은 미국 서부(캘리포니아 북부) 리전의 Amazon Linux 인스턴스용 `.kitchen.yml` 파일의 예입니다.

```
driver:
  name: ec2
  aws_ssh_key_id: US-East1
  region: us-west-1
  availability_zone: us-west-1c
  require_chef_omnibus: true
  security_group_ids: sg........
  subnet_id: subnet-.........
  associate_public_ip: true
  interface: dns

provisioner:
  name: chef_solo

platforms:
  -name: amazon
  driver:
    image_id: ami-xxxxxxxx
  transport:
    username: ec2-user
    ssh_key: ../ec2_keys/US-East1.pem

suites:
  - name: default
    run_list:
      - recipe[createdir-ec2::default]
    attributes:
```

`provisioner` 및 `suites` 섹션의 기본 설정을 사용할 수 있지만 기본 `driver` 및 `platforms` 설정을 수정해야 합니다. 이 예제에서는 최소한의 설정 목록을 사용하며 나머지에 대해서는 기본값을 사용합니다. 완전한 `kitchen-ec2` 설정 목록은 [Kitchen::Ec2: Amazon EC2용 Test Kitchen 드라이버](https://github.com/test-kitchen/kitchen-ec2)를 참조하세요.

이 예제는 다음 `driver` 속성을 설정합니다. 이 예제에서는 앞서 설명한 것처럼 사용자의 액세스 키와 보안 키를 표준 환경 변수에 할당했다고 가정합니다. 드라이버는 기본적으로 이러한 키를 사용합니다. 그렇지 않은 경우, `aws_access_key_id`와 `aws_secret_access_key`를 `driver` 속성에 추가하여 명시적으로 키를 지정하고 적절한 키 값으로 설정해야 합니다.

**이름**  
(필수) 이 속성은 `ec2`로 설정해야 합니다.

**aws\$1ssh\$1key\$1id**  
(필수) 이 예제에서 `US-East1`으로 명명된 Amazon EC2 SSH 키 페어 이름.

**transport.ssh\$1key**  
(필수) `aws_ssh_key_id`에 대해 지정한 키의 프라이빗 키(`.pem`) 파일. 이 예제에서 이 파일은 `US-East1.pem`으로 명명되며 `../opsworks/ec2_keys` 디렉터리에 있습니다.

**리전**  
(필수) 인스턴스의 AWS 리전. 이 예에서는) 로 `us-west-1` 표시되는 미국 서부(캘리포니아 북부)를 사용합니다.

**availability\$1zone**  
(선택 사항) 인스턴스의 가용 영역. 이 설정을 생략하면 Test Kitchen은 지정된 리전에 대해 기본 가용 영역(`us-west-1b`의 경우, 미국 서부(캘리포니아 북부))를 사용합니다. 하지만 이 가용 영역은 사용자 계정에서 사용하지 못할 수 있습니다. 이 경우, 가용 영역을 명시적으로 지정해야 합니다. 마침 이 예제를 준비하는 데 사용된 계정이 `us-west-1b`를 지원하지 않기 때문에 예제는 명시적으로 `us-west-1c`를 지정합니다.

**require\$1chef\$1omnibus**  
이 설정을 `true`로 설정하면 omnibus installer를 사용하여 모든 플랫폼 인스턴스에 `chef-client`를 설치합니다.

**security\$1group\$1ids**  
(선택 사항) 인스턴스에 적용할 보안 그룹 ID 목록. 이 설정은 `default` 보안 그룹을 인스턴스에 적용합니다. 보안 그룹 수신 규칙이 인바운드 SSH 연결을 허용하도록 하세요. 그렇지 않으면 Test Kitchen이 인스턴스와 통신할 수 없습니다. `default` 보안 그룹을 사용하는 경우, 그에 맞게 편집해야 할 수 있습니다. 자세한 내용은 [Amazon EC2 보안 그룹](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html)을 참조하세요.

**subnet\$1id**  
인스턴스의 대상 서브넷 ID(해당되는 경우).

**associate\$1public\$1ip**  
인터넷에서 인스턴스에 액세스할 수 있도록 Amazon EC2 인스턴스가 해당 인스턴스에 퍼블릭 IP 주소를 연결하도록 할 수 있습니다.

**인터페이스**  
인스턴스에 액세스하는 데 사용하는 호스트 이름 구성 형식. 유효한 값은 `dns`, `public`, `private` 또는 `private_dns`입니다. 이 속성의 값을 지정하지 않으면 `kitchen-ec2`이 다음 순서로 호스트 이름 구성을 설정합니다. 이 속성을 생략하면 구성 형식이 설정되지 않습니다.  

1. DNS 이름

1. 퍼블릭 IP 주소

1. 프라이빗 IP 주소

1. 프라이빗 DNS 이름

**중요**  
액세스 키와 보안 키에 계정 자격 증명을 사용하는 대신 사용자를 생성해 이러한 자격 증명을 Test Kitchen에 제공해야 합니다. 자세한 내용은 [AWS 액세스 키 관리 모범 사례](https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html)를 참조하세요.  
`.kitchen.yml`을 공용 액세스가 가능한 위치에 저장하지 않도록 주의하세요(예: 퍼블릭 GitHub 또는 Bitbucket 리포지토리에 업로드). 그러면 자격 증명이 노출되고 계정의 보안이 훼손될 수 있습니다.

`kitchen-ec2` 드라이버는 다음 플랫폼에 대한 기본 지원을 제공합니다.
+ ubuntu-10.04
+ ubuntu-12.04
+ ubuntu-12.10
+ ubuntu-13.04
+ ubuntu-13.10
+ ubuntu-14.04
+ centos-6.4
+ debian-7.1.0
+ windows-2012r2
+ windows-2008r2

이런 플랫폼을 하나 이상 사용하려는 경우, 적절한 플랫폼 이름을 `platforms`에 추가합니다. `kitchen-ec2` 드라이버가 자동으로 적절한 AMI를 선택하고 SSH 사용자 이름을 생성합니다. 다른 플랫폼(이 예에서는 Amazon Linux 사용)을 사용할 수 있지만 다음 `platforms` 속성을 명시적으로 지정해야 합니다. 

**이름**  
플랫폼 이름. 이 예제는 Amazon Linux를 사용하므로 `name`이 `amazon`으로 설정됩니다.

**driver**  
다음을 포함하는 `driver` 속성.  
+ `image_id` – 플랫폼의 AMI로서 지정된 리전에 속해야 합니다. 이 예제는 미국 서부(캘리포니아 북부) 리전의 Amazon Linux AMI인 `ami-ed8e9284`를 사용합니다.
+ `transport.username` – Test Kitchen이 인스턴스와의 통신에 사용할 SSH 사용자 이름.

  Amazon Linux의 경우, `ec2-user`를 사용합니다. 다른 AMI는 사용자 이름이 다를 수 있습니다.

`.kitchen.yml`의 코드를 예제로 바꾸고 `aws_access_key_id`와 같은 계정별 속성에 적절한 값을 할당합니다.

## 레시피 실행
<a name="w2ab1c14c71b9c15c17c31c39"></a>

이 예제는 [반복](cookbooks-101-basics-ruby.md#cookbooks-101-basics-ruby-iteration)의 레시피를 사용합니다.

**레시피를 실행하려면**

1. 다음 코드를 사용하여 `default.rb` 파일을 만들어 이 파일을 쿡북의 `recipes` 폴더에 저장합니다.

   ```
   directory "/srv/www/shared" do
     mode 0755
     owner 'root'
     group 'root'
     recursive true
     action :create
   end
   ```

1. `kitchen converge`를 실행하여 레시피를 실행합니다. Amazon EC2 인스턴스를 시작 및 초기화하는 데 필요한 시간 때문에 이전 예제보다 이 명령을 완료하는 데 더 많은 시간이 걸릴 수 있습니다.

1.  [Amazon EC2 콘솔](https://console.aws.amazon.com/ec2/)로 이동하여 미국 서부(캘리포니아 북부) 리전을 선택하고 탐색 창에서 **인스턴스**를 클릭합니다. 목록에 새로 생성된 인스턴스가 보입니다.

1. VirtualBox에서 실행 중인 인스턴스에 대해 수행한 것처럼 `kitchen login`을 실행하여 인스턴스에 로그인합니다. `/srv`에 새로 생성된 디렉터리가 있습니다. 이제 즐겨 사용하는 SSH 클라이언트를 사용하여 인스턴스에 연결할 수 있습니다.

# 다음 단계
<a name="cookbooks-101-basics-next"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 서비스 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

이 장에서 Chef 쿡북 구현 방법의 기초를 살펴봤지만 아직 많은 내용이 남아 있습니다.
+ 예제에서 보다 일반적으로 사용되는 몇몇 리소스를 사용하는 방법을 보여 주었지만 아직 다루지 않은 내용이 많습니다.

  우리가 다룬 리소스의 경우, 예제에서는 사용할 수 있는 속성과 작업 일부만이 사용됐습니다. 완전한 참조는 [리소스 및 공급자에 대하여](https://docs.chef.io/resource.html)를 참조하세요.
+ 예제는 핵심 쿡북 요소인 `recipes`, `attributes`, `files`, `templates`만을 사용했습니다.

  쿡북에는 `libraries`, `definitions`, `specs`와 같은 그 밖의 다양한 요소도 포함될 수 있습니다. 자세한 정보는 [Chef 설명서](https://docs.chef.io)를 참조하세요.
+ 예제에서는 인스턴스를 시작하고, 레시피를 실행하며, 인스턴스에 로그인하는 편리한 방법으로만 Test Kitchen을 사용했습니다.

  Test Kitchen은 기본적으로 레시피에서 다양한 테스트를 실행할 수 있는 테스트 플랫폼입니다. 아직 살펴보지 않았다면 Test Kitchen의 테스트 기능을 소개하는 [Test Kitchen walkthrough](https://kitchen.ci/docs/getting-started/introduction/)를 살펴보십시오.
+ [OpsWorks 스택용 쿡북 구현](cookbooks-101-opsworks.md)는 몇 가지 고급 예제를 제공하며 Stacks용 OpsWorks 쿡북을 구현하는 방법을 보여줍니다.

# OpsWorks 스택용 쿡북 구현
<a name="cookbooks-101-opsworks"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

[쿡북 기본 사항](cookbooks-101-basics.md) 섹션에서는 쿡북 및 레시피에 대해 소개했습니다. 이 섹션의 예제는 설계상 간단했으며 OpsWorks Stacks 인스턴스를 포함하여 Chef를 지원하는 모든 인스턴스에서 작동합니다. Stacks에 보다 정교한 OpsWorks 쿡북을 구현하려면 일반적으로 여러 가지 면에서 표준 Chef와 다른 OpsWorks Stacks 환경을 최대한 활용해야 합니다.

이 주제에서는 OpsWorks Stacks 인스턴스용 레시피 구현의 기본 사항에 대해 설명합니다.

**참고**  
쿡북을 구현하는 방법을 잘 알지 못하는 경우 [쿡북 기본 사항](cookbooks-101-basics.md) 섹션부터 시작해야 합니다.

**Topics**
+ [OpsWorks Stacks Linux 인스턴스에서 레시피 실행](cookbooks-101-opsworks-opsworks-instance.md)
+ [Windows 인스턴스에서 레시피 실행](cookbooks-101-opsworks-opsworks-windows.md)
+ [Windows PowerShell 스크립트 실행](cookbooks-101-opsworks-opsworks-powershell.md)
+ [Vagrant에서 스택 구성 및 배포 속성 모의](opsworks-opsworks-mock.md)
+ [스택 구성 및 배포 속성 값 사용](cookbooks-101-opsworks-opsworks-stack-config.md)
+ [Linux 인스턴스에서 외부 쿡북 사용: Berkshelf](cookbooks-101-opsworks-berkshelf.md)
+ [SDK for Ruby 사용: Amazon S3에서 파일 다운로드](cookbooks-101-opsworks-s3.md)
+ [Windows 소프트웨어 설치](cookbooks-101-opsworks-install-software.md)
+ [내장 속성 재정의](cookbooks-101-opsworks-attributes.md)
+ [내장 템플릿 재정의](cookbooks-101-opsworks-templates.md)

# OpsWorks Stacks Linux 인스턴스에서 레시피 실행
<a name="cookbooks-101-opsworks-opsworks-instance"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

Test Kitchen과 Vagrant는 쿡북을 구현하는 간단하고 효율적인 방법을 제공하지만 쿡북의 레시피가 프로덕션 환경에서 올바르게 실행되는지 확인하려면 OpsWorks Stacks 인스턴스에서 실행해야 합니다. 이 주제에서는 OpsWorks Stacks Linux 인스턴스에 사용자 지정 쿡북을 설치하고 간단한 레시피를 실행하는 방법을 설명합니다. 또한 효율적으로 레시피 버그를 수정하기 위한 몇 가지 팁도 제공합니다.

Windows 인스턴스에서 레시피를 실행하는 방법에 대한 설명은 [Windows 인스턴스에서 레시피 실행](cookbooks-101-opsworks-opsworks-windows.md) 단원을 참조하세요.

**Topics**
+ [레시피 생성 및 실행](#opsworks-opsworks-instance-create)
+ [자동으로 레시피 실행](#cookbooks-101-opsworks-opsworks-instance-events)
+ [레시피 문제 해결 및 수정](#cookbooks-101-opsworks-opsworks-instance-bugs)

## 레시피 생성 및 실행
<a name="opsworks-opsworks-instance-create"></a>

먼저 스택을 생성해야 합니다. 다음은 이 예제를 위한 스택을 생성하는 방법을 간략히 요약한 것입니다. 자세한 내용은 [새 스택 생성](workingstacks-creating.md) 섹션을 참조하세요.

**스택 생성**

1. [OpsWorks Stacks 콘솔](https://console.aws.amazon.com/opsworks/)을 열고 **스택 추가**를 클릭합니다.

1. 다음 설정을 지정하고, 그 외 설정에 대해서는 기본값을 수락한 다음 [**스택 추가**]를 클릭합니다.
   + **이름** – OpsTest
   + **기본 SSH 키** – Amazon EC2 키 페어

   Amazon EC2 키 페어를 생성해야 하는 경우 [Amazon EC2 키 페어](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)를 참조하세요. 키 페어는 인스턴스와 동일한 AWS 리전에 속해야 합니다. 이 예에서는 기본 미국 서부(오레곤) 리전을 사용합니다.

1. [**계층 추가**]를 클릭하여 스택에 다음 설정으로 [사용자 지정 계층을 추가](workinglayers-custom.md)합니다.
   + **이름** – OpsTest
   + **짧은 이름** - opstest

   모든 계층 유형이 실제로 Linux 스택에서 작동하지만 이 예제에서는 다른 계층 유형에서 설치한 패키지가 필요하지 않기 때문에 사용자 지정 계층을 사용하는 것이 가장 간단합니다.

1. 기본 설정을 사용하여 계층에 [24/7 인스턴스를 추가](workinginstances-add.md)하고 [해당 인스턴스를 시작](workinginstances-starting.md)합니다.

인스턴스가 시작되는 동안(보통 몇 분 정도 소요됨) 쿡북을 생성할 수 있습니다. 이 예제에서는 [조건부 논리](cookbooks-101-basics-ruby.md#cookbooks-101-basics-ruby-conditional)을 약간 수정한 버전을 사용합니다. 이는 플랫폼에 따라 명명된 데이터 디렉터리를 생성합니다.

**쿡북을 설정하려면**

1. `opsworks_cookbooks` 안에 `opstest` 하위 디렉터리를 만들고 그 디렉터리로 이동합니다.

1. 다음 내용이 포함된 `metadata.rb` 파일을 만들어 `opstest`에 저장합니다.

   ```
   name "opstest"
   version "0.1.0"
   ```

1. `recipes` 안에 `opstest` 디렉터리를 만듭니다.

1. 다음 레시피가 포함된 `default.rb` 파일을 만들어 `recipes` 디렉터리에 저장합니다.

   ```
   Chef::Log.info("******Creating a data directory.******")
   
   data_dir = value_for_platform(
     "centos" => { "default" => "/srv/www/shared" },
     "ubuntu" => { "default" => "/srv/www/data" },
     "default" => "/srv/www/config"
   )
   
   directory data_dir do
     mode 0755
     owner 'root'
     group 'root'
     recursive true
     action :create
   end
   ```

   레시피는 메시지를 기록하지만 이 파일은 `Chef::Log.info`를 호출해 기록합니다. 이 예제에서는 Test Kitchen을 사용하지 않으므로 `log` 메서드가 그다지 유용하지 않습니다.는 Chef 실행이 완료된 후 읽을 수 있는 Chef 로그에 메시지를 `Chef::Log.info` 넣습니다. OpsWorks Stacks는 나중에 설명하듯이 이러한 로그를 쉽게 볼 수 있는 방법을 제공합니다.
**참고**  
Chef 로그에는 일반적으로 일상적이고 상대적으로 관심도가 떨어지는 정보가 많이 포함되어 있습니다. 메시지 텍스트를 묶고 있는 '\$1' 문자 덕분에 메시지를 쉽게 식별할 수 있습니다.

1. `.zip`의 `opsworks_cookbooks` 아카이브를 생성합니다. OpsWorks Stacks 인스턴스에 쿡북을 설치하려면 리포지토리에 쿡북을 저장하고 인스턴스에 쿡북을 다운로드하는 데 필요한 정보를 OpsWorks Stacks에 제공해야 합니다. 지원되는 여러 리포지토리 유형에 쿡북을 저장할 수 있습니다. 이 예제에서는 쿡북이 포함된 아카이브 파일을 Amazon S3 버킷에 저장합니다. 쿡북 리포지토리에 대한 자세한 정보는 [쿡북 리포지토리](workingcookbook-installingcustom-repo.md) 단원을 참조하세요.
**참고**  
간단한 설명을 위해 이 예제에서는 전체 `opsworks_cookbooks` 디렉터리를 보관합니다. 그러나 Stacks는 인스턴스에의 모든 OpsWorks 쿡북`opsworks_cookbooks`을 다운로드합니다. 단, 인스턴스 중 하나만 사용해야 합니다. 예제 쿡북만 설치하려면 다른 상위 디렉터리를 만들어 `opstest`를 해당 디렉터리로 이동합니다. 그런 다음 상위 디렉터리의 `.zip` 아카이브를 만들어 `opsworks_cookbooks.zip` 대신 사용합니다.  
Amazon S3 버킷에 전달한 콘텐츠에는 고객 콘텐츠가 포함될 수 있습니다. 중요 데이터 제거에 관한 자세한 내용은 [S3 버킷을 비우려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html) 단원 또는 [S3 버킷을 삭제하려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html) 단원을 참조하세요.

1. [아카이브를 Amazon S3 버킷에 업로드](https://docs.aws.amazon.com/AmazonS3/latest/UG/UploadingObjectsintoAmazonS3.html)하고, [해당 아카이브를 퍼블릭으로 설정](https://docs.aws.amazon.com/AmazonS3/latest/UG/EditingPermissionsonanObject.html)한 다음, 아카이브의 URL을 적어 둡니다.

이제 쿡북을 설치하고 레시피를 실행할 수 있습니다.

**레시피를 실행하려면**

1. [스택을 편집해 사용자 지정 쿡북을 활성화](workingcookbook-installingcustom-enable.md)하고 다음 설정을 지정합니다.
   + **리포지토리 유형** – **S3 아카이브**
   + **리포지토리 URL** - 앞에서 기록해 둔 쿡북 아카이브 URL

   기타 설정에 기본값을 사용하고 [**저장**]을 클릭하여 스택 구성을 업데이트합니다.

1. [사용자 지정 쿡북 업데이트 스택 명령을 실행](workingstacks-commands.md)하여 스택의 인스턴스에 사용자 지정 쿡북의 최신 버전을 설치합니다. 쿡북의 이전 버전이 있으면 이 명령이 이전 버전을 덮어 씁니다.

1. **실행할 레시피**가 **opstest::default**으로 설정된 상태에서 **레시피 실행** 스택 명령을 실행하여 레시피를 실행합니다. 이 명령은 `opstest::default`로 구성된 실행 목록을 사용하여 Chef 실행을 시작합니다.

레시피가 성공적으로 실행되면 이를 확인할 수 있습니다.

**opstest를 확인하려면**

1. 가장 먼저 [Chef 로그](troubleshoot-debug-log.md)를 확인합니다. opstest1 인스턴스의 **로그** 열에서 **표시**를 클릭하여 로그를 표시합니다. 아래로 스크롤하면 맨 아래 근처에 로그 메시지가 보입니다.

   ```
   ...
   [2014-07-31T17:01:45+00:00] INFO: Storing updated cookbooks/opsworks_cleanup/attributes/customize.rb in the cache.
   [2014-07-31T17:01:45+00:00] INFO: Storing updated cookbooks/opsworks_cleanup/metadata.rb in the cache.
   [2014-07-31T17:01:46+00:00] INFO: ******Creating a data directory.******
   [2014-07-31T17:01:46+00:00] INFO: Processing template[/etc/hosts] action create (opsworks_stack_state_sync::hosts line 3)
   ...
   ```

1. [SSH를 사용하여 인스턴스에 로그인](workinginstances-ssh.md)하고 `/srv/www/`의 내용을 표시합니다.

모든 단계를 수행했다면 예상했던 `/srv/www/shared` 디렉터리 대신 `/srv/www/config` 디렉터리가 보일 것입니다. 다음 섹션에서는 이러한 버그를 빠르게 수정하는 몇 가지 지침을 제공합니다.

## 자동으로 레시피 실행
<a name="cookbooks-101-opsworks-opsworks-instance-events"></a>

[**레시피 실행**] 명령은 사용자 지정 레시피를 테스트하는 편리한 방법입니다. 이 때문에 다음 예제의 대부분에서 이 명령이 사용됩니다. 그러나 실제로는 인스턴스 부팅이 완료된 후 또는 앱을 배포할 때와 같이 인스턴스 수명 주기의 표준 지점에서 레시피를 실행합니다. OpsWorks Stacks는 설정, 구성, 배포, 배포 취소 및 종료와 같은 각 계층에 대한 수명 [주기 이벤트](workingcookbook-events.md) 세트를 지원하여 인스턴스에서 레시피 실행을 간소화합니다. 레시피를 적절한 수명 주기 이벤트에 할당하여 OpsWorks Stacks가 계층의 인스턴스에서 레시피를 자동으로 실행하도록 할 수 있습니다.

일반적으로는 인스턴스가 부팅을 완료하는 대로 디렉터리를 생성하는데, 이는 설정 이벤트에 해당합니다. 다음 절차는 예제의 이전 단계에서 생성한 것과 동일한 스택을 사용하여 설정 시 예제 레시피를 실행하는 방법을 보여줍니다. 다른 이벤트에도 동일한 절차를 사용할 수 있습니다.

**설정 시 레시피를 자동으로 실행하려면**

1. 탐색 창에서 [**계층**]를 선택한 다음 OpsTest 계층의 [**레시피**] 링크 옆에 있는 연필 아이콘을 선택합니다.

1. **opstest::default**을 계층의 **설정** 레시피에 추가하고, **\$1**를 클릭하여 계층에 추가하고, **저장**을 선택하여 구성을 저장합니다.

1. [**인스턴스**]를 선택해 계층에 다른 인스턴스를 추가한 다음 시작합니다.

   이 인스턴스의 이름은 `opstest2`여야 합니다. 부팅이 완료되면 OpsWorks Stacks가를 실행합니다`opstest::default`.

1. `opstest2` 인스턴스가 온라인 상태가 되면 `/srv/www/shared`가 있는지 확인합니다.

**참고**  
설정, Configure 또는 Deploy 이벤트에 레시피를 할당한 경우 [스택 명령](workingstacks-commands.md)(설정 및 Configure) 또는 [배포 명령](workingapps-deploying.md)(Deploy)을 사용하여 이벤트를 트리거함으로써 수동으로 레시피를 실행할 수도 있습니다. 한 이벤트에 여러 레시피를 할당하면 이러한 명령은 모든 레시피를 실행합니다.

## 레시피 문제 해결 및 수정
<a name="cookbooks-101-opsworks-opsworks-instance-bugs"></a>

예상한 결과를 얻지 못하거나 레시피가 성공적으로 실행되지 않은 경우 일반적으로 Chef 로그를 검사하는 것으로 문제 해결이 시작됩니다. 로그에는 실행에 대한 상세한 설명과 레시피로부터의 모든 인라인 로그 메시지가 포함됩니다. 레시피가 그냥 실패한 경우 로그가 특히 유용합니다. 이러한 경우가 발생하면 Chef가 스택 트레이스를 포함하여 오류를 기록합니다.

이 예제에서와 같이 레시피가 성공한 경우에는 Chef 로그가 큰 도움이 안 됩니다. 그러면 레시피의 첫 몇 줄을 보다 면밀히 검토하여 문제를 파악할 수 있습니다.

```
Chef::Log.info("******Creating a data directory.******")

data_dir = value_for_platform(
  "centos" => { "default" => "/srv/www/shared" },
  "ubuntu" => { "default" => "/srv/www/data" },
  "default" => "/srv/www/config"
)
...
```

Vagrant에서 레시피를 테스트할 경우 CentOS가 Amazon Linux의 합리적 대역이지만, 지금은 실제 Amazon Linux 인스턴스가 실행 중입니다. Amazon Linux용 플랫폼 값은 `amazon`입니다. `value_for_platform` 호출에 이 값이 포함되지 않으므로 기본적으로 레시피가 `/srv/www/config`를 생성합니다. 문제 해결에 대한 자세한 정보는 [디버깅 및 문제 해결 안내서](troubleshoot.md) 단원을 참조하세요.

이제 문제를 식별했으므로 레시피를 업데이트하고 수정을 확인해야 합니다. 원래 소스 파일로 돌아가 `default.rb`를 업데이트하고, 새 아카이브를 Amazon S3로 업로드하는 등의 작업을 수행합니다. 하지만 이 프로세스는 약간 번거롭고 시간이 걸릴 수 있습니다. 다음은 인스턴스에서 레시피를 편집하는 방법으로, 예제 내 버그와 같은 간단한 레시피 버그를 수정하는 데 특히 유용한 훨씬 빠른 접근 방식입니다.

**인스턴스에서 레시피를 편집하려면**

1. SSH를 사용하여 인스턴스에 로그인한 다음 `sudo su`를 실행하여 권한을 승격시킵니다. 이 쿡북 디렉터리에 액세스하려면 루트 권한이 필요합니다.

1. OpsWorks Stacks는 쿡북을에 저장`/opt/aws/opsworks/current/site-cookbooks`하므로 로 이동합니다`/opt/aws/opsworks/current/site-cookbooks/opstest/recipes`.
**참고**  
OpsWorks 또한 Stacks는 쿡북의 사본을에 저장합니다`/opt/aws/opsworks/current/merged-cookbooks`. 이러한 쿡북은 편집하지 마십시오. 레시피를 실행하면 OpsWorks Stacks가 쿡북을에서 `.../site-cookbooks`로 복사하므로 `.../merged-cookbooks`에서 변경한 내용을 `.../merged-cookbooks` 덮어씁니다.

1. 인스턴스에서 텍스트 편집기를 사용하여 `default.rb`를 편집하고 `centos`는 `amazon`으로 바꿉니다. 이제 레시피가 다음과 같이 보여야 합니다.

   ```
   Chef::Log.info("******Creating a data directory.******")
   
   data_dir = value_for_platform(
     "amazon" => { "default" => "/srv/www/shared" },
     "ubuntu" => { "default" => "/srv/www/data" },
     "default" => "/srv/www/config"
   )
   ...
   ```

수정을 확인하려면 **레시피 실행** 스택 명령을 다시 실행하여 레시피를 실행합니다. 이제 인스턴스에 `/srv/www/shared` 디렉터리가 있을 것입니다. 추가로 레시피를 수정해야 할 경우 [**레시피 실행**]을 원하는 만큼 실행할 수 있으며, 명령을 실행할 때마다 인스턴스를 중지했다 재시작할 필요가 없습니다. 레시피가 올바로 작동하는 것으로 판단되면 소스 쿡북에서 코드를 업데이트할 필요가 없습니다.

**참고**  
 OpsWorks Stacks가 자동으로 실행하도록 레시피를 수명 주기 이벤트에 할당한 경우 언제든지 **레시피 실행**을 사용하여 레시피를 다시 실행할 수 있습니다. 또한 OpsWorks Stacks 콘솔을 사용하여 적절한 이벤트를 수동으로 트리거하여 인스턴스를 다시 시작하지 않고도 레시피를 원하는 횟수만큼 다시 실행할 수 있습니다. 하지만 이 방법에서는 이벤트의 레시피가 모두 실행됩니다. 다음을 기억하세요.  
설정 또는 Configure 이벤트를 트리거하려면 [스택 명령](workingstacks-commands.md)을 사용합니다.
Deploy 또는 Undeploy 이벤트를 트리거하려면 [배포 명령](workingapps-deploying.md)을 사용합니다.

# Windows 인스턴스에서 레시피 실행
<a name="cookbooks-101-opsworks-opsworks-windows"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

이 주제는 기본적으로 [Linux 인스턴스에서 레시피 실행](cookbooks-101-opsworks-opsworks-instance.md) 섹션의 요약 버전으로, Windows 스택에서 레시피를 실행하는 방법을 보여줍니다. 두 운영 체제 모두와 관련이 있는 내용이 보다 자세히 설명되어 있으므로 먼저 [Linux 인스턴스에서 레시피 실행](cookbooks-101-opsworks-opsworks-instance.md) 섹션을 읽는 것이 좋습니다.

 OpsWorks Stacks Linux 인스턴스에서 레시피를 실행하는 방법에 대한 설명은 섹션을 참조하세요[Linux 인스턴스에서 레시피 실행](cookbooks-101-opsworks-opsworks-instance.md).

**Topics**
+ [RDP 액세스 활성화](#cookbooks-101-opsworks-opsworks-windows-rdp)
+ [레시피 생성 및 실행](#cookbooks-101-opsworks-opsworks-windows-run-recipe)
+ [자동으로 레시피 실행](#cookbooks-101-opsworks-opsworks-windows-event)

## RDP 액세스 활성화
<a name="cookbooks-101-opsworks-opsworks-windows-rdp"></a>

시작하기 전에 인스턴스에 대해 RDP 액세스를 허용하는 인바운드 규칙을 포함하는 보안 그룹을 설정해야 합니다. 스택을 생성할 때 이 그룹이 필요합니다.

리전에서 첫 번째 스택을 생성하면 OpsWorks Stacks가 보안 그룹 세트를 생성합니다. 여기에는과 같은 이름의 인스턴스가 포함되며`AWS-OpsWorks-RDP-Server`, OpsWorks Stacks는 모든 Windows 인스턴스에 연결하여 RDP 액세스를 허용합니다. 하지만 이 보안 그룹은 기본적으로 아무 규칙도 포함하고 있지 않으므로, 인스턴스에 RDP 액세스를 허용하는 인바운드 규칙을 추가해야 합니다.

**RDP 액세스를 허용하려면**

1. [Amazon EC2 콘솔](https://console.aws.amazon.com/ec2/v2/)을 열고, 콘솔을 스택의 리전으로 설정한 다음, 탐색 창에서 **보안 그룹**을 선택합니다.

1. [**AWS-OpsWorks-RDP-Server**], [**인바운드**] 탭, [**편집**]을 차례대로 선택합니다.

1. 다음 설정으로 규칙을 추가합니다.
   + **유형** – **RDP**
   + **소스** – 허용 가능한 소스 IP 주소.

     일반적으로 IP 주소 또는 지정된 IP 주소 범위(대개 회사 IP 주소)에서 들어오는 인바운드 RDP 요청을 허용합니다.

**참고**  
또한 나중에 설명하듯이 사용자 권한을 편집해 일반 사용자에게 RDP 액세스를 허용해야 합니다.

자세한 내용은 [RDP를 사용하여 로그인](workinginstances-rdp.md) 섹션을 참조하세요.

## 레시피 생성 및 실행
<a name="cookbooks-101-opsworks-opsworks-windows-run-recipe"></a>

다음은 이 예제를 위한 스택을 생성하는 방법을 간략히 요약한 것입니다. 자세한 내용은 [새 스택 생성](workingstacks-creating.md) 섹션을 참조하세요.

**스택을 만듭니다**

1. [OpsWorks Stacks 콘솔](https://console.aws.amazon.com/opsworks/)을 열고 **스택 추가**를 선택합니다. 다음 설정을 지정하고, 그 외 설정에 대해서는 기본값을 수락한 다음 [**스택 추가**]를 선택합니다.
   + **이름** – WindowsRecipeTest
   + **리전** – 미국 서부(오레곤)

     이 예제는 모든 리전에서 작동하지만 자습서의 경우 미국 서부(오레곤)를 사용하는 것이 좋습니다.
   + **기본 운영 체제** - Microsoft Windows Server 2012 R2

1. [**계층 추가**]를 선택하여 스택에 다음 설정으로 [사용자 지정 계층을 추가](workinglayers-custom.md)합니다.
   + **이름** – RecipeTest
   + **짧은 이름** - recipetest

1. 기본 설정을 사용하여 RecipeTest 계층에 [24/7 인스턴스를 추가](workinginstances-add.md)하고 [해당 인스턴스를 시작](workinginstances-starting.md)합니다.

   OpsWorks Stacks는이 인스턴스`AWS-OpsWorks-RDP-Server`에를 자동으로 할당하므로 권한 있는 사용자가 인스턴스에 로그인할 수 있습니다.

1. [**권한**] 및 [**편집**]을 차례대로 선택하고 [**SSH/RDP**] 및 [**sudo/admin**]을 선택합니다. 인스턴스에 로그인하려면 일반 사용자에게는 `AWS-OpsWorks-RDP-Server` 보안 그룹 이외에 이러한 권한 부여가 필요합니다.
**참고**  
Administrator로도 로그인할 수 있지만 로그인 절차가 다릅니다. 자세한 내용은 [RDP를 사용하여 로그인](workinginstances-rdp.md) 섹션을 참조하세요.

인스턴스가 시작되는 동안(보통 몇 분 정도 소요됨) 쿡북을 생성할 수 있습니다. 이 예제의 레시피는 데이터 디렉터리를 생성하며, 기본적으로 [예제 3: 디렉터리 생성](cookbooks-101-basics-directories.md)의 레시피를 Windows용으로 수정한 것입니다.

**참고**  
Stacks Windows 인스턴스용 OpsWorks 쿡북을 구현할 때는 Stacks Linux 인스턴스용 OpsWorks 쿡북을 구현할 때와 약간 다른 디렉터리 구조를 사용합니다. 자세한 내용은 [쿡북 리포지토리](workingcookbook-installingcustom-repo.md) 단원을 참조하십시오.

**쿡북을 설정하려면**

1. `windowstest` 하위 디렉터리를 만들고 그 디렉터리로 이동합니다.

1. 다음 내용이 포함된 `metadata.rb` 파일을 만들어 `windowstest`에 저장합니다.

   ```
   name "windowstest"
   version "0.1.0"
   ```

1. `recipes` 안에 `windowstest` 디렉터리를 만듭니다.

1. 다음 레시피가 포함된 `default.rb` 파일을 만들어 `recipes` 디렉터리에 저장합니다.

   ```
   Chef::Log.info("******Creating a data directory.******")
   
   directory 'C:\data' do
     rights :full_control, 'instance_name\username'
     inherits false
     action :create
   end
   ```

   *username*을 사용자 이름으로 바꿉니다.

1. 쿡북을 리포지토리에 저장합니다.

   Stacks 인스턴스에 OpsWorks 쿡북을 설치하려면 리포지토리에 쿡북을 저장하고 인스턴스에 쿡북을 다운로드하는 데 필요한 정보를 OpsWorks Stacks에 제공해야 합니다. S3 버킷 또는 Git 리포지토리에 Windows 쿡북을 아카이브 파일로 저장할 수 있습니다. 이 예제에서는 S3 버킷을 사용하므로 `windowstest` 디렉터리의 .zip 아카이브를 생성해야 합니다. 쿡북 리포지토리에 대한 자세한 정보는 [쿡북 리포지토리](workingcookbook-installingcustom-repo.md) 단원을 참조하세요.

1. [아카이브를 S3 버킷에 업로드](https://docs.aws.amazon.com/AmazonS3/latest/UG/UploadingObjectsintoAmazonS3.html)하고, [해당 아카이브를 퍼블릭으로 설정](https://docs.aws.amazon.com/AmazonS3/latest/UG/EditingPermissionsonanObject.html)한 다음, 아카이브의 URL을 적어 둡니다. 또한 프라이빗 아카이브를 사용할 수도 있지만 이 예제에는 퍼블릭 아카이브면 충분합니다. 퍼블릭 아카이브가 작업하기 더 간단합니다.

   Amazon S3 버킷에 전달한 콘텐츠에는 고객 콘텐츠가 포함될 수 있습니다. 중요 데이터 제거에 관한 자세한 내용은 [S3 버킷을 비우려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html) 단원 또는 [S3 버킷을 삭제하려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html) 단원을 참조하세요.

이제 쿡북을 설치하고 레시피를 실행할 수 있습니다.

**레시피를 실행하려면**

1. [스택을 편집해 사용자 지정 쿡북을 활성화](workingcookbook-installingcustom-enable.md)하고 다음 설정을 지정합니다.
   + **리포지토리 유형** – **S3 아카이브**
   + **리포지토리 URL** - 앞에서 기록해 둔 쿡북 아카이브 URL

   기타 설정에 대해 기본값을 수락하고 [**저장**]을 선택하여 스택 구성을 업데이트합니다.

1. [사용자 지정 쿡북 업데이트 스택 명령을 실행](workingstacks-commands.md)하여 스택의 인스턴스(온라인 인스턴스 포함)에 사용자 지정 쿡북의 최신 버전을 설치합니다. 쿡북의 이전 버전이 있으면 이 명령이 이전 버전을 덮어 씁니다.

1. 사용자 지정 쿡북 업데이트가 완료되면 **실행할 레시피**가 **windowstest::default**로 설정된 상태에서 [**레시피 실행** 스택 명령](workingstacks-commands.md)을 실행하여 레시피를 실행합니다. 이 명령은 레시피로 구성된 실행 목록을 사용하여 Chef 실행을 시작합니다.

레시피가 성공적으로 실행되면 이를 확인할 수 있습니다.

**windowstest를 확인하려면**

1. [Chef 로그](troubleshoot-debug-log.md)를 확인합니다. opstest1 인스턴스의 **로그** 열에서 **표시**를 선택하여 로그를 표시합니다. 아래로 스크롤하면 맨 아래 근처에 로그 메시지가 보입니다.

   ```
   ...
   [2014-07-31T17:01:45+00:00] INFO: Storing updated cookbooks/opsworks_cleanup/attributes/customize.rb in the cache.
   [2014-07-31T17:01:45+00:00] INFO: Storing updated cookbooks/opsworks_cleanup/metadata.rb in the cache.
   [2014-07-31T17:01:46+00:00] INFO: ******Creating a data directory.******
   [2014-07-31T17:01:46+00:00] INFO: Processing template[/etc/hosts] action create (opsworks_stack_state_sync::hosts line 3)
   ...
   ```

1. **인스턴스**를 선택하고, 인스턴스의 **작업** 열에서 **rdp**를 선택한 다음 적절한 만료 시간을 가진 RDP 비밀번호를 요청합니다. DNS 이름, 사용자 이름 및 암호를 복사합니다. 그런 다음 RDP 클라이언트(예: Windows 원격 데스크톱 연결 클라이언트)에서 해당 정보를 사용해 인스턴스에 로그인하고 `c:\data`가 있는지 확인합니다. 자세한 내용은 [RDP를 사용하여 로그인](workinginstances-rdp.md) 섹션을 참조하세요.

**참고**  
레시피가 올바로 작동하지 않는다면 문제 해결 팁은 [레시피 문제 해결 및 수정](cookbooks-101-opsworks-opsworks-instance.md#cookbooks-101-opsworks-opsworks-instance-bugs) 단원을 참조하세요. Windows 인스턴스에도 대부분 적용됩니다. 인스턴스에서 레시피를 편집하여 수정 사항을 테스트하려면 `C:\chef\cookbooks` 디렉터리에서 쿡북을 찾습니다. 여기서 OpsWorks Stacks는 사용자 지정 쿡북을 설치합니다.

## 자동으로 레시피 실행
<a name="cookbooks-101-opsworks-opsworks-windows-event"></a>

[**레시피 실행**] 명령은 사용자 지정 레시피를 테스트하는 편리한 방법입니다. 이 때문에 다음 예제의 대부분에서 이 명령이 사용됩니다. 그러나 실제로는 인스턴스 부팅이 완료된 후 또는 앱을 배포할 때와 같이 인스턴스 수명 주기의 표준 지점에서 레시피를 실행합니다. OpsWorks Stacks는 설정, 구성, 배포, 배포 취소 및 종료와 같은 각 계층에 대한 [수명 주기 이벤트](workingcookbook-events.md) 세트를 지원하여 인스턴스에서 레시피 실행을 간소화합니다. 레시피를 적절한 수명 주기 이벤트에 할당하여 OpsWorks Stacks가 계층의 인스턴스에서 레시피를 자동으로 실행하도록 할 수 있습니다.

일반적으로는 인스턴스가 부팅을 완료하는 대로 디렉터리를 생성하는데, 이는 설정 이벤트에 해당합니다. 다음 절차는 예제의 이전 단계에서 생성한 것과 동일한 스택을 사용하여 설정 시 예제 레시피를 실행하는 방법을 보여줍니다. 다른 이벤트에도 동일한 절차를 사용할 수 있습니다.

**설정 시 레시피를 자동으로 실행하려면**

1. 탐색 창에서 [**계층**]를 선택한 다음 RecipeTest 계층의 [**레시피**] 링크 옆에 있는 연필 아이콘을 선택합니다.

1. **windowstest::default**을 계층의 **설정** 레시피에 추가하고, **\$1**를 선택하여 계층에 추가하고, **저장**을 선택하여 구성을 저장합니다.

1. [**인스턴스**]를 선택해 계층에 다른 인스턴스를 추가한 다음 시작합니다.

   이 인스턴스의 이름은 `recipetest2`여야 합니다. 부팅이 완료되면 OpsWorks Stacks가를 실행합니다`windowstest::default`.

1. `recipetest2` 인스턴스가 온라인 상태가 되면 `c:\data`가 있는지 확인합니다.

**참고**  
설정, Configure 또는 Deploy 이벤트에 레시피를 할당한 경우 [스택 명령](workingstacks-commands.md)(설정 및 Configure) 또는 [배포 명령](workingapps-deploying.md)(Deploy)을 사용하여 이벤트를 트리거함으로써 수동으로 레시피를 실행할 수도 있습니다. 한 이벤트에 여러 레시피를 할당하면 이러한 명령은 모든 레시피를 실행합니다.

# Windows PowerShell 스크립트 실행
<a name="cookbooks-101-opsworks-opsworks-powershell"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
다음 예제에서는 사용자가 이미 [Windows 인스턴스에서 레시피 실행](cookbooks-101-opsworks-opsworks-windows.md) 예제를 완료한 것으로 가정합니다. 그렇지 않은 경우 먼저 그 예제를 수행해야 합니다. 특히, 그 예제는 인스턴스에 대한 [RDP 액세스](cookbooks-101-opsworks-opsworks-windows.md#cookbooks-101-opsworks-opsworks-windows-rdp)를 활성화하는 방법을 설명합니다.

레시피가 Windows 인스턴스에서 작업, 특히 해당 Chef 리소스가 없는 작업을 수행하도록 하는 한 가지 방법은 레시피에서 Windows PowerShell 스크립트를 실행하도록 하는 것입니다. 이 섹션에서는 Windows PowerShell 스크립트를 사용하여 Windows 기능을 설치하는 방법을 설명하면서 기본 사항을 소개합니다.

[https://docs.chef.io/chef/resources.html#powershell-script](https://docs.chef.io/chef/resources.html#powershell-script) 리소스는 인스턴스에서 Windows PowerShell cmdlet을 실행합니다. 다음 예제는 [Install-WindowsFeature cmdlet](https://technet.microsoft.com/en-us/library/hh849795.aspx)을 사용하여 인스턴스에 XPS 뷰어를 설치합니다.

다음은 이 예제를 위한 스택을 생성하는 방법을 간략히 요약한 것입니다. 자세한 내용은 [새 스택 생성](workingstacks-creating.md) 섹션을 참조하세요.

**스택을 만듭니다**

1. [OpsWorks Stacks 콘솔](https://console.aws.amazon.com/opsworks/)을 열고 **스택 추가**를 선택합니다. 다음 설정을 지정하고, 그 외 설정에 대해서는 기본값을 수락한 다음 [**스택 추가**]를 클릭합니다.
   + **이름** – PowerShellTest
   + **리전** – 미국 서부(오레곤)

     이 예제는 모든 리전에서 작동하지만 자습서의 경우 미국 서부(오레곤)를 사용하는 것이 좋습니다.
   + **기본 운영 체제** - Microsoft Windows Server 2012 R2

1. [**계층 추가**]를 선택하여 스택에 다음 설정으로 [사용자 지정 계층을 추가](workinglayers-custom.md)합니다.
   + **이름** – PowerShell
   + **짧은 이름** - powershell

1. 기본 설정을 사용하여 PowerShell 계층에 [24/7 인스턴스를 추가](workinginstances-add.md)하고 [해당 인스턴스를 시작](workinginstances-starting.md)합니다.

1. [**권한**] 및 [**편집**]을 차례대로 선택하고 [**SSH/RDP**] 및 [**sudo/admin**]을 선택합니다. 인스턴스에 일반 사용자로 로그인하려면 `AWS-OpsWorks-RDP-Server` 보안 그룹 이외에 이러한 권한 부여가 필요합니다.

인스턴스가 시작되는 동안(보통 몇 분 정도 소요됨) 쿡북을 생성할 수 있습니다. 이 예제의 레시피는 데이터 디렉터리를 생성하며, 기본적으로 [예제 3: 디렉터리 생성](cookbooks-101-basics-directories.md)의 레시피를 Windows용으로 수정한 것입니다.

**쿡북을 설정하려면**

1. `powershell` 하위 디렉터리를 만들고 그 디렉터리로 이동합니다.

1. 다음 내용이 포함된 `metadata.rb` 파일을 만들어 `windowstest`에 저장합니다.

   ```
   name "powershell"
   version "0.1.0"
   ```

1. `recipes` 디렉터리 내에 `powershell` 디렉터리를 만듭니다.

1. 다음 레시피가 포함된 `default.rb` 파일을 만들어 `recipes` 디렉터리에 저장합니다.

   ```
   Chef::Log.info("******Installing XPS.******")
   
   powershell_script "Install XPS Viewer" do
     code <<-EOH
       Install-WindowsFeature XPS-Viewer
     EOH
     guard_interpreter :powershell_script
     not_if "(Get-WindowsFeature -Name XPS-Viewer).installed"
   end
   ```
   + `powershell_script` 리소스가 cmdlet을 실행해 XPS 뷰어를 설치합니다.

     이 예제에서는 cmdlet을 하나만 실행하지만 `code` 블록에는 명령줄을 무제한 포함할 수 있습니다.
   + `guard_interpreter` 속성은 Chef에 Windows PowerShell의 64비트 버전을 사용하도록 지시합니다.
   + `not_if` 보호 속성은 Chef가 이미 설치된 기능을 설치하지 않도록 합니다.

1. `powershell` 디렉터리의 `.zip` 아카이브를 생성합니다.

1. [아카이브를 Amazon S3 버킷에 업로드](https://docs.aws.amazon.com/AmazonS3/latest/UG/UploadingObjectsintoAmazonS3.html)하고, [해당 아카이브를 퍼블릭으로 설정](https://docs.aws.amazon.com/AmazonS3/latest/UG/EditingPermissionsonanObject.html)한 다음, 아카이브의 URL을 적어 둡니다. 또한 프라이빗 아카이브를 사용할 수도 있지만 이 예제에는 퍼블릭 아카이브면 충분합니다. 퍼블릭 아카이브가 작업하기 더 간단합니다.

   Amazon S3 버킷에 전달한 콘텐츠에는 고객 콘텐츠가 포함될 수 있습니다. 중요 데이터 제거에 관한 자세한 내용은 [S3 버킷을 비우려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html) 단원 또는 [S3 버킷을 삭제하려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html) 단원을 참조하세요.

이제 쿡북을 설치하고 레시피를 실행할 수 있습니다.

**레시피를 실행하려면**

1. [스택을 편집해 사용자 지정 쿡북을 활성화](workingcookbook-installingcustom-enable.md)하고 다음 설정을 지정합니다.
   + **리포지토리 유형** – **S3 아카이브**
   + **리포지토리 URL** - 앞에서 기록해 둔 쿡북 아카이브 URL

   기타 설정에 대해 기본값을 수락하고 [**저장**]을 선택하여 스택 구성을 업데이트합니다.

1. [[**사용자 지정 쿡북 업데이트**] 스택 명령을 실행](workingstacks-commands.md)하여 인스턴스에 사용자 지정 쿡북의 최신 버전을 설치합니다.

1. **사용자 지정 쿡북 업데이트**가 완료되면 **실행할 레시피**가 **powershell::default**로 설정된 상태에서 [**레시피 실행** 스택 명령](workingstacks-commands.md)을 실행하여 레시피를 실행합니다. 

**참고**  
이 예제에서는 편의상 **레시피 실행**을 사용하지만 일반적으로 OpsWorks Stacks가 레시피를 적절한 수명 주기 이벤트에 할당하여 [레시피를 자동으로 실행](workingcookbook-assigningcustom.md)하도록 합니다. 수동으로 이벤트를 트리거하여 그러한 레시피를 실행할 수 있습니다. 스택 명령을 사용하여 설정 및 Configure 이벤트를 트리거할 수 있고, [배포 명령](workingapps-deploying.md)을 사용하여 Deploy 및 Undeploy 이벤트를 트리거할 수 있습니다.

레시피가 성공적으로 실행되면 이를 확인할 수 있습니다.

**powershell 레시피를 확인하려면**

1. [Chef 로그](troubleshoot-debug-log.md)를 확인합니다. powershell1 인스턴스의 **로그** 열에서 **표시**를 클릭하여 로그를 표시합니다. 아래로 스크롤하면 맨 아래 근처에 로그 메시지가 보입니다.

   ```
   ...
   [2015-04-27T18:12:09+00:00] INFO: Storing updated cookbooks/powershell/metadata.rb in the cache.
   [2015-04-27T18:12:09+00:00] INFO: ******Installing XPS.******
   [2015-04-27T18:12:09+00:00] INFO: Processing powershell_script[Install XPS Viewer] action run (powershell::default line 3)
   [2015-04-27T18:12:09+00:00] INFO: Processing powershell_script[Guard resource] action run (dynamically defined)
   [2015-04-27T18:12:42+00:00] INFO: powershell_script[Install XPS Viewer] ran successfully 
   ...
   ```

1. [RDP를 사용하여 인스턴스에 로그인](workinginstances-rdp.md)하고 [**시작**] 메뉴를 엽니다. XPS 뷰어가 [**Windows 액세서리**]와 함께 나열되어야 합니다.

# Vagrant에서 스택 구성 및 배포 속성 모의
<a name="opsworks-opsworks-mock"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이 주제는 Linux 인스턴스에만 적용됩니다. Test Kitchen은 아직 Windows를 지원하지 않으므로 OpsWorks Stacks 인스턴스에서 모든 Windows 예제를 실행합니다.

OpsWorks Stacks는 모든 수명 주기 이벤트에 대해 [스택의 각 인스턴스에 대한 노드 객체에 스택 구성 및 배포 속성을](workingcookbook-json.md) 추가합니다. 이러한 속성은 스택 구성의 스냅샷을 제공합니다. 여기에는 각 계층 및 해당 온라인 인스턴스의 구성, 배포된 각 앱의 구성 등이 포함됩니다. 이러한 속성은 노드 객체에 있으므로 모든 레시피에서 액세스할 수 있습니다. OpsWorks 대부분의 Stacks 인스턴스용 레시피는 이러한 속성 중 하나 이상을 사용합니다.

Vagrant 상자에서 실행되는 인스턴스는 OpsWorks Stacks에서 관리하지 않으므로 노드 객체에는 기본적으로 스택 구성 및 배포 속성이 포함되지 않습니다. 하지만 Test Kitchen 환경에 적절한 속성 세트를 추가할 수 있습니다. 그런 다음 Test Kitchen은 인스턴스의 노드 객체에 속성을 추가하고 레시피는 OpsWorks Stacks 인스턴스에서와 마찬가지로 속성에 액세스할 수 있습니다.

이 주제는 적합한 스택 구성 및 배포 속성의 사본을 구하고, 인스턴스에 속성을 설치하고, 속성에 액세스하는 방법을 설명합니다.

**참고**  
Test Kitchen을 사용하여 레시피를 테스트하려는 경우, [fauxhai](https://github.com/customink/fauxhai)가 스택 구성 및 배포 JSON을 모의하는 대체 방법을 제공합니다.

**쿡북을 설정하려면**

1. `printjson`의 하위 디렉터리 `opsworks_cookbooks`를 만들고 그 디렉터리로 이동합니다.

1. [예제 1: 패키지 설치](cookbooks-101-basics-packages.md) 단원에서 설명하는 대로 Test Kitchen을 초기화 및 구성합니다.

1. `printjson`에 하위 디렉터리 `recipes` 및 `environments`를 추가합니다.

적절한 정의를 포함하는 속성 파일을 쿡북에 추가하여 스택 구성 및 배포 속성을 모의할 수도 있지만, Test Kitchen 환경을 사용하는 것이 더 나은 접근 방식입니다. 기본적으로 두 가지 방법이 있습니다.
+ `.kitchen.yml`에 속성 정의를 추가합니다.

  이 방법은 속성이 몇 개 정도일 경우 매우 유용합니다. 자세한 정보는 [kitchen.yml](https://docs.chef.io/config_yml_kitchen.html) 단원을 참조하세요.
+ 환경 파일에서 속성을 정의하고 `.kitchen.yml`에서 파일 단원을 참조합니다.

  이 방법은 환경 파일이 이미 JSON 형식이므로 일반적으로 스택 구성 및 배포 속성에 대해 선호됩니다. 적절한 Stacks 인스턴스에서 JSON 형식의 속성 사본을 가져와 붙여넣기만 OpsWorks 하면 됩니다. 다음 예제는 모두 환경 파일을 사용합니다.

쿡북에서 스택 구성 및 배포 속성을 생성하는 가장 간단한 방법은 적절히 구성된 스택을 생성하고 인스턴스에서 결과 속성을 JSON으로 복사하는 것입니다. Test Kitchen 환경 파일을 관리 가능하게 유지하기 위해 레시피에 필요한 속성만 포함하도록 JSON을 편집할 수 있습니다. 이 장에서 설명하는 예제는 [Chef 11 Linux 스택 시작하기](gettingstarted.md)의 스택을 기반으로 합니다. 이 스택은 로드 밸런서, PHP 애플리케이션 서버 및 MySQL 데이터베이스 서버를 포함하는 PHP 애플리케이션 서버 스택입니다.

**스택 구성 및 배포 JSON을 생성하려면**

1. SimplePHPApp 배포를 비롯하여 [Chef 11 Linux 스택 시작하기](gettingstarted.md) 단원에서 설명하는 대로 MyStack을 생성합니다. 원하는 경우 [4단계: MyStack 확장](gettingstarted-scale.md) 단원에서 호출한 두 번째 PHP 앱 서버 인스턴스를 생략할 수 있습니다. 이 예제에서는 이러한 속성을 사용하지 않기 때문입니다.

1. 아직 수행하지 않은 경우 `php-app1` 인스턴스를 시작한 다음 [SSH로 로그인](workinginstances-ssh.md)합니다.

1. 터미널 창에서 다음 [agent cli](agent.md) 명령을 실행합니다.

   ```
   sudo opsworks-agent-cli get_json
   ```

   이 명령은 인스턴스의 최신 스택 구성 및 배포 속성을 JSON 형식으로 터미널 창에 인쇄합니다.

1. JSON을 `.json` 파일에 복사하고 워크스테이션의 원하는 위치에 저장합니다. 세부 정보는 SSH 클라이언트에 따라 달라집니다. 예를 들어, Windows에서 PuTTY를 사용하는 경우 터미널 창의 모든 텍스트를 Windows 클립보드에 복사하는 `Copy All to Clipboard` 명령을 실행할 수 있습니다. 그런 다음 해당 내용을 `.json` 파일에 붙여 넣고 이 파일을 편집해 관련 없는 텍스트를 제거합니다.

1. 필요에 따라 MyStack JSON을 편집합니다. 스택 구성 및 배포 속성은 수 없이 많지만 일반적으로 쿡북에서는 이 중 극히 일부만 사용합니다. 환경 파일을 관리하기 쉽게 유지하려면 원래 구조를 유지하되 쿡북에서 실제 사용하는 속성만 포함하도록 JSON을 편집할 수 있습니다.

   이 예제에서는 `['opsworks']['stack']` 속성 두 개, 즉 `['id]` 및 `['name']`만 포함하도록 크게 편집한 MyStack JSON 버전을 사용합니다. 다음과 유사한 MyStack JSON의 편집 버전을 생성합니다.

   ```
   {
     "opsworks": {
       "stack": {
         "name": "MyStack",
         "id": "42dfd151-6766-4f1c-9940-ba79e5220b58",
       },
     },
   }
   ```

이 JSON을 인스턴스의 노드 객체로 가져오려면 Test Kitchen 환경에 추가해야 합니다.

**Test Kitchen 환경에 스택 구성 및 배포 속성을 추가하려면**

1. 다음 내용이 포함된 환경 파일 `test.json`을 만들어 이 파일을 쿡북의 `environments` 폴더에 저장합니다.

   ```
   {
     "default_attributes": {
       "opsworks" : {
         "stack" : {
           "name" : "MyStack",
           "id" : "42dfd151-6766-4f1c-9940-ba79e5220b58"
         }
       }
     },
     "chef_type" : "environment",
     "json_class" : "Chef::Environment"
   }
   ```

   환경 파일에는 다음 요소가 포함되어 있습니다.
   + `default_attributes` – JSON 형식의 기본 속성.

     이러한 속성은 속성 유형이 `default`인 노드 객체에 추가되는데, 이 속성 유형은 모든 스택 구성 및 배포 JSON 속성에서 사용합니다. 이 예제에서는 앞서 표시된 스택 구성 및 배포 JSON의 편집 버전을 사용합니다.
   + `chef_type` - 이 요소는 `environment`로 설정합니다.
   + `json_class` - 이 요소는 `Chef::Environment`로 설정합니다.

1. `.kitchen.yml`을 편집하여 Test Kitchen 환경을 다음과 같이 정의합니다.

   ```
   ---
   driver:
     name: vagrant
   
   provisioner:
     name: chef_solo
     environments_path: ./environments
   
   platforms:
     - name: ubuntu-12.04
   
   suites:
     - name: printjson 
       provisioner:
         solo_rb:
           environment: test
       run_list:
         - recipe[printjson::default]
       attributes:
   ```

   `kitchen init`이 생성한 기본 `.kitchen.yml`에 다음 요소를 추가하여 환경을 정의합니다.  
**provisioner**  
다음 요소를 추가합니다.  
   + `name` - 이 요소는 `chef_solo`로 설정합니다.

      OpsWorks Stacks 환경을 더 가깝게 복제하려면 [Chef 솔로 대신 Chef 클라이언트 로컬 모드를](https://docs.chef.io/ctl_chef_client.html) 사용할 수 있습니다. 로컬 모드는 원격 서버 대신 인스턴스에서 로컬로 실행되는 Chef 서버의 경량 버전(Chef Zero)을 사용하는 Chef 클라이언트 옵션입니다. 로컬 모드에서는 레시피가 원격 서버에 연결하지 않고 검색 또는 데이터 백과 같은 Chef 서버 기능을 사용할 수 있습니다.
   + `environments_path` - 환경 파일(이 예제의 경우 `./environments`)을 포함하는 쿡북 하위 디렉터리  
**suites:provisioner**  
환경 파일의 이름(.json 확장명 제외)으로 설정된 `environment` 요소와 함께 `solo_rb` 요소를 추가합니다. 이 예제에서는 `environment`를 `test`로 설정합니다.

1. 다음 내용이 포함된 레시피 파일 `default.rb`를 만들어 이 파일을 쿡북의 `recipes` 디렉터리에 저장합니다.

   ```
   log "Stack name: #{node['opsworks']['stack']['name']}"
   log "Stack id: #{node['opsworks']['stack']['id']}"
   ```

   이 레시피는 환경에 추가한 스택 구성 및 배포 값 2개를 기록하기만 합니다. 레시피가 가상 상자에서 로컬로 실행되지만 레시피가 OpsWorks Stacks 인스턴스에서 실행 중일 때와 동일한 노드 구문을 사용하여 이러한 속성을 참조합니다.

1. `kitchen converge`를 실행합니다. 다음 로그 출력과 유사해야 합니다.

   ```
   ...
   Converging 2 resources       
   Recipe: printjson::default       
     * log[Stack name: MyStack] action write[2014-07-01T23:14:09+00:00] INFO: Processing log[Stack name: MyStack] action write (printjson::default line 1)       
   [2014-07-01T23:14:09+00:00] INFO: Stack name: MyStack       
                
     * log[Stack id: 42dfd151-6766-4f1c-9940-ba79e5220b58] action write[2014-07-01T23:14:09+00:00] INFO: Processing log[Stack id: 42dfd151-6766-4f1c-9940-ba79e5220b58] action write (printjson::default line 2)       
   [2014-07-01T23:14:09+00:00] INFO: Stack id: 42dfd151-6766-4f1c-9940-ba79e5220b58       
   ...
   ```

# 스택 구성 및 배포 속성 값 사용
<a name="cookbooks-101-opsworks-opsworks-stack-config"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

레시피는 스택 구성 또는 배포된 앱에 대한 정보를 자주 필요로 합니다. 예를 들어 구성 파일을 생성하려면 스택의 IP 주소 목록이 필요하고, 로그 디렉터리를 생성하려면 앱의 배포 디렉터리가 필요합니다. 이 데이터를 중앙 서버에 저장하는 대신 OpsWorks Stacks는 각 수명 주기 이벤트에 대해 각 인스턴스의 노드 객체에 스택 구성 및 배포 속성 세트를 설치합니다. 이러한 속성은 배포된 앱을 포함하여 현재 스택 상태를 나타냅니다. 그러면 레시피가 노드 객체로부터 필요한 데이터를 가져옵니다.

**참고**  
때로는 애플리케이션이 스택 구성 및 배포 속성 값과 같이 노드 객체에 저장된 정보를 필요로 합니다. 하지만 애플리케이션은 노드 객체에 액세스할 수 없습니다. 노드 객체 데이터를 애플리케이션에 제공하기 위해 노드 객체에서 필요한 정보를 검색하여 편리한 형식의 파일에 기록하는 레시피를 구현할 수 있습니다. 그러면 애플리케이션이 파일에서 데이터를 읽을 수 있습니다. 자세한 내용과 예제는 [애플리케이션으로 데이터 전달](apps-data.md) 단원을 참조하세요.

레시피는 다음과 같이 노드 객체로부터 스택 구성 및 배포 속성 값을 가져올 수 있습니다.
+ 속성의 정규화된 이름을 사용하여 직접.

  이 방법은 모든 Linux 스택에서 사용할 수 있지만 Windows 스택에서는 사용할 수 없습니다.
+ 노드 객체에서 속성 값을 쿼리하는 데 사용할 수 있는 Chef 검색을 사용.

  이 방법은 모든 Windows 스택 및 Chef 11.10 Linux 스택에서 사용할 수 있습니다.

**참고**  
Linux 스택에서는 에이전트 CLI를 사용하여 인스턴스의 스택 구성 및 배포 속성의 사본을 JSON 형식으로 가져올 수 있습니다. 자세한 내용은 [Vagrant에서 스택 구성 및 배포 속성 모의](opsworks-opsworks-mock.md) 섹션을 참조하세요.

**Topics**
+ [속성 값을 직접 가져오기](cookbooks-101-opsworks-opsworks-stack-config-node.md)
+ [Chef 검색을 사용하여 속성 값 가져오기](cookbooks-101-opsworks-opsworks-stack-config-search.md)

# 속성 값을 직접 가져오기
<a name="cookbooks-101-opsworks-opsworks-stack-config-node"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이 방법은 Linux 스택에서만 사용할 수 있습니다.

[Vagrant에서 스택 구성 및 배포 속성 모의](opsworks-opsworks-mock.md) 섹션에서는 노드 구문을 사용하여 특정 속성을 직접 참조함으로써 스택 구성 및 배포 데이터를 가져오는 방법을 설명합니다. 때로는 이 방법이 최선입니다. 하지만 많은 속성이 모음 또는 목록으로 정의되어 있으며, 그 콘텐츠 및 이름은 스택마다 또한 특정 스택에서도 시간 경과에 따라 다를 수 있습니다. 예를 들어 `deploy` 속성에는 앱의 짧은 이름으로 명명된 앱 속성의 목록이 포함됩니다. 앱 속성을 포함하여 이 목록은 일반적으로 스택마다 다르며, 심지어 배포마다 다릅니다.

목록 또는 모음에서 속성을 열거하여 필요한 데이터를 가져오는 것이 종종 더 유용하고 때로는 반드시 필요할 수도 있습니다. 예를 들어 스택 내 인스턴스의 퍼블릭 IP 주소를 알아야 할 경우 이 정보는 `['opsworks']['layers']` 속성에 포함되어 있습니다. 이 속성은 스택의 각 계층마다 계층의 짧은 이름으로 명명된 한 요소를 포함하는 해시 테이블로 설정됩니다. 각 계층 요소는 계층의 속성을 포함하는 해시 테이블로 설정되며, 이 중 하나가 `['instances']`입니다. 이 요소는 계층의 각 인스턴스마다 인스턴스의 짧은 이름으로 명명된 한 속성을 포함하는 또 하나의 해시 테이블로 설정됩니다. 각 인스턴스 속성은 `['ip']`를 포함하여 퍼블릭 IP 주소를 나타내는 인스턴스 속성을 포함하는 또 다른 해시 테이블로 설정됩니다. 이를 시각화하는 데 어려움이 있을 경우 참조할 수 있도록 다음 절차에 JSON 형식의 예제가 포함되어 있습니다.

이 예제는 스택의 계층에 대해 스택 구성 및 배포 JSON으로부터 데이터를 가져오는 방법을 보여줍니다.

**쿡북을 설정하려면**

1. `opsworks_cookbooks` 안에 `listip` 하위 디렉터리를 만들고 그 디렉터리로 이동합니다.

1. [예제 1: 패키지 설치](cookbooks-101-basics-packages.md) 단원에서 설명하는 대로 Test Kitchen을 초기화 및 구성합니다.

1. `listip`에 디렉터리 `recipes` 및 `environments`를 추가합니다.

1. 관련 속성이 포함된 MyStack 구성 및 배포 속성의 편집된 JSON 버전을 생성합니다. 다음과 같이 보여야 합니다.

   ```
   {
     "opsworks": {
       "layers": {
         "php-app": {
           "name": "PHP App Server",
           "id": "efd36017-ec42-4423-b655-53e4d3710652",
           "instances": {
             "php-app1": {
               "ip": "192.0.2.0"
             }
           }
         },
         "db-master": {
           "name": "MySQL",
           "id": "2d8e0b9a-0d29-43b7-8476-a9b2591a7251",
           "instances": {
             "db-master1": {
               "ip": "192.0.2.5"
             }
           }
         },
         "lb": {
           "name": "HAProxy",
           "id": "d5c4dda9-2888-4b22-b1ea-6d44c7841193",
           "instances": {
             "lb1": {
               "ip": "192.0.2.10"
             }
           }
         }
       }
     }
   }
   ```

1. 환경 파일 `test.json`을 만들고, 예제 JSON을 `default_attributes`에 붙여 넣은 다음 쿡북의 `environments` 폴더에 이 파일을 저장합니다. 이 파일은 다음과 유사해야 합니다(간단한 설명을 위해 대부분의 예제 JSON에서는 생략 부호 사용).

   ```
   {
     "default_attributes" : {
       "opsworks": {
         "layers": {
           ...
         }
       }
     },
     "chef_type" : "environment",
     "json_class" : "Chef::Environment"
   }
   ```

1. `.kitchen.yml`의 텍스트를 다음으로 바꿉니다.

   ```
   ---
   driver:
     name: vagrant
   
   provisioner:
     name: chef_zero
     environments_path: ./environment
   
   platforms:
     - name: ubuntu-12.04
   
   suites:
     - name: listip 
       provisioner:
         client_rb:
           environment: test
       run_list:
         - recipe[listip::default]
       attributes:
   ```

쿡북을 설정한 후 다음 레시피를 사용하여 계층 ID를 기록할 수 있습니다.

```
node['opsworks']['layers'].each do |layer, layerdata|
  log "#{layerdata['name']} : #{layerdata['id']}"
end
```

레시피는 `['opsworks']['layers']`에서 계층을 열거하고 각 계층의 이름 및 ID를 기록합니다.

**계층 ID 로깅 레시피를 실행하려면**

1. 예제 레시피가 포함된 `default.rb` 파일을 만들어 `recipes` 디렉터리에 저장합니다.

1. `kitchen converge`를 실행합니다.

해당 부분은 다음과 유사하게 출력됩니다.

```
Recipe: listip::default       
  * log[PHP App Server : efd36017-ec42-4423-b655-53e4d3710652] action write[2014-07-17T22:56:19+00:00] INFO: Processing log[PHP App Server : efd36017-ec42-4423-b655-53e4d3710652] action write (listip::default line 4)       
[2014-07-17T22:56:19+00:00] INFO: PHP App Server : efd36017-ec42-4423-b655-53e4d3710652       
       
       
  * log[MySQL : 2d8e0b9a-0d29-43b7-8476-a9b2591a7251] action write[2014-07-17T22:56:19+00:00] INFO: Processing log[MySQL : 2d8e0b9a-0d29-43b7-8476-a9b2591a7251] action write (listip::default line 4)       
[2014-07-17T22:56:19+00:00] INFO: MySQL : 2d8e0b9a-0d29-43b7-8476-a9b2591a7251       
       
       
  * log[HAProxy : d5c4dda9-2888-4b22-b1ea-6d44c7841193] action write[2014-07-17T22:56:19+00:00] INFO: Processing log[HAProxy : d5c4dda9-2888-4b22-b1ea-6d44c7841193] action write (listip::default line 4)       
[2014-07-17T22:56:19+00:00] INFO: HAProxy : d5c4dda9-2888-4b22-b1ea-6d44c7841193
```

인스턴스의 IP 주소를 나열하려면 다음과 같은 중첩 루프가 필요합니다.

```
node['opsworks']['layers'].each do |layer, layerdata|
  log "#{layerdata['name']} : #{layerdata['id']}"
  layerdata['instances'].each do |instance, instancedata|
    log "Public IP: #{instancedata['ip']}"
  end
end
```

내부 루프는 각 계층의 인스턴스를 반복하고 IP 주소를 기록합니다.

**인스턴스 IP 로깅 레시피를 실행하려면**

1. `default.rb`의 코드를 예제 레시피로 바꿉니다.

1. `kitchen converge`를 실행하여 레시피를 실행합니다.

해당 부분은 다음과 유사하게 출력됩니다.

```
  * log[PHP App Server : efd36017-ec42-4423-b655-53e4d3710652] action write[2014-07-17T23:09:34+00:00] INFO: Processing log[PHP App Server : efd36017-ec42-4423-b655-53e4d3710652] action write (listip::default line 2)       
[2014-07-17T23:09:34+00:00] INFO: PHP App Server : efd36017-ec42-4423-b655-53e4d3710652       
       
       
  * log[Public IP: 192.0.2.0] action write[2014-07-17T23:09:34+00:00] INFO: Processing log[Public IP: 192.0.2.0] action write (listip::default line 4)       
[2014-07-17T23:09:34+00:00] INFO: Public IP: 192.0.2.0       
       
       
  * log[MySQL : 2d8e0b9a-0d29-43b7-8476-a9b2591a7251] action write[2014-07-17T23:09:34+00:00] INFO: Processing log[MySQL : 2d8e0b9a-0d29-43b7-8476-a9b2591a7251] action write (listip::default line 2)       
[2014-07-17T23:09:34+00:00] INFO: MySQL : 2d8e0b9a-0d29-43b7-8476-a9b2591a7251       
       
       
  * log[Public IP: 192.0.2.5] action write[2014-07-17T23:09:34+00:00] INFO: Processing log[Public IP: 192.0.2.5] action write (listip::default line 4)       
[2014-07-17T23:09:34+00:00] INFO: Public IP: 192.0.2.5       
       
       
  * log[HAProxy : d5c4dda9-2888-4b22-b1ea-6d44c7841193] action write[2014-07-17T23:09:34+00:00] INFO: Processing log[HAProxy : d5c4dda9-2888-4b22-b1ea-6d44c7841193] action write (listip::default line 2)       
[2014-07-17T23:09:34+00:00] INFO: HAProxy : d5c4dda9-2888-4b22-b1ea-6d44c7841193       
       
       
  * log[Public IP: 192.0.2.10] action write[2014-07-17T23:09:34+00:00] INFO: Processing log[Public IP: 192.0.2.10] action write (listip::default line 4)       
[2014-07-17T23:09:34+00:00] INFO: Public IP: 192.0.2.10
```

작업을 마쳤으면 `kitchen destroy`을 실행합니다. 다음 주제에서는 새 쿡북을 사용합니다.

**참고**  
스택 구성 및 배포 JSON 모음을 열거하는 가장 일반적인 이유는 배포된 앱에서 배포 디렉터리와 같은 데이터를 가져오는 것입니다. 예제는 [Deploy 레시피](create-custom-deploy.md) 섹션을 참조하세요.

# Chef 검색을 사용하여 속성 값 가져오기
<a name="cookbooks-101-opsworks-opsworks-stack-config-search"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이 방법은 Windows 스택 및 Chef 11.10 Linux 스택에서 사용할 수 있습니다.

노드 객체로부터 직접 스택 구성 및 배포 속성 값을 가져오는 방법은 복잡할 수 있으며 Windows 스택에서는 사용할 수 없습니다. 대안적 방법은 [Chef 검색](http://docs.chef.io/chef_search.html)을 사용하여 원하는 속성을 쿼리하는 것입니다. Chef 서버에 익숙하다면 Chef 검색이 OpsWorks Stacks와 약간 다르게 작동하는 것을 알 수 있습니다. OpsWorks Stacks는 로컬 모드에서 chef-client를 사용하기 때문에 Chef 검색은 chef-zero라는 로컬 버전의 Chef 서버에 의존하므로 원격 서버가 아닌 인스턴스의 노드 객체에 로컬로 저장된 데이터에 대해 검색이 작동합니다.

실제로는 OpsWorks Stacks 인스턴스의 노드 객체에 [스택 구성 및 배포 속성](workingcookbook-json.md)이 포함되어 있기 때문에 로컬에 저장된 데이터로 검색을 제한하는 것은 일반적으로 중요하지 않습니다. 레시피가 일반적으로 Chef 서버에서 가져오고 동일한 이름을 사용하는 데이터는 대부분 포함되지 않으므로 일반적으로 OpsWorks Stacks 인스턴스에서 Chef 서버에 대해 작성된 검색 코드를 수정 없이 사용할 수 있습니다. 자세한 내용은 [Chef 검색 사용](workingcookbook-chef11-10.md#workingcookbook-chef11-10-search) 단원을 참조하십시오.

다음은 검색 쿼리의 기본의 구조를 보여줍니다.

```
result = search(:search_index, "key:pattern")
```
+ 검색 인덱스는 쿼리가 적용되는 속성을 지정하고 반환되는 객체의 유형을 결정합니다.
+ 키는 속성 이름을 지정합니다.
+ 패턴은 검색하려는 속성의 값을 지정합니다.

  특정 속성 값을 쿼리할 수도 있고 와일드 카드를 사용하여 일련의 값을 쿼리할 수도 있습니다.
+ 결과는 쿼리를 만족하는 객체의 목록이며, 각각 관련 속성이 여러 개 포함된 해시 테이블입니다.

  예를 들어 `node` 검색 인덱스를 사용할 경우 쿼리는 쿼리를 만족하는 인스턴스마다 하나씩 인스턴스 객체의 목록을 반환합니다. 각 객체는 호스트 이름, IP 주소 등 인스턴스 구성을 정의하는 속성 세트를 포함하는 해시 테이블입니다.

예를 들어 다음 쿼리는 스택의 인스턴스(Chef 용어로는 노드)에 적용되는 표준 Chef 검색 인덱스인 `node` 검색 인덱스를 사용합니다. 이 쿼리는 호스트 이름이 `myhost`인 인스턴스를 검색합니다.

```
result = search(:node, "hostname:myhost")
```

검색은 호스트 이름이 `myhost`인 인스턴스 객체의 목록을 반환합니다. 예를 들어 첫 번째 인스턴스의 운영 체제를 원할 경우 `result[0][:os]`에 의해 표현됩니다. 쿼리가 여러 객체를 반환할 경우 객체를 열거하여 필요한 정보를 검색할 수 있습니다.

레시피에서 검색을 사용하는 세부 방법은 Linux 스택 또는 Windows 스택을 사용하는지에 따라 다릅니다. 다음 주제에서는 두 스택 유형 모두에 대한 예제를 제공합니다.

**Topics**
+ [Linux 스택에서 검색 사용](cookbooks-101-opsworks-opsworks-stack-config-search-linux.md)
+ [Windows 스택에서 검색 사용](cookbooks-101-opsworks-opsworks-stack-config-search-windows.md)

# Linux 스택에서 검색 사용
<a name="cookbooks-101-opsworks-opsworks-stack-config-search-linux"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

이 예제는 단일 PHP 애플리케이션 서버를 포함하는 Linux 스택을 기반으로 합니다. Chef 검색을 사용하여 서버의 퍼블릭 IP 주소를 가져와 `/tmp` 디렉터리의 파일에 이 주소를 저장합니다. 기본적으로 [속성 값을 직접 가져오기](cookbooks-101-opsworks-opsworks-stack-config-node.md)와 동일한 정보를 노드 객체에서 검색하지만, 이 코드는 스택 구성 및 배포 속성 구조의 세부 정보에 의존하지 않습니다.

다음은 이 예제를 위한 스택을 생성하는 방법을 간략히 요약한 것입니다. 자세한 내용은 [새 스택 생성](workingstacks-creating.md) 단원을 참조하십시오.

**참고**  
이전에 OpsWorks Stacks 인스턴스에서 사용자 지정 레시피를 실행하지 않은 경우 먼저 [Linux 인스턴스에서 레시피 실행](cookbooks-101-opsworks-opsworks-instance.md) 예제를 진행해야 합니다.

**스택을 만듭니다**

1. [OpsWorks Stacks 콘솔](https://console.aws.amazon.com/opsworks/)을 열고 **스택 추가**를 클릭합니다.

1. 다음 설정을 지정하고, 그 외 설정에 대해서는 기본값을 수락한 다음 [**스택 추가**]를 클릭합니다.
   + **이름** – SearchJSON
   + **기본 SSH 키** – Amazon EC2 키 페어

   Amazon EC2 키 페어를 생성해야 하는 경우 [Amazon EC2 키 페어](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)를 참조하세요. 키 페어는 인스턴스와 동일한 AWS 리전에 속해야 합니다. 이 예에서는 미국 서부(오레곤) 리전을 사용합니다.

1. **계층 추가**를 클릭하여 스택에 기본 설정으로 [PHP 앱 서버 계층을 추가](workinglayers-custom.md)합니다.

1. 기본 설정을 사용하여 계층에 [24/7 인스턴스를 추가](workinginstances-add.md)하고 [해당 인스턴스를 시작](workinginstances-starting.md)합니다.

**쿡북을 설정하려면**

1. `opsworks_cookbooks` 안에 `searchjson` 하위 디렉터리를 만들고 그 디렉터리로 이동합니다.

1. 다음 내용이 포함된 `metadata.rb` 파일을 만들어 `opstest`에 저장합니다.

   ```
   name "searchjson"
   version "0.1.0"
   ```

1. `recipes` 안에 `searchjson` 디렉터리를 만듭니다.

1. 다음 레시피가 포함된 `default.rb` 파일을 만들어 `recipes` 디렉터리에 저장합니다.

   ```
   phpserver = search(:node, "layers:php-app").first
   Chef::Log.info("**********The public IP address is: '#{phpserver[:ip]}'**********")
   
   file "/tmp/ip_addresses" do
     content "#{phpserver[:ip]}"
     mode 0644
     action :create
   end
   ```

   Linux 스택은 `node` 검색 인덱스만 지원합니다. 레시피는 이 인덱스를 사용하여 `php-app` 계층의 인스턴스 목록을 얻습니다. 이 계층에는 인스턴스가 하나 뿐인 것으로 알려져 있기 때문에 레시피는 첫 번째 인스턴스만 `phpserver`에 할당합니다. 계층에 인스턴스가 여러 개인 경우 인스턴스를 열거하여 필요한 정보를 검색할 수 있습니다. 각 목록 항목은 인스턴스 속성 세트가 포함된 해시 테이블입니다. `ip` 속성은 인스턴스의 퍼블릭 IP 주소로 설정되므로 후속 레시피 코드의 해당 주소를 `phpserver[:ip]`로 표현할 수 있습니다.

   메시지를 Chef 로그에 추가하면 레시피는 [https://docs.chef.io/chef/resources.html#file](https://docs.chef.io/chef/resources.html#file) 리소스를 사용하여 `ip_addresses` 파일을 만듭니다. `content` 속성은 `phpserver[:ip]`의 문자열 표현으로 설정됩니다. Chef가 `ip_addresses`를 생성하면 이 파일에 해당 문자열이 추가됩니다.

1. `opsworks_cookbooks`의 `.zip` 아카이브를 생성하고, [이 아카이브를 Amazon S3 버킷에 업로드](https://docs.aws.amazon.com/AmazonS3/latest/UG/UploadingObjectsintoAmazonS3.html)한 다음, [해당 아카이브를 퍼블릭으로 설정](https://docs.aws.amazon.com/AmazonS3/latest/UG/EditingPermissionsonanObject.html)하고, 아카이브의 URL을 기록합니다. 쿡북 리포지토리에 대한 자세한 정보는 [쿡북 리포지토리](workingcookbook-installingcustom-repo.md) 단원을 참조하세요.

   Amazon S3 버킷에 전달한 콘텐츠에는 고객 콘텐츠가 포함될 수 있습니다. 중요 데이터 제거에 관한 자세한 내용은 [S3 버킷을 비우려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html) 단원 또는 [S3 버킷을 삭제하려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html) 단원을 참조하세요.

이제 쿡북을 설치하고 레시피를 실행할 수 있습니다.

**레시피를 실행하려면**

1. [스택을 편집해 사용자 지정 쿡북을 활성화](workingcookbook-installingcustom-enable.md)하고 다음 설정을 지정합니다.
   + **리포지토리 유형** – **Http Archive**
   + **리포지토리 URL** - 앞에서 기록해 둔 쿡북 아카이브 URL

   기타 설정에 기본값을 사용하고 [**저장**]을 클릭하여 스택 구성을 업데이트합니다.

1. 사용자 지정 계층 구성을 편집하고 계층의 설정 이벤트에를 [할당`searchjson::default`](workingcookbook-assigningcustom.md)합니다. 인스턴스가 부팅된 후 또는 설정 이벤트를 명시적으로 트리거한 경우 OpsWorks 스택이 레시피를 실행합니다.

1. [사용자 지정 쿡북 업데이트 스택 명령을 실행](workingstacks-commands.md)하여 스택의 인스턴스에 사용자 지정 쿡북 리포지토리의 최신 버전을 설치합니다. 리포지토리의 이전 버전이 있으면 이 명령이 이전 버전을 덮어 씁니다.

1. [**설정**] 스택 명령을 실행하여 레시피를 실행합니다. 이 레시피는 인스턴스에서 설정 이벤트를 트리거하고 `searchjson::default`를 실행합니다. [**실행 명령 설정**] 페이지는 열어 둡니다.

레시피가 성공적으로 실행되면 이를 확인할 수 있습니다.

**searchjson을 확인하려면**

1. 가장 먼저, [Chef 로그](troubleshoot-debug-log.md)에서 최신 설정 이벤트를 확인합니다. **실행 중인 명령 설정 페이지**에서 php-app1 인스턴스의 **로그** 열에 있는 **표시**를 클릭하여 로그를 표시합니다. 로그를 중간 지점 근처까지 스크롤하여 다음과 같은 로그 메시지를 찾습니다.

   ```
   ...
   [2014-09-05T17:08:41+00:00] WARN: Previous bash[logdir_existence_and_restart_apache2]: ...
   [2014-09-05T17:08:41+00:00] WARN: Current  bash[logdir_existence_and_restart_apache2]: ...
   [2014-09-05T17:08:41+00:00] INFO: **********The public IP address is: '192.0.2.0'**********
   [2014-09-05T17:08:41+00:00] INFO: Processing directory[/etc/sysctl.d] action create (opsworks_initial_setup::sysctl line 1)
   ...
   ```

1. [SSH를 사용하여 인스턴스에 로그인](workinginstances-ssh.md)하고 `/tmp`의 내용을 나열합니다. 여기에는 IP 주소가 포함된 `ip_addresses` 파일이 있어야 합니다.

# Windows 스택에서 검색 사용
<a name="cookbooks-101-opsworks-opsworks-stack-config-search-windows"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

OpsWorks Stacks는 Windows 스택에서 검색을 사용할 수 있는 두 가지 옵션을 제공합니다.
+ 표준 Chef 속성을 쿼리하는 데 사용할 수 있는 `node` 검색 인덱스.

  를 사용하는 검색 코드가 있는 기존 레시피가 있는 경우 `node`일반적으로 수정 없이 OpsWorks Stacks 스택에서 작동합니다.
+  OpsWorks Stacks 고유 속성 및 일부 표준적이 특성을 쿼리하는 데 사용할 수 있는 추가 검색 인덱스 세트.

  이러한 인덱스는 [Windows OpsWorks Stacks에서 스택별 검색 인덱스 사용](cookbooks-101-opsworks-opsworks-stack-config-search-opsworks.md) 섹션에 설명되어 있습니다.

호스트 이름, IP 주소 등 표준적인 정보를 검색할 때는 `node`를 사용하는 것이 좋습니다. 이 방법은 레시피를 표준 Chef 관행과 일관되게 유지해줍니다. OpsWorks Stacks 검색 인덱스를 사용하여 OpsWorks Stacks와 관련된 정보를 검색합니다.

**Topics**
+ [Windows 스택에서 노드 검색 인덱스 사용](cookbooks-101-opsworks-opsworks-stack-config-search-node.md)
+ [Windows OpsWorks Stacks에서 스택별 검색 인덱스 사용](cookbooks-101-opsworks-opsworks-stack-config-search-opsworks.md)

# Windows 스택에서 노드 검색 인덱스 사용
<a name="cookbooks-101-opsworks-opsworks-stack-config-search-node"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이 예제에서는 사용자가 이미 [Windows 인스턴스에서 레시피 실행](cookbooks-101-opsworks-opsworks-windows.md) 예제를 완료한 것으로 가정합니다. 그렇지 않은 경우 먼저 그 예제를 수행해야 합니다. 특히, 그 예제는 인스턴스에 대한 RDP 액세스를 활성화하는 방법을 설명합니다.

이 예제는 단일 사용자 지정 계층 및 단일 인스턴스를 포함하는 Windows 스택을 기반으로 합니다. Chef 검색을 `node` 검색 인덱스와 함께 사용하여 서버의 퍼블릭 IP 주소를 가져와 `C:\tmp` 디렉터리에서 파일에 기록합니다. 다음은 이 예제를 위한 스택을 생성하는 방법을 간략히 요약한 것입니다. 자세한 내용은 [새 스택 생성](workingstacks-creating.md) 섹션을 참조하세요.

**스택을 만듭니다**

1. [OpsWorks Stacks 콘솔](https://console.aws.amazon.com/opsworks/)을 열고 **스택 추가**를 선택합니다.

1. 다음 설정을 지정하고, 그 외 설정에 대해서는 기본값을 수락한 다음 [**스택 추가**]를 선택합니다.
   + **이름** – NodeSearch
   + **리전** – 미국 서부(오레곤)

     이 예제는 모든 리전에서 작동하지만 자습서의 경우 미국 서부(오레곤)를 사용하는 것이 좋습니다.
   + **기본 운영 체제** - Microsoft Windows Server 2012 R2

1. [**계층 추가**]를 선택하여 스택에 다음 설정으로 [사용자 지정 계층을 추가](workinglayers-custom.md)합니다.
   + **이름** – IPTest
   + **짧은 이름** - iptest

1. 기본 설정을 사용하여 IPTest 계층에 [24/7 t2.micro 인스턴스를 추가](workinginstances-add.md)하고 [해당 인스턴스를 시작](workinginstances-starting.md)합니다. 이 인스턴스의 이름은 iptest1입니다.

   OpsWorks Stacks는이 인스턴스`AWS-OpsWorks-RDP-Server`에를 자동으로 할당하므로 권한 있는 사용자가 인스턴스에 로그인할 수 있습니다.

1. [**권한**] 및 [**편집**]을 차례대로 선택하고 [**SSH/RDP**] 및 [**sudo/admin**]을 선택합니다. 인스턴스에 로그인하려면 일반 사용자에게는 `AWS-OpsWorks-RDP-Server` 보안 그룹 이외에 이러한 권한 부여가 필요합니다.
**참고**  
Administrator로도 로그인할 수 있지만 로그인 절차가 다릅니다. 자세한 내용은 [RDP를 사용하여 로그인](workinginstances-rdp.md) 섹션을 참조하세요.

**쿡북을 설정하려면**

1. `nodesearch` 하위 디렉터리를 만들고 그 디렉터리로 이동합니다.

1. 다음 내용이 포함된 `metadata.rb` 파일을 만들어 `opstest`에 저장합니다.

   ```
   name "nodesearch"
   version "0.1.0"
   ```

1. `recipes` 안에 `nodesearch` 디렉터리를 만듭니다.

1. 다음 레시피가 포함된 `default.rb` 파일을 만들어 `recipes` 디렉터리에 저장합니다.

   ```
   directory 'C:\tmp' do
     rights :full_control, 'Everyone'
     recursive true
     action :create
   end
   
   windowsserver = search(:node, "hostname:iptest*").first
   Chef::Log.info("**********The public IP address is: '#{windowsserver[:ipaddress]}'**********")
   
   file 'C:\tmp\addresses.txt' do
     content "#{windowsserver[:ipaddress]}"
     rights :full_control, 'Everyone'
     action :create
   end
   ```

   이 레시피는 다음 작업을 수행합니다.

   1. 디렉터리 리소스를 사용하여 파일을 위한 `C:\tmp` 디렉터리를 만듭니다.

      이 리소스에 대한 자세한 정보는 [예제 3: 디렉터리 생성](cookbooks-101-basics-directories.md) 단원을 참조하세요.

   1. `node` 검색 인덱스와 함께 Chef 검색을 사용하여 `iptest`로 시작하는 호스트 이름이 포함된 노드(인스턴스) 목록을 얻습니다.

      계층의 짧은 이름에 정수를 추가하여 호스트 이름을 생성하는 기본 테마를 사용하는 경우 이 쿼리는 IPTest 계층의 인스턴스를 모두 반환합니다. 예를 들어, 이 계층에는 인스턴스가 하나 뿐인 것으로 알려져 있기 때문에 레시피는 첫 번째 인스턴스만 `windowsserver`에 할당합니다. 인스턴스가 여러 개인 경우 전체 목록을 가져와 인스턴스를 열거할 수 있습니다.

   1. 이 실행을 위해 Chef 로그에 IP 주소와 함께 메시지를 추가합니다.

      `windowsserver` 객체는 `ipaddress` 속성이 인스턴스의 퍼블릭 IP 주소로 설정된 해시 테이블이므로, 후속 레시피 코드의 해당 주소를 `windowsserver[:ipaddress]`로 표현할 수 있습니다. 레시피가 해당 문자열을 메시지에 삽입하고 Chef 로그에 추가합니다.

   1. `file` 리소스를 사용하여 IP 주소가 포함된 `C:\tmp\addresses.txt`라는 파일을 만듭니다.

      이 리소스의 `content` 속성은 파일에 추가할 내용을 지정하는데, 이 경우에는 퍼블릭 IP 주소입니다.

1. `nodesearch`의 `.zip` 아카이브를 생성하고, [이 아카이브를 S3 버킷에 업로드](https://docs.aws.amazon.com/AmazonS3/latest/UG/UploadingObjectsintoAmazonS3.html)한 다음, [해당 아카이브를 퍼블릭으로 설정](https://docs.aws.amazon.com/AmazonS3/latest/UG/EditingPermissionsonanObject.html)하고, 아카이브의 URL을 기록합니다.

   Amazon S3 버킷에 전달한 콘텐츠에는 고객 콘텐츠가 포함될 수 있습니다. 중요 데이터 제거에 관한 자세한 내용은 [S3 버킷을 비우려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html) 단원 또는 [S3 버킷을 삭제하려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html) 단원을 참조하세요.

이제 쿡북을 설치하고 레시피를 실행할 수 있습니다.

**쿡북을 설치하고 레시피를 실행하려면**

1. [스택을 편집해 사용자 지정 쿡북을 활성화](workingcookbook-installingcustom-enable.md)하고 다음 설정을 지정합니다.
   + **리포지토리 유형** – **S3 아카이브**
   + **리포지토리 URL** - 앞에서 기록해 둔 쿡북 아카이브 URL

   기타 설정에 대해 기본값을 수락하고 [**저장**]을 선택하여 스택 구성을 업데이트합니다.

1. [사용자 지정 쿡북 업데이트 스택 명령을 실행](workingstacks-commands.md)하여 스택의 인스턴스(온라인 인스턴스 포함)에 사용자 지정 쿡북의 최신 버전을 설치합니다. 쿡북의 이전 버전이 있으면 이 명령이 이전 버전을 덮어 씁니다.

1. 사용자 지정 쿡북 업데이트가 완료되면 **실행할 레시피**가 **nodesearch::default**로 설정된 상태에서 [**레시피 실행** 스택 명령](workingstacks-commands.md)을 실행하여 레시피를 실행합니다. 이 명령은 레시피로 구성된 실행 목록을 사용하여 Chef 실행을 시작합니다. execute\$1recipes 페이지는 그대로 열어 두십시오.

레시피가 성공적으로 실행되면 이를 확인할 수 있습니다.

**nodesearch를 확인하려면**

1. [Chef 로그](troubleshoot-debug-log.md)에서 최신 execute\$1recipes 이벤트를 확인합니다. **실행 중인 명령 execute\$1recipes 페이지**에서 iptest1 인스턴스의 **로그** 열에 있는 **표시**를 선택하여 로그를 표시합니다. 로그를 거의 끝까지 아래로 스크롤하여 다음과 같은 로그 메시지를 찾습니다.

   ```
   ...
   [2015-05-13T18:55:47+00:00] INFO: Storing updated cookbooks/nodesearch/recipes/default.rb in the cache.
   [2015-05-13T18:55:47+00:00] INFO: Storing updated cookbooks/nodesearch/metadata.rb in the cache.
   [2015-05-13T18:55:47+00:00] INFO: **********The public IP address is: '192.0.0.1'**********
   [2015-05-13T18:55:47+00:00] INFO: Processing directory[C:\tmp] action create (nodesearch::default line 1)
   [2015-05-13T18:55:47+00:00] INFO: Processing file[C:\tmp\addresses.txt] action create (nodesearch::default line 10) 
   ...
   ```

1. [RDP를 사용하여 인스턴스에 로그인](workinginstances-rdp.md)하고 `C:\tmp\addresses.txt`의 내용을 확인합니다.

# Windows OpsWorks Stacks에서 스택별 검색 인덱스 사용
<a name="cookbooks-101-opsworks-opsworks-stack-config-search-opsworks"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이 예제에서는 사용자가 이미 [Windows 인스턴스에서 레시피 실행](cookbooks-101-opsworks-opsworks-windows.md) 예제를 완료한 것으로 가정합니다. 그렇지 않은 경우 먼저 그 예제를 수행해야 합니다. 특히, 그 예제는 인스턴스에 대한 RDP 액세스를 활성화하는 방법을 설명합니다.

OpsWorks Stacks는 외에도 `node`다음과 같은 검색 인덱스를 제공합니다.
+ `aws_opsworks_stack` – 스택 구성.
+ `aws_opsworks_layer` – 스택의 계층 구성.
+ `aws_opsworks_instance` – 스택의 인스턴스 구성.
+ `aws_opsworks_app` – 스택의 앱 구성.
+ `aws_opsworks_user` – 스택의 사용자 구성.
+ `aws_opsworks_rds_db_instance` – 등록된 RDS 인스턴스의 연결 정보.

이러한 인덱스에는 일부 표준 Chef 속성이 포함되지만 주로 OpsWorks Stacks별 속성을 검색하기 위한 것입니다. 예를 들어 `aws_opsworks_instance`는 `online`과 같은 인스턴스 상태를 제공하는 `status` 포함합니다.

**참고**  
권장되는 방법은 가능할 경우 `node`를 사용하여 레시피를 표준 Chef 사용과 일관되게 유지하는 것입니다. 예제는 [Windows 스택에서 노드 검색 인덱스 사용](cookbooks-101-opsworks-opsworks-stack-config-search-node.md) 섹션을 참조하세요.

이 예제에서는 OpsWorks Stacks 인덱스를 사용하여 OpsWorks Stacks별 속성의 값을 검색하는 방법을 보여줍니다. 이 예제는 단일 인스턴스의 단일 사용자 지정 계층을 포함하는 단순한 Windows 스택을 기반으로 합니다. Chef 검색을 사용하여 인스턴스의 OpsWorks Stacks ID를 가져오고 결과를 Chef 로그에 넣습니다.

다음은 이 예제를 위한 스택을 생성하는 방법을 간략히 요약한 것입니다. 자세한 내용은 [새 스택 생성](workingstacks-creating.md) 섹션을 참조하세요.

**스택을 만듭니다**

1. [OpsWorks Stacks 콘솔](https://console.aws.amazon.com/opsworks/)을 열고 **\$1 Stack(\$1 스택)**을 선택합니다. 다음 설정을 지정하고, 그 외 설정에 대해서는 기본값을 수락한 다음 [**스택 추가**]를 선택합니다.
   + **이름** – IDSearch
   + **리전** – 미국 서부(오레곤)

     이 예제는 모든 리전에서 작동하지만 자습서의 경우 미국 서부(오레곤)를 사용하는 것이 좋습니다.
   + **기본 운영 체제** - Microsoft Windows Server 2012 R2

1. [**계층 추가**]를 선택하여 스택에 다음 설정으로 [사용자 지정 계층을 추가](workinglayers-custom.md)합니다.
   + **이름** – IDCheck
   + **짧은 이름** - idcheck

1. 기본 설정을 사용하여 IDCheck 계층에 [24/7 t2.micro 인스턴스를 추가](workinginstances-add.md)하고 [해당 인스턴스를 시작](workinginstances-starting.md)합니다. 이 인스턴스의 이름은 iptest1입니다.

   OpsWorks Stacks는이 인스턴스`AWS-OpsWorks-RDP-Server`에를 자동으로 할당합니다.는 권한이 있는 사용자가 인스턴스에 로그인할 수 있도록 허용하는 인바운드 규칙을이 보안 그룹에 추가하는 방법을 [RDP 액세스 활성화](cookbooks-101-opsworks-opsworks-windows.md#cookbooks-101-opsworks-opsworks-windows-rdp) 설명합니다.

1. [**권한**] 및 [**편집**]을 차례대로 선택하고 [**SSH/RDP**] 및 [**sudo/admin**]을 선택합니다. 인스턴스에 로그인하려면 일반 사용자에게는 `AWS-OpsWorks-RDP-Server` 보안 그룹 이외에 이러한 권한 부여가 필요합니다.
**참고**  
Administrator로도 로그인할 수 있지만 로그인 절차가 다릅니다. 자세한 내용은 [RDP를 사용하여 로그인](workinginstances-rdp.md) 섹션을 참조하세요.

**쿡북을 설정하려면**

1. `idcheck` 하위 디렉터리를 만들고 그 디렉터리로 이동합니다.

1. 다음 내용이 포함된 `metadata.rb` 파일을 만들어 `opstest`에 저장합니다.

   ```
   name "idcheck"
   version "0.1.0"
   ```

1. `idcheck` 안에 `recipes` 디렉터리를 만들고 다음 레시피가 포함된 `default.rb` 파일을 이 디렉터리에 추가합니다.

   ```
   windowsserver = search(:aws_opsworks_instance, "hostname:idcheck*").first
   Chef::Log.info("**********The public IP address is: '#{windowsserver[:instance_id]}'**********")
   ```

   이 레시피는 `aws_opsworks_instance` 검색 인덱스와 함께 Chef 검색을 사용하여 스택의 각 인스턴스에 대한 [인스턴스 속성](data-bag-json-instance.md)을 `idcheck`로 시작하는 호스트 이름과 함께 가져옵니다. 계층의 짧은 이름에 정수를 추가하여 호스트 이름을 생성하는 기본 테마를 사용하는 경우 이 쿼리는 IDCheck 계층의 인스턴스를 모두 반환합니다. 예를 들어, 이 계층에는 인스턴스가 하나 뿐인 것으로 알려져 있기 때문에 레시피는 첫 번째 인스턴스만 `windowsserver`에 할당합니다. 인스턴스가 여러 개인 경우 전체 목록을 가져와 인스턴스를 열거할 수 있습니다.

   이 레시피는 스택에는 이 호스트 이름을 가진 인스턴스가 하나 뿐이라는 사실을 활용하므로 첫 번째 결과는 올바른 인스턴스 하나입니다. 스택에 인스턴스가 여러 개인 경우 다른 속성을 검색하면 결과가 두 개 이상 반환될 수 있습니다. 인스턴스 속성의 목록은 [인스턴스 데이터 백(aws\$1opsworks\$1instance)](data-bag-json-instance.md) 단원을 참조하세요.

   인스턴스 속성은 기본적으로 해시 테이블이며 인스턴스의 OpsWorks Stacks ID가 `instance_id` 속성에 할당되므로 ID를 로 참조할 수 있습니다`windowsserver[:instance_id]`. 레시피가 해당 문자열을 메시지에 삽입하고 Chef 로그에 추가합니다.

1. `ipaddress` 쿡북의 `.zip` 아카이브를 생성하고, [이 아카이브를 Amazon S3 버킷에 업로드](https://docs.aws.amazon.com/AmazonS3/latest/UG/UploadingObjectsintoAmazonS3.html)한 다음, 해당 아카이브의 URL을 기록합니다. 쿡북 리포지토리에 대한 자세한 정보는 [쿡북 리포지토리](workingcookbook-installingcustom-repo.md) 단원을 참조하세요.

   Amazon S3 버킷에 전달한 콘텐츠에는 고객 콘텐츠가 포함될 수 있습니다. 중요 데이터 제거에 관한 자세한 내용은 [S3 버킷을 비우려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html) 단원 또는 [S3 버킷을 삭제하려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html) 단원을 참조하세요.

이제 쿡북을 설치하고 레시피를 실행할 수 있습니다.

**쿡북을 설치하고 레시피를 실행하려면**

1. [스택을 편집해 사용자 지정 쿡북을 활성화](workingcookbook-installingcustom-enable.md)하고 다음 설정을 지정합니다.
   + **리포지토리 유형** – **S3 아카이브**
   + **리포지토리 URL** - 앞에서 기록해 둔 쿡북 아카이브 URL

   기타 설정에 대해 기본값을 수락하고 [**저장**]을 선택하여 스택 구성을 업데이트합니다.

1. [사용자 지정 쿡북 업데이트 스택 명령을 실행](workingstacks-commands.md)하여 스택의 인스턴스(온라인 인스턴스 포함)에 사용자 지정 쿡북의 최신 버전을 설치합니다. 쿡북의 이전 버전이 있으면 이 명령이 이전 버전을 덮어 씁니다.

1. 사용자 지정 쿡북 업데이트가 완료되면 **실행할 레시피**가 **idcheck::default**로 설정된 상태에서 [**레시피 실행** 스택 명령](workingstacks-commands.md)을 실행하여 레시피를 실행합니다. 이 명령은 레시피로 구성된 실행 목록을 사용하여 Chef 실행을 시작합니다. execute\$1recipes 페이지는 그대로 열어 두십시오.

레시피가 성공적으로 실행되면 [Chef 로그](troubleshoot-debug-log.md)에서 가장 최근의 execute\$1recipes 이벤트를 보고 이를 확인할 수 있습니다. **실행 중인 명령 execute\$1recipes 페이지**에서 iptest1 인스턴스의 **로그** 열에 있는 **표시**를 선택하여 로그를 표시합니다. 로그를 거의 끝까지 아래로 스크롤하여 다음과 같은 로그 메시지를 찾습니다.

```
...
[2015-05-13T20:03:47+00:00] INFO: Storing updated cookbooks/nodesearch/recipes/default.rb in the cache.
[2015-05-13T20:03:47+00:00] INFO: Storing updated cookbooks/nodesearch/metadata.rb in the cache.
[2015-05-13T20:03:47+00:00] INFO: **********The instance ID is: 'i-8703b570'**********
[2015-05-13T20:03:47+00:00] INFO: Chef Run complete in 0.312518 seconds 
...
```

# Linux 인스턴스에서 외부 쿡북 사용: Berkshelf
<a name="cookbooks-101-opsworks-berkshelf"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
Berkshelf는 Chef 11.10 Linux 스택에서만 사용할 수 있습니다.

쿡북을 구현하기 전에 Chef 커뮤니티의 구성원들이 매우 다양한 용도를 위해 생성한 쿡북이 포함되어 있는 [Chef 커뮤니티 쿡북](https://github.com/opscode-cookbooks)을 확인하세요. 이러한 쿡북은 대부분 수정 없이 OpsWorks Stacks에서 사용할 수 있으므로 모든 코드를 직접 구현하는 대신 일부 작업에 활용할 수 있습니다.

인스턴스에서 외부 쿡북을 사용하려면 쿡북을 설치하고 종속성을 관리할 방법이 필요합니다. 선호되는 방법은 Berkshelf라는 종속성 관리자를 지원하는 쿡북을 구현하는 것입니다. Berkshelf는 OpsWorks Stacks 인스턴스를 포함한 Amazon EC2 인스턴스에서 작동하지만 Test Kitchen 및 Vagrant와 함께 작동하도록 설계되었습니다. 그러나 Vagrant의 사용량은 OpsWorks Stacks와 약간 다르므로이 주제에는 두 플랫폼에 대한 예제가 포함되어 있습니다. Berkshelf를 사용하는 방법에 대한 자세한 정보는 [Berkshelf](http://berkshelf.com/)를 참조하세요.

**Topics**
+ [Test Kitchen 및 Vagrant에서 Berkshelf 사용](#cookbooks-101-opsworks-berkshelf-vagrant)
+ [OpsWorks Stacks에서 Berkshelf 사용](#opsworks-berkshelf-opsworks)

## Test Kitchen 및 Vagrant에서 Berkshelf 사용
<a name="cookbooks-101-opsworks-berkshelf-vagrant"></a>

 이 예제는 Berkshelf를 사용하여 시작하기 커뮤니티 쿡북을 설치하고 해당 레시피를 실행하는 방법을 보여줍니다. 이 레시피는 인스턴스의 홈 디렉터리에 간단한 텍스트 파일을 설치합니다.

**Berkshelf를 설치하고 쿡북을 초기화하려면**

1. 워크스테이션에 다음과 같이 Berkshelf Gem을 설치합니다.

   ```
   gem install berkshelf
   ```

   워크스테이션에 따라 이 명령에는 `sudo`가 필요할 수 있습니다. 또는 Ruby 환경 관리자(예: [RVM](https://rvm.io/))를 사용할 수도 있습니다. Berkshelf가 성공적으로 설치되었는지 확인하려면 `berks --version`을 실행합니다.

1. 이 주제의 쿡북 이름은 external\$1cookbook입니다. 이전 주제에서 채택한 수동 접근 방식 대신 Berkshelf를 사용하여 초기화된 쿡북을 생성할 수 있습니다. 이렇게 하려면 `opsworks_cookbooks` 디렉터리로 이동하여 다음 명령을 실행합니다.

   ```
   berks cookbook external_cookbook
   ```

   이 명령은 `external_cookbook` 디렉터리와 `recipes` 및 `test`를 비롯하여 Chef 및 Test Kitchen 하위 디렉터리를 만듭니다. 또한 이 명령은 다음을 비롯하여 여러 표준 파일의 기본 버전을 생성합니다.
   + `metadata.rb`
   + Vagrant, Test Kitchen 및 Berkshelf용 구성 파일
   + `default.rb` 디렉터리의 빈 `recipes` 레시피
**참고**  
`kitchen init`를 실행할 필요가 없습니다. `berks cookbook` 명령이 이러한 작업을 처리하기 때문입니다.

1. `kitchen converge`를 실행합니다. 새로 생성된 쿡북은 이 시점에서 어떠한 의미 있는 작업을 수행하지 않지만 수렴을 수행합니다.

**참고**  
또한 `berks init`를 사용하여 Berkshelf를 사용하도록 기존 쿡북을 초기화할 수도 있습니다.

Berkshelf를 사용하여 쿡북의 외부 종속성을 관리하려면 쿡북의 루트 디렉터리에 Berkshelf가 종속성을 관리하는 방법을 지정하는 구성 파일인 `Berksfile`이 포함되어야 합니다. `berks cookbook`을 사용하여 `external_cookbook` 쿡북을 생성한 경우 다음 콘텐츠를 포함하는 `Berksfile`이 생성되었습니다.

```
source "https://supermarket.chef.io"
metadata
```

이 파일에는 다음 선언이 포함됩니다.
+ `source` – 쿡북 소스의 URL.

  Berksfile에는 각각 종속 쿡북의 기본 소스를 지정하는 `source` 선언이 여러 개 포함될 수 있습니다. 쿡북의 소스를 명시적으로 지정하지 않을 경우 Berkshelf는 기본 리포지토리에서 동일한 이름의 쿡북을 찾습니다. 기본 Berksfile에는 커뮤니티 쿡북 리포지토리를 지정하는 `source` 속성이 포함됩니다. 이 리포지토리에 시작하기 쿡북이 들어 있습니다. 따라서 이 줄은 그대로 둘 수 있습니다.
+ `metadata` - Berkshelf에게 쿡북의 `metadata.rb` 파일에서 선언된 쿡북 종속성을 포함하도록 지시합니다.

  나중에 설명하듯이 `cookbook` 속성을 포함시켜 Berksfile에서 종속 쿡북을 선언할 수도 있습니다.

쿡북 종속성을 선언하는 방법은 두 가지입니다.
+ Berksfile에 `cookbook` 선언을 포함.

  이는 OpsWorks Stacks에서 사용하는 접근 방식입니다. 예를 들어 이 예제에서 사용되는 시작하기 쿡북을 지정하려면 Berksfile에 `cookbook "getting-started"`를 포함시킵니다. 그러면 Berkshelf가 기본 리포지토리에서 동일한 이름의 쿡북을 찾습니다. 또한 `cookbook`을 사용하여 쿡북 소스는 물론 특정 버전까지 명시적으로 지정할 수도 있습니다. 자세한 정보는 [Berkshelf](http://berkshelf.com/)를 참조하세요.
+ Berksfile에 `metadata` 선언을 포함하고 `metadata.rb`에서 종속성을 선언.

  이 선언은 Berkshelf에게 쿡북의 `metadata.rb` 파일에서 선언된 쿡북 종속성을 포함하도록 지시합니다. 예를 들어 시작하기 종속성을 선언하려면 `depends 'getting-started'` 선언을 쿡북의 `metadata.rb` 파일에 추가합니다.

이 예제에서는 OpsWorks Stacks와의 일관성을 위해 첫 번째 접근 방식을 사용합니다.

**getting-started 쿡북을 설치하려면**

1. 기본 Berksfile을 편집하여 `metadata` 선언을 `getting-started`에 대한 `cookbook` 선언으로 바꿉니다. 내용은 다음과 같아야 합니다.

   ```
   source "https://supermarket.chef.io"
   
   cookbook 'getting-started'
   ```

1. 커뮤니티 쿡북 리포지토리에서 워크스테이션의 Berkshelf 디렉터리(일반적으로 `~/.berkshelf`)로 getting-started 쿡북을 다운로드하는 `berks install`을 실행합니다. 일반적으로 이 디렉터리는 *the Berkshelf*라고 합니다. Berkshelf의 `cookbooks` 디렉터리를 살펴보면 getting-started 쿡북의 디렉터리가 있어야 하고 이 디렉터리의 이름은 `getting-started-0.4.0`과 유사합니다.

1. `external_cookbook::default` 실행 목록의 `.kitchen.yml`를 `getting-started::default`로 바꿉니다. 이 예제는 external\$1cookbook의 레시피를 실행하지 않고 기본적으로 getting-started 쿡북을 사용하는 방식입니다. `.kitchen.yml` 파일은 이제 다음과 유사해야 합니다.

   ```
   ---
   driver:
     name: vagrant
   
   provisioner:
     name: chef_solo
   
   platforms:
     - name: ubuntu-12.04
   
   suites:
     - name: default
       run_list:
         - recipe[getting-started::default]
       attributes:
   ```

1. `kitchen converge`를 실행한 다음 `kitchen login`을 사용하여 인스턴스에 로그인합니다. 로그인 디렉터리에는 내용이 다음과 같은 `chef-getting-started.txt` 파일이 포함되어 있어야 합니다.

   ```
   Welcome to Chef!
   
   This is Chef version 11.12.8.
   Running on ubuntu.
   Version 12.04.
   ```

   Test Kitchen은 인스턴스의 `/tmp/kitchen/cookbooks` 디렉터리에 쿡북을 설치합니다. 이 디렉터리의 내용을 나열하면 external\$1cookbook 및 getting-started, 이렇게 2개의 쿡북이 있습니다.

1. `kitchen destroy`를 실행하여 인스턴스를 종료합니다. 다음 예제에서는 OpsWorks Stacks 인스턴스를 사용합니다.

## OpsWorks Stacks에서 Berkshelf 사용
<a name="opsworks-berkshelf-opsworks"></a>

OpsWorks Stacks는 선택적으로 Chef 11.10 스택용 Berkshelf를 지원합니다. 스택에서 Berkshelf를 사용하려면 다음을 수행해야 합니다.
+ 스택에서 Berkshelf를 활성화합니다.

  OpsWorks 그런 다음 Stacks는 스택의 인스턴스에 Berkshelf를 설치하는 세부 정보를 처리합니다.
+ Berksfile을 리포지토리의 루트 디렉터리에 추가합니다.

  Berksfile은 모든 종속 쿡북에 대해 `source` 및 `cookbook` 선언을 포함해야 합니다.

Stacks는 인스턴스에 사용자 지정 쿡북 OpsWorks 리포지토리를 설치할 때 Berkshelf를 사용하여 리포지토리의 Berksfile에 선언된 종속 쿡북을 설치합니다. 자세한 내용은 [Berkshelf 사용](workingcookbook-chef11-10.md#workingcookbook-chef11-10-berkshelf) 단원을 참조하십시오.

이 예제에서는 Berkshelf를 사용하여 Stacks 인스턴스에 시작하기 커뮤니티 OpsWorks 쿡북을 설치하는 방법을 보여줍니다. 또한 지정된 디렉터리에 파일을 생성하는 createfile 사용자 지정 쿡북도 설치합니다. createfile 파일이 작동하는 방식에 대한 자세한 정보는 [쿡북에서 파일 설치](cookbooks-101-basics-files.md#cookbooks-101-basics-files-cookbook_file) 단원을 참조하세요.

**참고**  
Stacks 스택에 사용자 지정 OpsWorks 쿡북을 처음 설치한 경우 먼저 [Linux 인스턴스에서 레시피 실행](cookbooks-101-opsworks-opsworks-instance.md) 예제를 살펴봐야 합니다.

다음에 요약된 대로 스택을 생성하여 시작합니다. 자세한 내용은 [새 스택 생성](workingstacks-creating.md) 섹션을 참조하세요.

**스택을 만듭니다**

1. [OpsWorks Stacks 콘솔](https://console.aws.amazon.com/opsworks/)을 열고 **스택 추가**를 클릭합니다.

1. 다음 설정을 지정하고, 그 외 설정에 대해서는 기본값을 수락한 다음 [**스택 추가**]를 클릭합니다.
   + **이름** – BerksTest
   + **기본 SSH 키** – Amazon EC2 키 페어

   Amazon EC2 키 페어를 생성해야 하는 경우 [Amazon EC2 키 페어](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)를 참조하세요. 키 페어는 인스턴스와 동일한 AWS 리전에 속해야 합니다. 이 예에서는 기본 미국 서부(오레곤) 리전을 사용합니다.

1. [**계층 추가**]를 클릭하여 스택에 다음 설정으로 [사용자 지정 계층을 추가](workinglayers-custom.md)합니다.
   + **이름** – BerksTest
   + **짧은 이름** - berkstest

   이 예제에는 실제로 모든 계층 유형을 사용할 수 있습니다. 그러나 이 예제에서는 다른 계층에서 설치한 패키지가 필요하지 않기 때문에 사용자 지정 계층을 사용하는 것이 가장 간단합니다.

1. 기본 설정을 사용하여 BerksTest 계층에 [24/7 인스턴스를 추가](workinginstances-add.md)하되 해당 인스턴스를 아직 시작하지는 마십시오.

Stacks에서는 OpsWorks 쿡북이 표준 디렉터리 구조의 원격 리포지토리에 있어야 합니다. 그런 다음 Stacks에 다운로드 정보를 제공합니다. 그러면 시작 시 OpsWorks 스택의 각 인스턴스에 리포지토리가 자동으로 다운로드됩니다. 간소화를 위해이 예제의 OpsWorks 리포지토리는 퍼블릭 Amazon S3 아카이브이지만 Stacks는 HTTP 아카이브, Git 리포지토리 및 하위 버전 리포지토리도 지원합니다. 자세한 내용은 [쿡북 리포지토리](workingcookbook-installingcustom-repo.md) 단원을 참조하십시오.

Amazon S3 버킷에 전달한 콘텐츠에는 고객 콘텐츠가 포함될 수 있습니다. 중요 데이터 제거에 관한 자세한 내용은 [S3 버킷을 비우려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html) 단원 또는 [S3 버킷을 삭제하려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html) 단원을 참조하세요.

**쿡북 리포지토리를 생성하려면**

1. `opsworks_cookbooks` 디렉터리에서 `berkstest_cookbooks`라는 디렉터리를 만듭니다. 이 디렉터리는 리포지토리에 업로드할 것이므로 원하는 경우 편리한 위치면 어디에든 이 디렉터리를 만들 수 있습니다.

1. 다음 내용이 포함된 Berksfile이라는 파일을 `berkstest_cookbooks`에 추가합니다.

   ```
   source "https://supermarket.chef.io"
   
   cookbook 'getting-started'
   ```

   이 파일은 getting-started 쿡북 종속성을 선언하고 Berkshelf에 커뮤니티 쿡북 사이트에서 종속성을 다운로드하도록 지시합니다.

1. `createfile` 디렉터리를 다음 항목이 포함된 `berkstest_cookbooks`에 추가합니다.
   + 다음 내용이 포함된 `metadata.rb` 파일

     ```
     name "createfile"
     version "0.1.0"
     ```
   + 다음 내용이 들어 있는 `files/default` 파일이 포함된 `example_data.json` 디렉터리

     ```
     {
       "my_name" : "myname",
       "your_name" : "yourname",
       "a_number" : 42,
       "a_boolean" : true
     }
     ```

     파일의 이름 및 내용은 임의적입니다. 이 레시피는 지정된 위치에 파일을 복사하기만 합니다.
   + 다음 레시피 코드가 들어 있는 `recipes` 파일이 포함된 `default.rb` 디렉터리

     ```
     directory "/srv/www/shared" do
       mode 0755
       owner 'root'
       group 'root'
       recursive true
       action :create
     end
     
     cookbook_file "/srv/www/shared/example_data.json" do
       source "example_data.json"
       mode 0644
       action :create_if_missing
     end
     ```

     이 레시피는 `/srv/www/shared`를 만들고, 쿡북의 `files` 디렉터리에서 이 디렉터리로 `example_data.json`을 복사합니다.

1. `berkstest_cookbooks`의 `.zip` 아카이브를 생성하고, [이 아카이브를 Amazon S3 버킷에 업로드](https://docs.aws.amazon.com/AmazonS3/latest/UG/UploadingObjectsintoAmazonS3.html)한 다음, [해당 아카이브를 퍼블릭으로 설정](https://docs.aws.amazon.com/AmazonS3/latest/UG/EditingPermissionsonanObject.html)하고, 아카이브의 URL을 기록합니다.

이제 쿡북을 설치하고 레시피를 실행할 수 있습니다.

**쿡북을 설치하고 레시피를 실행하려면**

1. [스택을 편집해 사용자 지정 쿡북을 활성화](workingcookbook-installingcustom-enable.md)하고 다음 설정을 지정합니다.
   + **리포지토리 유형** – **Http Archive**
   + **리포지토리 URL** - 앞에서 기록해 둔 쿡북 아카이브 URL
   + **Berkshelf 관리** – **예**

   처음 두 설정은 OpsWorks Stacks에 쿡북 리포지토리를 인스턴스에 다운로드하는 데 필요한 정보를 제공합니다. 마지막 설정은 인스턴스로 getting-started 쿡북을 다운로드하는 Berkshelf 지원을 활성화합니다. 기타 설정에 대해 기본값을 수락하고 [**저장**]을 클릭하여 스택 구성을 업데이트합니다.

1. BerksTest 계층을 편집하여 [다음 레시피를 계층의 설정 수명 주기 이벤트에 추가](workingcookbook-assigningcustom.md)합니다.
   + `getting-started::default`
   + `createfile::default`

1. 인스턴스를 [시작](workinginstances-starting.md)합니다. Setup 이벤트는 인스턴스 부팅이 완료된 후에 발생합니다. 그런 다음 OpsWorks Stacks는 쿡북 리포지토리를 설치하고, Berkshelf를 사용하여 시작하기 쿡북을 다운로드하고, `getting-started::default` 및를 포함한 계층의 설정 및 배포 레시피를 실행합니다`createfile::default`.

1. 인스턴스가 온라인 상태가 되면 [SSH를 사용하여 로그인합니다](workinginstances-ssh.md). 다음과 같은 모양이어야 합니다.
   + `/srv/www/shared`에는 `example_data.json`이 포함되어 있어야 합니다.
   + `/root`에는 `chef-getting-started.txt`이 포함되어 있어야 합니다.

     OpsWorks Stacks는 레시피를 루트로 실행하므로 시작하기를 통해 홈 `/root` 디렉터리가 아닌 디렉터리에 파일이 설치됩니다.

# SDK for Ruby 사용: Amazon S3에서 파일 다운로드
<a name="cookbooks-101-opsworks-s3"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

AWS 서비스와 통합과 같은 일부 작업은 Chef 리소스를 사용하여 처리할 수 없습니다. 예를 들어 파일을 원격에 저장하고 레시피가 인스턴스로 다운로드하게 하는 것이 더 좋을 때가 있습니다. [remote\$1file](https://docs.chef.io/chef/resources.html#remote-file) 리소스를 사용하여 원격 서버에서 파일을 다운로드할 수 있습니다. 하지만 [Amazon S3 버킷](https://docs.aws.amazon.com/AmazonS3/latest/dev/Welcome.html)에 파일을 저장하려는 경우 `remote_file`는 [ACL](https://docs.aws.amazon.com/AmazonS3/latest/UG/EditingPermissionsonanObject.html)에서 작업을 허용하는 경우에만 해당 파일을 다운로드할 수 있습니다.

레시피는 [AWS SDK for Ruby](https://docs.aws.amazon.com/sdk-for-ruby/v3/api/)를 사용하여 대부분의 AWS 서비스에 액세스할 수 있습니다. 이 주제는 SDK for Ruby를 사용하여 S3 버킷에서 파일을 다운로드하는 방법을 보여줍니다.

**참고**  
[AWS SDK for Ruby](https://docs.aws.amazon.com/sdk-for-ruby/v3/api/)를 사용하여 암호화 및 암호 해독을 처리하는 방법에 대한 자세한 내용은 [AWS::S3::S3Object](https://docs.aws.amazon.com/AWSRubySDK/latest/AWS/S3/S3Object.html)를 참조하세요. Amazon S3 버킷에 전달한 콘텐츠에는 고객 콘텐츠가 포함될 수 있습니다. 중요 데이터 제거에 관한 자세한 내용은 [S3 버킷을 비우려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html) 단원 또는 [S3 버킷을 삭제하려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html) 단원을 참조하세요.

**Topics**
+ [Vagrant 인스턴스에서 SDK for Ruby 사용](cookbooks-101-opsworks-s3-vagrant.md)
+ [OpsWorks Stacks Linux 인스턴스에서 SDK for Ruby 사용](cookbooks-101-opsworks-s3-opsworks.md)
+ [OpsWorks Stacks Windows 인스턴스에서 SDK for Ruby 사용](cookbooks-101-opsworks-s3-windows.md)

# Vagrant 인스턴스에서 SDK for Ruby 사용
<a name="cookbooks-101-opsworks-s3-vagrant"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

이 주제에서는 Vagrant 인스턴스에서 실행되는 레시피가 어떻게 [AWS SDK for Ruby](https://docs.aws.amazon.com/sdk-for-ruby/v3/api/)를 사용하여 Amazon S3에서 파일을 다운로드할 수 있는지에 대해 설명합니다. 시작하기 전에 먼저 레시피가 Amazon S3에 액세스할 수 있도록 허용하는 액세스 키와 보안 액세스 키라는 AWS 자격 증명 세트가 있어야 합니다.

**중요**  
이 목적으로 루트 계정 자격 증명은 사용하지 않는 것이 좋습니다. 그 대신, 적절한 정책으로 사용자를 생성하고 레시피에 해당 자격 증명을 제공합니다.  
자격 증명을 포함한 파일을 공개 GitHub 또는 Bitbucket 저장소에 업로드하는 등 공개적으로 액세스할 수 있는 위치에 자격 증명(IAM 사용자 자격 증명 포함)을 보관하지 않도록 주의하세요. 그러면 자격 증명이 노출되고 계정의 보안이 훼손될 수 있습니다.  
 EC2Amazon EC2 인스턴스에서 실행되는 레시피는 더욱 뛰어난 방식인 IAM 역할을 사용할 수 있습니다([OpsWorks Stacks Linux 인스턴스에서 SDK for Ruby 사용](cookbooks-101-opsworks-s3-opsworks.md) 단원 참조).  
Amazon S3 버킷에 전달한 콘텐츠에는 고객 콘텐츠가 포함될 수 있습니다. 중요 데이터 제거에 관한 자세한 내용은 [S3 버킷을 비우려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html) 단원 또는 [S3 버킷을 삭제하려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html) 단원을 참조하세요.

적절한 사용자가 아직 없는 경우 다음과 같이 생성할 수 있습니다. 자세한 내용은 [IAM이란?](https://docs.aws.amazon.com/IAM/latest/UserGuide/Introduction.html)을 참조하세요.

**주의**  
IAM 사용자는 장기 자격 증명을 가지므로 보안 위험이 있습니다. 이 위험을 줄이려면 이러한 사용자에게 작업을 수행하는 데 필요한 권한만 제공하고 더 이상 필요하지 않을 경우 이러한 사용자를 제거하는 것이 좋습니다.

**IAM 사용자 생성**

1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) IAM 콘솔을 엽니다.

1. 탐색 창에서 **사용자**를 선택하고 필요한 경우 **사용자 추가**를 선택하여 신규 관리 사용자를 만듭니다.

1. **권한 설정** 페이지에서 **정책을 직접 연결**을 선택합니다.

1. **권한 정책** 검색 상자에 **S3**을 입력하여 Amazon S3 정책을 표시합니다.

   **AmazonS3ReadOnlyAccess**를 선택합니다. 원하는 경우 **AmazonS3FullAccess**와 같이 더 넓은 권한을 부여하는 정책을 지정할 수 있지만 필요한 권한만 부여하는 것이 일반적입니다. 이 경우, 레시피는 파일만 다운로드하므로 읽기 전용 액세스로 충분합니다.

1. **다음**을 선택합니다.

1. **사용자 생성**을 선택합니다.

1. 그다음에 사용자에 대해 액세스 키를 생성합니다. 액세스 키 생성에 대한 자세한 내용은 [IAM 사용 설명서](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)의 *IAM 사용자를 위한 액세스 키 관리*를 참조하세요.

다음에는 다운로드할 파일을 제공해야 합니다. 이 예제에서는 새로 생성된 `myfile.txt`이라는 S3 버킷에 `cookbook_bucket`라는 파일을 저장하는 것으로 가정합니다.

**다운로드할 파일을 제공하려면**

1. 다음 텍스트가 포함된 `myfile.txt` 파일을 만든 다음 워크스테이션의 원하는 위치에 저장합니다.

   ```
   This is the file that you just downloaded from Amazon S3.
   ```

1. [Amazon S3 `cookbook_bucket` 콘솔](https://console.aws.amazon.com/s3/)에서 **표준** 리전에 라는 이름의 버킷을 생성하고 `myfile.txt`를 버킷에 업로드합니다.

다음과 같이 쿡북을 설정합니다.

**쿡북을 설정하려면**

1. `opsworks_cookbooks` 안에 `s3bucket` 하위 디렉터리를 만들고 그 디렉터리로 이동합니다.

1. [예제 1: 패키지 설치](cookbooks-101-basics-packages.md) 단원에서 설명하는 대로 Test Kitchen을 초기화 및 구성합니다.

1. `.kitchen.yml`의 텍스트를 다음으로 바꿉니다.

   ```
   ---
   driver:
     name: vagrant
   
   provisioner:
     name: chef_solo
     environments_path: ./environments
   
   platforms:
     - name: ubuntu-14.04
   
   suites:
     - name: s3bucket
       provisioner:
         solo_rb:
           environment: test
       run_list:
         - recipe[s3bucket::default]
       attributes:
   ```

1. `s3bucket`에 디렉터리 `recipes` 및 `environments`를 추가합니다.

1. 다음 `default_attributes` 섹션을 사용하여 환경 파일 `test.json`을 만들고 사용자에 해당하는 키로 `access_key` 및 `secret_key` 값을 바꿉니다. 쿡북의 `environments` 폴더에 파일을 저장합니다.

   ```
   {
     "default_attributes" : {
       "cookbooks_101" : {
         "access_key": "AKIAIOSFODNN7EXAMPLE",
         "secret_key" : "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
       }
     },
     "chef_type" : "environment",
     "json_class" : "Chef::Environment"
   }
   ```

다양한 방법으로 인스턴스에서 실행되는 레시피에 자격 증명을 제공할 수 있습니다. 중요한 고려 사항은 잘못하여 키가 노출되어 계정 보안이 훼손될 가능성을 제한하는 것입니다. 이를 위해 코드에 명시적 키 값을 사용하는 것은 권장하지 않습니다. 예제에서는 키 값을 노드 객체에 저장합니다. 그러면 레시피가 리터럴 값을 노출하는 대신 노드 구문을 사용하여 참조할 수 있습니다. 노드 객체에 액세스하려면 루트 권한이 있어야 합니다. 이는 키가 노출될 가능성을 제한합니다. 자세한 내용은 [AWS 액세스 키 관리 모범 사례](https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html)를 참조하세요.

**참고**  
이 예제에서는 `cookbooks_101`을 첫 번째 요소로 하는 중첩 속성을 사용합니다. 이 방법은 노드 객체에 다른 `access_key` 또는 `secret_key` 속성이 있을 경우 이름 충돌의 가능성을 줄여줍니다.

다음 레시피는 `myfile.text` 버킷에서 `cookbook_bucket` 파일을 다운로드합니다.

```
gem_package "aws-sdk ~> 3" do
  action :install
end

ruby_block "download-object" do
  block do
    require 'aws-sdk'

    s3 = Aws::S3::Client.new(
          :access_key_id => "#{node['cookbooks_101']['access_key']}",
          :secret_access_key => "#{node['cookbooks_101']['secret_key']}")

    myfile = s3.bucket['cookbook_bucket'].objects['myfile.txt']
    Dir.chdir("/tmp")
    File.open("myfile.txt", "w") do |f|
      f.write(myfile.read)
      f.close
    end
  end
  action :run
end
```

레시피의 첫 번째 부분은 젬 패키지인 SDK for Ruby를 설치합니다. [gem\$1package](https://docs.chef.io/chef/resources.html#gem-package) 리소스는 레시피 또는 다른 애플리케이션에서 사용될 젬을 설치합니다.

**참고**  
사용자의 인스턴스에는 일반적으로 두 개의 Ruby 인스턴스가 있으며, 이 두 개의 인스턴스는 일반적으로 버전이 다릅니다. 하나는 Chef 클라이언트가 사용하는 전용 인스턴스입니다. 다른 하나는 인스턴스에서 실행되는 애플리케이션 및 레시피가 사용합니다. 젬 설치를 위한 리소스는 [gem\$1package](https://docs.chef.io/chef/resources.html#gem-package) 및 [chef\$1gem](https://docs.chef.io/chef/resources.html#chef-gem) 두 개가 있으므로 젬 패키지를 설치할 때 이 구분을 이해하는 것이 중요합니다. 애플리케이션 또는 레시피가 젬 패키지를 사용하는 경우 `gem_package`를 사용하여 젬 패키지를 설치합니다. `chef_gem`은 Chef 클라이언트가 사용하는 젬 패키지에만 사용합니다.

레시피의 나머지 부분은 [ruby\$1block](https://docs.chef.io/chef/resources.html#ruby-block) 리소스입니다. 여기에 파일을 다운로드하는 Ruby 코드가 포함됩니다. 레시피가 Ruby 애플리케이션이기 때문에 코드를 레시피에 직접 배치할 수 있다고 생각할 수 있습니다. 하지만 Chef 실행은 리소스를 실행하기 전에 모든 코드를 컴파일합니다. 예제 코드를 레시피에 직접 배치할 경우, Ruby는 `gem_package` 리소스를 실행하기 전에 `require 'aws-sdk'` 문을 해결하려고 시도합니다. SDK for Ruby가 아직 설치되지 않았으므로 컴파일이 실패합니다.

`ruby_block` 리소스 내 코드는 해당 리소스가 실행될 때까지는 컴파일되지 않습니다. 이 예제에서 `gem_package` 리소스가 SDK for Ruby 설치를 마친 후에 `ruby_block` 리소스가 실행됩니다. 그러므로 코드가 성공적으로 실행될 것입니다.

`ruby_block` 내 코드는 다음과 같이 작동합니다.

1. 새 [https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/S3.html](https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/S3.html) 객체를 생성합니다. 이 객체는 서비스 인터페이스를 제공합니다.

   액세스 키와 보안 키는 노드 객체에 저장된 값 단원을 참조하여 지정됩니다.

1. `S3` 객체의 `bucket.objects` 연결을 호출하여 이를 `myfile.txt`을 나타내는 `myfile` 이름의 [https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/S3/Object.html](https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/S3/Object.html) 객체를 반환합니다.

1. `Dir.chdir`을 사용하여 작업 디렉터리를 `/tmp`로 설정합니다.

1. `myfile.txt` 파일을 열고, 파일에 `myfile`을 기록하고, 파일을 닫습니다.

**레시피를 실행하려면**

1. 예제 레시피가 포함된 `default.rb` 파일을 만들어 `recipes` 디렉터리에 저장합니다.

1. `kitchen converge`를 실행합니다.

1. `kitchen login`을 실행하여 인스턴스에 로그인한 다음, `ls /tmp`를 실행합니다. 여러 Test Kitchen 파일 및 디렉터리와 함께 `myfile.txt`가 있어야 합니다.

   ```
   vagrant@s3bucket-ubuntu-1204:~$ ls /tmp
   install.sh  kitchen  myfile.txt  stderr
   ```

   또한 `cat /tmp/myfile.txt`를 실행하여 파일의 내용이 올바른지 확인할 수 있습니다.

다 마치면 `kitchen destroy`를 실행해 인스턴스를 종료하세요.

# OpsWorks Stacks Linux 인스턴스에서 SDK for Ruby 사용
<a name="cookbooks-101-opsworks-s3-opsworks"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

이 주제에서는 OpsWorks Stacks Linux 인스턴스에서 SDK for Ruby를 사용하여 Amazon S3 버킷에서 파일을 다운로드하는 방법을 설명합니다. OpsWorks Stacks는 모든 Linux 인스턴스에 SDK for Ruby를 자동으로 설치합니다. 하지만 서비스의 클라이언트 객체를 생성할 때는 적절한 AWS 자격 증명 `AWS::S3.new`(또는 다른 서비스의 동등한 값)를 제공해야 합니다.

Amazon S3 버킷에 전달한 콘텐츠에는 고객 콘텐츠가 포함될 수 있습니다. 중요 데이터 제거에 관한 자세한 내용은 [S3 버킷을 비우려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html) 단원 또는 [S3 버킷을 삭제하려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html) 단원을 참조하세요.

 [Vagrant 인스턴스에서 SDK for Ruby 사용](cookbooks-101-opsworks-s3-vagrant.md) 섹션은 노드 객체에 자격 증명을 저장하고 레시피 코드에서 속성 단원을 참조하는 식으로 자격 증명 노출 위험을 완화하는 방법을 보여줍니다. Amazon EC2 인스턴스에서 레시피를 실행하는 경우 [IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)이라는 훨씬 더 좋은 옵션을 사용할 수 있습니다.

IAM 역할은 IAM 사용자와 거의 비슷하게 작동합니다. 여기에는 다양한 AWS 서비스를 사용할 수 있는 권한을 부여하는 정책이 연결됩니다. 하지만 역할은 개인이 아니라 Amazon EC2 인스턴스에 할당합니다. 그러면 이 인스턴스에서 실행되는 애플리케이션은 연결된 정책이 부여하는 권한을 획득할 수 있습니다. 역할을 사용하면 자격 증명이 간접적으로라도 코드에 표시되지 않습니다. 이 주제에서는 IAM 역할을 사용하여 Amazon EC2 인스턴스에서 [Vagrant 인스턴스에서 SDK for Ruby 사용](cookbooks-101-opsworks-s3-vagrant.md)의 레시피를 실행하는 방법을 설명합니다.

[예제 9: Amazon EC2 인스턴스 사용](cookbooks-101-basics-ec2.md) 색션에 설명된 대로 kitchen-ec2 드라이버를 사용하여 이 레시피를 Test Kitchen과 함께 실행할 수 있습니다. 하지만 SDK for Ruby를 Amazon EC2 인스턴스에 설치하는 것은 다소 복잡하며 OpsWorks Stacks에 대해 걱정할 필요가 없습니다. 모든 OpsWorks Stacks Linux 인스턴스에는 기본적으로 SDK for Ruby가 설치되어 있습니다. 따라서 간소화를 위해이 예제에서는 OpsWorks Stacks 인스턴스를 사용합니다.

첫 번째 단계는 IAM 역할을 설정하는 것입니다. 이 예제에서는 첫 번째 스택을 생성할 때 OpsWorks Stacks가 생성하는 Amazon EC2 역할을 사용하는 가장 간단한 접근 방식을 취합니다. 이 역할은 `aws-opsworks-ec2-role`로 명명됩니다. 그러나 OpsWorks Stacks는 정책을 해당 역할에 연결하지 않으므로 기본적으로 권한을 부여하지 않습니다.

적절한 권한을 부여하려면 `AmazonS3ReadOnlyAccess` 정책을 `aws-opsworks-ec2-role` 역할에 연결해야 합니다. 정책을 역할에 연결하는 방법에 대한 자세한 내용은 *IAM 사용 설명서*의 [IAM 자격 증명 권한 추가(콘솔)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console)를 참조하세요.

스택을 생성하거나 업데이트할 때 역할을 지정합니다. [Linux 인스턴스에서 레시피 실행](cookbooks-101-opsworks-opsworks-instance.md) 섹션에 설명된 대로 사용자 지정 계층을 포함하는 스택을 설정하되 한 가지를 추가합니다. **스택 추가** 페이지에서 **기본 IAM 인스턴스 프로파일**이 **aws-opsworks-ec2-role**로 설정되어 있는지 확인합니다. 그러면 OpsWorks 스택이 스택의 모든 인스턴스에 해당 역할을 할당합니다.

쿡북을 설정하는 절차는 [Linux 인스턴스에서 레시피 실행](cookbooks-101-opsworks-opsworks-instance.md) 섹션에서 사용한 것과 비슷합니다. 다음은 간략한 요약이며, 자세한 정보는 해당 예제를 참조해야 합니다.

**쿡북을 설정하려면**

1. `s3bucket_ops` 하위 디렉터리를 만들고 그 디렉터리로 이동합니다.

1. 다음 내용이 포함된 `metadata.rb` 파일을 만들어 `s3bucket_ops`에 저장합니다.

   ```
   name "s3bucket_ops"
   version "0.1.0"
   ```

1. `recipes` 안에 `s3bucket_ops` 디렉터리를 만듭니다.

1. 다음 레시피가 포함된 `default.rb` 파일을 만들어 `recipes` 디렉터리에 저장합니다.

   ```
   Chef::Log.info("******Downloading a file from Amazon S3.******")
   
   ruby_block "download-object" do
     block do
       require 'aws-sdk'
   
       s3 = AWS::S3.new
   
       myfile = s3.buckets['cookbook_bucket'].objects['myfile.txt']
       Dir.chdir("/tmp")
       File.open("myfile.txt", "w") do |f|
         f.syswrite(myfile.read)
         f.close
       end
     end
     action :run
   end
   ```

1. `s3bucket_ops`의 `.zip` 아카이브를 만들고 그 아카이브를 Amazon S3 버킷에 업로드합니다. 간단한 설명을 위해 [아카이브를 퍼블릭으로 설정](https://docs.aws.amazon.com/AmazonS3/latest/UG/EditingPermissionsonanObject.html)한 다음 나중에 사용하기 위해 아카이브의 URL을 적어 둡니다. 프라이빗 Amazon S3 아카이브 또는 기타 여러 가지 리포지토리 유형에 쿡북을 저장할 수도 있습니다. 자세한 내용은 [쿡북 리포지토리](workingcookbook-installingcustom-repo.md) 섹션을 참조하세요.

이 레시피는 다음을 제외하면 이전 예제에서 사용된 것과 비슷합니다.
+  OpsWorks Stacks가 이미 SDK for Ruby를 설치했으므로 `chef_gem` 리소스가 삭제되었습니다.
+ 레시피가 `AWS::S3.new`로 자격 증명을 전달하지 않습니다.

  자격 증명이 인스턴스의 역할에 따라 자동으로 애플리케이션에 할당됩니다.
+ 레시피는 `Chef::Log.info`를 사용하여 Chef 로그에 메시지를 추가합니다.

다음과 같이 이 예제를 위한 스택을 생성합니다. 기존의 Windows 스택을 사용할 수 있습니다. 나중에 설명하듯이 쿡북을 업데이트하면 됩니다.

**스택 생성**

1. [OpsWorks Stacks 콘솔](https://console.aws.amazon.com/opsworks/)을 열고 **스택 추가**를 클릭합니다.

1. 다음 설정을 지정하고, 그 외 설정에 대해서는 기본값을 수락한 다음 [**스택 추가**]를 클릭합니다.
   + **이름** – RubySDK
   + **기본 SSH 키** – Amazon EC2 키 페어

   Amazon EC2 키 페어를 생성해야 하는 경우 [Amazon EC2 키 페어](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)를 참조하세요. 키 페어는 인스턴스와 동일한 AWS 리전에 속해야 합니다. 이 예에서는 기본 미국 서부(오레곤) 리전을 사용합니다.

1. [**계층 추가**]를 클릭하여 스택에 다음 설정으로 [사용자 지정 계층을 추가](workinglayers-custom.md)합니다.
   + **이름** – S3Download
   + **짧은 이름** - s3download

   모든 계층 유형이 실제로 Linux 스택에서 작동하지만 이 예제에서는 다른 계층 유형에서 설치한 패키지가 필요하지 않기 때문에 사용자 지정 계층을 사용하는 것이 가장 간단합니다.

1. 기본 설정을 사용하여 계층에 [24/7 인스턴스를 추가](workinginstances-add.md)하고 [해당 인스턴스를 시작](workinginstances-starting.md)합니다.

이제 레시피를 설치하고 실행할 수 있습니다.

**레시피를 실행하려면**

1. [스택을 편집해 사용자 지정 쿡북을 활성화](workingcookbook-installingcustom-enable.md)하고 다음 설정을 지정합니다.
   + **리포지토리 유형** – **Http Archive**
   + **리포지토리 URL** - 앞에서 기록해 둔 쿡북 아카이브 URL

   기타 설정에 기본값을 사용하고 [**저장**]을 클릭하여 스택 구성을 업데이트합니다.

1. [사용자 지정 쿡북 업데이트 스택 명령을 실행](workingstacks-commands.md)하여 스택의 인스턴스에 사용자 지정 쿡북의 최신 버전을 설치합니다. 쿡북의 이전 버전이 있으면 이 명령이 이전 버전을 덮어 씁니다.

1. **실행할 레시피**가 **s3bucket\$1ops::default**으로 설정된 상태에서 **레시피 실행** 스택 명령을 실행하여 레시피를 실행합니다. 이 명령은 `s3bucket_ops::default`로 구성된 실행 목록을 사용하여 Chef 실행을 시작합니다.
**참고**  
일반적으로 OpsWorks Stacks가 레시피를 적절한 수명 주기 이벤트에 할당하여 레시피를 [자동으로 실행하도록 합니다](workingcookbook-assigningcustom.md). 수동으로 이벤트를 트리거하여 그러한 레시피를 실행할 수 있습니다. 스택 명령을 사용하여 설정 및 Configure 이벤트를 트리거할 수 있고, [배포 명령](workingapps-deploying.md)을 사용하여 Deploy 및 Undeploy 이벤트를 트리거할 수 있습니다.

레시피가 성공적으로 실행되면 이를 확인할 수 있습니다.

**s3bucket\$1ops를 확인하려면**

1. 가장 먼저 Chef 로그를 확인합니다. 스택에는 opstest1이라는 인스턴스가 하나 있어야 합니다. **인스턴스** 페이지에서 인스턴스의 **로그** 열에 있는 **표시**를 클릭하여 Chef 로그를 표시합니다. 아래로 스크롤하면 맨 아래 근처에 로그 메시지가 보입니다.

   ```
   ...
   [2014-07-31T17:01:45+00:00] INFO: Storing updated cookbooks/opsworks_cleanup/attributes/customize.rb in the cache.
   [2014-07-31T17:01:45+00:00] INFO: Storing updated cookbooks/opsworks_cleanup/metadata.rb in the cache.
   [2014-07-31T17:01:46+00:00] INFO: ******Downloading a file from Amazon S3.******
   [2014-07-31T17:01:46+00:00] INFO: Processing template[/etc/hosts] action create (opsworks_stack_state_sync::hosts line 3)
   ...
   ```

1. [SSH를 사용하여 인스턴스에 로그인](workinginstances-ssh.md)하고 `/tmp`의 내용을 표시합니다.

# OpsWorks Stacks Windows 인스턴스에서 SDK for Ruby 사용
<a name="cookbooks-101-opsworks-s3-windows"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이 예제에서는 사용자가 이미 [Windows 인스턴스에서 레시피 실행](cookbooks-101-opsworks-opsworks-windows.md) 예제를 완료한 것으로 가정합니다. 그렇지 않은 경우 먼저 그 예제를 수행해야 합니다. 특히, 그 예제는 인스턴스에 대한 RDP 액세스를 활성화하는 방법을 설명합니다.  
Amazon S3 버킷에 전달한 콘텐츠에는 고객 콘텐츠가 포함될 수 있습니다. 중요 데이터 제거에 관한 자세한 내용은 [S3 버킷을 비우려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html) 또는 [S3 버킷을 삭제하려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html)를 참조하세요.

이 주제에서는 OpsWorks Stacks Windows 인스턴스[AWS SDK for Ruby](https://docs.aws.amazon.com/sdk-for-ruby/v3/api/)에서를 사용하여 S3 버킷에서 파일을 다운로드하는 방법을 설명합니다.

Ruby 애플리케이션이 AWS 리소스에 액세스해야 하는 경우 적절한 권한을 가진 AWS 자격 증명을 제공해야 합니다. 레시피의 경우 AWS 자격 증명을 제공하는 가장 좋은 방법은 AWS Identity and Access Management ([IAM) 역할을](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) 사용하는 것입니다. IAM 역할은 IAM 사용자처럼 작동하며 다양한 AWS 서비스를 사용할 수 있는 권한을 부여하는 정책이 연결되어 있습니다. 하지만 역할은 개인이 아니라 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에 할당합니다. 그러면 이 인스턴스에서 실행되는 애플리케이션은 연결된 정책이 부여하는 권한을 획득할 수 있습니다. 역할을 사용하면 자격 증명이 간접적으로라도 코드에 표시되지 않습니다.

첫 번째 단계는 IAM 역할을 설정하는 것입니다. 이 예제에서는 첫 번째 스택을 생성할 때 OpsWorks Stacks가 생성하는 Amazon EC2 역할을 사용하는 가장 간단한 접근 방식을 취합니다. 이 역할은 `aws-opsworks-ec2-role`로 명명됩니다. 그러나 OpsWorks Stacks는 정책을 해당 역할에 연결하지 않으므로 기본적으로 권한을 부여하지 않습니다.

적절한 권한을 부여하려면 `AmazonS3ReadOnlyAccess` 정책을 `aws-opsworks-ec2-role` 역할에 연결해야 합니다. 정책을 역할에 연결하는 방법에 대한 자세한 내용은 *IAM 사용 설명서*의 [IAM 자격 증명 권한 추가(콘솔)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console)를 참조하세요.

스택을 생성하거나 업데이트할 때 역할을 지정합니다. [Windows 인스턴스에서 레시피 실행](cookbooks-101-opsworks-opsworks-windows.md) 섹션에 설명된 대로 사용자 지정 계층을 포함하는 스택을 설정하되 한 가지를 추가합니다. **스택 추가** 페이지에서 **기본 IAM 인스턴스 프로파일**이 **aws-opsworks-ec2-role**로 설정되어 있는지 확인합니다. 그러면 OpsWorks 스택이 스택의 모든 인스턴스에 해당 역할을 할당합니다.

쿡북을 설정하는 절차는 [Linux 인스턴스에서 레시피 실행](cookbooks-101-opsworks-opsworks-instance.md) 섹션에서 사용한 것과 비슷합니다. 다음은 간략한 요약이며, 자세한 정보는 해당 예제를 참조하세요.

**쿡북을 설정하려면**

1. `s3bucket_ops` 하위 디렉터리를 만들고 그 디렉터리로 이동합니다.

1. 다음 내용이 포함된 `metadata.rb` 파일을 만들어 `s3bucket_ops`에 저장합니다.

   ```
   name "s3download"
   version "0.1.0"
   ```

1. `recipes` 안에 `s3download` 디렉터리를 만듭니다.

1. 다음 레시피가 포함된 `default.rb` 파일을 만들어 `recipes` 디렉터리에 저장합니다. *windows-cookbooks*를 다운로드할 파일을 저장하는 데 사용할 S3 버킷의 이름으로 바꿉니다.

   ```
   Chef::Log.info("******Downloading an object from S3******")
   
   chef_gem "aws-sdk-s3" do
     compile_time false
     action :install
   end
   
   ruby_block "download-object" do
     block do
       require 'aws-sdk-s3'
       
       Aws.use_bundled_cert!
   
       s3_client = Aws::S3::Client.new(region:'us-west-2')
   
       s3_client.get_object(bucket: 'windows-cookbooks',
                        key: 'myfile.txt',
                        response_target: '/chef/myfile.txt')
     end
     action :run
   end
   ```

1. `s3download`의 `.zip` 아카이브를 만들어 이 파일을 S3 버킷에 업로드합니다. 이 파일을 퍼블릭으로 설정하고 나중에 사용하기 위해 URL을 적어 둡니다.

1. `myfile.txt`라는 텍스트 파일을 만들어 이 파일을 S3 버킷에 업로드합니다. 이 파일은 레시피에서 다운로드할 파일이므로 편리한 버킷은 어느 것이든 사용할 수 있습니다.

이 레시피가 수행하는 작업은 다음과 같습니다.

1: SDK for Ruby v2 설치  
이 예에서는 SDK for Ruby를 이용하여 객체를 다운로드합니다. 그러나 OpsWorks Stacks는 Windows 인스턴스에이 SDK를 설치하지 않으므로 레시피의 첫 번째 부분은 [https://docs.chef.io/chef/resources.html#chef-gem](https://docs.chef.io/chef/resources.html#chef-gem) 리소스를 사용하여 해당 작업을 처리합니다. 사용자는 이 리소스를 사용하여 레시피를 포함하여 Chef가 사용하는 젬을 설치합니다.

2: 파일을 다운로드합니다.  
레시피의 세 번째 부분은 [https://docs.chef.io/chef/resources.html#ruby-block](https://docs.chef.io/chef/resources.html#ruby-block) 리소스를 사용하여 `windows-cookbooks`라는 이름의 S3 버킷 에서 인스턴스의 `/chef` 디렉터리로 `myfile.txt`을 다운로드하는 SDK for Rub v2 코드를 실행합니다. `windows-cookbooks`를 `myfile.txt`가 저장된 버킷의 이름으로 변경합니다.

**참고**  
레시피는 Ruby 애플리케이션입니다. 따라서 Ruby 코드를 레시피 본문에 배치할 수 있습니다. 코드가 반드시 `ruby_block` 리소스에 위치할 필요는 없습니다. 하지만 Chef는 Ruby 코드를 레시피 본문부터 실행한 다음 각 리소스를 순서대로 실행합니다. 이 예제에서는 다운로드 코드를 레시피 본문에 배치할 경우 코드가 실패합니다. 이 코드는 SDK for Ruby에 의존하는데 SDK를 설치하는 `chef_gem` 리소스가 아직 실행되지 않았기 때문입니다. 리소스가 실행될 때 `ruby_block` 리소스 내 코드가 실행되며, 이는 `chef_gem` 리소스가 SDK for Ruby를 설치한 후에 이루어집니다.

다음과 같이 이 예제를 위한 스택을 생성합니다. 기존의 Windows 스택을 사용할 수 있습니다. 나중에 설명하듯이 쿡북을 업데이트하면 됩니다.

**스택을 만듭니다**

1. [OpsWorks Stacks 콘솔](https://console.aws.amazon.com/opsworks/)을 열고 **스택 추가**를 선택합니다. 다음 설정을 지정하고, 그 외 설정에 대해서는 기본값을 수락한 다음 [**스택 추가**]를 선택합니다.
   + **이름** – S3Download
   + **리전** – 미국 서부(오레곤)

     이 예제는 모든 리전에서 작동하지만 자습서의 경우 미국 서부(오레곤)를 사용하는 것이 좋습니다.
   + **기본 운영 체제** - Microsoft Windows Server 2012 R2

1. [**계층 추가**]를 선택하여 스택에 다음 설정으로 [사용자 지정 계층을 추가](workinglayers-custom.md)합니다.
   + **이름** – S3Download
   + **짧은 이름** - s3download

1. 기본 설정을 사용하여 S3Download 계층에 [24/7 인스턴스를 추가](workinginstances-add.md)하고 [해당 인스턴스를 시작](workinginstances-starting.md)합니다.

이제 레시피를 설치하고 실행할 수 있습니다.

**레시피를 실행하려면**

1. [스택을 편집해 사용자 지정 쿡북을 활성화](workingcookbook-installingcustom-enable.md)하고 다음 설정을 지정합니다.
   + **리포지토리 유형** – **S3 아카이브**
   + **리포지토리 URL** - 앞에서 기록해 둔 쿡북 아카이브 URL

   기타 설정에 대해 기본값을 수락하고 [**저장**]을 선택하여 스택 구성을 업데이트합니다.

1. [사용자 지정 쿡북 업데이트 스택 명령을 실행](workingstacks-commands.md)하여 스택의 온라인 인스턴스에 사용자 지정 쿡북의 최신 버전을 설치합니다. 쿡북의 이전 버전이 있으면 이 명령이 이전 버전을 덮어 씁니다.

1. **실행할 레시피**가 **s3download::default**으로 설정된 상태에서 **레시피 실행** 스택 명령을 실행하여 레시피를 실행합니다. 이 명령은 `s3download::default`로 구성된 실행 목록을 사용하여 Chef 실행을 시작합니다.
**참고**  
일반적으로 OpsWorks Stacks가 레시피를 적절한 수명 주기 이벤트에 할당하여 레시피를 [자동으로 실행하도록 합니다](workingcookbook-assigningcustom.md). 수동으로 이벤트를 트리거하여 그러한 레시피를 실행할 수도 있습니다. 스택 명령을 사용하여 설정 및 Configure 이벤트를 트리거할 수 있고, [배포 명령](workingapps-deploying.md)을 사용하여 Deploy 및 Undeploy 이벤트를 트리거할 수 있습니다.

레시피가 성공적으로 실행되면 이를 확인할 수 있습니다.

**s3download를 확인하려면**

1. 가장 먼저 Chef 로그를 확인합니다. 스택에는 s3download1이라는 인스턴스가 하나 있어야 합니다. **인스턴스** 페이지에서 인스턴스의 **로그** 열에서 **표시**를 선택하여 Chef 로그를 표시합니다. 아래로 스크롤하면 맨 아래 근처에 로그 메시지가 보입니다.

   ```
   ...
   [2015-05-01T21:11:04+00:00] INFO: Loading cookbooks [s3download@0.0.0]
   [2015-05-01T21:11:04+00:00] INFO: Storing updated cookbooks/s3download/recipes/default.rb in the cache.
   [2015-05-01T21:11:04+00:00] INFO: ******Downloading an object from S3******
   [2015-05-01T21:11:04+00:00] INFO: Processing chef_gem[aws-sdk] action install (s3download::default line 3)
   [2015-05-01T21:11:05+00:00] INFO: Processing ruby_block[download-object] action run (s3download::default line 8) 
   ...
   ```

1. [RDP를 사용하여 인스턴스에 로그인](workinginstances-rdp.md)하고 `c:\chef`의 내용을 확인합니다.

# Windows 소프트웨어 설치
<a name="cookbooks-101-opsworks-install-software"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
다음 예제에서는 사용자가 이미 [Windows 인스턴스에서 레시피 실행](cookbooks-101-opsworks-opsworks-windows.md) 예제를 완료한 것으로 가정합니다. 그렇지 않은 경우 먼저 그 예제를 수행해야 합니다. 특히, 그 예제는 인스턴스에 대한 RDP 액세스를 활성화하는 방법을 설명합니다.

 Windows 인스턴스는 Windows Server 2012 R2 Standard를 사용하여 시작하므로, 대개 일부 소프트웨어를 설치해야 합니다. 세부 정보는 소프트웨어 유형에 따라 다릅니다.
+  Windows 기능은 .NET 프레임워크 및 인터넷 정보 서비스(IIS)를 비롯한 선택적 시스템 구성 요소이며 인스턴스로 다운로드할 수 있습니다.
+ 타사 소프트웨어는 일반적으로 MSI 파일과 같은 설치 프로그램 관리자로 제공됩니다. 이 패키지를 인스턴스로 다운로드하여 실행해야 합니다.

  일부 Microsoft 소프트웨어도 설치 프로그램 패키지로 제공됩니다.

이 섹션에서는 Windows 기능 및 패키지를 설치하는 쿡북을 구현하는 방법을 설명합니다. 또한 Windows 인스턴스용 레시피 구현을 간소화하는 리소스 및 헬퍼 기능을 포함하는 Chef windows 쿡북도 소개합니다.

**Topics**
+ [Windows 기능 설치: IIS](cookbooks-101-opsworks-install-software-feature.md)
+ [Windows 인스턴스에 패키지 설치](cookbooks-101-opsworks-install-software-package.md)

# Windows 기능 설치: IIS
<a name="cookbooks-101-opsworks-install-software-feature"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

 Windows 기능은 .NET 프레임워크 및 인터넷 정보 서비스(IIS)를 비롯한 일련의 선택적 시스템 구성 요소입니다. 이 주제에서는 일반적으로 사용되는 기능인 인터넷 정보 서비스(IIS)를 설치하는 쿡북을 구현하는 방법을 설명합니다.

**참고**  
[패키지 설치](cookbooks-101-opsworks-install-software-package.md) 섹션은 MSI 파일과 같은 설치 프로그램 관리자로 제공되는 소프트웨어를 설치하는 방법을 보여줍니다. 이러한 패키지는 인스턴스로 다운로드하여 실행해야 합니다. [IIS 쿡북](https://github.com/opscode-cookbooks/iis) 

[Windows 인스턴스에서 레시피 실행](cookbooks-101-opsworks-opsworks-windows.md) 섹션은`powershell_script` 리소스를 사용하여 Windows 기능을 설치하는 방법을 보여줍니다. 이 예제는 Chef [Windows 쿡북의](https://github.com/opscode-cookbooks/windows) `windows_feature` 리소스를 사용하는 대안적 방법을 보여줍니다. 이 쿡북에는 [Deployment Image Servicing and Management](https://technet.microsoft.com/en-us/library/dd744256%28v=ws.10%29.aspx)를 사용하여 기능 설치를 비롯한 다양한 Windows 작업을 수행하는 일련의 리소스가 포함되어 있습니다.

**참고**  
Chef에도 IIS를 관리하는 데 사용할 수 있는 IIS 쿡북이 있습니다. 자세한 정보는 [IIS cookbook](https://github.com/opscode-cookbooks/iis) 단원을 참조하세요.

**쿡북을 설정하려면**

1. [windows cookbook GitHub 리포지토리](https://github.com/opscode-cookbooks/windows)로 이동한 다음 `windows` 쿡북을 다운로드합니다.

   이 예제에서는 `windows` 리포지토리를 .zip 파일로 다운로드한다고 가정하지만 원하는 경우 이 리포지토리를 복제할 수도 있습니다.

1. [chef\$1handler cookbook GitHub 리포지토리](https://github.com/opscode-cookbooks/chef_handler)로 이동한 다음 `chef-handler` 쿡북을 다운로드합니다.

   `windows` 쿡북은 `chef_handler`에 따라 달라지므로 이 쿡북을 직접 사용하지는 않습니다. 이 예제에서는 `chef_handler` 리포지토리를 .zip 파일로 다운로드한다고 가정하지만 원하는 경우 이 리포지토리를 복제할 수도 있습니다.

1. `windows` 및 `chef_handler` 쿡북을 쿡북 디렉터리 `windows` 및 `chef_handler`에 각각 추출합니다.

1. 쿡북 디렉터리 `install-iis` 안에 디렉터리를 만들고 그 디렉터리로 이동합니다.

1. `install-iis`에 다음 콘텐츠가 포함된 `metadata.rb` 파일을 추가합니다.

   ```
   name "install-iis"
   version "0.1.0"
   
   depends "windows"
   ```

   `depends` 명령을 사용하면 레시피에서 `windows` 쿡북 리소스를 사용할 수 있습니다.

1. `recipes`에 `install-iis` 디렉터리를 추가하고 다음 레시피 코드가 포함된 `default.rb` 파일을 이 디렉터리에 추가합니다.

   ```
   %w{ IIS-WebServerRole IIS-WebServer }.each do |feature|
     windows_feature feature do
       action :install
     end
   end
   
   service 'w3svc' do
     action [:start, :enable]
   end
   ```

   레시피에서는 `windows` 쿡북의 `windows_feature` 리소스를 사용하여 다음을 설치합니다.

   1. The [IIS 웹 서버 역할](https://technet.microsoft.com/en-us/library/cc770634.aspx).

   1. The [IIS 웹 서버](https://technet.microsoft.com/en-us/library/cc753433%28v=ws.10%29.aspx).

   그런 다음 레시피에서는 [https://docs.chef.io/chef/resources.html#service](https://docs.chef.io/chef/resources.html#service) 리소스를 사용하여 IIS 서비스(W3SVC)를 시작 및 활성화합니다.
**참고**  
사용 가능한 Windows 기능의 전체 목록을 확인하려면 [RDP를 사용하여 인스턴스에 로그인](workinginstances-rdp.md)해 명령 프롬프트 창을 열고 다음 명령을 실행합니다. 이 목록은 상당히 깁니다.  

   ```
   dism /online /Get-Features
   ```

1. `install-iis`, `chef_handler` 및 `windows` 쿡북이 포함된 `.zip` 아카이브를 만들어 S3 버킷에 업로드합니다. 이 아카이브를 퍼블릭으로 설정하고 나중에 사용하기 위해 URL을 적어 둡니다. 이 예제에서는 이 아카이브의 이름을 `install-iis.zip`이라고 가정합니다. 자세한 내용은 [쿡북 리포지토리](workingcookbook-installingcustom-repo.md) 섹션을 참조하세요.

   Amazon S3 버킷에 전달한 콘텐츠에는 고객 콘텐츠가 포함될 수 있습니다. 중요 데이터 제거에 관한 자세한 내용은 [S3 버킷을 비우려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html) 단원 또는 [S3 버킷을 삭제하려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html) 단원을 참조하세요.

다음과 같이 이 예제를 위한 스택을 생성합니다. 기존의 Windows 스택을 사용할 수도 있습니다. 나중에 설명하듯이 쿡북을 업데이트하면 됩니다.

**스택을 만듭니다**

1. [OpsWorks Stacks 콘솔](https://console.aws.amazon.com/opsworks/)을 열고 **스택 추가**를 선택합니다. 다음 설정을 지정하고, 그 외 설정에 대해서는 기본값을 수락한 다음 [**스택 추가**]를 선택합니다.
   + **이름** – InstallIIS
   + **리전** – 미국 서부(오레곤)

     이 예제는 모든 리전에서 작동하지만 자습서의 경우 미국 서부(오레곤)를 사용하는 것이 좋습니다.
   + **기본 운영 체제** - Microsoft Windows Server 2012 R2

1. [**계층 추가**]를 선택하여 스택에 다음 설정으로 [사용자 지정 계층을 추가](workinglayers-custom.md)합니다.
   + **이름** - IIS
   + **짧은 이름** - iis

1. 기본 설정을 사용하여 IIS 계층에 [24/7 인스턴스를 추가](workinginstances-add.md)하고 [해당 인스턴스를 시작](workinginstances-starting.md)합니다.

이제 쿡북을 설치하고 레시피를 실행할 수 있습니다.

**쿡북을 설치하고 레시피를 실행하려면**

1. [스택을 편집해 사용자 지정 쿡북을 활성화](workingcookbook-installingcustom-enable.md)하고 다음 설정을 지정합니다.
   + **리포지토리 유형** – **S3 아카이브**
   + **리포지토리 URL** – 앞에서 기록해 둔 쿡북 아카이브 URL

   기타 설정에 대해 기본값을 수락하고 [**저장**]을 선택하여 스택 구성을 업데이트합니다.

1. [[**사용자 지정 쿡북 업데이트**] 스택 명령을 실행](workingstacks-commands.md)하여 스택의 온라인 인스턴스에 사용자 지정 쿡북의 최신 버전을 설치합니다. 쿡북의 이전 버전이 있으면 이 명령이 이전 버전을 덮어 씁니다.

1. **실행할 레시피**가 **install-iis::default**으로 설정된 상태에서 **레시피 실행** 스택 명령을 실행하여 레시피를 실행합니다. 이 명령은 지정한 레시피를 실행하는 Chef 실행을 시작합니다.
**참고**  
이 예제에서는 편의상 **레시피 실행**을 사용하지만 일반적으로 OpsWorks Stacks가 레시피를 적절한 수명 주기 이벤트에 할당하여 [레시피를 자동으로 실행](workingcookbook-assigningcustom.md)하도록 합니다. 수동으로 이벤트를 트리거하여 그러한 레시피를 실행할 수 있습니다. 스택 명령을 사용하여 설정 및 Configure 이벤트를 트리거할 수 있고, [배포 명령](workingapps-deploying.md)을 사용하여 Deploy 및 Undeploy 이벤트를 트리거할 수 있습니다.

1. 설치를 확인하려면 [RDP를 사용하여 인스턴스에 연결](workinginstances-rdp.md)한 다음 Windows 탐색기를 엽니다. 이제 파일 시스템에 `C:\inetpub` 디렉터리가 있을 것입니다. 관리 도구 제어판 애플리케이션에서 서비스 목록을 확인하는 경우 IIS는 맨 아래 근처에 있습니다. 그러나 이름이 IIS가 아니라 World Wide Web Publishing Service로 표시됩니다.

# Windows 인스턴스에 패키지 설치
<a name="cookbooks-101-opsworks-install-software-package"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이 예제에서는 사용자가 이미 [Windows 인스턴스에서 레시피 실행](cookbooks-101-opsworks-opsworks-windows.md) 예제를 완료한 것으로 가정합니다. 그렇지 않은 경우 먼저 그 예제를 수행해야 합니다. 특히, 그 예제는 인스턴스에 대한 RDP 액세스를 활성화하는 방법을 설명합니다.

소프트웨어가 MSI와 같은 설치 프로그램 관리자로 제공될 경우 파일을 인스턴스로 다운로드하여 실행해야 합니다. 이 예제는 연결된 환경 변수를 정의하는 방법을 포함하여 MSI 패키지 형태의 Python 런타임을 설치하는 쿡북을 구현하는 방법을 보여줍니다. IIS와 같은 Windows 기능을 설치하는 방법에 대한 자세한 정보는 [Windows 기능 설치: IIS](cookbooks-101-opsworks-install-software-feature.md) 단원을 참조하세요.

**쿡북을 설정하려면**

1. `installpython` 하위 디렉터리를 만들고 그 디렉터리로 이동합니다.

1. `installpython`에 다음 콘텐츠가 포함된 `metadata.rb` 파일을 추가합니다.

   ```
   name "installpython"
   version "0.1.0"
   ```

1. `installpython`에 `recipes` 및 `files` 디렉터리를 추가하고 파일에 `default` 디렉터리를 추가합니다.

1. [Windows용 Python 버전](https://www.python.org/downloads/windows/)에서 쿡북의 `files\default` 디렉터리로 Python 패키지를 다운로드합니다. 이 예제에서는 `python-3.4.3.amd64.msi`라는 MSI 설치 관리자를 사용하는 Python 3.5.0a3의 Windows x86-64 버전을 설치합니다.

1. 다음 레시피 코드가 포함된 `default.rb` 파일을 `recipes` 디렉터리에 추가합니다.

   ```
   directory 'C:\tmp' do
     rights :full_control, 'Everyone'
     recursive true
     action :create
   end
   
   cookbook_file 'C:\tmp\python-3.4.3.amd64.msi' do
     source "python-3.4.3.amd64.msi"
     rights :full_control, 'Everyone'
     action :create
   end
   
   windows_package 'python' do
     source 'C:\tmp\python-3.4.3.amd64.msi'
     action :install
   end
   
   env "PATH" do
     value 'c:\python34'
     delim ";"
     action :modify
   end
   ```

   이 레시피는 다음 작업을 수행합니다.

   1. [디렉터리](https://docs.chef.io/chef/resources.html#directory) 리소스를 사용하여 `C:\tmp` 디렉터리를 만듭니다.

      이 리소스에 대한 자세한 정보는 [예제 3: 디렉터리 생성](cookbooks-101-basics-directories.md) 단원을 참조하세요.

   1. [cookbook\$1file](https://docs.chef.io/chef/resources.html#cookbook-file) 리소스를 사용하여 쿡북의 `files\default` 디렉터리에서 `C:\tmp`로 설치 관리자를 복사합니다.

      이 리소스에 대한 자세한 정보는 [쿡북에서 파일 설치](cookbooks-101-basics-files.md#cookbooks-101-basics-files-cookbook_file) 단원을 참조하세요.

   1. [windows\$1package](https://docs.chef.io/chef/resources.html#windows-package) 리소스를 사용하여 `c:\python34`에 Python을 설치하는 MSI 설치 관리자를 실행합니다.

      이 설치 관리자는 필수 디렉터리를 만들고 파일을 설치하지만 시스템의 `PATH` 환경 변수를 수정하지는 않습니다.

   1. [env](https://docs.chef.io/chef/resources.html#env) 리소스를 사용하여 시스템 경로에 `c:\python34`를 추가합니다.

      env 리소스를 사용하여 환경 변수를 정의합니다. 이 경우, 레시피를 사용하면 경로에 `c:\python34`를 추가하여 명령줄에서 Python 스크립트를 쉽게 실행할 수 있습니다.
      + 리소스 이름은 이 예제에 필요한 환경 변수의 이름인 `PATH`를 지정합니다.
      + `value` 특성은 이 예제에 필요한 변수 값 `c:\\python34`를 지정합니다(`\` 문자를 이스케이프해야 함).
      + `:modify` 작업은 변수의 현재 값 앞에 지정된 값을 추가합니다.
      + `delim` 속성은 새 값을 기존 값과 구분하는 구분 기호를 지정합니다. 이 예제에서는 `;`입니다.

1. `installpython`의 `.zip` 아카이브를 만들고 그 아카이브를 S3 버킷에 업로드하고 퍼블릭으로 지정합니다. 나중에 사용하기 위해 아카이브의 URL를 적어 둡니다. 자세한 내용은 [쿡북 리포지토리](workingcookbook-installingcustom-repo.md) 섹션을 참조하세요.

   Amazon S3 버킷에 전달한 콘텐츠에는 고객 콘텐츠가 포함될 수 있습니다. 중요 데이터 제거에 관한 자세한 내용은 [S3 버킷을 비우려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html) 단원 또는 [S3 버킷을 삭제하려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html) 단원을 참조하세요.

다음과 같이 이 예제를 위한 스택을 생성합니다. 기존의 Windows 스택을 사용할 수도 있습니다. 나중에 설명하듯이 쿡북을 업데이트하면 됩니다.

**스택을 만듭니다**

1. [OpsWorks Stacks 콘솔](https://console.aws.amazon.com/opsworks/)을 열고 **스택 추가**를 선택합니다. 다음 설정을 지정하고, 그 외 설정에 대해서는 기본값을 수락한 다음 [**스택 추가**]를 선택합니다.
   + **이름** – InstallPython
   + **리전** – 미국 서부(오레곤)

     이 예제는 모든 리전에서 작동하지만 자습서의 경우 미국 서부(오레곤)를 사용하는 것이 좋습니다.
   + **기본 운영 체제** - Microsoft Windows Server 2012 R2

1. [**계층 추가**]를 선택하여 스택에 다음 설정으로 [사용자 지정 계층을 추가](workinglayers-custom.md)합니다.
   + **이름** – Python
   + **짧은 이름** - python

1. 기본 설정을 사용하여 Python 계층에 [24/7 인스턴스를 추가](workinginstances-add.md)하고 [해당 인스턴스를 시작](workinginstances-starting.md)합니다.

인스턴스가 온라인 상태로 전환되면 쿡북을 설치하고 레시피를 실행할 수 있습니다.

**쿡북을 설치하고 레시피를 실행하려면**

1. [스택을 편집해 사용자 지정 쿡북을 활성화](workingcookbook-installingcustom-enable.md)하고 다음 설정을 지정합니다.
   + **리포지토리 유형** – **S3 아카이브**
   + **리포지토리 URL** - 앞에서 기록해 둔 쿡북 아카이브 URL

   기타 설정에 대해 기본값을 수락하고 [**저장**]을 선택하여 스택 구성을 업데이트합니다.

1. [[**사용자 지정 쿡북 업데이트**] 스택 명령을 실행](workingstacks-commands.md)하여 스택의 온라인 인스턴스에 사용자 지정 쿡북의 최신 버전을 설치합니다. 쿡북의 이전 버전이 있으면 이 명령이 이전 버전을 덮어 씁니다.

1. **실행할 레시피**가 **installpython::default**으로 설정된 상태에서 **레시피 실행** 스택 명령을 실행하여 레시피를 실행합니다. 이 명령은 `installpython::default`로 구성된 실행 목록을 사용하여 Chef 실행을 시작합니다.
**참고**  
이 예제에서는 편의상 **레시피 실행**을 사용하지만 일반적으로 OpsWorks Stacks가 레시피를 적절한 수명 주기 이벤트에 할당하여 [레시피를 자동으로 실행](workingcookbook-assigningcustom.md)하도록 합니다. 수동으로 이벤트를 트리거하여 그러한 레시피를 실행할 수 있습니다. 스택 명령을 사용하여 설정 및 Configure 이벤트를 트리거할 수 있고, [배포 명령](workingapps-deploying.md)을 사용하여 Deploy 및 Undeploy 이벤트를 트리거할 수 있습니다.

1. 설치를 확인하려면 [RDP를 사용하여 인스턴스에 연결](workinginstances-rdp.md)한 다음 Windows 탐색기를 엽니다.
   + 이제 파일 시스템에 `C:\Python34` 디렉터리가 있을 것입니다.
   + 명령줄에서 `path`를 실행하면 그 결과는 `PATH=c:\python34;C:\Windows\system32;...`와 유사해야 합니다.
   + 명령줄에서 `python --version`을 실행하면 `Python 3.4.3`을 반환해야 합니다.

# 내장 속성 재정의
<a name="cookbooks-101-opsworks-attributes"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이 주제는 Linux 스택에만 적용됩니다. Windows 스택에서는 내장 속성을 재정의할 수 없습니다.

OpsWorks Stacks는 각 인스턴스에 내장 쿡북 세트를 설치합니다. 내장 쿡북은 대부분 내장 계층을 지원하며, 속성 파일은 Apache 서버 구성 설정과 같은 다양한 기본 시스템 및 애플리케이션 설정을 정의합니다. 속성 파일에 이러한 설정을 포함시키면 다음 방법 중 하나를 사용하여 해당되는 내장 속성을 재정의함으로써 많은 구성 설정을 사용자 지정할 수 있습니다.
+ 속성을 사용자 지정 JSON으로 정의합니다.

  이 방법은 간단하고 유연하다는 장점이 있습니다. 하지만 속성 정의를 관리할 확실한 방법이 없으므로 수동으로 사용자 지정 JSON을 입력해야 합니다.
+ 사용자 지정 쿡북을 구현하고 속성을 `customize.rb` 속성 파일에 정의합니다.

  이 방법은 사용자 지정 JSON을 사용하는 것보다 덜 유연하지만, 사용자 지정 쿡북을 소스 제어에 포함시킬 수 있으므로 보다 확실합니다.

이 주제는 사용자 지정 쿡북 속성 파일을 사용하여 내장 속성을 재정의하는 방법을 Apache 서버를 예로 하여 설명합니다. 사용자 지정 JSON을 사용하여 속성을 재정의하는 방법에 대한 자세한 정보는 [사용자 지정 JSON 사용](workingcookbook-json-override.md) 단원을 참조하세요. 속성 재정의 대한 일반적 설명은 [속성 재정의](workingcookbook-attributes.md) 단원을 참조하세요.

**참고**  
속성 재정의는 구성 설정을 사용자 지정하는 데 선호되는 방법이지만, 설정이 항상 속성으로 표현되는 것은 아닙니다. 이런 경우 종종 내장 레시피가 구성 파일을 생성하는 데 사용하는 템플릿을 재정의하여 구성 파일을 사용자 지정할 수 있습니다. 예제는 [내장 템플릿 재정의](cookbooks-101-opsworks-templates.md) 섹션을 참조하세요.

일반적으로 내장 속성은 설정 레시피가 구성 파일을 생성하는 데 사용하는 템플릿 파일의 값을 나타냅니다. 예를 들어 `apache2` 설정 레시피 중 하나인 [https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/apache2/recipes/default.rb](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/apache2/recipes/default.rb)는 [https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/apache2/templates/default/apache2.conf.erb](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/apache2/templates/default/apache2.conf.erb) 템플릿을 사용하여 Apache 서버의 주 구성 파일 `httpd.conf`(Amazon Linux) 또는 `apache2.conf`(Ubuntu)를 생성합니다. 다음은 템플릿 파일에서 발췌한 코드입니다.

```
...
#
# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited amount.
# We recommend you leave this number high, for maximum performance.
#
MaxKeepAliveRequests <%= node[:apache][:keepaliverequests] %>
#
# KeepAliveTimeout: Number of seconds to wait for the next request from the
# same client on the same connection.
#
KeepAliveTimeout <%= node[:apache][:keepalivetimeout] %>
##
## Server-Pool Size Regulation (MPM specific)
##

...
```

이 예제의 `KeepAliveTimeout` 설정은 `[:apache][:keepalivetimeout]` 속성의 값입니다. 다음 코드에 나오듯이 이 속성의 기본값은 `apache2` cookbook's [https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/apache2/attributes/apache.rb](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/apache2/attributes/apache.rb) 속성 파일에서 정의됩니다.

```
...
# General settings
default[:apache][:listen_ports] = [ '80','443' ]
default[:apache][:contact] = 'ops@example.com'
default[:apache][:log_level] = 'info'
default[:apache][:timeout] = 120
default[:apache][:keepalive] = 'Off'
default[:apache][:keepaliverequests] = 100
default[:apache][:keepalivetimeout] = 3
...
```

**참고**  
일반적으로 사용되는 내장 속성에 대한 자세한 정보는 [내장 쿡북 속성](attributes-recipes.md) 단원을 참조하세요.

내장 속성 재정의를 지원하기 위해 모든 내장 쿡북은 `customize.rb` 속성 파일을 포함합니다. 이 파일은 `include_attribute` 명령을 통해 모든 모듈에 통합됩니다. 내장 쿡북의 `customize.rb` 파일은 속성 정의가 없으므로 내장 속성에 아무 영향을 미치지 않습니다. 내장 속성을 재정의하려면 내장 쿡북과 동일한 이름을 사용하여 사용자 지정 쿡북을 생성하고 사용자 지정 속성 정의를 마찬가지로 `customize.rb`로 명명된 속성 파일에 저장합니다. 이 파일은 내장 버전보다 우선하며 관련된 모든 모듈에 포함됩니다. `customize.rb`에서 내장 속성을 정의할 경우 이들이 해당되는 내장 속성을 재정의합니다.

이 예제는 내장 `[:apache][:keepalivetimeout]` 속성을 재정의하여 값을 3 대신 5로 설정하는 방법을 보여줍니다. 모든 내장 속성에서 비슷한 방법을 사용할 수 있습니다. 하지만 어느 속성을 재정의할지는 신중해야 선택해야 합니다. 예를 들어 `opsworks` 네임스페이스에서 속성을 재정의하면 일부 내장 레시피에 문제가 생길 수 있습니다.

**중요**  
내장 속성 파일의 사본 자체를 수정하여 내장 속성을 재정의하지 마십시오. 예를 들어 사용자 지정 쿡북의 * 폴더에 *의 사본을 저장하고 일부 설정을 수정할 수 `apache.rb`있습니다`apache2/attributes`. 하지만 이 파일은 내장 버전에 우선하므로 이제부터 내장 레시피가 사용자 지정 버전의 `apache.rb`를 사용합니다. 나중에 OpsWorks Stacks가 기본 제공 `apache.rb` 파일을 수정하는 경우 버전을 수동으로 업데이트하지 않는 한 레시피는 새 값을 가져오지 않습니다. `customize.rb`를 사용하면 지정된 속성만 재정의되고 내장 레시피는 재정의되지 않은 모든 속성에 대해 계속해서 최신 값을 자동으로 가져옵니다.

시작하려면 사용자 지정 쿡북을 생성합니다.

**쿡북을 생성하려면**

1. `opsworks_cookbooks` 디렉터리 안에 쿡북 디렉터리 `apache2`를 만들고 그 디렉터리로 이동합니다.

   내장 속성을 재정의하려면 사용자 지정 쿡북의 이름이 내장 쿡북과 동일해야 합니다(이 예제에서는 `apache2`).

1. `apache2` 디렉터리 내에 `attributes` 디렉터리를 만듭니다.

1. `customize.rb` 파일을 `attributes` 디렉터리에 추가하고 이 파일을 사용하여 재정의하려는 내장 쿡북 속성을 정의합니다. 이 예제의 경우 파일에 다음 내용이 포함되어 있어야 합니다.

   ```
   normal[:apache][:keepalivetimeout] = 5
   ```
**중요**  
내장 속성을 재정의하려면 사용자 지정 속성이 `normal` 유형 이상이어야 하며 해당하는 내장 속성과 노드 이름이 정확하게 같아야 합니다. `normal` 유형은 사용자 지정 속성이 모두 `default` 유형인 내장 속성보다 우선하도록 합니다. 자세한 내용은 [속성 우선 순위](workingcookbook-attributes-precedence.md) 섹션을 참조하세요.

1. `opsworks_cookbooks.zip` 이름이 지정된 `opsworks_cookbooks`의 `.zip` 아카이브를 생성하고 아카이브를 Amazon Simple Storage Service(S3) 버킷에 업로드합니다. 간단하게 설명하기 위해 [이 파일을 퍼블릭으로 설정](https://docs.aws.amazon.com/AmazonS3/latest/UG/EditingPermissionsonanObject.html)합니다. 나중에 사용하기 위해 이 URL을 적어 둡니다. 프라이빗 Amazon S3 아카이브 또는 기타 리포지토리 유형에 쿡북을 저장할 수도 있습니다. 자세한 내용은 [쿡북 리포지토리](workingcookbook-installingcustom-repo.md) 섹션을 참조하세요.

   Amazon S3 버킷에 전달한 콘텐츠에는 고객 콘텐츠가 포함될 수 있습니다. 중요 데이터 제거에 관한 자세한 내용은 [S3 버킷을 비우려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html) 단원 또는 [S3 버킷을 삭제하려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html) 단원을 참조하세요.

사용자 지정 속성을 사용하려면 스택을 생성하고 쿡북을 설치합니다.

**사용자 지정 속성을 사용하려면**

1. [OpsWorks Stacks 콘솔](https://console.aws.amazon.com/opsworks/)을 열고 **스택 추가**를 선택합니다.

1. 다음 표준 설정을 지정합니다.
   + **이름** - ApacheConfig
   + **리전** – 미국 서부(오레곤)

     모든 리전에서 스택을 저장할 수 있지만 자습서의 경우 미국 서부(오레곤)를 선택하는 것이 좋습니다.
   + **기본 SSH 키** - EC2 키 페어

     EC2 키 페어를 생성해야 하는 경우 [Amazon EC2 키 페어](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)를 참조하세요. 키 페어는 스택과 동일한 AWS 리전에 속해야 합니다.

   [**고급>>**]을 선택하고 [**사용자 지정 Chef 쿡북 사용**]을 [**예**]로 설정한 후 다음 설정을 지정합니다.
   + **리포지토리 유형** – **Http Archive**
   + **리포지토리 URL** - 앞에서 기록해 둔 쿡북 아카이브 URL

   다른 설정에 대해서는 기본값을 수락한 다음 [**스택 추가**]를 선택해 스택을 생성합니다.
**참고**  
이 예제에서는 기본 운영 체제인 Amazon Linux를 사용하지만, 원한다면 Ubuntu를 사용해도 됩니다. Ubuntu 시스템에서는 내장 설정 레시피가 설정이 동일한 구성 파일 `apache2.conf`를 생성해 `/etc/apache2` 디렉터리에 저장한다는 점만 다릅니다.

1. **계층 추가**를 선택한 다음 스택에 기본 설정으로 [Java 앱 서버 계층을 추가](layers-java.md)합니다.

1. 기본 설정을 사용하여 계층에 [24/7 인스턴스를 추가](workinginstances-add.md)한 다음 해당 인스턴스를 시작합니다.

   이 예제에는 t2.micro 인스턴스면 충분합니다.

1. 인스턴스가 온라인 상태가 되면 [SSH를 사용하여 이 인스턴스에 연결](workinginstances-ssh.md)합니다. `httpd.conf` 파일은 `/etc/httpd/conf` 디렉터리에 있습니다. 이 파일을 확인하는 경우 사용자 지정 `KeepAliveTimeout` 설정이 보여야 합니다. 나머지 설정은 내장 `apache.rb` 파일의 기본값을 갖습니다. `httpd.conf`의 관련 부분에 다음과 비슷한 내용이 표시됩니다.

   ```
   ...
   #
   # KeepAliveTimeout: Number of seconds to wait for the next request from the
   # same client on the same connection.
   #
   KeepAliveTimeout 5
   ...
   ```

# 내장 템플릿 재정의
<a name="cookbooks-101-opsworks-templates"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이 주제는 Linux 스택에만 적용됩니다. Windows 스택에서는 템플릿을 재정의할 수 없습니다.

 OpsWorks Stacks 내장 레시피는 템플릿을 사용하여 인스턴스에 파일을 생성하고, 주로 Apache와 같은 서버에 대한 구성 파일을 생성합니다. 예를 들어 `apache2` 레시피는 [https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/apache2/templates/default/apache2.conf.erb](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/apache2/templates/default/apache2.conf.erb) 템플릿을 사용하여 Apache 서버의 주 구성 파일 `httpd.conf`(Amazon Linux) 또는 `apache2.conf`(Ubuntu)를 생성합니다.

이러한 설정에서 구성 설정은 대부분은 속성으로 표현되므로 해당 내장 속성을 재정하여 구성 파일을 사용자 지정하는 것이 선호되는 방법입니다. 예제는 [내장 속성 재정의](cookbooks-101-opsworks-attributes.md) 섹션을 참조하세요. 하지만 사용자 지정할 설정이 내장 속성으로 표현되지 않거나 템플릿에 포함되지 않은 경우 템플릿 자체를 재정의해야 합니다. 이 주제에서는 내장 템플릿을 재정의하여 사용자 지정 Apache 구성 설정을 지정하는 방법을 설명합니다.

`ErrorDocument` 설정을 `httpd.conf` 파일에 추가하여 Apache에 사용자 지정 오류 응답을 제공할 수 있습니다. 다음 코드에서 보듯이 `apache2.conf.erb`는 일부 코멘트 아웃된 예제만 포함하고 있습니다.

```
...
#
# Customizable error responses come in three flavors:
# 1) plain text 2) local redirects 3) external redirects
#
# Some examples:
#ErrorDocument 500 "The server made a boo boo."
#ErrorDocument 404 /missing.html
#ErrorDocument 404 "/cgi-bin/missing_handler.pl"
#ErrorDocument 402 http://www.example.com/subscription_info.html
...
```

이러한 설정은 하드코딩된 주석이므로 속성을 재정의하여 사용자 지정 값을 지정할 수 없습니다. 템플릿 자체를 재정의해야 합니다. 하지만 속성과 달리 템플릿 파일의 특정 부분을 재정의할 수는 없습니다. 내장 버전과 동일한 이름으로 사용자 지정 쿡북을 생성하고, 템플릿 파일을 동일한 하위 디렉터리에 복사하고, 필요에 따라 파일을 수정해야 합니다. 이 주제는 `apache2.conf.erb`를 재정의하여 오류 500에 대한 사용자 지정 응답을 제공하는 방법을 설명합니다. 템플릿 재정의 대한 일반적 설명은 [사용자 지정 템플릿 사용 ](workingcookbook-template-override.md) 단원을 참조하세요.

**중요**  
내장 템플릿을 재정의하면 내장 레시피가 내장 버전 대신 사용자 지정 버전의 템플릿을 사용합니다. OpsWorks Stacks가 기본 제공 템플릿을 업데이트하면 사용자 지정 템플릿이 동기화되지 않아 올바르게 작동하지 않을 수 있습니다. OpsWorks Stacks는 이러한 변경을 자주 수행하지 않으며 템플릿이 변경되면 OpsWorks Stacks는 변경 사항을 나열하고 새 버전으로 업그레이드할 수 있는 옵션을 제공합니다. [OpsWorks Stacks 리포지토리](https://github.com/aws/opsworks-cookbooks)에서 변경 사항을 모니터링하고 필요에 따라 사용자 지정 템플릿을 수동으로 업데이트하는 것이 좋습니다. 리포지토리는 지원되는 Chef 버전마다 별도의 브랜치가 있습니다. 따라서 올바른 브랜치에 위치하는지 확인해야 합니다.

시작하려면 사용자 지정 쿡북을 생성합니다.

**쿡북을 생성하려면**

1. `opsworks_cookbooks` 디렉터리 안에 쿡북 디렉터리 `apache2`를 만들고 그 디렉터리로 이동합니다. 내장 템플릿을 재정의하려면 사용자 지정 쿡북의 이름이 내장 쿡북과 동일해야 합니다(이 경우에는 `apache2`).
**참고**  
[내장 속성 재정의](cookbooks-101-opsworks-attributes.md) 연습을 이미 완료한 경우 이 예제에 동일한 `apache2` 쿡북을 사용해 2단계를 건너뛸 수 있습니다.

1. 다음 내용이 포함된 `metadata.rb` 파일을 만들어 `apache2` 디렉터리에 저장합니다.

   ```
   name "apache2"
   version "0.1.0"
   ```

1. `apache2` 디렉터리에서 `templates/default` 디렉터리를 만듭니다.
**참고**  
`templates/default` 디렉터리는 기본 `apache2.conf.erb` 템플릿을 사용하는 Amazon Linux 인스턴스에 대해 작동합니다. Ubuntu 14.04 인스턴스는 `apache2.conf.erb` 디렉터리에 있는 운영 체제별 `templates/ubuntu-14.04` 템플릿을 사용합니다. Ubuntu 14.04 인스턴스에도 사용자 지정 사항을 적용하려면 해당 템플릿도 재정의해야 합니다.

1. [내장 `apache2.conf.erb` 템플릿](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/apache2/templates/default/apache2.conf.erb)을 `templates/default` 디렉터리에 복사합니다. 템플릿 파일을 열고 `ErrorDocument 500` 행의 주석 처리를 해제하고 다음과 같이 사용자 지정 오류 메시지를 입력합니다.

   ```
   ...
   ErrorDocument 500 "A custom error message."
   #ErrorDocument 404 /missing.html
   ...
   ```

1. `opsworks_cookbooks`의 `.zip` 아카이브를 만들어 `opsworks_cookbooks.zip`으로 이름을 지정한 다음 해당 파일을 Amazon Simple Storage Service(S3) 버킷에 업로드합니다. 간단하게 설명하기 위해 [이 아카이브를 퍼블릭으로 설정](https://docs.aws.amazon.com/AmazonS3/latest/UG/EditingPermissionsonanObject.html)합니다. 나중에 사용하기 위해 아카이브의 URL를 적어 둡니다. 프라이빗 Amazon S3 아카이브 또는 기타 리포지토리 유형에 쿡북을 저장할 수도 있습니다. 자세한 내용은 [쿡북 리포지토리](workingcookbook-installingcustom-repo.md) 섹션을 참조하세요.

   Amazon S3 버킷에 전달한 콘텐츠에는 고객 콘텐츠가 포함될 수 있습니다. 중요 데이터 제거에 관한 자세한 내용은 [S3 버킷을 비우려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html) 단원 또는 [S3 버킷을 삭제하려면 어떻게 해야 합니까?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html) 단원을 참조하세요.

**참고**  
간결한 설명을 위해 이 예제에서는 템플릿에 하드코딩된 오류 메시지를 추가합니다. 이를 변경하려면 템플릿을 수정하고 [쿡북을 재설치](workingcookbook-installingcustom-enable-update.md)해야 합니다. 유연성을 높이기 위해 사용자 지정 쿡북의 `customize.rb` 속성 파일에서 오류 문자열의 [기본 사용자 지정 속성을 정의](cookbooks-101-opsworks-attributes.md)하고 해당 속성의 값을 `ErrorDocument 500`에 할당할 수 있습니다. 예를 들어 속성을 `[:apache][:custom][:error500]`으로 명명할 경우 `apache2.conf.erb`에서 해당 줄이 다음과 같을 것입니다.  

```
...
ErrorDocument 500 <%= node[:apache][:custom][:error500] %>
#ErrorDocument 404 /missing.html
...
```
그런 다음 언제라도 `[:apache][:custom][:error500]`을 재정의하여 사용자 지정 오류 매시지를 변경할 수 있습니다. [사용자 지정 JSON을 사용하여 속성을 재정의](workingcookbook-json-override.md)하는 경우 쿡북은 손댈 필요조차 없습니다.

사용자 지정 템플릿을 사용하려면 스택을 생성하고 쿡북을 설치합니다.

**사용자 지정 템플릿을 사용하려면**

1. [OpsWorks Stacks 콘솔](https://console.aws.amazon.com/opsworks/)을 열고 **스택 추가**를 선택합니다.

1. 다음 표준 설정을 지정합니다.
   + **이름** – ApacheTemplate
   + **리전** – 미국 서부(오레곤)
   + **기본 SSH 키** - Amazon Elastic Compute Cloud(Amazon EC2) 키 페어

     Amazon EC2 키 페어를 생성해야 하는 경우 [Amazon EC2 키 페어](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)를 참조하세요. 키 페어는 인스턴스와 동일한 AWS 리전에 속해야 합니다.

   [**고급>>**]를 선택한 다음 [**사용자 지정 Chef 쿡북 사용**]를 선택하여 다음 설정을 지정합니다.
   + **리포지토리 유형** – **Http Archive**
   + **리포지토리 URL** - 앞에서 기록해 둔 쿡북 아카이브 URL

   기타 설정에 대해 기본값을 수락하고 [**스택 추가**]를 선택하여 스택을 생성합니다.

1. **계층 추가**를 선택한 다음 스택에 기본 설정으로 [Java 앱 서버 계층을 추가](layers-java.md)합니다.

1. 기본 설정을 사용하여 계층에 [24/7 인스턴스를 추가](workinginstances-add.md)한 다음 해당 인스턴스를 시작합니다.

   이 예제에는 t2.micro 인스턴스면 충분합니다.

1. 인스턴스가 온라인 상태가 되면 [SSH를 사용하여 이 인스턴스에 연결](workinginstances-ssh.md)합니다. `httpd.conf` 파일은 `/etc/httpd/conf` 디렉터리에 있습니다. 이 파일에는 다음과 유사한 사용자 지정 `ErrorDocument` 설정이 포함되어 있어야 합니다.

   ```
   ...
   # Some examples:
   ErrorDocument 500 "A custom error message."
   #ErrorDocument 404 /missing.html
   #ErrorDocument 404 "/cgi-bin/missing_handler.pl"
   #ErrorDocument 402 http://www.example.com/subscription_info.html
   ...
   ```

# 계층 로드 밸런싱
<a name="best-server-load-balancing"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

OpsWorks Stacks는 두 가지 로드 밸런싱 옵션인 [Elastic Load Balancing](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elastic-load-balancing.html)과 [HAProxy](http://www.haproxy.org/)를 제공합니다.이 옵션은 일반적으로 애플리케이션 서버 계층의 인스턴스에서 로드 밸런싱에 사용됩니다. 이 주제에서는 계층에 로드 밸런싱을 추가할 때 어떤 옵션을 선택할지 결정하는 데 도움이 되도록 각 옵션의 이점과 제약을 설명합니다. 일부의 경우 두 옵션을 모두 사용하는 것이 최선의 방법입니다.

**SSL 종료**  <a name="best-server-load-balancing-ssl"></a>
내장 HAProxy 계층은 SSL 종료를 처리하지 않습니다. 따라서 서버에서 SSL을 종료해야 합니다. 이 접근 방식의 장점은 트래픽이 서버에 도달할 때까지 암호화된다는 것입니다. 하지만 서버가 암호 해독을 처리해야 하므로 서버 로드가 증가합니다. 또한 애플리케이션 서버에 SSL 인증서를 배치해야 하는데, 애플리케이션 서버는 사용자가 액세스하기 더 쉽습니다.  
Elastic Load Balancing을 사용하면 로드 밸런서에서 SSL을 종료할 수 있습니다. 이렇게 하면 애플리케이션 서버의 부하가 줄어들지만 로드 밸런서와 서버 간의 트래픽은 암호화되지 않습니다. Elastic Load Balancing을 사용하면 [서버에서 SSL을 종](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-https-load-balancers.html)료할 수도 있지만 설정하기가 다소 복잡합니다.

**규모 조정**  <a name="best-server-load-balancing-scaling"></a>
수신 트래픽이 HAProxy 로드 밸런서의 용량을 초과할 경우 수동으로 용량을 증가해야 합니다.  
Elastic Load Balancing은 수신 트래픽을 처리하기 위해 자동으로 확장됩니다. Elastic Load Balancing 로드 밸런서가 처음 온라인으로 전환될 때 예상 로드를 처리하는 데 충분한 용량을 갖추게 하려면 로드 밸런서를 [사전 워밍](https://aws.amazon.com/articles/1636185810492479#pre-warming)할 수 있습니다.

**로드 밸런서 장애**  <a name="best-server-load-balancing-failure"></a>
HAProxy 서버를 호스팅하는 인스턴스에 장애가 발생할 경우 인스턴스를 재시작할 수 있을 때까지 전체 사이트가 오프라인이 될 수 있습니다.  
Elastic Load Balancing은 HAProxy보다 장애 방지 기능이 더 강합니다. 예를 들어, EC2 인스턴스가 등록된 각 가용 영역에 로드 밸런싱 노드를 프로비저닝합니다. 한 영역에서 서비스가 중단되면 다른 노드가 계속해서 수신 트래픽을 처리합니다. 자세한 내용은 [Elastic Load Balancing Concepts](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/TerminologyandKeyConcepts.html)를 참조하세요.

**유휴 제한 시간**  <a name="best-server-load-balancing-timeout"></a>
두 유형의 로드 밸런서는 모두 서버가 지정된 제한 시간 값보다 오래 유휴 상태를 유지할 경우 연결을 종료합니다.  
+ HAProxy - 유휴 제한 시간 값에 상한이 없습니다.
+ Elastic Load Balancing – 기본 유휴 제한 시간 값이 60초이며 최대값은 3,600초(60분)입니다.
대부분의 경우 Elastic Load Balancing 유휴 제한 시간은 충분합니다. 이보다 긴 유휴 제한 시간이 필요할 경우 HAProxy를 사용하는 것이 좋습니다. 예제:  
+ 푸시 알림에 사용되는 장시간 HTTP 연결.
+ 60분 이상 소요되는 작업을 수행하기 위해 사용하는 관리 인터페이스.

**URL 기반 매핑**  <a name="best-server-load-balancing-url"></a>
로드 밸런서가 수신 요청을 요청의 URL에 따라 특정 서버로 전달해야 할 수 있습니다. 예를 들어 온라인 상거래 애플리케이션을 지원하는 애플리케이션 서버 10개의 그룹이 있다고 가정합시다. 서버 중 8개는 카탈로그를 처리하고 2개는 결제를 처리합니다. 요청 URL을 기반으로 모든 결제 관련 HTTP 요청을 결제 서버로 보내려고 합니다. 이 경우, "payment" 또는 "checkout"을 포함하는 모든 URL을 결제 서버 중 하나로 리디렉션합니다.  
HAProxy에서는 URL 기반 매핑을 사용하여 지정된 문자열을 포함하는 URL을 특정 서버로 리디렉션할 수 있습니다. OpsWorks Stacks에서 URL 기반 매핑을 사용하려면 `haproxy` 기본 제공 쿡북의 `haproxy-default.erb` 템플릿을 재정의하여 사용자 지정 HAProxy 구성 파일을 생성해야 합니다. 자세한 정보는 [HAProxy Configuration Manual](http://cbonte.github.io/haproxy-dconv/configuration-1.5.html) 및 [사용자 지정 템플릿 사용 ](workingcookbook-template-override.md) 단원을 참조하세요. HTTPS 요청에는 URL 기반 매핑을 사용할 수 없습니다. HTTPS 요청은 암호화됩니다. 따라서 HAProxy가 요청 URL을 검사할 방법이 없습니다.  
Elastic Load Balancing은 URL 매핑을 제한적으로 지원합니다. 자세한 내용은 [Elastic Load Balancing의 리스너 구성](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html)을 참조하세요.

**권장 사항:** HAProxy에서만 처리할 수 있는 요구 사항이 아니라면 로드 밸런싱에 Elastic Load Balancing을 사용할 것을 권장합니다. 이 경우 가장 좋은 방법은 Elastic Load Balancing을 HAProxy 서버 집합으로 수신 트래픽을 분산하는 프런트 엔드 로드 밸런서로 사용하여 두 유형을 결합하는 것이 최선의 방법일 수 있습니다. 방법:
+ 스택의 각 가용 영역에서 HAProxy 인스턴스를 설정하여 요청을 영역의 애플리케이션 서버로 분산합니다.
+ HAProxy 인스턴스를 Elastic Load Balancing 로드 밸런서에 할당합니다. 그러면 수신 요청이 HAProxy 로드 밸런서로 분산됩니다.

이 접근 방식은 HAProxy의 URL 기반 매핑을 사용하여 다양한 유형의 요청을 적절한 애플리케이션 서버로 분산할 수 있습니다. 하지만 HAProxy 서버 중 하나가 오프라인으로 전환될 경우 Elastic Load Balancing 로드 밸런서가 자동으로 수신 트래픽을 정상 상태의 HAProxy 서버로 분산하므로 사이트는 기능을 유지합니다. 단, Elastic Load Balancing을를 프런트 엔드 로드 밸런서로 사용해야 합니다. HAProxy 서버는 요청을 다른 HAProxy 서버로 분산할 수 없습니다.

# Chef Server에서 OpsWorks Stacks로 마이그레이션
<a name="best-practices-server-migrate"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

 OpsWorks Stacks는 Chef를 기반으로 하기 때문에 Chef Server에서 OpsWorks Stacks로 마이그레이션하는 것은 비교적 간단합니다. 이 주제에서는 OpsWorks Stacks와 연동되도록 Chef Server 코드를 수정하는 지침을 제공합니다.

**참고**  
chef-solo를 기반으로 하고 검색 또는 데이터 백을 지원하지 않는 11.10 이전의 Chef 버전을 사용하는 스택으로 마이그레이션하는 것은 권장하지 않습니다.

**Topics**
+ [계층에 역할 매핑](#best-practices-server-migrate-roles)
+ [데이터 백 사용](#best-practices-server-migrate-data-bags)
+ [Chef 검색 사용](#best-practices-server-migrate-search)
+ [쿡북 및 레시피 관리](#best-practices-server-migrate-cookbooks)
+ [Chef 환경 사용](#best-practices-server-migrate-environments)

## 계층에 역할 매핑
<a name="best-practices-server-migrate-roles"></a>

Chef Server는 각각 Java 애플리케이션 서버를 호스팅하는 인스턴스 집합처럼 용도와 구성이 동일한 인스턴스를 나타내고 관리하는 데 역할을 사용합니다. [OpsWorks Stacks 계층](workinglayers.md)은 기본적으로 Chef 역할과 같은 용도로 사용됩니다. 계층이란 구성, 설치된 패키지, 애플리케이션 배포 절차 등이 동일한 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 집합을 생성하기 위한 청사진입니다.

OpsWorks Stacks에는 여러 유형의 애플리케이션 서버, HAProxy 로드 밸런서, MySQL 데이터베이스 마스터 및 Ganglia 모니터링 마스터를 위한 [기본 제공 계층](workinglayers.md) 세트가 포함되어 있습니다. 예를 들어 내장 [Java 앱 서버](layers-java.md) 계층은 Tomcat 서버를 호스팅하는 인스턴스를 생성하기 위한 청사진입니다.

 OpsWorks Stacks로 마이그레이션하려면 각 역할을 동등한 기능을 제공하는 계층과 연결해야 합니다. 일부 역할은 내장 계층 중 하나를 그냥 사용할 수 있습니다. 일부 역할에는 다양한 정도의 사용자 지정이 필요할 수 있습니다. 연결된 레시피 등 내장 계층의 기능부터 검사하여 내장 계층이 최소한 역할의 기능 일부를 제공하는지 확인하세요. 내장 계층에 대한 자세한 정보는 [계층](workinglayers.md) 및 [OpsWorks Stacks 계층 참조](layers.md) 단원을 참조하세요. 내장 레시피를 검사하려면 [OpsWorks Stacks 퍼블릭 GitHub 리포지토리를](https://github.com/aws/opsworks-cookbooks) 참조하세요.

이후의 진행은 다음과 같이 계층을 각 역할에 얼마나 가깝게 일치시킬 수 있는지에 따라 달라집니다.

**내장 계층이 역할의 모든 기능을 지원**  
이 내장 계층을 직접 사용하거나 필요하다면 약간의 사용자 지정을 거쳐 사용할 수 있습니다. 예를 들어 역할이 Tomcat 서버를 지원하는 경우, Java 앱 서버 계층의 레시피는 이미 역할의 모든 작업과 어쩌면 일부 약간의 사용자 지정까지 처리할 수 있습니다. 예컨대 적절한 [속성](workingcookbook-attributes.md) 또는 [템플릿을](workingcookbook-template-override.md) 재정의하여 계층의 내장 레시피가 사용자 지정 Tomcat 또는 Apache 구성 설정을 사용하도록 할 수 있습니다.

**내장 계층이 역할의 일부 기능을 지원하지만 모든 기능을 지원하지는 않음**  
[계층을 확장](workingcookbook-extend.md)하여 내장 계층을 사용할 수 있습니다. 그러려면 일반적으로 사용자 지정 레시피를 구현하여 빠진 기능을 지원하고 레시피를 계층의 수명 주기 이벤트에 할당해야 합니다. 예를 들어 역할이 Tomcat 서버를 호스팅하는 동일한 인스턴스에 Redis 서버를 설치한다고 가정해 보십시오. 이 경우, 사용자 지정 레시피를 구현하여 Redis를 Java 앱 서버 계층의 인스턴스에 설치하고 계층의 설정 이벤트에 레시피를 할당하면 역할의 기능에 일치하도록 계층을 확장할 수 있습니다.

**역할의 모든 기능을 적절히 지원하는 내장 계층이 없음**  
사용자 지정 계층을 구현합니다. 예를 들어 어느 내장 계층도 지원하지 않는 MongoDB 데이터베이스 서버를 역할이 지원한다고 가정해 보십시오. 이러한 지원은 레시피를 구현하여 필요한 패키지를 설치하고 서버를 구성한 다음 레시피를 사용자 지정 계층의 수명 주기 이벤트에 할당함으로써 제공할 수 있습니다. 일반적으로 적어도 역할의 레시피 일부는 이러한 용도에 사용할 수 있습니다. 사용자 지정 계층을 구현하는 방법에 대한 자세한 정보는 [사용자 지정 Tomcat 서버 계층 생성](create-custom.md) 단원을 참조하세요.

## 데이터 백 사용
<a name="best-practices-server-migrate-data-bags"></a>

Chef Server를 통해 데이터 백을 사용하여 사용자 정의 데이터를 레시피에 전달할 수 있습니다.
+ 쿡북을 사용하여 데이터를 저장하면 Chef가 각 인스턴스에 데이터를 설치합니다.
+ 비밀번호와 같은 민감한 데이터에는 암호화된 데이터 백을 사용할 수 있습니다.

 OpsWorks Stacks는 데이터 백을 지원합니다. 레시피는 Chef Server와 정확히 동일한 코드를 사용하여 데이터를 검색할 수 있습니다. 다만 이 지원에는 다음과 같은 제한과 차이점이 있습니다.
+ 데이터 백은 Chef 11.10 Linux 및 이후의 스택에서만 지원됩니다.

  이보다 이전 버전의 Chef에서 실행되는 Windows 스택과 Linux 스택은 데이터 백을 지원하지 않습니다.
+ 데이터 백을 쿡북 리포지토리에 저장하지 마십시오.

  그 대신 사용자 지정 JSON을 사용하여 데이터 백의 데이터를 관리하세요.
+ OpsWorks Stacks는 암호화된 데이터 백을 지원하지 않습니다.

  암호나 인증서 등 암호화된 형식의 민감한 데이터를 저장해야 하는 경우, 프라이빗 S3 버킷에 저장하는 것이 좋습니다. 그런 다음 [Ruby용 Amazon SDK](https://aws.amazon.com/documentation/sdk-for-ruby/)를 사용하는 사용자 지정 레시피를 생성해 데이터를 검색할 수 있습니다. 예제는 [ SDK for Ruby 사용](cookbooks-101-opsworks-s3.md) 섹션을 참조하세요.

자세한 내용은 [데이터 백 사용](workingcookbook-chef11-10.md#workingcookbook-chef11-10-databag) 섹션을 참조하세요.

## Chef 검색 사용
<a name="best-practices-server-migrate-search"></a>

Chef Server는 IP 주소와 역할 구성 같은 스택 구성 정보를 서버에 저장합니다. 레시피는 Chef 검색을 사용하여이 데이터를 검색합니다. OpsWorks Stacks는 약간 다른 접근 방식을 사용합니다. 예를 들어 Chef 11.10 Linux 스택은 Chef Server의 경량 버전(흔히 Chef Zero라고 함)을 인스턴스에서 로컬로 실행하는 Chef 클라이언트 옵션인 Chef 클라이언트 로컬 모드에 기반합니다. Chef Zero는 인스턴스의 노드 객체에 저장된 데이터에 대한 검색을 지원합니다.

스택 데이터를 원격 서버에 저장하는 대신 OpsWorks Stacks는 모든 수명 주기 이벤트에 대해 각 인스턴스의 노드 객체에 [스택 구성 및 배포 속성](workingcookbook-json.md) 세트를 추가합니다. 이 속성들은 스택 구성의 스냅샷을 나타냅니다. 이 속성들은 Chef Server와 동일한 구문을 사용하며, 레시피가 서버에서 검색해야 하는 대부분의 데이터를 나타냅니다.

 OpsWorks Stacks에 대한 레시피의 검색 종속 코드를 수정할 필요가 없는 경우가 많습니다. Chef 검색은 스택 구성 및 배포 속성을 포함하는 노드 객체에서 작동하므로 OpsWorks Stacks의 검색 쿼리는 일반적으로 Chef Server와 동일하게 작동합니다.

기본 예외는 스택 구성 및 배포 속성에 인스턴스에 속성을 설치할 때 OpsWorks Stacks가 인식하는 데이터만 포함되어 있기 때문입니다. 특정 인스턴스에서 로컬로 속성을 생성하거나 수정하는 경우 이러한 변경 사항은 OpsWorks Stacks로 다시 전파되지 않으며 다른 인스턴스에 설치된 스택 구성 및 배포 속성에 통합되지 않습니다. 해당 인스턴스에서만 검색을 사용하여 속성을 검색할 수 있습니다. 자세한 내용은 [Chef 검색 사용](workingcookbook-chef11-10.md#workingcookbook-chef11-10-search) 단원을 참조하십시오.

Chef Server와의 호환성을 위해 OpsWorks Stacks는 노드 객체에 `role` 속성 세트를 추가합니다. 각 속성에는 스택의 계층 속성 중 하나가 포함됩니다. 레시피가 `roles`를 검색 키로 사용하는 경우, 검색 코드를 변경할 필요가 없습니다. 쿼리는 자동으로 해당 계층에 대한 데이터를 반환합니다. 예를 들어 다음의 두 쿼리는 모두 `php-app` 계층의 속성을 반환합니다.

```
phpserver = search(:node, "layers:php-app").first
```

```
phpserver = search(:node, "roles:php-app").first
```

## 쿡북 및 레시피 관리
<a name="best-practices-server-migrate-cookbooks"></a>

OpsWorks Stacks와 Chef Server는 쿡북과 레시피를 약간 다르게 처리합니다. Chef Server의 경우:
+ 직접 구현하거나 커뮤니티 쿡북을 사용하여 모든 쿡북을 제공합니다.
+ 쿡북을 서버에 저장합니다.
+ 수동으로 또는 정기적으로 레시피를 실행합니다.

 OpsWorks Stacks 사용:
+ OpsWorks Stacks는 각 내장 계층에 대해 하나 이상의 쿡북을 제공합니다. 이러한 쿡북은 내장 계층의 소프트웨어 설치 및 구성과 앱 배포 같은 표준 작업을 처리합니다.

  내장 쿡북이 수행하지 않는 작업을 처리하려면 스택에 사용자 지정 쿡북을 추가하거나 커뮤니티 쿡북을 사용해야 합니다.
+ Stacks OpsWorks 쿡북을 S3 버킷 또는 Git 리포지토리와 같은 원격 리포지토리에 저장합니다.

  자세한 내용은 [쿡북 저장](#best-practices-server-migrate-cookbooks-store) 단원을 참조하십시오.
+ [레시피를 수동으로 실행할](workingcookbook-manual.md) 수 있지만 일반적으로 인스턴스의 [수명 주기 중 주요 지점에서 발생하는 수명 주기 이벤트](workingcookbook-events.md) 세트에 대한 응답으로 OpsWorks Stacks가 레시피를 실행하도록 합니다.

  자세한 내용은 [레시피 실행](#best-practices-server-migrate-cookbooks-execute) 단원을 참조하십시오.
+ OpsWorks Stacks는 Chef 11.10 스택에서만 Berkshelf를 지원합니다. Berkshelf를 사용하여 쿡북 종속성을 관리하는 경우, Chef 11.4 또는 이전 버전을 실행하는 스택은 사용할 수 없습니다.

  자세한 내용은 [Berkshelf 사용](workingcookbook-chef11-10.md#workingcookbook-chef11-10-berkshelf) 섹션을 참조하세요.

**Topics**
+ [쿡북 저장](#best-practices-server-migrate-cookbooks-store)
+ [레시피 실행](#best-practices-server-migrate-cookbooks-execute)

### 쿡북 저장
<a name="best-practices-server-migrate-cookbooks-store"></a>

Chef Server의 경우, 쿡북을 서버에 저장하고 서버에서 인스턴스로 쿡북을 배포합니다. Stacks를 사용하면 S3 또는 HTTP 아카이브, Git 또는 Subversion 리포지토리와 같은 리포지토리에 OpsWorks 쿡북을 저장할 수 있습니다. [쿡북을 설치할](workingapps-creating.md) 때 OpsWorks Stacks가 리포지토리에서 스택의 인스턴스로 코드를 다운로드하는 데 필요한 정보를 지정합니다.

Chef Server에서 마이그레이션하려면 쿡북을 이러한 리포지토리 중 하나에 두어야 합니다. 쿡북 리포지토리를 구성하는 방법에 대해서는 [쿡북 리포지토리](workingcookbook-installingcustom-repo.md)를 참조하세요.

### 레시피 실행
<a name="best-practices-server-migrate-cookbooks-execute"></a>

 OpsWorks Stacks의 각 계층에는 설정, 구성, 배포, 배포 취소 및 종료와 같은 [수명 주기 이벤트](workingcookbook-events.md) 세트가 있으며, 각 이벤트는 인스턴스의 수명 주기 동안 키 포인트에서 발생합니다. 사용자 지정 레시피를 실행하려면 일반적으로 적절한 계층에서 적절한 이벤트에 사용자 지정 레시피를 할당합니다. 이벤트가 발생하면 OpsWorks Stacks는 연결된 레시피를 실행합니다. 예를 들어 설정 이벤트는 인스턴스 부팅이 완료된 후 발생하므로 일반적으로 이 이벤트에는 패키지 설치 및 구성과 서비스 시작을 수행하는 레시피를 할당합니다.

[레시피 실행 스택 명령](workingstacks-commands.md)을 사용하면 수동으로 레시피를 실행할 수 있습니다. 이 명령은 개발 및 테스트에도 유용하지만 수명 주기 이벤트에 매핑되지 않는 레시피를 실행하는 데도 사용할 수 있습니다. 레시피 실행 명령을 사용하여 설정 및 Configure 이벤트를 수동으로 트리거할 수도 있습니다.

 OpsWorks Stacks 콘솔 외에도 [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) 또는 [SDKs](https://aws.amazon.com/tools/)를 사용하여 레시피를 실행할 수 있습니다. 이 도구들은 모든 [OpsWorks Stacks API 작업](https://docs.aws.amazon.com/opsworks/latest/APIReference/Welcome.html)을 지원하지만 API보다 사용이 더 간단합니다. [create-deployment](https://docs.aws.amazon.com/cli/latest/reference/opsworks/create-deployment.html) CLI 명령을 사용하여 수명 주기 이벤트를 트리거하면 연결된 모든 레시피가 실행됩니다. 이 명령을 사용하여 이벤트를 트리거하지 않고 하나 이상의 레시피를 실행할 수도 있습니다. 이에 상응하는 SDK 코드는 특정 언어에 의존하지만 대체로 CLI 명령과 비슷합니다.

다음 예제는 `create-deployment` CLI 명령을 사용하여 애플리케이션 배포를 자동화하는 두 가지 방법을 설명합니다.
+ 단일 인스턴스가 포함된 사용자 지정 계층을 스택에 추가하여 정기적으로 앱을 배포합니다.

  인스턴스에서 `cron` 작업을 생성해 지정된 일정에 명령을 실행하는 사용자 지정 설정 레시피를 계층에 추가합니다. 레시피를 사용하여 `cron` 작업을 생성하는 방법의 예제는 [Linux 인스턴스에서 Cron 작업 실행](workingcookbook-extend-cron.md) 단원을 참조하세요.
+ `create-deployment` CLI 명령을 사용하여 앱을 배포하는 작업을 지속적 통합 파이프라인에 추가합니다.

## Chef 환경 사용
<a name="best-practices-server-migrate-environments"></a>

OpsWorks Stacks는 Chef 환경을 지원하지 않으며 `node.chef_environment` 항상를 반환합니다`_default`.

# OpsWorks Stacks 계층 참조
<a name="layers"></a>

**중요**  
이 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 스택을 사용하여 계층을 생성하고 관리하는 방법에 대한 자세한 내용은 섹션을 참조하세요[계층](workinglayers.md).

각 계층 설명에는 OpsWorks Stacks가 각 계층의 수명 주기 이벤트에 대해 실행하는 기본 제공 레시피 목록이 포함되어 있습니다. 이러한 레시피는 [https://github.com/aws/opsworks-cookbooks](https://github.com/aws/opsworks-cookbooks)에 저장되어 있습니다. 목록에는 OpsWorks Stacks에서 직접 실행하는 레시피만 포함됩니다. 이러한 레시피는 때때로 목록에는 나열되지 않는 종속 레시피를 실행합니다. 종속 및 사용자 지정 레시피를 비롯해 특정 이벤트에 대한 레시피의 전체 목록을 보려면 해당 [수명 주기 이벤트의 Chef 로그](troubleshoot-debug-log.md)에서 실행 목록을 확인하세요.

**Topics**
+ [HAProxy 계층 레퍼런스](layers-load.md)
+ [HAProxy OpsWorks 스택 계층](layers-haproxy.md)
+ [MySQL 계층 참조](layers-mysql.md)
+ [MySQL OpsWorks 계층](workinglayers-db-mysql.md)
+ [애플리케이션 서버 계층 참조](layers-server.md)
+ [애플리케이션 서버 계층](workinglayers-servers.md)
+ [ECS 클러스터 계층 참조](#w2ab1c14c71b9c21c23)
+ [사용자 지정 계층 참조](layers-other-custom.md)
+ [기타 계층 참조](layers-other.md)
+ [기타 계층](workinglayers-other.md)

# HAProxy 계층 레퍼런스
<a name="layers-load"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이 계층은 Linux 기반 스택에서만 사용할 수 있습니다.

HAProxy 계층은 신뢰할 수 있는 고성능 TCP/HTTP 로드 밸런서인 [HAProxy](http://haproxy.1wt.eu/)를 사용하여 TCP 및 HTTP 기반 애플리케이션을 위한 고가용성 로드 밸런싱 및 프록시 서비스를 제공합니다. 이는 매우 고부하에서 크롤링하면서도 지속성 또는 7계층 처리를 요구하는 웹 사이트에 특히 유용합니다.

HAProxy는 트래픽을 모니터링하고 연결된 인스턴스의 통계 및 상태를 웹 페이지에 표시합니다. 기본적으로 URI는 http://*DNSName*/haproxy?stats입니다. 여기서 *DNSName*은 HAProxy인스턴스의 DNS 이름입니다.

**짧은 이름:** lb

**호환성:** HAProxy 계층은 다음 계층과 호환됩니다. 사용자 지정, db-master, memcached.

**개방 포트:** HAProxy는 포트 22(SSH), 80(HTTP) 및 443(HTTPS)에 대한 퍼블릭 액세스를 허용합니다.

**탄력적 IP 주소 자동 할당:** 기본적으로 On

**기본 EBS 볼륨:** 없음

**기본 보안 그룹:** AWS-OpsWorks-LB-Server

**구성:** 계층을 구성하려면 다음을 지정해야 합니다.
+ 상태 확인 URI(기본값: http://*DNSName*/).
+ 통계 URI(기본값: http://*DNSName*/haproxy?stats).
+ 통계 암호(선택 항목).
+ 상태 확인 메서드(선택 항목). 기본적으로 HAProxy는 HTTP OPTIONS 메서드를 사용합니다. 사용자가 GET 또는 HEAD를 지정할 수도 있습니다.
+ 통계 활성화(선택 항목)
+ 포트. 기본적으로 OpsWorks Stacks는 HTTP 트래픽과 HTTPS 트래픽을 모두 처리하도록 HAProxy를 구성합니다. Chef 구성 [템플릿](https://github.com/aws/opsworks-cookbooks/tree/master-chef-11.4/haproxy/templates/default)인 `haproxy.cfg.erb`를 재정의하여 이 중 하나만 처리하도록 HAProxy를 구성할 수 있습니다.

**설정 레시피:**
+  opsworks\$1initial\$1설정
+ ssh\$1host\$1keys
+ ssh\$1users
+ mysql::client
+ dependencies
+ ebs
+ opsworks\$1ganglia::client
+ haproxy

**Configure 레시피:**
+ opsworks\$1ganglia::configure-client
+ ssh\$1users
+ agent\$1version
+ haproxy::configure

**Deploy 레시피:**
+ deploy::default
+ haproxy::configure 

**Shutdown 레시피:**
+ opsworks\$1shutdown::default
+ haproxy::stop

**설치:**
+ OpsWorks Stacks는 인스턴스의 패키지 설치 관리자를 사용하여 기본 위치에 HAProxy를 설치합니다.
+ 로그 파일을 지정된 위치로 보내도록 syslog를 설정해야 합니다. 자세한 내용은 [HAProxy](http://haproxy.1wt.eu/)를 참조하세요.

# HAProxy OpsWorks 스택 계층
<a name="layers-haproxy"></a>

**참고**  
이 계층은 Chef 11 및 이전 Linux 기반 스택에서만 사용할 수 있습니다.

 OpsWorks Stacks HAProxy 계층은 안정적인 고성능 TCP/HTTP 로드 밸런싱인 [HAProxy](http://haproxy.1wt.eu/) 서버를 호스팅하는 인스턴스에 대한 청사진을 제공하는 OpsWorks Stacks 계층입니다. 일반적으로 스몰 인스턴스 하나로 모든 애플리케이션 서버 트래픽을 처리하는 데 충분합니다.

**참고**  
스택은 단일 리전으로 제한됩니다. 여러 리전으로 애플리케이션을 분산하려면 각 리전마다 따로 스택을 생성해야 합니다.

**HAProxy 계층을 만들려면**

1. 탐색 창에서 [**계층**]를 클릭합니다.

1. [**계층**] 페이지에서 [**계층 추가**] 또는 [**\$1 계층**]을 클릭합니다. [**계층 유형**]으로 **HAProxy**를 선택합니다.

계층 구성 설정은 다음과 같습니다(모두 선택 사항).

**HAProxy 통계**  
계층이 통계를 수집하고 표시하는지 여부. 기본 값은 [**예**]입니다.

**통계 URL**  
통계 페이지의 URL 경로. 전체 URL은 http://*DNSName**StatisticsPath*이며, 여기서 *DNSName*은 연결된 인스턴스의 DNS 이름입니다. 기본 *StatisticsPath* 값은 /haproxy?stats이며, 다음과 같은 값에 해당합니다. http://ec2-54-245-151-7.us-west-2.compute.amazonaws.com/haproxy?stats.

**통계 사용자 이름**  
통계 페이지를 보려면 제공해야 하는 통계 페이지의 사용자 이름. 기본값은 “OpsWorks”입니다.

**통계 암호**  
통계 페이지를 보려면 제공해야 하는 통계 페이지 암호. 기본값은 무작위로 생성된 문자열입니다.

**상태 검사 URL**  
상태 검사 URL 접미사. HAProxy는 이 URL을 사용하여 주기적으로 각 애플리케이션 서버 인스턴스에서 HTTP 메서드를 호출하여 인스턴스가 작동하는지 판단합니다. 상태 검사가 실패할 경우 인스턴스가 수동으로 또는 [자동 조정](workinginstances-autohealing.md)을 통해 재시작될 때까지 HAProxy는 해당 인스턴스로 트래픽 라우팅을 중단합니다. URL 접미사 기본값은 "/"이며, 서버 인스턴스의 홈 페이지 http://*DNSName*/에 해당합니다.

**상태 검사 메서드**  
인스턴스가 작동하는지 검사하는 데 사용할 HTTP 메서드. 기본값은 [**OPTIONS**]이며 [**GET**] 또는 [**HEAD**]를 지정할 수도 있습니다. 자세한 정보는 [httpchk](http://cbonte.github.io/haproxy-dconv/configuration-1.5.html)를 참조하세요.

**사용자 지정 보안 그룹**  
이 설정은 내장 OpsWorks Stacks 보안 그룹을 계층에 자동으로 연결하지 않도록 선택한 경우에 나타납니다. 계층에 어떤 보안 그룹을 연결할지 지정해야 합니다. 계층 간 트래픽을 허용하도록 그룹의 설정이 올바른지 확인하세요. 자세한 내용은 [새 스택 생성](workingstacks-creating.md) 단원을 참조하십시오.

![\[HAProxy layer configuration form with options for statistics and health check settings.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/add_layer_haproxy.png)


**참고**  
나중에 사용할 수 있도록 암호를 기록합니다. OpsWorks Stacks에서는 계층을 생성한 후 암호를 볼 수 없습니다. 하지만 계층의 **편집** 페이지로 이동하고 **일반 설정** 탭의 **암호 업데이트**를 클릭하면 암호를 업데이트할 수 있습니다.  

![\[HAProxy layer settings interface with options for statistics, health checks, and auto healing.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/haproxy_update_password.png)


## HA프록시 계층 작동 방식
<a name="w2ab1c14c71b9c21c13c19"></a>

기본적으로 HAProxy는 다음 작업을 수행합니다.
+ HTTP 및 HTTPS 포트에서 요청을 수신 대기합니다.

  Chef 구성 템플릿인 `haproxy.cfg.erb`를 재정의하여 HTTP 또는 HTTPS 포트 중 하나에서만 수신 대기하도록 HAProxy를 구성할 수 있습니다.
+ 수신 트래픽을 애플리케이션 서버 계층의 멤버인 인스턴스로 라우팅합니다.

  기본적으로 OpsWorks Stacks는 모든 애플리케이션 서버 계층의 멤버인 인스턴스에 트래픽을 분산하도록 HAProxy를 구성합니다. 예를 들어 Rails 앱 서버 및 PHP 앱 서버 계층이 모두 포함된 스택이 있고 HAProxy 마스터가 두 계층 모두의 인스턴스로 트래픽을 분산하는 경우가 있을 수 있습니다. 사용자 지정 레시피를 사용하여 기본 라우팅을 구성할 수 있습니다.
+ 여러 가용 영역에 걸쳐 트래픽을 라우팅합니다.

  한 가용 영역이 다운되면 로드 밸런서가 수신 트래픽을 다른 영역의 인스턴스로 라우팅하여 애플리케이션이 중단 없이 계속 실행될 수 있습니다. 이러한 이유로, 권장되는 방법은 애플리케이션 서버를 여러 가용 영역으로 분산하는 것입니다.
+ 주기적으로 각 애플리케이션 서버 인스턴스에서 지정된 상태 검사 메서드를 실행하여 상태를 평가합니다

  메서드가 지정된 제한 시간 내에 반환되지 않으면 인스턴스가 실패한 것으로 간주되고 HAProxy가 인스턴스에 대한 요청 라우팅을 중지합니다. 또한 OpsWorks Stacks는 실패한 인스턴스를 자동으로 대체하는 방법도 제공합니다. 자세한 내용은 [자동 복구 사용](workinginstances-autohealing.md) 단원을 참조하십시오. 계층을 생성할 때 상태 검사 메서드를 변경할 수 있습니다.
+ 통계를 수집하고 선택적으로 웹 페이지에 통계를 표시합니다.

**중요**  
기본 OPTIONS 메서드를 사용하여 상태 검사가 올바로 작동하려면 앱이 2xx 또는 3xx 상태 코드를 반환해야 합니다.

기본적으로 인스턴스를 HAProxy 계층에 추가하면 OpsWorks Stacks는 인스턴스에 탄력적 IP 주소를 할당하여 전 세계에 공개된 애플리케이션을 나타냅니다. HAProxy 인스턴스의 탄력적 IP 주소는 애플리케이션의 유일하게 공개된 URL이므로 기본 애플리케이션 서버 인스턴스에 대해 퍼블릭 도메인 이름을 생성하고 관리할 필요가 없습니다. 다음 그림에서 보듯이 [**인스턴스**] 페이지로 이동하여 인스턴스의 퍼블릭 IP 주소를 보면 이 주소를 확인할 수 있습니다. (EIP) 다음의 주소가 탄력적 IP 주소입니다. 탄력적 IP 주소에 대한 자세한 내용은 [탄력적 IP 주소(EIP)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html)를 참조하세요.

![\[HAProxy instance table showing hostname, status, size, type, AZ, and public IP address.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/load_balancer_elastic_ip.png)


HAProxy 인스턴스를 중지하면 OpsWorks Stacks는 탄력적 IP 주소를 유지하고 다시 시작할 때 인스턴스에 다시 할당합니다. HAProxy 인스턴스가 삭제될 경우 기본적으로 OpsWorks Stacks는 인스턴스의 IP 주소를 삭제합니다. 주소를 보존하려면 다음 그림과 같이 [**인스턴스의 탄력적 IP 삭제**] 옵션을 선택 취소합니다.

![\[HAProxy instance deletion confirmation dialog with option to retain Elastic IP address.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/delete_lb.png)


이 옵션은 새 인스턴스를 계층에 추가하여 삭제된 인스턴스를 대체할 경우의 동작에 영향을 미칩니다.
+ 삭제된 인스턴스의 탄력적 IP 주소를 유지한 경우 OpsWorks Stacks는 새 인스턴스에 주소를 할당합니다.
+ 그렇지 않으면 OpsWorks Stacks가 인스턴스에 새 탄력적 IP 주소를 할당하므로 DNS 등록 기관 설정을 업데이트하여 새 주소에 매핑해야 합니다.

애플리케이션 서버 인스턴스가 수동으로 또는 [자동 조정](workinginstances-autoscaling.md) 또는 [자동 복구](workinginstances-autohealing.md)의 결과로 온라인 상태가 되거나 오프라인 상태가 되면 트래픽을 현재 온라인 인스턴스 세트로 라우팅하도록 로드 밸런서 구성을 업데이트해야 합니다. 이 작업은 계층의 내장 레시피에 의해 자동으로 처리됩니다.
+ 새 인스턴스가 온라인 상태가 되면 OpsWorks Stacks는 수명 [주기 구성 이벤트를](workingcookbook-events.md) 트리거합니다. HAProxy 계층의 내장 Configure 레시피가 새 애플리케이션 서버 인스턴스로도 요청을 분산하도록 로드 밸런서 구성을 업데이트합니다.
+ 인스턴스가 오프라인 상태가 되거나 인스턴스가 상태 확인에 실패하면 OpsWorks Stacks는 수명 주기 구성 이벤트도 트리거합니다. HAProxy Configure 레시피가 남은 온라인 인스턴스로만 트래픽을 라우팅하도록 로드 밸런서 구성을 업데이트합니다.

마지막으로 HAProxy 계층에서도 사용자 지정 도메인을 사용할 수 있습니다. 자세한 내용은 [사용자 지정 도메인 사용](workingapps-domains.md) 섹션을 참조하세요.

## 통계 페이지
<a name="w2ab1c14c71b9c21c13c21"></a>

통계 페이지를 활성화한 경우 HAProxy가 지정된 URL에서 다양한 측정치가 포함된 페이지를 표시합니다.

**HAProxy 통계를 보려면**

1. 인스턴스의 **세부 정보** 페이지에서 HAProxy 인스턴스의 **퍼블릭 DNS** 이름을 가져와 복사하세요.

1. **계층** 페이지에서 **HAProxy**를 클릭하여 계층의 세부 정보 페이지를 엽니다.

1. 계층 세부 정보에서 통계 URL을 확인하여 퍼블릭 DNS 이름에 추가합니다. 예를 들면 **http://ec2-54-245-102-172.us-west-2.compute.amazonaws.com/haproxy?stats**를 추가합니다.

1. 이전 단계에서 복사한 URL을 브라우저에 붙여 넣고 계층 생성 시 지정한 사용자 이름 및 암호를 사용하여 통계 페이지를 엽니다.  
![\[HAProxy statistics report showing process information and session data for frontend and backend servers.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/haproxy_stats.png)

# MySQL 계층 참조
<a name="layers-mysql"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이 계층은 Linux 기반 스택에서만 사용할 수 있습니다.

MySQL 계층은 널리 사용되는 관계형 데이터베이스 관리 시스템인 MySQL을 지원합니다. OpsWorks Stacks는 운영 체제에 따라 사용 가능한 최신 버전을 설치합니다. MySQL 인스턴스를 추가할 경우 필요한 액세스 정보가 애플리케이션 서버 계층으로 제공됩니다. 사용자 지정 Chef 레시피를 작성하여 마스터-마스터 또는 마스터-슬레이브 구성을 설정해야 합니다.

**짧은 이름:** db-master

**호환성:** MySQL 계층은 다음 계층과 호환됩니다. 사용자 지정, lb, memcached, monitoring-master, nodejs-app, php-app, rails-app, web.

**개방 포트:** MySQL 계층은 포트 22(SSH) 그리고 스택의 웹 서버, 사용자 지정 서버 및 Rails, PHP 및 Node.js 애플리케이션 서버의 모든 포트에 대한 퍼블릭 액세스를 허용합니다.

**탄력적 IP 주소 자동 할당:** 기본적으로 Off

**기본 EBS 볼륨:** 예. 위치: `/vol/mysql`

**기본 보안 그룹:** AWS-OpsWorks-DB-Master-Server 

**구성:** MySQL 계층을 구성하려면 다음을 지정해야 합니다.
+ 루트 사용자 암호
+ MySQL 엔진

**설정 레시피:**
+  opsworks\$1initial\$1설정
+ ssh\$1host\$1keys
+ ssh\$1users
+ mysql::client
+ dependencies
+ ebs
+ opsworks\$1ganglia::client
+ mysql::server
+ dependencies
+ deploy::mysql 

**Configure 레시피:**
+ opsworks\$1ganglia::configure-client
+ ssh\$1users
+ agent\$1version
+ deploy::mysql 

**Deploy 레시피:**
+ deploy::default
+ deploy::mysql 

**Shutdown 레시피:**
+ opsworks\$1shutdown::default
+ mysql::stop

**설치:**
+ OpsWorks Stacks는 인스턴스의 패키지 설치 관리자를 사용하여 MySQL 및 해당 로그 파일을 기본 위치에 설치합니다. 자세한 정보는 [MySQL 설명서](http://dev.mysql.com/doc/index.html)를 참조하세요.

# MySQL OpsWorks 계층
<a name="workinglayers-db-mysql"></a>

**중요**  
이 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 기반 스택에서만 사용할 수 있습니다.

MySQL OpsWorks 계층은 [MySQL](http://www.mysql.com/) 데이터베이스 마스터로 작동하는 Amazon EC2 인스턴스에 대한 청사진을 제공합니다. 내장 레시피는 애플리케이션 서버 계층에 배포된 각 애플리케이션의 데이터베이스를 생성합니다. 예를 들어 "myapp"이라는 PHP 애플리케이션을 배포하면 이 레시피가 “myapp” 데이터베이스를 생성합니다.

MySQL 계층에는 다음 구성 설정이 있습니다.

[**MySQL 루트 사용자 암호**]  
(필수) 루트 사용자 암호.

[**인스턴스마다 루트 사용자 암호 설정**]  
(선택 사항) 스택의 모든 인스턴스에 설치되는 스택 구성 및 배포 속성에 루트 사용자 암호가 포함되는지 여부. 기본 설정은 [**예**]입니다.  
이 값을 **아니요**로 설정하면 OpsWorks Stacks는 루트 암호만 애플리케이션 서버 인스턴스에 전달합니다.

**사용자 지정 보안 그룹**  
(선택 사항) 계층에 연결할 사용자 지정 보안 그룹. 자세한 내용은 [새 스택 생성](workingstacks-creating.md) 섹션을 참조하세요.

![\[Add layer interface for MySQL database setup with OpsWorks, ECS, and RDS options.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/add_layer_mysql.png)


각각이 별도의 MySQL 데이터베이스 마스터를 나타내는 하나 이상의 인스턴스를 계층에 추가할 수 있습니다. 그런 다음 [인스턴스를 앱에 연결](workingapps-creating.md)하면 앱의 애플리케이션 서버에 필요한 연결 정보가 설치됩니다. 그러면 애플리케이션이 연결 정보를 사용하여 [인스턴스의 데이터베이스 서버에 연결](workingapps-connectdb.md)할 수 있습니다.

# 애플리케이션 서버 계층 참조
<a name="layers-server"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

OpsWorks Stacks는 여러 애플리케이션 및 정적 웹 페이지 서버를 지원합니다.

**Topics**
+ [AWS Flow(루비) 계층 참조](layers-server-flow.md)
+ [Java 앱 서버 계층 참조](layers-server-java.md)
+ [Node.js 앱 서버 계층 참조](layers-server-nodejs.md)
+ [PHP 앱 서버 계층 참조](layers-server-php.md)
+ [Rails 앱 서버 계층 참조](layers-server-rails.md)
+ [Static Web Server 계층 참조](layers-server-static.md)

# AWS Flow(루비) 계층 참조
<a name="layers-server-flow"></a>

**중요**  
이 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 Simple Workflow Service 활동 및 워크플로우 worker를 호스트하는 인스턴스의 청사진이 됩니다.

**짧은 이름:** aws-flow-ruby

**호환성:** AWS Flow(Ruby) 계층은 PHP 앱 서버, MySQL, Memcached, Ganglia 및 사용자 지정 계층과 호환됩니다.

**개방 포트:** 없음.

**IAM 역할:** aws-opsworks-ec2-role-with-swf는 요청 시 OpsWorks Stacks가 자동으로 생성하는 표준 AWS Flow(Ruby) 역할입니다.

**탄력적 IP 주소 자동 할당:** 기본적으로 Off

**기본 EBS 볼륨:** 없음

**기본 보안 그룹:** AWS-OpsWorks-AWS-Flow-Ruby-Server

**설정 레시피:**
+ opsworks\$1initial\$1설정
+ ssh\$1host\$1keys
+ ssh\$1users
+ mysql::client
+ dependencies
+ ebs
+ opsworks\$1ganglia::client
+ opsworks\$1aws\$1flow\$1ruby::설정

**Configure 레시피:**
+ opsworks\$1ganglia::configure-client
+ ssh\$1users
+ mysql::client
+ agent\$1version
+ opsworks\$1aws\$1flow\$1ruby::configure 

**Deploy 레시피:**
+ deploy::default
+ deploy::aws-flow-ruby 

**Undeploy 레시피:**
+ deploy::aws-flow-ruby-undeploy

**Shutdown 레시피:**
+ opsworks\$1shutdown::default

# Java 앱 서버 계층 참조
<a name="layers-server-java"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이 계층은 Linux 기반 스택에서만 사용할 수 있습니다.

Java 앱 서버 계층은 [Apache Tomcat 7.0](http://tomcat.apache.org/) 애플리케이션 서버를 지원합니다.

**짧은 이름:** java-app

**호환성:** Java 앱 서버 계층은 다음 계층과 호환됩니다. 사용자 지정, db-master, memcached.

**개방 포트:** Java 앱 서버 계층은 포트 22(SSH), 80(HTTP), 443(HTTPS), 그리고 로드 밸런서의 모든 포트에 대한 퍼블릭 액세스를 허용합니다.

**탄력적 IP 주소 자동 할당:** 기본적으로 Off

**기본 EBS 볼륨:** 없음

**기본 보안 그룹:** AWS-OpsWorks-Java-App-Server

**설정 레시피:**
+ opsworks\$1initial\$1설정
+ ssh\$1host\$1keys
+ ssh\$1users
+ mysql::client
+ dependencies
+ ebs
+ opsworks\$1ganglia::client
+ opsworks\$1java::설정

**Configure 레시피:**
+ opsworks\$1ganglia::configure-client
+ ssh\$1users
+ agent\$1version
+ opsworks\$1java::configure 

**Deploy 레시피:**
+ deploy::default
+ deploy::java 

**Undeploy 레시피:**
+ deploy::java-undeploy

**Shutdown 레시피:**
+ opsworks\$1shutdown::default
+ deploy::java-stop

**설치:**
+ Tomcat이 `/usr/share/tomcat7`에 설치됩니다.
+ 로그 파일을 생성하는 방법에 대한 자세한 정보는 [Tomcat에 로그인](http://tomcat.apache.org/tomcat-6.0-doc/logging.html) 단원을 참조하세요.

# Node.js 앱 서버 계층 참조
<a name="layers-server-nodejs"></a>

**중요**  
이 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/) 애플리케이션 서버를 지원합니다. 프로그램은 JavaScript로 작성되며, 이벤트 중심 비동기식 I/O를 사용하여 오버헤드를 최소화하고 확장성을 최대화합니다.

**짧은 이름:** nodejs-app

**호환성:** Node.js 앱 서버 계층은 다음 계층과 호환됩니다. 사용자 지정, db-master, memcached, monitoring-master.

**개방 포트:** Node.js 앱 서버 계층은 포트 22(SSH), 80(HTTP), 443(HTTPS), 그리고 로드 밸런서의 모든 포트에 대한 퍼블릭 액세스를 허용합니다.

**탄력적 IP 주소 자동 할당:** 기본적으로 Off

**기본 EBS 볼륨:** 없음

**기본 보안 그룹:** AWS-OpsWorks-nodejs-App-Server

**설정 레시피:**
+  opsworks\$1initial\$1설정
+ ssh\$1host\$1keys
+ ssh\$1users
+ mysql::client
+ dependencies
+ ebs
+ opsworks\$1ganglia::client
+ opsworks\$1nodejs
+ opsworks\$1nodejs::npm 

**Configure 레시피:**
+  opsworks\$1ganglia::configure-client
+ ssh\$1users
+ agent\$1version
+ opsworks\$1nodejs::configure 

**Deploy 레시피:**
+ deploy::default
+ opsworks\$1nodejs
+ opsworks\$1nodejs::npm
+ deploy::nodejs 

**Undeploy 레시피:**
+ deploy::nodejs-undeploy

**Shutdown 레시피:**
+ opsworks\$1shutdown::default
+ deploy::nodejs-stop

**설치:**
+ Node.js가 `/usr/local/bin/node`에 설치됩니다.
+ 로그 파일을 생성하는 방법에 대한 자세한 정보는 Nodejitsu 웹사이트의 [node.js에 로그인하는 방법](https://docs.nodejitsu.com/articles/intermediate/how-to-log/)을 참조하세요.

**Node.js 애플리케이션 구성:**
+ Node.js가 실행하는 메인 파일은 이름이 `server.js`여야 하며, 배포된 애플리케이션의 루트 디렉터리에 상주해야 합니다.
+ Node.js 애플리케이션은 포트 80(또는 포트 443, 해당되는 경우)에서 수신 대기하도록 설정해야 합니다.

**참고**  
Express를 실행하는 Node.js 앱은 공통적으로 다음 코드를 사용하여 수신 포트를 설정합니다. 여기서 `process.env.PORT`는 기본 포트를 나타내며 80으로 확인됩니다.  

```
app.set('port', process.env.PORT || 3000);
```
 OpsWorks Stacks에서는 다음과 같이 포트 80을 명시적으로 지정해야 합니다.  

```
app.set('port', 80);
```

# PHP 앱 서버 계층 참조
<a name="layers-server-php"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이 계층은 Linux 기반 스택에서만 사용할 수 있습니다.

PHP 앱 서버 계층은 mod\$1php가 있는 [Apache2](http://httpd.apache.org/)를 사용하여 PHP 애플리케이션 서버를 지원합니다.

**짧은 이름:** php-app

**호환성:** PHP 앱 서버 계층은 다음 계층과 호환됩니다. 사용자 지정, db-master, memcached, monitoring-master, rails-app.

**개방 포트:** PHP 앱 서버 계층은 포트 22(SSH), 80(HTTP), 443(HTTPS), 그리고 로드 밸런서의 모든 포트에 대한 퍼블릭 액세스를 허용합니다.

**탄력적 IP 주소 자동 할당:** 기본적으로 Off

**기본 EBS 볼륨:** 없음

**기본 보안 그룹:** AWS-OpsWorks-PHP-App-Server

**설정 레시피:**
+  opsworks\$1initial\$1설정
+ ssh\$1host\$1keys
+ ssh\$1users
+ mysql::client
+ dependencies
+ ebs
+ opsworks\$1ganglia::client
+ mysql::client
+ dependencies
+ mod\$1php5\$1apache2 

**Configure 레시피:**
+ opsworks\$1ganglia::configure-client
+ ssh\$1users
+ agent\$1version
+ mod\$1php5\$1apache2::php
+ php::configure 

**Deploy 레시피:**
+ deploy::default
+ deploy::php 

**Undeploy 레시피:**
+ deploy::php-undeploy

**Shutdown 레시피:**
+ opsworks\$1shutdown::default
+ apache2::stop 

**설치: **
+  OpsWorks Stacks는 인스턴스의 패키지 설치 관리자를 사용하여 Apache2, mod\$1php 및 관련 로그 파일을 기본 위치에 설치합니다. 설치에 대한 자세한 정보는 [Apache](http://httpd.apache.org/)를 참조하세요. 로깅에 대한 자세한 정보는 [로그 파일](http://httpd.apache.org/docs/2.2/logs.html) 단원을 참조하세요.

# Rails 앱 서버 계층 참조
<a name="layers-server-rails"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이 계층은 Linux 기반 스택에서만 사용할 수 있습니다.

Rails 앱 서버 계층은 [Ruby on Rails](http://rubyonrails.org/) 애플리케이션 서버를 지원합니다.

**짧은 이름:** rails-app

**호환성:** Rails 앱 서버 계층은 다음 계층과 호환됩니다. 사용자 지정, db-master, memcached, monitoring-master, php-app.

**포트:** Rails 앱 서버 계층은 포트 22(SSH), 80(HTTP), 443(HTTPS), 그리고 로드 밸런서의 모든 포트에 대한 퍼블릭 액세스를 허용합니다.

**탄력적 IP 주소 자동 할당:** 기본적으로 Off

**기본 EBS 볼륨:** 없음

**기본 보안 그룹:** AWS-OpsWorks-Rails-App-Server

**구성:** Rails 앱 서버 계층을 구성하려면 다음을 지정해야 합니다.
+ Ruby 버전
+ Rails 스택
+ Rubygems 버전
+ [Bundler](http://gembundler.com/) 설치 및 관리 여부
+ Bundler 버전

**설정 레시피:**
+ opsworks\$1initial\$1설정
+ ssh\$1host\$1keys
+ ssh\$1users
+ mysql::client
+ dependencies
+ ebs
+ opsworks\$1ganglia::client
+ apache2 apache2::mod\$1deflate
+ passenger\$1apache2
+ passenger\$1apache2::mod\$1rails
+ passenger\$1apache2::rails 

**Configure 레시피:**
+ opsworks\$1ganglia::configure-client
+ ssh\$1users
+ agent\$1version
+ rails::configure 

**Deploy 레시피:**
+ deploy::default
+ deploy::rails

**Undeploy 레시피:**
+ deploy::rails-undeploy 

**Shutdown 레시피:**
+ opsworks\$1shutdown::default
+ apache2::stop 

**설치:**
+ OpsWorks Stacks는 인스턴스의 패키지 설치 관리자를 사용하여 mod\$1passenger, mod\$1rails 및 연결된 로그 파일이 있는 Apache2를 기본 위치에 설치합니다. 설치에 대한 자세한 정보는 [Phusion Passenger](https://www.phusionpassenger.com/)를 참조하세요. 로깅에 대한 자세한 정보는 [로그 파일](http://httpd.apache.org/docs/2.2/logs.html) 단원을 참조하세요.

# Static Web Server 계층 참조
<a name="layers-server-static"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이 계층은 Linux 기반 스택에서만 사용할 수 있습니다.

Static Web Server 계층은 정적 HTML 페이지를 서비스하며, 여기에는 JavaScript 같은 클라이언트 측 코드가 포함될 수 있습니다. 이 계층은 오픈 소스 HTTP, 리버스 프록시 및 메일 프록시 서버인 [Nginx](http://nginx.org/en/)를 기반으로 합니다.

**짧은 이름:** web

**호환성:** Static Web Server 계층은 다음 계층과 호환됩니다. 사용자 지정, db-master, memcached.

**개방 포트:** Static Web Server 계층은 포트 22(SSH), 80(HTTP), 443(HTTPS), 그리고 로드 밸런서의 모든 포트에 대한 퍼블릭 액세스를 허용합니다.

**탄력적 IP 주소 자동 할당:** 기본적으로 Off

**기본 EBS 볼륨:** 없음

**기본 보안 그룹:** AWS-OpsWorks-Web-Server

**설정 레시피:**
+ opsworks\$1initial\$1설정
+ ssh\$1host\$1keys
+ ssh\$1users
+ mysql::client
+ dependencies
+ ebs
+ opsworks\$1ganglia::client
+ nginx 

**Configure 레시피:**
+ opsworks\$1ganglia::configure-client
+ ssh\$1users
+ agent\$1version 

**Deploy 레시피:**
+ deploy::default
+ deploy::web 

**Undeploy 레시피:**
+ deploy::web-undeploy

**Shutdown 레시피:**
+ opsworks\$1shutdown::default
+ nginx::stop

**설치:**
+ Nginx가 `/usr/sbin/nginx`에 설치됩니다.
+ Nginx 로그 파일은 `/var/log/nginx`에 있습니다.

# 애플리케이션 서버 계층
<a name="workinglayers-servers"></a>

**중요**  
이 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) 계층
<a name="workinglayers-awsflow"></a>

**중요**  
이 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 스택 계층
<a name="layers-java"></a>

**중요**  
이 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 비활성화
<a name="layers-java-sslv3"></a>

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
</IfModule>
```
다음과 같이 `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
</IfModule>
```

**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
...
```

# 사용자 지정 구성
<a name="layers-java-config"></a>

**중요**  
이 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 앱 배포
<a name="layers-java-deploy"></a>

**중요**  
이 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은 버전이 변경되지 않은 경우에도 업데이트를 인식합니다.  

```
<context-param>
  <param-name>appVersion</param-name>
  <param-value>0.1</param-value>
</context-param>
```

**Topics**
+ [JSP 앱 배포](#layers-java-deploy-jsp)
+ [백엔드 데이터베이스를 사용하여 JSP 앱 배포](#layers-java-deploy-jsp-db)

## JSP 앱 배포
<a name="layers-java-deploy-jsp"></a>

JSP 앱을 배포하려면 이름 및 리포지토리 정보를 지정합니다. 필요한 경우, 도메인 및 SSL 설정도 지정할 수 있습니다. 앱을 생성하는 방법에 대한 자세한 정보는 [앱 추가](workingapps-creating.md) 단원을 참조하세요. 다음 절차에서는 퍼블릭 Amazon S3 아카이브에서 간단한 JSP 페이지를 생성하고 배포하는 방법을 살펴봅니다. 프라이빗 Amazon S3 아카이브 등 다른 리포지토리 유형을 사용하는 방법에 대해서는 [애플리케이션 소스](workingapps-creating.md#workingapps-creating-source) 단원을 참조하세요.

다음 예제는 단순히 일부 시스템 정보를 표시하는 JSP 페이지를 보여 줍니다.

```
<%@ page import="java.net.InetAddress" %>
<html>
<body>
<%
    java.util.Date date = new java.util.Date();
    InetAddress inetAddress = InetAddress.getLocalHost();
%>
The time is 
<%
    out.println( date );
    out.println("<br>Your server's hostname is "+inetAddress.getHostName());
%>
<br>
</body>
</html>
```

**참고**  
다음 절차에서는 스택 생성, 계층에 인스턴스 추가 등등의 기본적 내용에 이미 익숙하다고 가정합니다. 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 앱 배포
<a name="layers-java-deploy-jsp-db"></a>

JSP 페이지는 JDBC `DataSource` 객체를 사용하여 백엔드 데이터베이스에 연결할 수 있습니다. 이러한 앱은 이전 섹션의 절차와 연결을 설정하는 추가 단계를 사용하여 생성 및 배포할 수 있습니다.

다음 JSP 페이지는 `DataSource` 객체에 연결하는 방법을 보여 줍니다.

```
<html>
  <head>
    <title>DB Access</title>
  </head>
  <body>
    <%@ 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:<br>");
        stmt = con.createStatement();
        rs = stmt.executeQuery("show databases");
        while (rs.next()) {
          output.append(rs.getString(1));
          output.append("<br>");
        }
      }
      catch (Exception e) {
        output.append("Exception: ");
        output.append(e.getMessage());
        output.append("<br>");
      }
      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("<br>");
        }
      }
    %>
    <%= output.toString() %>
  </body>
</html>
```

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 스택 계층
<a name="workinglayers-node"></a>

**중요**  
이 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 앱 배포
<a name="w2ab1c14c71b9c21c21c19c17"></a>

 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 스택 계층
<a name="workinglayers-php"></a>

**중요**  
이 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 스택 계층
<a name="workinglayers-rails"></a>

**중요**  
이 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 비활성화
<a name="workinglayers-rails-sslv3"></a>

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)를 참조하세요.

## 데이터베이스에 연결
<a name="workinglayers-rails-db"></a>

앱을 배포하면 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 앱 배포
<a name="workinglayers-rails-deploy"></a>

지원되는 모든 리포지토리에서 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 스택 계층
<a name="workinglayers-static"></a>

**중요**  
이 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)를 참조하세요.

## ECS 클러스터 계층 참조
<a name="w2ab1c14c71b9c21c23"></a>

**참고**  
이 계층은 Linux 기반 스택에서만 사용할 수 있습니다.

ECS 클러스터 계층은 [Amazon Elastic Container Service (Amazon ECS) 클러스터](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html)를 나타내며 클러스터 관리를 단순화합니다.

**짧은 이름:** ecs-cluster

**호환성:** [Amazon ECS 서비스](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) 계층은 사용자 지정 계층과만 호환됩니다.

**개방 포트:** ECS 클러스터는 포트 22(SSH)에 대한 퍼블릭 액세스를 허용합니다.

**탄력적 IP 주소 자동 할당:** 기본적으로 Off

**기본 EBS 볼륨:** 없음

**기본 보안 그룹:** AWS-OpsWorks-ECS-App-Cluster

**구성:** ECS 클러스터 계층을 구성하려면 다음을 지정해야 합니다.
+ 컨테이너 인스턴스에 퍼블릭 IP 주소 또는 탄력적 IP 주소를 할당할지 여부
+ 컨테이너 인스턴스의 인스턴스 프로파일 

**설정 레시피:**
+  opsworks\$1initial\$1설정
+ ssh\$1host\$1keys
+ ssh\$1users
+ mysql::client
+ dependencies
+ ebs
+ opsworks\$1ganglia::client
+ opsworks\$1ecs::설정

**Configure 레시피:**
+ opsworks\$1ganglia::configure-client
+ ssh\$1users
+ mysql::client
+ agent\$1version
+ opsworks\$1ecs::configure

**Deploy 레시피:**
+ deploy::default
+ opsworks\$1ecs::deploy 

**Undeploy 레시피:**
+ opsworks\$1ecs::undeploy 

**Shutdown 레시피:**
+ opsworks\$1shutdown::default
+ opsworks\$1ecs::shutdown

**설치:**
+ OpsWorks Stacks는 인스턴스의 패키지 설치 관리자를 사용하여 기본 위치에 Docker를 설치합니다.
+ 설정 이벤트용 Chef 로그는 Amazon ECS 에이전트가 성공적으로 설치되었는지 여부를 기록합니다. 그렇지 않으면 OpsWorks Stacks에서 제공하는 로그에 Amazon ECS 오류 로그 정보가 포함되지 않습니다. Amazon ECS 오류 처리 방법에 대한 자세한 내용은 [Amazon ECS 문제 해결](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html)을 참조하세요.

# 사용자 지정 계층 참조
<a name="layers-other-custom"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

표준 계층이 사용자의 요구 사항에 적합하지 않은 경우 사용자 지정 계층을 생성할 수 있습니다. 스택은 여러 개의 사용자 지정 계층을 포함할 수 있습니다. 기본적으로 사용자 지정 계층은 기본 기능을 지원하는 제한된 수의 표준 레시피를 실행합니다. 사용자는 각 수명 주기 이벤트에 대해 계층의 소프트웨어를 설정 및 구성하는 등의 사용자 지정 Chef 레시피 세트를 구현함으로써 계층의 주 기능을 구현할 수 있습니다. 사용자 지정 레시피는 각 이벤트에 대한 표준 OpsWorks Stacks 레시피 이후에 실행됩니다.

**짧은 이름:** 사용자 정의됨. 스택 내 각 사용자 지정 계층은 서로 다른 짧은 이름을 가져야 합니다.

**개방 포트:** 기본적으로 사용자 지정 계층은 포트 22(SSH), 80(HTTP), 443(HTTPS), 그리고 스택의 Rails 및 PHP 애플리케이션 서버 계층의 모든 포트에 대해 퍼블릭 액세스를 허용합니다.

**탄력적 IP 주소 자동 할당:** 기본적으로 Off

**기본 EBS 볼륨:** 없음

**기본 보안 그룹:** AWS-OpsWorks-Custom-Server

**호환성:** 사용자 지정 계층은 다음 계층과 호환됩니다. 사용자 지정, db-master, lb, memcached, monitoring-master, nodejs-app, php-app, rails-app, web.

**구성:** 사용자 지정 계층을 구성하려면 다음을 지정해야 합니다.
+ 계층의 이름
+ 계층의 짧은 이름(Chef 레시피에서 계층을 식별하며 a-z 및 숫자만 사용)

Linux 스택의 경우 사용자 지정 계층은 다음 레시피를 사용합니다.

**설정 레시피:**
+  opsworks\$1initial\$1설정
+ ssh\$1host\$1keys
+ ssh\$1users
+ mysql::client
+ dependencies
+ ebs
+ opsworks\$1ganglia::client

**Configure 레시피:**
+ opsworks\$1ganglia::configure-client
+ ssh\$1users
+ agent\$1version 

**Deploy 레시피:**
+ deploy::default

**Shutdown 레시피:**
+ opsworks\$1shutdown::default

# 기타 계층 참조
<a name="layers-other"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

OpsWorks Stacks는 다음 계층도 지원합니다.

**Topics**
+ [Ganglia 계층 참조](layers-other-ganglia.md)
+ [Memcached 계층 참조](layers-other-memcached.md)

# Ganglia 계층 참조
<a name="layers-other-ganglia"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이 계층은 Linux 기반 스택에서만 사용할 수 있습니다.

Ganglia 계층은 인스턴스 측정치의 저장 및 시각화를 관리하는 분산형 모니터링 시스템인 [Ganglia](http://ganglia.sourceforge.net/)를 지원합니다. 이 계층은 계층적 인스턴스 토폴로지에서 사용하도록 설계되어 인스턴스 그룹에 특히 유용합니다. Ganglia에는 두 개의 기본 구성 요소가 있습니다.
+ 저 오버헤드 클라이언트 - 스택 내 각 인스턴스에 설치되고 측정치를 마스터로 전송합니다.
+ 마스터 - 클라이언트로부터 측정치를 수집하여 Amazon EBS 볼륨에 저장합니다. 또한 마스터는 측정치를 웹 페이지에 표시합니다.

OpsWorks Stacks에는 관리하는 각 인스턴스에 Ganglia 모니터링 에이전트가 있습니다. Ganglia 계층을 스택에 추가하여 시작하면 각 인스턴스의 Ganglia 에이전트가 Ganglia 인스턴스로 측정치를 보고합니다. Ganglia를 사용하려면 스택에 하나의 인스턴스를 포함하는 Ganglia 계층을 추가합니다. 데이터는 마스터의 IP 주소에서 Ganglia 백엔드에 로그인하여 액세스합니다. Chef 레시피를 작성하면 추가 측정치 정의를 제공할 수 있습니다.

**짧은 이름:** monitoring-master

**호환성:** Ganglia 계층은 다음 계층과 호환됩니다. 사용자 지정, db-master, memcached, php-app, rails-app.

**개방 포트:** 로드 밸런서는 포트 22(SSH), 80(HTTP) 및 443(HTTPS)에 대한 퍼블릭 액세스를 허용합니다.

**탄력적 IP 주소 자동 할당:** 기본적으로 Off

**기본 EBS 볼륨:** 예. 위치: `/vol/ganglia`

**기본 보안 그룹:** AWS-OpsWorks-Monitoring-Master-Server

**구성:** Ganglia 계층을 구성하려면 다음을 지정해야 합니다.
+ 모니터링 그래프에 대한 액세스를 제공하는 URI. 기본값은 http://*DNSName*/ganglia입니다. 여기서 *DNSName*은 Ganglia 인스턴스의 DNS 이름입니다.
+ 모니터링 통계에 대한 액세스를 제어하는 사용자 이름 및 암호.

**설정 레시피:**
+ opsworks\$1initial\$1설정
+ ssh\$1host\$1keys
+ ssh\$1users
+ mysql::client
+ dependencies
+ ebs
+ opsworks\$1ganglia::client
+ opsworks\$1ganglia::server 

**Configure 레시피:**
+ opsworks\$1ganglia::configure-client
+ ssh\$1users
+ agent\$1version
+ opsworks\$1ganglia::configure-server 

**Deploy 레시피:**
+ deploy::default
+ opsworks\$1ganglia::configure-server
+ opsworks\$1ganglia::deploy 

**Shutdown 레시피:**
+ opsworks\$1shutdown::default
+ apache2::stop 

**설치:**
+ Ganglia 클라이언트는 `/etc/ganglia` 아래에 설치됩니다.
+ Ganglia 웹 프런트 엔드는 `/usr/share/ganglia-webfrontend` 아래에 설치됩니다.
+ Ganglia logtailer는 `/usr/share/ganglia-logtailer` 아래에 설치됩니다.

# Memcached 계층 참조
<a name="layers-other-memcached"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이 계층은 Linux 기반 스택에서만 사용할 수 있습니다.

[Memcached](http://memcached.org/)는 임의 데이터용 분산형 메모리 캐싱 시스템입니다. 이 시스템은 문자열 및 객체를 RAM에서 키와 값으로 캐싱하여 외부 데이터 원본을 읽어야 하는 횟수를 줄이는 방식으로 웹 사이트 속도를 높여줍니다.

스택에서 Memcached를 사용하려면 Memcached 계층을 생성하고 Memcached 서버로 기능하는 인스턴스를 하나 이상 추가합니다. 인스턴스는 자동으로 Memcached를 설치하며, 스택의 다른 인스턴스는 Memcached 서버에 액세스하고 사용할 수 있습니다. Rails 앱 서버 계층을 사용하는 경우 OpsWorks Stacks는 계층에 있는 각 인스턴스의 구성 디렉터리에 `memcached.yml` 구성 파일을 자동으로 배치합니다. 이 파일에서 Memcached 서버 및 포트 번호를 가져올 수 있습니다.

**짧은 이름:** memcached

**호환성:** Memcached 계층은 다음 계층과 호환됩니다. 사용자 지정, db-master, lb, monitoring-master, nodejs-app, php-app, rails-app, web.

**개방 포트:** Memcached 계층은 포트 22(SSH) 그리고 스택의 웹 서버, 사용자 지정 서버 및 Rails, PHP 및 Node.js 애플리케이션 서버의 모든 포트에 대한 퍼블릭 액세스를 허용합니다.

**탄력적 IP 주소 자동 할당:** 기본적으로 Off

**기본 EBS 볼륨:** 없음

**기본 보안 그룹:** AWS-OpsWorks-Memcached-Server 

Memcached 계층을 구성하려면 캐시 크기를 MB 단위로 지정해야 합니다.

**설정 레시피:**
+ opsworks\$1initial\$1설정
+ ssh\$1host\$1keys
+ ssh\$1users
+ mysql::client
+ dependencies
+ ebs
+ opsworks\$1ganglia::client
+ memcached 

**Configure 레시피:**
+ opsworks\$1ganglia::configure-client
+ ssh\$1users
+ agent\$1version 

**Deploy 레시피:**
+ deploy::default

**Shutdown 레시피:**
+ opsworks\$1shutdown::default
+ memcached::stop

**설치:**
+ OpsWorks Stacks는 인스턴스의 패키지 설치 관리자를 사용하여 Memcached와 해당 로그 파일을 기본 위치에 설치합니다.

# 기타 계층
<a name="workinglayers-other"></a>

**중요**  
이 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는 Ganglia 및 Memcached 계층도 지원합니다.

**Topics**
+ [Ganglia 계층](workinglayers-ganglia.md)
+ [Memcached](workinglayers-mem.md)

# Ganglia 계층
<a name="workinglayers-ganglia"></a>

**중요**  
이 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는 모든 인스턴스 및 볼륨 지표를 [Amazon CloudWatch](https://aws.amazon.com/documentation/cloudwatch/)로 전송하므로 쉽게 그래프를 보고 경보를 설정하여 문제를 해결하고 리소스 상태에 따라 자동화된 조치를 취할 수 있습니다. 선택한 지표 저장과 같은 추가 애플리케이션 모니터링 옵션에 Ganglia OpsWorks Stacks 계층을 사용할 수도 있습니다.

Ganglia 계층은 [Ganglia](http://ganglia.sourceforge.net/) 분산형 모니터링을 사용하여 스택을 모니터링하는 인스턴스의 청사진입니다. 스택은 Ganglia 인스턴스를 하나만 포함하는 것이 일반적입니다. Ganglia 계층에는 다음의 선택적 구성 설정이 포함됩니다.

**Ganglia URL**  
통계의 URL 경로. 전체 URL은 http://*DNSName**URLPath*이며, 여기서 *DNSName*은 연결된 인스턴스의 DNS 이름입니다. 기본 *URLPath* 값은 "/ganglia"이며, 다음과 같은 값에 해당합니다. http://ec2-54-245-151-7.us-west-2.compute.amazonaws.com/ganglia.

**Ganglia 사용자 이름**  
통계 웹 페이지의 사용자 이름. 페이지를 보려면 사용자 이름을 제공해야 합니다. 기본값은 “OpsWorks”입니다.

**Ganglia 암호**  
통계 웹 페이지에 대한 액세스를 제어하는 암호. 페이지를 보려면 암호를 제공해야 합니다. 기본값은 무작위로 생성된 문자열입니다.  
나중에 사용할 수 있도록 암호를 기록합니다. OpsWorks Stacks에서는 계층을 생성한 후 암호를 볼 수 없습니다. 하지만 계층의 [편집] 페이지로 이동하고 [**암호 업데이트**]를 클릭하면 암호를 업데이트할 수 있습니다.

**사용자 지정 보안 그룹**  
이 설정은 내장 OpsWorks Stacks 보안 그룹을 계층에 자동으로 연결하지 않도록 선택한 경우에 나타납니다. 계층에 어떤 보안 그룹을 연결할지 지정해야 합니다. 자세한 내용은 [새 스택 생성](workingstacks-creating.md) 섹션을 참조하세요.

**Elastic Load Balancer**  
Elastic Load Balancing 로드 밸런서를 어떤 계층의 인스턴스에도 연결할 수 있습니다.

**중요**  
스택에 Ganglia 계층이 포함된 경우 이 계층이 [CVE-2014-3566](http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566)에 설명된 취약성을 해결하도록 가능하면 SSLv3를 비활성화하는 것이 좋습니다. 그러려면 Apache 서버의 `ssl.conf.erb` 템플릿을 재정의하여 `SSLProtocol` 설정을 수정해야 합니다. 자세한 내용은 [Apache 서버에서 SSLv3 비활성화](layers-java.md#layers-java-sslv3) 섹션을 참조하세요.

## Ganglia 통계 보기
<a name="w2ab1c14c71b9c21c29c11c15"></a>

OpsWorks Stacks 레시피는 모든 인스턴스에 로우 오버헤드 Ganglia 클라이언트를 설치합니다. 스택에 Ganglia 계층이 포함된 경우 Ganglia 클라이언트는 인스턴스가 온라인 상태로 전환되는 즉시 자동으로 Ganglia에 보고를 시작합니다. Ganglia는 클라이언트 데이터를 사용하여 다양한 통계를 계산하고 통계 웹 페이지에 그래프로 결과를 표시합니다.

**Ganglia 통계를 보려면**

1. **계층** 페이지에서 Ganglia를 클릭하여 계층의 세부정보 페이지를 엽니다.

1. 탐색 창에서 **인스턴스**를 클릭합니다. **Ganglia**에서 인스턴스 이름을 클릭합니다.

1.  인스턴스의 **퍼블릭 DNS** 이름을 복사합니다.

1. DNS 이름을 사용하여 통계 URL을 구성합니다. 이 URL은 http://ec2-54-245-151-7.us-west-2.compute.amazonaws.com/ganglia와 유사합니다.

1. 브라우저에 전체 URL을 붙여 넣고 이 페이지로 이동한 다음 Ganglia 사용자 이름 및 암호를 입력하여 페이지를 표시합니다. 예를 들면 다음과 같습니다.  
![\[ShortStack 클러스터 Report dashboard showing system metrics and load graph for the past hour.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/ganglia_stats.png)

# Memcached
<a name="workinglayers-mem"></a>

**중요**  
이 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 기반 스택에서만 사용할 수 있습니다.

Memcached 계층은 임의의 데이터를 위한 분산 메모리 캐싱 시스템인 [Memcached](http://memcached.org/) 서버로 작동하는 인스턴스에 대한 청사진을 제공하는 OpsWorks Stacks 계층입니다. Memcached 계층에는 다음 구성 설정이 포함됩니다.

**허용된 메모리(MB)**  
(선택 사항) 계층 내 각 인스턴스의 캐시 메모리 크기(MB). 기본값은 512MB입니다.

**사용자 지정 보안 그룹**  
이 설정은 내장 OpsWorks Stacks 보안 그룹을 계층에 자동으로 연결하지 않도록 선택한 경우에 나타납니다. 계층에 어떤 보안 그룹을 연결할지 지정해야 합니다. 자세한 내용은 [새 스택 생성](workingstacks-creating.md) 섹션을 참조하세요.

# 쿡북 구성 요소
<a name="workingcookbook-installingcustom-components"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

기본적으로 쿡북은 다음의 기본 구성 요소를 포함합니다.
+ **속성** 파일은 레시피 및 템플릿에서 사용할 값을 나타내는 속성 세트를 포함합니다.
+ **템플릿** 파일은 레시피가 구성 파일과 같은 다른 파일을 생성하는 데 사용하는 템플릿입니다.

  일반적으로 템플릿 파일을 사용하면 구성 파일을 다시 작성하는 대신 쿡북을 건드리지 않고도 속성을 재정의하여 구성 파일을 수정할 수 있습니다. 표준적인 방법은 인스턴스에서 사소하더라도 구성 파일 변경이 예상될 때마다 템플릿 파일을 사용하는 것입니다.
+ **레시피** 파일은 폴더 생성 및 구성, 패키지 설치 및 구성, 서비스 시작 등 시스템을 구성하는 데 필요한 모든 것을 정의하는 Ruby 애플리케이션입니다.

쿡북이 세 구성 요소를 모두 포함할 필요는 없습니다. 보다 간단한 사용자 지정 방법에서는 속성 또는 템플릿 파일만 필요합니다. 또한 쿡북은 선택적으로 정의 또는 사양과 같은 다른 파일 유형을 포함할 수 있습니다.

이 섹션에서는 표준 쿡북 구성 요소 3개를 설명합니다. 자세한 내용, 특히 레시피를 구현하는 방법은 [Opscode](http://www.opscode.com/chef/)를 참조하세요.

**Topics**
+ [속성](workingcookbook-installingcustom-components-attributes.md)
+ [템플릿](workingcookbook-installingcustom-components-templates.md)
+ [레시피](workingcookbook-installingcustom-components-recipes.md)

# 속성
<a name="workingcookbook-installingcustom-components-attributes"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

레시피 및 템플릿은 구성 설정과 같은 다양한 값을 기반으로 합니다. 이러한 값을 레시피 또는 템플릿에서 직접 하드코딩하지 않고 속성이 각 값을 나타내는 속성 파일을 생성할 수 있습니다. 그런 다음 레시피 또는 템플릿에 명시적 값 대신 속성을 사용합니다. 속성을 사용하는 장점은 쿡북을 손대지 않고 해당 값을 재정의할 수 있다는 점입니다. 이러한 이유 때문에 다음 유형의 값은 항상 속성을 사용하여 정의해야 합니다.
+ 사용자 이름 같이 스택마다 또는 시간 경과에 따라 바뀔 수 있는 값.

  이러한 값을 하드코딩할 경우 값을 바꿔야 할 때마다 레시피 또는 템플릿을 변경해야 합니다. 속성을 사용하여 이러한 값을 정의하면 동일한 쿡북을 모든 스택에서 사용하고 해당 속성만 재정의할 수 있습니다.
+ 암호 또는 보안 키 같은 중요한 값.

  쿡북에 중요한 값을 명시적으로 삽입한다면 노출 위험이 증가할 수 있습니다. 그 대신 더미 값으로 속성을 정의한 후 재정의하여 실제 값을 설정하세요. 이러한 속성을 재정의하는 최상의 방법은 사용자 지정 JSON입니다. 자세한 내용은 [사용자 지정 JSON 사용](workingcookbook-json-override.md) 섹션을 참조하세요.

속성과 속성 재정의 방법에 대한 자세한 정보는 [속성 재정의](workingcookbook-attributes.md) 단원을 참조하세요.

다음은 예제 속성 파일의 한 부분입니다.

```
...
default["apache"]["listen_ports"] = [ '80','443' ]
default["apache"]["contact"] = 'ops@example.com'
default["apache"]["timeout"] = 120
default["apache"]["keepalive"] = 'Off'
default["apache"]["keepaliverequests"] = 100
default["apache"]["keepalivetimeout"] = 3
default["apache"]["prefork"]["startservers"] = 16
default["apache"]["prefork"]["minspareservers"] = 16
default["apache"]["prefork"]["maxspareservers"] = 32
default["apache"]["prefork"]["serverlimit"] = 400
default["apache"]["prefork"]["maxclients"] = 400
default["apache"]["prefork"]["maxrequestsperchild"] = 10000
...
```

 OpsWorks Stacks는 다음 구문을 사용하여 속성을 정의합니다.

```
node.type["attribute"]["subattribute"]["..."]=value
```

다음과 같이 콜론(:)을 사용할 수도 있습니다.

```
node.type[:attribute][:subattribute][:...]=value
```

속성 정의에는 다음의 구성 요소가 있습니다.

## `node.`
<a name="node"></a>

`node.` 접두사는 예제에 나와 있는 것과 같이 선택 항목이며 일반적으로 생략됩니다.

## `type`
<a name="type"></a>

유형은 속성을 재정의할 수 있는지 여부를 제어합니다. OpsWorks Stacks 속성은 일반적으로 다음 유형 중 하나를 사용합니다.
+ `default`는 속성 재정의를 허용하기 때문에 가장 자주 사용되는 유형입니다.
+ `normal`는 표준 OpsWorks Stacks 속성 값 중 하나를 재정의하는 속성을 정의합니다.

**참고**  
Chef는 OpsWorks Stacks에는 필요하지 않지만 프로젝트에 유용할 수 있는 추가 유형을 지원합니다. 자세한 정보는 [속성 정보](http://docs.chef.io/attributes.html)를 참조하세요.

## `attribute name`
<a name="attribute-name"></a>

속성 이름은 표준 Chef 노드 구문 `[:attribute][:subattribute][...]`을 사용합니다. 속성에 원하는 이름을 사용할 수 있습니다. 그러나 [속성 재정의](workingcookbook-attributes.md) 단원에서 설명한 것처럼 사용자 지정 쿡북 속성은 스택 구성 및 배포 속성과 Chef의 [Ohai 도구](https://docs.chef.io/ohai.html)의 속성과 함께 인스턴스의 노드 객체로 병합됩니다. *port* 또는 *user*와 같이 흔히 사용되는 구성 이름은 여러 쿡북에서 나타날 수 있습니다.

이름 충돌을 방지하기 위한 규칙은 예제에 나와 있듯이 2개 이상의 요소를 포함하여 한정된 속성 이름을 생성하는 것입니다. 첫 번째 요소는 고유해야 하며 일반적으로 *Apache* 같은 제품 이름을 기반으로 합니다. 그 뒤에는 특정 값을 식별하는 하나 이상의 하위 속성이 옵니다. 예: `[:user]` 또는 `[:port]`. 프로젝트에 따라 원하는 만큼 여러 개의 하위 속성을 사용할 수 있습니다.

## `value`
<a name="value"></a>

속성은 다음 유형의 값으로 설정될 수 있습니다.
+ 문자열, 예: `default[:apache][:keepalive] = 'Off'`.
+ 숫자(따옴표 없음), 예: `default[:apache][:timeout] = 120`.
+ 부울 값 `true` 또는 `false`(따옴표 없음).
+ 값 목록, 예: `default[:apache][:listen_ports] = [ '80','443' ]`

속성 파일은 Ruby 애플리케이션이므로 노드 구문 및 논리 연산자도 사용할 수 있고 다른 속성을 기반으로 값을 할당할 수도 있습니다. 속성을 정의하는 방법에 대한 자세한 정보는 [속성 정보](https://docs.chef.io/chef_overview_attributes.html)를 참조하세요. 작동 속성 파일의 예는 OpsWorks [https://github.com/aws/opsworks-cookbooks](https://github.com/aws/opsworks-cookbooks) Stacks 내장 쿡북을 참조하세요.

# 템플릿
<a name="workingcookbook-installingcustom-components-templates"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

구성 파일을 변경하고 적절한 디렉터리에 배치하여 여러 패키지를 구성합니다. 쿡북에 구성 파일을 포함하고 적절한 디렉터리에 복사할 수 있습니다. 하지만 보다 유연한 접근 방법은 레시피가 템플릿에서 구성 파일을 생성하게 하는 것입니다. 템플릿의 장점 한 가지는 속성을 사용하여 템플릿의 값을 정의할 수 있다는 것입니다. 그러면 예를 들어 사용자 정의 JSON을 사용하여 해당 속성 값을 재정의하면 쿡북을 손대지 않고 구성 파일을 수정할 수 있습니다.

템플릿은 연결된 파일과 콘텐츠 및 구조가 기본적으로 동일합니다. 다음은 예제 파일 `httpd.conf`입니다.

```
ServerRoot "<%= node[:apache][:dir] %>"
<% if node[:platform] == "debian" || node[:platform] == "ubuntu" -%>
  LockFile /var/lock/apache2/accept.lock
<% else -%>
   LockFile logs/accept.lock
<% end -%>
PidFile <%= node[:apache][:pid_file] %>
Timeout <%= node[:apache][:timeout] %>
KeepAlive <%= node[:apache][:keepalive] %>
MaxKeepAliveRequests <%= node[:apache][:keepaliverequests] %>
KeepAliveTimeout <%= node[:apache][:keepalivetimeout] %>
<IfModule mpm_prefork_module>
    StartServers          <%= node[:apache][:prefork][:startservers] %>
    MinSpareServers       <%= node[:apache][:prefork][:minspareservers] %>
    MaxSpareServers       <%= node[:apache][:prefork][:maxspareservers] %>
    ServerLimit           <%= node[:apache][:prefork][:serverlimit] %>
    MaxClients            <%= node[:apache][:prefork][:maxclients] %>
    MaxRequestsPerChild   <%= node[:apache][:prefork][:maxrequestsperchild] %>
</IfModule>
...
```

다음 예제는 Ubuntu 인스턴스용으로 생성된 `httpd.conf` 파일입니다.

```
ServerRoot "/etc/httpd"
LockFile logs/accept.lock
PidFile /var/run/httpd/httpd.pid
Timeout 120
KeepAlive Off
MaxKeepAliveRequests 100
KeepAliveTimeout 3
<IfModule mpm_prefork_module>
    StartServers          16
    MinSpareServers       16
    MaxSpareServers       32
    ServerLimit           400
    MaxClients            400
    MaxRequestsPerChild   10000
</IfModule>
...
```

템플릿의 텍스트는 대부분 템플릿에서 `httpd.conf` 파일로 간단히 복사됩니다. 하지만 `<%= ... %>` 콘텐츠는 다음과 같이 처리됩니다.
+ Chef가 `<%= node[:attribute][:sub_attribute][:...]%>`를 속성 값으로 대체합니다.

  예를 들어 `StartServers <%= node[:apache][:prefork][:startservers] %>`는 `httpd.conf`에서 `StartServers 16`이 됩니다.
+ `<%if-%>, <%else-%>, and <%end-%>`를 사용하여 조건부로 값을 선택할 수 있습니다.

  예제는 `accept.lock`의 파일 경로를 플랫폼에 따라 다르게 설정합니다.

**참고**  
쿡북의 속성 파일 내 속성만 사용할 수 있는 것은 아닙니다. 인스턴스의 노드 객체에 포함된 속성은 모두 사용할 수 있습니다. 예를 들어, [Ohai](https://docs.chef.io/ohai.html)라는 Chef 도구로 생성하여 노드 객체에 통합하기도 합니다. 속성에 대한 자세한 정보는 [속성 재정의](workingcookbook-attributes.md)를 참조하세요.

Ruby 코드를 통합하는 방법을 포함해 템플릿에 대한 자세한 정보는 [템플릿 정보](http://docs.chef.io/templates.html)를 참조하세요.

# 레시피
<a name="workingcookbook-installingcustom-components-recipes"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

레시피는 시스템 구성을 정의하는 Ruby 애플리케이션입니다. 패키지를 설치하고, 템플릿에서 구성 파일을 생성하고, shell 명령을 실행하고, 파일 및 디렉터리를 생성하는 등의 작업을 수행합니다. 일반적으로 인스턴스에서 [수명 주기 이벤트](workingcookbook-events.md)가 발생할 때 OpsWorks Stacks가 레시피를 자동으로 실행하도록 하지만 [Execute Recipes 스택 명령을](workingcookbook-executing.md) 사용하여 언제든지 명시적으로 실행할 수도 있습니다. 자세한 정보는 [About Recipes](http://docs.chef.io/recipes.html)를 참조하세요.

대개 레시피는 일련의 *리소스*로 구성되는데, 각 리소스는 시스템 특정 측면에 대해 원하는 값을 나타냅니다. 각 리소스는 원하는 상태를 정의하는 속성 세트를 포함하며 수행될 작업을 지정합니다. Chef는 각 리소스를 작업을 수행하는 적절한 *공급자*와 연결합니다. 자세한 정보는 [Resources and Providers Reference](https://docs.chef.io/resource.html)를 참조하세요.

`package` 리소스는 Linux 인스턴스에서 소프트웨어 패키지를 관리하는 데 유용합니다. 다음 예제에서는 Apache 패키지를 설치합니다.

```
...
package 'apache2' do
  case node[:platform]
  when 'centos','redhat','fedora','amazon'
    package_name 'httpd'
  when 'debian','ubuntu'
    package_name 'apache2'
  end
  action :install
end
...
```

Chef는 플랫폼에 적절한 패키지 공급자를 사용합니다. 리소스 속성은 단순히 할당된 값일 경우가 많지만, Ruby 논리 연산을 사용하여 조건 할당도 가능합니다. 예제에서는 `case` 연산자가 사용됩니다. 이 연산자는 `node[:platform]`를 사용하여 인스턴스의 운영 체제를 식별하고 그 결과에 따라 `package_name` 속성을 설정합니다. 표준 Chef 노드 구문을 사용하여 레시피에 속성을 삽입할 수 있으며, Chef가 해당 속성을 연결된 값으로 대체합니다. 쿡북 속성뿐 아니라 노드 객체의 모든 속성을 사용할 수 있습니다.

적절한 패키지 이름을 결정하면 코드 세그먼트가 패키지를 설치하는 `install` 작업으로 끝납니다. 이 리소스에 대한 다른 작업은 `upgrade` 및 `remove`를 포함합니다. 자세한 정보는 [package](https://docs.chef.io/chef/resources.html#id150)를 참조하세요.

복잡한 설치 및 구성 작업을 하나 이상의 하위 작업으로 분할하고 각각 별도의 레시피로 구현한 후 주 레시피가 적절한 시간에 각 레시피를 실행하게 하는 것이 유용할 경우가 많습니다. 다음 예제는 이전 예제에 이어지는 코드입니다.

```
include_recipe 'apache2::service'
```

레시피가 하위 레시피를 실행하도록 하려면 `include_recipe` 키워드와 그 뒤에 레시피 이름을 사용합니다. 레시피는 표준 Chef `CookbookName::RecipeName` 구문을 사용하여 식별됩니다. 여기서 `RecipeName`에는 `.rb` 확장명을 생략합니다.

**참고**  
`include_recipe` 문은 주 레시피에서 해당 지점의 레시피를 효과적으로 실행합니다. 하지만 실제로는 Chef가 각 `include_recipe` 문을 지정된 레시피의 코드로 대체한 후 주 레시피를 실행합니다.

`directory` 리소스는 디렉터리를 나타냅니다(예: 패키지 파일이 저장된 디렉터리). 다음 `default.rb` 리소스는 Linux 로그 디렉터리를 생성합니다.

```
directory node[:apache][:log_dir] do
    mode 0755
    action :create
end
```

로그 디렉터리는 쿡북의 속성 파일 중 하나에서 정의됩니다. 이 리소스는 디렉터리 모드를 0755로 지정하며, `create` 작업을 사용하여 디렉터리를 생성합니다. 자세한 정보는 [directory](https://docs.chef.io/chef/resources.html#directory)를 참조하세요. 이 리소스를 Windows 인스턴스에서도 사용할 수 있습니다.

`execute` 리소스는 명령을 나타냅니다(예: shell 명령 또는 스크립트). 다음 예제는 module.load 파일을 생성합니다.

```
execute 'generate-module-list' do
  if node[:kernel][:machine] == 'x86_64'
    libdir = 'lib64'
  else
    libdir = 'lib'
  end
  command "/usr/local/bin/apache2_module_conf_generate.pl /usr/#{libdir}/httpd/modules /etc/httpd/mods-available"
  action :run
end
```

이 리소스는 먼저 CPU 유형을 식별합니다. `[:kernel][:machine]`은 Chef가 다양한 시스템 속성(이 경우에는 CPU 유형)을 나타내기 위해 생성하는 또 하나의 자동 속성입니다. 그런 다음 명령 Perl 스크립트를 지정하고 `run` 작업을 사용하여 스크립트를 실행합니다. 그러면 module.load 파일이 생성됩니다. 자세한 정보는 [실행](https://docs.chef.io/chef/resources.html#execute)을 참조하세요.

`template` 리소스는 쿡북의 템플릿 파일 중 하나에서 생성되는 파일(일반적으로 구성 파일)을 나타냅니다. 다음 예제는 [템플릿](workingcookbook-installingcustom-components-templates.md) 단원에 설명된 `apache2.conf.erb` 템플릿으로부터 `httpd.conf` 구성 파일을 생성합니다.

```
template 'apache2.conf' do
  case node[:platform]
  when 'centos','redhat','fedora','amazon'
    path "#{node[:apache][:dir]}/conf/httpd.conf"
  when 'debian','ubuntu'
    path "#{node[:apache][:dir]}/apache2.conf"
  end
  source 'apache2.conf.erb'
  owner 'root'
  group 'root'
  mode 0644
  notifies :restart, resources(:service => 'apache2')
end
```

이 리소스는 인스턴스의 운영 체제에 따라 생성된 파일의 이름 및 위치를 결정합니다. 그런 다음 `apache2.conf.erb`를 파일을 생성하는 데 사용할 템플릿으로 지정하고 파일의 소유자, 그룹 및 모드를 설정합니다. 이 리소스는 `notify` 작업을 실행하여 Apache 서버를 나타내는 `service` 리소스에 서버를 재시작하라고 알립니다. 자세한 정보는 [template](https://docs.chef.io/chef/resources.html#template) 단원을 참조하세요.

# 스택 구성 및 배포 속성: Linux
<a name="attributes-json-linux"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

이 주제에는 가장 일반적으로 사용되는 스택 구성 및 배포 속성과 연결된 노드 구문이 포함됩니다. 이 주제는 Linux 스택이 사용하는 스택 구성 네임스페이스 구조를 중심으로 짜여져 있습니다. 경우에 따라 동일한 속성 이름이 다른 목적으로 사용되며, 다른 네임스페이스에 존재한다는 점에 유의하세요. 예를 들어 `id`는 스택 ID, 계층 ID, 앱 ID 등등을 지칭할 수 있으므로 속성 값을 사용하려면 정규화된 이름이 필요합니다. 이 데이터를 시각화하는 편리한 방법은 JSON 객체로 시각화하는 것입니다. 예제는 [스택 구성 및 배포 속성](workingcookbook-json.md) 단원을 참조하세요.

**참고**  
Linux 인스턴스에서 OpsWorks Stacks는 노드 객체에 데이터를 추가하는 것 외에도 각 인스턴스에이 JSON 객체를 설치합니다. [에이전트 CLI의 `get_json` 명령을 사용하면 검색할 수 있습니다](agent-json.md).

**Topics**
+ [opsworks 속성](attributes-json-opsworks.md)
+ [opsworks\$1custom\$1cookbooks 속성](attributes-json-custom.md)
+ [dependencies 속성](attributes-json-dependencies.md)
+ [ganglia 속성](attributes-json-ganglia.md)
+ [mysql 속성](attributes-json-mysql.md)
+ [passenger 속성](attributes-json-passenger.md)
+ [opsworks\$1bundler 속성](attributes-json-bundler.md)
+ [deploy 속성](attributes-json-deploy.md)
+ [기타 최상위 속성](attributes-json-other.md)

# opsworks 속성
<a name="attributes-json-opsworks"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

`opsworks` 네임스페이스라고도 하는 `opsworks` 요소에는 기본 스택 구성을 정의하는 속성 집합이 포함되어 있습니다.

**중요**  
`opsworks` 네임스페이스에서 속성 값을 재정의하는 것은 권장하지 않습니다. 그럴 경우, 내장 레시피가 실패할 수 있습니다.

**Topics**
+ [애플리케이션](attributes-json-opsworks-applications.md)
+ [instance 속성](attributes-json-opsworks-instance.md)
+ [layers 속성](attributes-json-opsworks-layers.md)
+ [rails\$1stack 속성](attributes-json-opsworks-rails-stack.md)
+ [stack 속성](attributes-json-opsworks-stack.md)
+ [그 밖의 최상위 opsworks 속성](attributes-json-opsworks-other.md)

# 애플리케이션
<a name="attributes-json-opsworks-applications"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

스택에 존재하는 앱마다 하나씩 포함 객체의 목록을 포함합니다. 각각의 포함 객체에는 애플리케이션 구성을 설명하는 다음 속성이 포함됩니다.

**참고**  
이러한 속성의 일반적 노드 구문은 다음과 같습니다. 여기서 `i`는 인스턴스의 0부터 시작하는 목록 인덱스를 지정합니다.  

```
node["opsworks"]["applications"]["i"]["attribute_name"]
```

**application\$1type**  <a name="attributes-json-opsworks-applications-type"></a>
애플리케이션의 유형(문자열). 가능한 값은 다음과 같습니다.  
+ `php`: PHP 앱
+ `rails`: Ruby on Rails 앱
+ `java`: Java 앱
+ `nodejs`: Node.js 앱
+ `web`: 정적 HTML 페이지
+ `other`: 그 밖의 모든 애플리케이션 유형

```
node["opsworks"]["applications"]["i"]["application_type"]
```

**이름**  <a name="attributes-json-opsworks-applications-name"></a>
`"SimplePHP"`와 같은 사용자 정의 표시 이름(문자열).  

```
node["opsworks"]["applications"]["i"]["name"]
```

**slug\$1name**  <a name="attributes-json-opsworks-applications-slug"></a>
앱의 이름으로부터 OpsWorks가 생성하는, `"simplephp"`와 같이 전체가 소문자인 짧은 이름(문자열).  

```
node["opsworks"]["applications"]["i"]["slug_name"]
```

# instance 속성
<a name="attributes-json-opsworks-instance"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

`instance` 속성에는 이 인스턴스의 구성을 지정하는 속성 세트가 포함되어 있습니다.


****  

|  |  |  | 
| --- |--- |--- |
| [구조](#attributes-json-opsworks-instance-arch) | [availability\$1zone](#attributes-json-opsworks-instance-availability) | [backends](#attributes-json-opsworks-instance-backends) | 
| [aws\$1instance\$1id](#attributes-json-opsworks-instance-ec2-id) | [hostname](#attributes-json-opsworks-instance-host) | [id](#attributes-json-opsworks-instance-id) | 
| [instance\$1type](#attributes-json-opsworks-instance-type) | [ip](#attributes-json-opsworks-instance-ip) | [계층](#attributes-json-opsworks-instance-layers) | 
| [private\$1dns\$1name](#attributes-json-opsworks-instance-private-dns) | [private\$1ip](#attributes-json-opsworks-instance-private-ip) | [public\$1dns\$1name](#attributes-json-opsworks-instance-dns) | 
| [리전](#attributes-json-opsworks-instance-region) |  |  | 

**구조**  <a name="attributes-json-opsworks-instance-arch"></a>
`"i386"`과 같은 인스턴스의 아키텍처(문자열).  

```
node["opsworks"]["instance"]["architecture"]
```

**availability\$1zone**  <a name="attributes-json-opsworks-instance-availability"></a>
`"us-west-2a"`와 같은 인스턴스의 가용 영역(문자열).  

```
node["opsworks"]["instance"]["availability_zone"]
```

**backends**  <a name="attributes-json-opsworks-instance-backends"></a>
백엔드 웹 프로세스의 수(문자열). 예컨대 HAProxy가 Rails 백엔드에 전달할 동시 연결의 수를 결정합니다. 기본값은 인스턴스의 메모리 및 코어 개수에 따라 달라집니다.  

```
node["opsworks"]["instance"]["backends"]
```

**aws\$1instance\$1id**  <a name="attributes-json-opsworks-instance-ec2-id"></a>
EC2 인스턴스 ID(문자열).  

```
node["opsworks"]["instance"]["aws_instance_id"]
```

**hostname**  <a name="attributes-json-opsworks-instance-host"></a>
호스트 이름(문자열), 예: `"php-app1"`.  

```
node["opsworks"]["instance"]["hostname"]
```

**id**  <a name="attributes-json-opsworks-instance-id"></a>
인스턴스를 고유하게 식별하는 OpsWorks Stacks 생성 GUID인 인스턴스 ID(문자열).  

```
node["opsworks"]["instance"]["id"]
```

**instance\$1type**  <a name="attributes-json-opsworks-instance-type"></a>
`"c1.medium"`과 같은 인스턴스 유형(문자열).  

```
node["opsworks"]["instance"]["instance_type"]
```

**ip**  <a name="attributes-json-opsworks-instance-ip"></a>
퍼블릭 IP 주소(문자열).  

```
node["opsworks"]["instance"]["ip"]
```

**계층**  <a name="attributes-json-opsworks-instance-layers"></a>
`"lb"` 또는 `"db-master"` 같은 짧은 이름으로 식별되는 인스턴스 계층의 목록(문자열 목록).  

```
node["opsworks"]["instance"]["layers"]
```

**private\$1dns\$1name**  <a name="attributes-json-opsworks-instance-private-dns"></a>
프라이빗 DNS 이름(문자열).  

```
node["opsworks"]["instance"]["private_dns_name"]
```

**private\$1ip**  <a name="attributes-json-opsworks-instance-private-ip"></a>
프라이빗 IP 주소(문자열).  

```
node["opsworks"]["instance"]["private_ip"]
```

**public\$1dns\$1name**  <a name="attributes-json-opsworks-instance-dns"></a>
퍼블릭 DNS 이름(문자열).  

```
node["opsworks"]["instance"]["public_dns_name"]
```

**리전**  <a name="attributes-json-opsworks-instance-region"></a>
`"us-west-2"`와 같은 AWS 리전(문자열).  

```
node["opsworks"]["instance"]["region"]
```

# layers 속성
<a name="attributes-json-opsworks-layers"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

`layers` 속성에는 `php-app` 등 계층의 짧은 이름으로 명명되는 계층 속성 세트가 스택의 각 계층마다 하나씩 포함됩니다. 스택에는 짧은 이름이 다음과 같은 각각의 내장 계층이 최대 하나 있을 수 있습니다.
+ `db-master`: MySQL 계층
+ `java-app`: Java 앱 서버 계층
+ `lb`: HAProxy 계층
+ `monitoring-master`: Ganglia 계층
+ `memcached`: Memcached 계층
+ `nodejs-app`: Node.js 앱 서버 계층
+ `php-app`: PHP 앱 서버 계층
+ `rails-app`: Rails 앱 서버 계층
+ `web`: Static Web Server 계층

스택에는 사용자가 정의한 짧은 이름을 갖는 사용자 지정 계층이 개수 제한 없이 포함될 수 있습니다.

각 계층 속성은 다음 속성을 포함합니다.
+ [id](#attributes-json-opsworks-layers-id)
+ [instances](#attributes-json-opsworks-layers-instances)
+ [이름](#attributes-json-opsworks-layers-name)

**id**  <a name="attributes-json-opsworks-layers-id"></a>
OpsWorks에 의해 생성되고 계층을 고유하게 식별하는 GUID인 계층 ID(문자열).  

```
node["opsworks"]["layers"]["layershortname"]["id"]
```

**instances**  <a name="attributes-json-opsworks-layers-instances"></a>
`instances` 요소에는 계층의 온라인 인스턴스당 하나씩 인스턴스 속성 세트가 포함됩니다. 이들은 `php-app1`과 같이 인스턴스의 호스트 이름으로 명명됩니다.  
`instances` 요소에는 특정 스택 구성 및 배포 속성이 생성될 때 온라인 상태인 인스턴스만이 포함됩니다.
각 속성 요소에는 다음 속성이 포함됩니다.    
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/attributes-json-opsworks-layers.html)  
**availability\$1zone**  <a name="attributes-json-opsworks-layers-instances-availability"></a>
`"us-west-2a"`와 같은 가용 영역(문자열).  

```
node["opsworks"]["layers"]["layershortname"]["instances"]["instancehostname"]["availability_zone"]
```  
**aws\$1instance\$1id**  <a name="attributes-json-opsworks-layers-instances-aws-id"></a>
EC2 인스턴스 ID(문자열).  

```
node["opsworks"]["layers"]["layershortname"]["instances"]["instancehostname"]["aws_instance_id"]
```  
**backends**  <a name="attributes-json-opsworks-layers-instances-backends"></a>
백엔드 웹 프로세스의 수(숫자). 예컨대 HAProxy가 Rails 백엔드에 전달할 동시 연결의 수를 결정합니다. 기본값은 인스턴스의 메모리 및 코어 개수에 따라 달라집니다.  

```
node["opsworks"]["layers"]["layershortname"]["instances"]["instancehostname"]["backends"]
```  
**booted\$1at**  <a name="attributes-json-opsworks-layers-instances-booted"></a>
EC2 인스턴스가 부팅된 시간으로 UTC yyyy-mm-dddThh:mm:ss\$1hh:mm 형식을 사용합니다(문자열). 예를 들어 `"2013-10-01T08:35:22+00:00"`은 2013년 10월 10일 8:35:22에 해당합니다(시간대 오프셋 없음). 자세한 정보는 [ISO 8601](http://en.wikipedia.org/wiki/ISO_8601)를 참조하세요.  

```
node["opsworks"]["layers"]["layershortname"]["instances"]["instancehostname"]["booted_at"]
```  
**created\$1at**  <a name="attributes-json-opsworks-layers-instances-created"></a>
EC2 인스턴스가 생성된 시간으로 UTC yyyy-mm-dddThh:mm:ss\$1hh:mm 형식을 사용합니다(문자열). 예를 들어 `"2013-10-01T08:35:22+00:00"`은 2013년 10월 10일 8:35:22에 해당합니다(시간대 오프셋 없음). 자세한 정보는 [ISO 8601](http://en.wikipedia.org/wiki/ISO_8601)를 참조하세요.  

```
node["opsworks"]["layers"]["layershortname"]["instances"]["instancehostname"]["created_at"]
```  
**elastic\$1ip**  <a name="attributes-json-opsworks-layers-instances-elastic"></a>
탄력적 IP 주소로서 인스턴스에 탄력적 IP 주소가 없으면 null로 설정됩니다(문자열).  

```
node["opsworks"]["layers"]["layershortname"]["instances"]["instancehostname"]["elastic_ip"]
```  
**instance\$1type**  <a name="attributes-json-opsworks-layers-instances-type"></a>
`"c1.medium"`과 같은 인스턴스 유형(문자열).  

```
node["opsworks"]["layers"]["layershortname"]["instances"]["instancehostname"]["instance_type"]
```  
**ip**  <a name="attributes-json-opsworks-layers-instances-ip"></a>
퍼블릭 IP 주소(문자열).  

```
node["opsworks"]["layers"]["layershortname"]["instances"]["instancehostname"]["ip"]
```  
**private\$1ip**  <a name="attributes-json-opsworks-layers-instances-private-ip"></a>
프라이빗 IP 주소(문자열).  

```
node["opsworks"]["layers"]["layershortname"]["instances"]["instancehostname"]["private_ip"]
```  
**public\$1dns\$1name**  <a name="attributes-json-opsworks-layers-instances-public-dns"></a>
퍼블릭 DNS 이름(문자열).  

```
node["opsworks"]["layers"]["layershortname"]["instances"]["instancehostname"]["public_dns_name"]
```  
**private\$1dns\$1name**  <a name="attributes-json-opsworks-layers-instances-private-dns"></a>
프라이빗 DNS 이름(문자열).  

```
node["opsworks"]["layers"]["layershortname"]["instances"]["instancehostname"]["private_dns_name"]
```  
**리전**  <a name="attributes-json-opsworks-layers-instances-region"></a>
`"us-west-2"`와 같은 AWS 리전(문자열).  

```
node["opsworks"]["layers"]["layershortname"]["instances"]["instancehostname"]["region"]
```  
**status**  <a name="attributes-json-opsworks-layers-instances-status"></a>
상태(문자열). 가능한 값은 다음과 같습니다.  
+ `"requested"`
+ `"booting"`
+ `"running_setup"`
+ `"online"`
+ `"setup_failed"`
+ `"start_failed"`
+ `"terminating"`
+ `"terminated"`
+ `"stopped"`
+ `"connection_lost"`

```
node["opsworks"]["layers"]["layershortname"]["instances"]["instancehostname"]["status"]
```

**이름**  <a name="attributes-json-opsworks-layers-name"></a>
콘솔에서 계층을 나타내는 데 사용되는 계층의 이름(문자열). 사용자 정의 이름일 수 있으며 반드시 고유한 것은 아닙니다.  

```
node["opsworks"]["layers"]["layershortname"]["name"]
```

# rails\$1stack 속성
<a name="attributes-json-opsworks-rails-stack"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**이름**  <a name="attributes-json-opsworks-rails-stack-name"></a>
rails 스택을 지정하며, `"apache_passenger"` 또는 `"nginx_unicorn"`으로 설정됩니다(문자열).  

```
node["opsworks"]["rails_stack"]["name"]
```

**레시피 **  <a name="attributes-json-opsworks-rails-stack-recipe"></a>
연결된 레시피로서 Passenger를 사용 중인지 Unicorn을 사용 중인지에 따라 달라집니다(문자열).  
+ Unicorn: `"unicorn::rails"`
+ Passenger: `"passenger_apache2::rails"`

```
node["opsworks"]["rails_stack"]["recipe"]
```

**restart\$1command **  <a name="attributes-json-opsworks-rails-stack-restart"></a>
재시작 명령으로서 Passenger를 사용 중인지 Unicorn을 사용 중인지에 따라 달라집니다(문자열).  
+ Unicorn: `"../../shared/scripts/unicorn clean-restart"`
+ Passenger: `"touch tmp/restart.txt"`

**서비스 **  <a name="attributes-json-opsworks-rails-stack-service"></a>
서비스 이름으로서 Passenger를 사용 중인지 Unicorn을 사용 중인지에 따라 달라집니다(문자열).  
+ Unicorn: `"unicorn"`
+ Passenger: `"apache2"`

```
node["opsworks"]["rails_stack"]["service"]
```

# stack 속성
<a name="attributes-json-opsworks-stack"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

`stack` 속성은 서비스 계층 구성 등 스택 구성의 일부 측면을 지정합니다.
+ [elb-load-balancers](#attributes-json-opsworks-stack-elb)
+ [id](#attributes-json-opsworks-stack-id)
+ [이름](#attributes-json-opsworks-stack-name)
+ [rds\$1instances](#attributes-json-opsworks-stack-rds)
+ [vpc\$1id](#attributes-json-opsworks-stack-vpc-id)

**elb-load-balancers**  <a name="attributes-json-opsworks-stack-elb"></a>
스택에 있는 각각의 Elastic Load Balancing 로드 밸런서당 하나씩 포함 객체의 목록을 포함합니다. 각각의 포함 객체에는 로드 밸런서 구성을 설명하는 다음 속성이 포함됩니다.  
이러한 속성의 일반적 노드 구문은 다음과 같습니다. 여기서 `i`는 인스턴스의 0부터 시작하는 목록 인덱스를 지정합니다.  

```
node["opsworks"]["stack"]["elb-load-balancers"]["i"]["attribute_name"]
```  
**dns\$1name**  <a name="attributes-json-opsworks-stack-elb-dns-name"></a>
로드 밸런서의 DNS 이름(문자열).  

```
node["opsworks"]["stack"]["elb-load-balancers"]["i"]["dns_name"]
```  
**이름**  <a name="attributes-json-opsworks-stack-elb-name"></a>
로드 밸런서의 이름(문자열).  

```
node["opsworks"]["stack"]["elb-load-balancers"]["i"]["name"]
```  
**layer\$1id**  <a name="attributes-json-opsworks-stack-elb-layer-id"></a>
로드 밸런서가 연결된 계층의 ID(문자열).  

```
node["opsworks"]["stack"]["elb-load-balancers"]["i"]["layer_id"]
```

**id**  <a name="attributes-json-opsworks-stack-id"></a>
스택 ID(문자열).  

```
node["opsworks"]["stack"]["id"]
```

**이름**  <a name="attributes-json-opsworks-stack-name"></a>
스택 이름(문자열).  

```
node["opsworks"]["stack"]["name"]
```

**rds\$1instances**  <a name="attributes-json-opsworks-stack-rds"></a>
스택에 등록된 각각의 Amazon RDS 인스턴스에 하나씩 포함 객체의 목록을 포함합니다. 각각의 포함 객체에는 인스턴스의 구성을 설명하는 속성 세트가 포함됩니다. Amazon RDS 콘솔 또는 API를 사용하여 인스턴스를 생성할 때 이 값들을 지정합니다. 인스턴스가 생성된 후 Amazon RDS 콘솔 또는 API를 사용하여 일부 설정을 편집할 수도 있습니다. 자세한 내용은 [Amazon RDS 설명서](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html)를 참조하세요.  
이러한 속성의 일반적 노드 구문은 다음과 같습니다. 여기서 `i`는 인스턴스의 0부터 시작하는 목록 인덱스를 지정합니다.  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["attribute_name"]
```
스택에 여러 개의 Amazon RDS 인스턴스가 있는 경우, 레시피에서 특정 인스턴스를 사용하는 방법의 예는 다음과 같습니다.  

```
if my_rds = node["opsworks"]["stack"]["rds_instances"].select{|rds_instance| rds_instance["db_instance_identifier"] == ‘db_id’ }.first
  template “/etc/rds.conf” do
    source "rds.conf.erb"
    variables :address => my_rds["address"]
  end
end
```  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/attributes-json-opsworks-stack.html)  
**address**  <a name="attributes-json-opsworks-stack-rds-address"></a>
`opsinstance.ccdvt3hwog1a.us-west-2.rds.amazonaws.com`와 같은 인스턴스 URL(문자열).  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["address"]
```  
**allocated\$1storage**  <a name="attributes-json-opsworks-stack-rds-storage"></a>
할당된 스토리지, GB 단위(숫자).  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["allocated_storage"]
```  
**arn**  <a name="attributes-json-opsworks-stack-rds-arn"></a>
인스턴스의 ARN(문자열).  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["arn"]
```  
**auto\$1minor\$1version\$1upgrade**  <a name="attributes-json-opsworks-stack-rds-minor"></a>
마이너 버전 업그레이드를 자동으로 적용할지 여부(부울).  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["auto_minor_version_upgrade"]
```  
**availability\$1zone**  <a name="attributes-json-opsworks-stack-rds-az"></a>
`us-west-2a`와 같은 인스턴스의 가용 영역(문자열).  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["availability_zone"]
```  
**backup\$1retention\$1period**  <a name="attributes-json-opsworks-stack-rds-backup"></a>
백업 보존 기간, 일 단위(숫자).  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["backup_retention_period"]
```  
**db\$1instance\$1class**  <a name="attributes-json-opsworks-stack-rds-db-class"></a>
`db.m1.small`과 같은 DB 인스턴스 클래스(문자열).  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["db_instance_class"]
```  
**db\$1instance\$1identifier**  <a name="attributes-json-opsworks-stack-rds-db-id"></a>
사용자 정의 DB 인스턴스 식별자(문자열).  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["db_instance_identifier"]
```  
**db\$1instance\$1status**  <a name="attributes-json-opsworks-stack-rds-db-status"></a>
인스턴스의 상태(문자열). 자세한 내용은 [DB 인스턴스](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.html)를 참조하세요.  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["db_instance_status"]
```  
**db\$1name**  <a name="attributes-json-opsworks-stack-rds-db-name"></a>
사용자 정의 DB 이름(문자열).  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["db_name"]
```  
**db\$1parameter\$1groups**  <a name="attributes-json-opsworks-stack-rds-db-param"></a>
각 파라미터 그룹에 하나씩 포함 객체의 목록이 포함된 인스턴스의 DB 파라미터 그룹. 자세한 내용은 [DB 파라미터 그룹 작업](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.html)을 참조하세요. 각 객체에는 다음 속성이 포함됩니다.    
**db\$1parameter\$1group\$1name**  <a name="attributes-json-opsworks-stack-rds-db-param-name"></a>
그룹 이름(문자열).  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["db_parameter_groups"][j"]["db_parameter_group_name"]
```  
**parameter\$1apply\$1status**  <a name="attributes-json-opsworks-stack-rds-db-param-status"></a>
적용 상태(문자열).  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["db_parameter_groups"][j"]["parameter_apply_status"]
```  
**db\$1security\$1groups**  <a name="attributes-json-opsworks-stack-rds-db-security"></a>
각 보안 그룹에 하나씩 포함 객체의 목록이 포함된 인스턴스의 데이터베이스 보안 그룹. 자세한 내용은 [DB 보안 그룹 작업](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithSecurityGroups.html)을 참조하세요. 각 객체에는 다음 속성이 포함됩니다.    
**db\$1security\$1group\$1name**  <a name="attributes-json-opsworks-stack-rds-db-security-name"></a>
보안 그룹 이름(문자열).  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["db_security_groups"][j"]["db_security_group_name"]
```  
**status**  <a name="attributes-json-opsworks-stack-rds-db-security-status"></a>
상태(문자열).  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["db_security_groups"][j"]["status"]
```  
**db\$1user**  <a name="attributes-json-opsworks-stack-rds-db-user"></a>
사용자 정의 마스터 사용자 이름(문자열).  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["db_user"]
```  
**engine**  <a name="attributes-json-opsworks-stack-rds-engine"></a>
`mysql(5.6.13)`과 같은 데이터베이스 엔진(문자열).  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["engine"]
```  
**instance\$1create\$1time**  <a name="attributes-json-opsworks-stack-rds-create"></a>
`2014-04-15T16:13:34Z`와 같은 인스턴스 생성 시간(문자열).  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["instance_create_time"]
```  
**license\$1model**  <a name="attributes-json-opsworks-stack-rds-license"></a>
`general-public-license`와 같은 인스턴스의 라이선스 모델(문자열).  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["license_model"]
```  
**multi\$1az**  <a name="attributes-json-opsworks-stack-rds-multi-az"></a>
다중 AZ 배포가 활성화되었는지 여부(부울).  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["multi_az"]
```  
**option\$1group\$1memberships**  <a name="attributes-json-opsworks-stack-rds-option"></a>
각 옵션 그룹에 하나씩 포함 객체의 목록이 포함된 인스턴스의 옵션 그룹 멤버십. 자세한 내용은 [옵션 그룹 작업](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithOptionGroups.html)을 참조하세요. 각 객체에는 다음 속성이 포함됩니다.    
**option\$1group\$1name**  <a name="attributes-json-opsworks-stack-rds-option-name"></a>
그룹의 이름(문자열).  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["option_group_memberships"][j"]["option_group_name"]
```  
**status**  <a name="attributes-json-opsworks-stack-rds-option-status"></a>
그룹의 상태(문자열).  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["option_group_memberships"][j"]["status"]
```  
**포트**  <a name="attributes-json-opsworks-stack-rds-port"></a>
데이터베이스 서버의 포트(숫자).  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["port"]
```  
**preferred\$1backup\$1window**  <a name="attributes-json-opsworks-stack-rds-backup-window"></a>
`06:26-06:56`과 같은 기본 일일 백업 기간(문자열).  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["preferred_backup_window"]
```  
**preferred\$1maintenance\$1window**  <a name="attributes-json-opsworks-stack-rds-maintenance"></a>
`thu:07:13-thu:07:43`과 같은 기본 주별 유지 관리 기간(문자열).  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["preferred_maintenance_window"]
```  
**publicly\$1accessible**  <a name="attributes-json-opsworks-stack-rds-public"></a>
데이터베이스에 공개적으로 액세스할 수 있는지 여부(부울).  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["publicly_accessible"]
```  
**read\$1replica\$1db\$1instance\$1identifiers**  <a name="attributes-json-opsworks-stack-rds-read"></a>
읽기 전용 복제본 인스턴스 식별자의 목록(문자열의 목록). 자세한 내용은 [읽기 전용 복제본 작업](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)을 참조하세요.  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["read_replica_db_instance_identifiers"]
```  
**리전**  <a name="attributes-json-opsworks-stack-rds-region"></a>
`us-west-2`와 같은 AWS 리전(문자열).  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["region"]
```  
**status\$1infos**  <a name="attributes-json-opsworks-stack-rds-status"></a>
상태 정보의 목록(문자열의 목록).  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["status_infos"]
```  
**vpc\$1security\$1groups**  <a name="attributes-json-opsworks-stack-rds-vpc-sec"></a>
VPC 보안 그룹의 목록(문자열의 목록).  

```
node["opsworks"]["stack"]["rds_instances"]["i"]["vpc_security_groups"]
```

**vpc\$1id**  <a name="attributes-json-opsworks-stack-vpc-id"></a>
VPC ID(문자열). 인스턴스가 VPC에 없는 경우, 이 값은 `null`입니다.  

```
node["opsworks"]["stack"]["vpc_id"]
```

# 그 밖의 최상위 opsworks 속성
<a name="attributes-json-opsworks-other"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

이 섹션에는 하위 속성이 없는 `opsworks` 속성이 포함되어 있습니다.

**activity**  <a name="attributes-json-opsworks-activity"></a>
`deploy`와 같이 속성에 연결된 활동(문자열).  

```
node["opsworks"]["activity"]
```

**agent\$1version**  <a name="attributes-json-opsworks-agent"></a>
인스턴스의 OpsWorks 에이전트 버전(문자열).  

```
node["opsworks"]["agent_version"]
```

**deploy\$1chef\$1provider**  
배포된 앱의 디렉터리 구조에 영향을 미치는 Chef 배포 공급자(문자열). 이 속성을 다음 중 하나로 설정할 수 있습니다.  
+ `Branch`
+ `Revision`
+ `Timestamped`(기본값)

```
node["opsworks"]["deploy_chef_provider"]
```

**ruby\$1stack**  <a name="attributes-json-opsworks-ruby-stack"></a>
Ruby 스택(문자열). 기본 설정은 엔터프라이즈 버전입니다(`ruby_enterprise`). MRI 버전의 경우, 이 속성을 `ruby`로 설정합니다.  

```
node["opsworks"]["ruby_stack"]
```

**ruby\$1version**  <a name="attributes-json-opsworks-ruby-version"></a>
애플리케이션이 사용할 Ruby 버전(문자열). 이 속성을 사용하면 메이저 및 마이너 버전만 지정할 수 있습니다. 패치 버전을 지정하려면 적절한 [["ruby"]](attributes-recipes-ruby.md) 속성을 사용해야 합니다. 예제를 포함한 버전 지정 방법에 대한 자세한 정보는 [Ruby 버전](workingcookbook-ruby.md)를 참조하세요. OpsWorks Stacks가 Ruby 버전을 결정하는 방식에 대한 자세한 정보는 내장 속성 파일인 [ruby.rb](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/ruby/attributes/ruby.rb)를 참조하세요.  

```
node["opsworks"]["ruby_version"]
```

**run\$1cookbook\$1tests**  
Chef 11.4 쿡북에서 [minitest-chef-handler](https://github.com/calavera/minitest-chef-handler) 테스트를 실행할지 여부(부울).  

```
node["opsworks"]["run_cookbook_tests"]
```

**sent\$1at**  <a name="attributes-json-opsworks-sent"></a>
이 명령이 인스턴스에 전송된 때(숫자).  

```
node["opsworks"]["sent_at"]
```

**배포**  <a name="attributes-json-opsworks-deployment"></a>
이 속성이 배포 활동에 연결된 경우, `deployment`는 배포를 고유하게 식별하는 OpsWorks Stacks 생성 GUID인 배포 ID로 설정됩니다(문자열). 그렇지 않으면 이 속성은 null로 설정됩니다.  

```
node["opsworks"]["deployment"]
```

# opsworks\$1custom\$1cookbooks 속성
<a name="attributes-json-custom"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

스택의 사용자 지정 쿡북을 지정하는 속성을 포함합니다.

**enabled**  <a name="attributes-json-custom-enabled"></a>
사용자 지정 쿡북이 활성화되었는지 여부(부울).  

```
node["opsworks_custom_cookbooks"]["enabled"]
```

**recipes**  <a name="attributes-json-custom-recipes"></a>
사용자 지정 레시피를 포함하여 `cookbookname::recipename` 형식을 사용해 이 명령에 실행할 레시피의 목록(문자열의 목록).  

```
node["opsworks_custom_cookbooks"]["recipes"]
```

# dependencies 속성
<a name="attributes-json-dependencies"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

`update_dependencies` [스택 명령](workingstacks-commands.md)에 연결된 몇몇 속성을 포함합니다.

**gem\$1binary**  
Gems 이진수의 위치(문자열).

**upgrade\$1debs**  
Debs 패키지를 업그레이드할지 여부(부울).

**update\$1debs**  
Debs 패키지를 업데이트할지 여부(부울).

# ganglia 속성
<a name="attributes-json-ganglia"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

Ganglia 통계 웹 페이지에 액세스하는 방법을 지정하는 몇 가지 속성이 포함된 **web** 속성을 포함합니다.

**암호**  <a name="attributes-json-ganglia-password"></a>
통계 페이지에 액세스하는 데 필요한 암호(문자열).  

```
node["ganglia"]["web"]["password"]
```

**url**  <a name="attributes-json-ganglia-url"></a>
`"/ganglia"`와 같은 통계 페이지의 URL 경로(문자열). 완전한 URL은 `http://DNSNameURLPath`이며, 여기서 `DNSName`은 연결된 인스턴스의 DNS 이름입니다.  

```
node["ganglia"]["web"]["url"]
```

**user**  <a name="attributes-json-ganglia-user"></a>
통계 페이지에 액세스하는 데 필요한 사용자 이름(문자열).  

```
node["ganglia"]["web"]["user"]
```

# mysql 속성
<a name="attributes-json-mysql"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

MySQL 데이터베이스 서버 구성을 지정하는 속성 세트를 포함합니다.

**클라이언트**  <a name="attributes-json-mysql-clients"></a>
클라이언트 IP 주소의 목록(문자열의 목록).  

```
node["mysql"]["clients"]
```

**server\$1root\$1password**  <a name="attributes-json-mysql-root-pwd"></a>
루트 암호(문자열).  

```
node["mysql"]["server_root_password"]
```

# passenger 속성
<a name="attributes-json-passenger"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

Phusion Passenger 구성을 지정하는 속성 세트를 포함합니다.

**gem\$1bin**  <a name="attributes-json-passenger-gem"></a>
RubyGems 바이너리의 위치(예: `"/usr/local/bin/gem"`(문자열))  

```
node["passenger"]["gem_bin"]
```

**max\$1pool\$1size**  <a name="attributes-json-passenger-max-pool"></a>
최대 풀 크기(숫자).  

```
node["passenger"]["max_pool_size"]
```

**ruby\$1bin**  <a name="attributes-json-passenger-ruby"></a>
Ruby 바이너리의 위치(예: `"/usr/local/bin/ruby"`)  

```
node["passenger"]["ruby_bin"]
```

**버전**  <a name="attributes-json-passenger-version"></a>
Passenger 버전(문자열).  

```
node["passenger"]["version"]
```

# opsworks\$1bundler 속성
<a name="attributes-json-bundler"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

[Bundler](http://gembundler.com/) 지원을 지정하는 요소를 포함합니다.

**manage\$1package**  <a name="attributes-json-bundler-manage"></a>
Bundler를 설치 및 관리할지 여부(부울).  

```
node["opsworks_bundler"]["manage_package"]
```

**버전**  <a name="attributes-json-bundler-version"></a>
bundler 버전(문자열).  

```
node["opsworks_bundler"]["version"]
```

# deploy 속성
<a name="attributes-json-deploy"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

속성이 [Deploy 이벤트](workingcookbook-events.md) 또는 [레시피 실행 스택 명령](workingstacks-commands.md)에 연결된 경우, `deploy` 속성에는 앱의 짧은 이름으로 명명된, 배포된 각 앱의 속성이 포함됩니다. 각 앱 속성은 다음 속성을 포함합니다.


****  

|  |  |  | 
| --- |--- |--- |
| [애플리케이션](#attributes-json-deploy-app-app) | [application\$1type](#attributes-json-deploy-app-type) | [auto\$1bundle\$1on\$1deploy](#attributes-json-deploy-app-auto) | 
| [데이터베이스](#attributes-json-deploy-app-db) | [deploy\$1to](#attributes-json-deploy-app-deploy-to) | [domains](#attributes-json-deploy-app-domains) | 
| [document\$1root](#attributes-json-deploy-app-root) | [environment\$1variables](#attributes-json-deploy-app-environment) | [그룹](#attributes-json-deploy-app-group) | 
| [keep\$1releases](#attributes-json-deploy-app-keep-releases) | [memcached](#attributes-json-deploy-app-memcached) | [마이그레이션](#attributes-json-deploy-app-migrate) | 
| [mounted\$1at](#attributes-json-deploy-app-mounted) | [purge\$1before\$1symlink](#attributes-json-deploy-app-purge-before-symlink) | [rails\$1env](#attributes-json-deploy-app-ssl-rails) | 
| [restart\$1command](#attributes-json-deploy-app-restart) | [scm](#attributes-json-deploy-app-scm) | [ssl\$1certificate](#attributes-json-deploy-app-ssl-cert) | 
| [ssl\$1certificate\$1ca](#attributes-json-deploy-app-ssl-ca) | [ssl\$1certificate\$1key](#attributes-json-deploy-app-ssl-key) | [ssl\$1support](#attributes-json-deploy-app-ssl-supp) | 
| [스택](#attributes-json-deploy-app-stack) | [symlink\$1before\$1migrate](#attributes-json-deploy-app-symlink-migrate) | [symlinks](#attributes-json-deploy-app-symlinks) | 
| [user](#attributes-json-deploy-app-user) |  |  | 

**애플리케이션**  <a name="attributes-json-deploy-app-app"></a>
`"simplephp"`와 같은 앱의 slug 이름(문자열).  

```
node["deploy"]["appshortname"]["application"]
```

**application\$1type**  <a name="attributes-json-deploy-app-type"></a>
앱 유형(문자열). 가능한 값은 다음과 같습니다.  
+ `java`: Java 앱
+ `nodejs`: Node.js 앱
+ `php`: PHP 앱
+ `rails`: Ruby on Rails 앱
+ `web`: 정적 HTML 페이지
+ `other`: 그 밖의 모든 애플리케이션 유형

```
node["deploy"]["appshortname"]["application_type"]
```

**auto\$1bundle\$1on\$1deploy**  <a name="attributes-json-deploy-app-auto"></a>
Rails 애플리케이션의 경우, 배포 도중 bundler를 실행할지 여부(부울).  

```
node["deploy"]["appshortname"]["auto_bundle_on_deploy"]
```

**데이터베이스**  <a name="attributes-json-deploy-app-db"></a>
앱의 데이터베이스를 연결하는 데 필요한 정보를 포함합니다. 앱에 연결된 데이터베이스 계층이 있는 경우 OpsWorks Stacks는 이러한 속성에 적절한 값을 자동으로 할당합니다.    
**어댑터**  
`mysql`과 같은 데이터베이스 어댑터(문자열).  

```
node["deploy"]["appshortname"]["database"]["adapter"]
```  
**데이터베이스**  <a name="attributes-json-deploy-app-db-db"></a>
`"simplephp"` 등 일반적으로 앱의 slug 이름인 데이터베이스 이름(문자열).  

```
node["deploy"]["appshortname"]["database"]["database"]
```  
**data\$1source\$1provider**  
데이터 원본: `mysql` 또는 `rds`(문자열).  

```
node["deploy"]["appshortname"]["database"]["data_source_provider"]
```  
**host**  <a name="attributes-json-deploy-app-db-host"></a>
데이터베이스 호스트의 IP 주소(문자열).  

```
node["deploy"]["appshortname"]["database"]["host"]
```  
**암호**  <a name="attributes-json-deploy-app-db-pwd"></a>
데이터베이스 암호(문자열).  

```
node["deploy"]["appshortname"]["database"]["password"]
```  
**포트**  
데이터베이스 포트(숫자).  

```
node["deploy"]["appshortname"]["database"]["port"]
```  
**reconnect**  <a name="attributes-json-deploy-app-db-reconnect"></a>
Rails 애플리케이션의 경우, 연결이 더 이상 존재하지 않을 때 애플리케이션이 다시 연결해야 하는지 여부(부울).  

```
node["deploy"]["appshortname"]["database"]["reconnect"]
```  
**사용자 이름**  <a name="attributes-json-deploy-app-db-user"></a>
사용자 이름(문자열).  

```
node["deploy"]["appshortname"]["database"]["username"]
```

**deploy\$1to**  <a name="attributes-json-deploy-app-deploy-to"></a>
앱을 배포할 위치(예: `"/srv/www/simplephp"`(문자열))  

```
node["deploy"]["appshortname"]["deploy_to"]
```

**domains**  <a name="attributes-json-deploy-app-domains"></a>
앱의 도메인 목록(문자열의 목록).  

```
node["deploy"]["appshortname"]["domains"]
```

**document\$1root**  <a name="attributes-json-deploy-app-root"></a>
기본이 아닌 루트를 지정하는 경우에는 문서 루트, 기본 루트를 사용하는 경우에는 null(문자열).  

```
node["deploy"]["appshortname"]["document_root"]
```

**environment\$1variables**  <a name="attributes-json-deploy-app-environment"></a>
앱에 대해 정의된 사용자 지정 환경 변수를 나타내는 최대 20개의 속성 모음. 앱의 환경 변수를 정의하는 방법에 대한 자세한 정보는 [앱 추가](workingapps-creating.md) 단원을 참조하세요. 각 속성 이름은 환경 변수 이름으로 설정되고 해당 값은 변수의 값으로 설정되므로 다음 구문을 사용하여 특정 값 단원을 참조할 수 있습니다.  

```
node["deploy"]["appshortname"]["environment_variables"]["variable_name"]
```

**그룹**  <a name="attributes-json-deploy-app-group"></a>
앱의 그룹(문자열).  

```
node["deploy"]["appshortname"]["group"]
```

**keep\$1releases**  <a name="attributes-json-deploy-app-keep-releases"></a>
 OpsWorks Stacks가 저장할 앱 배포 수(숫자). 이 속성은 앱을 롤백할 수 있는 횟수를 제어합니다. 기본적으로 이 속성은 전역 값인 [deploy\$1keep\$1releases ](attributes-recipes-deploy.md#attributes-recipes-deploy-global-keep-releases)로 설정되며, 기본값은 5입니다. `keep_releases`를 재정의하여 특정 애플리케이션의 저장된 배포 수를 지정할 수 있습니다.  

```
node["deploy"]["appshortname"]["keep_releases"]
```

**memcached**  <a name="attributes-json-deploy-app-memcached"></a>
memcached 구성을 정의하는 두 가지 속성이 포함됩니다.    
**host**  <a name="attributes-json-deploy-app-memcached-host"></a>
Memcached 서버 인스턴스의 IP 주소(문자열).  

```
node["deploy"]["appshortname"]["memcached"]["host"]
```  
**포트**  <a name="attributes-json-deploy-app-memcached-port"></a>
memcached 서버가 수신 대기하는 포트(숫자).  

```
node["deploy"]["appshortname"]["memcached"]["port"]
```

**마이그레이션**  <a name="attributes-json-deploy-app-migrate"></a>
Rails 애플리케이션의 경우, 마이그레이션을 실행할지 여부(부울).  

```
node["deploy"]["appshortname"]["migrate"]
```

**mounted\$1at**  <a name="attributes-json-deploy-app-mounted"></a>
기본이 아닌 마운트 포인트를 지정하는 경우에는 앱의 마운트 루트, 기본 마운트 포인트를 사용하는 경우에는 null(문자열).  

```
node["deploy"]["appshortname"]["mounted_at"]
```

**purge\$1before\$1symlink**  <a name="attributes-json-deploy-app-purge-before-symlink"></a>
Rails 앱의 경우, symlink 생성 전에 삭제할 경로 어레이(문자열의 목록).  

```
node["deploy"]["appshortname"]["purge_before_symlink"]
```

**rails\$1env**  <a name="attributes-json-deploy-app-ssl-rails"></a>
Rails 앱 서버 인스턴스의 경우, `"production"`과 같은 rails 환경(문자열).  

```
node["deploy"]["appshortname"]["rails_env"]
```

**restart\$1command**  <a name="attributes-json-deploy-app-restart"></a>
`"echo 'restarting app'"` 등 앱이 다시 시작될 때 실행할 명령.  

```
node["deploy"]["appshortname"]["restart_command"]
```

**scm**  <a name="attributes-json-deploy-app-scm"></a>
OpsWorks가 소스 제어 리포지토리에서 앱을 배포하는 데 사용하는 정보를 지정하는 속성 세트를 포함합니다. 속성은 리포지토리 유형에 따라 다릅니다.    
**암호**  <a name="attributes-json-deploy-app-scm-pwd"></a>
프라이빗 리포지토리의 경우에는 암호, 퍼블릭 리포지토리의 경우 null(문자열). 프라이빗 Amazon S3 버킷의 경우, 이 속성은 보안 키로 설정됩니다.  

```
node["deploy"]["appshortname"]["scm"]["password"]
```  
**리포지토리**  <a name="attributes-json-deploy-app-scm-repo"></a>
`"git://github.com/amazonwebservices/opsworks-demo-php-simple-app.git"`와 같은 리포지토리 URL(문자열).  

```
node["deploy"]["appshortname"]["scm"]["repository"]
```  
**개정**  <a name="attributes-json-deploy-app-scm-revision"></a>
리포지토리에 여러 브랜치가 있는 경우, 이 속성은 `"version1"`과 같이 앱의 브랜치 또는 버전을 지정합니다(문자열). 그렇지 않으면 null로 설정됩니다.  

```
node["deploy"]["appshortname"]["scm"]["revision"]
```  
**scm\$1type**  <a name="attributes-json-deploy-app-scm-type"></a>
리포지토리 유형(문자열). 가능한 값은 다음과 같습니다.  
+ `"git"`: Git 리포지토리
+ `"svn"`: 하위 버전 리포지토리
+ `"s3"`: Amazon S3 버킷
+ `"archive"`: HTTP 아카이브
+ `"other"`: 기타 리포지토리 유형

```
node["deploy"]["appshortname"]["scm"]["scm_type"]
```  
**ssh\$1key**  <a name="attributes-json-deploy-app-scm-key"></a>
프라이빗 Git 리포지토리에 액세스하는 경우에는 [배포 SSH 키](workingapps-deploykeys.md), 퍼블릭 리포지토리의 경우에는 null(문자열).  

```
node["deploy"]["appshortname"]["scm"]["ssh_key"]
```  
**user**  <a name="attributes-json-deploy-app-scm-user"></a>
프라이빗 리포지토리의 경우에는 사용자 이름, 퍼블릭 리포지토리의 경우 null(문자열). 프라이빗 Amazon S3 버킷의 경우, 이 속성은 액세스 키로 설정됩니다.  

```
node["deploy"]["appshortname"]["scm"]["user"]
```

**ssl\$1certificate**  <a name="attributes-json-deploy-app-ssl-cert"></a>
SSL 지원을 활성화한 경우에는 앱의 SSL 인증서, 그렇지 않은 경우에는 null(문자열).  

```
node["deploy"]["appshortname"]["ssl_certificate"]
```

**ssl\$1certificate\$1ca**  <a name="attributes-json-deploy-app-ssl-ca"></a>
SSL이 활성화된 경우, 중간 인증서 발급 기관 공개 키 또는 클라이언트 인증을 지정하기 위한 속성(문자열).  

```
node["deploy"]["appshortname"]["ssl_certificate_ca"]
```

**ssl\$1certificate\$1key**  <a name="attributes-json-deploy-app-ssl-key"></a>
SSL 지원을 활성화한 경우에는 앱의 SSL 프라이빗 키, 그렇지 않은 경우에는 null(문자열).  

```
node["deploy"]["appshortname"]["ssl_certificate_key"]
```

**ssl\$1support**  <a name="attributes-json-deploy-app-ssl-supp"></a>
SSL이 지원되는지 여부(부울).  

```
node["deploy"]["appshortname"]["ssl_support"]
```

**스택**  <a name="attributes-json-deploy-app-stack"></a>
배포 중에 앱 서버를 다시 로드할지 지정하는 하나의 부울 속성 `needs_reload`를 포함합니다.  

```
node["deploy"]["appshortname"]["stack"]["needs_reload"]
```

**symlink\$1before\$1migrate**  <a name="attributes-json-deploy-app-symlink-migrate"></a>
Rails 앱의 경우, `"link":"target"` 쌍으로 마이그레이션을 실행하기 전에 생성할 symlink를 포함합니다.  

```
node["deploy"]["appshortname"]["symlink_before_migrate"]
```

**symlinks**  <a name="attributes-json-deploy-app-symlinks"></a>
`"link":"target"` 쌍으로 배포의 symlink를 포함합니다.  

```
node["deploy"]["appshortname"]["symlinks"]
```

**user**  <a name="attributes-json-deploy-app-user"></a>
앱의 사용자(문자열).  

```
node["deploy"]["appshortname"]["user"]
```

# 기타 최상위 속성
<a name="attributes-json-other"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

이 섹션에는 하위 속성이 없는 최상위 스택 구성 속성이 포함되어 있습니다.

**rails 속성**  <a name="attributes-json-rails"></a>
서버의 최대 풀 크기를 지정하는 **max\$1pool\$1size** 속성을 포함합니다(숫자). 속성 값은 OpsWorks Stacks에서 설정하며 인스턴스 유형에 따라 다르지만 사용자 지정 JSON 또는 사용자 지정 속성 파일을 사용하여 [재정](workingcookbook-attributes.md)의할 수 있습니다.  

```
node["rails"]["max_pool_size"]
```

**recipes 속성**  <a name="attributes-json-recipes"></a>
`"cookbookname::recipename"` 형식을 사용해 이 활동이 실행한 내장 레시피의 목록(문자열의 목록).  

```
node["recipes"]
```

**opsworks\$1rubygems 속성**  <a name="attributes-json-rubygems"></a>
RubyGems 버전을 지정하는 **버전** 요소를 포함합니다(문자열).  

```
node["opsworks_rubygems"]["version"]
```

**languages 속성**  <a name="attributes-json-lang"></a>
**ruby**와 같이 언어에 명명된, 설치된 각 언어의 속성을 포함합니다. 속성은 `"/usr/bin/ruby"`(문자열) 등의 설치 폴더를 지정하는 **ruby\$1bin**과 같은 속성을 포함하는 객체입니다. 

**ssh\$1users 속성**  <a name="attributes-json-ssh"></a>
SSH 권한을 부여받은 사용자 한 명을 각각 설명하는 속성 세트를 포함합니다. 각 속성의 이름은 사용자의 Unix ID로 지정됩니다. OpsWorks Stacks는 `"2001"`와 같이 2000-4000 범위의 각 사용자에 대해 고유한 ID를 생성하고 모든 인스턴스에서 해당 ID를 가진 사용자를 생성합니다. 는 2000-4000 범위를 OpsWorks 예약하므로 (쿡북 레시피 OpsWorks 를 사용하거나 IAM OpsWorks 에서 사용자를 가져와서) 외부에서 생성하는 사용자는 OpsWorks Stacks에서 다른 사용자에 대해 덮어쓰는 UIDs를 가질 수 있습니다. OpsWorks Stacks 콘솔에서 사용자를 생성하고 액세스를 관리하는 것이 가장 좋습니다. OpsWorks Stacks 외부에서 사용자를 생성하는 경우 4000보다 큰 *UnixID* 값을 사용합니다.  
각 속성은 다음 속성을 포함합니다.    
**이메일**  
 사용자의 이메일 주소(문자열).  

```
node["ssh_users"]["UnixID"]["email"]
```  
**public\$1key**  
 사용자의 퍼블릭 SSH 키(문자열).  

```
node["ssh_users"]["UnixID"]["public_key"]
```  
**sudoer**  
 사용자에게 sudo 권한이 있는지 여부(부울).  

```
node["ssh_users"]["UnixID"]["sudoer"]
```  
**이름**  
 사용자 이름(문자열).  

```
node["ssh_users"]["UnixID"]["name"]
```

# 내장 쿡북 속성
<a name="attributes-recipes"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이러한 속성 대부분은 Linux 스택에서만 사용할 수 있습니다.

대부분의 내장 레시피에는 다양한 설정을 정의하는 하나 이상의 [속성 파일](workingcookbook-installingcustom-components-attributes.md)이 있습니다. 사용자 지정 레시피의 이러한 설정에 액세스하고 사용자 지정 JSON을 사용해 재정의할 수 있습니다. 일반적으로 OpsWorks Stacks에서 지원하는 다양한 서버 기술의 구성을 제어하는 속성에 액세스하거나 재정의해야 합니다. 이 섹션에서는 이러한 속성을 요약합니다. 완전한 속성 파일과 연결된 레시피 및 템플릿은 [https://github.com/aws/opsworks-cookbooks.git](https://github.com/aws/opsworks-cookbooks.git)에 나와 있습니다.

**참고**  
모든 내장 레시피 속성은 `default` 유형입니다.

**Topics**
+ [apache2 속성](attributes-recipes-apache.md)
+ [deploy 속성](attributes-recipes-deploy.md)
+ [haproxy 속성](attributes-recipes-haproxy.md)
+ [memcached 속성](attributes-recipes-mem.md)
+ [mysql 속성](attributes-recipes-mysql.md)
+ [nginx 속성](attributes-recipes-nginx.md)
+ [opsworks\$1berkshelf 속성](attributes-recipes-berkshelf.md)
+ [opsworks\$1java 속성](attributes-recipes-java.md)
+ [passenger\$1apache2 Attributes](attributes-recipes-passenger.md)
+ [ruby 속성](attributes-recipes-ruby.md)
+ [unicorn 속성](attributes-recipes-unicorn.md)

# apache2 속성
<a name="attributes-recipes-apache"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이러한 속성은 Linux 스택에서만 사용할 수 있습니다.

[apache2 속성](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/apache2/attributes/apache.rb)은 [Apache HTTP 서버](http://httpd.apache.org/) 구성을 지정합니다. 자세한 정보는 [Apache 핵심 기능](http://httpd.apache.org/docs/current/mod/core.html) 단원을 참조하세요. 내장 속성을 재정의해 사용자 지정 값을 지정하는 방법에 대한 자세한 정보는 [속성 재정의](workingcookbook-attributes.md) 단원을 참조하세요.


****  

|  |  |  | 
| --- |--- |--- |
| [이진수 ](#attributes-recipes-apache-bin) | [contact ](#attributes-recipes-apache-contact) | [deflate\$1types](#attributes-recipes-apache-deflate) | 
| [dir ](#attributes-recipes-apache-dir) | [document\$1root ](#attributes-recipes-apache-doc-root) | [그룹 ](#attributes-recipes-apache-group) | 
| [hide\$1info\$1headers ](#attributes-recipes-apache-hide) | [icondir ](#attributes-recipes-apache-icondir) | [init\$1script ](#attributes-recipes-apache-init-script) | 
| [keepalive ](#attributes-recipes-apache-keep) | [keepaliverequests ](#attributes-recipes-apache-keep-requests) | [keepalivetimeout ](#attributes-recipes-apache-keep-timeout) | 
| [lib\$1dir ](#attributes-recipes-apache-lib-dir) | [libexecdir ](#attributes-recipes-apache-libexecdir) | [listen\$1ports ](#attributes-recipes-apache-ports) | 
| [log\$1dir ](#attributes-recipes-apache-log-dir) | [logrotate 속성](#attributes-recipes-apache-log) | [pid\$1file ](#attributes-recipes-apache-pidfile) | 
| [prefork 속성](#attributes-recipes-apache-prefork) | [serversignature ](#attributes-recipes-apache-sig) | [servertokens ](#attributes-recipes-apache-tokens) | 
| [제한 시간 ](#attributes-recipes-apache-timeout) | [traceenable ](#attributes-recipes-apache-trace) | [user ](#attributes-recipes-apache-user) | 
| [버전](#attributes-recipes-apache-version) | [worker 속성](#attributes-recipes-apache-worker) |  | 

**이진수 **  <a name="attributes-recipes-apache-bin"></a>
Apache 이진수의 위치(문자열). 기본값은 `'/usr/sbin/httpd'`입니다.  

```
node[:apache][:binary]
```

**contact **  <a name="attributes-recipes-apache-contact"></a>
이메일 연락처(문자열). 기본값은 더미 주소인 `'ops@example.com'`입니다.  

```
node[:apache][:contact]
```

**deflate\$1types**  <a name="attributes-recipes-apache-deflate"></a>
`mod_deflate`에게 브라우저가 지원하는 지정된 Mime 유형에 대해 압축을 활성화할 것을 지시합니다(문자열의 목록). 기본값은 다음과 같습니다.  

```
['application/javascript',
 'application/json',
 'application/x-javascript',
 'application/xhtml+xml',
 'application/xml',
 'application/xml+rss',
 'text/css',
 'text/html',
 'text/javascript',
 'text/plain',
 'text/xml']
```
압축은 보안 위험을 초래할 수 있습니다. 압축을 완전히 비활성화하려면 이 속성을 다음과 같이 설정하세요.  

```
node[:apache][:deflate_types] = []
```

```
node[:apache][:deflate_types]
```

**dir **  <a name="attributes-recipes-apache-dir"></a>
서버의 루트 디렉터리(문자열). 기본값은 다음과 같습니다.  
+ Amazon Linux 및 Red Hat Enterprise Linux(RHEL): `'/etc/httpd'`
+ Ubuntu: `'/etc/apache2'`

```
node[:apache][:dir]
```

**document\$1root **  <a name="attributes-recipes-apache-doc-root"></a>
문서 루트(문자열). 기본값은 다음과 같습니다.  
+ Amazon Linux 및 RHEL: `'/var/www/html'`
+ Ubuntu: `'/var/www'`

```
node[:apache][:document_root]
```

**그룹 **  <a name="attributes-recipes-apache-group"></a>
그룹 이름(문자열). 기본값은 다음과 같습니다.  
+ Amazon Linux 및 RHEL: `'apache'`
+ Ubuntu: `'www-data'`

```
node[:apache][:group]
```

**hide\$1info\$1headers **  <a name="attributes-recipes-apache-hide"></a>
HTTP 헤더에서 버전 및 모듈 정보를 생략할지 여부(`'true'`/`'false'`)(문자열). 기본값은 `'true'`입니다.  

```
node[:apache][:hide_info_headers]
```

**icondir **  <a name="attributes-recipes-apache-icondir"></a>
아이콘 디렉터리(문자열). 기본값은 다음과 같습니다.  
+ Amazon Linux 및 RHEL: `'/var/www/icons/'`
+ Ubuntu: `'/usr/share/apache2/icons'`

```
node[:apache][:icondir]
```

**init\$1script **  <a name="attributes-recipes-apache-init-script"></a>
초기화 스크립트(문자열). 기본값은 다음과 같습니다.  
+ Amazon Linux 및 RHEL: `'/etc/init.d/httpd'`
+ Ubuntu: `'/etc/init.d/apache2'`

```
node[:apache][:init_script]
```

**keepalive **  <a name="attributes-recipes-apache-keep"></a>
연결 유지를 활성화할지 여부(문자열). 가능한 값은 `'On'`과 `'Off'`입니다(문자열). 기본값은 `'Off'`입니다.  

```
node[:apache][:keepalive]
```

**keepaliverequests **  <a name="attributes-recipes-apache-keep-requests"></a>
Apache가 동시에 처리할 연결 유지 요청의 최대 개수(숫자). 기본값은 `100`입니다.  

```
node[:apache][:keepaliverequests]
```

**keepalivetimeout **  <a name="attributes-recipes-apache-keep-timeout"></a>
연결을 닫기 전에 Apache가 요청을 기다리는 시간(숫자). 기본값은 `3`입니다.  

```
node[:apache][:keepalivetimeout]
```

**lib\$1dir **  <a name="attributes-recipes-apache-lib-dir"></a>
객체 코드 라이브러리가 포함된 디렉터리(문자열). 기본값은 다음과 같습니다.  
+ Amazon Linux(x86): `'/usr/lib/httpd'`
+ Amazon Linux(x64) 및 RHEL: `'/usr/lib64/httpd'`
+ Ubuntu: `'/usr/lib/apache2'`

```
node[:apache][:lib_dir]
```

**libexecdir **  <a name="attributes-recipes-apache-libexecdir"></a>
프로그램 실행 파일이 포함된 디렉터리(문자열). 기본값은 다음과 같습니다.  
+ Amazon Linux(x86): `'/usr/lib/httpd/modules'`
+ Amazon Linux(x64) 및 RHEL: `'/usr/lib64/httpd/modules'`
+ Ubuntu: `'/usr/lib/apache2/modules'`

```
node[:apache][:libexecdir]
```

**listen\$1ports **  <a name="attributes-recipes-apache-ports"></a>
서버가 수신하는 포트의 목록(문자열의 목록). 기본값은 `[ '80','443' ]`입니다.  

```
node[:apache][:listen_ports]
```

**log\$1dir **  <a name="attributes-recipes-apache-log-dir"></a>
로그 디렉터리(문자열). 기본값은 다음과 같습니다.  
+ Amazon Linux 및 RHEL: `'/var/log/httpd'`
+ Ubuntu: `'/var/log/apache2'`

```
node[:apache][:log_dir]
```

**logrotate 속성**  <a name="attributes-recipes-apache-log"></a>
이러한 속성은 로그 파일을 교체하는 방법을 지정합니다.    
**delaycompress **  <a name="attributes-recipes-apache-log-delay"></a>
다음 교체 주기가 시작될 때까지 닫힌 로그 파일 압축을 지연할지 여부(`'true'`/`'false'`)(문자열). 기본값은 `'true'`입니다.  

```
node[:apache][:logrotate][:delaycompress]
```  
**그룹 **  <a name="attributes-recipes-apache-log-group"></a>
로그 파일의 그룹(문자열). 기본값은 `'adm'`입니다.  

```
node[:apache][:logrotate][:group]
```  
**모드 **  <a name="attributes-recipes-apache-log-mode"></a>
로그 파일의 모드(문자열). 기본값은 `'640'`입니다.  

```
node[:apache][:logrotate][:mode]
```  
**owner **  <a name="attributes-recipes-apache-log-owner"></a>
로그 파일의 소유자(문자열). 기본값은 `'root'`입니다.  

```
node[:apache][:logrotate][:owner]
```  
**rotate **  <a name="attributes-recipes-apache-log-rotate"></a>
닫힌 로그 파일이 제거되기 전 교체 주기의 수(문자열). 기본값은 `'30'`입니다.  

```
node[:apache][:logrotate][:rotate]
```  
**schedule **  <a name="attributes-recipes-apache-log-schedule"></a>
교체 일정(문자열). 가능한 값은 다음과 같습니다.  
+ `'daily'`
+ `'weekly'`
+ `'monthly'`
기본값은 `'daily'`입니다.  

```
node[:apache][:logrotate][:schedule]
```

**pid\$1file **  <a name="attributes-recipes-apache-pidfile"></a>
데몬의 프로세스 ID가 포함된 파일(문자열). 기본값은 다음과 같습니다.  
+ Amazon Linux 및 RHEL: `'/var/run/httpd/httpd.pid'`
+ Ubuntu: `'/var/run/apache2.pid'`

```
node[:apache][:pid_file]
```

**prefork 속성**  <a name="attributes-recipes-apache-prefork"></a>
이러한 속성은 프리포킹(pre-forking) 구성을 지정합니다.    
**maxclients **  <a name="attributes-recipes-apache-prefork-maxclients"></a>
처리할 동시 요청의 최대 수(숫자). 기본값은 `400`입니다.  
이 속성은 Amazon Linux 또는 RHEL을 실행하는 인스턴스에만 사용하세요. 인스턴스가 Ubuntu 14.04 LTS를 실행 중인 경우, [maxrequestworkers](#attributes-recipes-apache-prefork-maxrequestworkers)를 사용하세요.

```
node[:apache][:prefork][:maxclients]
```  
**maxrequestsperchild **  <a name="attributes-recipes-apache-prefork-maxrequests"></a>
하위 서버 프로세스가 처리할 요청의 최대 수(숫자). 기본값은 `10000`입니다.  

```
node[:apache][:prefork][:maxrequestsperchild]
```  
**maxrequestworkers**  <a name="attributes-recipes-apache-prefork-maxrequestworkers"></a>
처리할 동시 요청의 최대 수(숫자). 기본값은 `400`입니다.  
이 속성은 Ubuntu 14.04 LTS를 실행하는 인스턴스에만 사용하세요. 인스턴스가 Amazon Linux 또는 RHEL을 실행 중인 경우, [maxclients ](#attributes-recipes-apache-prefork-maxclients)를 사용하세요.

```
node[:apache][:prefork][:maxrequestworkers]
```  
**maxspareservers **  <a name="attributes-recipes-apache-prefork-maxspare"></a>
유휴 하위 서버 프로세스의 최대 수(숫자). 기본값은 `32`입니다.  

```
node[:apache][:prefork][:maxspareservers]
```  
**minspareservers **  <a name="attributes-recipes-apache-prefork-minspare"></a>
유휴 하위 서버 프로세스의 최소 수(숫자). 기본값은 `16`입니다.  

```
node[:apache][:prefork][:minspareservers]
```  
**serverlimit **  <a name="attributes-recipes-apache-prefork-limit"></a>
구성할 수 있는 프로세스의 최대 수(숫자). 기본값은 `400`입니다.  

```
node[:apache][:prefork][:serverlimit]
```  
**startservers **  <a name="attributes-recipes-apache-prefork-start"></a>
시작 시 생성될 하위 서버 프로세스의 수(숫자). 기본값은 `16`입니다.  

```
node[:apache][:prefork][:startservers]
```

**serversignature **  <a name="attributes-recipes-apache-sig"></a>
서버 생성 문서의 꼬리말을 구성할지 여부 및 구성 방법을 지정합니다(문자열). 가능한 값은 `'On'`, `'Off'` 및 `'Email'`입니다. 기본값은 `'Off'`입니다.  

```
node[:apache][:serversignature]
```

**servertokens **  <a name="attributes-recipes-apache-tokens"></a>
응답 헤더에 어떤 유형의 서버 버전 정보가 포함되는지 지정합니다(문자열).  
+ `'Full'`: 전체 정보. 예를 들어 Server: Apache/2.4.2 (Unix) PHP/4.2.2 MyMod/1.2 
+ `'Prod'`: 제품 이름. 예를 들어 Server: Apache
+ `'Major'`: 메이저 버전. 예를 들어 Server: Apache/2
+ `'Minor'`: 메이저 및 마이너 버전. 예를 들어 Server: Apache/2.4
+ `'Min'`: 최소 버전. 예를 들어 Server: Apache/2.4.2
+ `'OS'`: 운영 체제 포함 버전. 예를 들어 Server: Apache/2.4.2 (Unix) 
기본값은 `'Prod'`입니다.  

```
node[:apache][:servertokens]
```

**제한 시간 **  <a name="attributes-recipes-apache-timeout"></a>
Apache가 I/O를 기다리는 시간(숫자). 기본값은 `120`입니다.  

```
node[:apache][:timeout]
```

**traceenable **  <a name="attributes-recipes-apache-trace"></a>
`TRACE` 요청을 활성화할지 여부(문자열). 가능한 값은 `'On'`와 `'Off'`입니다. 기본값은 `'Off'`입니다.  

```
node[:apache][:traceenable]
```

**user **  <a name="attributes-recipes-apache-user"></a>
사용자 이름(문자열). 기본값은 다음과 같습니다.  
+ Amazon Linux 및 RHEL: `'apache'`
+ Ubuntu: `'www-data'`

```
node[:apache][:user]
```

**버전**  <a name="attributes-recipes-apache-version"></a>
Apache 버전(문자열). 기본값은 다음과 같습니다.  
+ Amazon Linux: `2.2`
+ Ubuntu 14.04 LTS: `2.4`
+ RHEL: `2.4`

```
node[:apache][:version]
```

**worker 속성**  <a name="attributes-recipes-apache-worker"></a>
이러한 속성은 worker 프로세스 구성을 지정합니다.    
**startservers **  <a name="attributes-recipes-apache-worker-start"></a>
시작 시 생성될 하위 서버 프로세스의 수(숫자). 기본값은 `4`입니다.  

```
node[:apache][:worker][:startservers]
```  
**maxclients **  <a name="attributes-recipes-apache-worker-maxclients"></a>
처리할 동시 요청의 최대 수(숫자). 기본값은 `1024`입니다.  

```
node[:apache][:worker][:maxclients]
```  
**maxsparethreads **  <a name="attributes-recipes-apache-worker-maxspare"></a>
유휴 스레드의 최대 수(숫자). 기본값은 `192`입니다.  

```
node[:apache][:worker][:maxsparethreads]
```  
**minsparethreads **  <a name="attributes-recipes-apache-worker-minspare"></a>
유휴 스레드의 최소 수(숫자). 기본값은 `64`입니다.  

```
node[:apache][:worker][:minsparethreads]
```  
**threadsperchild **  <a name="attributes-recipes-apache-worker-threads"></a>
하위 프로세스당 스레드 수(숫자). 기본값은 `64`입니다.  

```
node[:apache][:worker][:threadsperchild]
```  
**maxrequestsperchild **  <a name="attributes-recipes-apache-worker-maxreq"></a>
하위 서버 프로세스가 처리할 요청의 최대 수(숫자). 기본값은 `10000`입니다.  

```
node[:apache][:worker][:maxrequestsperchild]
```

# deploy 속성
<a name="attributes-recipes-deploy"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

[내장 배포 쿡북의 `deploy.rb` 속성 파일](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/deploy/attributes/deploy.rb)은 `opsworks` 네임스페이스에서 다음 속성을 정의합니다. 배포 디렉터리에 대한 자세한 정보는 [Deploy 레시피](create-custom-deploy.md) 단원을 참조하세요. 내장 속성을 재정의해 사용자 지정 값을 지정하는 방법에 대한 자세한 정보는 [속성 재정의](workingcookbook-attributes.md) 단원을 참조하세요.

**deploy\$1keep\$1releases **  <a name="attributes-recipes-deploy-global-keep-releases"></a>
 OpsWorks Stacks가 저장할 앱 배포 수(숫자)에 대한 전역 설정입니다. 기본값은 5입니다. 이 값은 앱을 롤백할 수 있는 횟수를 제어합니다.  

```
node[:opsworks][:deploy_keep_releases]
```

**그룹 **  
(Linux 한정) 앱의 배포 디렉터리에 대한 `group` 설정(문자열). 기본값은 인스턴스의 운영 체제에 따라 다릅니다.  
+ Ubuntu 인스턴스의 경우, 기본값은 `www-data`입니다.
+ Nginx와 Unicorn을 사용하는 Rails 앱 서버 계층에 속하는 Amazon Linux 또는 RHEL 인스턴스의 경우, 기본값은 `nginx`입니다.
+ 다른 모든 Amazon Linux 또는 RHEL 인스턴스의 경우, 기본값은 `apache`입니다.

```
node[:opsworks][:deploy_user][:group]
```

**user **  
(Linux 한정) 앱의 배포 디렉터리에 대한 `user` 설정(문자열). 기본값은 `deploy`입니다.  

```
node[:opsworks][:deploy_user][:user]
```

# haproxy 속성
<a name="attributes-recipes-haproxy"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이러한 속성은 Linux 스택에서만 사용할 수 있습니다.

[`haproxy` 속성](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/haproxy/attributes/default.rb)은 [HAProxy 서버](http://haproxy.1wt.eu/) 구성을 지정합니다. 자세한 정보는 [HAProxy Docs](http://cbonte.github.io/haproxy-dconv/configuration-1.5.html)를 참조하세요. 내장 속성을 재정의해 사용자 지정 값을 지정하는 방법에 대한 자세한 정보는 [속성 재정의](workingcookbook-attributes.md) 단원을 참조하세요.


****  

|  |  |  | 
| --- |--- |--- |
| [balance ](#attributes-recipes-haproxy-balance) | [check\$1interval ](#attributes-recipes-haproxy-interval) | [client\$1timeout ](#attributes-recipes-haproxy-client-timeout) | 
| [connect\$1timeout ](#attributes-recipes-haproxy-connect-timeout) | [default\$1max\$1connections ](#attributes-recipes-haproxy-default-max) | [global\$1max\$1connections ](#attributes-recipes-haproxy-global-max) | 
| [health\$1check\$1method ](#attributes-recipes-haproxy-health-method) | [health\$1check\$1url ](#attributes-recipes-haproxy-health-url) | [queue\$1timeout ](#attributes-recipes-haproxy-queue-timeout) | 
| [http\$1request\$1timeout ](#attributes-recipes-haproxy-http-timeout) | [maxcon\$1factor\$1nodejs\$1app ](#attributes-recipes-haproxy-nodejs-app) | [maxcon\$1factor\$1nodejs\$1app\$1ssl ](#attributes-recipes-haproxy-nodejs-ssl) | 
| [maxcon\$1factor\$1php\$1app ](#attributes-recipes-haproxy-php-app) | [maxcon\$1factor\$1php\$1app\$1ssl ](#attributes-recipes-haproxy-php-ssl) | [maxcon\$1factor\$1rails\$1app ](#attributes-recipes-haproxy-rails-app) | 
| [maxcon\$1factor\$1rails\$1app\$1ssl ](#attributes-recipes-haproxy-rails-ssl) | [maxcon\$1factor\$1static ](#attributes-recipes-haproxy-static-app) | [maxcon\$1factor\$1static\$1ssl ](#attributes-recipes-haproxy-static-ssl) | 
| [retries ](#attributes-recipes-haproxy-retries) | [server\$1timeout ](#attributes-recipes-haproxy-server-timeout) | [stats\$1url ](#attributes-recipes-haproxy-stats-url) | 
| [stats\$1user ](#attributes-recipes-haproxy-user) |  |  | 

**balance **  <a name="attributes-recipes-haproxy-balance"></a>
로드 밸런서가 서버를 선택하는 데 사용하는 알고리즘(문자열). 기본값은 `'roundrobin'`입니다. 그 밖의 옵션은 다음과 같습니다.  
+ 'static-rr'
+ 'leastconn'
+ 'source'
+ 'uri'
+ 'url\$1param'
+ 'hdr(name)'
+ 'rdp-cookie'
+ 'rdp-cookie(name)'
이러한 인수에 대한 자세한 정보는 [밸런스](http://cbonte.github.io/haproxy-dconv/configuration-1.5.html)를 참조하세요.  

```
node[:haproxy][:balance]
```

**check\$1interval **  <a name="attributes-recipes-haproxy-interval"></a>
상태 확인 시간 간격(문자열). 기본값은 `'10s'`입니다.  

```
node[:haproxy][:check_interval]
```

**client\$1timeout **  <a name="attributes-recipes-haproxy-client-timeout"></a>
클라이언트가 비활성 상태로 있을 수 있는 최대 시간(문자열). 기본값은 `'60s'`입니다.  

```
node[:haproxy][:client_timeout]
```

**connect\$1timeout **  <a name="attributes-recipes-haproxy-connect-timeout"></a>
HAProxy가 서버 연결 시도 성공을 기다리는 최대 시간(문자열). 기본값은 `'10s'`입니다.  

```
node[:haproxy][:connect_timeout]
```

**default\$1max\$1connections **  <a name="attributes-recipes-haproxy-default-max"></a>
연결의 기본 최대 수(문자열). 기본값은 `'80000'`입니다.  

```
node[:haproxy][:default_max_connections]
```

**global\$1max\$1connections **  <a name="attributes-recipes-haproxy-global-max"></a>
연결의 최대 수(문자열). 기본값은 `'80000'`입니다.  

```
node[:haproxy][:global_max_connections]
```

**health\$1check\$1method **  <a name="attributes-recipes-haproxy-health-method"></a>
상태 확인 메서드(문자열). 기본값은 `'OPTIONS'`입니다.  

```
node[:haproxy][:health_check_method]
```

**health\$1check\$1url **  <a name="attributes-recipes-haproxy-health-url"></a>
서버 상태 확인에 사용되는 URL 경로(문자열). 기본값은 `'/'`입니다.  

```
node[:haproxy][:health_check_url ]
```

**queue\$1timeout **  <a name="attributes-recipes-haproxy-queue-timeout"></a>
무료 연결의 최대 대기 시간(문자열). 기본값은 `'120s'`입니다.  

```
node[:haproxy][:queue_timeout]
```

**http\$1request\$1timeout **  <a name="attributes-recipes-haproxy-http-timeout"></a>
HAProxy가 완전한 HTTP 요청을 기다리는 최대 시간(문자열). 기본값은 `'30s'`입니다.  

```
node[:haproxy][:http_request_timeout]
```

**retries **  <a name="attributes-recipes-haproxy-retries"></a>
서버 연결 실패 후 재시도 횟수(문자열). 기본값은 `'3'`입니다.  

```
node[:haproxy][:retries]
```

**server\$1timeout **  <a name="attributes-recipes-haproxy-server-timeout"></a>
클라이언트가 비활성 상태로 있을 수 있는 최대 시간(문자열). 기본값은 `'60s'`입니다.  

```
node[:haproxy][:server_timeout]
```

**stats\$1url **  <a name="attributes-recipes-haproxy-stats-url"></a>
통계 페이지의 URL 경로(문자열). 기본값은 `'/haproxy?stats'`입니다.  

```
node[:haproxy][:stats_url]
```

**stats\$1user **  <a name="attributes-recipes-haproxy-user"></a>
통계 페이지 사용자 이름(문자열). 기본값은 `'opsworks'`입니다.  

```
node[:haproxy][:stats_user]
```

`maxcon` 속성은 HAProxy가 [백엔드](attributes-json-opsworks-instance.md#attributes-json-opsworks-instance-backends)에 허용하는 최대 연결 수를 계산하는 데 사용되는 로드 비율 승수를 나타냅니다. 예를 들어 `backend` 값이 4인 작은 인스턴스에 Rails 앱 서버가 있다고 가정해 보겠습니다. 즉, OpsWorks Stacks가 해당 인스턴스에 대해 4개의 Rails 프로세스를 구성합니다. 기본 `maxcon_factor_rails_app` 값인 7을 사용하는 경우, HAProxy는 Rails 서버와의 연결 28(4\$17)개를 처리합니다.

**maxcon\$1factor\$1nodejs\$1app **  <a name="attributes-recipes-haproxy-nodejs-app"></a>
Node.js 앱 서버의 maxcon 비율(숫자). 기본값은 `10`입니다.  

```
node[:haproxy][:maxcon_factor_nodejs_app]
```

**maxcon\$1factor\$1nodejs\$1app\$1ssl **  <a name="attributes-recipes-haproxy-nodejs-ssl"></a>
SSL 포함 Node.js 앱 서버의 maxcon 비율(숫자). 기본값은 `10`입니다.  

```
node[:haproxy][:maxcon_factor_nodejs_app_ssl]
```

**maxcon\$1factor\$1php\$1app **  <a name="attributes-recipes-haproxy-php-app"></a>
PHP 앱 서버의 maxcon 비율(숫자). 기본값은 `10`입니다.  

```
node[:haproxy][:maxcon_factor_php_app]
```

**maxcon\$1factor\$1php\$1app\$1ssl **  <a name="attributes-recipes-haproxy-php-ssl"></a>
SSL 포함 PHP 앱 서버의 maxcon 비율(숫자). 기본값은 `10`입니다.  

```
node[:haproxy][:maxcon_factor_php_app_ssl]
```

**maxcon\$1factor\$1rails\$1app **  <a name="attributes-recipes-haproxy-rails-app"></a>
Rails 앱 서버의 maxcon 비율(숫자). 기본값은 `7`입니다.  

```
node[:haproxy][:maxcon_factor_rails_app]
```

**maxcon\$1factor\$1rails\$1app\$1ssl **  <a name="attributes-recipes-haproxy-rails-ssl"></a>
SSL 포함 Rails 앱 서버의 maxcon 비율(숫자). 기본값은 `7`입니다.  

```
node[:haproxy][:maxcon_factor_rails_app_ssl]
```

**maxcon\$1factor\$1static **  <a name="attributes-recipes-haproxy-static-app"></a>
정적 웹 서버의 maxcon 비율(숫자). 기본값은 `15`입니다.  

```
node[:haproxy][:maxcon_factor_static]
```

**maxcon\$1factor\$1static\$1ssl **  <a name="attributes-recipes-haproxy-static-ssl"></a>
SSL 포함 정적 웹 서버의 maxcon 비율(숫자). 기본값은 `15`입니다.  

```
node[:haproxy][:maxcon_factor_static_ssl]
```

# memcached 속성
<a name="attributes-recipes-mem"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이러한 속성은 Linux 스택에서만 사용할 수 있습니다.

[`memcached` 속성](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/memcached/attributes/default.rb)은 [Memcached](http://memcached.org/) 서버 구성을 지정합니다. 내장 속성을 재정의해 사용자 지정 값을 지정하는 방법에 대한 자세한 정보는 [속성 재정의](workingcookbook-attributes.md) 단원을 참조하세요.


****  

|  |  |  | 
| --- |--- |--- |
| [메모리 ](#attributes-recipes-mem-memory) | [max\$1connections ](#attributes-recipes-mem-max) | [pid\$1file ](#attributes-recipes-mem-pid) | 
| [포트 ](#attributes-recipes-mem-port) | [start\$1command ](#attributes-recipes-mem-start) | [stop\$1command ](#attributes-recipes-mem-stop) | 
| [user ](#attributes-recipes-mem-user) |  |  | 

**메모리 **  <a name="attributes-recipes-mem-memory"></a>
사용할 최대 메모리 양(MB)(숫자). 기본값은 `512`입니다.  

```
node[:memcached][:memory]
```

**max\$1connections **  <a name="attributes-recipes-mem-max"></a>
연결의 최대 수(문자열). 기본값은 `'4096'`입니다.  

```
node[:memcached][:max_connections]
```

**pid\$1file **  <a name="attributes-recipes-mem-pid"></a>
데몬의 프로세스 ID가 포함된 파일(문자열). 기본값은 `'var/run/memcached.pid'`입니다.  

```
node[:memcached][:pid_file]
```

**포트 **  <a name="attributes-recipes-mem-port"></a>
수신 대기할 포트(숫자). 기본값은 `11211`입니다.  

```
node[:memcached][:port]
```

**start\$1command **  <a name="attributes-recipes-mem-start"></a>
시작 명령(문자열). 기본값은 `'/etc/init.d/memcached start'`입니다.  

```
node[:memcached][:start_command]
```

**stop\$1command **  <a name="attributes-recipes-mem-stop"></a>
중지 명령(문자열). 기본값은 `'/etc/init.d/memcached stop'`입니다.  

```
node[:memcached][:stop_command]
```

**user **  <a name="attributes-recipes-mem-user"></a>
사용자(문자열). 기본값은 `'nobody'`입니다.  

```
node[:memcached][:user]
```

# mysql 속성
<a name="attributes-recipes-mysql"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이러한 속성은 Linux 스택에서만 사용할 수 있습니다.

[`mysql` 속성](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/mysql/attributes/server.rb)은 [MySQL](http://www.mysql.com/) 마스터 구성을 지정합니다. 자세한 정보는 [서버 시스템 변수](http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html)를 참조하세요. 내장 속성을 재정의해 사용자 지정 값을 지정하는 방법에 대한 자세한 정보는 [속성 재정의](workingcookbook-attributes.md) 단원을 참조하세요.


****  

|  |  |  | 
| --- |--- |--- |
| [basedir ](#attributes-recipes-mysql-basedir) | [bind\$1address ](#attributes-recipes-mysql-bind) | [클라이언트 ](#attributes-recipes-mysql-clients) | 
| [conf\$1dir ](#attributes-recipes-mysql-conf) | [confd\$1dir ](#attributes-recipes-mysql-confd) | [datadir ](#attributes-recipes-mysql-datadir) | 
| [grants\$1path ](#attributes-recipes-mysql-grants) | [mysql\$1bin ](#attributes-recipes-mysql-bin) | [mysqladmin\$1bin ](#attributes-recipes-mysql-admin-bin) | 
| [pid\$1file ](#attributes-recipes-mysql-pid) | [포트 ](#attributes-recipes-mysql-port) | [root\$1group ](#attributes-recipes-mysql-group) | 
| [server\$1root\$1password ](#attributes-recipes-mysql-pwd) | [소켓 ](#attributes-recipes-mysql-socket) | [tunable 속성](#attributes-recipes-mysql-tunable) | 

**basedir **  <a name="attributes-recipes-mysql-basedir"></a>
기본 디렉터리(문자열). 기본값은 `'/usr'`입니다.  

```
node[:mysql][:basedir]
```

**bind\$1address **  <a name="attributes-recipes-mysql-bind"></a>
MySQL이 수신 대기하는 주소(문자열). 기본값은 `'0.0.0.0'`입니다.  

```
node[:mysql][:bind_address]
```

**클라이언트 **  <a name="attributes-recipes-mysql-clients"></a>
클라이언트 목록(문자열의 목록).  

```
node[:mysql][:clients]
```

**conf\$1dir **  <a name="attributes-recipes-mysql-conf"></a>
구성 파일이 포함된 디렉터리(문자열). 기본값은 다음과 같습니다.  
+ Amazon Linux 및 RHEL: `'/etc'`
+ Ubuntu: `'/etc/mysql'`

```
node[:mysql][:conf_dir]
```

**confd\$1dir **  <a name="attributes-recipes-mysql-confd"></a>
추가 구성 파일이 포함된 디렉터리(문자열). 기본값은 `'/etc/mysql/conf.d'`입니다.  

```
node[:mysql][:confd_dir]
```

**datadir **  <a name="attributes-recipes-mysql-datadir"></a>
데이터 디렉터리(문자열). 기본값은 `'/var/lib/mysql'`입니다.  

```
node[:mysql][:datadir]
```

**grants\$1path **  <a name="attributes-recipes-mysql-grants"></a>
그랜트 테이블 위치(문자열). 기본값은 `'/etc/mysql_grants.sql'`입니다.  

```
node[:mysql][:grants_path]
```

**mysql\$1bin **  <a name="attributes-recipes-mysql-bin"></a>
mysql 이진수 위치(문자열). 기본값은 `'/usr/bin/mysql'`입니다.  

```
node[:mysql][:mysql_bin]
```

**mysqladmin\$1bin **  <a name="attributes-recipes-mysql-admin-bin"></a>
mysqladmin 위치(문자열). 기본값은 `'/usr/bin/mysqladmin'`입니다.  

```
node[:mysql][:mysqladmin_bin]
```

**pid\$1file **  <a name="attributes-recipes-mysql-pid"></a>
데몬의 프로세스 ID가 포함된 파일(문자열). 기본값은 `'/var/run/mysqld/mysqld.pid'`입니다.  

```
node[:mysql][:pid_file]
```

**포트 **  <a name="attributes-recipes-mysql-port"></a>
서버가 수신 대기하는 포트(숫자). 기본값은 `3306`입니다.  

```
node[:mysql][:port]
```

**root\$1group **  <a name="attributes-recipes-mysql-group"></a>
루트 그룹(문자열). 기본값은 `'root'`입니다.  

```
node[:mysql][:root_group]
```

**server\$1root\$1password **  <a name="attributes-recipes-mysql-pwd"></a>
서버의 루트 암호(문자열). 기본값은 무작위로 생성됩니다.  

```
node[:mysql][:server_root_password]
```

**소켓 **  <a name="attributes-recipes-mysql-socket"></a>
소켓 파일의 위치(문자열). 기본값은 `'/var/lib/mysql/mysql.sock'`입니다. 기본값은 다음과 같습니다.  
+ Amazon Linux 및 RHEL: `'/var/lib/mysql/mysql.sock'`
+ Ubuntu: `'/var/run/mysqld/mysqld.sock'`

```
node[:mysql][:socket]
```

**tunable 속성**  <a name="attributes-recipes-mysql-tunable"></a>
tunable 속성은 성능 튜닝에 사용됩니다.    
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/attributes-recipes-mysql.html)  
**back\$1log **  <a name="attributes-recipes-mysql-tunable-back"></a>
대기 중인 요청의 최대 수(문자열). 기본값은 `'128'`입니다.  

```
node[:mysql][:tunable][:back_log]
```  
**innodb\$1additional\$1mem\$1pool\$1size **  <a name="attributes-recipes-mysql-tunable-mem"></a>
[Innodb](http://dev.mysql.com/doc/refman/5.5/en/innodb-storage-engine.html)가 내부 데이터 구조를 저장하는 데 사용하는 풀의 크기(문자열). 기본값은 `'20M'`입니다.  

```
node[:mysql][:tunable][:innodb_additional_mem_pool_size]
```  
**innodb\$1buffer\$1pool\$1size **  <a name="attributes-recipes-mysql-tunable-buffer"></a>
[Innodb](http://dev.mysql.com/doc/refman/5.5/en/innodb-storage-engine.html) 버퍼 풀 크기(문자열). 속성 값은 OpsWorks Stacks에서 설정하며 인스턴스 유형에 따라 다르지만 사용자 지정 JSON 또는 사용자 지정 속성 파일을 사용하여 [재정](workingcookbook-attributes.md)의할 수 있습니다.  

```
node[:mysql][:tunable][:innodb_buffer_pool_size]
```  
**innodb\$1flush\$1log\$1at\$1trx\$1commit **  <a name="attributes-recipes-mysql-tunable-flush"></a>
[Innodb](http://dev.mysql.com/doc/refman/5.5/en/innodb-storage-engine.html)가 로그 버퍼를 플러시하는 빈도(문자열). 기본값은 `'2'`입니다. 자세한 정보는 [innodb\$1flush\$1log\$1at\$1trx\$1commit](http://dev.mysql.com/doc/refman/5.1/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit) 단원을 참조하세요.  

```
node[:mysql][:tunable][:innodb_flush_log_at_trx_commit]
```  
**innodb\$1lock\$1wait\$1timeout **  <a name="attributes-recipes-mysql-tunable-lock"></a>
[Innodb](http://dev.mysql.com/doc/refman/5.5/en/innodb-storage-engine.html) 트랜잭션이 행 잠금을 기다리는 최대 시간(초)(문자열). 기본값은 `'50'`입니다.  

```
node[:mysql][:tunable][:innodb_lock_wait_timeout]
```  
**key\$1buffer **  <a name="attributes-recipes-mysql-tunable-key"></a>
인덱스 버퍼 크기(문자열). 기본값은 `'250M'`입니다.  

```
node[:mysql][:tunable][:key_buffer]
```  
**log\$1slow\$1queries **  <a name="attributes-recipes-mysql-tunable-slow"></a>
느린 쿼리 로그 파일의 위치(문자열). 기본값은 `'/var/log/mysql/mysql-slow.log'`입니다.  

```
node[:mysql][:tunable][:log_slow_queries]
```  
**long\$1query\$1time **  <a name="attributes-recipes-mysql-tunable-long"></a>
쿼리를 장기 쿼리로 지정하는 데 필요한 시간(초)(문자열). 기본값은 `'1'`입니다.  

```
node[:mysql][:tunable][:long_query_time]
```  
**max\$1allowed\$1packet **  <a name="attributes-recipes-mysql-tunable-packet"></a>
허용되는 최대 패킷 크기(문자열). 기본값은 `'32M'`입니다.  

```
node[:mysql][:tunable][:max_allowed_packet]
```  
**max\$1connections **  <a name="attributes-recipes-mysql-tunable-connections"></a>
동시 클라이언트 연결 최대 수(문자열). 기본값은 `'2048'`입니다.  

```
node[:mysql][:tunable][:max_connections]
```  
**max\$1heap\$1table\$1size **  <a name="attributes-recipes-mysql-tunable-heap"></a>
사용자가 만든 `MEMORY` 테이블의 최대 크기(문자열). 기본값은 `'32M'`입니다.  

```
node[:mysql][:tunable][:max_heap_table_size]
```  
**net\$1read\$1timeout **  <a name="attributes-recipes-mysql-tunable-net-read"></a>
연결로부터 더 많은 데이터를 기다릴 시간(초)(문자열). 기본값은 `'30'`입니다.  

```
node[:mysql][:tunable][:net_read_timeout]
```  
**net\$1write\$1timeout **  <a name="attributes-recipes-mysql-tunable-net-write"></a>
블록이 연결에 작성되기를 기다리는 시간(초)(문자열). 기본값은 `'30'`입니다.  

```
node[:mysql][:tunable][:net_write_timeout]
```  
**query\$1cache\$1limit **  <a name="attributes-recipes-mysql-tunable-cache-limit"></a>
캐시된 개별 쿼리의 최대 크기(문자열). 기본값은 `'2M'`입니다.  

```
node[:mysql][:tunable][:query_cache_limit]
```  
**query\$1cache\$1size **  <a name="attributes-recipes-mysql-tunable-cache-size"></a>
쿼리 캐시 크기(문자열). 기본값은 `'128M'`입니다.  

```
node[:mysql][:tunable][:query_cache_size]
```  
**query\$1cache\$1type **  <a name="attributes-recipes-mysql-tunable-cache-type"></a>
쿼리 캐시 유형(문자열). 가능한 값은 다음과 같습니다.  
+ `'0'`: 캐시 또는 캐시된 데이터 검색 없음.
+ `'1'`: `SELECT SQL_NO_CACHE`로 시작하지 않는 Cache 문.
+ `'2'`: `SELECT SQL_CACHE`로 시작하는 Cache 문.
기본값은 `'1'`입니다.  

```
node[:mysql][:tunable][:query_cache_type]
```  
**thread\$1cache\$1size **  <a name="attributes-recipes-mysql-tunable-thread-cache"></a>
재사용을 위해 캐시되는 클라이언트 스레드 수(문자열). 기본값은 `'8'`입니다.  

```
node[:mysql][:tunable][:thread_cache_size]
```  
**thread\$1stack **  <a name="attributes-recipes-mysql-tunable-thread-stack"></a>
각 스레드의 스택 크기(문자열). 기본값은 `'192K'`입니다.  

```
node[:mysql][:tunable][:thread_stack]
```  
**wait\$1timeout **  <a name="attributes-recipes-mysql-tunable-wait"></a>
상호 작용하지 않는 연결을 기다릴 시간(초). 기본값은 `'180'`입니다(문자열).  

```
node[:mysql][:tunable][:wait_timeout]
```  
**table\$1cache **  <a name="attributes-recipes-mysql-tunable-table"></a>
열려 있는 테이블의 수(문자열). 기본값은 `'2048'`입니다.  

```
node[:mysql][:tunable][:table_cache]
```

# nginx 속성
<a name="attributes-recipes-nginx"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이러한 속성은 Linux 스택에서만 사용할 수 있습니다.

[`nginx` 속성](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/nginx/attributes/nginx.rb)은 [Nginx](http://wiki.nginx.org/Main) 구성을 지정합니다. 자세한 정보는 [명령 인덱스](http://wiki.nginx.org/DirectiveIndex)를 참조하세요. 내장 속성을 재정의해 사용자 지정 값을 지정하는 방법에 대한 자세한 정보는 [속성 재정의](workingcookbook-attributes.md) 단원을 참조하세요.


****  

|  |  |  | 
| --- |--- |--- |
| [이진수 ](#attributes-recipes-nginx-binary) | [dir ](#attributes-recipes-nginx-dir) | [gzip ](#attributes-recipes-nginx-gzip) | 
| [gzip\$1comp\$1level ](#attributes-recipes-nginx-gzip-comp) | [gzip\$1disable ](#attributes-recipes-nginx-gzip-disable) | [gzip\$1http\$1version ](#attributes-recipes-nginx-gzip-http) | 
| [gzip\$1proxied ](#attributes-recipes-nginx-gzip-proxied) | [gzip\$1static ](#attributes-recipes-nginx-gzip-static) | [gzip\$1types ](#attributes-recipes-nginx-gzip-types) | 
| [gzip\$1vary ](#attributes-recipes-nginx-gzip-vary) | [keepalive ](#attributes-recipes-nginx-keepalive) | [keepalive\$1timeout ](#attributes-recipes-nginx-keepalive-timeout) | 
| [log\$1dir ](#attributes-recipes-nginx-log) | [user ](#attributes-recipes-nginx-user) | [server\$1names\$1hash\$1bucket\$1size](#attributes-recipes-nginx-worker-hash) | 
| [worker\$1processes ](#attributes-recipes-nginx-worker-processes) | [worker\$1connections ](#attributes-recipes-nginx-worker-connections) |  | 

**이진수 **  <a name="attributes-recipes-nginx-binary"></a>
Nginx 이진수의 위치(문자열). 기본값은 `'/usr/sbin/nginx'`입니다.  

```
node[:nginx][:binary]
```

**dir **  <a name="attributes-recipes-nginx-dir"></a>
구성 파일 등의 파일 위치(문자열). 기본값은 `'/etc/nginx'`입니다.  

```
node[:nginx][:dir]
```

**gzip **  <a name="attributes-recipes-nginx-gzip"></a>
gzip 압축이 활성화되어 있는지 여부(문자열). 가능한 값은 `'on'`와 `'off'`입니다. 기본값은 `'on'`입니다.  
압축은 보안 위험을 초래할 수 있습니다. 압축을 완전히 비활성화하려면 이 속성을 다음과 같이 설정하세요.  

```
node[:nginx][:gzip] = 'off'
```

```
node[:nginx][:gzip]
```

**gzip\$1comp\$1level **  <a name="attributes-recipes-nginx-gzip-comp"></a>
1-9까지의 압축 수준(1이 최소 압축)(문자열). 기본값은 `'2'`입니다.  

```
node[:nginx][:gzip_comp_level]
```

**gzip\$1disable **  <a name="attributes-recipes-nginx-gzip-disable"></a>
지정된 사용자 에이전트에 대해 gzip 압축을 비활성화합니다(문자열). 값은 정규 표현식이며 기본값은 `'MSIE [1-6].(?!.*SV1)'`입니다.  

```
node[:nginx][:gzip_disable]
```

**gzip\$1http\$1version **  <a name="attributes-recipes-nginx-gzip-http"></a>
지정된 HTTP 버전에 대해 gzip 압축을 활성화합니다(문자열). 기본값은 `'1.0'`입니다.  

```
node[:nginx][:gzip_http_version]
```

**gzip\$1proxied **  <a name="attributes-recipes-nginx-gzip-proxied"></a>
프록시 요청에 대한 응답을 압축할지 여부 및 압축 방법이며, 다음 값 중 하나를 취할 수 있습니다(문자열).  
+ `'off'`: 프록시된 요청을 압축하지 않습니다
+ `'expired'`: Expire 헤더가 캐싱을 금지하는 경우, 압축합니다
+ `'no-cache'`: Cache-Control 헤더가 "no-cache"로 설정된 경우, 압축합니다
+ `'no-store'`: Cache-Control 헤더가 "no-store"로 설정된 경우, 압축합니다
+ `'private'`: Cache-Control 헤더가 "private"으로 설정된 경우, 압축합니다
+ `'no_last_modified'`: Last-Modified가 설정되지 않은 경우, 압축합니다
+ `'no_etag'`: 요청에 ETag 헤더가 없는 경우, 압축합니다
+ `'auth'`: 요청에 Authorization 헤더가 포함된 경우, 압축합니다
+ `'any'`: 모든 프록시된 요청을 압축합니다 
기본값은 `'any'`입니다.  

```
node[:nginx][:gzip_proxied]
```

**gzip\$1static **  <a name="attributes-recipes-nginx-gzip-static"></a>
gzip 정적 모듈이 활성화되어 있는지 여부(문자열). 가능한 값은 `'on'`와 `'off'`입니다. 기본값은 `'on'`입니다.  

```
node[:nginx][:gzip_static]
```

**gzip\$1types **  <a name="attributes-recipes-nginx-gzip-types"></a>
압축할 MIME 형식의 목록(문자열의 목록). 기본값은 `['text/plain', 'text/html', 'text/css', 'application/x-javascript', 'text/xml', 'application/xml', 'application/xml+rss', 'text/javascript']`입니다.  

```
node[:nginx][:gzip_types]
```

**gzip\$1vary **  <a name="attributes-recipes-nginx-gzip-vary"></a>
`Vary:Accept-Encoding `응답 헤더를 활성화할지 여부(문자열). 가능한 값은 `'on'`와 `'off'`입니다. 기본값은 `'on'`입니다.  

```
node[:nginx][:gzip_vary]
```

**keepalive **  <a name="attributes-recipes-nginx-keepalive"></a>
연결 유지 연결을 활성화할지 여부(문자열). 가능한 값은 `'on'`와 `'off'`입니다. 기본값은 `'on'`입니다.  

```
node[:nginx][:keepalive]
```

**keepalive\$1timeout **  <a name="attributes-recipes-nginx-keepalive-timeout"></a>
연결 유지 연결이 계속 열려 있는 최대 시간(초)(숫자). 기본값은 `65`입니다.  

```
node[:nginx][:keepalive_timeout]
```

**log\$1dir **  <a name="attributes-recipes-nginx-log"></a>
로그 파일의 위치(문자열). 기본값은 `'/var/log/nginx'`입니다.  

```
node[:nginx][:log_dir]
```

**user **  <a name="attributes-recipes-nginx-user"></a>
사용자(문자열). 기본값은 다음과 같습니다.  
+ Amazon Linux 및 RHEL: `'www-data'`
+ Ubuntu: `'nginx'`

```
node[:nginx][:user]
```

**server\$1names\$1hash\$1bucket\$1size**  <a name="attributes-recipes-nginx-worker-hash"></a>
서버 이름의 해시 테이블 버킷 크기로서 `32`, `64` 또는 `128`로 설정할 수 있습니다(숫자). 기본값은 `64`입니다.  

```
node[:nginx][:server_names_hash_bucket_size]
```

**worker\$1processes **  <a name="attributes-recipes-nginx-worker-processes"></a>
worker 프로세스의 수(숫자). 기본값은 `10`입니다.  

```
node[:nginx][:worker_processes]
```

**worker\$1connections **  <a name="attributes-recipes-nginx-worker-connections"></a>
worker 연결의 최대 수(숫자). 기본값은 `1024`입니다. 클라이언트의 최대 수는 `worker_processes * worker_connections`로 설정됩니다.  

```
node[:nginx][:worker_connections]
```

# opsworks\$1berkshelf 속성
<a name="attributes-recipes-berkshelf"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이러한 속성은 Linux 스택에서만 사용할 수 있습니다.

[`opsworks_berkshelf` 속성](https://github.com/aws/opsworks-cookbooks/blob/master-chef-11.10/opsworks_berkshelf/attributes/default.rb)은 Berkshelf 구성을 지정합니다. 자세한 정보는 [Berkshelf](http://berkshelf.com/)를 참조하세요. 내장 속성을 재정의해 사용자 지정 값을 지정하는 방법에 대한 자세한 정보는 [속성 재정의](workingcookbook-attributes.md) 단원을 참조하세요.

**debug**  <a name="attributes-recipes-berkshelf-debug"></a>
Chef 로그에 Berkshelf 디버깅 정보를 포함할지 여부(부울). 기본값은 `false`입니다.  

```
node['opsworks_berkshelf]['debug']
```

# opsworks\$1java 속성
<a name="attributes-recipes-java"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이러한 속성은 Linux 스택에서만 사용할 수 있습니다.

[`opsworks_java` 속성](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/opsworks_java/attributes/default.rb)은 [Tomcat](http://tomcat.apache.org/) 서버 구성을 지정합니다. 자세한 정보는 [Apache Tomcat 구성 참조](http://tomcat.apache.org/tomcat-5.5-doc/config/)를 참조하세요. 내장 속성을 재정의해 사용자 지정 값을 지정하는 방법에 대한 자세한 정보는 [속성 재정의](workingcookbook-attributes.md) 단원을 참조하세요.


****  

|  |  |  | 
| --- |--- |--- |
| [datasources ](#attributes-recipes-java-datasources) | [java\$1app\$1server\$1version ](#attributes-recipes-java-server-version) | [java\$1shared\$1lib\$1dir ](#attributes-recipes-java-shared-lib) | 
| [jvm\$1pkg Attributes ](#attributes-recipes-java-pkg) | [custom\$1pkg\$1location\$1url\$1debian ](#attributes-recipes-java-pkg-debian) | [java\$1home\$1basedir ](#attributes-recipes-java-pkg-basedir) | 
| [custom\$1pkg\$1location\$1url\$1rhel ](#attributes-recipes-java-pkg-rhel) | [use\$1custom\$1pkg\$1location ](#attributes-recipes-java-pkg-use) | [jvm\$1options ](#attributes-recipes-java-jvm-options) | 
| [jvm\$1version ](#attributes-recipes-java-jvm-version) | [tomcat 속성](#attributes-recipes-java-tomcat) |  | 

**datasources **  <a name="attributes-recipes-java-datasources"></a>
JNDI 리소스 이름을 정의하는 속성 집합(문자열). 이 속성을 사용하는 방법에 대한 자세한 정보는 [백엔드 데이터베이스를 사용하여 JSP 앱 배포](layers-java-deploy.md#layers-java-deploy-jsp-db) 단원을 참조하세요. 기본값인 빈 해시는 앱 짧은 이름과 JNDI 이름 사이의 사용자 지정 매핑으로 채울 수 있습니다. 자세한 내용은 [백엔드 데이터베이스를 사용하여 JSP 앱 배포](layers-java-deploy.md#layers-java-deploy-jsp-db) 섹션을 참조하세요.  

```
node['opsworks_java']['datasources']
```

**java\$1app\$1server\$1version **  <a name="attributes-recipes-java-server-version"></a>
Java 앱 서버 버전(숫자). 기본값은 `7`입니다. 이 속성을 재정의하여 버전 6을 지정할 수 있습니다. 기본이 아닌 JDK를 설치하는 경우, 이 속성은 무시됩니다.  

```
node['opsworks_java']['java_app_server_version']
```

**java\$1shared\$1lib\$1dir **  <a name="attributes-recipes-java-shared-lib"></a>
Java 공유 라이브러리의 디렉터리(문자열). 기본값은 `/usr/share/java`입니다.  

```
node['opsworks_java']['java_shared_lib_dir']
```

**jvm\$1pkg Attributes **  <a name="attributes-recipes-java-pkg"></a>
재정의하여 기본이 아닌 JDK를 설치할 수 있는 속성 세트.    
**use\$1custom\$1pkg\$1location **  <a name="attributes-recipes-java-pkg-use"></a>
OpenJDK 대신 사용자 지정 JDK를 설치할지 여부(부울). 기본값은 `false`입니다.  

```
node['opsworks_java']['jvm_pkg']['use_custom_pkg_location']
```  
**custom\$1pkg\$1location\$1url\$1debian **  <a name="attributes-recipes-java-pkg-debian"></a>
Ubuntu 인스턴스에 설치할 JDK 패키지의 위치(문자열). 기본값은 `'http://aws.amazon.com/'`이며, 별 의미가 없는 단순한 초기화 값입니다. 기본이 아닌 JDK를 설치하려면 이 속성을 재정의해 적절한 URL로 설정해야 합니다.  

```
node['opsworks_java']['jvm_pkg']['custom_pkg_location_url_debian']
```  
**custom\$1pkg\$1location\$1url\$1rhel **  <a name="attributes-recipes-java-pkg-rhel"></a>
Amazon Linux 및 RHEL 인스턴스에 설치할 JDK 패키지의 위치(문자열). 기본값은 `'http://aws.amazon.com/'`이며, 별 의미가 없는 단순한 초기화 값입니다. 기본이 아닌 JDK를 설치하려면 이 속성을 재정의해 적절한 URL로 설정해야 합니다.  

```
node['opsworks_java']['jvm_pkg']['custom_pkg_location_url_rhel']
```  
**java\$1home\$1basedir **  <a name="attributes-recipes-java-pkg-basedir"></a>
JDK 패키지가 추출될 디렉터리(문자열). 기본값은 `/usr/local`입니다. RPM 패키지의 경우, 이 설정을 지정할 필요가 없습니다. 완전한 디렉터리 구조가 포함되어 있기 때문입니다.  

```
node['opsworks_java']['jvm_pkg']['java_home_basedir']
```

**jvm\$1options **  <a name="attributes-recipes-java-jvm-options"></a>
JVM 명령줄 옵션으로서 힙 크기 같은 설정을 지정할 수 있습니다(문자열). 공통 옵션 세트는 `-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC`입니다. 기본값은 no options입니다.  

```
node['opsworks_java']['jvm_options']
```

**jvm\$1version **  <a name="attributes-recipes-java-jvm-version"></a>
OpenJDK 버전(숫자). 기본값은 `7`입니다. 이 속성을 재정의하여 OpenJDK 버전 6을 지정할 수 있습니다. 기본이 아닌 JDK를 설치하는 경우, 이 속성은 무시됩니다.  

```
node['opsworks_java']['jvm_version']
```

**tomcat 속성**  <a name="attributes-recipes-java-tomcat"></a>
재정의하여 기본 Tomcat 구성을 설치할 수 있는 속성 세트.    
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/attributes-recipes-java.html)  
**ajp\$1port **  <a name="attributes-recipes-java-ajp-port"></a>
AJP 포트(숫자). 기본값은 `8009`입니다.  

```
node['opsworks_java']['tomcat]['ajp_port']
```  
**apache\$1tomcat\$1bind\$1mod **  <a name="attributes-recipes-java-bind-mod"></a>
프록시 모듈(문자열). 기본값은 `proxy_http`입니다. 이 속성을 재정의하여 AJP 프록시 모듈 `proxy_ajp`를 지정할 수 있습니다.  

```
node['opsworks_java']['tomcat]['apache_tomcat_bind_mod']
```  
**apache\$1tomcat\$1bind\$1path **  <a name="attributes-recipes-java-bind-path"></a>
Apache-Tomcat 바인딩 경로(문자열). 기본값은 `/`입니다. 이 속성은 재정의하면 안 됩니다. 바인딩 경로를 변경하면 애플리케이션 작동이 중지될 수 있습니다.  

```
node['opsworks_java']['tomcat]['apache_tomcat_bind_path']
```  
**auto\$1deploy **  <a name="attributes-recipes-java-deploy"></a>
autodeploy할지 여부(부울). 기본값은 `true`입니다.  

```
node['opsworks_java']['tomcat]['auto_deploy']
```  
**connection\$1timeout **  <a name="attributes-recipes-java-timeout"></a>
연결 제한 시간(밀리초)(숫자). 기본값은 `20000`(20초)입니다.  

```
node['opsworks_java']['tomcat]['connection_timeout']
```  
**mysql\$1connector\$1jar **  <a name="attributes-recipes-java-connector"></a>
MySQL 커넥터 라이브러리의 JAR 파일(문자열). 기본값은 `mysql-connector-java.jar`입니다.  

```
node['opsworks_java']['tomcat]['mysql_connector_jar']
```  
**포트 **  <a name="attributes-recipes-java-port"></a>
표준 포트(숫자). 기본값은 `8080`입니다.  

```
node['opsworks_java']['tomcat]['port']
```  
**secure\$1port **  <a name="attributes-recipes-java-secure-port"></a>
보안 포트(숫자). 기본값은 `8443`입니다.  

```
node['opsworks_java']['tomcat]['secure_port']
```  
**shutdown\$1port **  <a name="attributes-recipes-java-shutdown-port"></a>
 종료 포트(숫자). 기본값은 `8005`입니다.  

```
node['opsworks_java']['tomcat]['shutdown_port']
```  
**threadpool\$1max\$1threads **  <a name="attributes-recipes-java-threadpool-max"></a>
스레드 풀의 스레드 최대 수(숫자). 기본값은 `150`입니다.  

```
node['opsworks_java']['tomcat]['threadpool_max_threads']
```  
**threadpool\$1min\$1spare\$1threads **  <a name="attributes-recipes-java-threadpool-min"></a>
스레드 풀의 예비 스레드 최소 수(숫자). 기본값은 `4`입니다.  

```
node['opsworks_java']['tomcat]['threadpool_min_spare_threads']
```  
**unpack\$1wars **  <a name="attributes-recipes-java-unpack"></a>
WAR 파일의 압축을 풀지 여부(부울). 기본값은 `true`입니다.  

```
node['opsworks_java']['tomcat]['unpack_wars']
```  
**uri\$1encoding **  <a name="attributes-recipes-java-encoding"></a>
URI 인코딩(문자열). 기본값은 `UTF-8`입니다.  

```
node['opsworks_java']['tomcat]['uri_encoding']
```  
**use\$1ssl\$1connector **  <a name="attributes-recipes-java-ssl"></a>
SSL 커넥터를 사용할지 여부(부울). 기본값은 `false`입니다.  

```
node['opsworks_java']['tomcat]['use_ssl_connector']
```  
**use\$1threadpool **  <a name="attributes-recipes-java-threadpool"></a>
스레드 풀을 사용할지 여부(부울). 기본값은 `false`입니다.  

```
node['opsworks_java']['tomcat]['use_threadpool']
```  
**userdatabase\$1pathname **  <a name="attributes-recipes-java-userdb"></a>
사용자 데이터베이스 경로 이름(문자열). 기본값은 `conf/tomcat-users.xml`입니다.  

```
node['opsworks_java']['tomcat]['userdatabase_pathname']
```

# passenger\$1apache2 Attributes
<a name="attributes-recipes-passenger"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이러한 속성은 Linux 스택에서만 사용할 수 있습니다.

[`passenger_apache2` 속성](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/passenger_apache2/attributes/passenger.rb)은 [Phusion Passenger](https://www.phusionpassenger.com/) 구성을 지정합니다. 자세한 정보는 [Phusion Passenger 사용 설명서, Apache 버전](http://www.modrails.com/documentation/Users%20guide%20Apache.html) 단원을 참조하세요. 내장 속성을 재정의해 사용자 지정 값을 지정하는 방법에 대한 자세한 정보는 [속성 재정의](workingcookbook-attributes.md) 단원을 참조하세요.


****  

|  |  |  | 
| --- |--- |--- |
| [friendly\$1error\$1pages](#attributes-recipes-passenger-friendly-error-pages) | [gem\$1bin ](#attributes-recipes-passenger-gem-bin) | [gems\$1path](#attributes-recipes-passenger-gems-path) | 
| [high\$1performance\$1mode ](#attributes-recipes-passenger-perf) | [root\$1path ](#attributes-recipes-passenger-root) | [max\$1instances\$1per\$1app ](#attributes-recipes-passenger-instances) | 
| [max\$1pool\$1size ](#attributes-recipes-passenger-max-pool) | [max\$1requests](#attributes-recipes-passenger-max-requests) | [module\$1path ](#attributes-recipes-passenger-mod_path) | 
| [pool\$1idle\$1time ](#attributes-recipes-passenger-pool-idle) | [rails\$1app\$1spawner\$1idle\$1time ](#attributes-recipes-passenger-rails-app) | [rails\$1framework\$1spawner\$1idle\$1time ](#attributes-recipes-passenger-rails-framework) | 
| [rails\$1spawn\$1method ](#attributes-recipes-passenger-rails-spawn) | [ruby\$1bin ](#attributes-recipes-passenger-ruby-bin) | [ruby\$1wrapper\$1bin ](#attributes-recipes-passenger-ruby-wrapper) | 
| [stat\$1throttle\$1rate ](#attributes-recipes-passenger-throttle) | [버전](#attributes-recipes-passenger-version) |  | 

**friendly\$1error\$1pages**  <a name="attributes-recipes-passenger-friendly-error-pages"></a>
애플리케이션 시작이 실패하는 경우, 익숙한 오류 페이지를 표시할지 여부(문자열). 이 속성은 'on' 또는 'off'로 설정할 수 있으며, 기본 값은 'off'입니다.  

```
node[:passenger][:friendly_error_pages]
```

**gem\$1bin **  <a name="attributes-recipes-passenger-gem-bin"></a>
Gem 이진수의 위치(문자열). 기본값은 `'/usr/local/bin/gem'`입니다.  

```
node[:passenger][:gem_bin]
```

**gems\$1path**  <a name="attributes-recipes-passenger-gems-path"></a>
gems 경로(문자열). 기본값은 인스턴스의 Ruby 버전에 따라 다릅니다. 예제:  
+ Ruby 버전 1.8: `'/usr/local/lib/ruby/gems/1.8/gems'`
+ Ruby 버전 1.9: `'/usr/local/lib/ruby/gems/1.9.1/gems'`

```
node[:passenger][:gems_path]
```

**high\$1performance\$1mode **  <a name="attributes-recipes-passenger-perf"></a>
Passenger의 고성능 모드를 사용할지 여부(문자열). 가능한 값은 `'on'`와 `'off'`입니다. 기본값은 `'off'`입니다.  

```
node[:passenger][:high_performance_mode ]
```

**root\$1path **  <a name="attributes-recipes-passenger-root"></a>
Passenger 루트 디렉터리(문자열). 기본값은 Ruby 및 Passenger 버전에 따라 다릅니다. Chef 구문에서 값은 `"#{node[:passenger][:gems_path]}/passenger-#{passenger[:version]}"`입니다.  

```
node[:passenger][:root_path]
```

**max\$1instances\$1per\$1app **  <a name="attributes-recipes-passenger-instances"></a>
앱당 애플리케이션 프로세스 최대 수(숫자). 기본값은 `0`입니다. 자세한 정보는 [PassengerMaxInstancesPerApp](http://www.modrails.com/documentation/Users%20guide%20Apache.html#_passengermaxinstancesperapp_lt_integer_gt) 단원을 참조하세요.  

```
node[:passenger][:max_instances_per_app]
```

**max\$1pool\$1size **  <a name="attributes-recipes-passenger-max-pool"></a>
애플리케이션 프로세서의 최대 수(숫자). 기본값은 `8`입니다. 자세한 정보는 [PassengerMaxPoolSize](http://www.modrails.com/documentation/Users%20guide%20Apache.html#_passengermaxpoolsize_lt_integer_gt)를 참조하세요.  

```
node[:passenger][:max_pool_size]
```

**max\$1requests**  <a name="attributes-recipes-passenger-max-requests"></a>
요청의 최대 수(숫자). 기본값은 `0`입니다.  

```
node[:passenger][:max_requests]
```

**module\$1path **  <a name="attributes-recipes-passenger-mod_path"></a>
모듈 경로(문자열). 기본값은 다음과 같습니다.  
+ Amazon Linux 및 RHEL: `"#{node['apache']['libexecdir']}/mod_passenger.so"`
+ Ubuntu: `"#{passenger[:root\$1path]}/ext/apache2/mod_passenger.so"`

```
node[:passenger][:module_path]
```

**pool\$1idle\$1time **  <a name="attributes-recipes-passenger-pool-idle"></a>
애플리케이션 프로세스가 유휴 상태로 있을 수 있는 최대 시간(초)(숫자). 기본값은 `14400`(4시간)입니다. 자세한 정보는 [PassengerPoolIdleTime](http://www.modrails.com/documentation/Users%20guide%20Apache.html#PassengerPoolIdleTime) 단원을 참조하세요.  

```
node[:passenger][:pool_idle_time]
```

**rails\$1app\$1spawner\$1idle\$1time **  <a name="attributes-recipes-passenger-rails-app"></a>
Rails 앱 스포너의 최대 유휴 시간(숫자). 이 속성이 0으로 설정되면 앱 스포너는 제한 시간이 없습니다. 기본값은 `0`입니다. 자세한 정보는 [Spawning Methods Explained](http://www.modrails.com/documentation/Users%20guide%20Apache.html#spawning_methods_explained)를 참조하세요.  

```
node[:passenger][:rails_app_spawner_idle_time]
```

**rails\$1framework\$1spawner\$1idle\$1time **  <a name="attributes-recipes-passenger-rails-framework"></a>
Rails 프레임워크 스포너의 최대 유휴 시간(숫자). 이 속성이 0으로 설정되면 프레임워크 스포너는 제한 시간이 없습니다. 기본값은 `0`입니다. 자세한 정보는 [Spawning Methods Explained](http://www.modrails.com/documentation/Users%20guide%20Apache.html#spawning_methods_explained)를 참조하세요.  

```
node[:passenger][:rails_framework_spawner_idle_time]
```

**rails\$1spawn\$1method **  <a name="attributes-recipes-passenger-rails-spawn"></a>
Rails 복제 메서드(문자열). 기본값은 `'smart-lv2'`입니다. 자세한 정보는 [Spawning Methods Explained](http://www.modrails.com/documentation/Users%20guide%20Apache.html#spawning_methods_explained)를 참조하세요.  

```
node[:passenger][:rails_spawn_method]
```

**ruby\$1bin **  <a name="attributes-recipes-passenger-ruby-bin"></a>
Ruby 이진수의 위치(문자열). 기본값은 `'/usr/local/bin/ruby'`입니다.  

```
node[:passenger][:ruby_bin]
```

**ruby\$1wrapper\$1bin **  <a name="attributes-recipes-passenger-ruby-wrapper"></a>
Ruby 래퍼 스크립트의 위치(문자열). 기본값은 `'/usr/local/bin/ruby_gc_wrapper.sh'`입니다.  

```
node[:passenger][:ruby_wrapper_bin]
```

**stat\$1throttle\$1rate **  <a name="attributes-recipes-passenger-throttle"></a>
Passenger가 파일 시스템 검사를 수행하는 속도(숫자). 기본값은 `5`이며, 이는 검사가 최대 5초마다 수행됨을 뜻합니다. 자세한 정보는 [PassengerStatThrottleRate](http://www.modrails.com/documentation/Users%20guide%20Apache.html#_passengerstatthrottlerate_lt_integer_gt)를 참조하세요.  

```
node[:passenger][:stat_throttle_rate]
```

**버전**  <a name="attributes-recipes-passenger-version"></a>
버전(문자열). 기본값은 `'3.0.9'`입니다.  

```
node[:passenger][:version]
```

# ruby 속성
<a name="attributes-recipes-ruby"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이러한 속성은 Linux 스택에서만 사용할 수 있습니다.

[`ruby` 속성](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/ruby/attributes/ruby.rb)은 애플리케이션이 사용하는 Ruby 버전을 지정합니다. Ruby 2.1에서 의미 체계 버전 관리가 도입되면서 속성 사용이 바뀌었습니다. 예제를 포함한 버전 지정 방법에 대한 자세한 정보는 [Ruby 버전](workingcookbook-ruby.md)를 참조하세요. OpsWorks Stacks가 Ruby 버전을 결정하는 방법에 대한 자세한 내용은 기본 제공 속성 파일인 [ruby.rb](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/ruby/attributes/ruby.rb)를 참조하세요. 내장 속성을 재정의해 사용자 지정 값을 지정하는 방법에 대한 자세한 정보는 [속성 재정의](workingcookbook-attributes.md) 단원을 참조하십시오.

**full\$1version**  <a name="attributes-recipes-ruby-full"></a>
정품 버전 번호(문자열). 이 속성은 재정의해서는 안 됩니다. 그 대신 [[:opsworks][:ruby\$1version]](attributes-json-opsworks-other.md#attributes-json-opsworks-ruby-version)과 적절한 패치 버전 속성을 사용하여 버전을 지정하세요.  

```
[:ruby][:full_version]
```

**major\$1version**  <a name="attributes-recipes-ruby-major"></a>
메이저 버전 번호(문자열). 이 속성은 재정의해서는 안 됩니다. 그 대신 [[:opsworks][:ruby\$1version]](attributes-json-opsworks-other.md#attributes-json-opsworks-ruby-version)을 사용하여 메이저 버전을 지정하세요.  

```
[:ruby][:major_version]
```

**minor\$1version**  <a name="attributes-recipes-ruby-minor"></a>
마이너 버전 번호(문자열). 이 속성은 재정의해서는 안 됩니다. 그 대신 [[:opsworks][:ruby\$1version]](attributes-json-opsworks-other.md#attributes-json-opsworks-ruby-version)을 사용하여 마이너 버전을 지정하세요.  

```
[:ruby][:minor_version]
```

**패치**  <a name="attributes-recipes-ruby-patch"></a>
패치 수준(문자열). 이 속성은 Ruby 버전 2.0.0 및 이전 버전에 유효합니다. 이후의 Ruby 버전은 `patch_version` 속성을 사용합니다.  

```
[:ruby][:patch]
```
패치 번호는 `p`로 시작해야 합니다. 예를 들어 다음 사용자 지정 JSON을 사용하여 패치 수준 484를 지정합니다.  

```
{
  "ruby":{"patch":"p484"}
}
```

**patch\$1version**  <a name="attributes-recipes-ruby-patch-version"></a>
패치 번호(문자열). 이 속성은 Ruby 버전 2.1 및 이후 버전에 유효합니다. 그 이전의 Ruby 버전은 `patch` 속성을 사용합니다.  

```
[:ruby][:patch_version]
```

**pkgrelease**  <a name="attributes-recipes-ruby-pkgrelease"></a>
패키지 릴리스 번호(문자열).  

```
[:ruby][:pkgrelease]
```

# unicorn 속성
<a name="attributes-recipes-unicorn"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
이러한 속성은 Linux 스택에서만 사용할 수 있습니다.

[`unicorn` 속성](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.10/unicorn/attributes/default.rb)은 [Unicorn](http://unicorn.bogomips.org/) 구성을 지정합니다. 자세한 정보는 [Unicorn::Configurator](http://unicorn.bogomips.org/Unicorn/Configurator.html)를 참조하세요. 내장 속성을 재정의해 사용자 지정 값을 지정하는 방법에 대한 자세한 정보는 [속성 재정의](workingcookbook-attributes.md) 단원을 참조하세요.


****  

|  |  |  | 
| --- |--- |--- |
| [accept\$1filter](#attributes-recipes-unicorn-accept) | [backlog](#attributes-recipes-unicorn-backlog) | [delay](#attributes-recipes-unicorn-delay) | 
| [tcp\$1nodelay](#attributes-recipes-unicorn-nodelay) | [tcp\$1nopush](#attributes-recipes-unicorn-nopush) | [preload\$1app](#attributes-recipes-unicorn-preload) | 
| [제한 시간](#attributes-recipes-unicorn-timeout) | [tries](#attributes-recipes-unicorn-tries) | [버전](#attributes-recipes-unicorn-version) | 
| [worker\$1processes](#attributes-recipes-unicorn-worker) |  |  | 

**accept\$1filter**  <a name="attributes-recipes-unicorn-accept"></a>
accept 필터, `'httpready'` 또는 `'dataready'`(문자열). 기본값은 `'httpready'`입니다.  

```
node[:unicorn][:accept_filter]
```

**backlog**  <a name="attributes-recipes-unicorn-backlog"></a>
대기열이 보관할 수 있는 요청의 최대 수(숫자). 기본값은 `1024`입니다.  

```
node[:unicorn][:backlog]
```

**delay**  <a name="attributes-recipes-unicorn-delay"></a>
소켓 바인딩을 재시도하기 위해 기다릴 시간(초)(숫자). 기본값은 `0.5`입니다.  

```
node[:unicorn][:delay]
```

**preload\$1app**  <a name="attributes-recipes-unicorn-preload"></a>
worker 프로세스 포킹 전에 앱을 사전 로드할지 여부(부울). 기본값은 `true`입니다.  

```
node[:unicorn][:preload_app]
```

**tcp\$1nodelay**  <a name="attributes-recipes-unicorn-nodelay"></a>
TCP 소켓에 대한 Nagle의 알고리즘을 비활성화할지 여부(부울). 기본값은 `true`입니다.  

```
node[:unicorn][:tcp_nodelay]
```

**tcp\$1nopush**  <a name="attributes-recipes-unicorn-nopush"></a>
TCP\$1CORK를 활성화할지 여부(부울). 기본값은 `false`입니다.  

```
node[:unicorn][:tcp_nopush]
```

**제한 시간**  <a name="attributes-recipes-unicorn-timeout"></a>
각 요청마다 worker 사용이 허용되는 최대 시간(초)(숫자). 제한 시간 값을 초과하는 worker는 종료됩니다. 기본값은 `60`입니다.  

```
node[:unicorn][:timeout]
```

**tries**  <a name="attributes-recipes-unicorn-tries"></a>
소켓에 대한 바인딩을 재시도할 최대 횟수(숫자). 기본값은 `5`입니다.  

```
node[:unicorn][:tries]
```

**버전**  <a name="attributes-recipes-unicorn-version"></a>
Unicorn 버전(문자열). 기본값은 `'4.7.0'`입니다.  

```
node[:unicorn][:version]
```

**worker\$1processes**  <a name="attributes-recipes-unicorn-worker"></a>
worker 프로세스의 수(숫자). 기본값은 존재하는 경우, `max_pool_size`이고 그렇지 않은 경우에는 `4`입니다.  

```
node[:unicorn][:worker_processes]
```

# Linux용 Chef 11.10 및 이전 버전 문제 해결
<a name="troubleshooting-chef-11-linux"></a>

**중요**  
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.

**참고**  
추가 문제 해결 정보는 [디버깅 및 문제 해결 안내서](troubleshoot.md) 단원을 참조하세요.

## Linux용 Chef 11.10 및 이전 버전의 Chef 로그
<a name="troubleshooting-chef-11-linux-logs"></a>

OpsWorks Stacks는 각 인스턴스의 Chef 로그를 `/var/lib/aws/opsworks/chef` 디렉터리에 저장합니다. 이 디렉터리에 액세스하려면 sudo 권한이 필요합니다. 각 실행에 대한 로그 파일은 `YYYY-MM-DD-HH-MM-SS-NN.log` 파일에 저장됩니다.

자세한 내용은 다음을 참조하세요.
+ [콘솔을 사용하여 Chef 로그 보기](troubleshoot-debug-log.md#troubleshoot-debug-log-console)
+ [CLI 또는 API를 사용하여 Chef 로그 보기](troubleshoot-debug-log.md#troubleshoot-debug-log-cli)
+ [Chef 로그 해석](troubleshoot-debug-log.md#troubleshoot-debug-log-interpret)
+ [일반적인 Chef 로그 오류](troubleshoot-debug-log.md#troubleshoot-debug-log-errors)