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

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

このセクションでは、よく発生する AWS OpsWorks スタックの問題とその解決策について説明します。

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

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

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

原因: インスタンスが依存している 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 との互換性に問題があることが知られているものがあります。

解決策： カスタム Chef クックブックの使用設定が有効になっている AWS 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 スタックの使用開始」で使用されている SimplePHPApp は index.html を使用しません。これらのサーバーに適した ping パスは / です。

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

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

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

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

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

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

問題： AWS OpsWorks スタックにインポートした EC2 インスタンスを再起動すると、インスタンスのステータスとして AWS OpsWorks スタックコンソールに失敗と表示されます。これは、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 スタックコンソール、API、または CLI を使用してのみ Amazon EBS ボリュームを管理します。自分のアカウントの Amazon EBS ボリュームの 1 つをスタックで使用する場合は、スタックの [Resources] (リソースリソース) ページを使用してボリュームを登録し、インスタンスにアタッチします。詳細については、「リソース管理」を参照してください。

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

問題： スタックを削除すると、削除できない AWS OpsWorks スタックセキュリティグループがいくつか残されます。

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

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

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

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

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

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

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 レシピを実行できないため、スタートアップオペレーションが「ブート」ステータスを超えることはできません。

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

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

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

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

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

原因 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"]