パイプラインの構築（その8）

本連載では、マイクロサービスアーキテクチャでの継続的デリバリ(CD：Continuous Delivery:CD)を以下のようなパイプラインで実装する方法について、解説を進めています。

前回は、プロダクション環境向けのアプリケーションのコンテナイメージをビルドしてDockerHubへプッシュするパイプラインを構築しました。今回は、そのコンテナをプロダクション環境へデプロイするパイプラインを構築します。

プロダクション環境へのリリース

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

事前準備：アプリケーションのプロダクション環境の構築

パイプラインの設定を行う前に、第17回と同様にプロダクション環境のアプリケーションロードバランサ、ECSクラスタ、タスク定義、サービスの構築をBackendとBFF両方で行います。

構築にあたり、留意する必要がある設定は第14回で解説した通りです。加えて、以下の環境変数の設定にも留意してください。

AWS Sysmtems Managers Parameter Storeでの環境変数の定義

CodePipelineの設定を行う前に、前節のECSで使用する環境変数を定義しておきます。設定の要領は、第10回と同様です。以下のパラメータを定義します。

• “SERVICE_DNS_PRODUCTION”：前節で作成したアプリケーションロードバランサーのDNS

プロダクション環境デプロイのパイプラインの作成

これまで作成してきたCodePipelineを編集して、プロダクション環境へのデプロイパイプラインを設定します。AWSコンソールの「CodePipeline」サービスを選択し、パイプラインを選択して「編集する」ボタンを押下してください。

前回作成した、プロダクション環境のコンテナを作成したステージにデプロイアクションを追加します。「ステージを編集する」ボタンを押下し、新たなアクショングループを追加してください。

まず、Backendのコンテナイメージをデプロイするための設定を追加します。以下の要領でアクションを設定し、「完了」ボタンを押下します。

• アクション名：任意のアクション名を追加します
• アクションプロバイダー：「Amazon ECS」を選択します
• リージョン：プロダクション環境があるリージョンを選択します
• 入力アーティファクト：前回のコンテナをビルドするパイプラインで出力アーティファクトとなっている「BuildArtifact-backend-production」を選択します。なお、この実体はimagedefinition.jsonであり、S3に保存されています
• クラスタ名：前節で作成したECSクラスタを選択します
• サービス名：前節で作成したECSサービスを選択します
• イメージ定義ファイル：前回のパイプライン処理でbuildspec.ymlで出力したimagedefition.jsonを設定します

同様に、BFFのコンテナイメージを並列実行してデプロイするための設定を追加します。上記で作成したアクションの横にある「アクションの追加」を選んだ後、同様の要領でアクションを設定します。

設定完了後、「変更をリリースする」ボタンを押下し、デプロイが問題なく完了するかどうかを確認します。

マイクロサービスにおける継続的デリバリーのまとめ

以上、ここまでの連載で、E2Eテストを含め、以下のような継続的デリバリーをCodePipelineを使って構築してきました。

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

なお、今回はトピックスには盛り込んでいませんが、デプロイのオプションとしてECSブルーグリーンデプロイメントを選択することで、一部のアプリケーションコンテナのみを新しいバージョンで試しながらリリースすることもできます。

クラウドベースのCI/CDサービスであるCodeBuildやCodePipelineを活用することにより、複数のマイクロサービスの並列ビルド／デプロイや、マルチOS／ブラウザでのE2Eテストの並列実行などを容易に実現できることがおわかりいただけたのではないでしょうか。

複数のサービスが連携するマイクロサービスでは、各サービスごとに独立してビルドやテスト、デプロイなどを行います。継続的インテグレーションや継続的デリバリーの仕組みも、スケーラビリティに優れたCI/CDサービスを利用することで、開発におけるアジリティ／耐障害性の向上といった、マイクロサービスアーキテクチャのメリットをより享受できるようになります。

また、SystemsManagerParameterStoreなどを活用し、ステージング環境でテストしたアプリケーションのコンテナイメージの環境変数だけを差し替えて、そのままプロダクション環境へ持っていけば、プロダクション向けのビルドが省略できます。これにより、本番環境起因のバグリスクを極力下げながら、リリースも迅速に行うことが可能です。

次回以降は、これまで構築してきたクラウドネイティブアプリケーションおよび継続的インテグレーション・デリバリ環境の一括構築をIaC(InfrastructureAsCode)として行うCloudFormationを使った開発手法について概説していきます。