パイプラインの構築(その8)

【連載】

AWSで実践! 基盤構築・デプロイ自動化

【第20回】パイプラインの構築(その8)

[2019/11/07 09:00]川畑 光平 ブックマーク ブックマーク

開発ソフトウェア

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

本連載で実装を進めている継続的デリバリのパイプライン

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

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

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

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

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

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

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

設定箇所 設定内容 説明
ECSタスク定義:コンテナの追加 環境:環境変数 バックエンドマイクロサービスへパスルーティングするアプリケーションロードバランサのDNSをSERVICE_DNS環境変数として設定します。プロダクション環境での具体的な設定値は、SystemsManagerParameterStoreで定義した"SERVICE_DNS_PRODUCTION"から取得するよう、ValueFromフィールドを設定します

環境変数の設定

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

FFのコンテナイメージを並列実行してデプロイするための設定を追加

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

デプロイが問題なく完了するかどうかを確認する

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

以上、ここまでの連載で、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を使った開発手法について概説していきます。

著者紹介


川畑 光平(KAWABATA Kohei) - NTTデータ 課長代理

金融機関システム業務アプリケーション開発・システム基盤担当を経て、現在はソフトウェア開発自動化関連の研究開発・推進に従事。

Red Hat Certified Engineer、Pivotal Certified Spring Professional、AWS Certified Solutions Architect Professional等の資格を持ち、アプリケーション基盤・クラウドなどさまざまな開発プロジェクト支援にも携わる。2019 APN AWS Top Engineers & Ambassadors選出。

本連載の内容に対するご意見・ご質問は Facebook まで。

※ 本記事は掲載時点の情報であり、最新のものとは異なる場合がございます。予めご了承ください。

一覧はこちら

連載目次

この記事に興味を持ったら"いいね!"を Click
Facebook で IT Search+ の人気記事をお届けします

会員登録(無料)

注目の特集/連載
[解説動画] Googleアナリティクス分析&活用講座 - Webサイト改善の正しい考え方
[解説動画] 個人の業務効率化術 - 短時間集中はこうして作る
ミッションステートメント
教えてカナコさん! これならわかるAI入門
知りたい! カナコさん 皆で話そうAIのコト
対話システムをつくろう! Python超入門
Kubernetes入門
AWSで作るクラウドネイティブアプリケーションの基本
PowerShell Core入門
徹底研究! ハイブリッドクラウド
マイナビニュース スペシャルセミナー 講演レポート/当日講演資料 まとめ
セキュリティアワード特設ページ

一覧はこちら

今注目のIT用語の意味を事典でチェック!

一覧はこちら

ページの先頭に戻る