はじめに
AWS Fargate with CI/CDパイプラインでデプロイ失敗する原因について
コンテナログ(CloudWatch Logs)には何も出ず、遭遇して原因がすぐに分かりづらい物をまとめてみました。
CodeDeploy-Fargateデプロイ失敗は常々分かりづらいと感じているので、少しでも手助けになればと考えております。
目次
概要
単純化した下記のような構成でどこが原因で、デプロイ失敗したのかを記載していきます。
CodePipelineの中身としては下記のような物を例としています。
CodeCommit ⇢ CodeBuild ⇢ 手動承認 ⇢ CodeDeploy (Blue-Green)
事象
CodeBuildエラー
ImageBuild時点で失敗している場合、原因は分かりやすい事が多いため、地道にログを確認する
対処方法
エラー原因が多岐に渡るため、Debugログを多めに出しつつじっくりとログを確認するしかありませんが
ローカルだと上手くいくのに！というような場合、下記のような環境原因を調べるのが良いかもしれません。
- CodeBuild時に動作するコンテナがどのVPC/サブネットで動作する設定となっているか
- CodeBuild時に実行されるユニットテストでDB接続が必要等
- CodeBuildサービス内の環境変数
- Build時、ライブラリ取得する際に対向側が不安定ではないか（再試行ですんなり行く事も）
CodeDeployエラー
ここまでくれば、Fargate上でコンテナが立ち上がった後停止されているはずですので
ECSクラスタを選択し、[タスク]タブを選択、直近で停止されたタスクの詳細を確認すると停止理由の所に失敗原因が出ているはずです。
代表的な物を下記に記載します。
コンテナ内ヘルスチェックに失敗
ヘルスステータス : UNHEALTHY
停止理由 : Task failed container health checks
- コンテナDefinitionで定義したヘルスチェックコマンド起因 (nc -z…等)
- 利用しているプログラムが存在しない
- Dockerfile内で必要なコマンドをインストールしましょう
- コマンドのパスが通っていない
- 自前のヘルスチェックプログラム等を組んだ場合要注意
- 利用しているプログラムが存在しない
- アプリケーションFrameworkのConfigファイル起因
- ローカルホストからしか接続許可されていない (host=… 等の設定)
- Listenポートが異なっていた
- 開発環境用設定ファイル、デプロイ用設定ファイル内容は適切か
ALBヘルスチェックに失敗
- Fargateサービス設定起因
- 起動VPC/サブネット設定は適切か
- セキュリティグループ設定は適切か
- ヘルスチェック設定条件（ターゲットグループのヘルスチェック設定）
- ヘルスチェックページ/APIは想定通りのレスポンスコードを返却しているか
このような場合、ヘルスチェック間隔にもよりますが数分はコンテナが起動しているはずですので
踏み台サーバ等を利用し、コンテナに振られたIPアドレスでcurl等でアクセスしてみると原因が分かると思います。
番外編
環境変数としてシークレット文字列を引き渡すのに便利な、SSM ParameterStoreから値をValuesFromで設定している場合に起きうる問題として下記を紹介させて頂きます。
- タスク定義している環境変数は適切か
- SSMParameterStoreに引き渡しているキーが存在するか
Fargateタスク起動に即時失敗し、停止理由に下記のようなエラーが出力されます。
Fetching secret data from SSM Parameter Store in ap-northeast-1: invalid parameters: ...
投稿者プロフィール
