本連載では、マイクロサービスアーキテクチャでの継続的デリバリ(Continuous Delivery:CD)を以下のようなパイプラインで実現していきます。
前回は(1)バックエンドのマイクロサービスアプリケーションをビルドし、コンテナイメージを作成してDockerHubへプッシュするパイプライン処理を構築しました。今回はプッシュしたコンテナイメージをECSクラスタ上にデプロイするパイプラインを構築します。
パイプラインの設定を行う前に、マイクロサービスをデプロイする先であるステージング環境のアプリケーションロードバランサ、ECSクラスタ、タスク定義、サービスの構築を行います。 作成方法の要領は、以下の手順と同様です。
ただし、この事前準備では、以下の設定に留意が必要です。
設定箇所 | 設定内容 | 説明 |
基本設定:ECSタスク定義 | タスクサイズ:タスクメモリ | SpringBootアプリケーションであれば1024MB以上を目処に設定した方がベターです。起動時間がかかり、ヘルスチェックがNGになる可能性があります。 |
基本設定:ECSタスク定義 | タスクサイズ:タスクCPU | 0.25〜0.5 vcpuを目処に設定します。ECSクラスタのスペックにもよりますが、小さすぎると上記のタスクメモリの設定同様、起動に時間がかかりヘルスチェックがNGになる可能性がありますが、逆に大きすぎるとパイプライン処理のコンテナ再起動時にリソースが足りず、エラーとなる可能性があります。 |
基本設定:ECSタスク定義 | コンテナの編集:コンテナ名 | 前回作成したbuildspec.ymlのアーティファクトで指定したimagedefinitions.jsonのname属性と一致した名前を設定する必要があります。 |
基本設定:ECSタスク定義 | コンテナの編集:イメージ | buildspec.yml及びSystemsManagerParameterStoreで環境変数として設定した値のイメージ名とバージョンを指定します。 |
前回作成したベースのパイプラインに、ステージング環境として構築したECSクラスタにマイクロサービスをデプロイするパイプラインを追加します。 CodePipelineサービスメニューから、前回作成したパイプラインを選択し、「編集する」ボタンを押下して末尾にある「ステージを追加する」ボタンを押下します。
ステージングへデプロイするためのステージを追加します。
「アクションを追加する」ボタンを押下して、以下の要領でステージングデプロイアクションを設定します。
注釈
なお、入力アーティファクトは、前回のパイプラインの出力アーティファクトですが、S3上に実体となるファイルが保存されています。
作成が完了したら、「変更をリリースする」ボタンを押下して、パイプラインを実行しなおしてみましょう。グリーンで表示されれば正常完了です。 ECSタスクのリビジョンがあがり、ECSサービスのイベントログでは、コネクションドレイニングされて、実行コンテナが入れ替わったことがわかります。
これでBakcendサービスのコンテナイメージをステージング環境へデプロイするパイプラインが完成し、プッシュしたコンテナがECSクラスタ上で起動しました。 次回以降は、Web(BFF)アプリケーションをビルドし、Seleniumを使用したE2Eテストを自動実行するパイプラインを作成します。
川畑 光平(KAWABATA Kohei) - NTTデータ 課長代理
金融機関システム業務アプリケーション開発・システム基盤担当を経て、現在はソフトウェア開発自動化関連の研究開発・推進に従事。
Red Hat Certified Engineer、Pivotal Certified Spring Professional、AWS Certified Solutions Architect Professional等の資格を持ち、アプリケーション基盤・クラウドなど様々な開発プロジェクト支援にも携わる。