More than 3 years have passed since last update.

CloudFormationでECSクラスター(開発、QA、本番)へのビルド・デプロイパイプライン構築の自動化

Last updated at 2020-06-18Posted at 2020-06-18

ECSのクラスターに対するパイプラインのリファレンス・アーキテクチャについては以下のGithubリポジトリで公開されています。
ECS Reference Architecture: Continuous Deployment

こちらで公開されているCloudFormationテンプレートでは本番環境を想定したECSクラスターに対してコンテナイメージのビルド・デプロイを自動化するパイプラインを構築し、パイプラインを実際に動作させるために必要な以下のAWSリソースが自動的に作成されます。

DeploymentPipeline:デプロイメント・パイプラインを構成するCodeBuildプロジェクト、CodePipelineパイプライン、CodePipelineのアーティファクト・ストア用のS3バケット、これらのサービスに必要なIAMロールを含めたAWSリソース、サンプルアプリケーションのためのECRリポジトリ(このテンプレートはCodePipelineパイプラインが継続的にサンプル・アプリケーションをデプロイするターゲットとして使用される)
Service: ECSタスク定義、ECSサービス、IAMロール
Cluster:ECSクラスター（起動タイプでEC2を選択した場合はECS最適化されたAMIで起動されたEC2インスタンスのAutoScaling Groupも含む）
Load Balancer:サンプル・アプリケーションへのトラフィックに使用されるApplication Load Balancer
VPC:VPCと異なる2つのAvailability Zoneに分離された2つのパプリック・サブネット、インターネット・ゲートウェイ、パプリック・インターネントへのデフォルト・ルートを伴うルート・テーブル

このリファレンス・アーキテクチャのサンプルではパイプラインのデモをする際に必要なすべてのリソースが作成されてしまうためプロジェクトではそのまま使用できないため以下の拡張を行いました。

前述のリソースのうちDeploymentPipeline以外のリソースを除外（別チームが担当するため）
前述のDeploymentPipeline内のIAMロールおよびS3バケット（別チームが担当するため）
パイプラインを実行環境（開発、QA、本番）の数分作成するように拡張
パイプラインのビルド・ステージに単体テスト用のCodeBuildプロジェクト実行ステップを追加
本番用のパイプラインのビルド・ステージの先頭で承認ステップを追加し、承認がないとパイプラインが実行されないように拡張。なお、承認依頼の通知が指定のAmazon SNSトピックに飛ぶように構成
パイプライン内で使用するCodeBuildプロジェクトは各環境用のパイプラインで共通に使用できるためテンプレートを分離

この拡張の結果作成したテンプレートについては以下のGithubリポジトリで公開しています。
ECS Continuous Deployment Architecture

こちらで公開している手順でパイプラインを構築することで、上図で示されるパイプラインが実行環境ごとに作成されます。

手順はGithubリポジトリの方にも記載していますが、この記事には画面ショットも含めたステップ・バイ・ステップの形式で手順を記載します。

0. 前提条件

ECSクラスタの実行環境が構築済みであること
- パイプラインテスト用ECS実行環境構築手順はこちらを参照してください
ECRリポジトリが作成済みであること
- 開発用、QA用、本番用の3つのECRリポジトリが必要
本番環境パイプラインにおける承認通知用のSNSトピックが作成済みであること
- 実際の通知が不要な場合はSNSトピックのみ作成でもOK
- 通知が必要な場合はお好きな通知方法でトピックに紐付けるサブスクリプションを追加
CodePipelineのアーティファクトストア用S3バケットが作成済みであること
- 任意の名前でS3バケットを作成
- この名前を
CodePipelineおよびCodeBuild、CloudWatch events用のIAMロールが設定済みであること
- CodePipeline用のIAMロールに関してはGithubに記載のもののままでOK
- CloudWatch events用のIAMロールに関してはGithubに記載のもののままでOK
- CodeBuild用のIAMロールに関してはGithubに記載のものの環境固有の情報を置換したものを設定

以下のAWS Account IDをご自身のIDに置換し、nodejs-build-project-nameおよびcontainerImage-build-project-nameを後ほど作成するNodeJSアプリケーションビルド用CodeBuildプロジェクト名とコンテナ・イメージビルド用CodeBuildプロジェクト名に置換します。

"Resource": [
    "arn:aws:logs:ap-northeast-1:<AWS Account ID>:log-group:/aws/codebuild/<nodejs-build-project-name>",
    "arn:aws:logs:ap-northeast-1:<AWS Account ID>:log-group:/aws/codebuild/<nodejs-build-project-name>:*",
    "arn:aws:logs:ap-northeast-1:<AWS Account ID>:log-group:/aws/codebuild/<containerImage-build-project-name>",
    "arn:aws:logs:ap-northeast-1:<AWS Account ID>:log-group:/aws/codebuild/<containerImage-build-project-name>:*"
],

以下のs3-bucket-nameを任意のシステム名接頭語に置換します。

"Resource": [
    "arn:aws:s3:::<s3-bucket-name>*"
],

1. AWS CodeBuildプロジェクトの作成

前述したとおりパイプライン内で使用するCodeBuildプロジェクトは全てのパイプラインから共通で使用可能であるため、パイプライン本体のCloudFormationスタックとは別に作成します。

1.1. NodeJSアプリケーションビルド用CodeBuildプロジェクトの作成

Githubの手順4の下のデプロイアイコンをクリックする
スタックのクイック作成画面に以下のパラメータを入力してスタックの作成をクリック

パラメータの説明	パラメータの値
What is the CodeBuild Project Name for Node.js application build?	NodeJSアプリケーションビルド用CodeBuildプロジェクトの名前
Which CodeBuild service role should be used?	前提条件で作成したCodeBuild用のIAMロール名

イベントテーブルの一番上の行の論理IDが前の手順で入力したスタック名でステータスがCREATE_COMPLETEと表示されればOK

1.2. コンテナ・イメージビルド用CodeBuildプロジェクトの作成

Githubの手順5の下のデプロイアイコンをクリックする
スタックのクイック作成画面に以下のパラメータを入力してスタックの作成をクリック

パラメータの説明	パラメータの値
What is the CodeBuild Project Name for Container images build?	コンテナ・イメージビルド用CodeBuildプロジェクトの名前
Which CodeBuild service role should be used?	前提条件で作成したCodeBuild用のIAMロール名

イベントテーブルの一番上の行の論理IDが前の手順で入力したスタック名でステータスがCREATE_COMPLETEと表示されればOK

2. AWS CodeCommitリポジトリの整備

ここではパイプラインのSourceステージの入力となるソースコード管理のリポジトリとしてAWS CodeCommitのリポジトリを作成します。

2.1. AWS CodeCommitリポジトリの作成

AWS CodeCommitのコンソールを開く
リポジトリの作成をクリック
任意のリポジトリ名を入力し、作成をクリック
リポジトリの作成が成功したことを確認

2.2. AWS CodeCommitリポジトリへのパイプライン用ファイルの配置

サンプル・アプリケーションのGithubリポジトリの内容をダウンロードする
ローカルコンピュータへ2.1で作成したCodeCommitリポジトリのクローンを作成する

（参考）AWS CodeCommit リポジトリに接続する - AWS CodeCommit
リポジトリのクローンを作成して CodeCommit リポジトリに接続する
https://docs.aws.amazon.com/ja_jp/codecommit/latest/userguide/how-to-connect.html#how-to-connect-http

CodeCommitのリポジトリにサンプル・アプリケーションの内容をPUSHする

（参考）AWS CodeCommit でコミットを作成する - AWS CodeCommit
https://docs.aws.amazon.com/ja_jp/codecommit/latest/userguide/how-to-create-commit.html

2.3. AWS CodeCommitリポジトリのブランチ作成

AWS CodeCommitのコンソールを開き、2.1で作成したCodeCommitリポジトリを選択し左メニューからブランチを選択する
ブランチ一覧の右上にあるブランチの作成をクリックする
ブランチ名にQA環境用のブランチ名を入力し、ブランチ元にmasterを入力し、ブランチの作成をクリックする
同様の手順で本番環境用のブランチも作成する

3. AWS CodePipelineパイプラインの作成

ここではメインとなるCodePipelineのパイプラインをCloudFormationのテンプレートから作成します

3.1 開発、QA、本番環境用パイプラインの作成

Githubの手順6の下のデプロイアイコンをクリックする
スタックのクイック作成画面に以下のパラメータを入力してスタックの作成をクリック

パラメータの説明	パラメータの値
What is the Code Pipeline Name for the development environment?	開発環境用パイプライン名
What is the Code Pipeline Name for the quality assurance environment?	QA環境用パイプライン名
What is the Code Pipeline Name for the production environment?	本番環境用パイプライン名
Which CodePipeline service role should be used?	前提条件で作成したCodePipeline用のIAMロール名
Which s3 bucket should be used for a codepipeline artifact store?	前提条件で作成したCodePipelineのアーティファクトストア用S3バケット
Which SNS Topic should be used for the approval of a production deployment?	前提条件で作成した本番環境パイプラインにおける承認通知用のSNSトピック
Which Role should be used for CloudWatch Event?	前提条件で作成したCloudWatch events用のIAMロール名
Which CodeCommit Repository should be used?	2.1で作成したCodeCommitリポジトリ名
Which CodeCommit Branch should be used for the development environment?	master
Which CodeCommit Branch should be used for the quality assurance environment?	2.3で作成したQA環境用のブランチ名
Which CodeCommit Branch should be used for the production environment?	2.3で作成した本番環境用のブランチ名
Which CodeBuild Project should be used for Node.js application build?	1.1で作成したNodeJSアプリケーションビルド用CodeBuildプロジェクト名
Which CodeBuild Project should be used for container image build?	1.2で作成したコンテナ・イメージビルド用CodeBuildプロジェクト名
What is the ECR Repository Name for the development environment?	開発環境用のECRリポジトリ名
What is the ECR Repository Name for the quality assurance environment?	QA環境用のECRリポジトリ名
What is the ECR Repository Name for the production environment?	本番環境用のECRリポジトリ名
What is the ECS Container Name?	現在ECSで稼働しているタスク定義上のアプリケーションがデプロイされているコンテナの名前
Describe lifecycle policy text for the development environment?	開発環境用のECRリポジトリに適用されるライフサイクルポリシーのJSON文字列。デフォルト値では最大5つまでのイメージを保持する設定となっているため設定変更が不要であれば修正不要
Describe lifecycle policy text for the quality assurance environment?	QA環境用のECRリポジトリに適用されるライフサイクルポリシーのJSON文字列
Describe lifecycle policy text for the production environment?	本番環境用のECRリポジトリに適用されるライフサイクルポリシーのJSON文字列
Which ECS Cluster should a container image be deployed to for the development environment?	前提条件で作成した開発環境用のECSクラスター名
Which ECS Cluster should a container image be deployed to for the quality assurance environment?	前提条件で作成したQA環境用のECSクラスター名
Which ECS Cluster should a container image be deployed to for the production environment?	前提条件で作成した本番環境用のECSクラスター名
Which ECS Service should a container image be deployed to for the development environment?	前提条件で作成した開発環境用のECSサービス名
Which ECS Service should a container image be deployed to for the quality assurance environment?	前提条件で作成したQA環境用のECSサービス名
Which ECS Service should a container image be deployed to for the production environment?	前提条件で作成した本番環境用のECSサービス名

イベントテーブルの一番上の行の論理IDが前の手順で入力したスタック名でステータスが「CREATE_COMPLETE」と表示されればOK

4. パイプラインの動作確認

ここでは作成された各環境のパイプラインの動作を確認します。
※パイプラインは作成したタイミングで自動的に初回実行されるため注意が必要。開発環境用のパイプラインに関しては設定に問題がなければこの時点で全て成功で完了するはず。QAと本番はブランチにソースがマージされていないために失敗する想定。

4.1. 開発環境へのデプロイ

開発環境のパイプラインはCodeCommitリポジトリのmasterブランチへのPUSHをトリガーとしているため、サンプル・アプリケーションを変更してPUSHすることで、パイプラインが変更内容をECSに自動的に反映することを確認します。

2.1で作成したCodeCommitリポジトリにアクセスし、app.jsを表示する
- 現在はHello worldが応答されることが確認できる
Hello worldをHello ECS Continuous Delivery Worldに変更し、変更のコミットをクリックする
CodePipelineのコンソールを開き、開発環境用のパイプラインが進行中となっていることを確認し、パイプライン名を選択して開く

全てのステージが完了するまで待機
- 前提条件で作成したIAMロールの権限に問題がある場合には失敗してしまうので、不足している権限をログから確認して正しく設定すること
全てのステージが完了したことを確認
- Deployステージが完了するのに結構時間がかかります
パイプラインが完了したら開発環境のECSサービスのエンドポイントにアクセスし、サンプル・アプリケーションの応答メッセージが変更されていればOK

4.2. QA環境へのデプロイ

QA環境のパイプラインはCodeCommitリポジトリのQA環境用ブランチへのPUSHをトリガーとしているため、masterブランチでの変更をマージすることで、パイプラインが変更内容をECSに自動的に反映することを確認します。
※CodeCommitの機能の都合上プルリクエストを使用してマージする手順で記載しています。

2.1で作成したCodeCommitリポジトリにアクセスし、プルリクエストの作成をクリックする
プルリクエストの作成画面でターゲットにQA環境用ブランチを選択し、ソースにmasterを選択し、比較をクリックする
変更内容を確認の上プルリクエストのタイトルを入力し、プルリクエストの作成をクリックする
マージをクリックし、QA環境用ブランチへマージする
マージ戦略で任意の方法を選択し、プルリクエストのマージをクリックする
マージが正しく完了したことを確認する
CodePipelineのコンソールを開き、QA環境用のパイプラインが実行されていることを確認
以降の手順は開発環境のパイプラインと同様で、パイプラインが完了したらECSサービスのエンドポイントにアクセスし、サンプル・アプリケーションの応答メッセージが変更されていればOK

4.3. 本番環境へのデプロイ

本番環境についてはマージ先のブランチが異なる以外は基本的にQA環境と同様の手順で確認できますが、パイプラインが開始したらパイプライン実行の承認が必要となります。パイプラインの承認は以下の手順で実施してください。

CodePipelineのコンソールを開き、本番環境用のパイプラインが実行されており、BuildステージのApprovalステップで承認を待機中となっていることを確認
Approvalステップ内のレビューをクリックし、表示されたダイアログで承認しますをクリックする