翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# CodeDeploy のトラブルシューティング
このセクションのトピックは、CodeDeploy を使用するときに発生することがある問題やエラーの解決にお使いください。
**注記**
多くのデプロイ失敗の原因を特定するには、デプロイプロセスで作成されたログファイルを確認できます。分かりやすいように、インスタンス別に表示するのではなく、Amazon CloudWatch Logs を使用してログファイルを集中的にモニタリングすることをお勧めします。詳細については、「[Amazon CloudWatch ツールを使用したデプロイのモニタリング](monitoring-cloudwatch.md)」を参照してください。
**Topics**
+ [一般的なトラブルシューティングの問題](troubleshooting-general.md)
+ [EC2/オンプレミスのデプロイに関する問題のトラブルシューティング](troubleshooting-deployments.md)
+ [Amazon ECS のデプロイに関する問題のトラブルシューティング](troubleshooting-ecs.md)
+ [AWS Lambda デプロイの問題のトラブルシューティング](troubleshooting-deployments-lambda.md)
+ [デプロイグループの問題のトラブルシューティング](troubleshooting-deployment-groups.md)
+ [インスタンスの問題のトラブルシューティング](troubleshooting-ec2-instances.md)
+ [GitHub トークンの問題のトラブルシューティング](troubleshooting-github-token-issues.md)
+ [Amazon EC2 Auto Scaling の問題のトラブルシューティング](troubleshooting-auto-scaling.md)
+ [AWS CodeDeploy のエラーコード](error-codes.md)
# 一般的なトラブルシューティングの問題
**Topics**
+ [一般的なトラブルシューティングのチェックリスト](#troubleshooting-checklist)
+ [CodeDeploy デプロイリソースは、一部の AWS リージョンでのみ でサポートされています](#troubleshooting-supported-regions)
+ [このガイドの手順が CodeDeploy コンソールと一致しない](#troubleshooting-old-console)
+ [必要な IAM ロールを取得できない](#troubleshooting-iam-cloudformation)
+ [何らかのテキストエディタを使用して AppSpec ファイルとシェルスクリプトを作成すると、デプロイが失敗する場合がある](#troubleshooting-text-editors)
+ [macOS の Finder を使用してアプリケーションリビジョンをバンドルすると、デプロイが失敗することがある](#troubleshooting-bundle-with-finder)
## 一般的なトラブルシューティングのチェックリスト
次のチェックリストを使用して、失敗したデプロイをトラブルシューティングできます。
1. デプロイが失敗した理由を確認するには、「[CodeDeploy デプロイの詳細を表示する](deployments-view-details.md)」および「[CodeDeploy を用いてインスタンスの詳細の表示](instances-view-details.md)」を参照してください。原因を特定できない場合は、このチェックリストの項目を確認します。
1. インスタンスが正しく設定されているかどうかを確認します。
+ インスタンスは、指定された EC2 キーペアで起動されましたか? 詳細については、「*Amazon EC2 ユーザーガイド*」の「[EC2 キーペア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2-key-pairs.html)」を参照してください。
+ 正しい IAM インスタンスプロファイルがインスタンスにアタッチされていますか? 詳細については、「[CodeDeploy と共に動作するように Amazon EC2 インスタンスを構成します](instances-ec2-configure.md)」および「[ステップ 4: Amazon EC2 インスタンス用の IAM インスタンスプロファイルを作成する](getting-started-create-iam-instance-profile.md)」を参照してください。
+ インスタンスにタグが付けられていますか? 詳細については、「*Amazon EC2 ユーザーガイド*」の「[コンソールでのタグの操作](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console)」を参照してください。
+ CodeDeploy エージェントは、インスタンスにインストール後、更新、実行されていますか? 詳細については、「[CodeDeploy エージェントのオペレーションの管理](codedeploy-agent-operations.md)」を参照してください。インストールされているエージェントのバージョンを確認するには、「[CodeDeploy エージェントのバージョンを特定します。](codedeploy-agent-operations-version.md)」を参照してください。
1. アプリケーションとデプロイグループの設定を確認します。
+ アプリケーション設定を確認するには、「[CodeDeploy を使用してアプリケーション詳細を表示する](applications-view-details.md)」を参照してください。
+ デプロイグループの設定を確認するには、「[CodeDeploy を使用したデプロイグループの詳細の表示](deployment-groups-view-details.md)」を参照してください。
1. アプリケーションリビジョンが正しく設定されていることを確認します
+ AppSpec ファイルの形式を確認します。詳細については、「[CodeDeploy 用のアプリケーション仕様ファイルをリビジョンに追加](application-revisions-appspec-file.md)」および「[CodeDeploy AppSpec ファイルのリファレンス](reference-appspec-file.md)」を参照してください。
+ GitHub レポジトリで Amazon S3 バケットを調べ、アプリケーションリビジョンが予期されている場所にあることを確認します。
+ CodeDeploy アプリケーションリビジョンの詳細を調べ、正しく登録されていることを確認します。詳細については、「[CodeDeploy を使用したアプリケーションリビジョン詳細の表示](application-revisions-view-details.md)」を参照してください。
+ Amazon S3 からデプロイする場合は、Amazon S3 バケットをチェックし、アプリケーションリビジョンをダウンロードするアクセス許可が CodeDeploy に付与されていることを確認します。バケットポリシーの詳細については、[デプロイの前提条件](deployments-create-prerequisites.md) を参照してください。
+ GitHub からデプロイする場合、GitHub リポジトリをチェックし、アプリケーションリビジョンをダウンロードするアクセス許可が CodeDeploy に付与されていることを確認します。詳細については、「[CodeDeploy でデプロイを作成する](deployments-create.md)」および「[CodeDeploy のアプリケーションを使用した GitHub の認証](integrations-partners-github.md#behaviors-authentication)」を参照してください。
1. サービスロールが正しく設定されているかどうかを確認します。詳細については、「[ステップ 2: CodeDeployのサービスのロールを作成する](getting-started-create-service-role.md)」を参照してください。
1. 「[CodeDeploy の開始方法](getting-started-codedeploy.md)」のステップに従って次の操作を行ったことを確認します。
+ 適切なアクセス許可を持つユーザーをプロビジョニングしました。
+ AWS CLIをインストールまたはアップグレードして設定する。
+ IAM インスタンスプロファイルとサービスロールを作成する。
詳細については、「[の ID とアクセスの管理 AWS CodeDeploy](security-iam.md)」を参照してください。
1. AWS CLI バージョン 1.6.1 以降を使用していることを確認します。インストールしたバージョンを確認するには、**aws --version** を呼び出します。
それでも失敗したデプロイをトラブルシューティングできない場合は、このトピックの他の問題を確認します。
## CodeDeploy デプロイリソースは、一部の AWS リージョンでのみ でサポートされています
または AWS CLI CodeDeploy コンソールからアプリケーション、デプロイグループ、インスタンス、またはその他のデプロイリソースが表示されないか、アクセスできない場合は、「」の AWS リージョン[とエンドポイント](https://docs.aws.amazon.com/general/latest/gr/rande.html#codedeploy_region)にリストされているリージョンのいずれかを参照していることを確認してください*AWS 全般のリファレンス*。
CodeDeploy デプロイで使用される EC2 インスタンスと Amazon EC2 Auto Scaling グループは、これらの AWS リージョンのいずれかで起動および作成する必要があります。
を使用している場合は AWS CLI、 から **aws configure** コマンドを実行します AWS CLI。その後、デフォルトの AWS リージョンを表示および設定できます。
CodeDeploy コンソールを使用している場合は、ナビゲーションバーのリージョンセレクタから、サポートされている AWS リージョンのいずれかを選択します。
**重要**
中国 (北京) リージョンまたは中国 (寧夏)でサービスを使用するには、そのリージョンのアカウントと認証情報が必要です。他の AWS リージョンのアカウントと認証情報は、北京および寧夏リージョンでは機能せず、その逆も同様です。
CodeDeploy リソースキットのバケット名や CodeDeploy エージェントのインストール手順など、中国リージョン向けのいくつかのリソースに関する情報は、今回の「*CodeDeploy ユーザーガイド*」には含まれていません。
詳細については:
*[中国 (北京) リージョンでの の開始方法 AWS の](http://docs.amazonaws.cn/en_us/aws/latest/userguide/introduction.html) *[CodeDeploy](http://docs.amazonaws.cn/en_us/aws/latest/userguide/codedeploy.html)
「*CodeDeploy User Guide for the China Regions* (中国リージョン向け CodeDeploy ユーザーガイド)」([英語版](http://docs.amazonaws.cn/en_us/codedeploy/latest/userguide/welcome.html) \$1 [中国語版](http://docs.amazonaws.cn/codedeploy/latest/userguide/welcome.html))
## このガイドの手順が CodeDeploy コンソールと一致しない
このガイドの手順は、新しいコンソールデザインで記述されています。古いバージョンのコンソールを使用した場合、古い概念が反映され、本ガイドの基本的な手順がそのまま適用されます。新しいコンソールのヘルプにアクセスするには、情報アイコンを選択します。
## 必要な IAM ロールを取得できない
AWS CloudFormation スタックの一部として作成された IAM インスタンスプロファイルまたはサービスロールに依存している場合、スタックを削除すると、すべての IAM ロールも削除されます。これが、IAM ロールが IAM コンソールに表示されなくなり、CodeDeploy が予期どおり動作しなくなる理由と考えられます。この問題を解決するには、削除された IAM ロールを再作成する必要があります。
## 何らかのテキストエディタを使用して AppSpec ファイルとシェルスクリプトを作成すると、デプロイが失敗する場合がある
テキストエディタによっては、不適合で非表示の文字がファイルに含まれる場合があります。テキストエディタを使用して AppSpec ファイルやシェルスクリプトファイルを作成または変更し、Amazon Linux、Ubuntu Server、または RHEL インスタンスで実行する場合、これらのファイルに依存するデプロイは失敗する可能性があります。CodeDeploy がこれらのファイルをデプロイ中に使用したときに、このような文字が存在すると、トラブルシューティングが困難な AppSpec ファイルの検証エラーにつながり、スクリプトの実行が失敗する可能性があります。
CodeDeploy コンソールのデプロイのイベント詳細ページで、[**ログを表示する**] を選択します。(または AWS CLI 、 を使用して [get-deployment-instance](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-instance.html) コマンドを呼び出します。) `invalid character`、`command not found`、`file not found` のようなエラーを探します。
この問題に対処するには、次のことをお勧めします。
+ 改行 (`^M` 文字) などの非表示の文字を AppSpec ファイルとシェルスクリプトファイルに含めるテキストエディタは使用しない。
+ AppSpec ファイルやシェルスクリプトファイルで改行など非表示の文字を表示するテキストエディタを使用して、対象となる可能性のある文字を見つけ、削除できるようにする。このようなタイプのテキストエディタの例については、インターネットで「改行を表示するテキストエディタ」を検索します。
+ Amazon Linux、Ubuntu サーバー、または RHEL インスタンスで動作するテキストエディタを使用して、Amazon Linux、Ubuntu サーバー、または RHEL インスタンスで動作するシェルスクリプトファイルを作成してください。このようなタイプのテキストエディタの例については、インターネットで「Linux シェルスクリプトエディタ」を検索します。
+ Windows または macOS でテキストエディタを使用して、Amazon Linux、Ubuntu Server、 または RHEL インスタンスで実行するシェルスクリプトファイルを作成する場合は、Windows または macOS 形式のテキストを Unix 形式に変換するプログラムまたはユーティリティを使用する。このようなプログラムとユーティリティの例については、インターネットで「DOS から UNIX へ」または「Mac から UNIX へ」を検索します。必ず、ターゲットのオペレーティングシステムで、変換されたシェルスクリプトファイルをテストします。
## macOS の Finder を使用してアプリケーションリビジョンをバンドルすると、デプロイが失敗することがある
Mac の Finder グラフィカルユーザーインタフェース (GUI) アプリケーションを使用して、AppSpec ファイルおよび関連ファイルとスクリプトをアプリケーションリビジョンのアーカイブ (.zip) ファイルにバンドル (zip) すると、デプロイが失敗する場合があります。これは、Finder が .zip ファイルに中間の `__MACOSX` フォルダを作成し、そこにコンポーネントファイルを配置するためです。CodeDeploy はコンポーネントファイルを見つけることができないため、デプロイは失敗します。
この問題に対処するには、 を使用して [push](https://docs.aws.amazon.com/cli/latest/reference/deploy/push.html) コマンド AWS CLI を呼び出し、コンポーネントファイルを期待される構造に圧縮することをお勧めします。または、GUI の代わりにターミナルを使用してコンポーネントファイルを zip 圧縮できます。ターミナルでは、中間の `__MACOSX` フォルダは作成されません。
# EC2/オンプレミスのデプロイに関する問題のトラブルシューティング
**Topics**
+ [CodeDeploy プラグイン CommandPoller の認証情報不足エラー](#troubleshooting-agent-commandpoller-error)
+ [「PKCS7 署名メッセージの検証に失敗しました」というメッセージでデプロイが失敗する](#troubleshooting-deployments-agent-SHA-256)
+ [同じデプロイ先のインスタンスに対する同じファイルのデプロイや再デプロイは失敗し、「指定したファイルはこの場所に既に存在するため、デプロイに失敗しました」というエラーが返されます。](#troubleshooting-same-files-different-app-name)
+ [ファイルパスが長いと、「そのようなファイルまたはディレクトリはありません」というエラーが発生します](#troubleshooting-long-file-paths)
+ [長時間実行されているプロセスにより、デプロイが失敗することがある](#troubleshooting-long-running-processes)
+ [AllowTraffic ライフサイクルイベントが失敗し、デプロイログにエラーが報告されない場合のトラブルシューティング](#troubleshooting-deployments-allowtraffic-no-logs)
+ [失敗した ApplicationStop、BeforeBlockTraffic、または AfterBlockTraffic デプロイライフサイクルイベントのトラブルシューティング](#troubleshooting-deployments-lifecycle-event-failures)
+ [「不明なエラー: 読み取り用に開いていません」で失敗した DownloadBundle デプロイライフサイクルイベントのトラブルシューティング](#troubleshooting-deployments-downloadbundle)
+ [スキップされたすべてのライフサイクルイベントのエラーをトラブルシューティングする](#troubleshooting-skipped-lifecycle-events)
+ [Windows PowerShell スクリプトで、デフォルトで 64 ビットバージョンの Windows PowerShell スクリプトを使用できない](#troubleshooting-deployments-powershell)
**注記**
多くのデプロイ失敗の原因は、デプロイプロセス中に作成されたログファイルを確認して特定できます。分かりやすいように、インスタンス別に表示するのではなく、Amazon CloudWatch Logs を使用してログファイルを集中的にモニタリングすることをお勧めします。詳細については、「[CloudWatch Logs コンソールで CodeDeploy ログを見る](https://aws.amazon.com/blogs/devops/view-aws-codedeploy-logs-in-amazon-cloudwatch-console/)」を参照してください。
**ヒント**
EC2/オンプレミスデプロイに関連する多くのトラブルシューティングタスクを自動化するランブックについては、「*AWS Systems Manager オートメーションランブックリファレンス*」の「[AWSSupport-TroubleshootCodeDeploy](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-troubleshootcodedeploy.html)」を参照してください。
## CodeDeploy プラグイン CommandPoller の認証情報不足エラー
`InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Missing credentials - please check if this instance was started with an IAM instance profile` のようなエラーが表示された場合は、次のいずれがが原因の可能性があります。
+ デプロイ先のインスタンスに、関連付けられている IAM インスタンスプロファイルがない。
+ IAM インスタンスプロファイルに、適切なアクセス許可が設定されていない。
IAM インスタンスプロファイルによって、CodeDeploy と通信し、リビジョンを Amazon S3 からダウンロードするためのアクセス許可が CodeDeploy エージェントに付与されている。EC2 インスタンスの場合は、「[の ID とアクセスの管理 AWS CodeDeploy](security-iam.md)」を参照してください。オンプレミスインスタンスの場合は、[CodeDeploy 用のオンプレミスインスタンスを用いての作業](instances-on-premises.md) を参照してください。
## 「PKCS7 署名メッセージの検証に失敗しました」というメッセージでデプロイが失敗する
このエラーメッセージは、SHA-1 ハッシュアルゴリズムのみをサポートするバージョンの CodeDeploy エージェントをインスタンスが実行していることを示します。SHA-2 ハッシュアルゴリズムのサポートは、2015 年 11 月にリリースされたバージョン 1.0.1.854 の CodeDeploy エージェントで導入されました。2016 年 10 月 17 日から、バージョン 1.0.1.854 以前の CodeDeploy エージェントがインストールされている場合、デプロイは失敗します。詳細については、「[AWS SSL 証明書のハッシュアルゴリズムを SHA256 に変更すること](https://aws.amazon.com/security/security-bulletins/aws-to-switch-to-sha256-hash-algorithm-for-ssl-certificates/)」、「[NOTICE: バージョン 1.0.1.85 より古い CodeDeploy ホストエージェントを使用停止にする](https://forums.aws.amazon.com/thread.jspa?threadID=223319)」、および「[CodeDeploy エージェントを更新する](codedeploy-agent-operations-update.md)」を参照してください。
## 同じデプロイ先のインスタンスに対する同じファイルのデプロイや再デプロイは失敗し、「指定したファイルはこの場所に既に存在するため、デプロイに失敗しました」というエラーが返されます。
CodeDeploy でファイルをデプロイしようとして、指定したデプロイ先のインスタンスに同じファイルが既に存在している場合、そのインスタンスへのデプロイは失敗する場合があります。「指定したファイルはこの場所 (*location-name*) に既に存在しているため、デプロイに失敗しました」というエラーメッセージが返される場合があります。このエラーが発生するのは、デプロイごとに CodeDeploy では最初にクリーンアップログファイルにリストされているすべてのファイルを以前のデプロイから削除するためです。このクリーンアップファイルにリストされていないファイルがデプロイ先のフォルダにあると、CodeDeploy エージェントでは、デフォルトでこれをエラーと解釈し、デプロイを失敗させます。
**注記**
Amazon Linux、RHEL、および Ubuntu Server の各インスタンスでは、クリーンアップファイルは `/opt/codedeploy-agent/deployment-root/deployment-instructions/` にあります。Windows Server インスタンスでは、場所は `C:\ProgramData\Amazon\CodeDeploy\deployment-instructions\` です。
このエラーを最も簡単に回避するには、デプロイを失敗させるデフォルト動作とは別のオプションを指定します。デプロイごとに、デプロイを失敗させるか、クリーンアップファイルにリストされていないファイルを上書きするか、インスタンスの既存ファイルを保持するかを選択できます。
上書きオプションは、最後のデプロイ後に手動でインスタンスに追加した同じ名前のファイルを、次回のアプリケーションリビジョンにも追加する場合などに便利です。
保持オプションは、次回のデプロイでインスタンスに追加するファイルを、アプリケーションリビジョンパッケージには追加する必要がない場合に選択できます。保持オプションは、アプリケーションファイルが既に本番稼働環境にあり、これらを CodeDeploy を使用して初めてデプロイする場合にも便利です。詳細については、「[EC2/オンプレミスコンピューティングプラットフォームのデプロイ作成 (コンソール)](deployments-create-console.md)」および「[既存のコンテンツでのロールバック動作](deployments-rollback-and-redeploy.md#deployments-rollback-and-redeploy-content-options)」を参照してください。
### `The deployment failed because a specified file already exists at this location` デプロイメント失敗のトラブルシューティング
CodeDeploy がデプロイ先で検出したコンテンツを上書きまたは保持するオプションを指定しない場合 (または既存のコンテンツを処理するデプロイオプションをプログラムによるコマンドで指定しない場合)、エラーのトラブルシューティングを行うことを選択できます。
次の情報は、コンテンツを保持または上書きしないことを選択した場合にのみ該当します。
同じ名前と場所のファイルの再デプロイを試みる場合、以前に使用した基になるデプロイグループ ID のアプリケーション名およびデプロイグループを指定すると、成功する可能性が高まります。CodeDeploy は、基になるデプロイグループ ID を使用して、再デプロイする前に削除するファイルを識別します。
新しいファイルのデプロイや、インスタンスの同じ場所への同じファイルの再デプロイは、次の理由により失敗することがあります。
+ 同じリビジョンの同じインスタンスへの再デプロイのため、別のアプリケーション名を指定した。デプロイグループ名が同じでも、別のアプリケーション名を使用すると、基になる別のデプロイグループ ID が使用されるため、再デプロイは失敗します。
+ アプリケーションのデプロイグループを削除して再作成し、同じリビジョンをデプロイグループに対して再デプロイしようとした。デプロイグループ名が同じでも、CodeDeploy は基になるデプロイグループ ID を参照するため、再デプロイは失敗します。
+ CodeDeploy のアプリケーションとデプロイグループを削除し、削除したものと同じ名前の新しいアプリケーションとデプロイグループを作成した。その後、以前のデプロイグループにデプロイされていたリビジョンを、同じ名前の新しいデプロイグループに再デプロイしようとした。アプリケーション名とデプロイグループ名が同じであっても、CodeDeploy は削除したデプロイグループの ID を引き続き参照するため、再デプロイは失敗します。
+ リビジョンをデプロイグループにデプロイし、同じリビジョンを同じインスタンスの別のデプロイグループにデプロイした。CodeDeploy は別の基になるデプロイグループ ID を参照するため、2 番目のデプロイは失敗します。
+ リビジョンを 1 つのデプロイグループにデプロイし、別のリビジョンを同じインスタンスの別のデプロイグループにデプロイした。2 番目のデプロイグループがデプロイを試みる同じ名前と場所のファイルが、少なくとも 1 つある。CodeDeploy は 2 番目のデプロイが開始される前に既存のファイルを削除しないため、2 番目のデプロイは失敗します。両方のデプロイは、異なるデプロイグループ ID を参照します。
+ CodeDeploy でリビジョンデプロイしたが、同じ名前と場所のファイルが少なくとも 1 つある。デフォルトでは、CodeDeploy はデプロイが開始される前に既存のファイルを削除しないため、デプロイは失敗します。
これらの状況に対応するには、次のいずれかを実行します。
+ 以前のデプロイされた場所とインスタンスからファイルを削除してから、もう一度デプロイを試みます。
+ リビジョンの AppSpec ファイルで、ApplicationStop または BeforeInstall デプロイライフサイクルイベントのいずれかにおいて、リビジョンでインストールするファイルと一致するファイルがいずれかの場所にある場合、これらを削除するためのカスタムスクリプトを指定します。
+ 以前のデプロイの一部ではない場所またはインスタンスにファイルをデプロイまたは再デプロイします。
+ アプリケーションまたはデプロイグループを削除する前に、インスタンスにコピーするファイルを指定しない AppSpec ファイル を含むリビジョンをデプロイします。このデプロイの場合、削除しようとしているものと同じ、基になるアプリケーションおよびデプロイグループ ID を使用するアプリケーション名とデプロイグループ名を指定します ([get-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-group.html) コマンドで、デプロイグループ ID を取得することができます。) CodeDeploy は、基になるデプロイグループ ID と AppSpec ファイルを使用して、前回成功したデプロイでインストールしたすべてのファイルを削除します。
## ファイルパスが長いと、「そのようなファイルまたはディレクトリはありません」というエラーが発生します
Windows インスタンスへのデプロイでは、appspec.yml ファイルのファイルセクションに 260 文字を超えるファイルパスがあると、デプロイが次のようなエラーで失敗することがあります。
`No such file or directory @ dir_s_mkdir - C:\your-long-file-path`
このエラーは、[Microsoft のドキュメント](https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=powershell#enable-long-paths-in-windows-10-version-1607-and-later)に詳述されているように、Windows ではデフォルトで 260 文字を超えるファイルパスが許可されていないために発生します。
CodeDeploy エージェントバージョン 1.4.0 以降では、エージェントのインストールプロセスに応じて、次の 2 つの方法で長いファイルパスを有効にできます。
CodeDeploy エージェントがまだインストールされていない場合:
1. CodeDeploy エージェントをインストールする予定のマシンで、次のコマンドを使用して `LongPathsEnabled` Windows レジストリキーを有効にします。
```
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem"
-Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force
```
1. CodeDeploy エージェントをインストールします。詳細については、「[CodeDeploy エージェントをインストールする](codedeploy-agent-operations-install.md)」を参照してください。
CodeDeploy エージェントがすでにインストールされている場合:
1. CodeDeploy エージェントマシンで、次のコマンドを使用して `LongPathsEnabled` Windows レジストリキーを有効にします。
```
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem"
-Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force
```
1. CodeDeploy エージェントを再起動して、レジストリキーの変更を有効にします。エージェントを再起動するには、次のコマンドを使用します。
```
powershell.exe -Command Restart-Service -Name codedeployagent
```
## 長時間実行されているプロセスにより、デプロイが失敗することがある
Amazon Linux、Ubuntu Server、RHEL インスタンスへのデプロイでは、長時間実行されるプロセスを開始するデプロイスクリプトがある場合、CodeDeploy はデプロイライフサイクルイベントでの待機に長い時間がかかり、その後デプロイに失敗することがあります。これは、そのイベントのフォアグラウンドおよびバックグラウンドで予期されるよりも長くプロセスが実行される場合、プロセスがまだ予期どおり実行されていても、CodeDeploy によってデプロイは中止され、失敗するためです。
たとえば、アプリケーションリビジョンのルートに 2 つのファイル (`after-install.sh` および `sleep.sh`) が含まれているとします。その AppSpec ファイルファイル には次の指示が含まれています。
```
version: 0.0
os: linux
files:
- source: ./sleep.sh
destination: /tmp
hooks:
AfterInstall:
- location: after-install.sh
timeout: 60
```
`after-install.sh` ファイルは AfterInstall アプリケーションライフサイクルイベント中に実行されます。そのコンテンツは次のとおりです。
```
#!/bin/bash
/tmp/sleep.sh
```
`sleep.sh` ファイルには以下が含まれます。これはプログラムの実行を 3 分 (180 秒) 停止し、長時間実行されるプロセスをシミュレートします。
```
#!/bin/bash
sleep 180
```
`after-install.sh` が `sleep.sh` を呼び出すと、`sleep.sh` が起動し、3 分 (180 秒) 実行します。これは CodeDeploy が `sleep.sh` (および関連で `after-install.sh`) の実行を停止させると予期した時間を 2 分 (120 秒) 経過した時間です。1 分 (60 秒) のタイムアウト後、`sleep.sh` は予期どおり実行を継続しますが、CodeDeploy は停止し、AfterInstall アプリケーションライフサイクルイベントでデプロイに失敗します。次のエラーが表示されます。
`Script at specified location: after-install.sh failed to complete in 60 seconds`.
単純に `&` でアンパサンド (`after-install.sh`) を追加して、バックグラウンドで `sleep.sh` を実行することはできません。
```
#!/bin/bash
# Do not do this.
/tmp/sleep.sh &
```
この操作を行うと、デプロイは最大でデフォルトの 1 時間のデプロイライフサイクルイベントのタイムアウト期間まで保留状態になり、その後 CodeDeploy は以前のように AfterInstall アプリケーションライフサイクルイベントでデプロイを停止し、失敗させます。
`after-install.sh` で、次のように `sleep.sh` を呼び出します。これにより、CodeDeploy はプロセスの実行開始後に続行できます。
```
#!/bin/bash
/tmp/sleep.sh > /dev/null 2> /dev/null < /dev/null &
```
前の呼び出しで、`sleep.sh` はバックグラウンドで実行を開始し、stdout、stderr、および stdin を `/dev/null` にリダイレクトするプロセスの名前です。
## AllowTraffic ライフサイクルイベントが失敗し、デプロイログにエラーが報告されない場合のトラブルシューティング
AllowTraffic ライフサイクルイベント中に Blue/Green デプロイが失敗しても、デプロイログに失敗の原因が表示されない場合があります。
通常、この障害は、デプロイグループへのトラフィック管理に使用される Classic Load Balancer、Application Load Balancer、または Network Load Balancer の Elastic Load Balancing のヘルスチェックが間違って設定されていることが原因です。
この問題を解決するには、ロードバランサーのヘルスチェックの設定エラーを確認して修正します。
Classic Load Balancer については、「*Classic Load Balancer のユーザーガイド*」の 「[Configure health checks for your Classic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-healthchecks.html) (Classic Load Balancer のヘルスチェックの設定)」、および「*Elastic Load Balancing API リファレンスバージョン 2012-06-01*」の「[ConfigureHealthCheck](https://docs.aws.amazon.com/elasticloadbalancing/2012-06-01/APIReference/API_ConfigureHealthCheck.html)」を参照してください。
Application Load Balancer については、「*Application Load Balancer のユーザーガイド*」の「[ターゲットグループのヘルスチェック](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html)」を参照してください。
Network Load Balancer については、*Network Load Balancer ユーザーガイド* の「[ターゲットグループのヘルスチェック](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-health-checks.html)」を参照してください。
## 失敗した ApplicationStop、BeforeBlockTraffic、または AfterBlockTraffic デプロイライフサイクルイベントのトラブルシューティング
デプロイ時に、CodeDeploy エージェントは ApplicationStop、BeforeBlockTraffic、および AfterBlockTraffic に対して前回の正常なデプロイで AppSpec ファイルに指定されていたスクリプトを実行します。(他のすべてのスクリプトは、現在のデプロイの AppSpec ファイルから実行されます)。これらのスクリプトのいずれかにエラーがあって正常に実行されない場合、デプロイに失敗することがあります。
これらの失敗の原因としては以下のようなことが考えられます。
+ CodeDeploy エージェントは `deployment-group-id_last_successful_install` ファイルを正しい場所で見つけたが、`deployment-group-id_last_successful_install` ファイルにリストされている場所が存在しない。
**Amazon Linux、Ubuntu サーバー、および RHEL インスタンス** では、このファイルは `/opt/codedeploy-agent/deployment-root/deployment-instructions` に存在する必要があります。
**Windows Server インスタンスでは**、このファイルは `C:\ProgramData\Amazon\CodeDeploy\deployment-instructions` フォルダに保存されている必要があります。
+ `deployment-group-id_last_successful_install` ファイルに示された場所で、AppSpec ファイルが無効であるか、スクリプトが正常に実行されない。
+ スクリプトに修正できないエラーがあるため、正常に実行されることはありません。
CodeDeploy コンソールを使用して、これらのいずれかのイベント中にデプロイが失敗した理由を調査します。デプロイの詳細ページで、[**View events**] を選択します。インスタンスの詳細ページの [**ApplicationStop**] 行、[**BeforeBlockTraffic**] 行、または [**AfterBlockTraffic**] 行で、[**ログを表示する**] を選択します。または AWS CLI 、 を使用して [get-deployment-instance](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-instance.html) コマンドを呼び出します。
前回の正常なデプロイのスクリプトが正常に実行されないために失敗した場合は、デプロイを作成して [ApplicationStop]、[BeforeBlockTraffic]、および [AfterBlockTraffic] のエラーを無視するように指定します。これには、以下の 2 つの方法があります。
+ CodeDeploy コンソールを使用してデプロイを作成します。[**デプロイの作成**] ページの [**ApplicationStop ライフサイクルイベントの障害**] で、[**このインスタンス上のライフサイクルイベントの障害で、デプロイを失敗させない**] を選択します。
+ AWS CLI を使用して **[create-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html)** コマンドを呼び出し、 `--ignore-application-stop-failures`オプションを含めます。
アプリケーションリビジョンを再度デプロイすると、これら 3 つのライフサイクルイベントのいずれが失敗してもデプロイは続行されます。これらのライフサイクルイベントの修正済みスクリプトが新しいリビジョンに含まれている場合は、この修正を適用しなくても以降のデプロイは正常に実行されます。
## 「不明なエラー: 読み取り用に開いていません」で失敗した DownloadBundle デプロイライフサイクルイベントのトラブルシューティング
Amazon S3 からアプリケーションリビジョンをデプロイしようとして、DownloadBundle デプロイライフサイクルイベント中に「`UnknownError: not opened for reading`」というエラーでデプロイが失敗する場合:
+ Amazon S3 の内部サーバーエラーが発生しました。アプリケーションリビジョンをもう一度デプロイします。
+ EC2 インスタンスの IAM インスタンスプロファイルに、Amazon S3 のアプリケーションリビジョンにアクセスするアクセス許可がありません。Amazon S3 バケットポリシーの詳細については、「[Amazon S3 に CodeDeploy のリビジョンをプッシュする (EC2/オンプレミスのデプロイのみ)](application-revisions-push.md)」と「[デプロイの前提条件](deployments-create-prerequisites.md)」 を参照してください。
+ デプロイするインスタンスは 1 つの AWS リージョン (米国西部 (オレゴン) など) に関連付けられますが、アプリケーションリビジョンを含む Amazon S3 バケットは別の AWS リージョン (米国東部 (バージニア北部) など) に関連付けられます。アプリケーションリビジョンがインスタンスと同じ AWS リージョンに関連付けられている Amazon S3 バケットにあることを確認します。
デプロイのイベント詳細ページの [**Download bundle (バンドルのダウンロード)**] 行で、[**ログを表示する**] を選択します。または AWS CLI 、 を使用して [get-deployment-instance](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-instance.html) コマンドを呼び出します。このエラーが発生した場合、エラーコード「`UnknownError`」とエラーメッセージ「`not opened for reading`」のエラーが出力に表示されます。
このエラーの原因を特定するには:
1. インスタンスの少なくとも 1 つでワイヤログを有効にして、もう一度アプリケーションリビジョンをデプロイします。
1. ワイヤログファイルを調べてエラーを見つけます。この問題の一般的なエラーメッセージには、「access denied」という語句が含まれます。
1. ログファイルを確認した後、ワイヤログを無効にして、ログファイルサイズと、今後インスタンスでプレーンテキストで出力に表示される可能性がある機密情報の量を減らすことをお勧めします。
ワイヤログファイルを探し、ワイヤログを有効または無効にする方法については、「[CodeDeploy エージェント構成リファレンス](https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-agent-configuration.html)」の「`:log_aws_wire:`」を参照してください。
## スキップされたすべてのライフサイクルイベントのエラーをトラブルシューティングする
EC2 またはオンプレミスのデプロイのライフサイクルイベントがすべてスキップされた場合は、`The overall deployment failed because too many individual instances failed deployment, too few healthy instances are available for deployment, or some instances in your deployment group are experiencing problems. (Error code: HEALTH_CONSTRAINTS)` のようなエラーが表示されます。考えられる原因と解決策は次のとおりです。
+ CodeDeploy エージェントがインスタンスにインストールされていないか、インスタンスで実行されていない。CodeDeploy エージェントが実行されていることを確認するには:
+ Amazon Linux RHEL または Ubuntu server の場合は、以下を実行します。
```
systemctl status codedeploy-agent
```
+ Windows の場合は、以下を実行します。
```
powershell.exe -Command Get-Service -Name CodeDeployagent
```
CodeDeploy エージェントがインストールまたは実行されていない場合は、[CodeDeploy エージェントが実行されていることの確認](codedeploy-agent-operations-verify.md) を参照してください。
インスタンスがポート 443 を使用して CodeDeploy または Amazon S3 のパブリックエンドポイントに到達できない可能性があります。以下のいずれかを行ってください。
+ インスタンスにパブリック IP アドレスを割り当て、そのルートテーブルを使用してインターネットアクセスを許可します。インスタンスに関連付けられているセキュリティグループで、ポート 443 (HTTPS) 経由で送信アクセスが許可されていることを確認してください。詳細については、「[CodeDeploy エージェントの通信プロトコルとポート](codedeploy-agent.md#codedeploy-agent-outbound-port)」を参照してください。
+ インスタンスがプライベートサブネットにプロビジョニングされている場合は、ルートテーブルで、インターネットゲートウェイではなく NAT ゲートウェイを使用します。詳細については、「[NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)」を参照してください。
+ CodeDeploy のサービスロールに、必要なアクセス許可が付与されていない可能性があります。CodeDeploy サービスロールを設定するには、「[ステップ 2: CodeDeployのサービスのロールを作成する](getting-started-create-service-role.md)」を参照してください。
+ HTTP プロキシを使用している場合は、CodeDeploy エージェントの設定ファイルの `:proxy_uri:` 設定で指定されていることを確認してください。詳細については、「[CodeDeploy エージェント設定リファレンス](reference-agent-configuration.md)」を参照してください。
+ デプロイメントインスタンスの日時が、デプロイメントリクエストの日時と一致しない場合があります。CodeDeploy エージェントログファイルに、`Cannot reach InstanceService: Aws::CodeDeployCommand::Errors::InvalidSignatureException - Signature expired` のようなエラーがないか確認します。このエラーが表示されている場合は、[「InvalidSignatureException – Signature expired: [time] is now earlier than [time]」デプロイエラーのトラブルシューティング](troubleshooting-ec2-instances.md#troubleshooting-instance-time-failures) のステップに従います。詳細については、「[CodeDeploy EC2/オンプレミスデプロイのログデータの表示](deployments-view-logs.md)」を参照してください。
+ インスタンスのメモリまたはハードディスクの空き容量が不足しているため、CodeDeploy エージェントが停止している可能性があります。インスタンス上のアーカイブされたデプロイメントの数が減るように、CodeDeploy エージェントの `max_revisions` 設定を更新してください。EC2 インスタンスにこのプロセスを行っても問題が解決しない場合は、インスタンスのサイズを大きくすることを検討してください。たとえば、インスタンスタイプが `t2.small` の場合は、`t2.medium` の使用を検討します。詳細については、「[CodeDeploy エージェントでインストールされるファイル](codedeploy-agent.md#codedeploy-agent-install-files)」、「[CodeDeploy エージェント設定リファレンス](reference-agent-configuration.md)」、「[ インスタンスタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)」を参照してください。
+ デプロイ先のインスタンスに、IAM インスタンスプロファイルがアタッチされていないか、または必要なアクセス許可が付与されていない IAM インスタンスプロファイルがアタッチされている可能性があります。
+ IAM インスタンスプロファイルがインスタンスにアタッチされていない場合は、必要なアクセス許可を付与したインスタンスプロファイルを作成し、アタッチします。
+ IAM インスタンスプロファイルがインスタンスにすでにアタッチされている場合は、必要なアクセス許可があることを確認します。
必要なアクセス許可が付与されているインスタンスプロファイルがアタッチされていることを確認したら、インスタンスを再起動します。詳細については、*Amazon EC2 ユーザーガイド* の「[ステップ 4: Amazon EC2 インスタンス用の IAM インスタンスプロファイルを作成する](getting-started-create-iam-instance-profile.md)」と「[Amazon EC2 の IAM ロール](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-EC2.html)」を参照してください。
## Windows PowerShell スクリプトで、デフォルトで 64 ビットバージョンの Windows PowerShell スクリプトを使用できない
デプロイの一部として実行中の Windows PowerShell スクリプトが 64 ビットの機能に依存している場合 (たとえば、32 ビットアプリケーションで許可されるよりも多くのメモリを消費する、64 ビットバージョンのみで提供されるライブラリを呼び出すなど)、スクリプトはクラッシュするか、予期どおりに実行されない可能性があります。これは、CodeDeploy はデフォルトで 32 ビットバージョンの Windows PowerShell を使用して、アプリケーションリビジョンの一部である Windows PowerShell スクリプトを実行するためです。
64 ビットバージョンの Windows PowerShell で実行する必要があるスクリプトの先頭に、次のようなコードを追加します。
```
# Are you running in 32-bit mode?
# (\SysWOW64\ = 32-bit mode)
if ($PSHOME -like "*SysWOW64*")
{
Write-Warning "Restarting this script under 64-bit Windows PowerShell."
# Restart this script under 64-bit Windows PowerShell.
# (\SysNative\ redirects to \System32\ for 64-bit mode)
& (Join-Path ($PSHOME -replace "SysWOW64", "SysNative") powershell.exe) -File `
(Join-Path $PSScriptRoot $MyInvocation.MyCommand) @args
# Exit 32-bit script.
Exit $LastExitCode
}
# Was restart successful?
Write-Warning "Hello from $PSHOME"
Write-Warning " (\SysWOW64\ = 32-bit mode, \System32\ = 64-bit mode)"
Write-Warning "Original arguments (if any): $args"
# Your 64-bit script code follows here...
# ...
```
このコードのファイルパス情報を直観的にはわかりにくいかもしれませんが、32 ビットの Windows PowerShell では次のようなパスが使用されます。
`c:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe`
64 ビットの Windows PowerShell では次のようなパスが使用されます。
`c:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe`
# Amazon ECS のデプロイに関する問題のトラブルシューティング
**Topics**
+ [置き換えタスクセットを待っている間にタイムアウトが発生します](#troubleshooting-ecs-timeout)
+ [通知が継続されるのを待っている間のタイムアウトの発生](#troubleshooting-ecs-timeout-notif)
+ [IAM ロールに十分なアクセス許可がありません](#troubleshooting-ecs-iam)
+ [ステータスコールバックを待っている間に、デプロイがタイムアウトした](#troubleshooting-ecs-timeout-callback)
+ [1 つ以上のライフサイクルイベントの検証機能が失敗したため、デプロイが失敗しました](#troubleshooting-ecs-lifecycle)
+ [「プライマリタスクセットのターゲットグループはリスナーの後ろにある必要があります」というエラーのため、ELB を更新できませんでした](#troubleshooting-ecs-elb)
+ [Auto Scaling を使用するとデプロイが失敗することがあります](#troubleshooting-ecs-auto-scaling)
+ [ALB のみが段階的なトラフィックルーティングをサポートしているため、デプロイグループの作成/更新時には、代わりに AllAtOnce トラフィックルーティングを使用してください](#troubleshooting-ecs-lb)
+ [デプロイが成功しても、置き換えタスクセットは Elastic Load Balancing のヘルスチェックに失敗し、アプリケーションがダウンしています](#troubleshooting-ecs-task-set-stability)
+ [1 つのデプロイグループに複数のロードバランサーをアタッチできますか?](#troubleshooting-ecs-lb-multi)
+ [ロードバランサーなしで CodeDeploy のブルー/グリーンデプロイを実行できますか?](#troubleshooting-ecs-lb-bg)
+ [デプロイ中に Amazon ECS サービスを新しい情報で更新する方法を教えてください。](#troubleshooting-ecs-exec)
## 置き換えタスクセットを待っている間にタイムアウトが発生します
**問題**: CodeDeploy を使用して Amazon ECS アプリケーションをデプロイする際に、次のエラーメッセージが表示される。
`The deployment timed out while waiting for the replacement task set to become healthy. This time out period is 60 minutes.`
**考えられる原因**: このエラーは、タスク定義ファイルまたはその他のデプロイ関連ファイルに誤りがある場合に発生する可能性があります。例えば、タスク定義ファイルの `image` フィールドにタイプミスがあると、Amazon ECS は間違ったコンテナイメージを取得しようとして失敗し続けるため、このエラーが発生します。
**解決方法と次のステップ**:
+ タスク定義ファイルやその他のファイルの入力ミスや設定の問題を修正します。
+ 関連する Amazon ECS サービスイベントをチェックして、置き換えタスクが正常に動作しない理由を調べます。Amazon ECS イベントに関する詳細については、「Amazon Elastic Container Service デベロッパーガイド**」の「[Amazon ECS イベント](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)」を参照してください。
+ Amazon Elastic Container Service デベロッパーガイド**の「[Amazon ECS トラブルシューティング](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html)」セクションで、イベント内のメッセージに関連するエラーについて参照してください。
## 通知が継続されるのを待っている間のタイムアウトの発生
**問題**: CodeDeploy を使用して Amazon ECS アプリケーションをデプロイする際に、次のエラーメッセージが表示される。
`The deployment timed out while waiting for a notification to continue. This time out period is n minutes.`
**考えられる原因**: このエラーは、デプロイグループの作成時に **[トラフィックを再ルーティングするタイミングを指定します]** フィールドで待機時間を指定したものの、待機時間が経過する前にデプロイを完了できなかった場合に発生する可能性があります。
**解決方法と次のステップ**:
+ デプロイグループで、**[トラフィックを再ルーティングするタイミングを指定します]** をより長い時間に設定して再デプロイします。詳細については、「[Amazon ECS デプロイ用のデプロイグループを作成する (コンソール)](deployment-groups-create-ecs.md)」を参照してください。
+ デプロイグループで、[**トラフィックを再ルーティングするタイミングを指定します**] を [**すぐにトラフィックを再ルーティング**] に変更して、再デプロイします。詳細については、「[Amazon ECS デプロイ用のデプロイグループを作成する (コンソール)](deployment-groups-create-ecs.md)」を参照してください。
+ 再デプロイし、 `--deployment-wait-type`オプションを に設定して [https://docs.aws.amazon.com/cli/latest/reference/deploy/continue-deployment.html](https://docs.aws.amazon.com/cli/latest/reference/deploy/continue-deployment.html) AWS CLI コマンドを実行します`READY_WAIT`。[**トラフィックを再ルーティングするタイミングを指定します**] で指定した時間が経過する*前に*、このコマンドを必ず実行してください。
## IAM ロールに十分なアクセス許可がありません
**問題**: CodeDeploy を使用して Amazon ECS アプリケーションをデプロイしている際に、次のエラーメッセージが表示されます。
`The IAM role role-arn does not give you permission to perform operations in the following AWS service: AWSLambda.`
**考えられる原因**: このエラーは、[AppSpec ファイルの `Hooks` セクション](reference-appspec-file-structure-hooks.md#appspec-hooks-ecs)で Lambda 関数を指定したが、Lambda サービスに CodeDeploy アクセス許可を付与しなかった場合に発生する可能性があります。
**解決方法**: CodeDeploy サービスロールに `lambda:InvokeFunction` アクセス許可を追加します。このアクセス許可を追加するには、**AWSCodeDeployRoleForECS** か **AWSCodeDeployRoleForECSLimited** の AWSマネージドポリシーのいずれかをロールに追加します。これらのポリシーと、ポリシーを CodeDeploy サービスロールに追加する方法については、「[ステップ 2: CodeDeployのサービスのロールを作成する](getting-started-create-service-role.md)」を参照してください。
## ステータスコールバックを待っている間に、デプロイがタイムアウトした
**問題**: CodeDeploy を使用して Amazon ECS アプリケーションをデプロイしている際に、次のエラーメッセージが表示されます。
`The deployment timed out while waiting for a status callback. CodeDeploy expects a status callback within one hour after a deployment hook is invoked.`
**考えられる原因**: このエラーは、[AppSpec ファイルの `Hooks` セクション](reference-appspec-file-structure-hooks.md#appspec-hooks-ecs)で Lambda 関数を指定したが、Lambda 関数が CodeDeploy に `Succeeded` または `Failed` ステータスを返すのに必要な `PutLifecycleEventHookExecutionStatus` API を呼び出せなかった場合に発生する可能性があります。
**解決方法と次のステップ:**
+ AppSpec ファイルで指定した Lambda 関数が使用する Lambda 実行ロールに `codedeploy:putlifecycleEventHookExecutionStatus` アクセス許可を追加します。このアクセス許可により、Lambda 関数には CodeDeploy に `Succeeded` または `Failed` のステータスを返すアクセス許可が付与されます。Lambda 実行ロールの詳細については、「AWS Lambda ユーザーガイド**」の「[Lambda 実行ロール](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)」を参照してください。
+ Lambda 関数のコードと実行ログを確認して、Lambda 関数が CodeDeploy の `PutLifecycleEventHookExecutionStatus` API を呼び出して、ライフサイクル検証テストが `Succeeded` か `Failed` であるかを CodeDeploy に通知していることを確認します。`putlifecycleEventHookExecutionStatus` API の詳細については、「AWS CodeDeploy API リファレンス**」の「[PutLifecycleEventHookExecutionStatus](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_PutLifecycleEventHookExecutionStatus.html)」を参照してください。Lambda 実行ログの詳細については、「[AWS Lambdaでの Amazon CloudWatch Logs の使用](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html)」を参照してください。
## 1 つ以上のライフサイクルイベントの検証機能が失敗したため、デプロイが失敗しました
**問題**: CodeDeploy を使用して Amazon ECS アプリケーションをデプロイしている際に、次のエラーメッセージが表示されます。
`The deployment failed because one or more of the lifecycle event validation functions failed.`
**考えられる原因**: このエラーは、[AppSpec ファイルの `Hooks` セクション](reference-appspec-file-structure-hooks.md#appspec-hooks-ecs)で Lambda 関数を指定したが、Lambda 関数が `PutLifecycleEventHookExecutionStatus` を呼び出した際に CodeDeploy に `Failed` を返した場合に発生する可能性があります。この失敗は、ライフサイクル検証テストが失敗したことを CodeDeploy に示します。
**考えられる次のステップ**: Lambda 実行ログを確認して、検証テストコードが失敗している理由を確認します。Lambda 実行ログの詳細については、「[AWS Lambdaでの Amazon CloudWatch Logs の使用](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html)」を参照してください。
## 「プライマリタスクセットのターゲットグループはリスナーの後ろにある必要があります」というエラーのため、ELB を更新できませんでした
**問題**: CodeDeploy を使用して Amazon ECS アプリケーションをデプロイしている際に、次のエラーメッセージが表示されます。
`The ELB could not be updated due to the following error: Primary taskset target group must be behind listener`
**考えられる原因**:このエラーは、オプションのテストリスナーを設定しており、そのリスナーに間違ったターゲットグループが設定されている場合に発生する可能性があります。CodeDeploy のテストリスナーの詳細については、「[Amazon ECS デプロイを開始する前に](deployment-steps-ecs.md#deployment-steps-prerequisites-ecs)」と「[Amazon ECS デプロイ中の処理で起こっていること](deployment-steps-ecs.md#deployment-steps-what-happens)」を参照してください。タスクセットの詳細については、「Amazon Elastic Container Service API リファレンス**」の「[TaskSet](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_TaskSet.html)」と、「*AWS CLI コマンドリファレンス*」の「Amazon ECS」セクションの「[describe-task-set](https://docs.aws.amazon.com/cli/latest/reference/ecs/describe-task-set.html)」を参照してください。
**考えられる解決方法**: Elastic Load Balancing の本稼働リスナーとテストリスナーの両方が、現在ワークロードを処理しているターゲットグループを指していることを確認します。確認すべき箇所は 3 つあります。
+ Amazon EC2 のロードバランサーの「**リスナーとルール**」の設定。詳細については、「Application Load Balancer のユーザーガイド**」の「[Application Load Balancer のリスナー](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html)」、または「Network Load Balancer のユーザーガイド**」の「[Network Load Balancer のリスナー](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-listeners.html)」を参照してください。
+ Amazon ECS のクラスター内のサービスの**ネットワーク**設定。詳細については、「Amazon Elastic Container Service デベロッパーガイド**」の「[Application Load Balancerおよび Network Load Balancerの場合](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/load-balancer-types.html#alb-considerations)」を参照してください。
+ CodeDeploy のデプロイグループ設定。詳細については、「[Amazon ECS デプロイ用のデプロイグループを作成する (コンソール)](deployment-groups-create-ecs.md)」を参照してください。
## Auto Scaling を使用するとデプロイが失敗することがあります
**問題**: CodeDeploy で Auto Scaling を使用中、デプロイが失敗することがあることに気付きました。この問題の症状の詳細については、「Amazon Elastic Container Service デベロッパーガイド**」の「[サービスの自動スケーリングと ブルー/グリーンデプロイタイプを使用するように設定されたサービスでは、自動スケーリングはデプロイ中にブロックされませんが、状況によってはデプロイが失敗する場合があります](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-bluegreen.html#deployment-type-bluegreen-considerations)」というトピックを参照してください。
**考えられる原因**: この問題は、CodeDeploy プロセスと Auto Scaling プロセスが競合する場合に発生する可能性があります。
**解決方法**: `RegisterScalableTarget` API (または対応する`register-scalable-target` AWS CLI コマンド) を使用して CodeDeploy デプロイ中に Auto Scaling プロセスを一時停止および再開します。詳細については、「Application Auto Scaling ユーザーガイド**」の「[Application Auto Scaling のスケーリングの一時停止と再開](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-suspend-resume-scaling.html)」を参照してください。
**注記**
CodeDeploy は `RegisterScaleableTarget` を直接呼び出すことはできません。この API を使用するには、Amazon Simple Notification Service (または Amazon CloudWatch) に通知またはイベントを送信するように CodeDeploy を設定する必要があります。次に、Lambda 関数を呼び出すように Amazon SNS (または CloudWatch) を設定し、`RegisterScalableTarget` API を呼び出すように Lambda 関数を設定する必要があります。Auto Scaling オペレーションを一時停止するには `SuspendedState` パラメータを`true` に設定し、再開するには `false` に設定し、`RegisterScalableTarget` API を呼び出す必要があります。
CodeDeploy が送信する通知またはイベントは、デプロイが開始したとき (Auto Scaling の一時停止オペレーションをトリガーする場合)、またはデプロイが成功したとき、失敗したとき、または停止したとき (Auto Scaling 再開オペレーションをトリガーする場合) に発生する必要があります。
Amazon SNS 通知または CloudWatch イベントを生成するように CodeDeploy を設定する方法については、「[Amazon CloudWatch Events を使用したデプロイのモニタリング](monitoring-cloudwatch-events.md)」と「[Amazon SNS イベント通知を使用したデプロイのモニタリング](monitoring-sns-event-notifications.md)」を参照してください。
## ALB のみが段階的なトラフィックルーティングをサポートしているため、デプロイグループの作成/更新時には、代わりに AllAtOnce トラフィックルーティングを使用してください
**問題**: CodeDeploy でデプロイグループを作成または更新している際に、次のエラーメッセージが表示されます。
`Only ALB supports gradual traffic routing, use AllAtOnce Traffic routing instead when you create/update Deployment group.`
**考えられる原因**: このエラーは Network Load Balancer を使用していて、`CodeDeployDefault.ECSAllAtOnce` 以外の事前定義されたデプロイ設定を使用しようとした場合に発生する可能性があります。
**解決方法:**
+ 事前定義されたデプロイ設定を `CodeDeployDefault.ECSAllAtOnce` に変更します。これは Network Load Balancer がサポートする唯一の事前定義されたデプロイ設定です。
事前定義されたデプロイ設定の詳細については、「[Amazon ECS コンピューティングプラットフォームの事前定義されたデプロイ設定](deployment-configurations.md#deployment-configurations-predefined-ecs)」を参照してください。
+ ロードバランサーを Application Load Balancer に変更します。Application Load Balancer は、事前定義されたデプロイ設定をすべてサポートします。Application Load Balancer の作成の詳細については、「[CodeDeploy Amazon ECS デプロイ用のロードバランサー、ターゲットグループ、リスナーをセットアップする](deployment-groups-create-load-balancer-for-ecs.md)」を参照してください。
## デプロイが成功しても、置き換えタスクセットは Elastic Load Balancing のヘルスチェックに失敗し、アプリケーションがダウンしています
**問題**: CodeDeploy ではデプロイが成功したと表示されているのに、置き換えタスクセットは Elastic Load Balancing からのヘルスチェックに失敗し、アプリケーションがダウンしています。
**考えられる原因**: この問題は、CodeDeploy 一括デプロイを実行した際に、置き換え (グリーン) タスクセットに Elastic Load Balancing ヘルスチェックが失敗する原因となる誤ったコードが含まれている場合に発生する可能性があります。1 回にすべてのデプロイ設定では、トラフィックが置き換えタスクセットに移行した*後* (つまり、CodeDeploy の `AllowTraffic` ライフサイクルイベントが発生した*後*)、ロードバランサーのヘルスチェックが置き換えタスクセットで実行され始めます。そのため、トラフィックが移行した後は置き換えタスクセットでヘルスチェックが失敗しますが、それ以前には失敗しません。CodeDeploy が生成するライフサイクルイベントについては、「[Amazon ECS デプロイ中の処理で起こっていること](deployment-steps-ecs.md#deployment-steps-what-happens)」を参照してください。
**解決方法:**
+ デプロイ設定を 1 回にすべてから canary またはリニアに変更します。canary 設定またはリニア設定では、CodeDeploy が置き換え先環境にアプリケーションをインストールしている間、およびトラフィックが移行される*前* (つまり、`Install` ライフサイクルイベント中および `AllowTraffic` イベント*前*) に、ロードバランサーのヘルスチェックが置き換えタスクセットで実行を開始します。アプリケーションのインストール中、トラフィックが移行する前にチェックを実行できるようにすることで、アプリケーションが一般公開される前に誤ったアプリケーションコードが検出され、デプロイが失敗します。
canary デプロイまたはリニアデプロイを設定する方法については、「[CodeDeploy を使用して、デプロイグループの設定を変更します。](deployment-groups-edit.md)」を参照してください。
Amazon ECS のデプロイ中に実行される CodeDeploy ライフサイクルイベントの詳細については、「[Amazon ECS デプロイ中の処理で起こっていること](deployment-steps-ecs.md#deployment-steps-what-happens)」を参照してください。
**注記**
canary デプロイ設定およびリニアデプロイ設定は、Application Load Balancer でのみサポートされます。
+ 1 回にすべてデプロイ設定を維持したい場合は、テストリスナーをセットアップし、`BeforeAllowTraffic` ライフサイクルフックを使用して置き換えタスクセットのヘルスステータスを確認します。詳細については、「[Amazon ECS のデプロイ向けのライフサイクルイベントフックのリスト](reference-appspec-file-structure-hooks.md#reference-appspec-file-structure-hooks-list-ecs)」を参照してください。
## 1 つのデプロイグループに複数のロードバランサーをアタッチできますか?
いいえ。複数の Application Load Balancer または Network Load Balancer を使用する場合は、CodeDeploy ブルー/グリーンデプロイの代わりに Amazon ECS ローリング更新を使用してください。ローリング更新の詳細については、「Amazon Elastic Container Service デベロッパーガイド**」の「[ローリング更新](https://docs.aws.amazon.com/AmazonECS/latest/userguide/deployment-type-ecs.html)」を参照してください。Amazon ECS で複数のロードバランサーを使用する方法の詳細については、「Amazon Elastic Container Service デベロッパーガイド**」の「[サービスに複数のターゲットグループを登録する](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/register-multiple-targetgroups.html)」を参照してください。
## ロードバランサーなしで CodeDeploy のブルー/グリーンデプロイを実行できますか?
いいえ、ロードバランサーなしで CodeDeploy のブルー/グリーンデプロイを実行することはできません。ロードバランサーを使用できない場合は、代わりに Amazon ECS のローリング更新機能を使用してください。Amazon ECS のローリング更新機能の詳細については、「Amazon Elastic Container Service デベロッパーガイド**」の「[ローリング更新](https://docs.aws.amazon.com/AmazonECS/latest/userguide/deployment-type-ecs.html)」を参照してください。
## デプロイ中に Amazon ECS サービスを新しい情報で更新する方法を教えてください。
CodeDeploy がデプロイの実行中に Amazon ECS サービスを新しいパラメータで更新するようにするには、AppSpec ファイルの `resources` セクションでパラメータを指定します。CodeDeploy でサポートされている Amazon ECS パラメータは、タスク定義ファイルやコンテナ名パラメータなど、ごく一部です。CodeDeploy が更新できる Amazon ECS パラメータの一覧については、「[Amazon ECS デプロイ用の AppSpec の「resources」セクション](reference-appspec-file-structure-resources.md#reference-appspec-file-structure-resources-ecs)」を参照してください。
**注記**
CodeDeploy でサポートされていないパラメータで Amazon ECS サービスを更新する必要がある場合は、以下のタスクを実行します。
更新したいパラメータを指定して Amazon ECS の `UpdateService` API を呼び出します。更新できるパラメータの一覧については、「*Amazon Elastic Container Service API リファレンス*」の「[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)」を参照してください。
変更をタスクに適用するには、新しい Amazon ECS ブルー/グリーンデプロイを作成します。詳細については、「[Amazon ECS コンピューティングプラットフォームのデプロイの作成 (コンソール)](deployments-create-console-ecs.md)」を参照してください。
# AWS Lambda デプロイの問題のトラブルシューティング
**Topics**
+ [AWS Lambda ロールバックが設定されていない Lambda デプロイを手動で停止すると、デプロイは失敗します](#troubleshooting-manually-stopped-lambda-deployment)
## AWS Lambda ロールバックが設定されていない Lambda デプロイを手動で停止すると、デプロイは失敗します
場合によっては、デプロイで指定された Lambda 関数のエイリアスで、2 つの異なる関数バージョンが参照されることがあります。そのため、Lambda 関数をデプロイしようとすると失敗します。Lambda デプロイでは、ロールバックが設定されていない場合に手動で停止すると、この状態になることがあります。続行するには、 AWS Lambda コンソールを使用して、 関数が 2 つのバージョン間でトラフィックをシフトするように設定されていないことを確認します。
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/) で AWS Lambda コンソールを開きます。
1. 左側のペインで、[**関数**] を選択します。
1. CodeDeploy デプロイ内にある Lambda 関数の名前を選択します。
1. 「**エイリアス**」から、CodeDeploy デプロイで使用されているエイリアスを選択し、「**編集**」を選択します。
1. [**加重エイリアス**] から [**none**] を選択します。これにより、このエイリアスで、トラフィックの割合やウェイトが 2 つ以上のバージョンに移行されることはありません。[**バージョン**] で選択されているバージョンを書き留めます。
1. **[保存]** を選択します。
1. CodeDeploy コンソールを開き、ステップ 5 のドロップダウンメニューで表示されているバージョンをデプロイします。
# デプロイグループの問題のトラブルシューティング
## デプロイグループの一部としてインスタンスにタグを付けても、アプリケーションが自動的に新しいインスタンスにデプロイされない
CodeDeploy は新しくタグが付けられたインスタンスに自動的にアプリケーションをデプロイしません。デプロイグループで新しいデプロイを作成する必要があります。
CodeDeploy を使用すると、Amazon EC2 Auto Scaling グループの新しい EC2 インスタンスへの自動デプロイを有効にすることができます。詳細については、「[CodeDeploy と Amazon EC2 Auto Scaling の統合](integrations-aws-auto-scaling.md)」を参照してください。
# インスタンスの問題のトラブルシューティング
**Topics**
+ [タグは正しく設定する必要がある](#troubleshooting-EC2-tags)
+ [AWS CodeDeploy エージェントはインスタンスにインストールして実行する必要があります](#troubleshooting-sds-agent)
+ [デプロイ中にインスタンスを削除した場合、デプロイは最大 1 時間は失敗しません。](#troubleshooting-one-hour-timeout)
+ [ログファイルの分析によるインスタンスでのデプロイの失敗の調査](#troubleshooting-deploy-failures)
+ [誤って削除した場合は、新しい CodeDeploy ログファイルを作成します。](#troubleshooting-create-new-log-file)
+ [「InvalidSignatureException – Signature expired: [time] is now earlier than [time]」デプロイエラーのトラブルシューティング](#troubleshooting-instance-time-failures)
## タグは正しく設定する必要がある
デプロイに使用されるインスタンスに正しくタグが付けられていることを確認するには、 [list-deployment-instances](https://docs.aws.amazon.com/cli/latest/reference/deploy/list-deployment-instances.html) コマンドを使用します。出力に EC2 インスタンスがない場合は、EC2 コンソールを使用して、インスタンスにタグが設定されていることを確認します。詳細については、「*Amazon EC2 ユーザーガイド*」の「[コンソールでのタグの操作](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console)」を参照してください。
**注記**
インスタンスにタグを付け、直後に CodeDeploy を使用してそのインスタンスにアプリケーションをデプロイする場合、インスタンスはデプロイに含まれないこともあります。これは、CodeDeploy がタグを読み込むまでに数分かかることがあるためです。インスタンスにタグを付けてから、そのインスタンスへのデプロイを試みるまでに、少なくとも 5 分待つことをお勧めします。
## AWS CodeDeploy エージェントはインスタンスにインストールして実行する必要があります
インスタンスに CodeDeploy エージェントがインストールされて実行されていることを確認する方法については、「[CodeDeploy エージェントが実行されていることの確認](codedeploy-agent-operations-verify.md)」を参照してください。
CodeDeploy エージェントをインストール、アンインストール、または再インストールする方法については、「[CodeDeploy エージェントをインストールする](codedeploy-agent-operations-install.md)」を参照してください。
## デプロイ中にインスタンスを削除した場合、デプロイは最大 1 時間は失敗しません。
CodeDeploy は、各デプロイライフサイクルイベントの実行が完了するまでに 1 時間の枠を設定しています。これにより、実行時間が長いスクリプトにも十分な時間が提供されます。
ライフサイクルイベントの進行中に、スクリプト実行が完了しない場合 (たとえば、インスタンスが終了された、CodeDeploy エージェントがシャットダウンされたなど)、デプロイのステータスが Failed になるまで、最大で 1 時間かかることがあります。スクリプトに指定されたタイムアウト時間が 1 時間未満である場合も同様です。これは、インスタンスが終了すると CodeDeploy エージェントがシャットダウンし、それ以上のスクリプトを処理できなくなるためです。
インスタンスがライフサイクル間、または最初のライフサイクルイベントのステップが開始する前に削除された場合、タイムアウトはわずか 5 分後に発生します。
## ログファイルの分析によるインスタンスでのデプロイの失敗の調査
デプロイのインスタンスのステータスが `Succeeded` 以外のいずれかである場合は、デプロイのログファイルデータを確認すると、問題の特定に役立ちます。デプロイのログデータへのアクセス方法については、「[CodeDeploy EC2/オンプレミスデプロイのログデータの表示](deployments-view-logs.md)」を参照してください。
## 誤って削除した場合は、新しい CodeDeploy ログファイルを作成します。
誤ってインスタンスのデプロイログファイルを削除した場合、CodeDeploy は代わりのログファイルを作成しません。新しいログファイルを作成するには、インスタンスにサインインし、以下のコマンドを実行します。
**Amazon Linux、Ubuntu Server、または RHEL インスタンスの場合**、以下のコマンドをこの順序で 1 つずつ実行します。
```
systemctl stop codedeploy-agent
```
```
systemctl start codedeploy-agent
```
**Windows Server インスタンスの場合**
```
powershell.exe -Command Restart-Service -Name codedeployagent
```
## 「InvalidSignatureException – Signature expired: [time] is now earlier than [time]」デプロイエラーのトラブルシューティング
CodeDeploy では、オペレーションを実行するために正確な時間の参照が必要です。インスタンスの日時が正しく設定されていない場合は、デプロイリクエストの署名と一致しないことがあり、その場合は CodeDeploy によってリクエストが却下されます。
誤った時間設定に関連するデプロイの失敗を回避する方法については、次のトピックを参照してください。
+ [Linux インスタンスの時刻の設定](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html)
+ [Windows インスタンスの時刻を設定する](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/windows-set-time.html)
# GitHub トークンの問題のトラブルシューティング
## GitHub OAuth トークンが無効です
2017 年 6 月以降に作成された CodeDeploy アプリケーションでは、各 AWS リージョンの GitHub OAuth トークンを使用します。特定の AWS リージョンに関連付けられたトークンを使用すると、GitHub リポジトリにアクセスできる CodeDeploy アプリケーションをより詳細に制御できます。
GitHub トークンエラーが発生した場合は、すでに無効になっている古いトークンの場合があります。
**無効な GitHub OAuth トークンを修正するには**
1. 以下のいずれかの方法を使用して、古いトークンを削除してください。
+ API を使って古いトークンを削除するには、[DeleteGitHubAccountToken](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_DeleteGitHubAccountToken.html) を使用します。
+ AWS Command Line Interfaceを使用して古いトークンを削除するには:
1. トークンが存在するコンピュータに移動します。
1. AWS CLI がこのコンピュータにインストールされていることを確認します。インストール方法については、[AWS CLIユーザーガイド](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) の「*AWS Command Line Interface のインストール、更新、およびアンインストール*」を参照してください。
1. トークンが存在するコンピュータで、次のコマンドを入力します。
**aws delete-git-hub-account-token**
コマンド構文の詳細については、「[delete-git-hub-account-token](https://docs.aws.amazon.com/cli/latest/reference/deploy/delete-git-hub-account-token.html)」を参照してください。
1. 新しい OAuth トークンを追加します。詳細については、「[GitHub と CodeDeploy との統合](integrations-partners-github.md)」を参照してください。
## GitHub OAuth トークンの最大数を超えました
CodeDeploy のデプロイを作成する際に許可されている GitHub トークンの最大数は 10 です。GitHub OAuth トークンに関するエラーが発生した場合、トークンが 10 個以下であることを確認します。トークンが 10 個以上ある場合は、最初に作成されたトークンが無効になります。たとえば、トークンが 11 個ある場合、最初に作成したトークンが無効になります。トークンが 12 個ある場合、最初に作成した 2 個のトークンが無効になります。CodeDeploy API を使用して古いトークンを削除する方法については、「[DeleteGitHubAccountToken](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_DeleteGitHubAccountToken.html)」を参照してください。
# Amazon EC2 Auto Scaling の問題のトラブルシューティング
**Topics**
+ [Amazon EC2 Auto Scaling の一般的なトラブルシューティング](#troubleshooting-auto-scaling-general)
+ [CodeDeployRole は、次の AWS サービスでオペレーションを実行するアクセス許可を付与しません: AmazonAutoScaling」エラー](#troubleshooting-auto-scaling-permissions-error)
+ [Amazon EC2 Auto Scaling グループのインスタンスのプロビジョニングと終了が繰り返されてリビジョンをデプロイできない](#troubleshooting-auto-scaling-provision-termination-loop)
+ [Amazon EC2 Auto Scaling インスタンスを終了または再起動すると、デプロイが失敗する場合がある](#troubleshooting-auto-scaling-reboot)
+ [複数のデプロイグループを 1 つの Amazon EC2 Auto Scaling グループに関連付けることは避ける](#troubleshooting-multiple-depgroups)
+ [Amazon EC2 Auto Scaling グループの EC2 インスタンスが起動に失敗し、「ハートビートのタイムアウト」というエラーが表示される](#troubleshooting-auto-scaling-heartbeat)
+ [Amazon EC2 Auto Scaling ライフサイクルフックの不一致により、Amazon EC2 Auto Scaling グループへの自動デプロイが停止または失敗することがある](#troubleshooting-auto-scaling-hooks)
+ [「デプロイグループのインスタンスが見つからないため、デプロイに失敗しました」というエラー](#troubleshooting-deployment-failed-because-no-instances-found)
## Amazon EC2 Auto Scaling の一般的なトラブルシューティング
Amazon EC2 Auto Scaling グループの EC2 インスタンスへのデプロイは、次の理由で失敗する場合があります。
+ **Amazon EC2 Auto Scaling は、EC2 インスタンスを継続的に起動および終了します。**CodeDeploy がアプリケーションリビジョンを自動的にデプロイできない場合、Amazon EC2 Auto Scaling は継続的に EC2 インスタンスを起動および終了させます。
CodeDeploy デプロイグループから Amazon EC2 Auto Scaling グループの関連付けを解除するか、Amazon EC2 Auto Scaling グループの設定を変更し、必要なインスタンス数が現在のインスタンス数に一致するようにします (これにより、Amazon EC2 Auto Scaling がそれ以上の EC2 インスタンスを起動できないようにします)。詳細については、「[CodeDeploy を使用して、デプロイグループの設定を変更します。](deployment-groups-edit.md)」または「[Amazon EC2 Auto Scaling のマニュアルスケーリング](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-manual-scaling.html)」を参照してください。
+ **CodeDeploy エージェントが応答しません。**EC2 インスタンスの起動直後に実行される初期化スクリプト (cloud-init スクリプトなど) の実行に 1 時間以上かかる場合、CodeDeploy エージェントがインストールされないことがあります。CodeDeploy には、CodeDeploy エージェントが保留中のデプロイに応答するための 1 時間のタイムアウトがあります。この問題に対応するには、CodeDeploy アプリケーションリビジョンに初期化スクリプトを移動します。
+ **Amazon EC2 Auto Scaling グループの EC2 インスタンスは、デプロイ中に再起動します。**デプロイ中に EC2 インスタンスが再起動したか、デプロイコマンドの処理中に CodeDeploy エージェントがシャットダウンした場合、デプロイは失敗することがあります。詳細については、「[Amazon EC2 Auto Scaling インスタンスを終了または再起動すると、デプロイが失敗する場合がある](#troubleshooting-auto-scaling-reboot)」を参照してください。
+ **複数のアプリケーションリビジョンが 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 エージェントをインストールする場合は、 CloudFormation テンプレートの `cfn-init`セクションの最後にエージェントインストールスクリプトを配置します。
+ **CodeDeploy エージェントを AMI に含める場合**: インスタンスの作成時にエージェントが `Stopped` 状態になるように設定し、次に `cfn-init` スクリプトライブラリの最終ステップとして、エージェントを起動するスクリプトを含めます
## CodeDeployRole は、次の AWS サービスでオペレーションを実行するアクセス許可を付与しません: AmazonAutoScaling」エラー
起動テンプレートを使用して作成された Auto Scaling グループを使用するデプロイでは、次のアクセス権限が必要です。これらは、 `AWSCodeDeployRole` AWS 管理ポリシーによって付与されたアクセス許可に追加されます。
+ `EC2:RunInstances`
+ `EC2:CreateTags`
+ `iam:PassRole`
これらのアクセス権限がないために、このエラーが発生した可能性があります。詳細については、「Amazon EC2 Auto Scaling ユーザーガイド**」の「[チュートリアル: CodeDeploy を使用して、Auto Scaling グループにアプリケーションをデプロイします。](tutorials-auto-scaling-group.md)」、「[Auto Scaling グループの起動テンプレートの作成](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-launch-template.html)」、および「[アクセス許可](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-templates.html#launch-templates-permissions)」を参照してください。
## Amazon EC2 Auto Scaling グループのインスタンスのプロビジョニングと終了が繰り返されてリビジョンをデプロイできない
エラーが原因で、Amazon EC2 Auto Scaling グループ内の新しくプロビジョニングされたインスタンスに正常にデプロイできない場合があります。その結果として、インスタンスは正常な状態にならず、デプロイは失敗します。デプロイが正常に実行または完了されないため、インスタンスは作成後すぐに終了されます。この場合、Amazon EC2 Auto Scaling グループの設定により、正常なホスト数の最小要件を満たすために別のバッチのインスタンスがプロビジョニングされます。このバッチも終了され、同じサイクルが繰り返されます。
エラーの原因として以下が考えられます。
+ Amazon EC2 Auto Scaling グループのヘルスチェックに失敗しました。
+ アプリケーションリビジョンのエラー。
この問題を回避するには、次の手順に従います。
1. Amazon EC2 Auto Scaling グループに属していない EC2 インスタンスを手動で作成します。インスタンスに一意の EC2 インスタンスタグを付けます。
1. 新しいインスタンスを該当するデプロイグループに追加します。
1. 新しい、エラーのないアプリケーションリビジョンをデプロイグループにデプロイします。
これにより、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 ファイルを追加する](application-revisions-appspec-file.md#add-appspec-file-server)」を参照してください。
複数のデプロイが同時に実行を試みた場合、デプロイが発生する順序を制御することはできない。
最後に、インスタンスへのデプロイが失敗した場合、Amazon EC2 Auto Scaling は直ちにインスタンスを終了します。その最初のインスタンスがシャットダウンすると、実行中の他のデプロイも失敗します。CodeDeploy には、CodeDeploy エージェントが保留中のデプロイに応答するための 1 時間のタイムアウトがあるため、各インスタンスのタイムアウトは最大 60 分かかる場合があります。
Amazon EC2 Auto Scaling の詳細については、「[内部構造: CodeDeploy と Auto Scaling の統合](https://aws.amazon.com/blogs/devops/under-the-hood-aws-codedeploy-and-auto-scaling-integration/)」を参照してください。
## Amazon EC2 Auto Scaling グループの EC2 インスタンスが起動に失敗し、「ハートビートのタイムアウト」というエラーが表示される
Amazon EC2 Auto Scaling グループが新しい EC2 インスタンスの起動に失敗し、次のようなメッセージを生成する場合があります。
`Launching a new EC2 instance . Status Reason: Instance failed to complete user's Lifecycle Action: Lifecycle Action with token was abandoned: Heartbeat Timeout`.
このメッセージは通常、以下のいずれかを示します。
+ AWS アカウントに関連付けられた同時デプロイの最大数に達しました。デプロイの制限の詳細については、「[CodeDeploy のクォータ](limits.md)」を参照してください。
+ Auto Scaling グループは、あまりにも多くの EC2 インスタンスを早く起動しようとしました。新しいインスタンスごとに [RecordLifecycleActionHeartbeat](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_RecordLifecycleActionHeartbeat.html) または [CompleteLifecycleAction](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_CompleteLifecycleAction.html) への API コールがスロットルされました。
+ 関連付けられたデプロイグループが更新または削除される前に、CodeDeploy のアプリケーションが削除された。
アプリケーションまたはデプロイグループを削除すると、CodeDeploy はそれに関連付けられていた Amazon EC2 Auto Scaling フックのクリーンアップを試みますが、一部のフックが残る場合があります。デプロイグループを削除するコマンドを実行すると、残りのフックが出力で返ります。ただし、アプリケーションを削除するコマンドを実行した場合、残りのフックは出力に表示されません。
したがって、アプリケーションを削除する前に、アプリケーションと関連付けられたすべてのデプロイグループを削除することをお勧めします。コマンド出力を使用して、手動で削除する必要があるライフサイクルフックを識別できます。
「ハートビートのタイムアウト」エラーメッセージが表示される場合は、次の操作を行い、残っているライフサイクルフックが原因かどうかを特定して問題を解決します。
1. 次のいずれかを行います。
+ [delete-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/delete-deployment-group.html) コマンドを呼び出して、ハートビートタイムアウトの原因となっている Auto Scaling グループに関連付けられたデプロイグループを削除します。
+ Auto Scaling グループ名の NULL ではない空のリストを指定して、[update-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/update-deployment-group.html) コマンドを呼び出し、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()` に設定します。これにより、`autoScalingGroups` を空のリストに設定し、既存のリストを削除します。デフォルトの `null` を使用すると、`autoScalingGroups` がそのまま残ってしまうので使用しないでください。
呼び出しの出力を確認します。出力に `hooksNotCleanedUp` 構造と Amazon EC2 Auto Scaling ライフサイクルフックの一覧が含まれている場合、ライフサイクルフックの残りがあります。
1. [describe-lifecycle-hooks](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/describe-lifecycle-hooks.html) コマンドを呼び出し、起動に失敗した EC2 インスタンスに関連付けられている Amazon EC2 Auto Scaling グループの名前を指定します。出力で、次のいずれかを確認します。
+ Amazon EC2 Auto Scaling ライフサイクルフック名で、ステップ 1 で特定した `hooksNotCleanedUp` 構造に対応するもの
+ Amazon EC2 Auto Scaling ライフサイクルフック名で、失敗している Auto Scaling グループに関連するデプロイグループの名前を含むもの
+ Amazon EC2 Auto Scaling のライフサイクルフック名で、CodeDeploy デプロイのハートビートタイムアウトの原因となった可能性のあるもの
1. フックがステップ 2 でリストされたカテゴリのいずれかに該当する場合は、[delete-lifecycle-hook](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/delete-lifecycle-hook.html) コマンドを呼び出して削除します。Amazon EC2 Auto Scaling グループとライフサイクルフックをコールで指定します。
**重要**
ステップ 2 で説明したように、問題の原因となっているフックのみを削除してください。実行可能なフックを削除すると、デプロイが失敗したり、CodeDeploy がアプリケーションリビジョンをスケールアウトした EC2 インスタンスにデプロイできなくなったりする可能性があります。
1. [update-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/update-deployment-group.html) または [create-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment-group.html) コマンドを、必要な Auto Scaling グループ名で呼び出します。CodeDeploy は、新しい UUID を持つ Auto Scaling フックを再インストールします。
**注記**
CodeDeploy デプロイグループから Auto Scaling グループをデタッチすると、Auto Scaling グループへの進行中のデプロイはすべて失敗し、Auto Scaling グループによってスケールアウトされる新しい EC2 インスタンスは CodeDeploy からアプリケーションリビジョンを受けとれなくなる可能性があります。CodeDeploy で Auto Scaling を再度動作させるには、Auto Scaling グループをデプロイグループに再アタッチし、新しい `CreateDeployment` を呼び出しして、フリート全体のデプロイを開始する必要があります。
## Amazon EC2 Auto Scaling ライフサイクルフックの不一致により、Amazon EC2 Auto Scaling グループへの自動デプロイが停止または失敗することがある
Amazon EC2 Auto Scaling と CodeDeploy はライフサイクルフックを使用して、Amazon EC2 Auto Scaling グループで起動された後にデプロイするアプリケーションリビジョンと、そのデプロイ先の EC2 インスタンスを判断します。ライフサイクルフックとそれに関する情報が Amazon EC2 Auto Scaling と CodeDeploy で正確に一致しない場合、自動デプロイは停止または失敗することがあります。
Amazon EC2 Auto Scaling グループへのデプロイに失敗する場合、Amazon EC2 Auto Scaling および CodeDeploy のライフサイクルフック名が一致するかどうかを確認します。そうでない場合は、これらの AWS CLI コマンド呼び出しを使用します。
最初に、Amazon EC2 Auto Scaling グループとデプロイグループの両方のライフサイクルフック名の一覧を取得します。
1. [describe-lifecycle-hooks](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/describe-lifecycle-hooks.html) コマンドを呼び出し、CodeDeploy のデプロイグループに関連付けられた Amazon EC2 Auto Scaling グループの名前を指定します。出力の `LifecycleHooks` リストで、`LifecycleHookName` のそれぞれの値を書き留めます。
1. [get-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-group.html) コマンドを呼び出し、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](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/delete-lifecycle-hook.html) コマンドを呼び出します。
1. [update-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/update-deployment-group.html) コマンドを呼び出し、元の Amazon EC2 Auto Scaling のグループ名を指定します。CodeDeploy は、Amazon EC2 Auto Scaling グループに新しい代替のライフサイクルフックを作成し、そのライフサイクルフックをデプロイグループに関連付けます。これで、Amazon EC2 Auto Scaling グループに新しいインスタンスを追加すると、自動デプロイが開始されます。
1. **describe-lifecycle-hooks** コマンド出力にもないライフサイクルフック名が **get-deployment-group** コマンド出力にある場合は、次の操作を行います。
1. [update-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/update-deployment-group.html) コマンドを呼び出し、元の Amazon EC2 Auto Scaling のグループ名を指定しないようにします。
1. **update-deployment-group** コマンドを再度呼び出し、今度は元の Amazon EC2 Auto Scaling グループの名前を指定します。CodeDeploy は、Amazon EC2 Auto Scaling グループに不足しているライフサイクルフックを再作成します。これで、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 インスタンス、またはオンプレミスインスタンスのタグが含まれています。この問題を解決するには、タグが正しいことをチェックしてから、アプリケーションを再デプロイしてください。
1. デプロイ開始後、フリートがスケールアウトしました。このシナリオでは、フリートで `InService` 状態の正常なインスタンスが表示されますが、上記のエラーも表示されます。この問題を解決するには、アプリケーションを再デプロイします。
1. Auto Scaling グループには、`InService` 状態のインスタンスは含まれません。このシナリオでは、CodeDeploy は少なくとも 1 つのインスタンスが `InService` 状態である必要があるため、フリート全体のデプロイを実行しようとすると、上記のエラーメッセージが表示されてデプロイが失敗します。`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](#ToTroubleshootIfNoInServiceInstances) の説明に従ってトラブルシューティングします。
**InService 状態のインスタンスが存在しない場合のエラーのトラブルシューティングについて**
1. Amazon EC2 コンソールで、[**希望する容量**] の設定を確認します。ゼロの場合は、正の数に設定します。インスタンスが `InService` になるのを待ちます。これは、デプロイが成功したことを意味します。問題が解決されたので、このトラブルシューティングの手順の残りのステップはスキップできます。**[Desired Capacity]** (希望する容量) の設定については、「*Amazon EC2 Auto Scaling ユーザーガイド*」の「[Auto Scaling グループの容量制限を設定する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-capacity-limits.html)」を参照してください。
1. Auto Scaling が希望する容量を満たすために新しい EC2 インスタンスを起動し続けようとするが、スケールアウトを実行できない場合は、通常、Auto Scaling のライフサイクルフックが失敗していることが原因です。この問題については、次のようにトラブルシューティングします。
1. 失敗している Auto Scaling ライフサイクルフックイベントを確認するには、Amazon EC2 Auto Scaling ユーザーガイドの「[Auto Scaling グループのスケーリングアクティビティの確認](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-verify-scaling-activity.html)」を参照してください。
1. 失敗したフックの名前が `CodeDeploy-managed-automatic-launch-deployment-hook-DEPLOYMENT_GROUP_NAME` の場合、CodeDeploy に移動し、デプロイグループを見つけて、Auto Scaling によって開始され、失敗したデプロイを見つけます。次に、デプロイが失敗した理由を調べます。
1. デプロイが失敗した理由 (例えば、CloudWatch アラームが発生していたなど) がわかっていて、リビジョンを変更せずに問題を修正できる場合は、今すぐ実行してください。
1. 調査の結果、CodeDeploy の*最後に成功したリビジョン*が正常ではなくなり、Auto Scaling グループ内の正常なインスタンスがゼロであると判断された場合、デプロイのデッドロックシナリオに陥っています。この問題を解決するには、Auto Scaling グループから CodeDeploy のライフサイクルフックを一時的に削除し、フックを再インストールして新しい (正しい) リビジョンを再デプロイすることで、不正な CodeDeploy リビジョンを修正する必要があります。手順については、こちらを参照してください。
+ [To fix the deployment deadlock issue (CLI)](#ToFixDeployDeadlockCLI)
+ [To fix the deployment deadlock issue (console)](#ToFixDeployDeadlockConsole)
**デプロイのデッドロックの問題を解決するには (CLI)**
1. (オプション) CodeDeploy エラーを引き起こしている CI/CD パイプラインをブロックして、この問題を解決している間に予期しないデプロイが発生しないようにします。
1. Auto Scaling の現在の **[DesiredCapacity]** 設定を書き留めます:
`aws autoscaling describe-auto-scaling-groups --auto-scaling-group-name ASG_NAME`
場合によっては、この手順の最後に、この数値にスケールバックする必要があります。
1. Auto Scaling の **[DesiredCapacity]** 設定を `1` にしてください。開始の際に希望する容量が `1` より大きい場合、オプションとなります。それを `1` に減らすことで、インスタンスのプロビジョニングとデプロイにかかる時間が短くなり、トラブルシューティングが高速化されます。Auto Scaling の希望する容量がもともと `0` に設定されている場合、`1` に増やす必要があります。これは必須です。
aws autoscaling set-desired-capacity — auto-scaling-group-name *ASG\$1NAME* —desired-capacity 1
**注記**
この手順の残りのステップでは、**[DesiredCapacity]** を `1` に 設定したものとします。
この時点で、Auto Scaling は 1 つのインスタンスへのスケーリングを試みます。次に、CodeDeploy が追加したフックがまだ存在するため、CodeDeploy がデプロイを試みても失敗し、Auto Scaling はインスタンスをキャンセルして希望容量の 1 に達するようにインスタンスを再起動しようとしますが、これも失敗します。キャンセル再起動ループに入っています。
1. デプロイグループから 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 グループを登録解除します。
1. CodeDeploy は Auto Scaling グループから Auto Scaling ライフサイクルフックを削除します。
1. デプロイ失敗の原因となっていたフックが存在しなくなるため、Auto Scaling は既存の EC2 インスタンスをキャンセルし、希望容量にスケーリングする新しいインスタンスを直ちに起動します。新しいインスタンスは、`InService` 状態にまもなく移行するはずです。新しいインスタンスには、ソフトウェアは含まれません。
1. EC2 インスタンスが `InService` 状態になるのを待ちます。その状態を確認するには、次のコマンドを使用します。
`aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names ASG_NAME --query AutoScalingGroups[0].Instances[*].LifecycleState`
1. 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 は、Auto Scaling ライフサイクルフックを EC2 インスタンスに再インストールします。
1. CodeDeploy は、Auto Scaling グループをデプロイグループに再登録します。
1. 正常であることがわかり、使用したい 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` インスタンスが一つ存在するため、このデプロイは機能するはずで、エラー [*デプロイグループのインスタンスが見つからないため、デプロイに失敗しました*] は表示されなくなります。
1. 以前にスケールインしていた場合、デプロイが成功したら、Auto Scaling グループをスケールアウトして元の容量に戻します。
`aws autoscaling set-desired-capacity --auto-scaling-group-name ASG_NAME --desired-capacity ORIGINAL_CAPACITY`
**デプロイのデッドロックの問題を解決するには (コンソール)**
1. (オプション) CodeDeploy エラーを引き起こしている CI/CD パイプラインをブロックして、この問題を解決している間に予期しないデプロイが発生しないようにします。
1. Amazon EC2 コンソールにアクセスし、Auto Scaling の [**希望する容量**] の設定を書き留めます。場合によっては、この手順の最後に、この数値にスケールバックする必要があります。この設定の見つけ方の詳細については、「[Auto Scaling グループの容量制限の設定](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-capacity-limits.html)」を参照してください。
1. 必要な EC2 インスタンスの数を `1` に設定:
希望する容量が `1` より大きい場合、オプションとなります。それを `1` に減らすことで、インスタンスのプロビジョニングとデプロイにかかる時間が短くなり、トラブルシューティングが高速化されます。Auto Scaling の **希望する容量** がもともとに `0` 設定されている場合、`1` に増やす必要があります。これは必須です。
**注記**
この手順の残りのステップでは、`1` に **希望する容量** を設定したものとします。
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで **[Auto Scaling グループ]** を選択します。
1. 適切なリージョンを選択します。
1. 問題がある Auto Scaling グループに移動します。
1. [**グループの詳細**] で、[**編集**] を選択します。
1. **1** に **希望する容量** を設定。
1. **[更新]** を選択します。
1. デプロイグループから Auto Scaling グループの登録を解除します。
**警告**
次のサブステップでは、ソフトウェアなしで新しい EC2 インスタンスを起動します。コマンドを実行する前に、ソフトウェアを実行していない Auto Scaling `InService` インスタンスが許容されることを確認します。例えば、インスタンスに関連付けられているロードバランサーがソフトウェアなしでこのホストにトラフィックを送信していないことを確認してください。
1. [https://console.aws.amazon.com/codedeploy/](https://console.aws.amazon.com/codedeploy/) で、CodeDeploy コンソールを開きます。
1. 適切なリージョンを選択します。
1. ナビゲーションペインで、**[アプリケーション]** を選択します。
1. CodeDeploy アプリケーションの名前を選択します。
1. CodeDeploy デプロイグループ名を選択する。
1. **[編集]** を選択します。
1. **環境設定** では、**Amazon EC2 Auto Scaling グループ** の選択を解除します。
**注記**
環境設定が定義されていない場合、コンソールでは設定を保存できません。チェックをバイパスするには、どのホストにも解決しないことがわかっている `EC2` または `On-premises` のタグを一時的に追加してください。タグを追加するには、**Amazon EC2 インスタンス** または **オンプレミスインスタンス** を選択し、タグの **キー** として **EC2** または **On-premises** を追加します。タグの **値** は、空欄でも構いません。
1. **[Save changes]** (変更の保存) をクリックします。
これらのサブステップを完了すると、次のようになります。
1. CodeDeployは、デプロイグループから Auto Scaling グループを登録解除します。
1. CodeDeploy は Auto Scaling グループから Auto Scaling ライフサイクルフックを削除します。
1. デプロイ失敗の原因となっていたフックが存在しなくなるため、Auto Scaling は既存の EC2 インスタンスをキャンセルし、希望容量にスケーリングする新しいインスタンスを直ちに起動します。新しいインスタンスは、`InService` 状態にまもなく移行するはずです。新しいインスタンスには、ソフトウェアは含まれません。
1. EC2 インスタンスが `InService` 状態になるのを待ちます。その状態を確認するには:
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、[**Auto Scaling Groups**] をクリックしてください。
1. [Auto Scaling グループ] を選択します。
1. コンテンツペインで、**インスタンス管理** タブを選択します。
1. **インスタンス** で、**ライフサイクル** 列がインスタンスの横で **InService** と表示されていることを確認します。
1. 削除にした方法と同じ方法で、Auto Scaling グループを CodeDeploy デプロイグループに再登録します。
1. [https://console.aws.amazon.com/codedeploy/](https://console.aws.amazon.com/codedeploy/) で、CodeDeploy コンソールを開きます。
1. 適切なリージョンを選択します。
1. ナビゲーションペインで、**[アプリケーション]** を選択します。
1. CodeDeploy アプリケーションの名前を選択します。
1. CodeDeploy デプロイグループ名を選択する。
1. **[編集]** を選択します。
1. **環境設定** で、**Amazon EC2 Auto Scaling グループ** を選択し、リストから Auto Scaling グループを選択します。
1. **Amazon EC2 インスタンス** または **オンプレミスインスタンス** で、追加したタグを見つけて削除します。
1. **Amazon EC2 インスタンス**または**オンプレミスインスタンス** の横にあるチェックボックスの選択を解除します。
1. **[Save changes]** (変更の保存) をクリックします。
この設定により、ライフサイクルフックが Auto Scaling グループに再インストールされます。
1. 正常であることがわかり使用したい Amazon S3 または GitHub のリビジョンで、フリート全体のデプロイを作成します。
たとえば、リビジョンが、`my-revision-bucket` という Amazon S3 バケットにある .zip ファイルで、オブジェクトキーが `httpd_app.zip` である場合、以下を実行します。
1. CodeDeploy コンソールの、[**デプロイグループ**] ページで、[**デプロイの作成**] を選択します。
1. [**Revision type (リビジョンのタイプ)**] の場合は、[**My application is stored in Amazon S3 (Amazon S3 に保存されているアプリケーション)**] を選択します。
1. **リビジョンの場所** は、`s3://my-revision-bucket/httpd_app.zip` を選択します。
1. [**リビジョンファイルの種類**] で、[`.zip`] を選択します。
1. **[デプロイの作成]** を選択します。
現在、Auto Scaling グループに `InService` インスタンスが一つ存在するため、このデプロイは機能するはずで、エラー [*デプロイグループのインスタンスが見つからないため、デプロイに失敗しました*] は表示されなくなります。
1. 以前にスケールインしていた場合、デプロイが成功したら、Auto Scaling グループをスケールアウトして元の容量に戻します。
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで **[Auto Scaling グループ]** を選択します。
1. 適切なリージョンを選択します。
1. Auto Scaling グループに移動します。
1. [**グループの詳細**] で、[**編集**] を選択します。
1. **希望する容量** 元の値に戻す設定をします。
1. **[更新]** を選択します。
# AWS CodeDeploy のエラーコード
このトピックでは、CodeDeploy エラーに関するリファレンス情報を提供します。
****
| エラーコード | 説明 |
| --- | --- |
| `AGENT_ISSUE` | CodeDeploy デプロイは、 エージェントの問題により失敗しました。このデプロイグループのすべてのインスタンスで、エージェントがインストールされ、実行されていることを確認します。 詳細はこちら: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/error-codes.html) |
| `AUTO_SCALING_IAM_ROLE_PERMISSIONS` | デプロイグループに関連付けられたサービスロールに、次の AWS のサービスでオペレーションを実行するために必要なアクセス権限がありません。 詳細はこちら: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/error-codes.html) |
| `HEALTH_CONSTRAINTS` | デプロイに失敗した個別のインスタンスが多すぎる、デプロイに使用できる正常なインスタンスが少なすぎる、またはデプロイグループの一部のインスタンスで問題が発生しているため、全体的なデプロイが失敗しました。 詳細はこちら: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/error-codes.html) |
| `HEALTH_CONSTRAINTS_INVALID` | デプロイ設定で定義されている正常なインスタンスの最小数が利用できないため、デプロイを開始できません。デプロイ設定を更新するか、このデプロイグループのインスタンス数を増やすことで、正常なインスタンスの必要な数を減らすことができます。 詳細はこちら: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/error-codes.html) |
| `IAM_ROLE_MISSING` | デプロイグループに指定された名前のサービスロールが存在しないため、デプロイに失敗しました。正しいサービスロール名を使用していることを確認します。 詳細はこちら: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/error-codes.html) |
| `IAM_ROLE_PERMISSIONS` | CodeDeploy にロールを引き受けるために必要なアクセス権限がないか、使用している IAM ロールに、AWS のサービスでオペレーションを実行するアクセス権限がありません。 詳細はこちら: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/error-codes.html) |
| `NO_INSTANCES` | これは、次のいずれかの条件によって発生する可能性があります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/error-codes.html) 詳細はこちら: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/error-codes.html) |
| `OVER_MAX_INSTANCES` | デプロイの対象となるインスタンス数が、アカウントで許可されるインスタンス数より多いため、デプロイに失敗しました。このデプロイの対象となるインスタンスの数を減らすには、このデプロイグループのタグ設定を更新するか、対象インスタンスの一部を削除します。または、AWS サポート に問い合わせて、制限の引き上げをリクエストできます。 詳細はこちら: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/error-codes.html) |
| `THROTTLED` | IAM ロールによって AWS CodeDeploy で許可されるよりも多くのリクエストが行われたため、デプロイに失敗しました。リクエスト数を減らしてみてください。 詳細はこちら: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/error-codes.html) |
| `UNABLE_TO_SEND_ASG` | デプロイグループが Amazon EC2 Auto Scaling グループに対して正しく設定されていないため、デプロイに失敗しました。CodeDeploy コンソールで、デプロイグループから Amazon EC2 Auto Scaling グループを削除し、もう一度追加してください。 詳細はこちら: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/error-codes.html) |
## 関連トピック
[CodeDeploy のトラブルシューティング](troubleshooting.md)