本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 使用 Elastic Beanstalk .NET Windows 平台
本主题介绍如何在 Elastic Beanstalk 上配置、构建和运行 ASP.NET 和 .NET Core Windows Web 应用程序。
AWS Elastic Beanstalk 支持适用于不同版本的.NET 编程框架和 Windows 服务器的多种平台。有关完整列表，请参阅 *AWS Elastic Beanstalk 平台*文档中的[使用 IIS 的 Windows Server 上的 .NET](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.net)。
Elastic [Beanstalk 提供了](command-options.md)配置选项，您可以使用这些选项来自定义在 Elastic Beanstalk 环境中的实例 EC2 上运行的软件。您可以配置应用程序所需的环境变量，启用到 Amazon S3 的日志轮换，并设定 .NET Framework 设置。
Elastic Beanstalk 控制台中提供了配置选项，可用于[修改运行环境的配置](environment-configuration-methods-after.md)。要避免在终止环境时丢失环境配置，可以使用[保存的配置](environment-configuration-savedconfig.md)来保存您的设置，并在以后将这些设置应用到其他环境。
要保存源代码中的设置，您可以包含[配置文件](ebextensions.md)。在您每次创建环境或部署应用程序时，会应用配置文件中的设置。您还可在部署期间使用配置文件来安装程序包、运行脚本以及执行其他实例自定义操作。
在 Elastic Beanstalk 控制台中应用的设置会覆盖配置文件中的相同设置（如果存在）。这让您可以在配置文件中包含默认设置，并使用控制台中的特定环境设置加以覆盖。有关优先顺序和其他设置更改方法的更多信息，请参阅[配置选项](command-options.md)。
## 在 Elastic Beanstalk 控制台中配置 .NET 环境
您可以使用 Elastic Beanstalk 控制台启用到 Amazon S3 的日志轮换，配置应用程序可以从环境中读取的变量以及更改 .NET Framework 设置。
**在 Elastic Beanstalk 控制台中配置 .NET 环境**
1. 打开 [Elastic Beanstalk](https://console.aws.amazon.com/elasticbeanstalk) 控制台，然后**在 “区域” 列表中，选择您**的。 AWS 区域
1. 在导航窗格中，选择 **Environments**（环境），然后从列表中选择环境的名称。
1. 在导航窗格中，选择 **Configuration**（配置）。
1. 在 **Updates, monitoring, and logging**（更新、监控和日志记录）配置类别中，选择 **Edit**（编辑）。
### 容器选项
+ **Target .NET runtime**（目标 .NET 运行时）– 设置为 `2.0` 以运行 CLR v2。
+ **Enable 32-bit applications**（启用 32 位应用程序）– 设置为 `True` 可运行 32 位应用程序。
### 日志选项
“日志选项”部分有两个设置：
+ **Instance profile**（实例配置文件）– 指定有权访问与应用程序关联的 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 平台在 `aws:elasticbeanstalk:container:dotnet:apppool` 命名空间中定义可用来配置 .NET 运行时的选项。
以下示例配置文件显示这个命名空间中可用的每个选项的设置：
**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 BeanstalkWindows Server 平台的主要版本迁移
AWS Elastic Beanstalk 其 Windows 服务器平台有多个主要版本。此页面介绍每个主要版本的主要改进以及在迁移到较新版本之前应考虑的事项。
Windows Server 平台当前处于版本 2 (v2)。如果应用程序使用 v2 之前的任何 Windows Server 平台版本，我们建议迁移到 v2。
## Windows Server 平台的主要版本中的新增功能
### Windows Server 平台 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 Server 平台 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
在之前的版本中，配置文件的处理顺序不一致。创建环境期间，`Container Commands` 在应用程序源部署到 IIS 后运行。在向正在运行的环境部署期间，容器命令在新版本部署前运行。在向上扩展期间，系统根本不处理配置文件。
此外，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 Server 平台更早的主要版本迁移
在更新环境之前，先阅读此部分中的迁移注意事项。要将环境的平台更新为较新版本，请参阅[更新 Elastic Beanstalk 环境的平台版本](using-features.platform.upgrade.md)。
### 从 V1 到 V2
Windows Server 平台 v2 不支持 .NET 内核 1.x 和 2.0。如果您正在将应用程序从 Windows Server v1 迁移到 v2，并且您的应用程序使用其中一个 .NET 内核版本，则将您的应用程序更新到 v2 支持的 .NET 内核版本。有关受支持版本的列表，请参阅中的 *AWS Elastic Beanstalk 平台*中的 [将 Windows Server 上的 .NET 与 IIS 结合使用](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 环境中使用自定义亚马逊机器映像（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 配置文件而不致出现问题。
例如，您可以使用从 Amazon S3 将 DLL 文件下载到您的应用程序源中： 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 如何部署您的应用程序。通过使用此方法，您无需使用 `MSDeploy` 为在网站根路径上运行的单个 ASP.NET 应用程序生成源包。相反，您可以使用清单文件在不同路径上运行多个应用程序。或者，您也可以告诉 Elastic Beanstalk 使用 ASP.NET Core 部署和运行应用程序。您也可以使用部署清单配置一个应用程序池，在其中运行您的应用程序。
部署清单向 Elastic Beanstalk 添加了对 [.NET Core 应用程序](#dotnet-manifest-dotnetcore)的支持。您可以在不使用部署清单的情况下部署 .NET Framework 应用程序。但是，.NET Core 应用程序需要在 Elastic Beanstalk 上运行部署清单。使用部署清单时，请为每个应用程序创建一个站点存档，然后将该站点存档捆绑在包含部署清单的另一个 ZIP 存档中。
部署清单还增加了[在不同路径上运行多个应用程序](#dotnet-manifest-multiapp)的能力。一个部署清单定义了一组部署目标，每个部署目标有一个站点存档和一个 IIS 应在其上运行部署清单的路径。例如，您可以在 `/api` 路径上运行 Web API，以服务异步请求，以及使用 API 的根路径上的 Web 应用程序。
您可以使用部署清单来[配置使用自定义绑定和物理路径的 IIS 网站](#dotnet-manifest-websites)。这样，您便可在部署应用程序之前设置用于侦听特定端口或主机名的网站。
您也可以使用部署清单[通过在 IIS 或 Kestrel 中的应用程序池运行多个应用程序](#dotnet-manifest-apppool)。您可以将应用程序池配置为定期重启应用程序、运行 32 位应用程序或使用特定版本的 .NET 框架运行时。
要进行完全自定义，您可以在 Windows 中[编写自己的部署脚本](#dotnet-manifest-custom)， PowerShell 然后告诉 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)
+ [使用应用程序请求路由（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 内核应用程序。
**Example aws-windows-deployment-manifest.json-.NET 核心**
```
{
"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
```
## 运行多个应用程序
您可以定义多个部署目标，从而使用一个部署清单运行多个应用程序。
以下部署清单配置两个 .NET Core 应用程序。`WebApiSampleApp` 应用程序实现一个简单的 Web API 并在 `/api` 路径提供异步请求。`DotNetSampleApp` 应用程序是在根路径上服务请求的 Web 应用程序。
**Example aws-windows-deployment-manifest.json-多个应用程序**
```
{
"manifestVersion": 1,
"deployments": {
"aspNetCoreWeb": [
{
"name": "WebAPISample",
"parameters": {
"appBundle": "WebApiSampleApp.zip",
"iisPath": "/api"
}
},
{
"name": "DotNetSample",
"parameters": {
"appBundle": "DotNetSampleApp.zip",
"iisPath": "/"
}
}
]
}
}
```
此处提供了一个具有多个应用场合的示例应用程序：
+ **可部署的源代码包** [--v2.zip dotnet-multiapp-sample-bundle](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 “” 的网站
+ 该网站在端口 8080 上具有 HTTP 绑定，并具有特定的主机名
+ ASP.NET Core 应用程序使用 `iisWebSite` 参数部署到此自定义网站
## 使用应用程序请求路由（ARR）
应用程序请求路由 (ARR) 和 URL 重写模块已预先安装并在 Elastic Beanstalk Windows 中可用。 AMIs这些模块使用 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 环境中支持多个应用程序。有两种方法可供选择：
+ 您可以将 out-of-process托管模式与 Kestrel 网络服务器配合使用。使用此模型，您可以配置多个应用程序以在一个应用程序池中运行。
+ 您可以使用进程内托管模式。使用此模型，您可以使用多个应用程序池运行多个应用程序，每个池中只有一个应用程序。如果您使用的是 IIS 服务器并且需要运行多个应用程序，则必须使用此方法。
要将 Kesttrel 配置为在一个应用程序池中运行多个应用程序，请在 `hostingModel="OutofProcess"` 文件中添加 `web.config`。考虑以下示例。
**Example web.config-适用于 Ke out-of-process strel 托管模型**
```
```
**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 不支持一个应用程序池中的多个应用程序，因为它使用进程内托管模型。因此，您需要通过将每个应用程序分配到一个应用程序池来配置多个应用程序。换句话说，只将一个应用程序分配到一个应用程序池。
您可以将 IIS 配置为在 `aws-windows-deployment-manifest.json` 文件中使用不同的应用程序池。在参考下一个示例文件时进行以下更新：
+ 添加 `iisConfig` 部分，该部分包含称为 `appPools` 的子部分。
+ 在 `appPools` 数据块中，列出应用程序池。
+ 在 `deployments` 部分中，为每个应用程序定义 `parameters` 部分。
+ 对于每个应用程序，`parameters` 部分都将指定一个存档、一个运行该存档的路径以及要在其中运行的 `appPool` 。
以下部署清单配置了两个应用程序池，它们每 10 分钟重新启动一次应用程序。他们还将应用程序附加到以指定路径运行的 .NET Framework Web 应用程序。
**Example aws-windows-deployment-manifest.json-每个应用程序池一个应用程序**
```
{
"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"
}
}
]
}
}
```
## 定义自定义部署
为了实现更多控制，您可以通过定义*自定义部署* 来完全自定义应用程序部署。
此部署清单指示 Elastic Beanstalk 在 32 位模式下执行脚 PowerShell 本。它指定了三个脚本：一个`install`在实例启动和部署期间运行的`uninstall`脚本 (`siteUninstall.ps1`)，一个在部署期间安装新版本之前执行的`restart`脚本 (`siteRestart.ps1`)，以及在 AWS 管理控制台中选择 “[重新启动应用服务器](environments-dashboard-actions.md)” 时运行的脚本 ()。`siteInstall.ps1`
**Example aws-windows-deployment-manifest.json-自定义部署**
```
{
"manifestVersion": 1,
"deployments": {
"custom": [
{
"name": "Custom site",
"architecture" : 32,
"scripts": {
"install": {
"file": "siteInstall.ps1"
},
"restart": {
"file": "siteRestart.ps1"
},
"uninstall": {
"file": "siteUninstall.ps1"
}
}
}
]
}
}
```
包括使用清单和脚本运行源包中的应用程序所需的任何项目。
**Example C ustom-site-bundle .zip**
```
.
|-- aws-windows-deployment-manifest.json
|-- siteInstall.ps1
|-- siteRestart.ps1
|-- siteUninstall.ps1
`-- site-contents.zip
```
# 部署清单架构参考
部署清单是一个 JSON 文件，用于定义 Elastic Beanstalk 应如何部署和配置您的 Windows 应用程序。本节为清单架构中所有支持的属性和配置选项提供全面的参考。
## 清单结构
部署清单遵循具有以下顶级结构的特定 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 管理器中标识网站，并且在 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 框架应用程序。
**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 和 aspNetCore Web）
`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 快速启动
EC2 快速启动功能可缩短您的 Elastic Beanstalk 环境中的 Windows 实例启动时间。本主题旨在引导您在 Elastic Beanstalk 环境中使用此功能。从 [2025 年 1 月 22 日发布的 Windows 平台版本 2.16.2 开始，](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2025-01-22-windows.html)Elastic Beanstalk 平台版本包括启用快速启动的基础版本。 AMIs EC2
## 默认 EC2 快速启动可用性
最新的 Elastic Beanstalk Windows 平台版本 AMIs 包括自动启用快速启动 EC2 的基本版本，无需支付额外费用。但是，当较新的平台版本发布时， EC2 Fast Launch 可能不会在旧平台版本的基础 AMIs 上自动启用。
我们建议升级到最新的 Windows 平台版本，以便在自动启用 EC2 快速启动的情况下 AMIs 使用基本版本。但是，如果您需要继续使用现有平台版本，则可以在环境的基础 AMI 上手动启用 EC2 Fast Launch。有关说明，请参阅[手动配置 EC2 快速启动](#dotnet-ec2fastlaunch-manual)。
## 手动配置 EC2 快速启动
**注意**
与使用自动启用 EC2 快速启动的平台版本相比，手动启用 EC2 快速启动可能会产生额外费用。有关 EC2 快速启动成本的更多信息，请参阅 *Amazon EC2 用户指南*中的[管理 EC2 快速启动底层资源的成](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/win-fast-launch-manage-costs.html)本页面。
按照以下步骤在你的 Elastic Beanstalk 环境使用的基于 Windows 的 AMI 上启用 EC2 快速启动：
**为您的 Elastic Beanstalk 环境手动启用 EC2 快速启动**
1. 确定环境的基础 AMI：
按照[创建自定义 AMI](using-features.customenv.md) 中的步骤来确定环境的基础 AMI ID。请注意，您无需创建自定义 AMI，只需按照步骤查找当前的基础 AMI ID 即可。
1. 在 AMI 上启用 EC2 快速启动：
使用 *Amazon EC2 用户指南*中的[启用 EC2 快速启动](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/win-fast-launch-configure.html)中的说明为您的 AMI 配置 EC2 快速启动。