기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 디버깅 및 문제 해결 안내서
**중요**
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 서비스 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.
레시피를 디버깅하거나 서비스 문제를 해결해야 하는 경우, 일반적으로 가장 좋은 방법은 다음 단계를 순서대로 따르는 것입니다.
1. 구체적 문제를 [일반적인 디버깅 및 문제 해결](common-issues.md)에서 확인합니다.
1. [OpsWorks Stacks 포럼](https://forums.aws.amazon.com/forum.jspa?forumID=153#)을 검색하여 문제가 논의된 적이 있는지 확인합니다.
포럼에는 경험이 풍부한 많은 사용자가 포함되며 OpsWorks Stacks 팀에서 모니터링합니다.
1. 레시피 관련 문제는 [레시피 디버깅](troubleshoot-debug.md) 단원을 참조하세요.
1. OpsWorks Stacks Support에 문의하거나 [OpsWorks Stacks 포럼](https://forums.aws.amazon.com/forum.jspa?forumID=153#)에 문제를 게시합니다.
다음 섹션에서는 레시피 디버깅에 대해 안내합니다. 마지막 섹션에서는 일반적인 디버깅 및 문제 해결과 해법을 설명합니다.
**참고**
각각의 Chef 실행은 실행에 대한 상세한 설명을 제공하고 중요한 문제 해결 리소스인 로그를 생성합니다. 로그의 세부 정보의 양을 지정하려면 사용자 지정 레시피에 원하는 로그 수준을 지정하는 [https://docs.chef.io/resource_log.html](https://docs.chef.io/resource_log.html) 문을 추가합니다. 기본값은 `:info`입니다. 다음 예제는 Chef 로그 수준을 실행에 대한 가장 상세한 설명을 제공하는 `:debug`로 설정하는 방법을 보여 줍니다.
```
Chef::Log.level = :debug
```
Chef 로그를 보고 해석하는 방법에 대한 자세한 정보는 [Chef 로그](troubleshoot-debug-log.md) 단원을 참조하세요.
**Topics**
+ [레시피 디버깅](troubleshoot-debug.md)
+ [일반적인 디버깅 및 문제 해결](common-issues.md)
# 레시피 디버깅
**중요**
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.
수명 주기 이벤트가 발생하거나 [레시피 실행 스택 명령](workingstacks-commands.md)이 사용되면 OpsWorks Stacks가 [에이전트](troubleshoot-debug-cli.md)로 명령을 전송해 지정된 인스턴스에서 해당 레시피를 실행하기 위한 [Chef Solo 실행](https://docs.chef.io/ctl_chef_solo.html)을 시작합니다. 이 섹션에서는 실패한 레시피를 디버깅할 수 있는 몇 가지 방법을 설명합니다.
**Topics**
+ [실패한 인스턴스에 로그인](troubleshoot-debug-login.md)
+ [Chef 로그](troubleshoot-debug-log.md)
+ [OpsWorks Stacks 에이전트 CLI 사용](troubleshoot-debug-cli.md)
# 실패한 인스턴스에 로그인
**중요**
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.
레시피가 실패하면 인스턴스는 온라인 상태가 아니라 `setup_failed` 상태로 끝납니다. 인스턴스가 OpsWorks Stacks에 관한 한 온라인 상태가 아니더라도 EC2 인스턴스가 실행 중이므로 로그인해 문제를 해결하는 것이 유용한 경우가 많습니다. 예를 들어 애플리케이션 또는 사용자 지정 쿡북이 올바로 설치되었는지 확인할 수 있습니다. [SSH](workinginstances-ssh.md) 및 [RDP](workinginstances-rdp.md) 로그인에 대한 OpsWorks Stacks 기본 제공 지원은 온라인 상태의 인스턴스에서만 사용할 수 있습니다. 하지만 SSH 키 페어를 인스턴스에 할당했다면 다음과 같이 로그인이 가능합니다.
+ Linux 인스턴스 - SSH 키 페어의 프라이빗 키를 사용하여 OpenSSH 또는 PuTTY와 같은 타사 SSH 클라이언트로 로그인합니다.
이 목적을 위해 EC2 키 페어 또는 [개인 SSH 키 페어](security-ssh-access.md)를 사용할 수 있습니다.
+ Windows 인스턴스 - EC2 키 페어의 프라이빗 키를 사용하여 인스턴스의 관리자 암호를 검색합니다.
이 암호를 사용하여 원하는 RDP 클라이언트로 로그인합니다. 자세한 내용은 [관리자로 로그인](workinginstances-rdp.md#workinginstances-rdp-admin) 단원을 참조하십시오. [개인 SSH 키 페어](security-ssh-access.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 로그는 특히 레시피 디버깅을 위한 주요 문제 해결 리소스 중 하나입니다. OpsWorks Stacks는 각 명령에 대한 Chef 로그를 캡처하고 인스턴스의 최신 명령 30개에 대한 로그를 유지합니다. 실행이 디버깅 모드이므로 로그에는 `stdout` 및 `stderror`로 전송되는 텍스트를 비롯해 Chef 실행에 대한 자세한 설명이 포함됩니다. 레시피가 실패할 경우 로그에 Chef 스택 트레이스가 포함됩니다.
OpsWorks Stacks는 Chef 로그를 볼 수 있는 여러 가지 방법을 제공합니다. 로그 정보를 입수하면 이 정보를 사용하여 실패한 레시피를 디버깅할 수 있습니다.
**참고**
또한 SSH를 사용하여 인스턴스에 연결하고 CLI `show_log` 명령을 실행하여 지정된 로그의 끝부분을 볼 수도 있습니다. 자세한 내용은 [Chef 로그 표시](troubleshoot-debug-cli.md#troubleshoot-debug-cli-log) 단원을 참조하십시오.
**Topics**
+ [콘솔을 사용하여 Chef 로그 보기](#troubleshoot-debug-log-console)
+ [CLI 또는 API를 사용하여 Chef 로그 보기](#troubleshoot-debug-log-cli)
+ [인스턴스에서 Chef 로그 보기](#troubleshoot-debug-log-instance)
+ [Chef 로그 해석](#troubleshoot-debug-log-interpret)
+ [일반적인 Chef 로그 오류](#troubleshoot-debug-log-errors)
## 콘솔을 사용하여 Chef 로그 보기
Chef 로그를 보는 가장 간단한 방법은 인스턴스의 세부 정보 페이지로 이동하는 것입니다. [**로그**] 섹션에는 각 이벤트 및 [레시피 실행](workingstacks-commands.md) 명령에 대한 항목이 포함되어 있습니다. 다음은 인스턴스의 [**로그**] 섹션입니다. 구성 및 설정 수명 주기 이벤트에 해당하는 [**구성**] 및 [**설정**] 명령이 표시되어 있습니다.
![\[Logs section showing configure and setup commands with timestamps and durations.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/gs11.png)
해당 명령의 **로그** 열에서 **표시**를 클릭하면 해당 Chef 로그를 볼 수 있습니다. 오류가 발생하면 OpsWorks Stacks는 일반적으로 파일 끝에 있는 오류에 대한 로그를 자동으로 엽니다.
## CLI 또는 API를 사용하여 Chef 로그 보기
OpsWorks Stacks CLI [https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-commands.html](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-commands.html) 명령 또는 [https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeCommands.html](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_DescribeCommands.html) API 작업을 사용하여 Amazon S3 버킷에 저장된 로그를 볼 수 있습니다. 다음은 CLI를 사용하여 지정된 인스턴스에 대한 현재 로그 파일 세트를 보는 방법을 보여줍니다. `DescribeCommands`를 사용하기 위한 절차는 기본적으로 비슷합니다.
**OpsWorks Stacks를 사용하여 인스턴스의 Chef 로그를 보려면**
1. 인스턴스의 세부 정보 페이지를 열고 인스턴스의 **OpsWorks ID** 값을 복사해 둡니다.
1. 이 ID 값을 사용하여 다음과 같이 `describe-commands` CLI 명령을 실행합니다.
```
aws opsworks describe-commands --instance-id 67bf0da2-29ed-4217-990c-d895d51812b9
```
명령은 OpsWorks Stacks가 인스턴스에서 실행한 각 명령에 대해 포함된 객체가 있는 JSON 객체를 반환하며, 가장 최근 객체가 먼저 반환됩니다. 이 예제의 `Type` 파라미터에는 각 포함 객체의 명령 유형, `configure` 명령 및 `setup` 명령이 포함되어 있습니다.
```
{
"Commands": [
{
"Status": "successful",
"CompletedAt": "2013-10-25T19:38:36+00:00",
"InstanceId": "67bf0da2-29ed-4217-990c-d895d51812b9",
"AcknowledgedAt": "2013-10-25T19:38:24+00:00",
"LogUrl": "https://s3.amazonaws.com/prod_stage-log/logs/b6c402df-5c23-45b2-a707-ad20b9c5ae40?AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE
&Expires=1382731518&Signature=YkqS5IZN2P4wixjHwoC3aCMbn5s%3D&response-cache-control=private&response-content-encoding=gzip&response-content-
type=text%2Fplain",
"Type": "configure",
"CommandId": "b6c402df-5c23-45b2-a707-ad20b9c5ae40",
"CreatedAt": "2013-10-25T19:38:11+00:00",
"ExitCode": 0
},
{
"Status": "successful",
"CompletedAt": "2013-10-25T19:31:08+00:00",
"InstanceId": "67bf0da2-29ed-4217-990c-d895d51812b9",
"AcknowledgedAt": "2013-10-25T19:29:01+00:00",
"LogUrl": "https://s3.amazonaws.com/prod_stage-log/logs/2a90e862-f974-42a6-9342-9a4f03468358?AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE
&Expires=1382731518&Signature=cxKYHO8mCCd4MvOyFb6ywebeQtA%3D&response-cache-control=private&response-content-encoding=gzip&response-content-
type=text%2Fplain",
"Type": "setup",
"CommandId": "2a90e862-f974-42a6-9342-9a4f03468358",
"CreatedAt": "2013-10-25T19:26:01+00:00",
"ExitCode": 0
}
]
}
```
1. `LogUrl` 값을 브라우저에 복사해 로그를 확인합니다.
인스턴스에 많은 명령이 있을 경우 `describe-commands`에 파라미터를 추가하여 응답 객체에 포함된 명령을 필터링할 수 있습니다. 자세한 내용은 [describe-commands](https://docs.aws.amazon.com/cli/latest/reference/opsworks/describe-commands.html)를 참조하세요.
## 인스턴스에서 Chef 로그 보기
**참고**
이 섹션의 각 항목은 Chef 12에 적용됩니다. Chef 11.10 및 이전 릴리스에 대한 Chef 로그의 위치에 대한 자세한 정보는 [Linux용 Chef 11.10 및 이전 버전 문제 해결](https://docs.aws.amazon.com/opsworks/latest/userguide/troubleshooting-chef-11-linux.html) 단원을 참조하세요.
### Linux 인스턴스
OpsWorks Stacks는 각 인스턴스의 Chef 로그를 `/var/chef/runs` 디렉터리에 저장합니다. (Linux 인스턴스의 경우 이 디렉터리에 JSON 형식 파일로 저장되는 연결된 [데이터 백](data-bags.md)도 들어 있습니다.) 이 디렉터리에 액세스하려면 [sudo 권한](opsworks-security-users.md)이 필요합니다. 각 실행에 대한 로그는 개별 실행의 하위 디렉터리 안에 위치하는 `chef.log`라는 파일에 기록됩니다.
OpsWorks Stacks는 내부 로그를 인스턴스의 `/var/log/aws/opsworks` 폴더에 저장합니다. 일반적으로 이 정보는 문제 해결 목적으로는 그다지 유용하지 않습니다. 그러나 이러한 로그는 OpsWorks Stacks 지원에 유용하며 서비스에 문제가 발생할 경우 제공하라는 메시지가 표시될 수 있습니다. Linux 로그가 때로는 유용한 문제 해결 데이터를 제공할 수도 있습니다.
### Windows 인스턴스
**에이전트 로그**
Windows 인스턴스에서는 OpsWorks 로그가 다음과 같은 `ProgramData` 경로에 저장됩니다. 번호에 타임스탬프가 포함됩니다.
```
C:\ProgramData\OpsWorksAgent\var\logs\number
```
**참고**
기본적으로 `ProgramData`는 숨겨진 폴더입니다. 폴더 숨김을 해제하려면 [**폴더 옵션**]으로 이동합니다. [**보기**]에서 숨겨진 파일을 표시하는 옵션을 선택합니다.
다음 예제는 Windows 인스턴스에 대한 에이전트 로그입니다.
```
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 5/24/2015 11:59 PM 127277 command.20150524.txt
-a--- 5/25/2015 11:59 PM 546772 command.20150525.txt
-a--- 5/26/2015 11:59 PM 551514 command.20150526.txt
-a--- 5/27/2015 9:43 PM 495181 command.20150527.txt
-a--- 5/24/2015 11:59 PM 24353 keepalive.20150524.txt
-a--- 5/25/2015 11:59 PM 106232 keepalive.20150525.txt
-a--- 5/26/2015 11:59 PM 106208 keepalive.20150526.txt
-a--- 5/27/2015 8:54 PM 92593 keepalive.20150527.txt
-a--- 5/24/2015 7:19 PM 3891 service.20150524.txt
-a--- 5/27/2015 8:54 PM 1493 service.20150527.txt
-a--- 5/24/2015 11:59 PM 112549 wire.20150524.txt
-a--- 5/25/2015 11:59 PM 501501 wire.20150525.txt
-a--- 5/26/2015 11:59 PM 499640 wire.20150526.txt
-a--- 5/27/2015 8:54 PM 436870 wire.20150527.txt
```
**Chef 로그**
Windows 인스턴스에서는 Chef 로그가 다음과 같은 `ProgramData` 경로에 저장됩니다. 번호에 타임스탬프가 포함됩니다.
```
C:\ProgramData\OpsWorksAgent\var\commands\number
```
**참고**
이 디렉터리에는 첫 번째 (OpsWorks 소유) Chef 실행의 출력만 포함됩니다.
다음 예제는 Windows 인스턴스에 대한 OpsWorks 소유 Chef 로그입니다.
```
Mode LastWriteTime Name
---- ------------- ----
d---- 5/24/2015 7:23 PM configure-7ecb5f47-7626-439b-877f-5e7cb40ab8be
d---- 5/26/2015 8:30 PM configure-8e74223b-d15d-4372-aeea-a87b428ffc2b
d---- 5/24/2015 6:34 PM configure-c3980a1c-3d08-46eb-9bae-63514cee194b
d---- 5/26/2015 8:32 PM grant_remote_access-70dbf834-1bfa-4fce-b195-e50e85402f4c
d---- 5/26/2015 10:30 PM revoke_remote_access-1111fce9-843a-4b27-b93f-ecc7c5e9e05b
d---- 5/24/2015 7:21 PM setup-754ec063-8b60-4cd4-b6d7-0e89d7b7aa78
d---- 5/26/2015 8:27 PM setup-af5bed36-5afd-4115-af35-5766f88bc039
d---- 5/24/2015 6:32 PM setup-d8abeffa-24d4-414b-bfb1-4ad07319f358
d---- 5/24/2015 7:13 PM shutdown-c7130435-9b5c-4a95-be17-6b988fc6cf9a
d---- 5/26/2015 8:25 PM sync_remote_users-64c79bdc-1f6f-4517-865b-23d2def4180c
d---- 5/26/2015 8:48 PM update_custom_cookbooks-2cc59a94-315b-414d-85eb-2bdea6d76c6a
```
**사용자 Chef 로그**
사용자의 Chef 실행에 대한 로그는 다음 다이어그램과 같이 Chef 명령의 번호를 사용하여 명명되는 폴더 안의 `logfile.txt`라는 이름의 파일에서 확인할 수 있습니다.
C:/chef └── `runs` └── `command-12345` ├── `attribs.json` ├── `client.rb` └── `logfile.txt`
## Chef 로그 해석
로그의 첫 부분은 대부분 내부 Chef 로깅을 포함합니다
```
# Logfile created on Thu Oct 17 17:25:12 +0000 2013 by logger.rb/1.2.6
[2013-10-17T17:25:12+00:00] INFO: *** Chef 11.4.4 ***
[2013-10-17T17:25:13+00:00] DEBUG: Building node object for php-app1.localdomain
[2013-10-17T17:25:13+00:00] DEBUG: Extracting run list from JSON attributes provided on command line
[2013-10-17T17:25:13+00:00] INFO: Setting the run_list to ["opsworks_custom_cookbooks::load", "opsworks_custom_cookbooks::execute"] from JSON
[2013-10-17T17:25:13+00:00] DEBUG: Applying attributes from json file
[2013-10-17T17:25:13+00:00] DEBUG: Platform is amazon version 2013.03
[2013-10-17T17:25:13+00:00] INFO: Run List is [recipe[opsworks_custom_cookbooks::load], recipe[opsworks_custom_cookbooks::execute]]
[2013-10-17T17:25:13+00:00] INFO: Run List expands to [opsworks_custom_cookbooks::load, opsworks_custom_cookbooks::execute]
[2013-10-17T17:25:13+00:00] INFO: Starting Chef Run for php-app1.localdomain
[2013-10-17T17:25:13+00:00] INFO: Running start handlers
[2013-10-17T17:25:13+00:00] INFO: Start handlers complete.
[2013-10-17T17:25:13+00:00] DEBUG: No chefignore file found at /opt/aws/opsworks/releases/20131015111601_209/cookbooks/chefignore no files will be ignored
[2013-10-17T17:25:13+00:00] DEBUG: Cookbooks to compile: ["gem_support", "packages", "opsworks_bundler", "opsworks_rubygems", "ruby", "ruby_enterprise", "dependencies", "opsworks_commons", "scm_helper", :opsworks_custom_cookbooks]
[2013-10-17T17:25:13+00:00] DEBUG: Loading cookbook gem_support's library file: /opt/aws/opsworks/releases/20131015111601_209/cookbooks/gem_support/libraries/current_gem_version.rb
[2013-10-17T17:25:13+00:00] DEBUG: Loading cookbook packages's library file: /opt/aws/opsworks/releases/20131015111601_209/cookbooks/packages/libraries/packages.rb
[2013-10-17T17:25:13+00:00] DEBUG: Loading cookbook dependencies's library file: /opt/aws/opsworks/releases/20131015111601_209/cookbooks/dependencies/libraries/current_gem_version.rb
[2013-10-17T17:25:13+00:00] DEBUG: Loading cookbook opsworks_commons's library file: /opt/aws/opsworks/releases/20131015111601_209/cookbooks/opsworks_commons/libraries/activesupport_blank.rb
[2013-10-17T17:25:13+00:00] DEBUG: Loading cookbook opsworks_commons's library file: /opt/aws/opsworks/releases/20131015111601_209/cookbooks/opsworks_commons/libraries/monkey_patch_chefgem_resource.rb
...
```
파일의 이 부분은 주로 Chef 전문가에게 유용합니다. 대부분의 명령이 훨씬 더 많은 레시피와 관련되지만 실행 목록에는 두 개의 레시피만 나열됩니다. 이들 두 레시피는 다른 모든 내장 및 사용자 지정 레시피를 로드 및 실행하는 작업을 처리합니다.
이 파일에서 가장 중요한 부분은 일반적으로 끝부분입니다. 실행이 성공적으로 종료하면 다음과 같은 내용이 보일 것입니다.
```
...
[Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: STDERR:
[Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: ---- End output of /sbin/service mysqld restart ----
[Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: Ran /sbin/service mysqld restart returned 0
[Tue, 11 Jun 2013 16:00:50 +0000] INFO: service[mysql]: restarted successfully
[Tue, 11 Jun 2013 16:00:50 +0000] INFO: Chef Run complete in 84.07096 seconds
[Tue, 11 Jun 2013 16:00:50 +0000] INFO: cleaning the checksum cache
[Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: removing unused checksum cache file /var/chef/cache/checksums/chef-file--tmp-chef-rendered-template20130611-4899-8wef7e-0
[Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: removing unused checksum cache file /var/chef/cache/checksums/chef-file--tmp-chef-rendered-template20130611-4899-1xpwyb6-0
[Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: removing unused checksum cache file /var/chef/cache/checksums/chef-file--etc-monit-conf
[Tue, 11 Jun 2013 16:00:50 +0000] INFO: Running report handlers
[Tue, 11 Jun 2013 16:00:50 +0000] INFO: Report handlers complete
[Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: Exiting
```
**참고**
에이전트 CLI를 사용하여 실행 도중 또는 이후에 로그의 끝부분을 표시할 수 있습니다. 자세한 내용은 [Chef 로그 표시](troubleshoot-debug-cli.md#troubleshoot-debug-cli-log) 단원을 참조하십시오.
레시피가 실패할 경우 ERROR 수준 출력을 찾아야 합니다. 이 출력에는 예외, 그 다음에 Chef 스택 트레이스가 기록됩니다. 다음은 그 예입니다.
```
...
Please report any problems with the /usr/scripts/mysqlbug script!
[ OK ]
MySQL Daemon failed to start.
Starting mysqld: [FAILED]STDERR: 130611 15:07:55 [Warning] The syntax '--log-slow-queries' is deprecated and will be removed in a future release. Please use '--slow-query-log'/'--slow-query-log-file' instead.
130611 15:07:56 [Warning] The syntax '--log-slow-queries' is deprecated and will be removed in a future release. Please use '--slow-query-log'/'--slow-query-log-file' instead.
---- End output of /sbin/service mysqld start ----
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/mixin/command.rb:184:in `handle_command_failures'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/mixin/command.rb:131:in `run_command'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/provider/service/init.rb:37:in `start_service'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/provider/service.rb:60:in `action_start'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource.rb:406:in `send'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource.rb:406:in `run_action'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/runner.rb:53:in `run_action'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/runner.rb:89:in `converge'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/runner.rb:89:in `each'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/runner.rb:89:in `converge'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection.rb:94:in `execute_each_resource'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection/stepable_iterator.rb:116:in `call'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection/stepable_iterator.rb:116:in `call_iterator_block'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection/stepable_iterator.rb:85:in `step'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection/stepable_iterator.rb:104:in `iterate'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection/stepable_iterator.rb:55:in `each_with_index'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection.rb:92:in `execute_each_resource'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/runner.rb:84:in `converge'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/client.rb:268:in `converge'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/client.rb:158:in `run'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/application/solo.rb:190:in `run_application'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/application/solo.rb:181:in `loop'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/application/solo.rb:181:in `run_application'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/application.rb:62:in `run'
/opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/chef-solo:25
/opt/aws/opsworks/current/bin/chef-solo:16:in `load'
/opt/aws/opsworks/current/bin/chef-solo:16
```
파일의 끝부분이 Chef 스택 트레이스입니다. 예외 바로 앞의 출력도 검토해야 합니다. 이 출력에 실패 원인을 판단하는 데 유용할 수 있는 `package not available`과 같은 시스템 오류가 포함되는 경우가 종종 있습니다. 이 경우 MySQL 데몬이 시작하지 못한 것입니다.
## 일반적인 Chef 로그 오류
다음은 일반적인 Chef 로그 오류와 그 해결 방법입니다.
로그를 찾을 수 없음
Chef 실행 시작 후 Chef 실행이 끝났을 때 웹 페이지에서 로그를 볼 수 있게 해주는 미리 서명된 Amazon S3 URL이 인스턴스로 전송됩니다. 이 URL은 2시간 후에 만료되므로 Chef 실행이 2시간 이상 걸릴 경우 Chef 실행 도중 문제가 발생하지 않는다 해도 로그가 Amazon S3 사이트로 업로드되지 않습니다. 로그 생성 명령은 성공하지만 로그를 미리 서명된 URL에서가 아니라 인스턴스에서만 볼 수 있습니다.
로그가 갑자기 끝남
Chef 로그가 성공을 나타내거나 오류 정보를 표시하지 않고 갑자기 끝날 경우 아마도 메모리 부족 상태가 발생하여 Chef가 로그를 완료하지 못한 것일 수 있습니다. 최선의 옵션은 더 큰 용량의 인스턴스를 사용하여 다시 시도하는 것입니다.
쿡북 또는 레시피 누락
Chef가 쿡북 캐시에 없는 쿡북 또는 레시피를 마주칠 경우 다음과 같은 로그가 기록됩니다.
```
DEBUG: Loading Recipe mycookbook::myrecipe via include_recipe
ERROR: Caught exception during execution of custom recipe: mycookbook::myrecipe:
Cannot find a cookbook named mycookbook; did you forget to add metadata to a cookbook?
```
이 항목은 `mycookbook` 쿡북이 쿡북 캐시에 없음을 나타냅니다. Chef 11.4에서는 `metadata.rb`에서 종속성을 올바로 선언하지 않을 경우에도 이 오류가 발생할 수 있습니다.
OpsWorks Stacks는 인스턴스의 쿡북 캐시에서 레시피를 실행합니다. 인스턴스가 시작하면 쿡북이 리포지토리에서 이 캐시로 다운로드됩니다. 그러나 이후에 리포지토리의 쿡북을 수정하면 OpsWorks Stacks는 온라인 인스턴스의 캐시를 자동으로 업데이트하지 않습니다. 인스턴스 시작 후 쿡북을 수정했거나 새 쿡북을 추가한 경우 다음 단계를 수행하세요.
1. 리포지토리에서 변경을 커밋했는지 확인합니다.
1. [Update Cookbooks 스택 명령](workingstacks-commands.md)을 실행하여 리포지토리의 최신 버전으로 쿡북 캐시를 업데이트합니다.
로컬 명령 실패
Chef `execute` 리소스가 지정된 명령을 실행하지 못할 경우 다음과 같은 로그가 기록됩니다.
```
DEBUG: ---- End output of ./configure --with-config-file-path=/ returned 2
ERROR: execute[PHP: ./configure] (/root/opsworks-agent/site-cookbooks/php-fpm/recipes/install.rb line 48) had an error:
./configure --with-config-file-path=/
```
로그를 위로 스크롤하면 명령의 `stderr` 및 `stdout` 출력이 보일 것입니다. 이들은 명령이 실패한 이유를 판단하는 데 도움이 됩니다.
패키지 실패
패키지 설치가 실패할 경우 다음과 같은 로그가 기록됩니다.
```
ERROR: package[zend-server-ce-php-5.3] (/root/opsworks-agent/site-cookbooks/zend_server/recipes/install.rb line 20)
had an error: apt-get -q -y --force-yes install zend-server-ce-php-5.3=5.0.4+b17 returned 100, expected 0
```
로그를 위로 스크롤하면 명령의 STDOUT 및 STDERROR 출력이 보일 것입니다. 이들은 패키지 설치가 실패한 이유를 판단하는 데 도움이 됩니다.
# OpsWorks Stacks 에이전트 CLI 사용
**중요**
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.
**참고**
에이전트 CLI는 Linux 인스턴스에서만 사용할 수 있습니다.
모든 온라인 인스턴스에서 OpsWorks Stacks는 서비스와 통신하는 에이전트를 설치합니다. OpsWorks 그러면 Stacks 서비스가 에이전트에 명령을 전송하여 수명 주기 이벤트가 발생할 때 인스턴스에서 Chef 실행을 시작하는 등의 작업을 수행합니다. Linux 인스턴스에서는 에이전트가 문제 해결에 매우 유용한 명령줄 인터페이스(CLI)를 표시합니다. 에이전트 CLI 명령을 실행하려면 [SSH를 사용하여 인스턴스에 연결](workinginstances-ssh.md)합니다. 그런 다음 에이전트 CLI 명령을 실행하여 다음을 포함하여 다양한 작업을 수행합니다.
+ 레시피를 실행.
+ Chef 로그를 표시.
+ [스택 구성 및 배포 JSON](workingcookbook-json.md)를 표시
인스턴스와 SSH 연결을 설정하는 방법에 대한 자세한 정보는 [SSH를 사용하여 로그인](workinginstances-ssh.md) 단원을 참조하세요. 또한 스택에 대한 [SSH 및 sudo 권한](opsworks-security-users.md)도 있어야 합니다.
이 섹션에서는 문제 해결을 위해 에이전트 CLI를 사용하는 방법을 설명합니다. 자세한 내용 및 전체 명령 참조는 [OpsWorks Stacks 에이전트 CLI](agent.md) 단원을 참조하세요.
**Topics**
+ [레시피 실행](#troubleshoot-debug-cli-recipes)
+ [Chef 로그 표시](#troubleshoot-debug-cli-log)
+ [스택 구성 및 배포 JSON 표시](#troubleshoot-debug-cli-json)
## 레시피 실행
에이전트 CLI [`run_command`](agent-run.md) 명령은 에이전트에게 앞서 실행한 명령을 재실행하도록 지시합니다. 문제 해결에 가장 유용한 명령 `setup`, `configure`, `deploy` 및 `undeploy`은 각각 수명 주기 이벤트에 해당합니다. 이들 명령은 에이전트에게 Chef 실행을 시작하여 연결된 레시피를 실행하도록 지시합니다.
**참고**
`run_command` 명령은 지정된 명령과 연결된 레시피 그룹(일반적으로 특정 수명 주기 이벤트에 연결된 레시피)을 실행하는 것으로 제한됩니다. 이 명령을 사용하여 특정 레시피를 실행할 수는 없습니다. 하나 이상의 지정된 레시피를 실행하려면 [레시피 실행 스택 명령](workingstacks-commands.md) 또는 이와 동등한 CLI 또는 API 작업([https://docs.aws.amazon.com/cli/latest/reference/opsworks/create-deployment.html](https://docs.aws.amazon.com/cli/latest/reference/opsworks/create-deployment.html) 및 [https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateDeployment.html](https://docs.aws.amazon.com/opsworks/latest/APIReference/API_CreateDeployment.html))을 사용합니다.
`run_command` 명령은 사용자 지정 레시피, 특히 설정 및 Configure 수명 주기 이벤트에 할당된 것으로서 콘솔에서 직접 트리거할 수 없는 레시피를 디버깅하는 데 매우 유용합니다. `run_command`를 사용하여 특정 이벤트의 레시피를 인스턴스를 시작 또는 중지하지 않고도 원하는 횟수 만큼 실행할 수 있습니다.
**참고**
OpsWorks Stacks는 쿡북 리포지토리가 아닌 인스턴스의 쿡북 캐시에서 레시피를 실행합니다. OpsWorks Stacks는 인스턴스가 시작될 때 쿡북을이 캐시로 다운로드하지만 이후에 쿡북을 수정할 경우 온라인 인스턴스에서 캐시를 자동으로 업데이트하지 않습니다. 인스턴스 시작 이후 쿡북을 수정하지 않았다면 [Update Cookbooks 스택 명령](workingstacks-commands.md)을 실행하여 리포지토리의 최신 버전으로 쿡북 캐시를 업데이트하세요.
에이전트는 최근 명령만 캐시합니다. [`list_commands`](agent-list.md)를 실행하여 최근 명령을 나열할 수 있습니다. 그러면 캐시된 명령과 명령 실행 시간의 목록이 반환됩니다.
```
sudo opsworks-agent-cli list_commands
2013-02-26T19:08:26 setup
2013-02-26T19:12:01 configure
2013-02-26T19:12:05 configure
2013-02-26T19:22:12 deploy
```
최근 명령을 재실행하려면 다음을 실행합니다.
```
sudo opsworks-agent-cli run_command
```
지정된 명령의 최근 인스턴스를 재실행하려면 다음을 실행합니다.
```
sudo opsworks-agent-cli run_command command
```
예를 들어 설정 레시피를 재실행하려면 다음 명령을 실행할 수 있습니다.
```
sudo opsworks-agent-cli run_command setup
```
각 명령에는 명령이 실행된 당시의 스택 및 배포 상태를 나타내는 [스택 구성 및 배포 JSON](workingcookbook-json.md)이 연결되어 있습니다. 이 데이터는 명령마다 바뀔 수 있으므로 명령의 이전 인스턴스와 최근 인스턴스는 다른 데이터를 사용할 수 있습니다. 명령의 특정 인스턴스를 재실행하려면 `list_commands` 출력에서 시간을 복사하고 다음을 실행합니다.
```
sudo opsworks-agent-cli run_command time
```
이전 예제는 모두 해당 명령에 대해 설치된 JSON인 기본 JSON을 사용하여 명령을 재실행합니다. 다음과 같이 임의의 JSON 파일을 사용하여 명령을 재실행할 수 있습니다.
```
sudo opsworks-agent-cli run_command -f /path/to/valid/json.file
```
## Chef 로그 표시
에이전트 CLI [`show_log`](agent-show.md) 명령은 지정된 로그를 표시합니다. 명령이 완료되면 파일의 끝부분이 표시됩니다. 따라서 `show_log` 명령은 일반적으로 오류 정보를 찾을 수 있는 로그의 끝부분을 확인하는 편리한 방법을 제공합니다. 로그를 위로 스크롤하면 이전 부분을 볼 수 있습니다.
현재 명령의 로그를 표시하려면 다음을 실행합니다.
```
sudo opsworks-agent-cli show_log
```
특정 명령에 대한 로그를 표시할 수도 있지만, 에이전트는 마지막 30개의 명령에 대해서만 로그를 캐시한다는 점을 염두에 두십시오. [`list_commands`](agent-list.md)를 실행하여 인스턴스의 명령을 나열할 수 있습니다. 그러면 캐시된 명령과 명령 실행 시간의 목록이 반환됩니다. 예제는 [레시피 실행](#troubleshoot-debug-cli-recipes) 섹션을 참조하세요.
특정 명령의 최근 실행에 대한 로그를 표시하려면 다음을 실행합니다.
```
sudo opsworks-agent-cli show_log command
```
명령 파라미터는 `setup`, `configure`, `deploy`, `undeploy`, `start`, `stop` 또는 `restart`로 설정할 수 있습니다. 이들 명령은 대부분 수명 주기 이벤트에 해당하며 에이전트에게 연결된 레시피를 실행하도록 지시합니다.
특정 명령 실행에 대한 로그를 표시하려면 `list_commands` 출력에서 날짜를 복사하고 다음을 실행합니다.
```
sudo opsworks-agent-cli show_log date
```
실행 중인 명령이 있을 경우 `show_log`가 로그의 현재 상태를 표시합니다.
**참고**
오류 및 메모리 부족 문제를 해결하는 데 `show_log`를 사용하는 한 가지 방법은 다음과 같이 실행 도중 로그의 끝부분을 표시하는 것입니다.
`run_command`를 사용하여 해당 수명 주기 이벤트를 트리거합니다. 자세한 내용은 [레시피 실행](#troubleshoot-debug-cli-recipes) 단원을 참조하십시오.
`show_log`명령을 반복적으로 실행하여 로그가 기록되는 동안 로그의 끝부분을 확인합니다.
Chef에서 메모리 부족 또는 예기치 않은 종료가 발생하는 경우 로그가 갑자기 끝납니다. 레시피가 실패할 경우 로그가 예외 및 스택 트레이스로 끝납니다.
## 스택 구성 및 배포 JSON 표시
레시피가 사용하는 데이터는 많은 부분이 [스택 구성 및 배포 JSON](workingcookbook-json.md)에서 나옵니다. 이 JSON은 스택 구성, 배포, 그리고 사용자가 선택적으로 추가할 수 있는 사용자 지정 속성에 대한 상세한 설명을 제공하는 Chef 속성 세트를 정의합니다. 각 명령에 대해 OpsWorks Stacks는 명령 시 스택 및 배포 상태를 나타내는 JSON을 설치합니다. 자세한 내용은 [스택 구성 및 배포 속성](workingcookbook-json.md) 단원을 참조하십시오.
사용자 지정 레시피가 스택 구성 및 배포 JSON으로부터 데이터를 가져오는 경우 JSON을 검사하여 데이터를 확인할 수 있습니다. 스택 구성 및 배포 JSON을 표시하는 가장 간단한 방법은 에이전트 CLI [`get_json`](agent-json.md) 명령을 실행하는 것입니다. 이 명령은 JSON 객체의 서식 지정된 버전을 표시합니다. 다음은 일반적인 출력의 처음 몇 줄입니다.
```
{
"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": "10.112.235.192",
"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-10-112-235-192.us-west-2.compute.amazonaws.com"
...
```
다음과 같이 최근의 스택 구성 및 배포 JSON을 표시할 수 있습니다.
```
sudo opsworks-agent-cli get_json
```
다음을 실행하여 지정된 명령에 대해 최근의 스택 구성 및 배포 JSON을 표시할 수 있습니다.
```
sudo opsworks-agent-cli get_json command
```
명령 파라미터는 `setup`, `configure`, `deploy`, `undeploy`, `start`, `stop` 또는 `restart`로 설정할 수 있습니다. 이들 명령은 대부분 수명 주기 이벤트에 해당하며 에이전트에게 연결된 레시피를 실행하도록 지시합니다.
다음과 같이 명령의 날짜를 지정하여 특정 명령 실행에 대해 스택 구성 및 배포 JSON을 표시할 수 있습니다.
```
sudo opsworks-agent-cli get_json date
```
이 명령을 사용하는 가장 간단한 방법은 다음과 같습니다.
1. `list_commands`를 실행합니다. 그러면 인스턴스에서 실행된 명령과 각 명령이 실행된 날짜의 목록이 반환됩니다.
1. 해당 명령의 날짜를 복사하여 `get_json` *date* 인수로 사용합니다.
# 일반적인 디버깅 및 문제 해결
**중요**
이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 및 기존 고객 모두에서 비활성화되었습니다. 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션하는 것이 좋습니다. 마이그레이션에 대한 질문이 있는 경우 [AWS re:Post](https://repost.aws/) 또는 [AWS Premium Support](https://aws.amazon.com/support)를 통해 AWS Support 팀에 문의하세요.
이 섹션에서는 일반적으로 발생하는 일부 디버깅 및 문제 해결과 해법을 설명합니다.
**Topics**
+ [OpsWorks 스택 문제 해결](common-issues-troubleshoot.md)
+ [인스턴스 등록 문제 해결](#common-issues-instance-registration)
# OpsWorks 스택 문제 해결
**중요**
이 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**
+ [인스턴스를 관리할 수 없습니다](#w2ab1c14c77c17b9b9)
+ [Chef 실행 후 인스턴스가 부팅되지 않습니다](#w2ab1c14c77c17b9c11)
+ [계층의 인스턴스가 Elastic Load Balancing 상태 확인에 모두 실패](#common-issues-troubleshoot-health)
+ [Elastic Load Balancing 로드 밸런서와 통신할 수 없음](#w2ab1c14c77c17b9c15)
+ [가져온 온프레미스 인스턴스가 재시작 후 볼륨 설정을 완료하는 데 실패합니다](#w2ab1c14c77c17b9c17)
+ [재부팅 후 EBS 볼륨이 다시 연결되지 않습니다](#common-issues-troubleshoot-ebs)
+ [OpsWorks Stacks 보안 그룹을 삭제할 수 없습니다](#common-issues-troubleshoot-booting-secgroup)
+ [실수로 OpsWorks Stacks 보안 그룹을 삭제했습니다.](#common-issues-troubleshoot-booting-secgroup-delete)
+ [Chef 로그가 갑자기 종료됩니다](#common-issues-troubleshoot-log-terminates)
+ [쿡북이 업데이트되지 않습니다](#common-issues-troubleshoot-update)
+ [인스턴스가 부팅 상태에 멈춰 있습니다](#common-issues-troubleshoot-booting)
+ [인스턴스가 예기치 않게 다시 시작됩니다](#common-issues-troubleshoot-restart)
+ [`opsworks-agent` 프로세스가 인스턴스에서 실행 중입니다](#common-issues-troubleshoot-agent)
+ [예기치 않은 execute\$1recipes 명령](#common-issues-troubleshoot-unexpected)
## 인스턴스를 관리할 수 없습니다
**문제:** 전에는 관리할 수 있었던 인스턴스를 더 이상 관리할 수 없습니다. 일부 경우, 로그에 다음과 비슷한 오류가 표시될 수 있습니다.
```
Aws::CharlieInstanceService::Errors::UnrecognizedClientException - The security token included in the request is invalid.
```
**원인:** 이 문제는 인스턴스가 의존하는 OpsWorks 외부의 리소스가 편집 또는 삭제된 경우, 발생할 수 있습니다. 다음은 인스턴스와의 통신을 끊을 수 있는 리소스 변경의 예입니다.
+ 인스턴스와 연결된 IAM 사용자 또는 역할이 OpsWorks Stacks 외부에서 실수로 삭제되었습니다. 이로 인해 인스턴스에 설치된 OpsWorks 에이전트와 Stacks 서비스 간에 통신이 실패합니다 OpsWorks . 인스턴스에 연결된 사용자는 인스턴스의 수명이 끝날 때까지 필요합니다.
+ 인스턴스가 오프라인일 때 볼륨 또는 스토리지 구성을 편집하면 인스턴스를 관리할 수 없게 될 수 있습니다.
+ EC2 인스턴스를 ELB에 수동으로 추가. 인스턴스가 온라인 상태가 되거나 온라인 상태에서 나갈 때마다 할당된 Elastic Load Balancing 로드 밸런서를 OpsWorks 재구성합니다.는 알고 있는 인스턴스 OpsWorks 만 유효한 멤버로 간주합니다. 외부 OpsWorks또는 다른 프로세스에 의해 추가된 인스턴스는 제거됩니다. 인스턴스는 하나 걸러 하나씩 제거됩니다.
**해결 방법:** 인스턴스가 의존하는 IAM 사용자나 역할을 삭제하지 마세요. 가능하다면 종속 인스턴스가 실행 중일 때만 볼륨 또는 스토리지 구성을 편집하세요. OpsWorks 를 사용하여 OpsWorks 인스턴스의 로드 밸런서 또는 EIP 멤버십을 관리합니다. 인스턴스를 등록할 때 사용자가 우연히 삭제될 경우 발생하는 등록된 인스턴스 관리 문제를 예방하려면, `register` 명령에 `--use-instance-profile` 파라미터를 추가하여 인스턴스의 내장 인스턴스 프로파일을 대신 사용합니다.
## Chef 실행 후 인스턴스가 부팅되지 않습니다
**문제:** 사용자 지정 쿡북을 사용하도록 구성된 Chef 11.10 또는 이전의 스택에서 커뮤니티 쿡북을 사용한 Chef 실행 후 인스턴스가 부팅되지 않습니다. 로그 메시지에는 레시피가 컴파일에 실패했다거나("Recipe Compile Error") 종속성을 찾을 수 없어서 로드할 수 없다고 표시될 수 있습니다.
**원인:** 가장 가능성 높은 원인은 사용자 지정 또는 커뮤니티 쿡북이 스택이 사용하는 Chef 버전을 지원하지 않는 것입니다. `[apt](https://supermarket.chef.io/cookbooks/apt)` 및 `[build-essential](https://supermarket.chef.io/cookbooks/build-essential/versions/3.2.0)`과 같은 일부 인기 있는 커뮤니티 쿡북은 Chef 11.10과의 알려진 호환성 문제가 있습니다.
**솔루션:** 사용자 지정 Chef OpsWorks 쿡북 사용 설정이 켜져 있는 Stacks 스택에서 사용자 지정 또는 커뮤니티 쿡북은 스택에서 사용하는 Chef 버전을 항상 지원해야 합니다. **** 스택 설정에서 구성된 Chef 버전과 호환되는 버전으로 커뮤니티 쿡북을 고정시키십시오(즉, 쿡북 버전을 특정 버전으로 설정). 지원되는 커뮤니티 쿡북 버전을 찾으려면 컴파일에 실패하는 쿡북의 변경 로그를 보고 스택이 지원할 쿡북의 가장 최근 버전만을 사용합니다. 쿡북 버전을 고정하려면 사용자 지정 쿡북 리포지토리의 Berksfile에서 정확한 버전 번호를 지정하세요. 예를 들어 `cookbook 'build-essential', '= 3.2.0'`입니다.
## 계층의 인스턴스가 Elastic Load Balancing 상태 확인에 모두 실패
**문제:** Elastic Load Balancing 로드 밸런서를 앱 서버 계층에 연결하지만 모든 인스턴스가 상태 확인에 실패합니다.
**원인:** Elastic Load Balancing 로드 밸런서를 생성할 때 인스턴스 상태가 정상인지 확인하기 위해 로드 밸런서가 호출하는 ping 경로를 지정해야 합니다. 애플리케이션에 적합한 ping 경로를 지정해야 합니다. 기본값은 /index.html입니다. 애플리케이션에 `index.html`이 포함되지 않은 경우, 적절한 경로를 지정해야 상태 확인이 실패하지 않습니다. 예를 들어 [Chef 11 Linux 스택 시작하기](gettingstarted.md)에서 사용되는 SimplePHPApp 애플리케이션은 index.html을 사용하지 않습니다. 이러한 서버에 적절한 ping 경로는 /입니다.
**해결책:** 로드 밸런서의 ping 경로를 편집합니다. 자세한 내용은 [Elastic Load Balancing](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/gs-ec2classic.html)을 참조하세요.
## Elastic Load Balancing 로드 밸런서와 통신할 수 없음
**문제:** Elastic Load Balancing 로드 밸런서를 생성해 앱 서버 계층에 연결했지만 애플리케이션을 실행하기 위해 로드 밸런서의 DNS 이름이나 IP 주소를 클릭하면 "원격 서버가 응답하지 않습니다"라는 오류가 표시됩니다.
**원인:** 스택이 기본 VPC에서 실행되는 경우, 리전에서 Elastic Load Balancing 로드 밸런서를 생성할 때 보안 그룹을 지정해야 합니다. 보안 그룹에는 IP 주소로부터의 인바운드 트래픽을 허용하는 수신 규칙이 있어야 합니다. [**기본 VPC 보안 그룹**]을 지정한 경우, 기본 수신 규칙은 인바운드 트래픽을 전혀 허용하지 않습니다.
**해결책:** 적절한 IP 주소로부터의 인바운드 트래픽을 허용하도록 보안 그룹 수신 규칙을 편집합니다.
1. [Amazon EC2 콘솔의](https://console.aws.amazon.com/ec2/) 탐색 창에서 **보안 그룹**을 클릭합니다.
1. 로드 밸런서의 보안 그룹을 선택합니다.
1. [**인바운드**] 탭에서 [**편집**]을 클릭합니다.
1. [**소스**]를 적절한 CIDR로 설정하고 수신 규칙을 추가합니다.
예를 들어 [**모든 곳**]를 지정하면 CIDR이 0.0.0.0/0으로 설정되어 모든 IP 주소의 수신 트래픽을 허용하도록 로드 밸런서에게 명령합니다.
## 가져온 온프레미스 인스턴스가 재시작 후 볼륨 설정을 완료하는 데 실패합니다
**문제:** OpsWorks Stacks로 가져온 EC2 인스턴스를 다시 시작하면 인스턴스 상태로 OpsWorks Stacks 콘솔에 **실패**가 표시됩니다. 이 문제는 Chef 11 또는 Chef 12 인스턴스에서 발생할 수 있습니다.
**원인: **OpsWorks Stacks가 설정 프로세스 도중 인스턴스에 볼륨을 연결하지 못할 수 있습니다. 가능한 한 가지 원인은 `setup` 명령을 실행할 때 OpsWorks Stacks가 인스턴스에서 볼륨 구성을 덮어쓰는 것입니다.
**해결책:** 인스턴스의 [**세부 정보**] 페이지를 열고 [**볼륨**] 영역에서 볼륨 구성을 검사합니다. 볼륨 구성은 인스턴스가 [**중지됨**] 상태일 때만 변경할 수 있습니다. 모든 볼륨의 탑재 지점과 이름이 지정되어 있어야 합니다. 인스턴스를 다시 시작하기 전에 OpsWorks Stacks에서 구성에 올바른 탑재 지점을 제공했는지 확인합니다.
## 재부팅 후 EBS 볼륨이 다시 연결되지 않습니다
**문제:** 콘솔을 사용하여 Amazon EBS 볼륨을 인스턴스에 연결했지만 인스턴스를 재부팅할 때 볼륨이 더 이상 연결되지 않습니다.
**원인:** OpsWorks Stacks는 알고 있는 Amazon EBS 볼륨만 다시 연결할 수 있으며, 이는 다음으로 제한됩니다.
+ OpsWorks Stacks에서 생성한 볼륨입니다.
+ [**리소스**] 페이지를 사용하여 스택에 명시적으로 등록한 계정의 볼륨.
**솔루션:** OpsWorks Stacks 콘솔, API 또는 CLI를 사용해야만 Amazon EBS 볼륨을 관리할 수 있습니다. 스택에 계정의 Amazon EBS 볼륨 중 하나를 사용하려면 스택의 **리소스** 페이지를 사용하여 볼륨을 등록하고 인스턴스에 연결하세요. 자세한 내용은 [리소스 관리](resources.md) 단원을 참조하십시오.
## OpsWorks Stacks 보안 그룹을 삭제할 수 없습니다
**문제:** 스택을 삭제한 후에는 삭제할 수 없는 여러 OpsWorks Stacks 보안 그룹이 남아 있습니다.
**원인:** 보안 그룹은 특정 순서로 삭제해야 합니다.
**해결책:** 먼저 보안 그룹을 사용 중인 인스턴스가 없어야 합니다. 그 후 다음의 보안 그룹(존재하는 경우)을 다음 순서로 삭제하세요.
1. AWS-OpsWorks-Blank-Server
1. AWS-OpsWorks-Monitoring-Master-Server
1. AWS-OpsWorks-DB-Master-Server
1. AWS-OpsWorks-Memcached-Server
1. AWS-OpsWorks-Custom-Server
1. AWS-OpsWorks-nodejs-App-Server
1. AWS-OpsWorks-PHP-App-Server
1. AWS-OpsWorks-Rails-App-Server
1. AWS-OpsWorks-Web-Server
1. AWS-OpsWorks-Default-Server
1. AWS-OpsWorks-LB-Server
## 실수로 OpsWorks Stacks 보안 그룹을 삭제했습니다.
**문제:** OpsWorks Stacks 보안 그룹 중 하나를 삭제했으며 다시 생성해야 합니다.
**원인:** 이러한 보안 그룹은 보통 우연히 삭제됩니다.
**해결책:** 다시 생성되는 그룹은 그룹 이름의 동일한 대문자를 포함하여 원본의 정확한 복제본이어야 합니다. 수동으로 그룹을 다시 생성하는 것보다는 OpsWorks Stacks가 대신 이 작업을 수행하도록 하는 것이 좋습니다. 동일한 AWS 리전과 VPC에 새 스택을 생성하면 OpsWorks Stacks는 삭제한 보안 그룹을 포함하여 모든 기본 제공 보안 그룹을 자동으로 다시 생성합니다. 그런 다음 더 이상 사용할 일이 없으면 스택을 삭제할 수 있습니다. 보안 그룹은 그대로 남습니다.
## Chef 로그가 갑자기 종료됩니다
**문제:** Chef 로그가 갑자기 종료됩니다. 로그의 끝에 성공적 실행이 표시되지 않거나 예외 및 스택 추적이 표시되지 않습니다.
**원인:** 이 동작의 원인은 일반적으로 메모리 부족입니다.
**해결책:** 더 큰 인스턴스를 생성해 에이전트 CLI `run_command` 명령을 사용하여 레시피를 다시 실행합니다. 자세한 내용은 [레시피 실행](troubleshoot-debug-cli.md#troubleshoot-debug-cli-recipes) 단원을 참조하십시오.
## 쿡북이 업데이트되지 않습니다
**문제:** 쿡북을 업데이트했으나 스택의 인스턴스가 계속해서 이전 레시피를 실행 중입니다.
**원인:** OpsWorks 스택은 각 인스턴스에서 쿡북을 캐시하고 리포지토리가 아닌 캐시에서 레시피를 실행합니다. 새 인스턴스를 시작하면 OpsWorks Stacks는 리포지토리에서 인스턴스의 캐시로 쿡북을 다운로드합니다. 하지만 이후에 사용자 지정 쿡북을 수정하면 OpsWorks Stacks는 온라인 인스턴스의 캐시를 자동으로 업데이트하지 않습니다.
**해결 방법:** [쿡북 스택 업데이트 명령을](workingstacks-commands.md) 실행하여 Stacks에 온라인 인스턴스의 OpsWorks 쿡북 캐시를 업데이트하도록 명시적으로 지시합니다.
## 인스턴스가 부팅 상태에 멈춰 있습니다
**문제:** 인스턴스를 다시 시작하거나 자동 복구가 인스턴스를 자동으로 다시 시작할 때 시작 작업이 `booting` 상태에 멈춰 있습니다.
**원인:** 이 문제의 가능한 원인 한 가지는 기본 VPC를 포함한 VPC 구성입니다. 인스턴스는 항상 OpsWorks Stacks 서비스, Amazon S3 및 패키지, 쿡북 및 앱 리포지토리와 통신할 수 있어야 합니다. 예를 들어 기본 VPC에서 기본 게이트웨이를 제거하면 인스턴스가 OpsWorks Stacks 서비스에 대한 연결이 끊어집니다. OpsWorks Stacks는 더 이상 인스턴스 [에이전트](troubleshoot-debug-cli.md)와 통신할 수 없으므로 인스턴스를 실패로 취급하고 [자동으로 복구합니다](workinginstances-autohealing.md). 그러나 연결이 없으면 OpsWorks Stacks는 복구된 인스턴스에 인스턴스 에이전트를 설치할 수 없습니다. 에이전트가 없으면 OpsWorks Stacks는 인스턴스에서 Setup 레시피를 실행할 수 없으므로 시작 작업이 "부팅" 상태 이상으로 진행될 수 없습니다.
**해결책:** 인스턴스가 필요한 연결을 갖추도록 VPC 구성을 수정합니다.
## 인스턴스가 예기치 않게 다시 시작됩니다
**문제:** 정지한 인스턴스가 예기치 않게 다시 시작합니다.
**원인 1:** 인스턴스에 대해 [자동 복구](workinginstances-autohealing.md)를 활성화한 경우, OpsWorks Stacks는 연결된 Amazon EC2 인스턴스에서 주기적으로 상태 확인을 수행하고 비정상 상태인 인스턴스를 다시 시작합니다. Amazon EC2 콘솔, API 또는 CLI를 OpsWorks 사용하여 Stacks 관리형 인스턴스를 중지하거나 종료하면 OpsWorks Stacks에 알림이 전송되지 않습니다. 그 대신 정지된 인스턴스를 비정상으로 인식하고 자동으로 해당 인스턴스를 다시 시작합니다.
**해결 방법:** OpsWorks Stacks 콘솔, API 또는 CLI만을 사용하여 인스턴스를 관리합니다. OpsWorks Stacks를 사용하여 인스턴스를 중지하거나 삭제하면 인스턴스가 다시 시작되지 않습니다. 자세한 내용은 [수동으로 24/7 인스턴스 시작, 중지 및 재부팅](workinginstances-starting.md) 및 [OpsWorks 스택 인스턴스 삭제](workinginstances-delete.md) 섹션을 참조하세요.
**원인 2:** 인스턴스는 다양한 이유로 실패할 수 있습니다. 자동 복구를 활성화한 경우 OpsWorks Stacks는 실패한 인스턴스를 자동으로 다시 시작합니다.
**해결 방법:** 정상 작업입니다. Stacks가 실패한 인스턴스를 다시 시작하지 않도록 OpsWorks 하지 않는 한 아무 작업도 수행할 필요가 없습니다. 이 경우, 자동 복구를 비활성화해야 합니다.
## `opsworks-agent` 프로세스가 인스턴스에서 실행 중입니다
**문제:** 몇몇 `opsworks-agent` 프로세스가 인스턴스에서 실행 중입니다. 예제:
```
aws 24543 0.0 1.3 172360 53332 ? S Feb24 0:29 opsworks-agent: master 24543
aws 24545 0.1 2.0 208932 79224 ? S Feb24 22:02 opsworks-agent: keep_alive of master 24543
aws 24557 0.0 2.0 209012 79412 ? S Feb24 8:04 opsworks-agent: statistics of master 24543
aws 24559 0.0 2.2 216604 86992 ? S Feb24 4:14 opsworks-agent: process_command of master 24
```
**원인:** 이들은 에이전트의 정상 작동에 필요한 올바른 프로세스입니다. 이들은 배포를 처리하고 서비스에 연결 유지 메시지를 다시 전송하는 등의 작업을 수행합니다.
**해결책:** 이것은 정상적 동작입니다. 이 프로세스들을 중지하지 마십시오. 중지할 경우, 에이전트 작동이 손상될 수 있습니다.
## 예기치 않은 execute\$1recipes 명령
**문제:** 인스턴스 세부 정보 페이지의 [**로그**] 섹션에 예기치 않은 `execute_recipes` 명령이 포함되어 있습니다. 예기치 않은 `execute_recipes` 명령은 [**스택**] 및 [**배포**] 페이지에도 표시될 수 있습니다.
**원인:** 이 문제는 흔히 권한 변경으로 인해 발생합니다. 사용자 또는 그룹의 SSH 또는 sudo 권한을 변경하면 OpsWorks Stacks가를 실행`execute_recipes`하여 스택의 인스턴스를 업데이트하고 Configure 이벤트도 트리거합니다. `execute_recipes` 명령의 또 다른 출처는 인스턴스 에이전트를 업데이트하는 OpsWorks Stacks입니다.
**해결책:** 이것은 정상 작동이며 아무 조치도 취할 필요가 없습니다.
`execute_recipes` 명령이 어떤 작업을 수행했는지 보려면 [**배포**] 페이지로 가서 명령의 타임스탬프를 클릭하세요. 그러면 실행된 주요 레시피가 나열된 명령의 세부 정보 페이지가 열립니다. 예를 들어 다음 세부 정보 페이지는 `ssh_users`를 실행하여 SSH 권한을 업데이트한 `execute_recipes` 명령의 세부 정보 페이지입니다.
![\[Command details page showing successful execution of Recipes and ssh_users on php-app1.\]](http://docs.aws.amazon.com/ko_kr/opsworks/latest/userguide/images/command_details.png)
모든 세부 정보를 보려면 명령의 **로그** 열에서 **표시**를 클릭하여 관련 Chef 로그를 표시하세요. 로그에서를 검색합니다**Run List**. OpsWorks 스택 유지 관리 레시피는 아래에 있습니다`OpsWorks Custom Run List`. 예를 들어 다음은 이전 스크린샷에 나온 `execute_recipes` 명령의 실행 목록으로서 명령에 연결된 모든 레시피를 보여 줍니다.
```
[2014-02-21T17:16:30+00:00] INFO: OpsWorks Custom Run List: ["opsworks_stack_state_sync",
"ssh_users", "test_suite", "opsworks_cleanup"]
```
## 인스턴스 등록 문제 해결
이 섹션에는 일반적으로 발생하는 일부 인스턴스 등록 문제와 해결 방법이 나와 있습니다.
**참고**
등록 문제가 있는 경우, 추가 디버깅 정보를 제공하는 `--debug` 인수와 함께 `register`를 실행합니다.
**Topics**
+ [EC2User에게 다음을 수행할 권한이 부여되지 않았습니다](#common-issues-instance-registration-ec2user)
+ [자격 증명 범위가 유효한 리전으로 지정되어야 합니다](#common-issues-instance-registration-valid-region)
### EC2User에게 다음을 수행할 권한이 부여되지 않았습니다
**문제:** `register` 명령이 다음과 비슷한 결과를 반환합니다.
```
A client error (AccessDenied) occurred when calling the CreateGroup operation:
User: arn:aws:iam::123456789012:user/ImportEC2User is not authorized to
perform: iam:CreateGroup on resource:
arn:aws:iam::123456789012:group/AWS/OpsWorks/OpsWorks-b583ce55-1d01-4695-b3e5-ee19257d1911
```
**원인:** 필요한 권한을 부여하지 않는 자격 증명을 사용하여 `register` 명령이 실행 중입니다. 사용자의 정책이 무엇보다 `iam:CreateGroup` 작업을 허용해야 합니다.
**해결책** 필요한 권한이 있는 IAM 자격 증명을 `register`에 제공합니다. 자세한 내용은 [AWS CLI설치 및 구성](registered-instances-register-registering-cli.md) 단원을 참조하십시오.
### 자격 증명 범위가 유효한 리전으로 지정되어야 합니다
**문제:** `register` 명령이 다음을 반환합니다.
```
A client error (InvalidSignatureException) occurred when calling the
DescribeStacks operation: Credential should be scoped to a valid region, not 'cn-north-1'.
```
**원인:** 명령의 리전은 유효한 OpsWorks Stacks 리전이어야 합니다. 지원되는 리전 목록은 [리전 지원](gettingstarted_intro.md#gettingstarted-intro-region) 섹션을 참조하세요. 이 오류는 일반적으로 다음 이유 중 하나로 인해 발생할 수 있습니다.
+ 스택이 다른 리전에 있고 스택의 리전을 명령의 `--region` 인수에 할당했습니다.
스택 리전을 지정할 필요가 없습니다. OpsWorks 스택은 스택 ID에서 자동으로 결정합니다.
+ `--region` 인수를 생략하여 묵시적으로 기본 리전을 지정했지만 OpsWorks Stacks가 지원하지 않는 기본 리전입니다.
**해결 방법:** 지원되는 OpsWorks Stacks 리전`--region`으로 명시적으로 설정``하거나 `config` 파일을 편집 AWS CLI 하여 기본 리전을 지원되는 OpsWorks Stacks 리전으로 변경합니다. 자세한 내용은 [AWS 명령줄 인터페이스 구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html) 단원을 참조하세요.