Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Uso de la plataforma .NET Windows de Elastic Beanstalk
En este tema se describe cómo configurar, crear y ejecutar las aplicaciones ASP.NET y .NET Core Windows en Elastic Beanstalk.
AWS Elastic Beanstalk admite varias plataformas para diferentes versiones del marco de programación de.NET y Windows Server. Consulte [.NET en Windows Server con IIS](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.net) en el documento *Plataformas de AWS Elastic Beanstalk * para ver una lista completa.
Elastic [Beanstalk proporciona](command-options.md) opciones de configuración que puede usar para personalizar el software que se ejecuta EC2 en las instancias de su entorno de Elastic Beanstalk. También puede configurar las variables de entorno que necesita la aplicación, habilitar la rotación de registros en Amazon S3 y establecer la configuración del marco .NET.
En la consola de Elastic Beanstalk hay opciones de configuración disponibles para [modificar la configuración de un entorno en ejecución](environment-configuration-methods-after.md). Para evitar perder la configuración del entorno cuando lo termina, puede usar las [configuraciones guardadas](environment-configuration-savedconfig.md) para guardar la configuración y aplicarla posteriormente a otro entorno.
Para guardar la configuración en el código fuente, puede incluir [archivos de configuración](ebextensions.md). Los valores de configuración de los archivos de configuración se aplican cada vez que crea un entorno o que implementa la aplicación. También puede usar archivos de configuración para instalar paquetes, ejecutar scripts y llevar a cabo otras operaciones de personalización de instancias durante las implementaciones.
La configuración aplicada en la consola de Elastic Beanstalk anula la misma configuración en los archivos de configuración, si existe. Esto le permite tener la configuración predeterminada en los archivos de configuración y anularla con la configuración específica del entorno en la consola. Para obtener más información acerca de la prioridad y otros métodos para cambiar valores de configuración, consulte [Opciones de configuración](command-options.md).
## Configuración del entorno de .NET en la consola de Elastic Beanstalk
Puede utilizar la consola de Elastic Beanstalk para habilitar la rotación de registros en Amazon S3, configurar variables que la aplicación pueda leer desde el entorno y cambiar la configuración del marco .NET.
**Para configurar el entorno de .NET en la consola de Elastic Beanstalk**
1. Abra la consola de [Elastic Beanstalk](https://console.aws.amazon.com/elasticbeanstalk) y, **en** la lista Regiones, seleccione su. Región de AWS
1. En el panel de navegación, elija **Environments** (Entornos) y, a continuación, elija el nombre del entorno en la lista.
1. En el panel de navegación, elija **Configuración**.
1. En la categoría de configuración **Actualizaciones, supervisión y registro**, seleccione **Edición de**.
### Opciones de contenedor
+ **Target .NET runtime (Tiempo de ejecución de .NET de destino)**: establezca en `2.0` para ejecutar CLR v2.
+ **Enable 32-bit applications (Habilitar aplicaciones de 32 bits)**: establezca en `True` para ejecutar aplicaciones de 32 bits.
### Log Options (Opciones de registro)
La sección Log Options tiene dos valores:
+ **Instance profile (Perfil de instancia)**: especifica el perfil de instancia que tiene permiso para obtener acceso al bucket de Amazon S3 asociado con la aplicación.
+ **Habilite la rotación de archivos de registro a Amazon S3**: especifica si los archivos de registro de las EC2 instancias de Amazon de su aplicación se copian en el bucket de Amazon S3 asociado a su aplicación.
### Propiedades del entorno
La sección **Propiedades del entorno** le permite especificar los ajustes de configuración del entorno en las EC2 instancias de Amazon que ejecutan su aplicación. Estos ajustes se pasan como pares clave-valor a la aplicación. Utilice `System.GetEnvironmentVariable` para leerlos. Pueden existir claves idénticas en ambos `web.config` y como propiedades de entorno. Utilice el espacio de nombres `System.Configuration` para leer valores de `web.config`.
```
NameValueCollection appConfig = ConfigurationManager.AppSettings;
string endpoint = appConfig["API_ENDPOINT"];
```
Para obtener más información, consulte [Configuración de las variables de entorno y otras opciones de software](environments-cfg-softwaresettings.md).
## El espacio de nombres aws:elasticbeanstalk:container:dotnet:apppool
Puede usar un [archivo de configuración](ebextensions.md) para definir opciones de configuración y realizar otras tareas de configuración en las instancias durante las implementaciones. Las opciones de configuración pueden ser [específicas de la plataforma](command-options-specific.md) o aplicarse a [todas las plataformas](command-options-general.md) del servicio de Elastic Beanstalk en su conjunto. Las opciones de configuración se organizan en *espacios de nombres*.
La plataforma .NET define opciones en el espacio de nombres `aws:elasticbeanstalk:container:dotnet:apppool` que puede utilizar para configurar el tiempo de ejecución de .NET.
En el siguiente ejemplo, el archivo de configuración muestra los ajustes de cada una de las opciones disponibles en este espacio de nombres:
**Example .ebextensions/dotnet-settings.config**
```
option_settings:
aws:elasticbeanstalk:container:dotnet:apppool:
Target Runtime: 2.0
Enable 32-bit Applications: True
```
Elastic Beanstalk cuenta con numerosas opciones de configuración para personalizar el entorno. Además de los archivos de configuración, también puede definir opciones en la consola, configuraciones guardadas, la CLI de EB o la AWS CLI. Para obtener más información, consulte [Opciones de configuración](command-options.md).
# Migración entre las versiones principales de la plataforma Windows Server de Elastic Beanstalk
AWS Elastic Beanstalk ha tenido varias versiones principales de su plataforma Windows Server. En esta página se describen las principales mejoras de cada versión principal y lo que se ha de tener en cuenta antes de migrar a una versión posterior.
La plataforma Windows Server se encuentra actualmente en la versión 2 (v2). Si la aplicación utiliza una versión de la plataforma de Windows Server anterior a la versión 2, le recomendamos que migre a dicha versión.
## Novedades en las versiones principales de la plataforma Windows Server
### Plataforma Windows Server versión 2
La versión 2 (v2) de la plataforma Windows Server de Elastic Beanstalk se [publicó en febrero de 2019](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2019-02-21-windows-v2.html). La versión 2 acerca el comportamiento de la plataforma Windows Server al de las plataformas basadas en Linux de Elastic Beanstalk de varias maneras importantes. La versión 2 es totalmente compatible con la versión 1, lo que facilita la migración desde la versión 1.
La plataforma Windows Server ahora es compatible con lo siguiente:
+ *Control de versiones*: cada lanzamiento obtiene un nuevo número de versión y puede consultar las versiones anteriores (que aún estén disponibles) al crear y administrar los entornos.
+ *Estado mejorado*: consulte [Informes y monitoreo de estado mejorados de Elastic Beanstalk](health-enhanced.md) para obtener más información.
+ Implementaciones *inmutables* y *continuas con un lote adicional*: para ver más información sobre las políticas de implementación, consulte [Implementación de aplicaciones en entornos Elastic Beanstalk](using-features.deploy-existing-version.md).
+ *Actualizaciones inmutables*: para obtener más información acerca de los tipos de actualización, consulte [Cambios de configuración](environments-updating.md).
+ *Actualizaciones de plataformas administradas*: para obtener más información, consulte [Actualizaciones de plataforma administradas](environment-platform-update-managed.md).
**nota**
Las nuevas características de implementación y actualización dependen del estado mejorado. Habilite el estado mejorado para utilizarlas. Para obtener más información, consulte [Habilitación de informes de estado mejorado de Elastic Beanstalk](health-enhanced-enable.md).
### Plataforma Windows Server versión 1
La versión 1.0.0 (v1) de la plataforma Windows Server de Elastic Beanstalk se publicó en octubre de 2015. Esta versión cambia el orden en que Elastic Beanstalk procesa los comandos en [archivos de configuración](ebextensions.md) durante la creación y las actualizaciones del entorno.
Las versiones anteriores de la plataforma no tienen número de versión en el nombre de la pila de soluciones:
+ Windows Server 2012 R2 de 64 bits con IIS 8.5
+ Windows Server Core 2012 R2 de 64 bits con IIS 8.5
+ Windows Server 2012 de 64 bits con IIS 8
+ Windows Server 2008 R2 de 64 bits con IIS 7.5
En las versiones anteriores, el orden de procesamiento de los archivos de configuración no era coherente. Durante la creación del entorno, `Container Commands` se ejecutaba después de que el código fuente de la aplicación se implementaba en IIS. Durante las implementaciones en entornos en ejecución, los comandos de contenedor se ejecutaban antes de que se implementara la nueva versión. En las operaciones de escalado vertical, los archivos de configuración no se procesaban.
Además, IIS se iniciaba antes de que los comandos de contenedor se ejecutaran. Este comportamiento ha hecho que algunos clientes implementen soluciones en los comandos de contenedor, que detienen el servidor de IIS antes de que los comandos se ejecuten y lo inician de nuevo cuando se han completado.
La versión 1 corrige esta incoherencia y acerca el comportamiento de la plataforma Windows Server al de las plataformas basadas en Linux de Elastic Beanstalk. En la plataforma de la versión 1, Elastic Beanstalk siempre ejecuta los comandos de contenedor antes de iniciar el servidor de IIS.
Las pilas de la solución de la plataforma de la v1 tienen `v1` detrás de la versión de Windows Server:
+ Windows Server 2012 R2 v1.1.0 de 64 bits con IIS 8.5
+ Windows Server Core 2012 R2 v1.1.0 de 64 bits con IIS 8.5
+ Windows Server 2012 v1.1.0 de 64 bits con IIS 8
+ Windows Server 2008 R2 v1.1.0 de 64 bits con IIS 7.5
Asimismo, la plataforma de la v1 extrae el contenido del paquete de código fuente de la aplicación en `C:\staging\` antes de ejecutar los comandos de contenedor. Una vez que los comandos de contenedor se han completado, el contenido de esta carpeta se comprime en un archivo .zip y se implementa en IIS. Este flujo de trabajo le permite modificar el contenido del paquete de código fuente de la aplicación utilizando comandos o un script antes de la implementación.
## Migración desde versiones principales anteriores de la plataforma Windows Server
Consulte en esta sección las consideraciones de migración antes de actualizar el entorno. Para actualizar la plataforma del entorno a una versión más reciente, consulte [Actualización de la versión de la plataforma del entorno de Elastic Beanstalk](using-features.platform.upgrade.md).
### De V1 a V2
La plataforma de Windows Server v2 no es compatible con .NET Core 1.x y 2.0. Si va a migrar su aplicación desde Windows Server v1 hasta v2 y la aplicación utiliza una de estas versiones de .NET Core, actualice la aplicación a una versión de .NET Core compatible con v2. Para ver una lista de versiones compatibles, consulte [.NET en Windows Server con IIS](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.net) en *Plataformas de AWS Elastic Beanstalk *.
Si la aplicación utiliza una imagen de máquina de Amazon (Amazon Machine Image, AMI) personalizada, cree una nuevo AMI personalizada basada en una AMI de la plataforma de Windows Server v2. Para obtener más información, consulte [Uso de una imagen de máquina de Amazon (AMI) personalizada en el entorno de Elastic Beanstalk](using-features.customenv.md).
**nota**
Las características de implementación y actualización que son nuevas en Windows Server v2 dependen del estado mejorado. Al migrar un entorno a v2, el estado mejorado está deshabilitado. Habilítelo para utilizar estas características. Para obtener más información, consulte [Habilitación de informes de estado mejorado de Elastic Beanstalk](health-enhanced-enable.md).
### Antes de la versión 1
Además de las cuestiones relativas a la migración desde v1, si va a migrar la aplicación desde una pila de soluciones de Windows Server anterior a la v1 y actualmente utiliza comandos de contenedor, quite los comandos que haya agregado para evitar incoherencias de procesamiento al migrar a una versión más reciente. A partir de la v1, está garantizado que los comandos de contenedores se van a ejecutar por completo antes de que el código fuente de la aplicación que se implementa y antes de que IIS se inicie. Esto le permite realizar cambios en el código fuente en `C:\staging` y modificar los archivos de configuración de IIS durante este paso sin problemas.
Por ejemplo, puede utilizar el AWS CLI para descargar un archivo DLL a la fuente de la aplicación desde Amazon S3:
`.ebextensions\copy-dll.config`
```
container_commands:
copy-dll:
command: aws s3 cp s3://amzn-s3-demo-bucket/dlls/large-dll.dll .\lib\
```
Para obtener más información sobre cómo usar archivos de configuración, consulte [Personalización avanzada de entornos con archivos de configuración (`.ebextensions`)](ebextensions.md).
# Ejecutar múltiples aplicaciones y aplicaciones centrales ASP.NET con un manifiesto de implementación
Puede utilizar un manifiesto de implementación para indicarle a Elastic Beanstalk cómo se va a implementar la aplicación. Al utilizar este método, no es necesario utilizar `MSDeploy` para generar un paquete de código fuente para una única aplicación ASP.NET que se ejecuta en la ruta raíz del sitio web. En su lugar, puede utilizar un archivo de manifiesto para ejecutar varias aplicaciones en rutas diferentes. O bien, puede indicarle a Elastic Beanstalk que implemente y ejecute la aplicación con ASP.NET Core. También puede utilizar un manifiesto de implementación para configurar un grupo de aplicaciones en el que ejecutará las aplicaciones.
Los manifiestos de implementación añaden compatibilidad con las [aplicaciones de .NET Core](#dotnet-manifest-dotnetcore) en Elastic Beanstalk. Puede implementar una aplicación.NET Framework sin un manifiesto de implementación. Sin embargo, las aplicaciones.NET Core requieren un manifiesto de implementación para ejecutarse en Elastic Beanstalk. Si utiliza un manifiesto de implementación, debe crear un archivo del sitio para cada aplicación y empaquetar todos ellos después en un segundo ZIP que contenga el manifiesto de implementación.
Los manifiestos de implementación también brindan la posibilidad de [ejecutar varias aplicaciones en diferentes rutas](#dotnet-manifest-multiapp). Un manifiesto de implementación define una serie de objetivos de implementación, cada uno de ellos con un archivo del sitio y una ruta en la que IIS debe ejecutarse. Por ejemplo, puede ejecutar una API web en la ruta `/api` para que atienda las solicitudes asincrónicas y una aplicación web en la ruta raíz que utilice la API.
Puede usar un manifiesto de implementación para [configurar sitios web de IIS con enlaces personalizados y rutas físicas](#dotnet-manifest-websites). Esto le permite configurar sitios web que escuchen los nombres de puertos o hosts específicos antes de implementar las aplicaciones.
También puede utilizar un manifiesto de implementación para [ejecutar varias aplicaciones mediante grupos de aplicaciones en IIS o Kestrel](#dotnet-manifest-apppool). Puede configurar un grupo de aplicaciones para reiniciar las aplicaciones periódicamente, ejecutar aplicaciones de 32 bits o utilizar una versión específica del entorno de ejecución de .NET Framework.
Para una personalización completa, puede [escribir sus propios scripts de implementación](#dotnet-manifest-custom) en Windows PowerShell e indicar a Elastic Beanstalk qué scripts debe ejecutar para instalar, desinstalar y reiniciar la aplicación.
El manifiesto de implementación y las características relacionadas requieren una plataforma de Windows Server [versión 1.2.0 o posterior](dotnet-v2migration.md).
Para obtener información detallada sobre todas las opciones de configuración, propiedades y características avanzadas disponibles, como omitir los restablecimientos de IIS, consulte [deployment manifest schema reference](dotnet-manifest-schema.md).
**Topics**
+ [Aplicaciones de .NET Core](#dotnet-manifest-dotnetcore)
+ [Ejecutar múltiples aplicaciones](#dotnet-manifest-multiapp)
+ [Configurar sitios web de IIS](#dotnet-manifest-websites)
+ [Uso de enrutamiento de solicitudes de aplicaciones (ARR)](#dotnet-manifest-arr)
+ [Configuración de grupos de aplicaciones](#dotnet-manifest-apppool)
+ [Definir implementaciones personalizadas](#dotnet-manifest-custom)
+ [Referencia del esquema del manifiesto de implementación](dotnet-manifest-schema.md)
## Aplicaciones de .NET Core
Puede utilizar un manifiesto de implementación para ejecutar aplicaciones .NET Core en Elastic Beanstalk. .NET Core es una versión multiplataforma de .NET que incluye una herramienta de línea de comandos (`dotnet`). Puede utilizarla para generar una aplicación, ejecutarla localmente y prepararla para su publicación.
Para ejecutar una aplicación de .NET Core en Elastic Beanstalk, puede ejecutar `dotnet publish` y empaquetar la salida en un archivo ZIP, sin incluir los directorios que contiene. Coloque el archivo del sitio en un paquete de código fuente con un manifiesto de implementación que tenga un destino de implementación de tipo `aspNetCoreWeb`.
El siguiente manifiesto de implementación ejecuta una aplicación de .NET Core desde un archivo del sitio llamado `dotnet-core-app.zip` situado en la ruta raíz.
**Example aws-windows-deployment-manifest.json: .NET core**
```
{
"manifestVersion": 1,
"deployments": {
"aspNetCoreWeb": [
{
"name": "my-dotnet-core-app",
"parameters": {
"archive": "dotnet-core-app.zip",
"iisPath": "/"
}
}
]
}
}
```
Empaquete el manifiesto y el archivo del sitio en un ZIP para crear un paquete de código fuente.
**Example dotnet-core-bundle.zip**
```
.
|-- aws-windows-deployment-manifest.json
`-- dotnet-core-app.zip
```
El archivo del sitio contiene el código compilado de la aplicación, las dependencias y el archivo `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
```
## Ejecutar múltiples aplicaciones
Para ejecutar varias aplicaciones con un manifiesto de implementación, debe definir diferentes objetivos de implementación.
El manifiesto de implementación siguiente configura dos aplicaciones .NET Core. La aplicación `WebApiSampleApp` implementa una API web simple y sirve solicitudes asíncronas en la ruta `/api`. La aplicación `DotNetSampleApp` es una aplicación web que atiende solicitudes en la ruta raíz.
**Example aws-windows-deployment-manifest.json: múltiples aplicaciones**
```
{
"manifestVersion": 1,
"deployments": {
"aspNetCoreWeb": [
{
"name": "WebAPISample",
"parameters": {
"appBundle": "WebApiSampleApp.zip",
"iisPath": "/api"
}
},
{
"name": "DotNetSample",
"parameters": {
"appBundle": "DotNetSampleApp.zip",
"iisPath": "/"
}
}
]
}
}
```
Aquí hay disponible una aplicación de muestra con varias aplicaciones:
+ **[Paquete de código fuente desplegable: -v2.zip dotnet-multiapp-sample-bundle](samples/dotnet-multiapp-sample-bundle-v2.zip)**
+ **Código fuente**[: -v2.zip dotnet-multiapp-sample-source](samples/dotnet-multiapp-sample-source-v2.zip)
## Configurar sitios web de IIS
Puede configurar sitios web de IIS con enlaces personalizados y rutas físicas mediante el manifiesto de implementación. Esto resulta útil cuando necesita configurar sitios web que escuchen en puertos específicos, usen nombres de host personalizados o publiquen contenido de directorios específicos.
El siguiente manifiesto de implementación configura un sitio web de IIS personalizado que escucha en HTTP con un número de puerto específico y una ruta física personalizada:
**Example aws-windows-deployment-manifest.json: configuración del sitio web de 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": "/"
}
}
]
}
}
```
En este ejemplo:
+ Se crea un sitio web denominado MyCustomSite "» con una ruta física personalizada
+ El sitio web tiene un enlace HTTP en el puerto 8080 con un nombre de host específico.
+ La aplicación ASP.NET Core se implementa en este sitio web personalizado mediante el parámetro `iisWebSite`.
## Uso de enrutamiento de solicitudes de aplicaciones (ARR)
Los módulos Application Request Routing (ARR) y URL Rewrite vienen preinstalados y están disponibles en Elastic Beanstalk Windows. AMIs Estos módulos permiten escenarios de enrutamiento avanzados y la manipulación de URL mediante la configuración de IIS con configuración de ebextensions o aplicaciones.
El siguiente ejemplo muestra un manifiesto de implementación simple que configura un sitio web con un puerto personalizado, combinado con una configuración de ebextensions que establece el enrutamiento de ARR básico:
**Example aws-windows-deployment-manifest.json: configuración ARR sencilla**
```
{
"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"
}
}
]
}
}
```
La configuración de ARR se realiza a través de ebextensions. La siguiente configuración establece las reglas básicas de enrutamiento de ARR:
**Example .ebextensions/arr-config.config: configuración básica de 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
```
Esta configuración crea un sitio web en el puerto 8080 y configura ARR para enrutar todas las solicitudes entrantes a la aplicación de backend que se ejecuta en ese sitio.
## Configuración de grupos de aplicaciones
Puede admitir varias aplicaciones en su entorno Windows. Hay dos enfoques disponibles:
+ Puede usar el modelo de out-of-process alojamiento con el servidor web Kestrel. Con este modelo, puede configurar varias aplicaciones para que se ejecuten en un grupo de aplicaciones.
+ Puede utilizar el modelo de alojamiento en proceso. Con este modelo, se utilizan varios grupos de aplicaciones para ejecutar varias aplicaciones con una sola aplicación en cada grupo. Si utiliza el servidor IIS y necesita ejecutar varias aplicaciones, debe utilizar este enfoque.
Si desea configurar Kestrel para que ejecute varias aplicaciones en un grupo de aplicaciones, agregue `hostingModel="OutofProcess"` en el archivo `web.config`. Considere los siguientes ejemplos:
**Example web.config: para el modelo de alojamiento de Kestrel out-of-process**
```
```
**Example aws-windows-deployment-manifest.json: múltiples aplicaciones**
```
{
"manifestVersion": 1,
"deployments": {"msDeploy": [
{"name": "Web-app1",
"parameters": {"archive": "site1.zip",
"iisPath": "/"
}
},
{"name": "Web-app2",
"parameters": {"archive": "site2.zip",
"iisPath": "/app2"
}
}
]
}
}
```
IIS no admite varias aplicaciones en un grupo de aplicaciones porque utiliza el modelo de alojamiento en proceso. Por lo tanto, debe configurar varias aplicaciones mediante la asignación de cada aplicación a un grupo de aplicaciones. En otras palabras, asigne solo una aplicación a un grupo de aplicaciones.
Puede configurar IIS para que use diferentes grupos de aplicaciones en el archivo `aws-windows-deployment-manifest.json`. Realice las siguientes actualizaciones al consultar el siguiente archivo de ejemplo:
+ Agregue una sección `iisConfig` que incluya una subsección llamada `appPools`.
+ En el bloque `appPools`, enumere los grupos de aplicaciones.
+ En la sección `deployments`, defina una sección `parameters` para cada aplicación.
+ Para cada aplicación, la sección `parameters` especifica un archivo, una ruta de acceso para ejecutarlo y una `appPool` en la que se ejecutará.
El siguiente manifiesto de implementación configura dos grupos de aplicaciones que reinician su aplicación cada 10 minutos. También adjuntan sus aplicaciones a una aplicación web .NET Framework que se ejecuta en la ruta especificada.
**Example aws-windows-deployment-manifest.json: una aplicación por grupo de aplicaciones**
```
{
"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"
}
}
]
}
}
```
## Definir implementaciones personalizadas
Para tener aún más control, puede personalizar completamente la implementación de una aplicación y definir una *implementación personalizada*.
Este manifiesto de implementación indica a Elastic Beanstalk PowerShell que ejecute scripts en modo de 32 bits. [Especifica tres scripts: un `install` script (`siteInstall.ps1`) que se ejecuta durante el lanzamiento y las implementaciones de la instancia, un `uninstall` script (`siteUninstall.ps1`) que se ejecuta antes de instalar nuevas versiones durante las implementaciones y un `restart` script (`siteRestart.ps1`) que se ejecuta al seleccionar Restart App Server en la consola de administración.](environments-dashboard-actions.md) AWS
**Example aws-windows-deployment-manifest.json: implementación personalizada**
```
{
"manifestVersion": 1,
"deployments": {
"custom": [
{
"name": "Custom site",
"architecture" : 32,
"scripts": {
"install": {
"file": "siteInstall.ps1"
},
"restart": {
"file": "siteRestart.ps1"
},
"uninstall": {
"file": "siteUninstall.ps1"
}
}
}
]
}
}
```
Incluya los artefactos necesarios para ejecutar la aplicación en el paquete de código fuente con el manifiesto y los scripts.
**Example Custom-site-bundle: .zip**
```
.
|-- aws-windows-deployment-manifest.json
|-- siteInstall.ps1
|-- siteRestart.ps1
|-- siteUninstall.ps1
`-- site-contents.zip
```
# Referencia del esquema del manifiesto de implementación
El manifiesto de implementación es un archivo JSON que define cómo Elastic Beanstalk debe implementar y configurar las aplicaciones de Windows. En esta sección se proporciona una referencia completa de todas las propiedades y opciones de configuración compatibles en el esquema del manifiesto.
## Estructura del manifiesto
El manifiesto de implementación sigue un esquema JSON específico con la siguiente estructura de nivel superior:
**Example Estructura básica del manifiesto**
```
{
"manifestVersion": 1,
"skipIISReset": false,
"iisConfig": {
"websites": [...],
"appPools": [...]
},
"deployments": {
"msDeploy": [...],
"aspNetCoreWeb": [...],
"custom": [...]
}
}
```
### Propiedades de nivel superior
`manifestVersion` (obligatorio)
*Tipo*: Número
*Valor predeterminado*: 1
*Valores válidos: 1*
Especifica la versión del esquema del manifiesto. Actualmente, solo se admite la versión 1.
`skipIISReset` (opcional)
*Tipo*: Booleano
*Valor predeterminado:* falso
Controla si IIS se restablece durante las implementaciones de aplicaciones. Este indicador afecta a los tipos de implementación `msDeploy` y `aspNetCoreWeb`.
*Comportamiento:*
+ *No especificado o `false` (predeterminado):* los restablecimientos de IIS se realizan durante las operaciones de instalación, desinstalación y actualización. Este es el comportamiento tradicional.
+ *`true`:* los restablecimientos de IIS se omiten durante las operaciones de implementación.
*Beneficios:*
+ *Menor tiempo de inactividad*: las aplicaciones experimentan interrupciones de servicio más breves durante las implementaciones.
+ *Implementaciones más rápidas*: elimina el tiempo necesario para que IIS se reinicie y reinicialice por completo.
Cuando se utiliza`skipIISReset`, la [RestartAppServer](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_RestartAppServer.html)operación restablece el IIS independientemente de la configuración de este indicador.
*Ejemplo:*
```
{
"manifestVersion": 1,
"skipIISReset": true,
"deployments": {
"aspNetCoreWeb": [
{
"name": "my-dotnet-core-app",
"parameters": {
"archive": "dotnet-core-app.zip",
"iisPath": "/"
}
}
]
}
}
```
`deployments` (obligatorio)
*Tipo:* objeto
Contiene las configuraciones de implementación de sus aplicaciones. Este objeto puede tipos de implementación `msDeploy`, `aspNetCoreWeb` y `custom`.
`iisConfig` (opcional)
*Tipo:* objeto
Define las opciones de configuración de IIS que se deben aplicar antes de implementar las aplicaciones. Admite la configuración de sitios web y grupos de aplicaciones.
## Configuraciones de IIS
Esta sección de `iisConfig` le permite configurar los ajustes de IIS antes de implementar las aplicaciones. Esto incluye configurar grupos de aplicaciones con configuraciones específicas y configurar sitios web de IIS con enlaces personalizados.
### Sitios web de IIS
Los sitios web de IIS le permiten configurar ajustes personalizados de sitios web, incluidas las rutas físicas y los enlaces de red, antes de implementar las aplicaciones.
**Consideraciones importantes para la creación de sitios web de IIS diferentes**
*Orden de configuración de los sitios web:* los sitios web se configuran secuencialmente en el orden en que aparecen en la matriz de `websites`. La plataforma procesa la configuración de cada sitio web en secuencia, así que asegúrese de ordenarlos correctamente si tiene dependencias entre sitios web.
*Firewall y acceso a puertos:* solamente el puerto 80 se expone automáticamente a través de la configuración predeterminada del firewall de Windows de Elastic Beanstalk. Si configura los sitios web para que utilicen puertos no estándar, debe definir reglas de firewall personalizadas mediante extensiones electrónicas o scripts de implementación personalizados para permitir el acceso externo a estos puertos.
**Example Configuración de sitios web**
```
{
"iisConfig": {
"websites": [
{
"name": "MyCustomSite",
"physicalPath": "C:\inetpub\wwwroot\mysite",
"bindings": [
{
"protocol": "http",
"port": 8080,
"hostName": "mysite.local"
},
{
"protocol": "https",
"port": 8443
}
]
}
]
}
}
```Propiedades de sitios web
`name` (obligatorio)
*Tipo:* cadena
El nombre del sitio web de IIS. Este nombre se utiliza para identificar el sitio web en el Administrador de IIS y debe ser único en la configuración de IIS.
`physicalPath` (obligatorio)
*Tipo:* cadena
Ruta física en el servidor en el que se almacenan los archivos del sitio web. El proceso de trabajo de IIS debe poder acceder a esta ruta.
`bindings` (obligatorio)
*Tipo*: Array
*Elementos mínimos:* 1
Conjunto de configuraciones de enlace que definen la forma en que el sitio web responde a las solicitudes de la red. Cada enlace especifica un protocolo, un puerto y un nombre de host opcional.
#### Enlaces de sitios web
Los enlaces de sitios web definen los puntos de conexión de la red en los que su sitio web de IIS escuchará las solicitudes entrantes.
`protocol` (obligatorio)
*Tipo:* cadena
*Valores válidos:* «http», «https»
El protocolo utilizado para el enlace.
`port` (obligatorio)
*Tipo*: entero
*Rango válido: 1-65535*
El número de puerto en el que el sitio web escuchará las solicitudes.
`hostName` (opcional)
*Tipo:* cadena
El nombre de host (nombre de dominio) del enlace.
### Grupos de aplicaciones
Los grupos de aplicaciones proporcionan aislamiento entre las aplicaciones y permiten configurar los ajustes de tiempo de ejecución para grupos de aplicaciones.
**Example Configuración de grupos de aplicaciones**
```
{
"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
}
}
]
}
}
```Propiedades de grupos de aplicaciones
`name` (obligatorio)
*Tipo:* cadena
Nombre del grupo de aplicaciones. Este nombre se usa para hacer referencia al grupo en las configuraciones de implementación.
`enable32Bit` (opcional)
*Tipo*: Booleano
Permite que una aplicación de 32 bits se ejecute en una versión de 64 bits de Windows. Se configura en `true` para aplicaciones heredadas que requieren compatibilidad de 32 bits.
`managedPipelineMode` (opcional)
*Tipo:* cadena
*Valores válidos:* «Integrado», «Clásico»
Especifica el modo de procesamiento de solicitudes para el grupo de aplicaciones.
`managedRuntimeVersion` (opcional)
*Tipo:* cadena
*Valores válidos:* «Sin código administrado», «v2.0», «v4.0»
Especifica la versión de .NET Framework a la que apunta la aplicación.
`queueLength` (opcional)
*Tipo*: entero
Número máximo de solicitudes que HTTP.sys pone en cola para el grupo de aplicaciones antes de rechazar solicitudes adicionales.
#### Configuración de la CPU
El objeto `cpu` configura los límites de uso de la CPU y el monitoreo del grupo de aplicaciones.
`limitPercentage` (opcional)
*Tipo*: Número
Porcentaje máximo de tiempo de CPU que pueden consumir los procesos de trabajo del grupo de aplicaciones.
`limitAction` (opcional)
*Tipo:* cadena
*Valores válidos:* "NoAction«, «KillW3WP», «Throttle», "» ThrottleUnderLoad
Acción que se debe realizar cuando se alcanza el límite de la CPU.
`limitMonitoringInterval` (opcional)
*Tipo*: Número
Período de restablecimiento (en minutos) de los límites de monitoreo y limitación de la CPU.
#### Configuración de reciclaje
El objeto `recycling` configura cuándo y cómo se reciclan los procesos de trabajo del grupo de aplicaciones.
`regularTimeInterval` (opcional)
*Tipo*: entero
Intervalo de tiempo (en minutos) tras el cual se recicla el grupo de aplicaciones. Configúrelo en 0 para deshabilitar el reciclaje en función del tiempo.
`requestLimit` (opcional)
*Tipo*: entero
Número máximo de solicitudes que el grupo de aplicaciones procesa antes del reciclaje.
`memory` (opcional)
*Tipo*: entero
Cantidad de memoria virtual (en kilobytes) que activa el reciclaje de los procesos de trabajo.
`privateMemory` (opcional)
*Tipo*: entero
Cantidad de memoria privada (en kilobytes) que activa el reciclaje de los procesos de trabajo.
## Tipos de implementación
El objeto `deployments` contiene matrices de configuraciones de implementación para distintos tipos de aplicaciones. Cada tipo de implementación tiene propiedades y casos de uso específicos.
### MSDeploy despliegues
MSDeploy las implementaciones se utilizan para las aplicaciones tradicionales de.NET Framework que se pueden implementar mediante Web Deploy ()MSDeploy.
**Example MSDeploy configuración de despliegue**
```
{
"deployments": {
"msDeploy": [
{
"name": "WebApp",
"description": "Main web application",
"parameters": {
"appBundle": "webapp.zip",
"iisPath": "/",
"appPool": "DefaultAppPool"
}
}
]
}
}
```MSDeploy propiedades de despliegue
`name` (obligatorio)
*Tipo:* cadena
Nombre único de la implementación. Este nombre debe ser único en todas las implementaciones del manifiesto.
`description` (opcional)
*Tipo:* cadena
Descripción inteligible de la implementación.
`parameters` (obligatorio)
*Tipo:* objeto
Parámetros de configuración de la MSDeploy operación.
`scripts` (opcional)
*Tipo:* objeto
PowerShell scripts que se ejecutarán en diversas etapas del ciclo de vida de la implementación.
#### MSDeploy parámetros
`appBundle` (obligatorio)
*Tipo:* cadena
Ruta al paquete de aplicaciones (archivo ZIP) en relación con el archivo de manifiesto. Este paquete contiene los archivos de la aplicación que se implementarán.
`iisWebSite` (opcional)
*Tipo:* cadena
*Predeterminado:* «Sitio web predeterminado»
El sitio web de IIS en el que se implementará la aplicación. De forma predeterminada, las aplicaciones se implementan en el «sitio web predeterminado». Si lo desea, puede especificar un nombre de sitio web diferente, como uno configurado en la sección `iisConfig.websites`.
`iisPath` (opcional)
*Tipo:* cadena
*Predeterminado:* «/»
Ruta del directorio virtual en IIS donde se implementará la aplicación. Utilice «/» para la ruta raíz o «/api» para un subdirectorio.
`appPool` (opcional)
*Tipo:* cadena
Nombre del grupo de aplicaciones para ejecutar esta aplicación.
### Implementaciones de ASP.NET Core
Las implementaciones de ASP.NET Core están diseñadas específicamente para aplicaciones.NET Core y .NET 5\$1.
**Example Configuración de la implementación de ASP.NET Core**
```
{
"deployments": {
"aspNetCoreWeb": [
{
"name": "CoreAPI",
"description": "ASP.NET Core Web API",
"parameters": {
"appBundle": "coreapi.zip",
"iisPath": "/api",
"appPool": "CoreAppPool"
}
}
]
}
}
```
Las implementaciones de ASP.NET Core utilizan la misma estructura de propiedades que MSDeploy las implementaciones, con la diferencia clave en el entorno de ejecución y el modelo de alojamiento que se utilizan para la aplicación.Parámetros de la implementación de ASP.NET Core
`appBundle` (obligatorio)
*Tipo:* cadena
Ruta al paquete de aplicaciones en relación con el archivo de manifiesto. Puede ser un archivo ZIP o una ruta de directorio que contenga la aplicación ASP.NET Core publicada.
`iisWebSite` (opcional)
*Tipo:* cadena
*Predeterminado:* «Sitio web predeterminado»
El sitio web de IIS en el que se implementará la aplicación ASP.NET Core. De forma predeterminada, las aplicaciones se implementan en el «sitio web predeterminado». Si lo desea, puede especificar un nombre de sitio web diferente, como uno configurado en la sección `iisConfig.websites`.
`iisPath` (opcional)
*Tipo:* cadena
*Predeterminado:* «/»
Ruta del directorio virtual en IIS para la aplicación ASP.NET Core.
`appPool` (opcional)
*Tipo:* cadena
Grupo de aplicaciones para la aplicación ASP.NET Core. El grupo se configurará adecuadamente para el alojamiento de ASP.NET Core.
### implementaciones personalizadas
Las implementaciones personalizadas proporcionan un control total sobre el proceso de implementación mediante PowerShell scripts. Este tipo de implementación es útil para escenarios complejos que requieren una lógica personalizada de instalación, configuración o implementación.
**Example Configuración de implementación personalizada**
```
{
"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
}
}
}
]
}
}
```Propiedades de implementación personalizada
`name` (obligatorio)
*Tipo:* cadena
Nombre único de la implementación personalizada.
`description` (opcional)
*Tipo:* cadena
Descripción de la implementación personalizada.
`architecture` (opcional)
*Tipo*: entero
*Predeterminado: 32*
*Valores válidos:* 32, 64
La especificación de arquitectura para el modo de ejecución de los scripts de PowerShell
`scripts` (obligatorio)
*Tipo:* objeto
PowerShell scripts que definen el comportamiento de despliegue. Las implementaciones personalizadas admiten tipos de scripts adicionales en comparación con otros tipos de implementación.
## Scripts de implementación
Los scripts de despliegue son PowerShell scripts que se ejecutan en momentos específicos del ciclo de vida del despliegue. Los distintos tipos de implementación admiten distintos conjuntos de eventos de script.
### Eventos de script
Los siguientes eventos de script están disponibles en función del tipo de implementación:Scripts de despliegue estándar (MSDeploy y aspNetCore Web)
`preInstall`
Se ejecuta antes de instalar o actualizar la aplicación.
`postInstall`
Se ejecuta después de instalar o actualizar la aplicación.
`preRestart`
Se ejecuta antes de reiniciar la aplicación.
`postRestart`
Se ejecuta después de reiniciar la aplicación.
`preUninstall`
Se ejecuta antes de desinstalar la aplicación.
`postUninstall`
Se ejecuta después de desinstalar la aplicación.Scripts de implementación personalizados (solamente implementaciones personalizadas)
`install`
Script de instalación principal para implementaciones personalizadas. Este script se encarga de instalar la aplicación o el servicio.
`restart`
Script para reiniciar la aplicación o el servicio. Se llama cuando se reinicia el entorno.
`uninstall`
Script para desinstalar la aplicación o el servicio. Se llama durante la finalización del entorno o la eliminación de la aplicación.
### Propiedades de script
Cada script se define como un objeto con las siguientes propiedades:
`file` (obligatorio)
*Tipo:* cadena
Ruta al archivo de PowerShell script en relación con el archivo de manifiesto. El script debe tener una extensión `.ps1`.
`ignoreErrors` (opcional)
*Tipo*: Booleano
*Valor predeterminado:* falso
Si se establece en `true`, la implementación continúa aunque el script falle. Utilícelo para scripts u operaciones de limpieza que no sean críticos.
**Example Ejemplo de configuración de scripts**
```
{
"scripts": {
"preInstall": {
"file": "backup-config.ps1",
"ignoreErrors": true
},
"postInstall": {
"file": "configure-app.ps1"
}
}
}
```
# Uso de EC2 Fast Launch con las ramas de la plataforma Windows
La función EC2 Fast Launch reduce los tiempos de lanzamiento de las instancias de Windows en los entornos de Elastic Beanstalk. El propósito de este tema es guiarlo sobre el uso de esta característica con sus entornos de Elastic Beanstalk. A partir de la versión 2.16.2 de la plataforma Windows, publicada el [22 de enero de 2025,](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2025-01-22-windows.html) las versiones de la plataforma Elastic Beanstalk incluyen la versión básica con Fast Launch activado. AMIs EC2
## Disponibilidad predeterminada de Fast Launch EC2
Las versiones más recientes de la plataforma Windows de Elastic Beanstalk AMIs incluyen la versión EC2 básica con Fast Launch activado automáticamente, sin costes adicionales. Sin embargo, cuando se publiquen versiones de plataforma más recientes, es posible que EC2 Fast Launch no permanezca activado automáticamente en las versiones AMIs de plataforma base anteriores.
Recomendamos actualizar a la última versión de la plataforma Windows para utilizar la versión básica AMIs con EC2 Fast Launch activado automáticamente. Sin embargo, si necesita seguir utilizando la versión de plataforma existente, puede habilitar EC2 Fast Launch manualmente en la AMI base de su entorno. Para obtener instrucciones, consulte [Configuración manual de EC2 Fast Launch](#dotnet-ec2fastlaunch-manual).
## Configuración manual de EC2 Fast Launch
**nota**
La activación manual de EC2 Fast Launch puede suponer costes adicionales en comparación con el uso de versiones de plataforma con EC2 Fast Launch activado automáticamente. Para obtener más información sobre los costes de EC2 Fast Launch, consulta la página [Gestionar los costes de los recursos subyacentes de EC2 Fast Launch](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/win-fast-launch-manage-costs.html) en la *Guía del EC2 usuario de Amazon*.
Siga estos pasos para habilitar EC2 Fast Launch en una AMI base de Windows utilizada en su entorno de Elastic Beanstalk:
**Para habilitar EC2 Fast Launch manualmente en el entorno de Elastic Beanstalk**
1. Identifique la AMI básica de su entorno:
Siga los pasos de [Crear una AMI personalizada](using-features.customenv.md) para identificar el ID de la AMI básica de su entorno. Tenga en cuenta que no necesita crear una AMI personalizada; solamente tiene que seguir los pasos para localizar la ID de su AMI básica actual.
1. Habilite el inicio EC2 rápido en la AMI:
Utilice las instrucciones de [Enable EC2 Fast Launch](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/win-fast-launch-configure.html) de la *Guía del EC2 usuario de Amazon* para configurar EC2 Fast Launch para su AMI.