内容
業務でAWSのCodeサービス（CodePipeline・CodeCommit・CodeBuild・CodeDeploy）によるCI/CDパイプラインの構築を実施したので、知識のアウトプットのため本記事をまとめます。
デプロイはECS Fargateへのデプロイを想定しています。
目次
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名]/
- ソースアーティファクトが格納されるS3バケット：
③ Buildステージ
- ②のソースステージで出力したソースアーティファクトを元に、アプリケーションのコンパイルやテストを実行
- ビルドされたソースコードを使ってdocker-compose.yml（Docｋerfile）からDockerイメージを作成
- DockerイメージをECRへプッシュ
- ビルドアーティファクトとして以下のファイルをS3へ出力
appspec.ymltaskdef.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へのデプロイにおいてもほぼ同じようなイメージかと思います。
ここまで読んでいただきありがとうございました。