CodePipelineでECSデプロイを自動化した時につまずいた3つのポイント

こんにちは、OTTサービス技術部の藤原です。
AWSでCodePipelineを使ったECSデプロイを自動化する際にいくつかつまずいたことがありましたので、今回はそのポイントを共有します。
CodePipelineを使った設定方法はこちらの記事で紹介されていますので、そちらも参考にしてみてください。
developers.play.jp

背景
構成
つまずいたポイント3つ
まとめ

背景

もともと手動デプロイしていたプロジェクトがあり、深夜にメンテナンス時間を取ることもありました。そこでCodePipelineによる自動化とBlue/Greenデプロイを導入し、前日までにGreen環境で動作確認を済ませてリリース当日は切り替えだけで済むようにしました。

構成

設定の詳細は先ほど紹介した記事を参照してください。ここでは前提となる構成だけ共有します。
・CloudFront
・ALB - Blue/Green切り替え用のターゲットグループを2つ
・ECS (Fargate) - アプリケーション実行環境
・ECR - コンテナイメージの保存

・GitHubへのPushをトリガーにCodePipelineが自動起動
・CodePipeline - CI/CDのオーケストレーション
・CodeBuild - イメージのビルド、ECRへのプッシュ。今回はVPC内で実行（社内リソースへのアクセスが必要なため）。
・CodeDeploy - Blue/Greenデプロイの制御

デプロイの流れとしては、GitHub → CodePipeline → CodeBuild → CodeDeploy → ECS という形です。

つまずいたポイント3つ

1. CodeBuildのIAM権限不足

最初につまずいたのがこちらです。とりあえず最低限かつ基本的なIAMポリシーを使ったらビルドエラーになることがありました。原因はビルド内容を把握していなかったことです。CodeBuildに必要な権限はビルドの中で何をするかによって変わってきます。
例えば
・VPC内で動かすなら ec2:CreateNetworkInterface など
・パラメータストアから値を取得するなら ssm:GetParameters など
・ビルド完了時にSNS通知を送るなら sns:Publish など

結局、ビルドエラー → ログを見て足りない権限を追加 → 再ビルド...を何回か繰り返して解決しました。基本的には事前にアプリ側の方と調整して何をするかを把握しておけばスムーズに構築できたなと思います。
ただし、まずは最低限の環境構築を目指すのであれば、権限は必要最低限にしておいてエラーが出たら都度調整するのも1つのやり方かと思いました。

2. 社内パッケージサーバーへのアクセス拒否

次のつまずきポイントはこちらです。ビルド中にnpmやgemなどのインストールで失敗しました。
弊社ではプライベートなサーバーがありましてそれぞれアクセス制限をかけています。CodeBuildをVPC内で動かしていたので、外部へのアクセスはNAT Gateway経由になります。
つまり、NAT GatewayのElastic IPをプライベートなサーバのアクセス許可リストに追加すればOKでした。
CodeBuildをVPC内で動かす場合は、外部アクセスの経路を意識しておく必要がありますね。

3. ヘルスチェックパスの共有漏れ

こちらが3つ目。デプロイは通るのに、タスクが起動してすぐ停止する...を延々と繰り返しました。
ECSのイベントを見ると、ヘルスチェックに失敗してタスクが落とされている様子。原因を調べてみたら、ターゲットグループのヘルスチェックパスがデフォルトの / のままでした。
アプリ側のヘルスチェックパスが /health（例）だったので、それは失敗するなと。
タスクが立ち上がらない場合は、ヘルスチェックの設定に問題がないか確認することをおすすめします。