AWS OpsWorks スタックのトラブルシューティング

重要

AWS OpsWorks Stacks は新規顧客を受け付けなくなりました。既存のお客様は、2024 年 5 月 26 日までは OpsWorks コンソール、 API、 CLI、および CloudFormation リソースを通常どおり使用できますが、その時点でこれらのリソースは廃止されます。この移行に備えて、できるだけ早くスタックを AWS Systems Manager に移行することをおすすめします。詳細については、AWS OpsWorks Stacks サポート終了に関する FAQ および AWS Systems Manager アプリケーションマネージャへの AWS OpsWorks Stacks アプリケーションの移行 を参照してください。

このセクションでは、一般的な AWS OpsWorks スタックの問題とその解決方法を示します。

インスタンスを管理できない

問題: 以前に管理可能であったインスタンスを管理できなくなった。場合によっては、次のようなエラーがログに表示される。

Aws::CharlieInstanceService::Errors::UnrecognizedClientException - The security token included in the request is invalid.

原因: インスタンスが依存している AWS OpsWorks 外部のリソースが編集または削除された場合に、この問題が発生する可能性があります。インスタンスとの通信を遮断する可能性があるリソースの変更例を次に示します。

• インスタンスに関連付けられた ユーザーまたはロールが、AWS OpsWorks スタックの外部で誤って削除された。これにより、インスタンスにインストールされた AWS OpsWorks エージェントと、AWS OpsWorks スタックサービスの間で通信エラーが発生します。インスタンスの存続中は、インスタンスに関連付けられた ユーザーが必要です。

• インスタンスがオフラインの間にボリュームまたはストレージの設定を編集すると、インスタンスを管理できなくなる場合があります。

• EC2 インスタンスを手動で ELB に追加した。AWS OpsWorks はインスタンスがオンライン状態になるか、オンライン状態でなくなるたびに、割り当てられた Elastic Load Balancing ロードバランサーを再設定します。AWS OpsWorks は既知のインスタンスのみを有効なメンバーであると見なします。AWS OpsWorks の外部で追加されたインスタンスや、他のプロセスによって追加されたインスタンスは削除されます。その他のインスタンスはすべて削除されます。

解決策: インスタンスが依存している IAM ユーザーまたはロールを削除しないようにします。可能であれば、依存しているインスタンスが実行中の間のみ、ボリュームまたはストレージの設定を編集します。AWS OpsWorks を使用して、AWS OpsWorks インスタンスのロードバランサーまたは EIP メンバーシップを管理します。--use-instance-profile ユーザーが誤って削除された場合に登録済みインスタンスの管理に関する問題が発生するのを回避するために、 registerコマンドに パラメータを追加して、代わりにインスタンスの組み込みインスタンスプロファイルを使用します。

Chef の実行後にインスタンスが起動しない

問題: カスタムクックブックを使用するように設定されている Chef 11.10 以前のスタックで、コミュニティクックボックを使用した Chef の実行後、インスタンスが起動しません。ログメッセージが、レシピがコンパイルに失敗したことを示すか (「Recipe Compile Error」)、依存関係を見つけられないことを理由にロードされない可能性があります。

原因: もっとも可能性の高い原因は、カスタムクックブックまたはコミュニティクックブックが、スタックの使用する Chef バージョンをサポートしていないことです。apt や build-essential などの一般的なコミュニティクックブックには、Chef 11.10 との互換性に問題があることが知られているものがあります。

解決策: AWS OpsWorks Stacks の スタックが [Use custom Chef cookbooks] (カスタム Chef クックブックの使用) 設定を有効にしている場合、カスタムクックブックまたはコミュニティクックブックは、スタックで使用する 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 スタックの使用開始」で使用されている SimplePHPApp は index.html を使用しません。これらのサーバーに適した ping パスは / です。

解決策: ロードバランサーの ping パスを編集します。詳細については、「Elastic Load Balancing」を参照してください。

Elastic Load Balancing のロードバランサーと通信できない

問題: Elastic Load Balancing ロードバランサーを作成し、アプリケーションサーバーレイヤーにアタッチしても、ロードバランサーの DNS 名または IP アドレスをクリックしてアプリケーションを実行すると、「リモートサーバーが応答していません」というエラーが表示されます。

原因: スタックがデフォルトの VPC で実行されている場合、そのリージョンに Elastic Load Balancing ロードバランサーを作成するときに、セキュリティグループを指定する必要があります。セキュリティグループには、IP アドレスからのインバウンドトラフィックを許可する進入ルールが必要です。デフォルトの VPC セキュリティグループを指定する場合、デフォルトの進入ルールはインバウンドトラフィックを許可しません。

解決策: 適切な IP アドレスからのインバウンドトラフィックを許可するようにセキュリティグループの進入ルールを編集します。

1. Amazon EC2 コンソール ナビゲーションペインの [Security Groups] (セキュリティグループ) をクリックします。

2. ロードバランサーのセキュリティグループを選択します。

3. [Inbound] (インバウンド) タブで [Edit] (編集) をクリックします。

4. [Source] を適切な CIDR に設定して進入ルールを追加します。

   たとえば、[Anywhere] を指定すると、CIDR が 0.0.0.0/0 に設定され、任意の IP アドレスからの着信トラフィックを許可するようにロードバランサーに指示できます。

インポートしたオンプレミスインスタンスで再起動後にボリュームの設定を完了できない

問題: AWS OpsWorks スタック内にインポートした EC2 インスタンスを再起動すると、AWS OpsWorks スタックのコンソールにはインスタンスのステータスとして「failed」と表示されます。これは、Chef 11 または Chef 12 のインスタンスで発生する場合があります。

原因:AWS OpsWorks スタックでの設定プロセス中に、インスタンスにボリュームをアタッチできなかった可能性があります。1 つの原因として、AWS OpsWorks コマンドの実行時に、setup スタックによってインスタンスのボリューム設定が上書きされていることが考えられます。

解決策: インスタンスの [Details] ページを開き、[Volumes] エリアでボリューム設定を確認します。ボリューム設定を変更できるのは、インスタンスのステータスが [stopped] の場合のみであることに注意してください。すべてのボリュームにマウントポイントと名前が指定されていることを確認します。インスタンスを再起動する前に、AWS OpsWorksスタックで正しいマウントポイントを設定したことを確認します。

再起動後、EBS ボリュームが再アタッチされない

問題: Amazon EC2 コンソールを使用して Amazon EBS ボリュームをインスタンスにアタッチしても、インスタンスを再起動すると、ボリュームはアタッチされません。

原因: AWS OpsWorks スタックでは認識されている Amazon EBS ボリュームのみを再アタッチできますが、このボリュームは以下のように制限されます。

• AWS OpsWorks スタックによって作成されたボリューム。

• [Resources] ページを使用して、明示的にスタックに登録したアカウントのボリューム。

解決策: AWS OpsWorks スタックコンソール、API、または CLI のみを使用して Amazon EBS ボリュームを管理します。自分のアカウントの Amazon EBS ボリュームの 1 つをスタックで使用する場合は、スタックの [Resources] (リソースリソース) ページを使用してボリュームを登録し、インスタンスにアタッチします。詳細については、「リソース管理」を参照してください。

AWS OpsWorks スタックセキュリティグループを削除できない

問題: スタックを削除した後、削除できない多くの AWS OpsWorks スタックセキュリティグループが残ります。

原因: セキュリティグループは、特定の順序で削除する必要があります。

解決策: まず、どのインスタンスもセキュリティグループを使用していないことを確認します。その後、以下のセキュリティグループが存在する場合は、次の順序で任意のセキュリティグループを削除します。

1. AWS-OpsWorks-Blank-Server

2. AWS-OpsWorks-Monitoring-Master-Server

3. AWS-OpsWorks-DB-Master-Server

4. AWS-OpsWorks-Memcached-Server

5. AWS-OpsWorks-Custom-Server

6. AWS-OpsWorks-nodejs-App-Server

7. AWS-OpsWorks-PHP-App-Server

8. AWS-OpsWorks-Rails-App-Server

9. AWS-OpsWorks-Web-Server

10. AWS-OpsWorks-Default-Server

11. AWS-OpsWorks-LB-Server

誤って AWS OpsWorks スタックセキュリティグループを削除した

問題: AWS OpsWorks スタックセキュリティグループの 1 つを削除したため、再作成する必要があります。

原因: これらのセキュリティグループは誤って削除されることがよくあります。

解決策: 再作成されたグループは、グループ名の大文字と小文字を含め、元のグループとまったく同じである必要があります。グループを手動で再作成する代わりに、AWS OpsWorks スタックでこのタスクを実行する方法をお勧めします。同じ AWS のリージョン (および存在する場合は VPC) で新しいスタックを作成するだけで、AWS OpsWorks スタックによって、削除してしまったものを含め、すべての組み込みのセキュリティグループが自動的に再作成されます。その後、今後使用しないスタックを削除します。セキュリティグループは残ります。

Chef のログが突然終了する

問題: Chef のログが突然終了します。ログの最後には、正常な実行は示されず、例外やスタックトレースも表示されません。

原因: この動作は、通常、メモリが不十分であることによって発生します。

解決策: より大きいインスタンスを作成し、エージェント CLI の run_command コマンドを使用してレシピを再度実行します。詳細については、「レシピの実行」を参照してください。

クックブックが更新されない

問題: クックブックを更新しましたが、スタックのインスタンスはまだ古いレシピを実行しています。

原因: AWS OpsWorks スタックは各インスタンスにクックブックをキャッシュし、リポジトリからではなく、キャッシュからレシピを実行します。新しいインスタンスを起動すると、AWS OpsWorks スタックは、リポジトリからインスタンスのキャッシュに、クックブックをダウンロードします。ただし、その後でカスタムクックブックを変更した場合、AWS OpsWorks スタックはオンラインインスタンスのキャッシュを自動的には更新しません。

解決策: Update Cookbooks スタックコマンドを実行して、オンラインインスタンスのクックブックのキャッシュを更新するように明示的に AWS OpsWorks スタックに指示します。

インスタンスが起動中のステータスでスタックする

問題: インスタンスを再起動したとき、または自動ヒーリングが自動的にインスタンスを再起動したときに、起動オペレーションが booting ステータスで停止します。

原因: この問題の 1 つの原因として考えられるのは、デフォルト VPC を含む VPC 設定です。インスタンスは、常に AWS OpsWorks スタックサービス、Amazon S3、およびパッケージ、クックブック、アプリケーションのリポジトリと通信できる必要があります。たとえば、デフォルト VPC からデフォルトゲートウェイを削除した場合、インスタンスの AWS OpsWorks スタックサービスへの接続は失われます。AWS OpsWorks スタックはインスタンスのエージェントと通信できなくなるため、インスタンスが失敗したものと見なし、インスタンスを自動ヒーリングします。ただし、接続されていない場合、AWS OpsWorks スタックは修復されたインスタンスにインスタンスエージェントをインストールできません。エージェントがない場合、AWS OpsWorks スタックはインスタンスで Setup レシピを実行できないため、起動オペレーションを「booting」ステータスから先に進めることができません。

解決策: インスタンスが必要な接続を利用できるように、VPC の設定を変更します。

インスタンスが予期せずに再起動する

問題: 停止されたインスタンスが予期せずに再起動します。

原因 1: インスタンスの [auto healing] (オートヒーリング) を有効にしている場合、AWS OpsWorks スタックは関連付けられた Amazon EC2 インスタンスで定期的にヘルスチェックを実行し、異常なインスタンスを再起動します。Amazon EC2 コンソール、API、または CLI を使用して、AWS OpsWorks スタックで管理されるインスタンスを停止または終了する場合、AWS OpsWorks スタックには通知されません。代わりに、停止されたインスタンスを異常と見なし、自動的に再起動します。

解決策: AWS OpsWorks スタックコンソール、API、または CLI を使用することによってのみインスタンスを管理します。AWS OpsWorks スタックを使用してインスタンスを停止または削除する場合、そのスタックは再起動されません。詳細については、24/7 インスタンスの手動による起動、停止、再起動 および AWS OpsWorks Stacks インスタンスの削除 を参照してください。

原因 2: インスタンスは、さまざまな理由で失敗する可能性があります。自動ヒーリングを有効にしている場合、AWS OpsWorks スタックは失敗したインスタンスを自動的に再起動します。

解決策: これは通常の動作です。AWS 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_recipes コマンド

問題: インスタンスの詳細ページの [Logs] (ログ) セクションに、予期しない execute_recipes コマンドが表示されます。予期しない execute_recipes コマンドは、[Stack] (スタック) ページや [Deployments] (デプロイ) ページにも表示される場合があります。

原因: この問題は通常、アクセス許可の変更によって発生します。ユーザーまたはグループの SSH または sudo アクセス許可を変更すると、AWS OpsWorks スタックは execute_recipes を実行してスタックのインスタンスを更新し、Configure イベントもトリガーします。execute_recipes コマンドのもう 1 つのソースは、インスタンスエージェントを更新している AWS OpsWorks スタックです。

解決策: これは通常のオペレーションです。何もする必要はありません。

execute_recipes コマンドが実行したアクションを確認するには、[Deployments] (デプロイ) ページに移動し、コマンドのタイムスタンプをクリックします。これによりコマンドの詳細ページが開き、実行されたキーレシピがリスト表示されます。例えば、次の詳細ページは、execute_recipes を実行して SSH アクセス許可を更新する ssh_users コマンドのためのページです。

すべての詳細を表示するには、コマンドの [Log] (ログ) 列で [show] (表示) をクリックすると、関連付けられた Chef ログが表示されます。Run List のログを検索します。AWS 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"]