AWS Codeサービスを利用したCI/CDパイプラインの仕組み（CodePipeline・CodeCommit・CodeBuild・CodeDeploy）

内容

業務でAWSのCodeサービス（CodePipeline・CodeCommit・CodeBuild・CodeDeploy）によるCI/CDパイプラインの構築を実施したので、知識のアウトプットのため本記事をまとめます。
デプロイはECS Fargateへのデプロイを想定しています。

目次

• CI/CDとは
• AWS Codeサービスの説明
• CI/CDパイプラインの流れ
• 最後に

CI/CDとは

CI（継続的インテグレーション）・CD（継続的デリバリー）とは、提供するソフトウェアのアップデート作業を自動化し、アプリケーションのプロセスを向上するための手段のこと。
アップデート作業には「テスト」「ビルド」「デプロイ」などの手順があり、手動でこれを実施する場合、人為的なミスが生じたり、知識のある人員が退職などで離れてしまうなどといったリスクが生じる。
CI/CDパイプラインを構築し自動化を実現することで、このような人為的なミスや属人化を軽減する事ができる。

AWS Codeサービスの説明

AWSでCI/CDパイプラインを構築するのに使用するサービスとして、「CodePipeline」「CodeCommit」「CodeBuild」「CodeDeploy」があります。
これらの「Codeシリーズ」を利用することでCI/CDパイプラインを比較的簡単に実現できる。

CodeCommit

Gitリポジトリをホストする、スケーラブルなマネージド型ソース管理サービス。
スタンダードなGitツールが利用可能。

CodeBuild

フルマネージド型のビルドサービス。
ソースコードのコンパイル、テストの実行、パッケージの生成などを実施。

CodeDeploy

EC2やECS Fargateなどへのアプリケーションのデプロイを自動化するデプロイサービス。
Blue/Greenデプロイや自動ロールバックなど、複雑なアップデートに対処。

CodePipeline

アプリケーションのアップデートを素早く信頼できるアップデートを可能にする継続的デリバリーサービス。
ソフトウェアリリースプロセスの見える化が可能。

CI/CDパイプラインの流れ

全体像は以下のようなフローとなる。

① CodePipeline起動

• CodeCommitへプッシュ・マージによりブランチが変更されるとCloudWatchが検知し、CodePipelineを走らせる

② Sourceステージ

• CodePipelineのソースステージでCodeCommitからソースコードを取得
• ソースアーティファクトとしてS3へ格納
  • ソースアーティファクトが格納されるS3バケット：codepipeline-[リージョン]-[数字]/[パイプライン名]/[SorceArtifact名]/

③ Buildステージ

• ②のソースステージで出力したソースアーティファクトを元に、アプリケーションのコンパイルやテストを実行
• ビルドされたソースコードを使ってdocker-compose.yml（Docｋerfile）からDockerイメージを作成
• DockerイメージをECRへプッシュ
• ビルドアーティファクトとして以下のファイルをS3へ出力
  • appspec.yml
  • taskdef.json
  • imagedefinitions.json（ECS Blue/Greenデプロイの場合はimageDetail.json）
  • ビルドアーティファクトが格納されるS3のバケット：codepipeline-[リージョン]-[数字]/[パイプライン名]/[BuildArtifact名]/

④ Deployステージ

• ③で出力したビルドアーティファクトのappspec.yml（デプロイ定義ファイル）とtaskdef.json（タスク定義ファイル）を元に、ECRにプッシュされたDockerイメージをECS Fargateにデプロイ、ECSタスクを起動（コンテナを起動）

最後に

以上がAWS Codeサービスを用いたCI/CDパイプラインの仕組みです。
今回はECS Fargateの例を用いての説明のため、ECS Fargateの知識がない方にはデプロイフェーズのイメージが付きづらい点もあったかと思いますが、全体的な仕組みとしてはEC2へのデプロイにおいてもほぼ同じようなイメージかと思います。

ここまで読んでいただきありがとうございました。