기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 계층 확장
**중요**
이 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)
# 레시피를 사용하여 스크립트 실행
**중요**
이 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 배포 후크 사용
**중요**
이 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 작업 실행
**중요**
이 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 인스턴스에서 패키지 설치 및 구성
**중요**
이 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)을 참조하세요.