[概要]前提条件と制限アーキテクチャツールエピック関連リソース追加情報添付ファイル

を使用してマイクロサービス用の CI/CD パイプラインと Amazon ECSクラスターを自動的に構築する AWS CDK

作成者: Varsha Raju (AWS）

環境：PoC またはパイロット

テクノロジー: DevOps、コンテナとマイクロサービス、モダナイゼーション、インフラストラクチャ

AWS サービス: AWS CodeBuild、AWS CodeCommit、AWS CodePipeline、Amazon ECS、 AWS CDK

[概要]

このパターンでは、Amazon Elastic Container Service (Amazon ) でマイクロサービスを構築およびデプロイするための継続的統合および継続的配信 (CI/CD) パイプラインと基盤となるインフラストラクチャを自動的に作成する方法について説明しますECS。このアプローチは、CI/CD、マイクロサービス、の利点を組織に示すために CI/CD パイプラインをセットアップ proof-of-conceptする場合に使用できます DevOps。また、このアプローチを使用して最初の CI/CD パイプラインを作成し、組織の要件に応じてカスタマイズまたは変更もできます。

このパターンのアプローチにより、それぞれに仮想プライベートクラウド (VPC) と 2 つのアベイラビリティーゾーンで動作するように設定された Amazon ECSクラスターを持つ本番環境と非本番環境が作成されます。これらの環境はすべてのマイクロサービスとユーザーで共有され、各マイクロサービスに CI/CD パイプラインを作成します。これらの CI/CD パイプラインは、のソースリポジトリから変更をプルしAWS CodeCommit、自動的に変更を構築し、本番環境と非本番環境にデプロイします。パイプラインがすべてのステージを正常に完了すると、 URLsを使用して本番稼働環境と非本番稼働環境でマイクロサービスにアクセスできます。

前提条件と制限

前提条件

アクティブな Amazon Web Services (AWS) アカウント。
starter-code.zip ファイル (添付) を含む既存の Amazon Simple Storage Service (Amazon S3) バケット。
AWS Cloud Development Kit (AWS CDK) は、アカウントにインストールおよび設定されています。詳細については、 AWSCDKドキュメントAWSの「の開始方法CDK」を参照してください。
Python 3 と pip をインストールおよび設定済みです。詳細については、Python のドキュメントを参照してください。
AWS CDK、AWS CodePipeline、AWS CodeBuild、 CodeCommit、Amazon Elastic Container Registry (Amazon ECR）、Amazon ECS、および AWS Fargate に精通していること。
Docker に精通していること。
CI/CD との理解 DevOps。

制約事項

一般的なAWSアカウント制限が適用されます。詳細については、AWS「全般のリファレンス」ドキュメントのAWS「サービスクォータ」を参照してください。

製品バージョン

このコードは、Node.js バージョン 16.13.0 とAWSCDKバージョン 1.132.0 を使用してテストされました。

アーキテクチャ

AWS クラウド architecture diagram showing CI/CD pipeline and deployment to production and non-production VPCs.

この図表は、次のワークフローを示しています：

アプリケーションデベロッパーは、コードを CodeCommit リポジトリにコミットします。
パイプラインが開始されます。
CodeBuild Docker イメージを構築して Amazon ECRリポジトリにプッシュする
CodePipeline は、本番環境以外の Amazon ECSクラスター内の既存の Fargate サービスに新しいイメージをデプロイします。
Amazon は、Amazon ECRリポジトリから非本番環境の Fargate サービスにイメージをECSプルします。
テストは非本番を使用して実行されますURL。
リリースマネージャーは本番環境へのデプロイを承認します。
CodePipeline は、本番環境の Amazon ECSクラスター内の既存の Fargate サービスに新しいイメージをデプロイします。
Amazon は、Amazon ECRリポジトリから本番稼働の Fargate サービスにイメージをECSプルします。
本番稼働ユーザーは、本番稼働用を使用して機能にアクセスしますURL。

テクノロジースタック

AWS CDK
CodeBuild
CodeCommit
CodePipeline
Amazon ECR
Amazon ECS
Amazon VPC

自動化とスケール

このパターンのアプローチを使用して、共有AWS CloudFormation スタックにデプロイされたマイクロサービスのパイプラインを作成できます。自動化により、それぞれに複数の Amazon ECSクラスターを作成しVPC、共有 Amazon ECSクラスターにデプロイされたマイクロサービスのパイプラインを作成することもできます。ただし、そのためには、新しいリソース情報をパイプラインスタックへの入力として提供する必要があります。

ツール

AWS CDK – AWS Cloud Development Kit (AWS CDK) は、コードでクラウドインフラストラクチャを定義し、を通じてプロビジョニングするためのソフトウェア開発フレームワークですAWS CloudFormation。
AWS CodeBuild- AWS CodeBuild は、Cloud でフルマネージド型のビルドサービスです。はソースコードを CodeBuild コンパイルし、ユニットテストを実行し、デプロイする準備ができているアーティファクトを生成します。
AWS CodeCommit – AWS CodeCommit は、Git リポジトリを AWS Cloud にプライベートに保存および管理できるバージョンコントロールサービスです。は、独自のソースコントロールシステムを管理する必要性や、インフラストラクチャのスケーリングを心配する必要性 CodeCommit を排除します。
AWS CodePipeline– AWS CodePipeline は、ソフトウェアのリリースに必要なステップをモデル化、視覚化、自動化するために使用できる継続的な配信サービスです。ソフトウェアリリースプロセスのさまざまな段階をすばやくモデル化して設定できます。は、ソフトウェアの変更を継続的にリリースするために必要なステップ CodePipeline を自動化します。
Amazon ECS – Amazon Elastic Container Service (Amazon ECS) は、クラスター上のコンテナの実行、停止、管理に使用される、スケーラブルで高速なコンテナ管理サービスです。AWS Fargate が管理するサーバーレスインフラストラクチャでタスクとサービスを実行できます。または、インフラストラクチャをより詳細に制御するために、管理する Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのクラスターでタスクとサービスを実行できます。
Docker — Dockerを使用すると、開発者は任意のアプリケーションを軽量、ポータブル、自給自足のコンテナとして梱包、出荷、実行する上で役立ちます。

コード

このパターンのコードは、cicdstarter.zip および starter-code.zip ファイル (添付) にあります。

エピック

タスク	説明	必要なスキル
の作業ディレクトリを設定しますAWSCDK。	ローカルマシンで `cicdproject` という名前のディレクトリを作成します。 `cicdstarter.zip` ファイル (添付)を `cicdproject` ディレクトリにダウンロードし、解凍します。これで、`cicdstarter` という名前のフォルダが作成されます。 `cd <user-home>/cicdproject/cicdstarter` コマンドを実行します。 `python3 -m venv .venv` コマンドを実行して Python 仮想環境を設定します。 `source ./.venv/bin/activate` コマンドを実行します。 `aws configure` コマンドを実行するか、次のAWS環境変数を使用して環境を設定します。 `AWS_ACCESS_KEY_ID` `AWS_SECRET_ACCESS_KEY` `AWS_DEFAULT_REGION`	AWS DevOps、クラウドインフラストラクチャ

タスク	説明	必要なスキル
共有インフラストラクチャを作成します。	作業ディレクトリで、`cd cicdvpcecs` コマンドを実行します。 `pip3 install -r requirements.txt` コマンドを実行して、必要な Python 依存関係をすべてインストールしますを実行して`cdk bootstrap command`、 AWS のAWS環境を設定しますCDK。 `cdk synth --context aws_account=<aws_account_ID> --context aws_region=<aws-region>` コマンドを実行します。 `cdk deploy --context aws_account=<aws_account_ID> --context aws_region=<aws-region>` コマンドを実行します。 AWS CloudFormation スタックは次のインフラストラクチャを作成します。 VPC という名前の非本番稼働 `cicd-vpc-ecs/cicd-vpc-nonprod` VPC という名前の本番稼働 `cicd-vpc-ecs/cicd-vpc-prod` という名前の非本番 Amazon ECSクラスター `cicd-ecs-nonprod` という名前の本番稼働用 Amazon ECSクラスター `cicd-ecs-prod`	AWS DevOps、クラウドインフラストラクチャ
AWS CloudFormation スタックをモニタリングします。	AWS マネジメントコンソールにサインインし、AWS CloudFormation コンソールを開き、リストから`cicd-vpc-ecs`スタックを選択します。スタックの詳細ペインで、[Events]（イベント）タブを選択し、スタックの作成の進行状況をモニタリングします。	AWS DevOps、クラウドインフラストラクチャ
AWS CloudFormation スタックをテストします。	`cicd-vpc-ecs` AWS CloudFormation スタックを作成したら、 `cicd-vpc-ecs/cicd-vpc-nonprod`と `cicd-vpc-ecs/cicd-vpc-prod`VPCsが作成されていることを確認します。 `cicd-ecs-nonprod` と `cicd-ecs-prod` Amazon ECSクラスターが作成されていることを確認します。重要：両方ので、2 IDsつの VPCsとIDsデフォルトのセキュリティグループのセキュリティグループを必ず記録してくださいVPCs。	AWS DevOps、クラウドインフラストラクチャ

タスク	説明	必要なスキル
マイクロサービスのインフラストラクチャーを作成します。	マイクロサービスに名前を付けます。たとえば、このパターンはマイクロサービスの名前として `myservice1` を使用します。作業ディレクトリで `cd <working-directory>/cdkpipeline` コマンドを実行します。 `pip3 install -r requirements.txt` コマンドを実行します。このパターンの追加情報セクションにある `cdk synth` コマンドをすべて実行します。このパターンの追加情報セクションにある `cdk deploy` コマンドをすべて実行します。注: ディレクトリの `cdk.json` ファイルを使用して、両方のコマンドの値を指定することもできます。	AWS DevOps、クラウドインフラストラクチャ
AWS CloudFormation スタックをモニタリングします。	AWS CloudFormation コンソールを開き、`myservice1-cicd-stack`スタックの進行状況をモニタリングします。最終的に、ステータスは `CREATE_COMPLETE` に変わります。	AWS DevOps、クラウドインフラストラクチャ
AWS CloudFormation スタックをテストします。	AWS CodeCommit コンソールで、という名前のリポジトリ`myservice1`が存在し、スターターコードが含まれていることを確認します。 AWS CodeBuild コンソールで、という名前のビルドプロジェクト`myservice1`が存在することを確認します。 Amazon ECRコンソールで、という名前の Amazon ECRリポジトリ`myservice1`が存在することを確認します。 Amazon ECSコンソールで、という名前の Fargate サービスが非本番稼働用と本番用の両方の Amazon ECSクラスター`myservice1`に存在することを確認します。 Amazon Elastic Compute Cloud (Amazon EC2) コンソールで、非本番環境および本番環境の Application Load Balancer が作成されていることを確認します。DNS の名前を記録しますALBs。 AWS CodePipeline コンソールで、という名前のパイプライン`myservice1`が存在することを確認します。`Source`、`Build`、`Deploy-NonProd` および `Deploy-Prod` ステージが必要です。パイプラインにも `in progress` ステータスが必要です。すべてのステージが完了するまでパイプラインを監視します。本番環境用に手動で承認します。ブラウザウィンドウで、 DNSの名前を入力しますALBs。アプリケーションは、非本番および本番に表示される`Hello World`はずですURLs。
パイプラインを使用します。	以前に作成した CodeCommit リポジトリを開き、 `index.js` ファイルを開きます。 `Hello World` を `Hello CI/CD` に置き換えます。変更を保存してメインブランチにコミットします。パイプラインが開始され、変更が`Build`、`Deploy-NonProd` および `Deploy-Prod` ステージを通過することを確認します。本番環境用に手動で承認します。本番稼働用と非稼働用の両方URLsにが表示されるようになりました`Hello CICD`。	AWS DevOps、クラウドインフラストラクチャ
各マイクロサービスにこのエピックを繰り返します。	このエピックのタスクを繰り返して、各マイクロサービスの CI/CD パイプラインを作成します。	AWS DevOps、クラウドインフラストラクチャ

追加情報

cdk synthコマンド


cdk synth --context aws_account=<aws_account_number> --context aws_region=<aws_region> --context vpc_nonprod_id=<id_of_non_production VPC> --context vpc_prod_id=<id_of_production_VPC> --context ecssg_nonprod_id=< default_security_group_id_of_non-production_VPC> --context ecssg_prod_id=<default_security_group_id_of_production_VPC> --context code_commit_s3_bucket_for_code=<S3 bucket name> --context code_commit_s3_object_key_for_code=<Object_key_of_starter_code> --context microservice_name=<name_of_microservice>

cdk deploy コマンド


cdk deploy --context aws_account=<aws_account_number> --context aws_region=<aws_region> --context vpc_nonprod_id=<id_of_non_production_VPC> --context vpc_prod_id=<id_of_production_VPC> --context ecssg_nonprod_id=< default_security_group_id_of_non-production_VPC> --context ecssg_prod_id=<default_security_group_id_of_production_VPC> --context code_commit_s3_bucket_for_code=<S3 bucket name> --context code_commit_s3_object_key_for_code=<Object_key_of_starter_code> --context microservice_name=<name_of_microservice>

添付ファイル

このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「attachment.zip」

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

Systems Manager の管理ポリシーをEC2インスタンスプロファイルに自動的にアタッチする

マイクロサービスで疎結合アーキテクチャを構築する