翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Elastic Beanstalk .NET Windows プラットフォームの使用
このトピックでは、Elastic Beanstalk で ASP.NET および .NET Core Windows ウェブアプリケーションを設定、ビルド、実行する方法について説明します。
AWS Elastic Beanstalk は、.NET プログラミングフレームワークと Windows Server のさまざまなバージョンのプラットフォームをサポートしています。完全なリストについては、AWS Elastic Beanstalk プラットフォームドキュメントの「[IIS を使用する Windows Server での .NET](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.net)」を参照してください。
Elastic Beanstalk には、Elastic Beanstalk 環境内の EC2 インスタンスで実行されるソフトウェアのカスタマイズに使用できる[設定オプション](command-options.md)が用意されています。アプリケーションの環境変数を設定し、Amazon S3 へのログローテーションを有効にし、.NET フレームワークを設定することができます。
設定オプションは[実行中の環境の設定を変更するために](environment-configuration-methods-after.md) Elastic Beanstalk コンソールで利用できます。環境を終了したときにその設定が失われないようにするため、[保存済み設定](environment-configuration-savedconfig.md)を使用して設定を保存し、それを後で他の環境に適用することができます。
ソースコードの設定を保存する場合、[設定ファイル](ebextensions.md)を含めることができます。設定ファイルの設定は、環境を作成するたびに、またはアプリケーションをデプロイするたびに適用されます。設定ファイルを使用して、デプロイの間にパッケージをインストールしたり、スクリプトを実行したり、他のインスタンスのカスタマイズオペレーションを実行することもできます。
Elastic Beanstalk コンソールで適用される設定は、設定ファイルに同じ設定があれば、それらの設定を上書きします。これにより、設定ファイルでデフォルト設定を定義し、コンソールでそのデフォルト設定を環境固有の設定で上書きできます。設定の優先順位の詳細と設定の他の変更方法については、「」を参照してください[設定オプション](command-options.md)
## Elastic Beanstalk コンソールでの.NET 環境の設定
Elastic Beanstalk コンソールでは、Amazon S3 のログローテーションを有効にしたり、アプリケーションが環境から読み取ることができる変数を設定したり、.NET フレームワーク設定を変更することができます。
**Elastic Beanstalk コンソールで.NET 環境を設定するには**
1. [Elastic Beanstalk コンソール](https://console.aws.amazon.com/elasticbeanstalk)を開き、**リージョン**リストで を選択します AWS リージョン。
1. ナビゲーションペインで、[**環境**] を選択し、リストから環境の名前を選択します。
1. ナビゲーションペインで、[**設定**] を選択します。
1. **[更新、モニタリング、ログ]** の設定カテゴリで、**[編集]** を選択します。
### コンテナオプション
+ **Target .NET runtime** – CLR v2 を実行するには `2.0` に設定します。
+ **32 ビットアプリケーションの有効化** – 32 ビットアプリケーションを実行するには `True` に設定します。
### ログオプション
[Log Options (ログオプション)] セクションには、2 つの設定があります。
+ **インスタンスプロファイル** – アプリケーションに関連付けられた Amazon S3 バケットへのアクセス許可が付与されているインスタンスプロファイルを指定します。
+ **[Enable log file rotation to Amazon S3]** (Amazon S3 へのログファイルのローテーションの有効化) - アプリケーションの Amazon EC2 インスタンスのログファイルを、アプリケーションに関連付けられている Amazon S3 バケットにコピーするかどうかを指定します。
### 環境プロパティ
**環境プロパティ** セクションでは、アプリケーションを実行している Amazon EC2 インスタンスの環境設定を指定できます。これらの設定は、キーと値のペアでアプリケーションに渡されます。`System.GetEnvironmentVariable` を使用して、それらのペアを読み取ります。同じキーが `web.config` に存在するとともに、環境プロパティとして存在する可能性があります。`System.Configuration` 名前空間を使用して、`web.config` から値を読み取ります。
```
NameValueCollection appConfig = ConfigurationManager.AppSettings;
string endpoint = appConfig["API_ENDPOINT"];
```
詳細については、「[環境変数とその他のソフトウェアの設定](environments-cfg-softwaresettings.md)」を参照してください。
## aws:elasticbeanstalk:container:dotnet:apppool 名前空間
[設定ファイル](ebextensions.md)を使用して、設定オプションを設定し、デプロイの間、他のインスタンス設定タスクを実行できます。設定オプションは、[プラットフォーム固有](command-options-specific.md)のものでも、Elastic Beanstalk サービス全体の[すべてのプラットフォーム](command-options-general.md)に適用できるものでもかまいません。設定オプションは、名前空間として整理されています。
.NET プラットフォームは、.NET ランタイムの設定に使用できる `aws:elasticbeanstalk:container:dotnet:apppool` 名前空間のオプションを定義します。
以下の設定ファイルの例では、この名前空間で使用できる各オプションの設定を示しています。
**Example .ebextensions/dotnet-settings.config**
```
option_settings:
aws:elasticbeanstalk:container:dotnet:apppool:
Target Runtime: 2.0
Enable 32-bit Applications: True
```
Elastic Beanstalk には、環境をカスタマイズするための多数の設定オプションが用意されています。設定ファイルに加えて、コンソール、保存された設定、EB CLI、または を使用して、設定オプションを指定することもできます AWS CLI詳細については「[設定オプション](command-options.md)」を参照してください。
# Elastic Beanstalk Windows サーバープラットフォームのメジャーバージョン間での移行
AWS Elastic Beanstalk には、Windows Server プラットフォームのメジャーバージョンがいくつかあります。このページでは、各メジャーバージョンでの主な改善点と、以降のバージョンに移行する前の考慮点について説明します。
Windows Server プラットフォームは現在バージョン 2 (v2) です。アプリケーションで v2 より前の Windows Server プラットフォームバージョンを使用している場合は、v2 に移行することをお勧めします。
## Windows サーバープラットフォームのメジャーバージョンの最新情報
### Windows サーバープラットフォーム V2
Elastic Beanstalk Windows Server プラットフォームのバージョン 2 (v2) が [2019 年 2 月にリリースされました](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2019-02-21-windows-v2.html)。V2 では、いくつかの重要な点で Windows Server プラットフォームの動作が Elastic Beanstalk の Linux ベースのプラットフォームに近づいています。v2 は v1 と完全に下位互換性があり、v1 からの移行が容易です。
Windows Server プラットフォームでは次の機能がサポートされています。
+ *バージョニング* – 各リリースでは新しいバージョン番号が取得され、環境の作成および管理時には、以前のバージョン (まだ使用可能) を参照できます。
+ *拡張ヘルス* – 詳細については、「[Elastic Beanstalk の拡張ヘルスレポートおよびモニタリング](health-enhanced.md)」を参照してください。
+ *変更不可*の*追加のバッチとローリング*のデプロイ – デプロイポリシーの詳細については、「[Elastic Beanstalk 環境へのアプリケーションのデプロイ](using-features.deploy-existing-version.md)」を参照してください。
+ *変更不可の更新* – 更新タイプの詳細については、「[設定変更](environments-updating.md)」を参照してください。
+ *マネージドプラットフォーム更新* – 詳細については、「[マネージドプラットフォーム更新](environment-platform-update-managed.md)」を参照してください。
**注記**
新しいデプロイおよび更新機能は、拡張ヘルスに依存します。それらを使用するには、拡張ヘルスを有効にします。詳細については、「[Elastic Beanstalk の拡張ヘルスレポートの有効化](health-enhanced-enable.md)」を参照してください。
### Windows サーバープラットフォーム V1
Elastic Beanstalk Windows Server プラットフォームのバージョン 1.0.0 (v1) が 2015 年 10 月にリリースされました。このバージョンでは、環境の作成および更新中に Elastic Beanstalk が[設定ファイル](ebextensions.md)内のコマンドを実行する順序が変更されています。
以前のプラットフォームのバージョンでは、ソリューションスタック名にバージョン番号が使用されていません。
+ IIS 8.5 を実行する 64 ビット Windows Server 2012 R2
+ IIS 8.5 を実行する 64 ビット Windows Server Core 2012 R2
+ IIS 8 を実行する 64 ビット Windows Server 2012
+ IIS 7.5 を実行する 64 ビット Windows Server 2008 R2
以前のバージョンでは、設定ファイルの処理順には一貫性がありません。環境の作成中に、アプリケーションソースが IIS にデプロイされると `Container Commands` が実行されます。実行中の環境へのデプロイ中は、新しいバージョンがデプロイされる前にコンテナコマンドが実行されます。スケールアップ中は、設定ファイルはまったく処理されません。
これに加えて、コンテナコマンドの実行前に IIS が開始されます。この動作により一部の顧客はコンテナコマンドに回避策を実装し、コマンドの完了後に再度 IIS を起動して開始するコマンドの前に IIS サーバーを一時停止することになります。
バージョン 1 ではこの一貫性のない状態が修正されており、Windows Server プラットフォームの動作が Elastic Beanstalk の Linux ベースのプラットフォームにより近いものになっています。v1 プラットフォームでは、Elastic Beanstalk は IIS サーバーを起動する前に常にコンテナコマンドを実行します。
v1 のプラットフォームソリューションスタックでは、Windows Server のバージョンの後に `v1` が付きます。
+ IIS 8.5 を実行する 64 ビット Windows Server 2012 R2 v1.1.0
+ IIS 8.5 を実行する 64 ビット Windows Server Core 2012 R2 v1.1.0
+ IIS 8 を実行する 64 ビット Windows Server 2012 v1.1.0
+ IIS 7.5 を実行する 64 ビット Windows Server 2008 R2 v1.1.0
さらに、v1 プラットフォームはコンテナコマンドを実行する前に、アプリケーションソースバンドルのコンテンツを抽出して `C:\staging\` に保存します。コンテナコマンドの完了後に、このフォルダのコンテンツは .zip ファイルに圧縮され IIS にデプロイされます。このワークフローにより、コマンドまたはスクリプトを使用してアプリケーションソースバンドルのコンテンツを変更してからデプロイできます。
## Windows サーバープラットフォームの以前のメジャーバージョンからの移行
環境を更新する前に、このセクションの移行の考慮事項についてお読みください。新しいバージョンに環境のプラットフォームを更新するには、「[Elastic Beanstalk 環境のプラットフォームバージョンの更新](using-features.platform.upgrade.md)」を参照してください。
### V1 から V2 へ
Windows Server プラットフォーム v2 では、.NET Core 1.x および 2.0 をサポートしていません。アプリケーションを Windows Server v1 から v2 に移行中で、アプリケーションがこれらのいずれかの .NET Core バージョンを使用している場合は、v2 がサポートしている .NET Core バージョンにアプリケーションを更新します。サポートされているバージョンのリストについては、AWS Elastic Beanstalk プラットフォームの「[IIS を使用する Windows Server での .NET](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.net)」を参照してください。
アプリケーションでカスタム Amazon Machine Image (AMI) を使用している場合は、Windows Server プラットフォーム v2 AMI に基づいて新しいカスタム AMI を作成します。詳細については、「[Elastic Beanstalk 環境でのカスタム Amazon マシンイメージ (AMI) の使用](using-features.customenv.md)」を参照してください。
**注記**
Windows Server v2 の新しいデプロイおよび更新機能は、拡張ヘルスに依存します。環境を v2 に移行するときは、拡張ヘルスが無効になります。これらの機能を使用するには、拡張ヘルスを有効にします。詳細については、「[Elastic Beanstalk の拡張ヘルスレポートの有効化](health-enhanced-enable.md)」を参照してください。
### V1 以前から
v1 からの移行の考慮点に加えて、v1 以前の Windows Server ソリューションスタックからアプリケーションを移行していて、現在コンテナコマンドを使用している場合は、新しいバージョンに移行するときに処理の不一致を回避するために追加したコマンドをすべて削除します。v1 からは、コンテナコマンドは、デプロイされるアプリケーションソース、および IIS が起動する前に、完全に実行することが保証されています。これにより、このステップ中に問題なく `C:\staging` のソースに変更を加え、IIS 設定ファイルを修正することができます。
たとえば、 を使用して、DLL ファイルを Amazon S3 からアプリケーションソースに AWS CLI ダウンロードできます。
`.ebextensions\copy-dll.config`
```
container_commands:
copy-dll:
command: aws s3 cp s3://amzn-s3-demo-bucket/dlls/large-dll.dll .\lib\
```
設定ファイルの使用の詳細については、「[設定ファイル (`.ebextensions`) による高度な環境のカスタマイズ](ebextensions.md)」を参照してください。
# デプロイマニフェストを使用した複数のアプリケーションと ASP.NET コアアプリケーションの実行
デプロイマニフェストで、Elastic Beanstalk にアプリケーションをデプロイする方法を伝えることができます。この方法を使用すると、ウェブサイトのルートパスで実行される個々の ASP.NET アプリケーション用のソースバンドルを生成するために、`MSDeploy` を使用する必要がなくなります。マニフェストファイルを使用することにより、異なるパスで複数のアプリケーションを実行することが可能になります。または、Elastic Beanstalk に対して、ASP.NET Core を使用してアプリケーションのデプロイと実行を行うように指示することもできます。また、デプロイマニフェストは、アプリケーションを実行するためのアプリケーションプールの設定にも使用できます。
デプロイマニフェストは、Elastic Beanstalk へ [.NET Core アプリケーション](#dotnet-manifest-dotnetcore)のサポートを追加します。.NET Framework アプリケーションは、デプロイマニフェストなしでデプロイできます。ただし、.NET Core アプリケーションを Elastic Beanstalk で実行する場合は、デプロイマニフェストが必要です。デプロイマニフェストを使用する際には、まず各アプリケーションのサイトアーカイブを作成します。その上で、デプロイマニフェストを集録するための別の ZIP アーカイブ内に、先に作成したサイトアーカイブをバンドルします。
デプロイマニフェストを使用すると、[異なるパスで複数のアプリケーションを実行する](#dotnet-manifest-multiapp)こともできます。デプロイマニフェストは、多くのデプロイのターゲットを、サイトアーカイブと IIS が実行するパスにより個別に定義します。たとえば、`/api` パスで非同期リクエストを行うウェブ API を実行し、ルートパスでその API を実行するウェブアプリケーションを実行できます。
デプロイマニフェストを使用して、[カスタムバインディングと物理パスを備えた IIS ウェブサイトを設定できます](#dotnet-manifest-websites)。これにより、アプリケーションをデプロイする前に、特定のポートまたはホスト名をリッスンするウェブサイトを設定できるようになります。
デプロイマニフェストは、[IIS または Kestrel のアプリケーションプールを使用して、複数のアプリケーションを実行する](#dotnet-manifest-apppool)ために使用することもできます。アプリケーションプールを設定して、アプリケーションの定期的な再起動、32 ビットアプリケーションの実行、または、.NET Framework ランタイムの特定バージョンの使用ができます。
完全にカスタマイズするには、Windows PowerShell で[独自のデプロイスクリプトを作成し](#dotnet-manifest-custom)、Elastic Beanstalk にアプリケーションのインストール、アンインストール、再起動のために実行するスクリプトを伝えます。
デプロイマニフェストと関連機能を使用するには、Windows Server プラットフォーム[バージョン 1.2.0 以降](dotnet-v2migration.md)が必要です。
IIS リセットのスキップなど、使用可能なすべての設定オプション、プロパティ、および高度な機能の詳細については、[デプロイマニフェストスキーマリファレンス](dotnet-manifest-schema.md)を参照してください。
**Topics**
+ [.NET core アプリケーション](#dotnet-manifest-dotnetcore)
+ [複数のアプリケーションを実行する](#dotnet-manifest-multiapp)
+ [IIS ウェブサイトを設定する](#dotnet-manifest-websites)
+ [pplication Request Routing (ARR) を使用する](#dotnet-manifest-arr)
+ [アプリケーションプールを設定する](#dotnet-manifest-apppool)
+ [カスタムデプロイを定義する](#dotnet-manifest-custom)
+ [デプロイマニフェストスキーマのリファレンス](dotnet-manifest-schema.md)
## .NET core アプリケーション
デプロイマニフェストを使用すると、Elastic Beanstalk で .NET Core アプリケーションを実行することができます。.NET Core は .NET のクロスプラットフォームバージョンで、コマンドラインツール (`dotnet`) が付属しています。このマニフェストにより、アプリケーションの生成、ローカルでの実行、および公開の準備を行うことができます。
Elastic Beanstalk で .NET Core アプリケーションを実行するには、`dotnet publish` を実行し、その出力からディレクトリをすべて削除した内容を、ZIP アーカイブにパッケージします。サイトアーカイブを、デプロイマニフェストを使って、デプロイターゲットのタイプ `aspNetCoreWeb` と一緒にソースバンドルに配置します。
以下のデプロイマニフェストは、ルートパスの `dotnet-core-app.zip` という名前のサイトアーカイブから .NET Core アプリケーションを実行します。
**Example aws-windows-deployment-manifest.json - .NET core**
```
{
"manifestVersion": 1,
"deployments": {
"aspNetCoreWeb": [
{
"name": "my-dotnet-core-app",
"parameters": {
"archive": "dotnet-core-app.zip",
"iisPath": "/"
}
}
]
}
}
```
マニフェストとサイトアーカイブを ZIP アーカイブにバンドルし、ソースバンドルを作成します。
**Example dotnet-core-bundle.zip**
```
.
|-- aws-windows-deployment-manifest.json
`-- dotnet-core-app.zip
```
サイトアーカイブには、コンパイルされたアプリケーションコード、依存関係、`web.config` ファイルが含まれています。
**Example dotnet-core-app.zip**
```
.
|-- Microsoft.AspNetCore.Hosting.Abstractions.dll
|-- Microsoft.AspNetCore.Hosting.Server.Abstractions.dll
|-- Microsoft.AspNetCore.Hosting.dll
|-- Microsoft.AspNetCore.Http.Abstractions.dll
|-- Microsoft.AspNetCore.Http.Extensions.dll
|-- Microsoft.AspNetCore.Http.Features.dll
|-- Microsoft.AspNetCore.Http.dll
|-- Microsoft.AspNetCore.HttpOverrides.dll
|-- Microsoft.AspNetCore.Server.IISIntegration.dll
|-- Microsoft.AspNetCore.Server.Kestrel.dll
|-- Microsoft.AspNetCore.WebUtilities.dll
|-- Microsoft.Extensions.Configuration.Abstractions.dll
|-- Microsoft.Extensions.Configuration.EnvironmentVariables.dll
|-- Microsoft.Extensions.Configuration.dll
|-- Microsoft.Extensions.DependencyInjection.Abstractions.dll
|-- Microsoft.Extensions.DependencyInjection.dll
|-- Microsoft.Extensions.FileProviders.Abstractions.dll
|-- Microsoft.Extensions.FileProviders.Physical.dll
|-- Microsoft.Extensions.FileSystemGlobbing.dll
|-- Microsoft.Extensions.Logging.Abstractions.dll
|-- Microsoft.Extensions.Logging.dll
|-- Microsoft.Extensions.ObjectPool.dll
|-- Microsoft.Extensions.Options.dll
|-- Microsoft.Extensions.PlatformAbstractions.dll
|-- Microsoft.Extensions.Primitives.dll
|-- Microsoft.Net.Http.Headers.dll
|-- System.Diagnostics.Contracts.dll
|-- System.Net.WebSockets.dll
|-- System.Text.Encodings.Web.dll
|-- dotnet-core-app.deps.json
|-- dotnet-core-app.dll
|-- dotnet-core-app.pdb
|-- dotnet-core-app.runtimeconfig.json
`-- web.config
```
## 複数のアプリケーションを実行する
デプロイマニフェストを使って、複数のデプロイターゲットを指定することにより、複数のアプリケーションを実行できます。
以下のデプロイマニフェストでは 2 つの .NET Core アプリケーションを設定します。`WebApiSampleApp` アプリケーションは、シンプルなウェブ API を実装し、`/api` パスで非同期リクエストを提供します。`DotNetSampleApp` アプリケーションは、ルートパスでリクエストを処理するウェブアプリケーションです。
**Example aws-windows-deployment-manifest.json - multiple apps**
```
{
"manifestVersion": 1,
"deployments": {
"aspNetCoreWeb": [
{
"name": "WebAPISample",
"parameters": {
"appBundle": "WebApiSampleApp.zip",
"iisPath": "/api"
}
},
{
"name": "DotNetSample",
"parameters": {
"appBundle": "DotNetSampleApp.zip",
"iisPath": "/"
}
}
]
}
}
```
複数のアプリケーションのサンプルアプリケーションはこちらで入手できます:
+ **デプロイ可能なソースバンドル** - [dotnet-multiapp-sample-bundle-v2.zip](samples/dotnet-multiapp-sample-bundle-v2.zip)
+ **ソースコード** - [dotnet-multiapp-sample-source-v2.zip](samples/dotnet-multiapp-sample-source-v2.zip)
## IIS ウェブサイトを設定する
デプロイマニフェストを使用して、カスタムバインディングと物理パスを備えた IIS ウェブサイトを設定できます。これは、特定のポートでリッスンしたり、カスタムホスト名を使用したり、特定のディレクトリのコンテンツを処理したりするウェブサイトを設定する必要がある場合に役立ちます。
次のデプロイマニフェストは、特定のポート番号とカスタム物理パスを使用して HTTP をリッスンするカスタム IIS ウェブサイトを設定します。
**Example aws-windows-deployment-manifest.json - IIS ウェブサイト設定**
```
{
"manifestVersion": 1,
"iisConfig": {
"websites": [
{
"name": "MyCustomSite",
"physicalPath": "C:\inetpub\wwwroot\mysite",
"bindings": [
{
"protocol": "http",
"port": 8080,
"hostName": "mysite.local"
}
]
}
]
},
"deployments": {
"aspNetCoreWeb": [
{
"name": "my-dotnet-core-app",
"parameters": {
"appBundle": "dotnet-core-app.zip",
"iisWebSite": "MyCustomSite",
"iisPath": "/"
}
}
]
}
}
```
この例では、以下のようになっています：
+ 「MyCustomSite」という名前のウェブサイトがカスタム物理パスで作成されます
+ ウェブサイトには、特定のホスト名を持つ HTTP バインディングがポート 8080 にあります
+ ASP.NET Core アプリケーションは、`iisWebSite` パラメータを使用してこのカスタムウェブサイトにデプロイされます
## pplication Request Routing (ARR) を使用する
Application Request Routing (ARR) モジュールと URL Rewrite モジュールはプリインストールされており、Elastic Beanstalk Windows AMI で利用可能です。これらのモジュールにより、ebextensions またはアプリケーション設定を使用した IIS 設定を介した高度なルーティングシナリオと URL 操作が可能になります。
次の例は、カスタムポートを使用してウェブサイトを設定するシンプルなデプロイマニフェストと基本的な ARR ルーティングを設定する ebextensions 設定を組み合わせたものを示しています。
**Example aws-windows-deployment-manifest.json - シンプルな ARR セットアップ**
```
{
"manifestVersion": 1,
"iisConfig": {
"websites": [
{
"name": "ARRSite",
"physicalPath": "C:\\inetpub\\wwwroot\\arrsite",
"bindings": [
{
"protocol": "http",
"port": 8080,
"hostName": "localhost"
}
]
}
]
},
"deployments": {
"aspNetCoreWeb": [
{
"name": "BackendApp",
"parameters": {
"appBundle": "backend-app.zip",
"iisWebSite": "ARRSite",
"iisPath": "/backend"
}
}
]
}
}
```
ARR 設定は ebextensions を介して行われます。次の設定により、基本的な ARR ルーティングルールをセットアップします。
**Example .ebextensions/arr-config.config - 基本的な ARR 設定**
```
files:
"C:\\temp\\configure-arr.ps1":
content: |
# Enable ARR proxy at server level
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter 'system.webServer/proxy' -Name 'enabled' -Value 'True'
# Clear any existing global rules to avoid conflicts
Clear-WebConfiguration -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter 'system.webServer/rewrite/globalRules'
# Add global rule to route all requests to backend
Add-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' `
-Filter 'system.webServer/rewrite/globalRules' `
-Name '.' `
-Value @{
name = 'Route_to_Backend'
stopProcessing = 'True'
match = @{ url = '^(?!backend/)(.*)' }
action = @{
type = 'Rewrite'
url = 'http://localhost:8080/backend/{R:1}'
}
}
container_commands:
01_configure_arr:
command: powershell -ExecutionPolicy Bypass -File "C:\\temp\\configure-arr.ps1"
waitAfterCompletion: 0
```
この設定では、ポート 8080 でウェブサイトを作成し、すべての受信リクエストをそのサイトで実行されているバックエンドアプリケーションにルーティングするように ARR をセットアップします。
## アプリケーションプールを設定する
Windows 環境では、複数のアプリケーションをサポートできます。そのためには、次のような 2 つのアプローチが存在します。
+ Kestrel ウェブサーバーでは、アウトプロセスホスティングモデルを使用できます。このモデルでは、複数のアプリケーションを 1 つのアプリケーションプールで実行するように構成します。
+ インプロセスホスティングモデルを使用する場合には、複数のアプリケーションを実行するために複数のアプリケーションプールを用意して、各プール内では単一アプリケーションのみを実行します。IIS サーバーを使用していて、複数のアプリケーションを実行したい場合には、この方法を使用する必要があります。
1 つのアプリケーションプールで複数のアプリケーションを実行するように Kestrel を構成するには、`hostingModel="OutofProcess"` ファイルに `web.config` を追加で記述します。次に挙げるサンプルを参考にしてください。
**Example web.config - Kestrel アウトプロセスホスティングモデル用**
```
```
**Example aws-windows-deployment-manifest.json - 複数のアプリケーション**
```
{
"manifestVersion": 1,
"deployments": {"msDeploy": [
{"name": "Web-app1",
"parameters": {"archive": "site1.zip",
"iisPath": "/"
}
},
{"name": "Web-app2",
"parameters": {"archive": "site2.zip",
"iisPath": "/app2"
}
}
]
}
}
```
IIS では、インプロセスホスティングモデルが使用されているため、1 つのアプリケーションプールでの複数のアプリケーションの実行はサポートされていません。したがって、複数のアプリケーションを構成するには、各アプリケーションを個別のアプリケーションプールに割り当てる必要があります。つまり、1 つのアプリケーションプールに割り当てられるのは、1 つのアプリケーションのみです。
`aws-windows-deployment-manifest.json`ファイルで、IIS を異なるアプリケーションプールを使用するように構成できます。次のサンプルファイルを参考にしながら、同様な更新を行ってください。
+ `iisConfig` というサブセクションを含む、`appPools` というセクションを追加します。
+ `appPools` ブロックに、アプリケーションプールをリストします。
+ `deployments` セクションで、各アプリケーションの `parameters` セクションを定義します。
+ `parameters` セクションでは、各アプリケーションのアーカイブ、実行するパス、および実行するために使用する `appPool` を指定します。
次のデプロイマニフェストでは、10 分ごとにアプリケーションを再起動する 2 つのアプリケーションプールを構成しています。同時に、指定されたパスで実行される .NET Framework ウェブアプリケーションにも、アプリケーションをアタッチしています。
**Example aws-windows-deployment-manifest.json - アプリケーションプールごとに 1 つのアプリケーション**
```
{
"manifestVersion": 1,
"iisConfig": {"appPools": [
{"name": "MyFirstPool",
"recycling": {"regularTimeInterval": 10}
},
{"name": "MySecondPool",
"recycling": {"regularTimeInterval": 10}
}
]
},
"deployments": {"msDeploy": [
{"name": "Web-app1",
"parameters": {
"archive": "site1.zip",
"iisPath": "/",
"appPool": "MyFirstPool"
}
},
{"name": "Web-app2",
"parameters": {
"archive": "site2.zip",
"iisPath": "/app2",
"appPool": "MySecondPool"
}
}
]
}
}
```
## カスタムデプロイを定義する
さらにきめ細かく制御するには、*カスタムデプロイ*を定義することによって、アプリケーションのデプロイを完全にカスタマイズできます。
このデプロイマニフェストは、32 ビットモードで PowerShell スクリプトを実行するように Elastic Beanstalk に指示します。3 つのスクリプトを指定します。1 つはインスタンスの起動とデプロイ中に実行される`install`スクリプト (`siteInstall.ps1`)、もう 1 つはデプロイ中に新しいバージョンをインストールする前に実行される`uninstall`スクリプト (`siteUninstall.ps1`)、もう 1 つは AWS 管理コンソールで[アプリサーバーの再起動](environments-dashboard-actions.md)を選択したときに実行される`restart`スクリプト (`siteRestart.ps1`) です。
**Example aws-windows-deployment-manifest.json - custom deployment**
```
{
"manifestVersion": 1,
"deployments": {
"custom": [
{
"name": "Custom site",
"architecture" : 32,
"scripts": {
"install": {
"file": "siteInstall.ps1"
},
"restart": {
"file": "siteRestart.ps1"
},
"uninstall": {
"file": "siteUninstall.ps1"
}
}
}
]
}
}
```
ソースバンドルには、マニフェスト、スクリプトと一緒にアプリケーションの実行に必要なアーティファクトをすべて含めます。
**Example Custom-site-bundle.zip**
```
.
|-- aws-windows-deployment-manifest.json
|-- siteInstall.ps1
|-- siteRestart.ps1
|-- siteUninstall.ps1
`-- site-contents.zip
```
# デプロイマニフェストスキーマのリファレンス
デプロイマニフェストは、Elastic Beanstalk が Windows アプリケーションをデプロイおよび設定する方法を定義する JSON ファイルです。このセクションでは、マニフェストスキーマでサポートされているすべてのプロパティと設定オプションの包括的なリファレンスを提供します。
## マニフェスト構造
デプロイマニフェストは、次の最上位構造を持つ特定の JSON スキーマに従います。
**Example 基本的なマニフェスト構造**
```
{
"manifestVersion": 1,
"skipIISReset": false,
"iisConfig": {
"websites": [...],
"appPools": [...]
},
"deployments": {
"msDeploy": [...],
"aspNetCoreWeb": [...],
"custom": [...]
}
}
```
### 最上位プロパティ
`manifestVersion` (必須)
*タイプ:* 数値
*デフォルト:* 1
*有効な値:* 1
マニフェストスキーマのバージョンを指定します。現在、バージョン 1 のみがポートされていますです。
`skipIISReset` (オプション)
型: ブール
*デフォルト:* false
アプリケーションのデプロイ中に IIS をリセットするかどうかを制御します。このフラグは、`msDeploy` と `aspNetCoreWeb` の両方のデプロイタイプに影響します。
*動作:*
+ *指定されていないまたは `false` (デフォルト):* IIS リセットは、インストール、アンインストール、および更新オペレーション中に実行されます。これは従来の動作です。
+ *`true`:* IIS リセットはデプロイオペレーション中にスキップされます。
*利点:*
+ *ダウンタイムの短縮* – アプリケーションでは、デプロイ中のサービスの中断が短くなります。
+ *デプロイの高速化* – IIS が完全に再起動して再初期化するために必要な時間を無くします。
`skipIISReset` を使用すると、[RestartAppServer](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_RestartAppServer.html) オペレーションは、このフラグ設定に関係なく IIS リセットを実行します。
*例*:
```
{
"manifestVersion": 1,
"skipIISReset": true,
"deployments": {
"aspNetCoreWeb": [
{
"name": "my-dotnet-core-app",
"parameters": {
"archive": "dotnet-core-app.zip",
"iisPath": "/"
}
}
]
}
}
```
`deployments` (必須)
*タイプ:* オブジェクト
アプリケーションのデプロイ設定が含まれます。このオブジェクトには、`msDeploy`、`aspNetCoreWeb`、および `custom` のデプロイタイプを含めることができます。
`iisConfig` (オプション)
*タイプ:* オブジェクト
アプリケーションをデプロイする前に適用する IIS 構成設定を定義します。ウェブサイトとアプリケーションプールの両方の設定をサポートします。
## IIS 設定
`iisConfig` セクションにより、アプリケーションをデプロイする前に IIS 設定を構成できるようになります。これには、特定の設定でアプリケーションプールをセットアップし、カスタムバインディングで IIS ウェブサイトを設定することが含まれます。
### IIS ウェブサイト
IIS ウェブサイトにより、アプリケーションをデプロイする前に、物理パスやネットワークバインディングなどのカスタムウェブサイト設定を行えるようになります。
**さまざまな IIS ウェブサイトを作成するための重要な考慮事項**
*ウェブサイトのセットアップ順序:* ウェブサイトは `websites` 配列に表示される順序で順番に設定されます。プラットフォームは各ウェブサイト設定を順番に処理するため、ウェブサイト間に依存関係がある場合は適切な順序を確保します。
*ファイアウォールとポートへのアクセス:* ポート 80 のみがデフォルトの Elastic Beanstalk Windows ファイアウォール設定を介して自動的に公開されます。非標準ポートを使用するようにウェブサイトを設定する場合は、ebextensions またはカスタムデプロイスクリプトを介してカスタムファイアウォールルールを定義し、これらのポートへの外部アクセスを許可する必要があります。
**Example ウェブサイト設定**
```
{
"iisConfig": {
"websites": [
{
"name": "MyCustomSite",
"physicalPath": "C:\inetpub\wwwroot\mysite",
"bindings": [
{
"protocol": "http",
"port": 8080,
"hostName": "mysite.local"
},
{
"protocol": "https",
"port": 8443
}
]
}
]
}
}
```ウェブサイトのプロパティ
`name` (必須)
*タイプ:* 文字列
IIS ウェブサイトの名前。この名前は IIS Manager のウェブサイトを特定するために使用され、IIS 設定内で一意である必要があります。
`physicalPath` (必須)
*タイプ:* 文字列
ウェブサイトファイルが保存されているサーバーの物理パス。このパスは IIS ワーカープロセスからアクセス可能である必要があります。
`bindings` (必須)
*型*: 配列
*最小項目:* 1
ウェブサイトがネットワークリクエストに応答する方法を定義するバインディング設定の配列。各バインディングは、プロトコル、ポート、およびオプションのホスト名を指定します。
#### ウェブサイトバインディング
ウェブサイトバインディングは、IIS ウェブサイトが受信リクエストをリッスンするネットワークエンドポイントを定義します。
`protocol` (必須)
*タイプ:* 文字列
*有効な値:*「http」、「https」
バインディングに使用されるプロトコル。
`port` (必須)
*タイプ:* 整数
*有効な範囲:* 1～65535
ウェブサイトがリクエストをリッスンするポート番号。
`hostName` (オプション)
*タイプ:* 文字列
バインディングのホスト名 (ドメイン名)。
### アプリケーションプール
アプリケーションプールはアプリケーション間の分離を提供し、アプリケーションのグループのランタイム設定を構成することを許可します。
**Example アプリケーションプールの設定**
```
{
"iisConfig": {
"appPools": [
{
"name": "MyAppPool",
"enable32Bit": false,
"managedPipelineMode": "Integrated",
"managedRuntimeVersion": "v4.0",
"queueLength": 1000,
"cpu": {
"limitPercentage": 80,
"limitAction": "Throttle",
"limitMonitoringInterval": 5
},
"recycling": {
"regularTimeInterval": 1440,
"requestLimit": 10000,
"memory": 1048576,
"privateMemory": 524288
}
}
]
}
}
```アプリケーションプールのプロパティ
`name` (必須)
*タイプ:* 文字列
アプリケーションプールの名前。この名前は、デプロイ設定でプールを参照するために使用されます。
`enable32Bit` (オプション)
型: ブール
32 ビットアプリケーションが 64 ビットバージョンの Windows で実行できるようにします。32 ビットの互換性を必要とするレガシーアプリケーションの場合は、`true` に設定します。
`managedPipelineMode` (オプション)
*タイプ:* 文字列
*有効な値:*「Integrated」、「Classic」
アプリケーションプールのリクエスト処理モードを指定します。
`managedRuntimeVersion` (オプション)
*タイプ:* 文字列
*有効な値:*「No Managed Code」、「v2.0」、「v4.0」
アプリケーションプールの .NET Framework バージョンを指定します。
`queueLength` (オプション)
*タイプ:* 整数
追加のリクエストを拒否する前に HTTP.sys がアプリケーションプールに対してキューに入れるリクエストの最大数。
#### CPU 設定
`cpu` オブジェクトは、アプリケーションプールの CPU 使用率の制限とモニタリングを設定します。
`limitPercentage` (オプション)
*タイプ:* 数値
アプリケーションプール内のワーカープロセスが消費できる CPU 時間の最大パーセンテージ。
`limitAction` (オプション)
*タイプ:* 文字列
*有効な値:*「NoAction」、「KillW3wp」、「Throttle」、「ThrottleUnderLoad」
CPU 制限に達したときに実行するアクション。
`limitMonitoringInterval` (オプション)
*タイプ:* 数値
CPU モニタリングとスロットリングの制限のリセット期間 (分単位)。
#### リサイクル設定
`recycling` オブジェクトは、アプリケーションプールワーカープロセスをいつどのようにリサイクルするかを設定します。
`regularTimeInterval` (オプション)
*タイプ:* 整数
アプリケーションプールがリサイクルされるまでの時間間隔 (分単位)。時間ベースのリサイクルを無効にするには、0 に設定します。
`requestLimit` (オプション)
*タイプ:* 整数
リサイクル前にアプリケーションプールが処理するリクエストの最大数。
`memory` (オプション)
*タイプ:* 整数
ワーカープロセスのリサイクルをトリガーする仮想メモリの量 (キロバイト単位)。
`privateMemory` (オプション)
*タイプ:* 整数
ワーカープロセスのリサイクルをトリガーするプライベートメモリの量 (キロバイト単位)。
## デプロイタイプ
`deployments` オブジェクトには、さまざまなアプリケーションタイプのデプロイ設定の配列が含まれています。各デプロイタイプには、特定のプロパティとユースケースがあります。
### MSDeploy デプロイ
MSDeploy デプロイは、Web Deploy (MSDeploy) を使用してデプロイできる従来の .NET Framework アプリケーションに使用されます。
**Example MSDeploy デプロイ構成**
```
{
"deployments": {
"msDeploy": [
{
"name": "WebApp",
"description": "Main web application",
"parameters": {
"appBundle": "webapp.zip",
"iisPath": "/",
"appPool": "DefaultAppPool"
}
}
]
}
}
```MSDeploy デプロイプロパティ
`name` (必須)
*タイプ:* 文字列
デプロイの一意の名前。この名前は、マニフェスト内のすべてのデプロイで一意である必要があります。
`description` (オプション)
*タイプ:* 文字列
人が読み取り可能なデプロイの記述。
`parameters` (必須)
*タイプ:* オブジェクト
MSDeploy オペレーションの設定パラメータ。
`scripts` (オプション)
*タイプ:* オブジェクト
デプロイライフサイクルのさまざまな段階で実行する PowerShell スクリプト。
#### MSDeploy パラメータ
`appBundle` (必須)
*タイプ:* 文字列
マニフェストファイルに対するアプリケーションバンドル (ZIP ファイル) へのパス。このバンドルには、デプロイするアプリケーションファイルが含まれています。
`iisWebSite` (オプション)
*タイプ:* 文字列
*デフォルト:*「Default Web Site」
アプリケーションをデプロイする IIS ウェブサイト。デフォルトでは、アプリケーションは「Default Web Site」にデプロイされます。オプションで、`iisConfig.websites` セクションで設定されたウェブサイト名など、別のウェブサイト名を指定できます。
`iisPath` (オプション)
*タイプ:* 文字列
*デフォルト:* "/"
アプリケーションがデプロイされる IIS の仮想ディレクトリパス。ルートパスには「/」、サブディレクトリには「/api」を使用します。
`appPool` (オプション)
*タイプ:* 文字列
このアプリケーションを実行するアプリケーションプールの名前。
### ASP.NET Core デプロイ
ASP.NET Core デプロイは、.NET Core および .NET 5\$1 アプリケーション専用に設計されています。
**Example ASP.NET Core デプロイ設定**
```
{
"deployments": {
"aspNetCoreWeb": [
{
"name": "CoreAPI",
"description": "ASP.NET Core Web API",
"parameters": {
"appBundle": "coreapi.zip",
"iisPath": "/api",
"appPool": "CoreAppPool"
}
}
]
}
}
```
ASP.NET Core デプロイでは、MSDeploy デプロイと同じプロパティ構造を使用します。主な違いは、アプリケーションに使用されるランタイム環境とホスティングモデルです。ASP.NET Core デプロイパラメータ
`appBundle` (必須)
*タイプ:* 文字列
マニフェストファイルに対するアプリケーションバンドルへのパス。これは、ZIP アーカイブ、または公開された ASP.NET Core アプリケーションを含むディレクトリパスのいずれかにすることができます。
`iisWebSite` (オプション)
*タイプ:* 文字列
*デフォルト:*「Default Web Site」
ASP.NET Core アプリケーションをデプロイする IIS ウェブサイト。デフォルトでは、アプリケーションは「Default Web Site」にデプロイされます。オプションで、`iisConfig.websites` セクションで設定されたウェブサイト名など、別のウェブサイト名を指定できます。
`iisPath` (オプション)
*タイプ:* 文字列
*デフォルト:* "/"
ASP.NET Core アプリケーションの IIS 内の仮想ディレクトリパス。
`appPool` (オプション)
*タイプ:* 文字列
ASP.NET Core アプリケーションのアプリケーションプール。プールは、ASP.NET Core ホスティング用に適切に設定されます。
### カスタムデプロイ
カスタムデプロイでは、PowerShell スクリプトを介してデプロイプロセスを完全に制御できます。このデプロイタイプは、カスタムインストール、設定、またはデプロイロジックを必要とする複雑なシナリオに役立ちます。
**Example カスタムデプロイ設定**
```
{
"deployments": {
"custom": [
{
"name": "CustomService",
"description": "Custom Windows service deployment",
"architecture": 32,
"scripts": {
"install": {
"file": "install-service.ps1"
},
"restart": {
"file": "restart-service.ps1"
},
"uninstall": {
"file": "uninstall-service.ps1",
"ignoreErrors": true
}
}
}
]
}
}
```カスタムデプロイプロパティ
`name` (必須)
*タイプ:* 文字列
カスタムデプロイの一意の名前。
`description` (オプション)
*タイプ:* 文字列
カスタムデプロイの説明。
`architecture` (オプション)
*タイプ:* 整数
*デフォルト:* 32
*有効な値:* 32、64
PowerShell スクリプトの実行モードのアーキテクチャ仕様
`scripts` (必須)
*タイプ:* オブジェクト
デプロイ動作を定義する PowerShell スクリプト。カスタムデプロイでは、他のデプロイタイプと比較して追加のスクリプトタイプをサポートしています。
## デプロイスクリプト
デプロイスクリプトは、デプロイライフサイクル中の特定の時点で実行される PowerShell スクリプトです。異なるデプロイタイプは、異なるスクリプトイベントのセットをサポートします。
### スクリプトイベント
デプロイタイプに応じて、次のスクリプトイベントが利用可能です。標準デプロイスクリプト (msDeploy および aspNetCoreWeb)
`preInstall`
アプリケーションがインストールまたは更新される前に実行されます。
`postInstall`
アプリケーションがインストールまたは更新された後に実行されます。
`preRestart`
アプリケーションが再起動される前に実行されます。
`postRestart`
アプリケーションが再起動された後に実行されます。
`preUninstall`
アプリケーションがアンインストールされる前に実行されます。
`postUninstall`
アプリケーションがアンインストールされた後に実行されます。カスタムデプロイスクリプト (カスタムデプロイのみ)
`install`
カスタムデプロイ用のプライマリインストールスクリプト。このスクリプトは、アプリケーションまたはサービスをインストールする役割を負います。
`restart`
アプリケーションまたはサービスを再起動するスクリプト。環境が再起動されると呼び出されます。
`uninstall`
アプリケーションまたはサービスをアンインストールするスクリプト。環境の終了またはアプリケーションの削除中に呼び出されます。
### スクリプトのプロパティ
各スクリプトは、次のプロパティを持つオブジェクトとして定義されます。
`file` (必須)
*タイプ:* 文字列
マニフェストファイルに対する PowerShell スクリプトファイルへの相対パス。スクリプトには `.ps1` 拡張子がある必要があります。
`ignoreErrors` (オプション)
型: ブール
*デフォルト:* false
`true` に設定すると、スクリプトが失敗してもデプロイは続行されます。これは、重要ではないスクリプトまたはクリーンアップオペレーションに使用します。
**Example スクリプト設定の例**
```
{
"scripts": {
"preInstall": {
"file": "backup-config.ps1",
"ignoreErrors": true
},
"postInstall": {
"file": "configure-app.ps1"
}
}
}
```
# Windows プラットフォームブランチがある EC2 Fast Launch を使用する
EC2 Fast Launch 機能は、Elastic Beanstalk 環境での Windows インスタンスの起動時間を短縮します。このトピックの目的は、Elastic Beanstalk 環境でこの機能を使用する方法について説明することです。[2025 年 1 月 22 日](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2025-01-22-windows.html)にリリースされた Windows プラットフォームバージョン 2.16.2 以降、Elastic Beanstalk プラットフォームリリースには、EC2 Fast Launch が有効になっているベース AMI が含まれています。
## デフォルトの EC2 Fast Launch の可用性
最新の Elastic Beanstalk Windows プラットフォームバージョンには、EC2 Fast Launch が自動的に有効化された AMI が含まれており、追加料金はかかりません。ただし、新しいプラットフォームバージョンがリリースされると、EC2 Fast Launch は古いプラットフォームバージョンのベース AMI で自動的に有効な状態を維持しない場合があります。
EC2 Fast Launch が自動的に有効になっているベース AMI を使用するには、最新の Windows プラットフォームバージョンにアップグレードすることをお勧めします。ただし、既存のプラットフォームバージョンを引き続き使用する必要がある場合は、環境のベース AMI で EC2 Fast Launch を手動で有効にできます。手順については、「[EC2 Fast Launch を手動で設定する](#dotnet-ec2fastlaunch-manual)」を参照してください。
## EC2 Fast Launch を手動で設定する
**注記**
EC2 Fast Launch を手動で有効にすると、EC2 Fast Launch を自動的に有効になっているプラットフォームバージョンを使用する場合と比較して、追加コストが発生する可能性があります。EC2 Fast Launch のコストの詳細については、「*Amazon EC2 ユーザーガイド*」の「[EC2 Fast Launch の基盤となるリソースのコストを管理する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/win-fast-launch-manage-costs.html)」ページを参照してください。
Elastic Beanstalk 環境で使用される Windows ベース AMI で EC2 Fast Launch を有効にするには、次の手順に従います。
**Elastic Beanstalk 環境で EC2 Fast Launch を手動で有効にするには**
1. 環境のベース AMI を特定します。
「[カスタム AMI を作成する](using-features.customenv.md)」の手順に従って、環境のベース AMI ID を特定します。カスタム AMI を作成する必要はありません - 現在のベース AMI ID を見つけるために必要なのは、ステップに従うことのみです。
1. AMI で EC2 Fast Launch を有効にします。
「*Amazon EC2 ユーザーガイド*」の「[EC2 Fast Launch を有効にする](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/win-fast-launch-configure.html)」の手順を使用して、AMI の EC2 Fast Launch を設定します。