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

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

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

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

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

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

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

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

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

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

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

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

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

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

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

解決策: OnAWS OpsWorksスタックがUse custom Chef cookbooks設定を有効にしている場合、カスタムクックブックまたはコミュニティクックブックは、スタックで使用する Chef のバージョンを常にサポートしている必要があります。コミュニティクックブックを、スタック設定で設定されている Chef のバージョンと互換性があるバージョンにピンしてください (クックブックのバージョンを特定のバージョンに設定します)。サポートされているクックブックバージョンを探すには、コンパイルに失敗したクックブックの変更ログを表示し、スタックでサポートされているクックブックの最新バージョンのみを使用します。クックブックのバージョンをピンするには、カスタムクックブックリポジトリの Berkfile にバージョン番号を正確に指定します。たとえば、cookbook 'build-essential', '= 3.2.0' と指定します。

すべての Layer のインスタンスで Elastic Load Balancing のHealth チェック

問題: アプリケーションサーバー Layer に 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 のLoad Balancer と通信できない

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

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

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

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

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

  3. [] をクリックします。編集] のインバウンドタブ。

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

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

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

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

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

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

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

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

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

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

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

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

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 スタックセキュリティグループを削除した

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

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

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

Chef のログが突然終了する

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

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

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

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

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

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

解決策: を実行「クックブックの更新」スタックコマンド明示的に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 インスタンスで定期的にヘルスチェックを実行し、異常なインスタンスを再起動します。お客様がを停止または終了した場合AWS OpsWorksスタックで管理されるインスタンス。Amazon EC2 コンソール、API、または CLI を使用します。AWS OpsWorksスタックには通知されません。代わりに、停止されたインスタンスを異常と見なし、自動的に再起動します。

解決策: インスタンスを管理するには、AWS OpsWorksコンソール、API、CLI のいずれかをスタックします。AWS OpsWorks スタックを使用してインスタンスを停止または削除する場合、&OPS; スタックは再起動されません。詳細については、「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 コマンド

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

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

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

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

すべての詳細を表示するには、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"]