はじめに
AWSのECSを使用している環境でアプリケーションの更新を行うにあたり、CodeBuildやCodeDeploy等のサービスを使用する機会があります。
CodeDeployでは更新が完了するまでに各種ライフサイクルイベントがありますが、その中のInstallイベント時にタイムアウトによるエラーが発生することがありました。
今回はデプロイが失敗した原因と、その際の調査手順について紹介します。
原因
結論として、今回の事象ではECSのタスク定義で記載したSecretsManagerのキーが実際に設定されていなかったことが原因となります。
この状態でデプロイを実施すると、以下のようなタイムアウトが発生します。
The deployment timed out while waiting for the replacement task set to become healthy. This time out period is 60 minutes.
調査手順
今回の事象における調査手順について記載します。
- CodeDeployのサービスを開く
AWSのコンソールから、CodeDeployのサービスを開きます。
その後、デプロイに失敗したアプリケーションを押下します。
- 失敗したデプロイの確認
ステータスがFailedとなったデプロイを確認します。
該当のリンクを押下すると、デプロイ時の詳細を確認することが可能です。
- リビジョンの確認
デプロイの履歴としてリビジョンが残っているため、リンクを押下します。
リビジョンはデプロイするソースコード等の成果物のことを指しています。
- タスク定義の確認
App Specファイル内で定義されているタスク定義のリビジョン番号を確認します。
以下ではリビジョン10のタスク定義でデプロイを行ったことが確認できます。
例
version: 0.0 Resources: - TargetService: Type: AWS::ECS::Service Properties: TaskDefinition: arn:aws:ecs:ap-northeast-1:xxxxxxxx:task-definition/xxxxxxx:10 LoadBalancerInfo: ContainerName: "nginx" ContainerPort: 80
- タスク定義の比較
今回の例の場合、リビジョン9のタスク定義ではデプロイが成功しているため、タスク定義の差分を比較します。
diffコマンドの結果、以下のようなSecretsManagerの差分が検出されています。
"secrets": [ { "name": "TEST", "valueFrom": "arn:aws:secretsmanager:ap-northeast-1:xxxxxxxx:secret:TEST:TEST::" }, ]
- SecretsManagerを定義し、再デプロイ
差分の結果から、エラーの原因は検出されたSecretsManagerの設定不足、もしくはタスク定義における不要な設定と考えられます。
今回はSecretsManagerの設定を行い、再度リリースを行う事でデプロイが成功しています。
終わりに
ECSを使用した環境でCodeDeployのインストールイベントが終わらない件について説明しました。
今回の例ではSecretsManagerの設定不備が原因でしたが、他の要因でエラーが発生する場合も考えられます。
アプリケーションに問題ない際は設定に問題がある場合があるので、デプロイに成功・失敗した時のタスク定義を比較してみると原因がわかるかもしれません。