Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Utilisation de la plateforme Windows Elastic Beanstalk .NET
Cette rubrique explique comment configurer, créer et exécuter vos applications Web ASP.NET et .NET Core pour Windows sur Elastic Beanstalk.
AWS Elastic Beanstalk prend en charge un certain nombre de plateformes pour différentes versions du framework de programmation .NET et de Windows Server. Consultez [.NET sur Windows Server avec IIS](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.net) dans le document *Plateformes AWS Elastic Beanstalk * pour obtenir une liste complète.
Elastic [Beanstalk propose](command-options.md) des options de configuration que vous pouvez utiliser pour personnaliser le logiciel qui s'exécute EC2 sur les instances de votre environnement Elastic Beanstalk. Vous pouvez configurer des variables d'environnement nécessaires pour votre application, activer la rotation des journaux sur Amazon S3 et définir les paramètres de .NET framework.
Des options de configuration sont disponibles dans la console Elastic Beanstalk pour [modifier la configuration d'un environnement en cours d'exécution](environment-configuration-methods-after.md). Pour éviter de perdre la configuration de votre environnement en le résiliant, vous pouvez utiliser des [configurations enregistrées](environment-configuration-savedconfig.md) pour enregistrer vos paramètres et les appliquer par la suite à un autre environnement.
Pour enregistrer les paramètres dans votre code source, vous pouvez inclure des [fichiers de configuration](ebextensions.md). Les paramètres des fichiers de configuration sont appliquées chaque fois que vous créez un environnement ou que vous déployez votre application. Vous pouvez également utiliser des fichiers de configuration pour installer des packages, exécuter des scripts ou effectuer d'autres opérations de personnalisation d'instance lors des déploiements.
Les paramètres appliqués dans la console Elastic Beanstalk remplacent les mêmes paramètres des fichiers de configuration, s'ils existent. Cela vous permet d'utiliser les paramètres par défaut dans les fichiers de configuration et de les remplacer par des paramètres spécifiques à l'environnement dans la console. Pour de plus amples informations sur la priorité et les autres méthodes de modification des paramètres, veuillez consulter [Options de configuration](command-options.md).
## Configuration de votre environnement .NET dans la console Elastic Beanstalk
Vous pouvez utiliser la console Elastic Beanstalk pour activer la rotation des journaux sur Amazon S3, configurer des variables que votre application peut lire depuis l'environnement et modifier les paramètres de .NET Framework.
**Pour configurer votre environnement .NET dans la console Elastic Beanstalk**
1. Ouvrez la console [Elastic Beanstalk](https://console.aws.amazon.com/elasticbeanstalk), puis **dans la liste des régions, sélectionnez votre**. Région AWS
1. Dans le panneau de navigation, choisissez **Environments** (Environnements), puis choisissez le nom de votre environnement dans la liste.
1. Dans le panneau de navigation, choisissez **Configuration**.
1. Dans la catégorie de configuration **Mises à jour, surveillance et journalisation**, sélectionnez **Modifier**.
### Options de conteneur
+ **Cibler l'exécution .NET** – Réglez sur `2.0` pour exécuter CLR v2.
+ **Activer les applications 32 bits** – Réglez sur `True` pour exécuter des applications 32 bits.
### Options du journal
La section Options du journal a deux paramètres :
+ **Instance profile (Profil d'instance)** – Spécifie le profil d'instance qui est autorisé à accéder au compartiment Amazon S3 associé à votre application.
+ **Activer la rotation des fichiers journaux vers Amazon S3** : indique si les fichiers journaux des EC2 instances Amazon de votre application sont copiés dans le compartiment Amazon S3 associé à votre application.
### Propriétés de l'environnement
La section **Propriétés de l'environnement** vous permet de définir les paramètres de configuration de l'environnement sur EC2 les instances Amazon qui exécutent votre application. Ces paramètres sont passés en tant que paires clé-valeur à l'application. Utilisez `System.GetEnvironmentVariable` pour les lire. Des clés identiques peuvent exister dans `web.config` et en tant que propriétés de l'environnement. Utilisez l'espace de noms `System.Configuration` pour lire les valeurs de `web.config`.
```
NameValueCollection appConfig = ConfigurationManager.AppSettings;
string endpoint = appConfig["API_ENDPOINT"];
```
Pour plus d'informations, consultez [Variables d'environnement et autres paramètres du logiciel](environments-cfg-softwaresettings.md).
## Espace de noms aws:elasticbeanstalk:container:dotnet:apppool
Vous pouvez utiliser un [fichier de configuration](ebextensions.md) pour définir des options de configuration et exécuter d'autres tâches de configuration d'instance pendant les déploiements. Les options de configuration peuvent être [spécifiques à la plate-forme](command-options-specific.md) ou s'appliquer à [toutes les plateformes](command-options-general.md) du service Elastic Beanstalk dans son ensemble. Les options de configuration sont organisées en *espaces de noms.*
La plateforme .NET définit les options dans l'espace de noms `aws:elasticbeanstalk:container:dotnet:apppool` que vous pouvez utiliser pour configurer l'environnement d'exécution .NET.
L'exemple de fichier de configuration suivant affiche des paramètres pour chacune des options disponibles dans cet espace de noms :
**Example .ebextensions/dotnet-settings.config**
```
option_settings:
aws:elasticbeanstalk:container:dotnet:apppool:
Target Runtime: 2.0
Enable 32-bit Applications: True
```
Elastic Beanstalk fournit de nombreuses options de configuration pour personnaliser votre environnement. En plus des fichiers de configuration, vous pouvez également définir des options de configuration à l'aide de la console, de configurations enregistrées, de la CLI EB ou d' AWS CLI. Pour plus d'informations, consultez [Options de configuration](command-options.md).
# Migration entre les principales versions de la plateforme Windows Server pour Elastic Beanstalk
AWS Elastic Beanstalk dispose de plusieurs versions majeures de sa plateforme Windows Server. Cette page couvre les améliorations principales de chaque version majeure et les éléments que vous devez prendre en compte avant de migrer vers une version ultérieure.
La plateforme Windows Server est actuellement à la version 2 (v2). Si votre application utilise une version de plateforme Windows Server antérieure à v2, nous vous recommandons de migrer vers v2.
## Nouveautés des versions majeures de la plateforme Windows Server
### Plateforme Windows Server V2
La version 2 (v2) de la plateforme Windows Server pour Elastic Beanstalk a été [publiée en février 2019](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2019-02-21-windows-v2.html). La V2 aligne le comportement de la plateforme Windows Server sur celui des plateformes Linux Elastic Beanstalk pour plusieurs aspects importants. Le V2 est entièrement rétrocompatible avec la V1, ce qui facilite la migration à partir de la V1.
La plateforme Windows Server prend désormais en charge les fonctionnalités suivantes :
+ *Gestion des versions* : chaque version reçoit un nouveau numéro et vous pouvez consulter les versions précédentes (qui sont toujours disponibles) lors de la création et de la gestion des environnements.
+ *État amélioré* – Pour plus de détails, veuillez consulter [Rapports et surveillance de l'état de santé améliorés dans Elastic Beanstalk](health-enhanced.md).
+ Déploiements *immuables* et *propagés avec un lot supplémentaire* – Pour de plus amples informations sur les stratégies de déploiement, veuillez consulter [Déploiement d'applications dans des environnements Elastic Beanstalk](using-features.deploy-existing-version.md).
+ *Mises à jour immuables* – Pour de plus amples informations sur les types de mises à jour, veuillez consulter [Configuration changes](environments-updating.md).
+ *Mises à jour gérées de la plateforme* – Pour de plus amples informations, veuillez consulter [Mises à jour gérées de la plateforme](environment-platform-update-managed.md).
**Note**
Les nouvelles fonctionnalités de déploiement et de mise à jour dépendent des rapports améliorés sur l'état de santé. Activez la fonctionnalité correspondante pour les utiliser. Pour plus d'informations, consultez [Activation des rapports améliorés sur l'état Elastic Beanstalk](health-enhanced-enable.md).
### Plateforme Windows Server V1
La version 1.0.0 (v1) de la plateforme Windows Server pour Elastic Beanstalk a été publiée en octobre 2015. Cette version modifie l'ordre dans lequel Elastic Beanstalk traite les commandes dans les [fichiers de configuration](ebextensions.md) lors de la création et des mises à jour d'un environnement.
Les versions antérieures de la plateforme ne comportent pas de numéro dans le nom de pile de solutions :
+ Windows Server 64 bits 2012 R2 exécutant IIS 8.5
+ Windows Server Core 64 bits 2012 R2 exécutant IIS 8.5
+ Windows Server 64 bits 2012 exécutant IIS 8
+ Windows Server 64 bits 2008 R2 exécutant IIS 7.5
Dans les versions antérieures, l'ordre de traitement des fichiers de configuration n'est pas cohérent. Pendant la création de l'environnement, les commandes `Container Commands` sont exécutées une fois que la source de l'application est déployée dans IIS. Lors d'un déploiement dans un environnement en cours d'exécution, les commandes de conteneur sont exécutées avant le déploiement de la nouvelle version. Lors d'un ajustement à la hausse, les fichiers de configuration ne sont pas traités du tout.
En outre, IIS démarre avant l'exécution des commandes de conteneur. Ce comportement a conduit certains clients à mettre en place des solutions de contournement dans les commandes de conteneur. Elles consistent à mettre en veille le serveur IIS avant l'exécution des commandes et à le redémarrer une fois l'exécution terminée.
La version 1 corrige le problème d'incohérence et aligne le comportement de la plateforme Windows Server sur celui des plateformes Linux Elastic Beanstalk. Sur la plateforme v1, Elastic Beanstalk exécute toujours les commandes de conteneur avant de démarrer le serveur IIS.
Les piles de solutions de la plateforme v1 comportent la mention `v1` après la version de Windows Server :
+ Windows Server 64 bits 2012 R2 v1.1.0 exécutant IIS 8.5
+ Windows Server Core 64 bits 2012 R2 v1.1.0 exécutant IIS 8.5
+ Windows Server 64 bits 2012 v1.1.0 exécutant IIS 8
+ Windows Server 64 bits 2008 R2 v1.1.0 exécutant IIS 7.5
En outre, la plateforme v1 extrait le contenu du bundle de fichiers source de votre application dans `C:\staging\` avant d'exécuter les commandes de conteneur. Une fois que l'exécution des commandes de conteneur est terminée, le contenu de ce dossier est compressé en fichier .zip et déployé dans IIS. Ce processus vous permet de modifier le contenu du bundle source de votre application à l'aide des commandes ou d'un script avant le déploiement.
## Migration à partir de versions majeures antérieures de la plateforme Windows Server
Consultez cette section pour prendre connaissance des considérations relatives à la migration avant de mettre à jour votre environnement. Pour mettre à jour votre plateforme d'environnement vers une version plus récente, consultez [Mise à jour de la version de la plateforme de votre environnement Elastic Beanstalk](using-features.platform.upgrade.md).
### De V1 vers V2
La plateforme Windows Server v2 ne prend pas en charge .NET Core 1.x et 2.0. Si vous migrez votre application à partir de Windows Server v1 vers v2 et que votre application utilise l'une de ces versions .NET Core, mettez à jour votre application vers une version .NET Core prise en charge par la v2. Pour obtenir la liste des versions prises en charge, consultez [.NET sur Windows Server avec IIS](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.net) dans les *Plateformes AWS Elastic Beanstalk *.
Si votre application utilise une Amazon Machine Image (AMI) personnalisée, créez une AMI personnalisée basée sur une AMI de plate-forme Windows Server v2. Pour en savoir plus, consultez la section [Utilisation d'une image machine Amazon (AMI) personnalisée dans votre environnement Elastic Beanstalk](using-features.customenv.md).
**Note**
Les fonctionnalités de déploiement et de mise à jour qui sont nouvelles dans Windows Server v2 dépendent des rapports améliorés sur l'état de santé. Lorsque vous migrez un environnement vers v2, les rapports améliorés sur l'état de santé sont désactivés. Activez-les pour utiliser ces fonctionnalités. Pour plus d'informations, consultez [Activation des rapports améliorés sur l'état Elastic Beanstalk](health-enhanced-enable.md).
### À partir de versions antérieures à la V1
Outre les considérations concernant la migration à partir de la v1, si vous migrez votre application à partir d'une pile de solutions Windows Server antérieure à la v1 et que vous utilisez actuellement des commandes de conteneur, supprimez toutes les commandes que vous avez ajoutées pour contourner les incohérences de traitement lors de la migration vers une version plus récente. Depuis la v1, l'exécution complète des commandes de conteneur est garantie avant l'application source qui est déployée et avant le démarrage d'IIS. Vous pouvez ainsi apporter des modifications à la source dans `C:\staging` et modifier sans problème les fichiers de configuration IIS au cours de cette étape.
Par exemple, vous pouvez utiliser le AWS CLI pour télécharger un fichier DLL vers la source de votre application depuis Amazon S3 :
`.ebextensions\copy-dll.config`
```
container_commands:
copy-dll:
command: aws s3 cp s3://amzn-s3-demo-bucket/dlls/large-dll.dll .\lib\
```
Pour de plus amples informations sur l'utilisation des fichiers de configuration, veuillez consulter [Personnalisation d'environnement avancée avec fichiers de configuration (`.ebextensions`)](ebextensions.md).
# Exécution de plusieurs applications et d'applications ASP.NET Core avec un manifeste de déploiement
Vous pouvez utiliser un manifeste de déploiement pour indiquer à Elastic Beanstalk comment déployer votre application. Avec cette méthode, vous n'avez pas besoin d'utiliser `MSDeploy` pour générer une solution groupée source pour une seule application ASP.NET qui s'exécute sur le chemin d'accès racine de votre site Web. À la place, vous pouvez utiliser un fichier manifeste afin d'exécuter plusieurs applications sur différents chemins. Vous pouvez également demander à Elastic Beanstalk de déployer et d'exécuter l'application avec ASP.NET Core. Vous pouvez également utiliser un manifeste de déploiement pour configurer un groupe d'applications dans lequel exécuter vos applications.
Les manifestes de déploiement ajoutent la prise en charge des [applications .NET Core](#dotnet-manifest-dotnetcore) à Elastic Beanstalk. Vous pouvez déployer une application .NET Framework sans manifeste de déploiement. Toutefois, les applications .NET Core nécessitent un manifeste de déploiement pour s'exécuter sur Elastic Beanstalk. Lors de l'utilisation d'un manifeste de déploiement, vous créez une archive de site pour chaque application, puis regroupez les archives de site dans un second fichier ZIP contenant le manifeste de déploiement.
Les manifestes de déploiement ajoutent également la possibilité d'[exécuter plusieurs applications sur des chemins d'accès différents](#dotnet-manifest-multiapp). Un manifeste de déploiement définit un ensemble de cibles de déploiement, dotées chacune d'une archive de site et d'un chemin d'accès sur lequel elle doit être exécutée par IIS. Par exemple, vous pouvez exécuter une API web sur le chemin d'accès `/api` pour répondre aux demandes asynchrones, et une application web sur le chemin d'accès racine qui utilise l'API.
Vous pouvez utiliser un manifeste de déploiement pour [configurer les sites Web IIS avec des liaisons personnalisées et des chemins physiques](#dotnet-manifest-websites). Cela vous permet de configurer des sites Web qui écoutent sur des ports ou des noms d'hôtes spécifiques avant de déployer vos applications.
Vous pouvez également utiliser un manifeste de déploiement pour [exécuter plusieurs applications à l'aide de groupes d'applications dans IIS ou Kestrel](#dotnet-manifest-apppool). Vous pouvez configurer un pool d'applications pour redémarrer périodiquement vos applications, exécuter des applications 32 bits ou utiliser une version spécifique du runtime .NET Framework.
Pour une personnalisation complète, vous pouvez [écrire vos propres scripts de déploiement](#dotnet-manifest-custom) sous Windows PowerShell et indiquer à Elastic Beanstalk les scripts à exécuter pour installer, désinstaller et redémarrer votre application.
Les manifestes de déploiement et les fonctionnalités associées requièrent une plateforme Windows Server [version 1.2.0 ou ultérieure](dotnet-v2migration.md).
Pour obtenir des informations détaillées sur toutes les options de configuration, les propriétés et les fonctionnalités avancées disponibles, telles que le fait d'ignorer les réinitialisations IIS, consultez la référence du [schéma du manifeste de déploiement](dotnet-manifest-schema.md).
**Topics**
+ [Applications .NET core](#dotnet-manifest-dotnetcore)
+ [Exécution de plusieurs applications](#dotnet-manifest-multiapp)
+ [Configuration des sites Web IIS](#dotnet-manifest-websites)
+ [Utilisation du routage des demandes d'application (ARR)](#dotnet-manifest-arr)
+ [Configuration de groupes d'applications](#dotnet-manifest-apppool)
+ [Définition de déploiements personnalisés](#dotnet-manifest-custom)
+ [Référence du schéma du manifeste de déploiement](dotnet-manifest-schema.md)
## Applications .NET core
Vous pouvez utiliser un manifeste de déploiement pour exécuter des applications .NET Core sur Elastic Beanstalk. .NET Core est une version multiplateforme de .NET qui inclut un outil de ligne de commande (`dotnet`). Vous pouvez l'utiliser pour générer une application, l'exécuter localement et la préparer en vue de sa publication.
Pour exécuter une application .NET Core sur Elastic Beanstalk, vous pouvez exécuter `dotnet publish` et placer la sortie dans une archive ZIP, en excluant les répertoires contenant des fichiers. Placez l'archive de site dans un bundle de fichiers source avec un manifeste de déploiement, avec une cible de déploiement de type `aspNetCoreWeb`.
Le manifeste de déploiement suivant exécute une application .NET Core à partir d'une archive de site nommée `dotnet-core-app.zip` sur le chemin d'accès racine.
**Example aws-windows-deployment-manifest.json - .NET core**
```
{
"manifestVersion": 1,
"deployments": {
"aspNetCoreWeb": [
{
"name": "my-dotnet-core-app",
"parameters": {
"archive": "dotnet-core-app.zip",
"iisPath": "/"
}
}
]
}
}
```
Regroupez le manifeste et l'archive de site dans un fichier ZIP pour créer un bundle de fichiers source.
**Example dotnet-core-bundle.zip**
```
.
|-- aws-windows-deployment-manifest.json
`-- dotnet-core-app.zip
```
L'archive de site contient le code d'application compilé, les dépendances et le fichier `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
```
## Exécution de plusieurs applications
Vous pouvez exécuter plusieurs applications à l'aide d'un manifeste de déploiement en définissant plusieurs cibles de déploiement.
Le manifeste de déploiement suivant configure deux applications .NET Core. L'`WebApiSampleApp`application implémente une API Web simple et envoie des requêtes asynchrones sur le `/api` chemin. L'application `DotNetSampleApp` est une application Web qui sert les demandes à la racine du chemin d'accès.
**Example aws-windows-deployment-manifest.json - plusieurs applications**
```
{
"manifestVersion": 1,
"deployments": {
"aspNetCoreWeb": [
{
"name": "WebAPISample",
"parameters": {
"appBundle": "WebApiSampleApp.zip",
"iisPath": "/api"
}
},
{
"name": "DotNetSample",
"parameters": {
"appBundle": "DotNetSampleApp.zip",
"iisPath": "/"
}
}
]
}
}
```
Un exemple d'application avec plusieurs applications est disponible ici :
+ **Ensemble de sources déployable** [- -v2.zip dotnet-multiapp-sample-bundle](samples/dotnet-multiapp-sample-bundle-v2.zip)
+ **Code source** : [dotnet-multiapp-sample-source-v2.zip](samples/dotnet-multiapp-sample-source-v2.zip)
## Configuration des sites Web IIS
Vous pouvez configurer les sites Web IIS avec des liaisons personnalisées et des chemins physiques à l'aide du manifeste de déploiement. Cela est utile lorsque vous devez configurer des sites Web qui écoutent sur des ports spécifiques, utilisent des noms d'hôtes personnalisés ou diffusent du contenu provenant de répertoires spécifiques.
Le manifeste de déploiement suivant configure un site Web IIS personnalisé qui écoute sur HTTP avec un numéro de port spécifique et un chemin physique personnalisé :
**Example aws-windows-deployment-manifest.json - Configuration du site Web 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": "/"
}
}
]
}
}
```
Dans cet exemple :
+ Un site Web nommé MyCustomSite « » est créé avec un chemin physique personnalisé
+ Le site Web possède une liaison HTTP sur le port 8080 avec un nom d'hôte spécifique
+ L'application ASP.NET Core est déployée sur ce site Web personnalisé à l'aide du paramètre `iisWebSite`
## Utilisation du routage des demandes d'application (ARR)
Les modules Application Request Routing (ARR) et URL Rewrite sont préinstallés et disponibles dans Elastic Beanstalk Windows. AMIs Ces modules permettent des scénarios de routage avancés et la manipulation d'URL via la configuration IIS à l'aide d'extensions Web ou de la configuration d'applications.
L'exemple suivant montre un manifeste de déploiement simple qui configure un site Web avec un port personnalisé, combiné à une configuration ebextensions qui définit le routage ARR de base :
**Example aws-windows-deployment-manifest.json - Configuration ARR simple**
```
{
"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 configuration ARR se fait par le biais d'ebextensions. La configuration suivante définit les règles de routage ARR de base :
**Example .ebextensions/arr-config.config - Configuration ARR de base**
```
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
```
Cette configuration crée un site Web sur le port 8080 et configure ARR pour acheminer toutes les demandes entrantes vers l'application principale exécutée sur ce site.
## Configuration de groupes d'applications
Vous pouvez prendre en charge plusieurs applications dans votre environnement Windows. Vous avez le choix entre deux approches :
+ Vous pouvez utiliser le modèle out-of-process d'hébergement avec le serveur Web Kestrel. Avec ce modèle, vous configurez plusieurs applications pour qu'elles s'exécutent dans un groupe d'applications.
+ Vous pouvez utiliser le modèle d'hébergement en cours, avec lequel vous utilisez plusieurs groupes d'applications pour exécuter plusieurs applications avec une seule application dans chaque groupe. Si vous utilisez le serveur IIS et que vous avez besoin d'exécuter plusieurs applications, vous devez utiliser cette approche.
Pour configurer Kestrel de façon à exécuter plusieurs applications dans un groupe d'applications, ajoutez `hostingModel="OutofProcess"` dans le fichier `web.config`. Considérez les exemples suivants.
**Example web.config - pour le modèle d'hébergement Kestrel out-of-process**
```
```
**Example aws-windows-deployment-manifest.json - applications multiples**
```
{
"manifestVersion": 1,
"deployments": {"msDeploy": [
{"name": "Web-app1",
"parameters": {"archive": "site1.zip",
"iisPath": "/"
}
},
{"name": "Web-app2",
"parameters": {"archive": "site2.zip",
"iisPath": "/app2"
}
}
]
}
}
```
IIS ne prend pas en charge plusieurs applications dans un groupe d'applications car il utilise le modèle d'hébergement en cours. Par conséquent, vous devez configurer plusieurs applications en affectant chaque application à un groupe d'applications. En d'autres termes, n'affectez qu'une seule application à un groupe d'applications.
Vous pouvez configurer IIS pour qu'il utilise différents groupes d'applications dans le fichier `aws-windows-deployment-manifest.json`. Effectuez les mises à jour suivantes lorsque vous vous référez au fichier exemple suivant :
+ Ajoutez une section `iisConfig` qui comprend une sous-section appelée `appPools`.
+ Dans le bloc `appPools`, répertoriez les groupes d'applications.
+ Dans la section `deployments`, définissez une section `parameters` pour chaque application.
+ Pour chaque application, la section `parameters` spécifie une archive, un chemin d'accès pour l'exécuter et un `appPool` dans lequel s'exécuter.
Le manifeste de déploiement suivant configure deux groupes d'applications qui redémarrent leur application toutes les 10 minutes. En outre, ils attachent leurs applications à une application Web .NET Framework qui s'exécute au chemin spécifié.
**Example aws-windows-deployment-manifest.json : une application par pool d'applications**
```
{
"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"
}
}
]
}
}
```
## Définition de déploiements personnalisés
Pour encore davantage de contrôle, vous pouvez personnaliser entièrement un déploiement d'applications en définissant un *déploiement personnalisé*.
Ce manifeste de déploiement indique à Elastic Beanstalk PowerShell d'exécuter des scripts en mode 32 bits. Il spécifie trois scripts : un `install` script (`siteInstall.ps1`) qui s'exécute lors du lancement et des déploiements de l'instance, un `uninstall` script (`siteUninstall.ps1`) qui s'exécute avant d'installer de nouvelles versions pendant les déploiements et un `restart` script (`siteRestart.ps1`) qui s'exécute lorsque vous sélectionnez [Redémarrer le serveur d'applications](environments-dashboard-actions.md) dans la AWS console de gestion.
**Example aws-windows-deployment-manifest.json - déploiement personnalisé**
```
{
"manifestVersion": 1,
"deployments": {
"custom": [
{
"name": "Custom site",
"architecture" : 32,
"scripts": {
"install": {
"file": "siteInstall.ps1"
},
"restart": {
"file": "siteRestart.ps1"
},
"uninstall": {
"file": "siteUninstall.ps1"
}
}
}
]
}
}
```
Incluez les artefacts requis pour exécuter l'application dans le bundle de fichiers source avec le manifeste et les scripts.
**Example ustom-site-bundleC.zip**
```
.
|-- aws-windows-deployment-manifest.json
|-- siteInstall.ps1
|-- siteRestart.ps1
|-- siteUninstall.ps1
`-- site-contents.zip
```
# Référence du schéma du manifeste de déploiement
Le manifeste de déploiement est un fichier JSON qui définit la manière dont Elastic Beanstalk doit déployer et configurer vos applications Windows. Cette section fournit une référence complète pour toutes les propriétés et options de configuration prises en charge dans le schéma du manifeste.
## Structure du manifeste
Le manifeste de déploiement suit un schéma JSON spécifique avec la structure de haut niveau suivante :
**Example Structure de base du manifeste**
```
{
"manifestVersion": 1,
"skipIISReset": false,
"iisConfig": {
"websites": [...],
"appPools": [...]
},
"deployments": {
"msDeploy": [...],
"aspNetCoreWeb": [...],
"custom": [...]
}
}
```
### Propriétés de haut niveau
`manifestVersion` (obligatoire)
*Type* : nombre
*Par défaut* : 1
*Valeurs valides :* 1
Spécifie la version du schéma du manifeste. Actuellement, seule la version 1 est prise en charge.
`skipIISReset` (facultatif)
*Type* : valeur booléenne
*Par défaut :* faux
Contrôle si IIS est réinitialisé lors des déploiements d'applications. Cet indicateur affecte à la fois les types de `aspNetCoreWeb` déploiement `msDeploy` et les types de déploiement.
*Comportement :*
+ *Non spécifié ou `false` (par défaut) :* les réinitialisations IIS sont effectuées lors des opérations d'installation, de désinstallation et de mise à jour. C'est le comportement traditionnel.
+ *`true`:* les réinitialisations IIS sont ignorées lors des opérations de déploiement.
*Avantages :*
+ *Réduction des temps d'arrêt* : les applications subissent des interruptions de service plus courtes pendant les déploiements.
+ *Déploiements plus rapides* : élimine le temps nécessaire au redémarrage et à la réinitialisation complets d'IIS.
Lors de l'utilisation`skipIISReset`, l'[RestartAppServer](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/API_RestartAppServer.html)opération effectue une réinitialisation IIS quel que soit ce paramètre d'indicateur.
*Exemple :*
```
{
"manifestVersion": 1,
"skipIISReset": true,
"deployments": {
"aspNetCoreWeb": [
{
"name": "my-dotnet-core-app",
"parameters": {
"archive": "dotnet-core-app.zip",
"iisPath": "/"
}
}
]
}
}
```
`deployments` (obligatoire)
*Type :* objet
Contient les configurations de déploiement pour vos applications. Cet objet peut inclure `msDeploy``aspNetCoreWeb`, et des types de `custom` déploiement.
`iisConfig` (facultatif)
*Type :* objet
Définit les paramètres de configuration IIS à appliquer avant de déployer des applications. Prend en charge la configuration du site Web et du pool d'applications.
## Configuration d'IIS
Cette `iisConfig` section vous permet de configurer les paramètres IIS avant de déployer vos applications. Cela inclut la configuration de pools d'applications avec des configurations spécifiques et la configuration de sites Web IIS avec des liaisons personnalisées.
### Sites Web IIS
Les sites Web IIS vous permettent de configurer des paramètres de site Web personnalisés, notamment des chemins physiques et des liaisons réseau, avant de déployer vos applications.
**Considérations importantes relatives à la création de différents sites Web IIS**
*Ordre de configuration des sites Web :* les sites Web sont configurés séquentiellement dans l'ordre dans lequel ils apparaissent dans le `websites` tableau. La plateforme traite la configuration de chaque site Web dans l'ordre. Veillez donc à ce que l'ordre soit correct si vous avez des dépendances entre les sites Web.
*Pare-feu et accès aux ports :* seul le port 80 est automatiquement exposé via la configuration par défaut du pare-feu Windows Elastic Beanstalk. Si vous configurez des sites Web pour utiliser des ports non standard, vous devez définir des règles de pare-feu personnalisées par le biais d'ebextensions ou de scripts de déploiement personnalisés pour autoriser l'accès externe à ces ports.
**Example Configuration du site Web**
```
{
"iisConfig": {
"websites": [
{
"name": "MyCustomSite",
"physicalPath": "C:\inetpub\wwwroot\mysite",
"bindings": [
{
"protocol": "http",
"port": 8080,
"hostName": "mysite.local"
},
{
"protocol": "https",
"port": 8443
}
]
}
]
}
}
```Propriétés du site Web
`name` (obligatoire)
*Type* : chaîne
Nom du site Web IIS. Ce nom est utilisé pour identifier le site Web dans le Gestionnaire des services Internet et doit être unique dans la configuration IIS.
`physicalPath` (obligatoire)
*Type* : chaîne
Le chemin physique sur le serveur où les fichiers du site Web sont stockés. Ce chemin doit être accessible au processus de travail IIS.
`bindings` (obligatoire)
*Type* : tableau
*Nombre minimum d'articles :* 1
Ensemble de configurations de liaison qui définissent la manière dont le site Web répond aux demandes du réseau. Chaque liaison spécifie un protocole, un port et un nom d'hôte facultatif.
#### Liaisons du site Web
Les liaisons de sites Web définissent les points de terminaison du réseau sur lesquels votre site Web IIS écoutera les demandes entrantes.
`protocol` (obligatoire)
*Type* : chaîne
*Valeurs valides :* « http », « https »
Protocole utilisé pour la liaison.
`port` (obligatoire)
*Type* : entier
*Plage valide : 1-65535*
Numéro de port sur lequel le site Web écoutera les demandes.
`hostName` (facultatif)
*Type* : chaîne
Le nom d'hôte (nom de domaine) pour la liaison.
### Pools d'applications
Les pools d'applications isolent les applications et vous permettent de configurer les paramètres d'exécution pour des groupes d'applications.
**Example Configuration du pool d'applications**
```
{
"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
}
}
]
}
}
```Propriétés du pool d'applications
`name` (obligatoire)
*Type* : chaîne
Nom du pool d'applications. Ce nom est utilisé pour faire référence au pool dans les configurations de déploiement.
`enable32Bit` (facultatif)
*Type* : valeur booléenne
Permet à une application 32 bits de s'exécuter sur une version 64 bits de Windows. Définissez cette option `true` pour les applications existantes qui nécessitent une compatibilité 32 bits.
`managedPipelineMode` (facultatif)
*Type* : chaîne
*Valeurs valides :* « Intégré », « Classique »
Spécifie le mode de traitement des demandes pour le pool d'applications.
`managedRuntimeVersion` (facultatif)
*Type* : chaîne
*Valeurs valides :* « Aucun code géré », « v2.0 », « v4.0 »
Spécifie la version du .NET Framework pour le pool d'applications.
`queueLength` (facultatif)
*Type* : entier
Nombre maximal de demandes que HTTP.sys met en file d'attente pour le pool d'applications avant de rejeter les demandes supplémentaires.
#### Configuration du processeur
L'`cpu`objet configure les limites d'utilisation du processeur et la surveillance du pool d'applications.
`limitPercentage` (facultatif)
*Type* : nombre
Pourcentage maximal de temps processeur que les processus de travail peuvent consommer dans le pool d'applications.
`limitAction` (facultatif)
*Type* : chaîne
*Valeurs valides :* "NoAction«, « KillW3WP », « Throttle », "» ThrottleUnderLoad
Action à entreprendre lorsque la limite du processeur est atteinte.
`limitMonitoringInterval` (facultatif)
*Type* : nombre
Période de réinitialisation (en minutes) pour la surveillance du processeur et les limites de régulation.
#### Configuration du recyclage
L'`recycling`objet configure quand et comment les processus de travail du pool d'applications sont recyclés.
`regularTimeInterval` (facultatif)
*Type* : entier
Intervalle de temps (en minutes) après lequel le pool d'applications recycle. Réglez sur 0 pour désactiver le recyclage basé sur le temps.
`requestLimit` (facultatif)
*Type* : entier
Nombre maximal de demandes traitées par le pool d'applications avant le recyclage.
`memory` (facultatif)
*Type* : entier
Quantité de mémoire virtuelle (en kilo-octets) qui déclenche le recyclage des processus de travail.
`privateMemory` (facultatif)
*Type* : entier
Quantité de mémoire privée (en kilo-octets) qui déclenche le recyclage des processus de travail.
## Types de déploiement
L'`deployments`objet contient des tableaux de configurations de déploiement pour différents types d'applications. Chaque type de déploiement possède des propriétés et des cas d'utilisation spécifiques.
### MSDeploy déploiements
MSDeploy les déploiements sont utilisés pour les applications .NET Framework traditionnelles qui peuvent être déployées à l'aide de Web Deploy (MSDeploy).
**Example MSDeploy configuration de déploiement**
```
{
"deployments": {
"msDeploy": [
{
"name": "WebApp",
"description": "Main web application",
"parameters": {
"appBundle": "webapp.zip",
"iisPath": "/",
"appPool": "DefaultAppPool"
}
}
]
}
}
```MSDeploy propriétés de déploiement
`name` (obligatoire)
*Type* : chaîne
Nom unique pour le déploiement. Ce nom doit être unique pour tous les déploiements du manifeste.
`description` (facultatif)
*Type* : chaîne
Description lisible par l'homme du déploiement.
`parameters` (obligatoire)
*Type :* objet
Paramètres de configuration de l' MSDeploy opération.
`scripts` (facultatif)
*Type :* objet
PowerShell scripts à exécuter à différentes étapes du cycle de vie du déploiement.
#### MSDeploy paramètres
`appBundle` (obligatoire)
*Type* : chaîne
Chemin d'accès au bundle d'applications (fichier ZIP) relatif au fichier manifeste. Ce bundle contient les fichiers d'application à déployer.
`iisWebSite` (facultatif)
*Type* : chaîne
*Par défaut :* « Site Web par défaut »
Le site Web IIS sur lequel déployer l'application. Par défaut, les applications sont déployées sur le « site Web par défaut ». Vous pouvez éventuellement spécifier un autre nom de site Web, tel que celui configuré dans la `iisConfig.websites` section.
`iisPath` (facultatif)
*Type* : chaîne
*Par défaut :* «/»
Chemin du répertoire virtuel dans IIS où l'application sera déployée. Utilisez «/» pour le chemin racine ou « /api » pour un sous-répertoire.
`appPool` (facultatif)
*Type* : chaîne
Nom du pool d'applications pour exécuter cette application.
### Déploiements ASP.NET Core
Les déploiements ASP.NET Core sont spécialement conçus pour les applications .NET Core et .NET 5\$1.
**Example Configuration du déploiement d'ASP.NET Core**
```
{
"deployments": {
"aspNetCoreWeb": [
{
"name": "CoreAPI",
"description": "ASP.NET Core Web API",
"parameters": {
"appBundle": "coreapi.zip",
"iisPath": "/api",
"appPool": "CoreAppPool"
}
}
]
}
}
```
Les déploiements ASP.NET Core utilisent la même structure de propriétés que MSDeploy les déploiements, la principale différence étant l'environnement d'exécution et le modèle d'hébergement utilisés pour l'application.Paramètres de déploiement d'ASP.NET Core
`appBundle` (obligatoire)
*Type* : chaîne
Chemin d'accès au bundle d'applications relatif au fichier manifeste. Il peut s'agir d'une archive ZIP ou d'un chemin de répertoire contenant l'application ASP.NET Core publiée.
`iisWebSite` (facultatif)
*Type* : chaîne
*Par défaut :* « Site Web par défaut »
Le site Web IIS sur lequel déployer l'application ASP.NET Core. Par défaut, les applications sont déployées sur le « site Web par défaut ». Vous pouvez éventuellement spécifier un autre nom de site Web, tel que celui configuré dans la `iisConfig.websites` section.
`iisPath` (facultatif)
*Type* : chaîne
*Par défaut :* «/»
Chemin du répertoire virtuel dans IIS pour l'application ASP.NET Core.
`appPool` (facultatif)
*Type* : chaîne
Pool d'applications pour l'application ASP.NET Core. Le pool sera configuré de manière appropriée pour l'hébergement ASP.NET Core.
### Déploiements personnalisés
Les déploiements personnalisés permettent de contrôler totalement le processus de déploiement par le biais de PowerShell scripts. Ce type de déploiement est utile pour les scénarios complexes qui nécessitent une installation, une configuration ou une logique de déploiement personnalisées.
**Example Configuration de déploiement personnalisée**
```
{
"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
}
}
}
]
}
}
```Propriétés de déploiement personnalisées
`name` (obligatoire)
*Type* : chaîne
Nom unique pour le déploiement personnalisé.
`description` (facultatif)
*Type* : chaîne
Description du déploiement personnalisé.
`architecture` (facultatif)
*Type* : entier
*Par défaut :* 32
*Valeurs valides :* 32, 64
La spécification d'architecture pour le mode d'exécution des scripts PowerShell
`scripts` (obligatoire)
*Type :* objet
PowerShell des scripts qui définissent le comportement de déploiement. Les déploiements personnalisés prennent en charge des types de scripts supplémentaires par rapport aux autres types de déploiement.
## Scripts de déploiement
Les scripts de déploiement sont PowerShell des scripts qui s'exécutent à des moments spécifiques du cycle de vie du déploiement. Les différents types de déploiement prennent en charge différents ensembles d'événements de script.
### Événements liés au script
Les événements de script suivants sont disponibles en fonction du type de déploiement :Scripts de déploiement standard (MSDeploy et aspNetCore Web)
`preInstall`
S'exécute avant l'installation ou la mise à jour de l'application.
`postInstall`
S'exécute après l'installation ou la mise à jour de l'application.
`preRestart`
S'exécute avant le redémarrage de l'application.
`postRestart`
S'exécute après le redémarrage de l'application.
`preUninstall`
S'exécute avant la désinstallation de l'application.
`postUninstall`
S'exécute après la désinstallation de l'application.Scripts de déploiement personnalisés (déploiements personnalisés uniquement)
`install`
Script d'installation principal pour les déploiements personnalisés. Ce script est responsable de l'installation de l'application ou du service.
`restart`
Script pour redémarrer l'application ou le service. Appelé au redémarrage de l'environnement.
`uninstall`
Script permettant de désinstaller l'application ou le service. Appelé lors de la fermeture de l'environnement ou de la suppression d'une application.
### Propriétés du script
Chaque script est défini comme un objet doté des propriétés suivantes :
`file` (obligatoire)
*Type* : chaîne
Chemin d'accès au fichier de PowerShell script relatif au fichier manifeste. Le script doit avoir une `.ps1` extension.
`ignoreErrors` (facultatif)
*Type* : valeur booléenne
*Par défaut :* faux
Lorsque ce paramètre est défini sur`true`, le déploiement se poursuit même si le script échoue. Utilisez-le pour des scripts ou des opérations de nettoyage non critiques.
**Example Exemple de configuration de script**
```
{
"scripts": {
"preInstall": {
"file": "backup-config.ps1",
"ignoreErrors": true
},
"postInstall": {
"file": "configure-app.ps1"
}
}
}
```
# Utilisation de EC2 Fast Launch avec les branches de la plate-forme Windows
La fonctionnalité EC2 Fast Launch réduit les temps de lancement des instances Windows dans vos environnements Elastic Beanstalk. L'objectif de cette rubrique est de vous expliquer comment utiliser cette fonctionnalité dans vos environnements Elastic Beanstalk. À partir de la version 2.16.2 de la plateforme Windows, publiée le [22 janvier 2025,](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2025-01-22-windows.html) les versions de la plateforme Elastic Beanstalk incluent la version de base avec Fast Launch activé. AMIs EC2
## Disponibilité du lancement EC2 rapide par défaut
Les dernières versions de la plateforme Windows Elastic Beanstalk AMIs incluent la version de EC2 base avec Fast Launch automatiquement activé, sans frais supplémentaires. Toutefois, lorsque de nouvelles versions de plate-forme sont publiées, EC2 Fast Launch peut ne pas rester automatiquement activé sur la base AMIs des anciennes versions de plate-forme.
Nous vous recommandons de passer à la dernière version de la plateforme Windows pour utiliser la base AMIs avec EC2 Fast Launch automatiquement activé. Toutefois, si vous devez continuer à utiliser la version de votre plateforme existante, vous pouvez activer manuellement EC2 Fast Launch sur l'AMI de base de votre environnement. Pour obtenir des instructions, veuillez consulter [Configuration manuelle de EC2 Fast Launch](#dotnet-ec2fastlaunch-manual).
## Configuration manuelle de EC2 Fast Launch
**Note**
L'activation manuelle de EC2 Fast Launch peut entraîner des coûts supplémentaires par rapport à l'utilisation de versions de plateforme avec EC2 Fast Launch automatiquement activé. Pour plus d'informations sur les coûts de EC2 Fast Launch, consultez [la page des ressources sous-jacentes de EC2 Fast Launch](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/win-fast-launch-manage-costs.html) dans le *guide de EC2 l'utilisateur Amazon*.
Procédez comme suit pour activer EC2 Fast Launch sur une AMI de base Windows utilisée par votre environnement Elastic Beanstalk :
**Pour activer manuellement EC2 Fast Launch pour votre environnement Elastic Beanstalk**
1. Identifiez l'AMI de base de votre environnement :
Suivez les étapes décrites dans [Création d'une AMI personnalisée](using-features.customenv.md) pour identifier l'ID d'AMI de base de votre environnement. Notez qu'il n'est pas nécessaire de créer une AMI personnalisée, il vous suffit de suivre les étapes pour localiser votre ID d'AMI de base actuel.
1. Activez le lancement EC2 rapide sur l'AMI :
Suivez les instructions de la [section Activer le lancement EC2 rapide](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/win-fast-launch-configure.html) du *guide de EC2 l'utilisateur Amazon* pour configurer EC2 Fast Launch pour votre AMI.