AWS CodePipelineをGitHub Actionsへ移行してみた

TypeScriptが大好きなエンジニア。基幹システムグループのキムです。

担当するプロジェクトの中で、最近はGitHubで進めるプロジェクトが多くなりました。
以前はECSをAWS CodePipelineを利用してビルドとデプロイを行っていましたが、
GitHubで進めるプロジェクトはAWS CodePipelineより、GitHub Actionsが管理も楽だし値段も安いなと思ったため、CodePipelineからGitHub Actionsへ移行することを決めました。

AWS CodePipeline vs GitHub Actions

CodePipelineとGitHub Actionsの特徴の比較は以下になります。 GitHub Actionsが料金も安いし、無料枠の時間も長いためお得な感じですね。あとは、GitHub Actionsはworkflowのymlだけ管理すれば良いため、管理もしやすいイメージです。AWSだけではなく、GCPやAzureなどにもデプロイできるのは大きいメリットだと思います。

変更前 – AWS CodePipelineでECSのビルドとデプロイを行う

既存のプロジェクトではBitbucketを使うケースが多くありました。
そのため、以下の順でビルドとデプロイを行っていました。

1. BitbucketのコードをAWS CodeCommitへミラーリングする
2. 特定のブランチへのプッシュをトリガーにCodeBuildが走ってECR用のイメージ作成
3. イメージ作成後、ECSへデプロイする

手順だけ見れば簡単にも見えますが、管理をCDKで行い、あとはCodeBuildを利用するためにbuildspec.ymlも作成する必要がありました。 CDKは省略します。

変更後 – GitHub ActionsでECSのビルドとデプロイを行う

GitHub Actionsでは

1. 特定のブランチへのプッシュをトリガーにActionsのWorkflowが走る
2. イメージビルドとデプロイを行う

で終わり。簡単ですね。Workflowのymlファイルは になります。インスタンス内でAWSへログインして、Docker イメージのビルドを行ったあと、AWS CLIでそのイメージをECRへプッシュ、ECSへデプロイする流れになります。管理もこのymlファイル一つで終わるため簡単です。デプロイ後それをSlackに通知するジョブを付ければ完璧ですね。

実際に移行して運用してみた感想

今後CDKの管理はしなくてもよい点がかなり魅力的ですね。あとは、GitHubでプルリクエストのマージ後、すぐActionの動作を確認できることも楽でした。今後AWS LambdaもCDKで管理する必要なく、GitHubで管理が出来ると思っています。