翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 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"]
```