AWS CodePipeLineを用いた継続的デリバリ

本連載では、以下のようなマイクロサービスアーキテクチャでの継続的インテグレーション(CI：Continuous Integration)や継続的デリバリ(CD：Continuous Delivery)の自動化環境の構築を実践しています。

前回まで数回にわたり、ECSコンテナ、RDSを使ったSonarQubeServerによる静的チェック環境の構築から、SpringBootを使ったマイクロサービスにおける各種テストコードの実装、GitHubへプッシュされたソースコードに対するCodeBuildを使ったビルド／テスト、SonarScannerによる静的チェック結果の可視化といった一連の継続的インテグレーション自動化の仕組みについて解説してきました。

継続的インテグレーションは、以下のようなGit Flowをベースとしたブランチ構成で、feature/＊＊＊＊＊＊ブランチを対象に、赤字の吹き出しのタイミングで、ソースコードのGitHubへのプッシュを契機にビルド／テスト／静的解析結果可視化の自動化を実現しています。

feature/＊＊＊＊ブランチに対する機能実装が完了した後は、developブランチに対してプルリクスト(PR：Pull Request)をコードオーナーや管理者に送信し、マージ要求を行います。そして、developブランチへPRが発出されたタイミングやコードのマージを契機として、以下のようなプロセスを経て、プロダクション環境へリリースしていくものとします。

1. バックエンドのマイクロサービスのコンテナイメージのビルド、DockerHubへのプッシュ
2. マイクロサービスコンテナイメージをプロダクションとほぼ同等のステージング環境へデプロイ
3. Webアプリケーション(BFF)のE2Eテストとして、Seleniumテストコード実行
4. Webアプリケーション(BFF)のコンテナイメージのビルド、DockerHubへのプッシュ
5. Webアプリケーション(BFF)のステージング環境へデプロイ
6. パフォーマンステストやセキュリティテスト、受入など、その他テスト後の管理者によるリリース承認
7. ステージング環境でテスト済みのコンテナイメージをリリース用にタグ付けし、DockerHubへプッシュ
8. プロダクション環境へリリース

今回からは、上記の一連の流れをAWS CodePipelineを使ってパイプライン的に自動化する仕組みを構築／解説していきます。今回はCodePipelineの概要と、リリースまでのパイプライン構成、実行環境構成イメージについて解説します。

CodePipelineの概要

CodePipelineはアプリケーションのソースコードコミット／プッシュやプルリクエストを契機として、テスト／ビルドやステージング／プロダクション環境へのデプロイといった一連のソフトウェアリリースプロセスを自動化／可視化し、継続的デリバリーを実現するサービスです。主な特徴やメリットとして、以下のような点が挙げられます。

• ECR、S3、ElasticBeanstalk、CodeCommit、CodeDeploy、CodeBuild、LambdaといったAWSのさまざまなサービスと統合し、リリースプロセスを構築できること
アプリケーション実行環境となるECSやEC2などへのデプロイをシームレスに行えること
• クラウド実行ベースのCodeBuildとの連携により、マシンリソースを気にせず、さまざまなソースコードレポジトリに対して同時に多数のビルド処理やデプロイを同時実行できること
• GitHubやJenkinsなどの主要なレポジトリやCIツールとの連携もシームレスに実行できること

それでは、CodePipelineを使い、冒頭の図で示したマイクロサービスアーキテクチャにおけるアプリケーションリリースプロセスの自動化を実際に進めていきましょう。

マイクロサービスでのパイプライン構成

先に示したブランチ構成のイメージに基づき、feature/＊＊＊＊ブランチから、developブランチへのPRを契機として、以下のようなリリースプロセスに基づくパイプラインを構成します。

各パイプラインの具体的な処理のイメージは以下の通りです。

1. バックエンドのマイクロサービスのコンテナイメージのビルド
1. CodeBuildがbackendアプリケーションのステージング環境向けbuildspec.ymlに記載したビルド処理を行うコンテナを実行します。
2. ビルド処理の中で、アプリケーション実行コンテナイメージを作成し、DockerHubへプッシュします。

バックエンドのマイクロサービスのコンテナイメージのビルド

2. マイクロサービスコンテナイメージをプロダクションとほぼ同等のステージング環境へデプロイ
1. ECSクラスタ上にアプリケーションコンテナを実行させる命令を発出します。
2. ECSエージェントが(1-2)でプッシュしたコンテナをECSクラスタ上にプルします。
3. ECSクラスタ上でアプリケーションコンテナが実行されます。

プロダクションとほぼ同等のステージング環境へデプロイ

3. Webアプリケーション(BFF)のE2Eテストとして、Seleniumテストコード実行
1. CodeBuildがBFFアプリケーションのbuildspec_e2e.ymlに記載したビルド処理(テスト)を行うコンテナを実行します。
2. ビルド処理の中で、GitHubからBFFのアプリケーションソースコードをクローンします。
3. ビルド処理の中で、MavenビルドによりSeleniumを使ったE2Eテストを実行します。E2Eテストでは2でデプロイしたバックエンドアプリケーションの呼び出しを通してテスト実行されます。

Seleniumテストコード実行

4. Webアプリケーション(BFF)のコンテナイメージのビルド
1. CodeBuildがBFFアプリケーションのステージング環境向けbuildspec.ymlに記載したビルド処理を行うコンテナを実行します。
2. ビルド処理の中で、アプリケーション実行コンテナイメージを作成し、DockerHubへプッシュします。

コンテナイメージのビルド

5. Webアプリケーション(BFF)のステージング環境へデプロイ
1. ECSクラスタ上にアプリケーションコンテナを実行させる命令を発出します。
2. ECSエージェントが(4-2)でプッシュしたコンテナをECSクラスタ上にプルします。
3. ECSクラスタ上でアプリケーションコンテナが実行されます。

ステージング環境へデプロイ

6. パフォーマンステストやセキュリティテスト、受入などのその他テスト後の管理者によるリリース承認
1. CodePipelineがSNSに対し承認のトピックを発行し、パイプラインを一時停止させます。
2. デプロイされたBackendおよびBFFアプリケーションに対してパフォーマンステストやセキュリティテストを実行します。
3. テストの結果を踏まえ、プロダクトオーナーやマネージャがAWSコンソールでCodePipeline上で保留しているトピックを承認／否認します。

テスト後の管理者によるリリース承認

7. ステージング環境でテスト済みのコンテナイメージをリリース用にタグ付けして、DockerHubへプッシュ
1. CodeBuildがアプリケーションのプロダクション環境向けbuildspec.ymlに記載したビルド処理を行うコンテナを実行します(BackendおよびBFFは並列実行)。
2. 各々ビルド処理の中で、アプリケーション実行コンテナイメージを作成し、DockerHubへプッシュします。

DockerHubへプッシュ

8. プロダクション環境へリリース
1. ECSクラスタ上にアプリケーションコンテナを実行させる命令を発出します(BackendおよびBFFは並列実行)。
2. ECSエージェントが(7-2)でプッシュしたコンテナを、各々ECSクラスタ上にプルします。
3. 各々ECSクラスタ上でアプリケーションコンテナが実行されます。

次回以降は、各パイプラインの処理の内容を順次説明し、実際に環境を構築していきます。