翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# デバッグとトラブルシューティングのガイド
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
レシピをデバッグしたり、サービスの問題をトラブルシューティングしたりする必要がある場合、通常、以下の手順を順番に実行するのが最も適切な方法です。
1. 現在の問題が「[一般的なデバッグとトラブルシューティングの問題](common-issues.md)」に掲載されていないかを確認します。
1. [OpsWorks スタックフォーラム](https://forums.aws.amazon.com/forum.jspa?forumID=153#)を検索して、その問題が議論されていないか確認します。
フォーラムには経験豊富なユーザーが多数含まれており、 OpsWorks スタックチームによってモニタリングされています。
1. レシピの問題については、「[レシピのデバッグ](troubleshoot-debug.md)」を参照してください。
1. OpsWorks スタックサポートに問い合わせるか、 [OpsWorks スタックフォーラム](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 プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
ライフサイクルイベントが発生したときや、[[Execute Recipes]](workingstacks-commands.md) (レシピの実行) スタックコマンドを実行したときに、 OpsWorks スタックは [[agent]](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 CLI の使用](troubleshoot-debug-cli.md)
# 障害が発生したインスタンスへのログイン
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
レシピが失敗すると、インスタンスはオンラインではなく `setup_failed` 状態になります。インスタンスは OpsWorks スタックに関してオンラインではありませんが、EC2 インスタンスは実行されており、問題のトラブルシューティングのためにログインすると便利です。たとえば、アプリケーションまたはカスタムクックブックが正しくインストールされているかどうかを確認できます。 OpsWorks スタックの [SSH](workinginstances-ssh.md) および [RDP](workinginstances-rdp.md) ログインの組み込みサポートは、オンライン状態のインスタンスでのみ使用できます。ただし、インスタンスに 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 プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
Chef ログは、特にレシピをデバッグするための主要なトラブルシューティングリソースの 1 つです。 OpsWorks スタックは各コマンドの Chef ログをキャプチャし、インスタンスの最新の 30 個のコマンドのログを保持します。実行はデバッグモードであるため、ログには Chef 実行の詳細 (`stdout` や `stderror` に送信されたテキストなど) が含まれます。レシピが失敗した場合、ログには Chef スタックトレースが含まれます。
OpsWorks スタックには、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 ログを表示する最も簡単な方法は、インスタンスの詳細ページを参照することです。[**Logs**] セクションには、各イベントと [Execute Recipes](workingstacks-commands.md) コマンドのエントリが含まれています。Configure および Setup の各ライフサイクルイベントに対応する **configure** コマンドと **setup** コマンドが含まれた、インスタンスの [**Logs**] セクションを次に示します。
![\[Logs section showing configure and setup commands with timestamps and durations.\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/gs11.png)
該当するコマンドの [**Log**] 列で [**show**] をクリックすると、対応する Chef ログが表示されます。エラーが発生した場合、 OpsWorks スタックはエラーのログを自動的に開きます。これは通常、ファイルの最後にあります。
## CLI または API を使用した Chef ログの表示
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 OpsWorks S3 バケットに保存されているログを表示できます。 Amazon S3 次に、CLI を使用して、指定したインスタンスの現在のログファイルセットを表示する方法を示します。`DescribeCommands` を使用する場合の手順は基本的にほぼ同じです。
**OpsWorks スタックを使用してインスタンスの Chef ログを表示するには**
1. インスタンスの詳細ページを開き、**OpsWorks ID** 値をコピーします。
1. 次のように、ID 値を使用して `describe-commands` CLI コマンドを実行します。
```
aws opsworks describe-commands --instance-id 67bf0da2-29ed-4217-990c-d895d51812b9
```
コマンドは、 OpsWorks スタックがインスタンスで実行した各コマンドの埋め込みオブジェクトを含む 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 スタックは、各インスタンスの Chef ログを `/var/chef/runs` ディレクトリに保存します。(Linux インスタンスの場合、このディレクトリには、JSON 形式のファイルとして保存される、関連[データバッグ](data-bags.md)も含まれます)。このディレクトリにアクセスするには、[sudo 権限](opsworks-security-users.md)が必要です。各実行のログは、個別の実行のサブディレクトリ内にある `chef.log` という名前のファイルにあります。
OpsWorks スタックは内部ログをインスタンスの `/var/log/aws/opsworks`フォルダに保存します。通常、この情報はトラブルシューティングにはあまり役立ちません。ただし、これらのログは OpsWorks スタックのサポートに役立ちます。サービスで問題が発生した場合は、ログの提供を求められることがあります。Linux のログも、トラブルシューティングに役立つデータを提供する場合があります。
### Windows インスタンス
**エージェントログ**
Windows インスタンスでは、OpsWorks のログは次のような `ProgramData` のパスに保存されます。数値にはタイムスタンプが含まれます。
```
C:\ProgramData\OpsWorksAgent\var\logs\number
```
**注記**
デフォルトでは、`ProgramData` は非表示フォルダです。非表示を解除するには、[**Folder Options**] に移動します。[**View**] で、非表示のファイルを表示するオプションを選択します。
次の例では、エージェントは 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 の専門家に非常に役立ちます。ほとんどのコマンドは多数のレシピに関連していますが、実行リストに含まれるレシピは 2 つに限られます。この 2 つのレシピでは、他のすべての組み込みレシピとカスタムレシピをロードして実行するタスクを処理します。
通常、ファイルで最も関心を引く部分は末尾にあります。実行が正常に終了すると、次のような内容が表示されます。
```
...
[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)」を参照してください。
レシピが失敗した場合は、次のように、例外の後に Chef スタックトレースが続く ERROR レベルの出力を探す必要があります。
```
...
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 の実行が開始されると、インスタンスは署名付き Amazon S3 URL を受け取ります。この URL により、Chef の実行が終了したときにウェブページでログを表示することができます。この 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 スタックは、インスタンスのクックブックキャッシュからレシピを実行します。インスタンスの起動時に、リポジトリからこのキャッシュにクックブックがダウンロードされます。ただし、後でリポジトリ内のクックブックを変更しても、 OpsWorks スタックはオンラインインスタンスのキャッシュを自動的に更新しません。インスタンスの起動以降にクックブックの変更や新しいクックブックの追加を行った場合は、次の手順を実行します。
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 CLI の使用
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
**注記**
エージェントの CLI は Linux インスタンスにのみ使用できます。
すべてのオンラインインスタンスで、 OpsWorks スタックは サービスと通信する エージェントをインストールします。次に OpsWorks 、 スタックサービスはエージェントにコマンドを送信して、ライフサイクルイベントが発生したときにインスタンスで 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 スタックエージェント 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` コマンドで実行されるのは、指定されたコマンドに関連付けられたレシピ (通常はライフサイクルイベントに関連付けられたレシピ) のグループに限られています。このコマンドを使用して特定のレシピを実行することはできません。指定した 1 つ以上のレシピを実行するには、[Execute Recipes スタックコマンド](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` コマンドは、カスタムレシピ (特に、コンソールから直接トリガーできない、Setup および Configure の各ライフサイクルイベントに割り当てられたレシピ) をデバッグする際に役立ちます。`run_command` を使用すると、インスタンスを起動または停止しなくても、必要な頻度で特定のイベントのレシピを実行できます。
**注記**
OpsWorks スタックは、クックブックリポジトリではなく、インスタンスのクックブックキャッシュからレシピを実行します。 OpsWorks スタックは、インスタンスの起動時にクックブックをこのキャッシュにダウンロードしますが、その後クックブックを変更してもオンラインインスタンスのキャッシュは自動的に更新されません。インスタンスの起動以降にクックブックを変更した場合は、[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
```
たとえば、Setup レシピを再実行するには、次のコマンドを実行します。
```
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
```
command パラメータは、`setup`、`configure`、`deploy`、`undeploy`、`start`、`stop`、または `restart` に設定できます。これらのコマンドのほとんどはライフサイクルイベントに対応しており、関連付けられているレシピを実行するようエージェントに指示します。
実行された特定のコマンドのログを表示するには、`list_commands` の出力から日付をコピーし、次のコマンドを実行します。
```
sudo opsworks-agent-cli show_log date
```
コマンドがまだ実行中の場合、`show_log` はログの現在の状態を表示します。
**注記**
`show_log` を使用してエラーやメモリ不足の問題のトラブルシューティングを行う 1 つの方法として、次のように実行中にログの末尾を表示します。
`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 を表示する最も簡単な方法は、JSON オブジェクトの書式設定されたバージョンを表示する、エージェント CLI の [`get_json`](agent-json.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": "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
```
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 プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
このセクションでは、一般的なデバッグやトラブルシューティングに関する問題とその解決方法について説明します。
**Topics**
+ [OpsWorks スタックのトラブルシューティング](common-issues-troubleshoot.md)
+ [インスタンス登録の問題のトラブルシューティング](#common-issues-instance-registration)
# OpsWorks スタックのトラブルシューティング
**重要**
この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行についてご質問がある場合は、[AWS re:Post](https://repost.aws/) または[AWS プレミアムサポート](https://aws.amazon.com/support)を通じて AWS サポート チームにお問い合わせください。
このセクションでは、よく発生する OpsWorks スタックの問題とその解決策について説明します。
**Topics**
+ [インスタンスを管理できない](#w2ab1c14c77c17b9b9)
+ [Chef の実行後にインスタンスが起動しない](#w2ab1c14c77c17b9c11)
+ [Elastic Load Balancing ヘルスチェックでレイヤーのインスタンスがすべて失敗する](#common-issues-troubleshoot-health)
+ [Elastic Load Balancing のロードバランサーと通信できない](#w2ab1c14c77c17b9c15)
+ [インポートしたオンプレミスインスタンスで再起動後にボリュームの設定を完了できない](#w2ab1c14c77c17b9c17)
+ [再起動後、EBS ボリュームが再アタッチされない](#common-issues-troubleshoot-ebs)
+ [OpsWorks スタックセキュリティグループを削除できない](#common-issues-troubleshoot-booting-secgroup)
+ [OpsWorks スタックセキュリティグループが誤って削除されました](#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 スタックの外部で誤って削除されました。これにより、インスタンスにインストールされている OpsWorks エージェントと スタックサービス間の通信が失敗します OpsWorks 。インスタンスの存続中は、インスタンスに関連付けられた ユーザーが必要です。
+ インスタンスがオフラインの間にボリュームまたはストレージの設定を編集すると、インスタンスを管理できなくなる場合があります。
+ EC2 インスタンスを ELB に手動で追加します。 は、インスタンスがオンライン状態に出入りするたびに、割り当てられた Elastic Load Balancing ロードバランサー OpsWorks を再設定します。 は、既知のインスタンス OpsWorks のみを有効なメンバーと見なします。 の外部 OpsWorksまたは他のプロセスによって追加されたインスタンスは削除されます。その他のインスタンスはすべて削除されます。
**解決策:** インスタンスが依存している IAM ユーザーまたはロールを削除しないようにします。可能であれば、依存しているインスタンスが実行中の間のみ、ボリュームまたはストレージの設定を編集します。 OpsWorks を使用して、 OpsWorks インスタンスのロードバランサーまたは EIP メンバーシップを管理します。`--use-instance-profile` ユーザーが誤って削除された場合に登録済みインスタンスの管理に関する問題が発生するのを回避するために、 `register`コマンドに パラメータを追加して、代わりにインスタンスの組み込みインスタンスプロファイルを使用します。
## 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 スタックでは、カスタムクックブックまたはコミュニティクックブックは常にスタックが使用する Chef のバージョンをサポートしている必要があります。コミュニティクックブックを、スタック設定で設定されている Chef のバージョンと互換性があるバージョンにピンしてください (クックブックのバージョンを特定のバージョンに設定します)。サポートされているクックブックバージョンを探すには、コンパイルに失敗したクックブックの変更ログを表示し、スタックでサポートされているクックブックの最新バージョンのみを使用します。クックブックのバージョンをピンするには、カスタムクックブックリポジトリの Berkfile にバージョン番号を正確に指定します。例えば、`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/) ナビゲーションペインの **[Security Groups]** (セキュリティグループ) をクリックします。
1. ロードバランサーのセキュリティグループを選択します。
1. **[Inbound]** (インバウンド) タブで **[Edit]** (編集) をクリックします。
1. [**Source**] を適切な CIDR に設定して進入ルールを追加します。
たとえば、[**Anywhere**] を指定すると、CIDR が 0.0.0.0/0 に設定され、任意の IP アドレスからの着信トラフィックを許可するようにロードバランサーに指示できます。
## インポートしたオンプレミスインスタンスで再起動後にボリュームの設定を完了できない
**問題:** スタックにインポートした EC2 OpsWorks インスタンスを再起動すると、インスタンスのステータスとして OpsWorks スタックコンソールが表示され**なくなります**。これは、Chef 11 または Chef 12 のインスタンスで発生する場合があります。
**原因:**OpsWorks スタックでの設定プロセス中に、インスタンスにボリュームをアタッチできなかった可能性があります。1 つの原因として、 OpsWorks コマンドの実行時に、`setup` スタックによってインスタンスのボリューム設定が上書きされていることが考えられます。
**解決策:** インスタンスの [**Details**] ページを開き、[**Volumes**] エリアでボリューム設定を確認します。ボリューム設定を変更できるのは、インスタンスのステータスが [**stopped**] の場合のみであることに注意してください。すべてのボリュームにマウントポイントと名前が指定されていることを確認します。インスタンスを再起動する前に OpsWorks 、 スタックの設定で正しいマウントポイントが指定されていることを確認します。
## 再起動後、EBS ボリュームが再アタッチされない
**問題:** Amazon EC2 コンソールを使用して Amazon EBS ボリュームをインスタンスにアタッチしても、インスタンスを再起動すると、ボリュームはアタッチされません。
**原因:** OpsWorks スタックは、認識している Amazon EBS ボリュームのみを再アタッチできます。ただし、以下の制限があります。
+ OpsWorks スタックによって作成されたボリューム。
+ [**Resources**] ページを使用して、明示的にスタックに登録したアカウントのボリューム。
**解決策:** スタックコンソール、API、または CLI OpsWorks を使用してのみ Amazon EBS ボリュームを管理します。自分のアカウントの Amazon EBS ボリュームの 1 つをスタックで使用する場合は、スタックの **[Resources]** (リソースリソース) ページを使用してボリュームを登録し、インスタンスにアタッチします。詳細については、「[リソース管理](resources.md)」を参照してください。
## OpsWorks スタックセキュリティグループを削除できない
**問題:** スタックを削除すると、削除できない多くの OpsWorks スタックセキュリティグループが残ります。
**原因:** セキュリティグループは、特定の順序で削除する必要があります。
**解決策:** まず、どのインスタンスもセキュリティグループを使用していないことを確認します。その後、以下のセキュリティグループが存在する場合は、次の順序で任意のセキュリティグループを削除します。
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 スタックセキュリティグループが誤って削除されました
**問題:** スタックセキュリティグループの 1 OpsWorks つを削除し、再作成する必要があります。
**原因:** これらのセキュリティグループは誤って削除されることがよくあります。
**解決策:** 再作成されたグループは、グループ名の大文字と小文字を含め、元のグループとまったく同じである必要があります。グループを手動で再作成する代わりに、 OpsWorks スタックでこのタスクを実行する方法をお勧めします。同じ AWS リージョンに新しいスタックを作成するだけで、 OpsWorks VPC が存在する場合は、削除したセキュリティグループを含むすべての組み込みセキュリティグループが自動的に再作成されます。その後、今後使用しないスタックを削除します。セキュリティグループは残ります。
## Chef のログが突然終了する
**問題:** Chef のログが突然終了します。ログの最後には、正常な実行は示されず、例外やスタックトレースも表示されません。
**原因:** この動作は、通常、メモリが不十分であることによって発生します。
**解決策:** より大きいインスタンスを作成し、エージェント CLI の `run_command` コマンドを使用してレシピを再度実行します。詳細については、「[レシピの実行](troubleshoot-debug-cli.md#troubleshoot-debug-cli-recipes)」を参照してください。
## クックブックが更新されない
**問題:** クックブックを更新しましたが、スタックのインスタンスはまだ古いレシピを実行しています。
**原因:** OpsWorks スタックは各インスタンスでクックブックをキャッシュし、リポジトリではなくキャッシュからレシピを実行します。新しいインスタンスを起動すると、 OpsWorks スタックは リポジトリからインスタンスのキャッシュにクックブックをダウンロードします。ただし、その後でカスタムクックブックを変更した場合、 OpsWorks スタックはオンラインインスタンスのキャッシュを自動的には更新しません。
**解決策:** [クックブックの更新スタックコマンド](workingstacks-commands.md)を実行して、オンラインインスタンスのクックブックキャッシュを更新するように OpsWorks スタックに明示的に指示します。
## インスタンスが起動中のステータスでスタックする
**問題:** インスタンスを再起動したとき、または自動ヒーリングが自動的にインスタンスを再起動したときに、起動オペレーションが `booting` ステータスで停止します。
**原因:** この問題の 1 つの原因として考えられるのは、デフォルト VPC を含む VPC 設定です。インスタンスは、 OpsWorks スタックサービス、Amazon S3、パッケージ、クックブック、アプリケーションリポジトリと常に通信できる必要があります。たとえば、デフォルト VPC からデフォルトゲートウェイを削除すると、インスタンスは OpsWorks スタックサービスへの接続を失います。 OpsWorks スタックはインスタンス[エージェント](troubleshoot-debug-cli.md)と通信できなくなるため、インスタンスは失敗として扱われ、[自動修復されます](workinginstances-autohealing.md)。ただし、接続がない場合、 OpsWorks スタックは修復されたインスタンスにインスタンスエージェントをインストールできません。エージェントがない場合、 OpsWorks スタックはインスタンスで Setup レシピを実行できないため、スタートアップオペレーションが「ブート中」ステータスを超えることはできません。
**解決策:** インスタンスが必要な接続を利用できるように、VPC の設定を変更します。
## インスタンスが予期せずに再起動する
**問題:** 停止されたインスタンスが予期せずに再起動します。
**原因 1:** インスタンスの [[auto healing]](workinginstances-autohealing.md) (オートヒーリング) を有効にしている場合、 OpsWorks スタックは関連付けられた Amazon EC2 インスタンスで定期的にヘルスチェックを実行し、異常なインスタンスを再起動します。Amazon EC2 コンソール、 OpsWorks API、または CLI を使用して スタックマネージドインスタンスを停止または終了した場合、 OpsWorks スタックには通知されません。代わりに、停止されたインスタンスを異常と見なし、自動的に再起動します。
**解決策:** OpsWorks スタックコンソール、API、または CLI を使用することによってのみインスタンスを管理します。 OpsWorks スタックを使用してインスタンスを停止または削除する場合、インスタンスは再起動されません。詳細については、「[24/7 インスタンスの手動による起動、停止、再起動](workinginstances-starting.md)」および「[OpsWorks スタックインスタンスの削除](workinginstances-delete.md)」を参照してください。
**原因 2:** インスタンスは、さまざまな理由で失敗する可能性があります。自動ヒーリングが有効になっている場合、 OpsWorks スタックは自動的に失敗したインスタンスを再起動します。
**解決策:** これは通常のオペレーションです。失敗したインスタンスを 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 コマンド
**問題:** インスタンスの詳細ページの **[Logs]** (ログ) セクションに、予期しない `execute_recipes` コマンドが表示されます。予期しない `execute_recipes` コマンドは、**[Stack]** (スタック) ページや **[Deployments]** (デプロイ) ページにも表示される場合があります。
**原因:** この問題は通常、アクセス許可の変更によって発生します。ユーザーまたはグループの SSH または sudo アクセス許可を変更すると、 OpsWorks スタックは `execute_recipes`を実行してスタックのインスタンスを更新し、Configure イベントもトリガーします。`execute_recipes` コマンドのもう 1 つのソースは、インスタンスエージェントを更新している OpsWorks スタックです。
**解決策:** これは通常のオペレーションです。何もする必要はありません。
`execute_recipes` コマンドが実行したアクションを確認するには、**[Deployments]** (デプロイ) ページに移動し、コマンドのタイムスタンプをクリックします。これによりコマンドの詳細ページが開き、実行されたキーレシピがリスト表示されます。例えば、次の詳細ページは、`execute_recipes` を実行して SSH アクセス許可を更新する `ssh_users` コマンドのためのページです。
![\[Command details page showing successful execution of Recipes and ssh_users on php-app1.\]](http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/images/command_details.png)
すべての詳細を表示するには、コマンドの **[Log]** (ログ) 列で **[show]** (表示) をクリックすると、関連付けられた 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"]
```
## インスタンス登録の問題のトラブルシューティング
このセクションでは、インスタンスの登録の一般的な問題とその解決方法を示します。
**注記**
登録の問題が発生した場合、`register` 引数を使用して `--debug` を実行します。これにより、デバッグの詳細情報を取得できます。
**Topics**
+ [EC2User Is Not Authorized to Perform: ... (EC2User に以下を実行する権限がありません: ...)](#common-issues-instance-registration-ec2user)
+ [Credential Should Be Scoped to a Valid Region (認証情報の範囲を有効なリージョンに限定する必要があります)](#common-issues-instance-registration-valid-region)
### EC2User Is Not Authorized to Perform: ... (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` アクションが許可されている必要があります。
**ソリューション:** `register` を必要なアクセス権限が付与された IAM ユーザー認証情報で指定します。詳細については、「[AWS CLIのインストールおよび設定](registered-instances-register-registering-cli.md)」を参照してください。
### Credential Should Be Scoped to a Valid Region (認証情報の範囲を有効なリージョンに限定する必要があります)
**問題:** `register` コマンドにより、以下のような出力が返されます。
```
A client error (InvalidSignatureException) occurred when calling the
DescribeStacks operation: Credential should be scoped to a valid region, not 'cn-north-1'.
```
**原因:** コマンドのリージョンは、有効な OpsWorks スタックリージョンである必要があります。サポートされているリージョンのリストについては、「[リージョンのサポート](gettingstarted_intro.md#gettingstarted-intro-region)」を参照してください。通常、このエラーは、次のいずれかの原因により発生します。
+ スタックが別のリージョンにあり、スタックのリージョンをコマンドの `--region` 引数に割り当てた場合。
スタックリージョンを指定する必要はありません。 OpsWorks スタックはスタック ID から自動的に決定します。
+ `--region` 引数を省略したことにより、暗黙的にデフォルトのリージョンが指定されたものの、デフォルトのリージョンが OpsWorks スタックでサポートされていません。
**解決策:** サポートされている OpsWorks スタックリージョン`--region`に明示的に設定するか``、 `config` ファイルを編集してデフォルトのリージョンをサポートされている OpsWorks スタックリージョンに変更します AWS CLI 。詳細については、「[AWS コマンドラインインターフェイスの設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)」を参照してください。