Amazon ECS と AWS Fargate 上の .NET ワークロード

クラスターグループのコンテキストメニューには、次のオプションがあります。

• 更新: エクスプローラーに表示されているクラスターのコレクションを更新します。
  

エクスプローラーに表示されるデプロイされた各クラスターのコンテキストメニューには、以下を行うオプションがあります。

• クラスターの詳細を表示します (新しいドキュメントウィンドウが開きます)。
• クラスターを削除します。

実行中のタスクがあるクラスターは削除できません。タスクをクラスターから削除するには、まず [View] (表示) メニューオプションを使用してクラスターの詳細ビューを開き、次にビューで [Edit] (編集) を選択し、[Desired Tasks] (必要なタスク) の値を 0 に設定します。実行中のタスクをすべて削除したら、ビューの [Delete] (削除) ボタンまたはコンテキストメニューエントリを使用してクラスターを削除します。クラスターの詳細のビューは以下のとおりです。

リポジトリグループのコンテキストメニューには、以下を行うオプションがあります。

• リポジトリの作成: ダイアログウィンドウが開き、新しいリポジトリの名前を入力します。新しいリポジトリはプライベートレジストリでのみ作成できることに注意してください。
• 更新: エクスプローラーに表示されるリポジトリのコレクションを更新します。

リポジトリグループに一覧表示されているリポジトリのコンテキストメニューには、以下を行うオプションがあります。

• 表示: 新しいドキュメントウィンドウが開き、リポジトリに含まれる画像が一覧表示されます。このリポジトリにイメージをプッシュするために必要な特定のコマンドは、こちらでも確認できます
  

• 削除: リポジトリの削除を確認するダイアログウィンドウを開きます。ツールキットは、リポジトリ自体を削除する前に、オプションでリポジトリに含まれるすべてのイメージを削除できます (空でないリポジトリは削除できません)。
  

AWS への発行では、AWS Fargate、AWS App Runner、および AWS Elastic Beanstalk の仮想マシンを使用して、.NET アプリケーションを Amazon ECS にデプロイできます。コンテナイメージを Amazon ECR に発行するためにも使用できます。AWS への発行は、1 つの IDE ポータルから複数のサービスにデプロイできるだけでなく、以下の機能も提供します。

• アプリケーション向けのカスタムデプロイプロジェクトを作成する機能。カスタムデプロイプロジェクトでは、デプロイ中に追加の AWS リソースを構築したり、カスタムデプロイの UX 設定を行ったりすることができます。デプロイプロジェクトをアプリケーションと一緒にソース管理にチェックインすることで、開発チーム全員が Visual Studio 内からアプリケーションをデプロイするときに、そのアプリケーションに適用できる同じカスタム設定とデプロイリソースにアクセスできるようになります。
• dotnet コマンドラインエクスペリエンスは、NuGet から AWS.Deploy.Tools パッケージをインストールした後に利用できます。コマンドラインにより、カスタムデプロイプロジェクトを使用して追加されたものを含め、同じオプションが使えるようになります。コマンドラインツールの使用については、このセクションの後半で説明します。AWS コンテナサービスにデプロイする場合、アプリケーションには既存の Dockerfile は必要ありません。Dockerfile は必要に応じて生成されます。

注: AWS への発行は .NET アプリケーションのみをサポートし、.NET Framework を使用するアプリケーションのデプロイはサポートしていません。

注: AWS App Runner へのデプロイについては、「AWS App Runner での.NET ワークロード」という別のコースで説明します。

AWS への発行には前提条件となるインストールがいくつかあり、どちらかがインストールされていない場合はプロンプトが表示されます。AWS クラウドデプロイキット (CDK) は、アプリケーションのデプロイをサポートする AWS リソースのプロビジョニングと設定に使用されます。CDK には Node.js がインストールされている必要があります。ブラウザを開いて https://nodejs.org/en/ を開き、最新の長期サポート (LTS) バージョンまたは最新バージョンの Node.js をインストールします。Node.js がインストールされたら、コマンドシェルを開き、npm install -g aws-cdk コマンドを実行して CDK をインストールします。これらの 2 つの前提条件がインストールされると、AWS への発行を使用してデプロイを実行できます。

ソリューションエクスプローラーのアプリケーションプロジェクトのコンテキストメニューから AWS への発行を起動します。アプリケーションが分析され、レシピと呼ばれるいくつかのデプロイオプションが表示されます。Dockerfile で既に設定されているアプリケーションの場合、AWS Fargate を使用して Amazon ECS にアプリケーションをデプロイするレシピ、またはコンテナイメージを Amazon ECR にプッシュするレシピが最初に表示されます。まだ Dockerfile で設定されていないアプリケーションの場合、これらのオプションは ASP.NET Core ウェブおよび Web API アプリケーション (Blazor Server を含む)、およびコンソールアプリケーションに表示されます。

注: アプリケーションが既に (任意のサービスに) デプロイされている場合、パブリッシュ UI はまず既存のターゲットへの再デプロイを提案します。このような場合は、[Publish to New Target] (新しいターゲットに発行) タブオプションを選択して、再デプロイの代わりに新しいデプロイを実行します。

以下のスクリーンショットは、ASP.NET Core 6 ウェブアプリケーションで (執筆時点で) 利用できるレシピを示しています。アプリケーションで利用できるカスタムデプロイプロジェクトがある場合は、AWS が提供するレシピの上に一覧表示されます。スクリーンショットでは、AWS Fargate を使用して Amazon ECS に発行するレシピが選択されています。右側のパネルには、そのレシピのデフォルトのデプロイオプションが表示されます。

少なくともアプリケーション名が必要です。デフォルトではプロジェクト名が使用されます。アプリケーションによっては、[Publish] (発行) ボタンを選択してすぐにデプロイを開始できる場合があります。ただし、アプリケーションが AWS のサービスを呼び出す場合は、アプリケーションがサービスとサービス API にアクセスできるようにする許可を含むカスタムロールを提供する必要があります。[Edit settings] (設定の編集) ボタンを選択し、必要に応じてアプリケーションのロールとデプロイ前に必要なインフラストラクチャの変更を指定します。例えば、タスクメモリと CPU、ネットワーク設定、負荷分散、スケーリング要件を変更できます。下のスクリーンショットは、選択したレシピで使用できるオプションの一部を示しています。左側のカテゴリ (コンピューティング、許可、VPC など) は、デプロイで指定できるオプションの範囲を示しています。
Fargate 上の Windows コンテナは、.NET Framework と .NET アプリケーションの両方を実行できます。Fargate は現在、アプリケーション向けの Windows Server の 2 つのバージョン (Windows Server 2019 Full と Windows Server 2019 Core) をサポートしています。どのバージョンを使用しても、AWS がユーザーのために Windows オペレーティングシステムのライセンスを管理します。

必要なオプションを設定したら、[Publish] (発行) ボタンを選択してデプロイを開始します。

上記のサンプルの ASP.NET Core ウェブアプリケーションでは、AWS への発行 はいくつかのステップを経て進行します。進行状況はデプロイログの出力で確認できます。

1. コンテナイメージは、既存の Dockerfile または自動生成された Dockerfile を使用して構築されます。
2. 認証は Amazon ECR プライベートレジストリに対して実行され、イメージはリポジトリにプッシュされます。デフォルトでは、アプリケーションのデプロイと同じ名前のリポジトリが使用されますが、デプロイ設定を編集することで、発行を開始する前に別のリポジトリを選択できます (リポジトリ名はプロジェクトビルドカテゴリの設定にあります)。
3. 一時的な CDK プロジェクトが生成され、デプロイをサポートするために必要なリソース (タスク定義、クラスター設定、ネットワーク設定、その他の設定など) が定義されます。
4. 最後に、CDK プロジェクトを使用して AWS CloudFormation スタックをデプロイしてリソースを起動および設定し、アプリケーションをそれらのリソースにデプロイします。

デプロイが完了すると、CloudFormation スタックに関する概要情報がウィンドウに表示され、デプロイされたアプリケーションの URL (サービスとしてデプロイされた場合) も表示されます。URL をクリックすると、デプロイされたアプリケーションでブラウザが起動します。

AWS への発行を使用して作成されたアプリケーションのデプロイは、単に AWS CloudFormation スタックにすぎません。デプロイは次のいずれかの方法で削除できます。

• AWS マネジメントコンソールの CloudFormation ダッシュボードに移動し、関連するスタックを削除する方法。
• Visual Studio で、AWS Explorer の AWS CloudFormation エントリを展開し、スタックを選択して、スタックのコンテキストメニューから [Delete] (削除) を選択する方法。
• コマンドラインシェルから、インストールされている AWS.Tools.Deploy パッケージを使用して、dotnet aws delete-deployment コマンドを実行する方法。

また、コマンドラインシェルから、AWS Tools for PowerShell コマンド Remove-CFNStack または AWS CLI コマンド aws cloudformation delete-stack を使用して、デプロイされたコンテナベースのアプリケーションを表すスタックを削除することもできます。

AWS への発行は、コンテナ内での実行に適した .NET アプリケーションを AWS にデプロイするための、使いやすく拡張可能なメカニズムです。AWS やクラウド開発に関する幅広い知識は必要ありません。ビルトインのカスタマイズ可能なレシピにより、デベロッパーは開発中に Visual Studio 内から、AWS Fargate を使用した Amazon ECS、およびその他のコンテナベースのサービスに簡単にアプリケーションをデプロイおよび再デプロイできます。サーバー側の Blazor を含む ASP.NET Core ウェブおよびウェブ API アプリケーションを AWS 上のコンテナにデプロイする場合は、AWS への発行を選択することをお勧めします。

AWS へのコンテナの発行は、コンテナ化された .NET アプリケーションを Visual Studio 内から AWS にデプロイするためのウィザードベースのオリジナルアプローチです。現在はレガシーアプローチと見なされているこのウィザードは、この記事の執筆時点では Visual Studio 内で引き続きサポートされていますが、将来のバージョンでは削除される可能性があります。

AWS への発行と比較して、AWS へのコンテナの発行には次の機能と制限があります。

• Amazon ECS へのデプロイのみをサポートします (AWS Fargate の使用の有無にかかわらず)。AWS への発行では、AWS App Runner や、AWS Elastic Beanstalk などの仮想マシンサービスもサポート対象です。
• ASP.NET Core ウェブおよび Web API アプリケーション、およびコンソールアプリケーションからコンテナへのデプロイをサポートします。これは AWS への発行が提供するものと似ています。
• Dockerfile がアプリケーションに既に存在している必要があります。AWS への発行とは異なり、Dockerfile は自動生成されません。アプリケーションのプロジェクトに Dockerfile が含まれていない場合、コンテナを ECS に発行するオプションはプロジェクトのコンテキストメニューに表示されません。
• AWS クラウド開発キットと Node.js には依存しません。
• ウィザードで使用できる設定以外はデプロイを変更できません。AWS への発行により提供されるようなカスタムデプロイプロジェクトは利用できません。
• NuGet で入手可能な dotnet CLI ツール拡張機能である Amazon.ECS.Tools と一緒に使用できます。 シンプルな JSON 形式の設定ファイル aws-ecs-tools-defaults.json を使用すると、ウィザードで選択した構成設定をコマンドラインエクスペリエンスと共有できます。これはコマンドラインシェルで dotnet ecs を実行することで起動します。コマンドラインオプションは、Visual Studio や AWS ツールキットを使用できないデベロッパー、または CI/CD システムへの自動デプロイに適しています。
  

注: ウィザードには、新しい AWS への発行エクスペリエンスへの切り替えを推奨するバナーが含まれています。将来のある時点で、レガシーウィザードはツールキットから削除される予定です。

ウィザードは、AWS Explorer ウィンドウでの現在の選択に基づいて、AWS 認証情報とリージョンのフィールドに事前入力します。デフォルトでは、プロジェクトのリリース設定は、必要に応じて作成されるプロジェクト名のリポジトリにデプロイされます。

ページの下部にある [Deployment Target] (デプロイターゲット) ドロップダウンには、次の 4 つのオプションがあります。

• ECS クラスター上のサービスは 、ウェブアプリケーションや場合によっては Web API など、年中無休で実行する必要があるアプリケーションに適しています。
• ECS クラスターでのタスクの実行は、コンソールベースのアプリケーションなど、一度実行してから終了するアプリケーションコードに適しています。タスクが終了したら、必要に応じて手動で再実行できます。
• ECS クラスター上のスケジュールされたタスクは、終了前に定期的に実行されるタスクに適しています。例としては、バッチ処理や夜間の ETL ジョブなどがあります。
• Docker イメージのみを Amazon Elastic Container Registry にプッシュすると、アプリケーションのコンテナイメージが構築され、プライベートレジストリに対して認証され、プライベートレジストリのリポジトリにプッシュされます。パブリックレジストリのリポジトリはサポートされていません。

適切なターゲットを選択すると、[Next] (次へ) ボタンをクリックして起動設定が定義されているページに移動します。このページとそれ以降のページで選択したデータは、ユーザーのためにタスク定義に入力されます。

ECS クラスターフィールドで [Create an empty cluster] (空のクラスターの作成) を選択すると、ウィザードは AWS Fargate を使用するデプロイにロックされます。AWS Fargate を使用せずに Amazon ECS にデプロイするには、まず AWS マネジメントコンソールなどの他のツールを使用して必要なクラスターリソースを作成し、次にウィザードで既存のクラスターを選択する必要があります。

ウィザードの開始時に [Service on an ECS Cluster] (ECS クラスター上のサービス) を選択した場合、次のページでは、実行するタスク数、コンテナインスタンス (デフォルトは 1)、およびサービスが維持する必要がある最小タスク率と最大タスク率が求められます。既存のサービスを使用するには、ここでその名前を選択するか、作成する新しいサービスの名前を設定します。ECS クラスター上のタスクを選択した場合は、代わりにタスクの数を設定し、タスクグループに名前を付けるように求められます。以下のスクリーンショットは、ウェブアプリケーションをデプロイする際の ECS クラスター上のサービスのオプションを示しています。

デプロイターゲットがサービスの場合、ウィザードの次のページで Application Load Balancer を設定し、ヘルスチェックページを完了できます。デフォルトでは、ロードバランサーは設定されていません。タスクベースのデプロイターゲットの場合、タスクを構成するコンテナは一度実行されて終了するため、ロードバランサーページは表示されません。

ウィザードの最後の設定ページには、既存のタスク定義を使用するか、新しいタスク定義を作成するかなど、タスク定義に含めるその他のオプションなどがあります。ここでも、アプリケーションが AWS のサービスを呼び出す場合はアプリケーションコードの IAM ロール (タスクロール) を選択し、デプロイ中にリソースをプロビジョニングするために必要なプライベートレジストリイメージやその他のリソースへのアクセスを許可する Amazon ECS が引き受ける実行ロールを選択します。最後に、公開するコンテナポートとその他の環境変数を指定します。

すべての設定が完了したら、[Publish] (発行) を選択するとデプロイが開始されます。新しい AWS への発行機能と同様に、ツールキットではデプロイを完了するために数多くの手順をたどります。これらの手順は、ウィザードの進行状況出力、または IDE の出力ウィンドウの Amazon Web Services ペインでたどることができます。

1. アプリケーションが構築され、コンテナーイメージが作成されます。
2. 認証は Amazon ECR プライベートレジストリに対して実行され、イメージはリポジトリにプッシュされます。使用するリポジトリの名前はウィザードの最初のページで指定され、デフォルトはプロジェクト名です。
3. ウィザードで選択した設定に適したクラスターおよびその他のリソースがプロビジョニングされ、設定されます。

クラスターのリソースプロビジョニングが完了すると、ツールキットは [Cluster] (クラスター) ビューを開きます。ここでは、実行が開始されてウィザードで指定された数に達するまで行われるタスクの進行状況を監視できます。また、サービスに関しては、ウィザード中にロードバランサーを選択した場合は、デプロイされたアプリケーションにアクセスするための URL が見つかります。

Visual Studio の AWS へのコンテナの発行ウィザードは、IDE 内でアプリケーションを繰り返し使用するデベロッパー向けに設計されています。CI/CD オートメーションのため、または Windows システムで作業していないデベロッパーが使用できるように、AWS は dotnet CLI を拡張する NuGet ツールパッケージ、Amazon.ECS.Tools を提供しています。このツールをインストールするには、コマンドラインシェルを開いて次のコマンドを実行します。

dotnet tool install -g Amazon.ECS.Tools.

インストール後にトップレベルのコマンドオプションの表示を開始するには、次のコマンドを実行します。

dotnet ecs

デプロイを開始するには、アプリケーションのプロジェクトフォルダ内から以下を実行します。

dotnet ecs deploy

ツールとそのすべてのコマンドに関するその他のヘルプは、--help スイッチを使用して利用できます。

以前に Visual Studio のウィザードを使用してデプロイされたアプリケーションの場合、ウィザードで選択した設定は、デフォルトで JSON 形式のテキストファイル aws-ecs-tols-defaults.json で使用できます。このファイルはアプリケーションプロジェクトディレクトリにあります。これらの設定はコマンドラインツールによって読み込まれ、必要に応じてオーバーライドできます。

Amazon.ECS.Tools dotnet CLI 拡張機能を使用して AWS にコンテナ化されたアプリケーションをデプロイする方法 (CI/CD オートメーションでの使用を含む) の詳細については、このモジュールの後半の「コマンドラインから AWS へ .NET コンテナをデプロイする」というタイトルのセクションで詳しく説明します。

AWS へのコンテナの発行ウィザードを使用して行われたデプロイを削除するには、次のいずれかの方法を行います。

• AWS マネジメントコンソールで、ECS ダッシュボードに移動し、表示されたリストでクラスターを選択し、クラスターの詳細ビューで [Delete Cluster] (クラスターの削除) を選択します。
• Visual Studio で、デプロイされたアプリケーションのクラスタービューを開き、[Edit] (編集) を選択し、必要なタスク数を 0 に設定します。タスクが実行されなくなったら、クラスタービューまたは AWS Explorer ビューのクラスターエントリのコンテキストメニューから [Delete] (削除) を選択して、クラスターを削除します。
• クラスターを削除したら、デプロイ中に使用したイメージを含むリポジトリも削除したい場合もあるでしょう。

クラスターを削除したら、デプロイ中に使用したイメージを含むリポジトリも削除したい場合もあるでしょう。

注: Amazon.ECS.Tools コマンドライン拡張機能は、デプロイの削除をサポートしていません。

コンテナを AWS にパブリッシュすると、ウィザードベースの方法で Amazon ECS (AWS Fargate の使用の有無にかかわらず) と Amazon ECR にアプリケーションをデプロイできます。AWS への発行とは異なり、ECS へのコンテナの発行では、デプロイターゲットとして Amazon ECS、AWS Fargate、Amazon ECR のみがサポートされます。さらに、デプロイオプションはウィザードまたは同等のコマンドラインで提供されるものに限定され、カスタマイズすることはできません。.NET アプリケーションの AWS へのデプロイの代替ツールとしては、AWS への発行が推奨されます。ただし、新しいエクスペリエンスを採用できないチーム向けに、古いウィザードとコマンドライン拡張機能は引き続きサポートされ、使用できます。

NuGet 上の AWS.Deploy.Tools パッケージは、Windows 上の Visual Studio における AWS への発行と同等のコマンドラインです。Windows、macOS、および Linux プラットフォームで使用できるコマンドラインバージョンでは、Visual Studio で利用できるものと同じデプロイレシピを発行しています。これには、アプリケーション用に定義されたカスタムデプロイプロジェクトを選択する機能が含まれます。パッケージは GitHub でオープンソースプロジェクトとして管理されています。

注: この記事の執筆時点では、カスタムデプロイプロジェクトはコマンドラインと Visual Studio の両方から使用できますが、作成できるのはコマンドラインツールのみです。

パッケージをインストールするには、コマンドラインシェルを開いて次のコマンドを実行します。

dotnet tool install -g aws.deploy.tools

新しいバージョンが定期的にリリースされます。更新するには、次のコマンドを実行します。

dotnet tool update -g aws.deploy.tools

Visual Studio の AWS への発行と同様に、AWS.Deploy.Tools パッケージは Node.js と AWS クラウド開発キットに依存しているため、これらも必ずインストールしてください。

インストール後、インストールが成功したことを確認し、使用可能な最上位のコマンドオプションを確認するには、次のコマンドを実行します。

dotnet aws

コマンドラインでデプロイを開始するには、アプリケーションプロジェクトファイル (.csproj ファイル) を含むフォルダから、次のコマンドを実行します。

dotnet aws deploy

アプリケーションが分析され、番号付きのデプロイレシピのセットが表示されて選択できます。下のスクリーンショットでは、ツールが現在 Dockerfile を持たないアプリケーションの分析を完了しており、AWS Elastic Beanstalk で仮想マシンへデプロイすることを推奨しています。ただし、これは目的のレシピ番号 (この場合は 3) を入力することで変更でき、AWS Fargate を使用してコンテナとしてデプロイできます。Dockerfile はデプロイ時に作成され、プロジェクトに追加されます。

レシピを選択すると、一連のプロンプトがデプロイ名などの必要な情報を収集します (デフォルトはプロジェクト名ですが、変更可能です)。その他のオプション設定は、番号付きのサブメニューを使用して調整できます。

上のスクリーンショットでは、「4」を押すと、デプロイで新しい空のロールを作成する代わりに、アプリケーションが実行時に引き受けるカスタム IAM ロールを選択できます。「more」と入力すると、デプロイ用に設定するためのその他の詳細オプションが使えます。

設定に満足したら、Enter キーを押すとデプロイが開始されます。アプリケーションでカスタムロールを指定する必要がなく、提示されたデフォルト値でも問題ないシナリオでは、Enter キーを 2 回押すだけで十分です。1 回はデフォルトのデプロイ名を確認し、もう 1 回はアプリケーションのデプロイを開始します。

Visual Studio からのデプロイと同様に、コンテナレシピを選択すると、必要に応じて Dockerfile が生成され、イメージがビルドされて Amazon ECR にプッシュされ (ツールが自動的に認証します)、インフラストラクチャをプロビジョニングするための CDK プロジェクトが作成され、AWS CloudFormation にデプロイされます。デプロイからのイベントやその他のステータス情報は、ターミナルにエコーされます。最後に、アプリケーションエンドポイント URL が、クラスター名やサービス名などの他の要約情報とともに出力されます。

アプリケーションの再デプロイもコマンドラインでサポートされています。以前にデプロイされたプロジェクトのフォルダで dotnet aws deploy を実行すると、最初に既存のデプロイが一覧表示されて選択でき、次に新しいデプロイのレシピを選択するオプションが示されます。

AWS.Deploy.Tools は、継続的インテグレーションと継続的デリバリーのパイプライン内から使用できます。ただし、このようなシナリオでは、プロンプトが問題になる可能性があります。プロンプトを無効にするには、コマンドに --silent スイッチを追加します。

プロンプトを無効にすると、ツールは実行時にデプロイ設定を収集できません。必須設定とオプション設定をすべて指定するには、JSON 形式のテキストファイルで指定し、次の --apply オプションを使用してデプロイコマンドにファイル名 (とオプションでパス) を指定します。

dotnet aws deploy --apply settings.json –-silent

設定ファイルの作成は、このコースの範囲外です。ツールの GitHub リポジトリにあるファイル定義へのリンクは、「AWS .NET GitHub repo でデプロイ設定ファイルを作成する」というタイトルのセクションにあります。

このコースのテーマではなく、詳しく説明していませんが、コンテナ化された .NET アプリケーション向けにカスタマイズされたデプロイプロジェクトを作成できます。カスタムデプロイプロジェクトを作成すると、デプロイされたアプリケーションをサポートするインフラストラクチャやその他のアセットを追加し、ランタイム環境をカスタマイズできます。カスタムデプロイプロジェクトは、アプリケーションと一緒にソース管理にチェックインし、開発チーム全体で共有できるため、Visual Studio からデプロイするかコマンドラインからデプロイするかに関係なく、全員が同じ設定とカスタマイズでデプロイできます。

Visual Studio で AWS に発行するか、コマンドラインで AWS.Deploy.Tools を使用してカスタムデプロイプロジェクトを使用する方法の詳細については、https://aws.github.io/aws-dotnet-deploy/docs/deployment-projects/cdk-project/ を参照してください。

AWS.Deploy.Tools を使用して実行したアプリケーションのデプロイと Visual Studio での AWS への発行は、コマンドラインで次のコマンドを実行することで簡単に削除できます。

dotnet aws delete-deployment deployment-name

deployment-name は、デプロイ用に作成した AWS CloudFormation スタックの名前に置き換えてください。

NuGet 上の Amazon.ECS.Tools パッケージは、Visual Studio における AWS へのコンテナの発行と同じコマンドラインです。このパッケージは Windows、macOS、Linux プラットフォームで使用でき、GitHub のオープンソースプロジェクトとして管理されています。 そのリポジトリには、AWS Lambda と AWS Elastic Beanstalk へのデプロイに使用される他の 2 つの dotnet CLI 拡張機能が含まれています。

最上位のコマンドオプションを表示するには、次のコマンドを実行します。

dotnet ecs

すべてのコマンドには追加のヘルプがあり、--help スイッチを指定すると利用できます。

デプロイを開始するには、まず、サービス (継続的に実行)、タスク (1 回実行して終了)、またはスケジュールされたタスク (定期的に実行され、各実行後に終了) のいずれにデプロイするかを決定します。または、イメージを作成して Amazon ECR プライベートレジストリのリポジトリにプッシュすることもできます。このコースで使用するサンプルウェブサイトでは、継続的に実行されるサービスが適切な選択肢です。deploy-service コマンドを --help スイッチで指定すると、適用できるすべての設定が一覧表示されます。

イメージがプッシュされると、起動タイプ (EC2 または FARGATE) を指定するよう求められます。EC2 起動タイプの場合は、必要なクラスターインフラストラクチャを前もって作成しておく必要があります。FARGATE 起動タイプでは事前プロビジョニングは必要ありませんが、タスクの CPU とメモリを指定する必要があります。Linux と Windows のコンテナタイプで若干異なる最新の有効な値の組み合わせについては、https://docs.thinkwithwp.com/AmazonECS/latest/userguide/task_definition_parameters.html を参照してください。

以下のスクリーンショットでは、起動タイプとして FARGATE が選択されており、512 MiB のメモリと対応する 256 (.25 vCPU) の CPU が搭載されています。また、ツールは、デプロイを完了する前に、クラスター名とサービス名の値の入力を求めています。これらの値を入力して検証すると、デプロイがリクエストされ、コマンドが終了します。

注: このモジュールで既に説明した「AWS と AWS.Deploy.Tools に発行する」とは異なり、Amazon.ECS.Tools コマンドはデプロイが完了するまで待機しません。デプロイされたアプリケーション URL などのデータを取得するには、管理コンソールにアクセスするか、Visual Studio のクラスタービューを使用する必要があります。

このデプロイによって書き込まれた設定ファイルは、以下のスクリーンショットに示されています。これは、Visual Studio から開始されたデプロイ用に記述されるものとほぼ同じです (IDE バージョンでは、もう少し多くの設定が書き込まれます)。このファイルは、アプリケーションコードと共にソースコードリポジトリにチェックインでき、Windows 上の Visual Studio と Windows、macOS、Linux のコマンドラインデプロイの両方で使用できます。より広範囲な設定ファイルを手作業で作成して、すべてのコマンドラインオプションに値を指定することもできます。便宜上、オプションの名前は設定ファイルのキーに対応しています。

Amazon.ECS.Tools は、継続的インテグレーションと継続的デリバリーのパイプライン内から使用できます。ただし、このようなシナリオでは、プロンプトが問題になる可能性があります。プロンプト表示を無効にするには、コマンドに--disable-interactive スイッチを追加します。

プロンプトを無効にすると、ツールは実行時にデプロイ設定を収集できません。必須設定とオプション設定をすべて指定するには、JSON 形式の設定ファイルで指定し、--config-file オプションを使用してデプロイコマンドにファイル名 (とオプションでパス) を指定します

Amazon.ECS.Tools は、コマンドラインからデプロイされたコンテナアプリケーションを削除することをサポートしていません。デプロイを削除するには、以下のいずれかのオプションを使用してください。

• AWS マネジメントコンソールで、ECS ダッシュボードに移動し、表示されたリストでクラスターを選択し、クラスターの詳細ビューで [Delete Cluster] (クラスターの削除) を選択します。
• Visual Studio で、デプロイされたアプリケーションのクラスタービューを開き、[Edit] (編集) を選択し、[Desired tasks] (必要なタスク) を 0 に設定します。タスクが実行されなくなったら、クラスタービュー、または AWS Explorer ビューのクラスターエントリのコンテキストメニューから [Delete] (削除) を選択して、クラスターを削除します。

クラスターを削除したら、デプロイ中に使用したイメージを含むリポジトリも削除したい場合もあるでしょう。

a.Lambda

b.ECS

c.EC2

d.ECR

a.C# と Node.js

b.CDK と Node.js

c.Python と CDK

d.Python と Node.js

a.Windows

b. macOS

c.Linuxs

d.上記のすべて

回答: 1-b と d、2-b、3-d