Amazon EC2 Auto Scaling の問題のトラブルシューティング - AWS CodeDeploy
Amazon EC2 Auto Scaling の一般的なトラブルシューティング CodeDeployRole 「次の AWS サービスでオペレーションを実行するアクセス許可は付与されません： AmazonAutoScaling」エラー Amazon EC2 Auto Scaling グループのインスタンスのプロビジョニングと終了が繰り返されてリビジョンをデプロイできない Amazon EC2 Auto Scaling インスタンスを終了または再起動すると、デプロイが失敗する場合がある複数のデプロイグループを 1 つの Amazon EC2 Auto Scaling グループに関連付けることは避けるAmazon EC2 Auto Scaling グループの EC2 インスタンスが起動に失敗し、「ハートビートのタイムアウト」というエラーが表示されるAmazon EC2 Auto Scaling ライフサイクルフックの不一致により、Amazon EC2 Auto Scaling グループへの自動デプロイが停止または失敗することがある「デプロイグループのインスタンスが見つからないため、デプロイに失敗しました」というエラー

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

Amazon EC2 Auto Scaling の問題のトラブルシューティング

Amazon EC2 Auto Scaling の一般的なトラブルシューティング

Amazon EC2 Auto Scaling グループの EC2 インスタンスへのデプロイは、次の理由で失敗する場合があります。

  • Amazon EC2 Auto Scaling は、EC2 インスタンスを継続的に起動および終了します。 CodeDeploy がアプリケーションリビジョンを自動的にデプロイできない場合、Amazon EC2 Auto Scaling は EC2 インスタンスを継続的に起動および終了します。

    Amazon EC2 Auto Scaling グループの CodeDeploy デプロイグループとの関連付けを解除するか、Amazon EC2 Auto Scaling グループの設定を変更して、必要な数のインスタンスが現在のインスタンス数と一致するようにします (これにより、Amazon EC2 Auto Scaling がそれ以上 EC2 インスタンスを起動できないようにします）。詳細については、「でデプロイグループ設定を変更する CodeDeploy」または「Amazon EC2 Auto Scaling のマニュアルスケーリング」を参照してください。

  • CodeDeploy エージェントは応答しません。EC2 インスタンスの起動直後または起動直後に実行される初期化スクリプト (cloud-init スクリプトなど) が実行されるまでに 1 時間以上かかる場合、 CodeDeploy エージェントがインストールされないことがあります。 CodeDeploy エージェントが保留中 CodeDeploy のデプロイに応答するまでに 1 時間のタイムアウトがあります。この問題に対処するには、初期化スクリプトを CodeDeployアプリケーションリビジョンに移動します。

  • Amazon EC2 Auto Scaling グループの EC2 インスタンスは、デプロイ中に再起動します。デプロイ中に EC2 インスタンスが再起動された場合、またはデプロイコマンドの処理中に CodeDeploy エージェントがシャットダウンされた場合、デプロイが失敗する可能性があります。詳細については、「Amazon EC2 Auto Scaling インスタンスを終了または再起動すると、デプロイが失敗する場合がある」を参照してください。

  • 複数のアプリケーションリビジョンが Amazon EC2 Auto Scaling グループの同じ EC2 インスタンスに同時にデプロイされた。Amazon EC2 Auto Scaling グループの同じ EC2 インスタンスに複数のアプリケーションリビジョンをデプロイする場合、デプロイの 1 つに数分以上実行されるスクリプトがあると、失敗することがあります。Amazon EC2 Auto Scaling グループの同じ EC2 インスタンスに複数のアプリケーションリビジョンをデプロイしないでください。

  • Amazon EC2 Auto Scaling グループの一部として起動された新しい EC2 インスタンスに対して、デプロイが失敗する。このシナリオでは、デプロイでスクリプトを実行すると、Amazon EC2 Auto Scaling グループで EC2 インスタンスを起動できなくなる場合があります。(Amazon EC2 Auto Scaling グループの他の EC2 インスタンスは、正常に実行されているように見える場合があります)。この問題に対応するには、最初にその他のすべてのスクリプトが完了していることを確認します。

    • CodeDeploy エージェントは AMI に含まれていません: 新しいインスタンスの起動中に cfn-init コマンドを使用して CodeDeploy エージェントをインストールする場合は、 AWS CloudFormation テンプレートの cfn-initセクションの最後にエージェントインストールスクリプトを配置します。

    • CodeDeploy エージェントは AMI に含まれます: インスタンスの作成時にエージェントが Stopped状態になるように AMI を設定し、スクリプトライブラリの最終ステップとしてエージェントを開始するためのcfn-initスクリプトを含めます。

CodeDeployRole 「次の AWS サービスでオペレーションを実行するアクセス許可は付与されません： AmazonAutoScaling」エラー

起動テンプレートを使用して作成された Auto Scaling グループを使用するデプロイでは、次のアクセス権限が必要です。これらは、 AWSCodeDeployRole AWS 管理ポリシーによって付与されるアクセス許可に追加されます。

  • EC2:RunInstances

  • EC2:CreateTags

  • iam:PassRole

これらのアクセス権限がないために、このエラーが発生した可能性があります。詳細については、「Amazon EC2 Auto Scaling ユーザーガイド」の「チュートリアル: CodeDeploy を使用して Auto Scaling グループにアプリケーションをデプロイする」、「Auto Scaling グループの起動テンプレートの作成」、および「アクセス許可」を参照してください。

Amazon EC2 Auto Scaling グループのインスタンスのプロビジョニングと終了が繰り返されてリビジョンをデプロイできない

エラーが原因で、Amazon EC2 Auto Scaling グループ内の新しくプロビジョニングされたインスタンスに正常にデプロイできない場合があります。その結果として、インスタンスは正常な状態にならず、デプロイは失敗します。デプロイが正常に実行または完了されないため、インスタンスは作成後すぐに終了されます。この場合、Amazon EC2 Auto Scaling グループの設定により、正常なホスト数の最小要件を満たすために別のバッチのインスタンスがプロビジョニングされます。このバッチも終了され、同じサイクルが繰り返されます。

エラーの原因として以下が考えられます。

  • Amazon EC2 Auto Scaling グループのヘルスチェックに失敗しました。

  • アプリケーションリビジョンのエラー。

この問題を回避するには、次の手順に従います。

  1. Amazon EC2 Auto Scaling グループに属していない EC2 インスタンスを手動で作成します。インスタンスに一意の EC2 インスタンスタグを付けます。

  2. 新しいインスタンスを該当するデプロイグループに追加します。

  3. 新しい、エラーのないアプリケーションリビジョンをデプロイグループにデプロイします。

これにより、Amazon EC2 Auto Scaling グループの今後のインスタンスにアプリケーションリビジョンがデプロイされるようになります。

注記

デプロイが正常に完了したことを確認したら、作成したインスタンスを削除して、 AWS アカウントへの継続的な課金を回避します。

Amazon EC2 Auto Scaling インスタンスを終了または再起動すると、デプロイが失敗する場合がある

EC2 インスタンスが Amazon EC2 Auto Scaling を通じて起動され、その後で終了または再起動されると、そのインスタンスへのデプロイは、次の理由で失敗する場合があります。

  • 進行中のデプロイで、スケールインイベントまたはその他の終了イベントにより、インスタンスは Amazon EC2 Auto Scaling グループからデタッチされた後に削除されます。デプロイは完了できないため、失敗します。

  • インスタンスは再起動されますが、インスタンスが開始するまでに 5 分以上かかります。タイムアウトとして CodeDeploy 処理されます。サービスにより、インスタンスに対する現在およびそれ以降のすべてのデプロイが失敗します。

この問題に対応するには:

  • 一般的に、インスタンスが削除または再起動される前に、すべてのデプロイが完了したことを確認します。インスタンスの起動または再起動後に、すべてのデプロイが開始されることを確認します。

  • Amazon EC2 Auto Scaling の設定に Windows Server ベースの Amazon Machine Image (AMI) を指定し、EC2Config サービスを使用して、インスタンスのコンピュータ名を設定すると、デプロイは失敗します。この問題を解決するには、Windows Server ベース AMI で、[EC2 Service Properties] (EC2 サービスプロパティ) の [General] (全般) タブにある [Set Computer Name] (コンピュータ名の設定) をオフにします。このチェックボックスをオフにすると、この動作は、その Windows Server の基本 AMI で起動されるすべての新しい Windows Server Amazon EC2 Auto Scaling インスタンスで、この動作が無効になります。この動作が有効になっている Windows Server Amazon EC2 Auto Scaling インスタンスでは、このチェックボックスをオフにする必要はありません。再起動後に、失敗したデプロイをこれらのインスタンスに再デプロイします。

複数のデプロイグループを 1 つの Amazon EC2 Auto Scaling グループに関連付けることは避ける

各 Amazon EC2 Auto Scaling グループには 1 つのデプロイグループのみを関連付けることをお勧めします。

これは、複数のデプロイグループに関連付けられたフックを持つインスタンスを Amazon EC2 Auto Scaling がスケールアップする場合、すべてのフックに対して一度に通知を送信するためです。これにより、各インスタンスの複数のデプロイが同時に開始されます。複数のデプロイが CodeDeploy 同時にエージェントにコマンドを送信すると、ライフサイクルイベントとデプロイの開始または前のライフサイクルイベントの終了の間の 5 分間のタイムアウトに達する可能性があります。その場合は、予想通りにデプロイがプロセスされていてもデプロイが失敗します。

注記

ライフサイクルイベント内にあるスクリプトのデフォルトのタイムアウトは、デフォルトで 30 分です。タイムアウトは、 AppSpec ファイル内の別の値に変更できます。詳細については、「EC2/オンプレミスデプロイ用の AppSpec ファイルを追加する」を参照してください。

複数のデプロイが同時に実行を試みた場合、デプロイが発生する順序を制御することはできない。

最後に、インスタンスへのデプロイが失敗した場合、Amazon EC2 Auto Scaling は直ちにインスタンスを終了します。その最初のインスタンスがシャットダウンすると、実行中の他のデプロイも失敗します。 CodeDeploy には CodeDeploy エージェントが保留中のデプロイに応答するための 1 時間のタイムアウトがあるため、各インスタンスがタイムアウトするまでに最大 60 分かかることがあります。

Amazon EC2 Auto Scaling の詳細については、「Under the hood: CodeDeploy 」およびAuto Scaling 統合」を参照してください。

Amazon EC2 Auto Scaling グループの EC2 インスタンスが起動に失敗し、「ハートビートのタイムアウト」というエラーが表示される

Amazon EC2 Auto Scaling グループが新しい EC2 インスタンスの起動に失敗し、次のようなメッセージを生成する場合があります。

Launching a new EC2 instance <instance-Id>. Status Reason: Instance failed to complete user's Lifecycle Action: Lifecycle Action with token<token-Id> was abandoned: Heartbeat Timeout.

このメッセージは通常、以下のいずれかを示します。

  • AWS アカウントに関連付けられた同時デプロイの最大数に達しました。デプロイの制限の詳細については、「CodeDeploy クォータ」を参照してください。

  • Auto Scaling グループは、あまりにも多くの EC2 インスタンスを早く起動しようとしました。新しいインスタンスCompleteLifecycleActionごとに RecordLifecycleActionHeartbeatまたは への API コールがスロットリングされました。

  • のアプリケーション CodeDeploy は、関連付けられたデプロイグループが更新または削除される前に削除されました。

    アプリケーションまたはデプロイグループを削除すると、関連付けられた Amazon EC2 Auto Scaling フックをクリーンアップ CodeDeploy しようとしますが、一部のフックが残っている可能性があります。デプロイグループを削除するコマンドを実行すると、残りのフックが出力で返ります。ただし、アプリケーションを削除するコマンドを実行した場合、残りのフックは出力に表示されません。

    したがって、アプリケーションを削除する前に、アプリケーションと関連付けられたすべてのデプロイグループを削除することをお勧めします。コマンド出力を使用して、手動で削除する必要があるライフサイクルフックを識別できます。

「ハートビートのタイムアウト」エラーメッセージが表示される場合は、次の操作を行い、残っているライフサイクルフックが原因かどうかを特定して問題を解決します。

  1. 次のいずれかを行います。

    • delete-deployment-group コマンドを呼び出して、ハートビートタイムアウトの原因となっている Auto Scaling グループに関連付けられたデプロイグループを削除します。

    • null 以外の空の Auto Scaling グループ名のリストを指定して update-deployment-group コマンドを呼び出し、 CodeDeployが管理するすべての Auto Scaling ライフサイクルフックをデタッチします。

      例えば、次のコマンドを入力します AWS CLI 。

      aws deploy update-deployment-group --application-name my-example-app --current-deployment-group-name my-deployment-group --auto-scaling-groups

      別の例として、Java で CodeDeploy API を使用している場合は、 UpdateDeploymentGroupを呼び出し、 autoScalingGroupsを に設定しますnew ArrayList<String>()。これにより、autoScalingGroups を空のリストに設定し、既存のリストを削除します。デフォルトの null を使用すると、autoScalingGroups がそのまま残ってしまうので使用しないでください。

    呼び出しの出力を確認します。出力に hooksNotCleanedUp 構造と Amazon EC2 Auto Scaling ライフサイクルフックの一覧が含まれている場合、ライフサイクルフックの残りがあります。

  2. describe-lifecycle-hooks コマンドを呼び出し、起動に失敗した Amazon EC2 EC2 Auto Scaling グループの名前を指定します。出力で、次のいずれかを確認します。

    • Amazon EC2 Auto Scaling ライフサイクルフック名で、ステップ 1 で特定した hooksNotCleanedUp 構造に対応するもの

    • Amazon EC2 Auto Scaling ライフサイクルフック名で、失敗している Auto Scaling グループに関連するデプロイグループの名前を含むもの

    • CodeDeploy デプロイのハートビートタイムアウトの原因となった可能性がある Amazon EC2 Auto Scaling ライフサイクルフック名。

  3. フックがステップ 2 にリストされているカテゴリのいずれかに当てはまる場合は、 delete-lifecycle-hook コマンドを呼び出して削除します。Amazon EC2 Auto Scaling グループとライフサイクルフックをコールで指定します。

    重要

    ステップ 2 で説明したように、問題の原因となっているフックのみを削除してください。実行可能なフックを削除すると、デプロイが失敗したり、アプリケーションリビジョンをスケールアウトした EC2 インスタンスにデプロイできない CodeDeploy 場合があります。

  4. 目的の Auto Scaling グループ名を使用して update-deployment-groupまたは create-deployment-group コマンドを呼び出します。 CodeDeploy は、新しい UUID を使用して Auto Scaling フックを再インストールします。 UUIDs

注記

CodeDeploy デプロイグループから Auto Scaling グループをデタッチすると、Auto Scaling グループへの進行中のデプロイが失敗し、Auto Scaling グループによってスケールアウトされた新しい EC2 インスタンスは からアプリケーションリビジョンを受信しません CodeDeploy。 Auto Scaling Auto Scaling を で再び動作させるには CodeDeploy、Auto Scaling グループをデプロイグループに再アタッチし、新しい を呼び出しCreateDeploymentてフリート全体のデプロイを開始する必要があります。

Amazon EC2 Auto Scaling ライフサイクルフックの不一致により、Amazon EC2 Auto Scaling グループへの自動デプロイが停止または失敗することがある

Amazon EC2 Auto Scaling および は、ライフサイクルフック CodeDeploy を使用して、Amazon EC2 Auto Scaling グループでAmazon EC2 インスタンスにデプロイするかを決定します。 Auto Scaling Amazon EC2 Auto Scaling と でライフサイクルフックとこれらのフックに関する情報が完全に一致しない場合、自動デプロイは停止または失敗する可能性があります CodeDeploy。

Amazon EC2 Auto Scaling グループへのデプロイが失敗する場合は、Amazon EC2 Auto Scaling と のライフサイクルフック名 CodeDeploy が一致しているかどうかを確認します。そうでない場合は、次の AWS CLI コマンドコールを使用します。

最初に、Amazon EC2 Auto Scaling グループとデプロイグループの両方のライフサイクルフック名の一覧を取得します。

  1. describe-lifecycle-hooks コマンドを呼び出し、 のデプロイグループに関連付けられた Amazon EC2 Auto Scaling グループの名前を指定します CodeDeploy。出力の LifecycleHooks リストで、LifecycleHookName のそれぞれの値を書き留めます。

  2. get-deployment-group コマンドを呼び出し、Amazon EC2 Auto Scaling グループに関連付けられたデプロイグループの名前を指定します。出力の autoScalingGroups リストで、名前の値が Amazon EC2 Auto Scaling グループ名と一致する項目を見つけ、対応する hook の値を書き留めます。

ここで、2 セットのライフサイクルフック名を比較します。それらが 1 文字ずつ正確に一致する場合は、これが問題ではありません。このセクションの他の場所で説明されている Amazon EC2 Auto Scaling の他のトラブルシューティングステップを試してください。

ただし、2 セットのライフサイクルフック名が 1 文字ずつ正確に一致しない場合は、次の操作を行います。

  1. get-deployment-group コマンド出力にもないライフサイクルフック名が describe-lifecycle-hooks コマンド出力にある場合は、次の操作を行います。

    1. describe-lifecycle-hooks コマンド出力の各ライフサイクルフック名について、 delete-lifecycle-hook コマンドを呼び出します。

    2. update-deployment-group コマンドを呼び出し、元の Amazon EC2 Auto Scaling グループの名前を指定します。 は、Amazon EC2 Auto Scaling グループに新しい代替ライフサイクルフック CodeDeploy を作成し、ライフサイクルフックをデプロイグループに関連付けます。これで、Amazon EC2 Auto Scaling グループに新しいインスタンスを追加すると、自動デプロイが開始されます。

  2. describe-lifecycle-hooks コマンド出力にもないライフサイクルフック名が get-deployment-group コマンド出力にある場合は、次の操作を行います。

    1. update-deployment-group コマンドを呼び出しますが、元の Amazon EC2 Auto Scaling グループの名前を指定しないでください。

    2. update-deployment-group コマンドを再度呼び出しますが、今回は元の Amazon EC2 Auto Scaling group. CodeDeploy re-creates the missing Lifecycle hooks in the Amazon EC2 Auto Scaling group の名前を指定します。これで、Amazon EC2 Auto Scaling グループに新しいインスタンスを追加すると、自動デプロイが開始されます。

1 文字ごとに正確に一致する 2 セットのライフサイクルフック名を取得したら、アプリケーションリビジョンをもう一度デプロイしますが、Amazon EC2 Auto Scaling グループに追加された新しいインスタンスにのみデプロイします。Amazon EC2 Auto Scaling グループに既に存在するインスタンスに対しては、デプロイは自動的に行われません。

「デプロイグループのインスタンスが見つからないため、デプロイに失敗しました」というエラー

次の CodeDeploy エラーが表示された場合は、このセクションをお読みください。

The deployment failed because no instances were found for your deployment group. Check your deployment group settings to make sure the tags for your EC2 instances or Auto Scaling groups correctly identify the instances you want to deploy to, and then try again.

このエラーの原因として考えられるのは、以下の通りです。

  1. デプロイグループの設定には、正しくない Auto Scaling グループ、EC2 インスタンス、またはオンプレミスインスタンスのタグが含まれています。この問題を解決するには、タグが正しいことをチェックしてから、アプリケーションを再デプロイしてください。

  2. デプロイ開始後、フリートがスケールアウトしました。このシナリオでは、フリートで InService 状態の正常なインスタンスが表示されますが、上記のエラーも表示されます。この問題を解決するには、アプリケーションを再デプロイします。

  3. Auto Scaling グループには、InService 状態のインスタンスは含まれません。このシナリオでは、フリート全体のデプロイを実行しようとすると、少なくとも 1 つのインスタンスが InService状態 CodeDeploy になる必要があるため、上記のエラーメッセージが表示されてデプロイが失敗します。InService 状態でインスタンスがない場合、様々な理由が考えられます。その一部を紹介します。

    • Auto Scaling グループのサイズを 0 にスケジュール (または手動で設定) しました。

    • Auto Scaling は、不正な EC2 インスタンスを検出したため (例えば、EC2 インスタンスにハードウェア障害が発生した)、すべてキャンセルし、InService 状態には何も残さないようにしました。

    • から 0へのスケールアウトイベント中に1、 は、前回の CodeDeploy デプロイ以降に異常になった、以前に成功したリビジョン (最後に成功したリビジョン と呼ばれる) をデプロイしました。これにより、スケールアウトしたインスタンスのデプロイが失敗し、そのため、Auto Scaling がインスタンスをキャンセルし、InService 状態のインスタンスが一つも残らないという事態が発生しました。

      InService 状態のインスタンスがないことがわかった場合、次の手順 To troubleshoot the error if there are no instances in the InService state の説明に従ってトラブルシューティングします。

InService 状態のインスタンスがない場合にエラーをトラブルシューティングするには

  1. Amazon EC2 コンソールで、[希望する容量] の設定を確認します。ゼロの場合は、正の数に設定します。インスタンスが InService になるのを待ちます。これは、デプロイが成功したことを意味します。問題が解決されたので、このトラブルシューティングの手順の残りのステップはスキップできます。[Desired Capacity] (希望する容量) の設定については、「Amazon EC2 Auto Scaling ユーザーガイド」の「Auto Scaling グループの容量制限を設定する」を参照してください。

  2. Auto Scaling が希望する容量を満たすために新しい EC2 インスタンスを起動し続けようとするが、スケールアウトを実行できない場合は、通常、Auto Scaling のライフサイクルフックが失敗していることが原因です。この問題については、次のようにトラブルシューティングします。

    1. 失敗している Auto Scaling ライフサイクルフックイベントを確認するには、Amazon EC2 Auto Scaling ユーザーガイドの「Auto Scaling グループのスケーリングアクティビティの確認」を参照してください。

    2. 失敗したフックの名前が の場合はCodeDeploy-managed-automatic-launch-deployment-hook-DEPLOYMENT_GROUP_NAME、「」に移動し CodeDeploy、デプロイグループを見つけて、Auto Scaling によって開始された失敗したデプロイを見つけます。次に、デプロイが失敗した理由を調べます。

    3. デプロイが失敗した理由 ( CloudWatch アラームが発生していたなど) がわかっていて、リビジョンを変更せずに問題を解決できる場合は、今すぐ行ってください。

    4. 調査後、 CodeDeployの最後に成功したリビジョンが正常でなくなり、Auto Scaling グループに正常なインスタンスがゼロであると判断した場合、デプロイのデッドロックシナリオになります。この問題を解決するには、Auto Scaling グループから CodeDeployのライフサイクルフックを一時的に削除し、フックを再インストールして新しい (正常な) CodeDeploy リビジョンを再デプロイすることで、不正なリビジョンを修正する必要があります。手順については、こちらを参照してください。

デプロイのデッドロックの問題を解決するには (CLI)

  1. （オプション) CodeDeploy エラーの原因となっている CI/CD パイプラインをブロックして、この問題を解決している間に予期しないデプロイが発生しないようにします。

  2. 現在の Auto Scaling DesiredCapacity設定を書き留めます。

    aws autoscaling describe-auto-scaling-groups --auto-scaling-group-name ASG_NAME

    場合によっては、この手順の最後に、この数値にスケールバックする必要があります。

  3. Auto Scaling DesiredCapacity設定を に設定します1。開始の際に希望する容量が 1 より大きい場合、オプションとなります。それを 1 に減らすことで、インスタンスのプロビジョニングとデプロイにかかる時間が短くなり、トラブルシューティングが高速化されます。Auto Scaling の希望する容量がもともと 0 に設定されている場合、1 に増やす必要があります。これは必須です。

    aws 自動スケーリング set-desired-capacity --auto-scaling-group-name ASG_NAME --desired-capacity 1

    注記

    この手順の残りのステップでは、 を に設定していることを前提DesiredCapacityとしています1。

    この時点で、Auto Scaling は 1 つのインスタンスへのスケーリングを試みます。次に、 が CodeDeploy 追加したフックがまだ存在するため、デプロイ CodeDeploy を試みます。デプロイは失敗します。Auto Scaling はインスタンスをキャンセルします。Auto Scaling はインスタンスを再起動して希望する容量の 1 に到達しようとしますが、再度失敗します。キャンセル再起動ループに入っています。

  4. デプロイグループから Auto Scaling グループの登録を解除します。

    警告

    次のコマンドは、ソフトウェアなしで新しい EC2 インスタンスを起動します。コマンドを実行する前に、ソフトウェアを実行していない Auto Scaling InService インスタンスが許容されることを確認します。例えば、インスタンスに関連付けられているロードバランサーがソフトウェアなしでこのホストにトラフィックを送信していないことを確認してください。

    重要

    フックを削除するには、以下に示す CodeDeploy コマンドを使用します。フックは によって認識されないため、Auto Scaling サービスを通じてフックを削除しないでください CodeDeploy。

    aws deploy update-deployment-group --application-name APPLICATION_NAME --current-deployment-group-name DEPLOYMENT_GROUP_NAME --auto-scaling-groups

    このコマンドを実行すると、次の処理が実行されます。

    1. CodeDeploy は、デプロイグループから Auto Scaling グループを登録解除します。

    2. CodeDeploy は、Auto Scaling ライフサイクルフックを Auto Scaling グループから削除します。

    3. デプロイ失敗の原因となっていたフックが存在しなくなるため、Auto Scaling は既存の EC2 インスタンスをキャンセルし、希望容量にスケーリングする新しいインスタンスを直ちに起動します。新しいインスタンスは、InService 状態にまもなく移行するはずです。新しいインスタンスには、ソフトウェアは含まれません。

  5. EC2 インスタンスが InService 状態になるのを待ちます。その状態を確認するには、次のコマンドを使用します。

    aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names ASG_NAME --query AutoScalingGroups[0].Instances[*].LifecycleState

  6. EC2 インスタンスにフックを追加し直します。

    重要

    フックを追加するには、以下に示す CodeDeploy コマンドを使用します。フックの追加には Auto Scaling サービスを使用しないでください。追加は によって認識されないためです CodeDeploy。

    aws deploy update-deployment-group --application-name APPLICATION_NAME --current-deployment-group-name DEPLOYMENT_GROUP_NAME --auto-scaling-groups ASG_NAME

    このコマンドを実行すると、次の処理が実行されます。

    1. CodeDeploy は、EC2 インスタンスに Auto Scaling ライフサイクルフックを再インストールします。

    2. CodeDeploy は、Auto Scaling グループをデプロイグループに再登録します。

  7. Amazon S3 またはリ GitHub ビジョンを使用して、正常で使用したいフリート全体のデプロイを作成します。

    たとえば、リビジョンが、my-revision-bucket という Amazon S3 バケットにある .zip ファイルで、オブジェクトキーが httpd_app.zip である場合、次のコマンドを入力します。

    aws deploy create-deployment --application-name APPLICATION_NAME --deployment-group-name DEPLOYMENT_GROUP_NAME --revision "revisionType=S3,s3Location={bucket=my-revision-bucket,bundleType=zip,key=httpd_app.zip}"

    現在、Auto Scaling グループに InService インスタンスが一つ存在するため、このデプロイは機能するはずで、エラー [デプロイグループのインスタンスが見つからないため、デプロイに失敗しました] は表示されなくなります。

  8. 以前にスケールインしていた場合、デプロイが成功したら、Auto Scaling グループをスケールアウトして元の容量に戻します。

    aws autoscaling set-desired-capacity --auto-scaling-group-name ASG_NAME --desired-capacity ORIGINAL_CAPACITY

デプロイのデッドロックの問題を解決するには (コンソール)

  1. （オプション) CodeDeploy エラーの原因となっている CI/CD パイプラインをブロックして、この問題を解決している間に予期しないデプロイが発生しないようにします。

  2. Amazon EC2 コンソールにアクセスし、Auto Scaling の [希望する容量] の設定を書き留めます。場合によっては、この手順の最後に、この数値にスケールバックする必要があります。この設定の見つけ方の詳細については、「Auto Scaling グループの容量制限の設定」を参照してください。

  3. 必要な EC2 インスタンスの数を 1 に設定:

    希望する容量が 1 より大きい場合、オプションとなります。それを 1 に減らすことで、インスタンスのプロビジョニングとデプロイにかかる時間が短くなり、トラブルシューティングが高速化されます。Auto Scaling の 希望する容量 がもともとに 0 設定されている場合、1 に増やす必要があります。これは必須です。

    注記

    この手順の残りのステップでは、1 に 希望する容量 を設定したものとします。

    1. https://console.aws.amazon.com/ec2/ でAmazon EC2 コンソールを開き、ナビゲーションペインで [Auto Scaling グループ] を選択します。

    2. 適切なリージョンを選択します。

    3. 問題がある Auto Scaling グループに移動します。

    4. [グループの詳細] で、[編集] を選択します。

    5. 1 に 希望する容量 を設定。

    6. [更新] を選択します。

  4. デプロイグループから Auto Scaling グループの登録を解除します。

    警告

    次のサブステップでは、ソフトウェアなしで新しい EC2 インスタンスを起動します。コマンドを実行する前に、ソフトウェアを実行していない Auto Scaling InService インスタンスが許容されることを確認します。例えば、インスタンスに関連付けられているロードバランサーがソフトウェアなしでこのホストにトラフィックを送信していないことを確認してください。

    1. https://console.aws.amazon.com/codedeploy/ で CodeDeploy コンソールを開きます。

    2. 適切なリージョンを選択します。

    3. ナビゲーションペインで、[アプリケーション] を選択します。

    4. CodeDeploy アプリケーションの名前を選択します。

    5. CodeDeploy デプロイグループの名前を選択します。

    6. [編集] を選択します。

    7. 環境設定 では、Amazon EC2 Auto Scaling グループ の選択を解除します。

      注記

      環境設定が定義されていない場合、コンソールでは設定を保存できません。チェックをバイパスするには、どのホストにも解決しないことがわかっている EC2 または On-premises のタグを一時的に追加してください。タグを追加するには、Amazon EC2 インスタンス または オンプレミスインスタンス を選択し、タグの キー として EC2 または On-premises を追加します。タグの 値 は、空欄でも構いません。

    8. [変更を保存] を選択します。

      これらのサブステップを完了すると、次のようになります。

      1. CodeDeploy は、デプロイグループから Auto Scaling グループを登録解除します。

      2. CodeDeploy は、Auto Scaling ライフサイクルフックを Auto Scaling グループから削除します。

      3. デプロイ失敗の原因となっていたフックが存在しなくなるため、Auto Scaling は既存の EC2 インスタンスをキャンセルし、希望容量にスケーリングする新しいインスタンスを直ちに起動します。新しいインスタンスは、InService 状態にまもなく移行するはずです。新しいインスタンスには、ソフトウェアは含まれません。

  5. EC2 インスタンスが InService 状態になるのを待ちます。その状態を確認するには:

    1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

    2. ナビゲーションペインで、[Auto Scaling Groups] をクリックします。

    3. [Auto Scaling グループ] を選択します。

    4. コンテンツペインで、インスタンス管理 タブを選択します。

    5. 「インスタンス」で、ライフサイクル列にインスタンスのInService横に が表示されていることを確認します。

  6. デプロイグループの削除に使用したのと同じ方法を使用して、Auto Scaling グループを CodeDeploy デプロイグループに再登録します。

    1. https://console.aws.amazon.com/codedeploy/ で CodeDeploy コンソールを開きます。

    2. 適切なリージョンを選択します。

    3. ナビゲーションペインで、[アプリケーション] を選択します。

    4. CodeDeploy アプリケーションの名前を選択します。

    5. CodeDeploy デプロイグループの名前を選択します。

    6. [編集] を選択します。

    7. 環境設定 で、Amazon EC2 Auto Scaling グループ を選択し、リストから Auto Scaling グループを選択します。

    8. Amazon EC2 インスタンス または オンプレミスインスタンス で、追加したタグを見つけて削除します。

    9. Amazon EC2 インスタンスまたはオンプレミスインスタンス の横にあるチェックボックスの選択を解除します。

    10. [変更を保存] を選択します。

    この設定により、ライフサイクルフックが Auto Scaling グループに再インストールされます。

  7. Amazon S3 またはリ GitHub ビジョンを使用して、正常で使用したいフリート全体のデプロイを作成します。

    たとえば、リビジョンが、my-revision-bucket という Amazon S3 バケットにある .zip ファイルで、オブジェクトキーが httpd_app.zip である場合、以下を実行します。

    1. CodeDeploy コンソールのデプロイグループページで、デプロイの作成を選択します。

    2. [Revision type (リビジョンのタイプ)] の場合は、[My application is stored in Amazon S3 (Amazon S3 に保存されているアプリケーション)] を選択します。

    3. リビジョンの場所 は、s3://my-revision-bucket/httpd_app.zip を選択します。

    4. [リビジョンファイルの種類] で、[.zip] を選択します。

    5. [Create deployment] を選択します。

    現在、Auto Scaling グループに InService インスタンスが一つ存在するため、このデプロイは機能するはずで、エラー [デプロイグループのインスタンスが見つからないため、デプロイに失敗しました] は表示されなくなります。

  8. 以前にスケールインしていた場合、デプロイが成功したら、Auto Scaling グループをスケールアウトして元の容量に戻します。

    1. https://console.aws.amazon.com/ec2/ でAmazon EC2 コンソールを開き、ナビゲーションペインで [Auto Scaling グループ] を選択します。

    2. 適切なリージョンを選択します。

    3. Auto Scaling グループに移動します。

    4. [グループの詳細] で、[編集] を選択します。

    5. 希望する容量 元の値に戻す設定をします。

    6. [更新] を選択します。