Amazon CodeCatalyst ブループリントを使用して .NET ウェブアプリケーションを構築し、AWS にデプロイする

このブログはソリューションアーキテクトの遠藤宣嗣が翻訳しました。原文はこちらです。

このブログ記事では、Amazon CodeCatalyst での .NET の使用に関する一連の投稿の最初の記事として、CodeCatalyst と AWS .NET deployment tool に含まれている ASP.NET Core Web API プロジェクトブループリントを使用して、.NET 6.0 ASP.NET Core Web API を構築して Amazon Elastic Container Service (Amazon ECS) にデプロイする方法について説明します。

Amazon CodeCatalystとは何ですか？これは、ソフトウェア開発チーム向けの新しいクラウドベースの統合コラボレーションサービスです。継続的インテグレーションおよび継続的デリバリー (CI/CD) ツールのフルセットを提供し、開発チームが作業を計画し、コードで共同作業を行い、アプリケーションを構築、テスト、デプロイするのに役立ちます。CodeCatalyst は、開発者の生産性を高め、チームがより少ない労力でより多くのことを達成できるように支援する豊富な機能セットを提供することでこれを実現します。

CodeCatalyst ビルドオプションについて

ASP.NET 6.0 ベースの Web API をビルドおよびデプロイするための CodeCatalyst の全体的なエクスペリエンスについて説明する前に、CodeCatalyst が提供する .NET アプリケーションのビルドオプションについて説明します。CodeCatalyst には、ワークフローを実行するための 2 つのコンピュートタイプがあります：

オンデマンドフリートは、Amazon Elastic Compute Cloud (Amazon EC2) または AWS Lambda を使用してフルマネージド型の Linux ベースのコンピュートで、ビルドアクションの開始時にプロビジョニングされ、終了時にプロビジョニング解除されます。
プロビジョニングされたフリートは、CodeCatalyst が管理する Linux または Windows ベースの Amazon EC2インスタンスを提供します。プロビジョニングされたフリートを使用するには、価格は Standard ティアである必要があります。

.NET アプリケーションを構築するには、任意のフリートタイプとオペレーティングシステムを選択できます。このブログ記事では、オンデマンドフリートを使用して .NET Web API を構築します。今後のブログ記事では、Windows ベースのプロビジョニングされたフリートを使用して .NET Framework アプリケーションを構築する方法について説明します。

前提条件

以下の前提条件の一覧を確認して、ご使用の環境で以下のセクションで説明するすべての手順が実行できることを確認してください。次のものが必要です。

AWS ビルダー ID。作成方法は製品ドキュメントに記載されています。
CodeCatalyst スペースへのアクセス。自分で作成する方法、または招待を受ける方法については、製品ドキュメントを参照してください。
CodeCatalyst スペースに追加された AWS アカウント。これは、デプロイするインフラストラクチャが AWS 内にあるためです。詳細は、製品ドキュメントをご覧ください。
スペースに追加する AWS アカウントの AWS Identity and Access Management (IAM) ロールで、CodeCatalyst をそのアカウントにデプロイできるようにします。このチュートリアルでは、製品ドキュメントの手順に従って、CodeCatalystPreviewDevelopmentAdministrator IAM ロールを作成し、CodeCatalyst スペースにアタッチします。ベストプラクティスとして、これらのロールには、チームの運用に必要な最小限のアクセス許可を割り当ててください。

CodeCatalyst プロジェクトの作成

前提条件を満たしたら、CodeCatalyst でプロジェクトを作成できます。CodeCatalyst アカウントにログインし、CodeCatalyst スペースに移動します。[プロジェクトの作成] を選択し、[ブループリントで開始] オプションを選択します（図 1）。

ブループリントは、アプリケーションのサポートファイルや依存関係を生成し、拡張するプロジェクト・シンセサイザーです。

図 1: CodeCatalyst .NET ブループリント画面

[ブループリントの選択] 検索ボックスに “.NET” と入力します。.NET アプリケーションで使用可能なブループリントの一覧が表示されます。このブログ記事を書いている時点では、次の 2 つのブループリントを使用できます。

ASP.NET Core Web API: CI/CD ワークフローと共に ASP.NET Core 6.0 Web API プロジェクトを作成し、アプリケーションをビルドして選択した AWS サービスにデプロイします。
.NET serverless application: アプリケーションをビルドして AWS Lambda にデプロイする CI/CD ワークフローと共に、.NET 6.0 AWS サーバーレスアプリケーションプロジェクトを作成します。

ブループリントを選択すると、右側にサイドパネルが表示され、詳細な説明、アーキテクチャの概要、接続とアクセス許可、およびブループリントによって作成されるプロジェクトリソースが表示されます（図 2）。

図 2: ASP.NET Core Web API ブループリントの説明画面

このブログでは、ASP.NET Core Web API ブループリントの使用について説明します。そのオプションを選択し、[次へ] を選択してプロジェクトの設定を続行します。

次の画面（図 3）では、CodeCatalyst がプロジェクトを作成するための構成オプションを提供します。このブループリントでは、次の情報を指定する必要があります。

図 3: ASP.NET Core Web API ブループリント構成画面

プロジェクト名（必須）: CodeCatalyst はそれを使用して、プロジェクトとデフォルトのソースコードリポジトリに名前を付けます。
環境（必須）:
- AWS アカウント接続とデプロイロール: デプロイ先の AWS アカウントと、アプリケーションのデプロイ時に CodeCatalyst が使用するロール。[AWS アカウントなし] を選択した場合は後で追加できますが、追加するまでワークフローは正常に実行されません。
- 言語: ソースコードを作成するために使用する .NET プログラミング言語。C# または F# を選択できます。
- AWS デプロイサービス: アプリケーションのデプロイ先としてサポートされている AWS サービス。[なし] を選択した場合、ワークフローファイルにはアプリケーションを AWS にデプロイするためのアクションは含まれません。
コード（オプション）:
- コードリポジトリ名: ソースコードリポジトリの名前。
- .NET プロジェクト名: 作成するプロジェクトと名前空間の名前。
- 本稼働環境のデプロイ: これを選択すると、負荷分散と AWS のサービスに割り当てられたより大きなリソースの両方を含む設定が使用されます。
- AWS リージョン: アプリケーションをデプロイするリージョン。

画面の右側（図 4）には、前の画面と同じ説明を含む、ブループリントに関する情報が表示されます。また、[コードの表示] と [ワークフローの表示] の 2 つの追加ボタンもあります。

図 4: ASP.NET Core Web API ブループリント情報画面

[コードの表示] を選択すると、プロジェクト構成に基づいてブループリントテンプレートによって生成されるコードファイルを調べることができるパネルが表示されます（図 5）。構成を変更すると、生成されたファイルが自動的に更新されます。

図 5: ASP.NET Core Web API ブループリントコードのプレビュー画面

[ワークフローの表示] を選択すると、ワークフローエディターが表示されます（図 6）。CodeCatalyst がプロジェクト構成に基づいて作成するワークフローを視覚的にまたは YAML 形式で表示します。プロジェクト構成を変更すると、生成されたコードビューの場合と同様に、ワークフローが更新されます。

図 6: ASP.NET Core Web API ブループリントワークフローのプレビュー画面

この例では、言語として C# を選択し、デプロイサービスとして Amazon Elastic Container Service を選択します。[プロジェクトの作成] を選択して、プロジェクトの作成を開始します（図 7）。これは数秒で完了するはずです。

図7:プロジェクト作成画面

生成されたファイルの探索

プロジェクトの作成が完了すると、プロジェクトの概要画面にリダイレクトされます。プロジェクトを構成するリポジトリ、ワークフロー、プルリクエストなどの情報を表示できます。プロジェクトの [概要] 画面で、[リポジトリの表示] ボタンを選択して、既定のソースコードリポジトリに移動します（図 8）。

図8:プロジェクトリポジトリ画面

プロジェクトのリポジトリページでは、ブループリントによって生成されたソースコードの構造が次のようになっていることが分かります（図 9 参照）。

図 9: ASP.NET Core Web API ブループリントで生成されたコード構造

次のフォルダーに注意してください。

.cloud9: 開発環境として使用する場合に AWS Cloud9 を設定するために使用される AWS Cloud9 ランナーが含まれます。
.codecatalyst
- deployment-settings: AWS Elastic Beanstalk (Windows & Linux)、AWS AppRunner、および Amazon ECS 上の AWS Fargate にデプロイするときに .NET デプロイで使用されるさまざまなデプロイ設定ファイルが含まれています。各ファイルには、本番用と非本番用の 2 種類があります。
workflows: アプリケーションをビルドしてデプロイするための CodeCatalyst ワークフローの YAML コードが含まれています。
.vscode: 開発環境として使用する場合の Visual Studio Code の既定の構成が含まれています。
src: プロジェクトのソースコードが含まれます。
tests: プロジェクトの単体テストが含まれます。

“devfile.yaml” という名前のファイルも作成されます。これは、CodeCatalyst 開発環境を構成するために使用されます。

続行する前に、ファイル構造をより詳細に確認して、CI/CD ワークフローで作成およびデプロイされる内容を理解することをお勧めします。

デフォルトの CI/CD ワークフローの探索

CodeCatalyst では、ワークフローは、CI/CD システムの一部としてコードをビルド、テスト、およびデプロイする方法を説明する自動化された手順です。ワークフローの実行中に実行する一連の手順またはアクションを定義し、ワークフローを開始するイベントまたはトリガーも定義します。

次に、ASP.NET Core Web API ブループリントによって生成されたワークフローを調べます。ナビゲーションメニューで、[CI/CD] メニューを展開し、[ワークフロー] を選択します（図 10）。

図 10: CodeCatalyst ワークフローメニュー項目

すでに pull-request と main の2つのワークフローが作成されていることに注意しましょう。pull-request ワークフローはプルリクエストに応じて実行され、main ワークフローは新しいコミットがリポジトリの main ブランチにプッシュされたときに実行されます。main ワークフローには、pull-request ワークフローと同じステップに加え、デプロイステップがあります。main ワークフローを選択して、その構成を調べてみましょう（図11）

図 11: ASP.NET Core Web API ブループリントで生成されたワークフロー

次の画面で、[Definition] タブを選択して、ワークフローの視覚的な表現と YAML 定義を並べて表示します（図12）。

図 12: ASP.NET Core Web API ブループリントのメインワークフロー YAML

ワークフローは、次の 3 つの主要な要素で構成されています。

Triggers: コミットがメインブランチにプッシュされるたびにワークフローを開始します。
Build_And_Test: デフォルトのビルドイメージで実行されている .NET 6 CLI を使用して、コードをビルドしてテストします。そして、./TestResults フォルダーにあるテストレポートを検索し、その結果を画面に表示します。
Deploy_To_AWS: AWS Deploy Tool for .NET を使用してアプリケーションを AWS にデプロイします。Amazon Linux 用の zip yum パッケージのような必要な依存関係をインストールし、使用する AWS 接続を設定します。
–apply に渡す JSON ファイルを変更することで、デプロイ先の AWS サービスを簡単に変更できます。

デフォルトの CI/CD ワークフローの実行

メインワークフローは、CodeCatalyst プロジェクトを作成するとすぐに初めて自動的に実行されます。この最初の実行は、完了するまでに 15 分から 30 分かかります。完了したら、図 13 に赤枠で示すように、Deploy_To_AWS アクション内で、 dotnet aws deploy コマンドのログの末尾にあるエンドポイントの Amazon ECS サービスロードバランサー URL に移動して、デプロイされたアプリケーションを確認できます。

図 13: ASP.NET Core Web API ブループリント成功実行ログ

AWS.NET デプロイツールの設定を調べる

AWS Deploy Tool for .NET は、.NET CLI と AWS Toolkit for Visual Studio の両方に対応するインタラクティブなツールであり、最小限の AWS 知識と数回のクリックまたはコマンドで .NET アプリケーションをデプロイできます。AWS Deploy Tool for .NET コマンドラインツールは、1 つのコマンドでアプリケーションをデプロイできるため、CI/CD に最適です。AWS Deploy Tool for .NET は、デプロイレシピとデプロイ設定の概念を通じて、複数のアプリケーションタイプと AWS コンピューティングサービスをサポートします。

.codecatalyst/deployment/settings/non-prod/ecs-fargate-deployment-settings.json でデプロイ設定の内容を調べることができます。このファイルは、.NET アプリケーション（この場合は AspNetAppEcsFargate）をデプロイするために使用するレシピを定義し、レシピで定義されたデフォルト値の一部をオーバーライドします。AspNetAppEcsFargate レシピの場合、Amazon ECS クラスタ名、vCPU 数、Amazon ECS タスク定義で使用するメモリ量などのオプションを上書きします。このレシピと他のすべてのレシピのオプション設定の詳細については、公式の GitHub repo を参照してください。

AspNetAppEcsFargate レシピを使用してアプリケーションをデプロイすると、.NET デプロイツールは次のタスクを実行します。

プロジェクト内の Dockerfile を検索し、docker build を実行します。Dockerfile が見つからない場合は、ツールが Dockerfile を試みます。
コンテナイメージをプッシュするための Amazon Elastic Container Registry (Amazon ECR) を作成します。
コンテナイメージを Amazon ECR リポジトリにプッシュします。
レシピに関連付けられた AWS Cloud Development Kit (AWS CDK) プロジェクトを、デプロイ設定ファイルで上書きした値でデプロイします。
ロードバランサーエンドポイントなどのコンソール AWS リソースの詳細に出力します。

レシピがデフォルトで作成するリソースがアプリケーションに必要なものでない場合は、カスタムデプロイプロジェクトを作成して、ニーズに合わせてカスタマイズできる AWS CDK プロジェクトを作成できます。

クリーンアップ

今後の課金を避けるために、CodeCatalyst ワークフローによって作成されたリソースを削除してください。このブログ記事で提供されている値を使用した場合、リソースは名前が付けられます：

AWS CloudFormation stack: CompanyHelloWebAPI
Amazon ECR repository: companyhellowebapi

まとめ

このブログ記事では、ASP.NET Core Web API ブループリントを使用して、Amazon ECS 上の AWS Fargate に .NET アプリケーションをデプロイする方法を学びました。ブループリントは、ソースコードリポジトリ、サンプルソースコード、CI/CD ワークフローを持つプロジェクトを作成し、AWS にデプロイする準備をすべて整えました。

これは、アプリケーションの道のりの出発点にすぎません。次に、独自のソースコードをプッシュし、独自のアプリケーションのニーズに合わせて CI/CD ワークフローを変更できます。

CodeCatalyst ブループリントがどのように .NET アプリケーションの開発を迅速に開始し、より生産的にするのに役立つかについてのアイデアがあれば、.NET on AWS の公式 Twitter ハンドルで共有してください。AWS 上で .NET アプリケーションを実行するための追加情報やリソースについては、.NET on AWS をご覧ください。

AWS は、貴社がクラウドを最大限に活用する方法を評価するお手伝いをします。クラウドでの最も重要なアプリケーションの移行とモダナイズで AWS を信頼する何百万ものお客様の仲間入りをしてください。Windows Server または SQL Server の最新化の詳細については、Windows on AWS をご覧ください。モダナイゼーションの旅を始めるには、今すぐお問い合わせください。

投稿者について

Cristobal Espinosa は Amazon Web Services のシニアソリューションアーキテクトです。AWS 上で稼働する .NET アプリケーションのモダナイゼーションを専門に支援。2009 年以来、オープン Web 技術、Kubernetes、CI/CD、クラウドネイティブサービスを使用して、レガシー .NET アプリケーションの近代化を支援しています。

Jagadeesh Chitikesi は、AWS のシニアマイクロソフトスペシャリストソリューションアーキテクトです。彼は過去20年間、ヘルスケア、金融、小売、公益事業、政府のあらゆる規模の企業で開発者およびアーキテクトとして働いていました。彼はクラウドとAWSで起こっているすべてのイノベーションに情熱を注いでいます。

Amazon Web Services ブログ