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.
# Migration des applications IIS vers Elastic Beanstalk
AWS Elastic Beanstalk fournit un chemin de migration rationalisé pour vos applications Windows exécutées sur Internet Information Services (IIS). La fonctionnalité de migration décrite dans ce chapitre réduit considérablement le temps et la complexité généralement associés aux migrations vers le cloud, en vous aidant à maintenir les fonctionnalités des applications et l'intégrité de la configuration pendant la transition vers AWS.
**L'**eb migrate**opération**
Utilisez la **eb migrate** commande dans l'interface de ligne de commande Elastic Beanstalk (EB CLI) pour découvrir, empaqueter et déployer automatiquement vos applications IIS sur le. AWS Cloud Le processus préserve les fonctionnalités de l'application et préserve vos configurations, notamment les liaisons, les pools d'applications et les paramètres d'authentification.
Les étapes suivantes résument le processus effectué par l'`eb migrate`opération pour faire passer votre application vers AWS Cloud :
1. Découvrez les sites IIS et leurs configurations.
1. Package du contenu et de la configuration de l'application.
1. Créez l'environnement et l'application Elastic Beanstalk.
1. Déployez l'application avec des paramètres préservés.
**Options d'exécution du flux de travail et de l'emplacement**
La **eb migrate** commande fournit des options pour des flux de travail de migration et des emplacements d'exécution flexibles. Par défaut, exécutez la commande sur le serveur cible qui contient l'application que vous souhaitez migrer vers Elastic Beanstalk. Si vous ne pouvez pas exécuter de commandes directement sur le serveur d'applications, utilisez l'`remote`option permettant d'exécuter la commande depuis un hôte bastion qui se connecte au serveur cible contenant votre application et vos configurations. Pour effectuer la migration en deux étapes, vous pouvez également générer le package de migration sans le déployer à l'aide de l'`archive-only`option, puis le déployer ultérieurement à votre convenance en utilisant l'`archive`option.
Pour des informations de référence sur la **eb migrate** commande, consultez[**eb migrate**](eb3-migrate.md).
**Rubriques**
Les rubriques suivantes fournissent des informations détaillées sur la migration des applications IIS vers Elastic Beanstalk :
+ [Conditions préalables](dotnet-migrating-applications-prerequisites.md)- Découvrez les logiciels, les accès et les autorisations nécessaires pour migrer vos applications Windows vers AWS Elastic Beanstalk des environnements.
+ [Glossaire des migrations](dotnet-migrating-applications-glossary.md)- Découvrez comment les composants IIS sont mappés aux ressources Elastic Beanstalk
+ [Comprendre le mappage de migration entre IIS et Elastic Beanstalk](dotnet-migrating-applications-mapping.md)- Découvrez comment les composants IIS sont mappés aux ressources Elastic Beanstalk
+ [Réalisation de migrations IIS de base](dotnet-migrating-applications-basic-migration.md)- Apprenez à effectuer des migrations de base
+ [Scénarios de migration avancés](dotnet-migrating-applications-advanced-scenarios.md)- Gérez des scénarios de migration complexes
+ [Configurations de sécurité et rôles IAM](dotnet-migrating-applications-security.md)- Configurer les paramètres de sécurité lors de la migration
+ [Configuration réseau et paramètres des ports](dotnet-migrating-applications-network.md)- Gérez les configurations du réseau et des ports
+ [Dépannage et diagnostic](dotnet-migrating-applications-troubleshooting.md)- Résoudre les problèmes de migration courants
+ [Comparaison des options de migration : EB CLI et AWS Application Migration Service](dotnet-migrating-applications-comparison.md)- Comparez deux options de migration principales.
# Conditions préalables
Avant d'utiliser la **eb migrate** commande, assurez-vous que votre environnement répond aux exigences suivantes :
**Installation et version d'IIS**
Le serveur à partir duquel vous effectuez la migration doit exécuter Internet Information Services (IIS) version 7.0 ou ultérieure. IIS 10.0 sur Windows Server 2016 ou version ultérieure fournit l'environnement le plus compatible pour la migration.
Pour vérifier votre version d'IIS, exécutez la commande suivante :
```
PS C:\migrations_workspace> Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\InetStp\"
...
SetupString : IIS 10.0
VersionString : Version 10.0
...
```
**Configuration requise pour Windows Server**
Votre environnement source doit exécuter Windows Server 2016 ou version ultérieure pour une compatibilité optimale. Elastic Beanstalk prend en charge les versions de Windows Server suivantes en tant que plateformes cibles :
+ Windows Server 2025
+ Windows Server 2022
+ Windows Server 2019
+ Windows Server 2016
**Installation de la CLI EB**
+ *Flux de travail par défaut (sans `--remote` option)* :
+ Python et l'interface de ligne de commande Elastic Beanstalk (EB CLI) doivent être installés sur le serveur qui contient l'application que vous souhaitez migrer vers Elastic Beanstalk. Bien que cela ne soit pas obligatoire, nous vous recommandons d'installer l'interface de ligne de commande EB dans un `virtualenv` bac à sable, comme décrit dans[Installation de l'interface de ligne de commande EB dans un environnement virtuel](eb-cli3.md#eb-cli3-install-virtualenv).
+ *En utilisant l'`--remote`option* :
+ Python et l'interface de ligne de commande Elastic Beanstalk (EB CLI) doivent être installés sur votre hôte bastion. Bien que cela ne soit pas obligatoire, nous vous recommandons d'installer l'interface de ligne de commande EB dans un `virtualenv` bac à sable, comme décrit dans[Installation de l'interface de ligne de commande EB dans un environnement virtuel](eb-cli3.md#eb-cli3-install-virtualenv).
Autorisations ** nécessaires **
Vous avez besoin des informations d'identification et autorisations suivantes :
+ Privilèges d'administrateur sur le serveur IIS source ou sur l'hôte Bastion (si vous utilisez l'`--remote`option).
+ AWS informations d'identification avec autorisations pour créer et gérer les ressources Elastic Beanstalk
**Déploiement Web 3.6**
L'outil Microsoft Web Deploy (version 3.6 ou ultérieure) doit être installé sur votre serveur source ou sur l'hôte Bastion (si vous utilisez `--remote` cette option). Cet outil est utilisé **eb migrate** pour empaqueter vos applications.
Pour vérifier l'installation, exécutez la commande suivante :
:
```
PS C:\migrations_workspace> Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\IIS Extensions\MSDeploy\3" -Name InstallPath
InstallPath : C:\Program Files\IIS\Microsoft Web Deploy V3\
...
```
Pour les instructions d'installation, consultez la section [Installation et configuration de Web Deploy sur IIS 8.0 ou version ultérieure](https://learn.microsoft.com/en-us/iis/install/installing-publishing-technologies/installing-and-configuring-web-deploy-on-iis-80-or-later) sur le site Web de documentation du produit Microsoft Windows.
**Exigences relatives au réseau**
+ *Flux de travail par défaut (sans `--remote` option)* :
+ Votre serveur source doit disposer d'un accès Internet sortant aux AWS services.
+ *En utilisant l'`--remote`option* :
+ Votre serveur source doit disposer d'un accès Internet sortant aux AWS services.
+ Configurez les règles d'entrée des groupes de sécurité appropriées qui autorisent une connexion réseau sortante depuis votre hôte Bastion et une connexion entrante vers la machine distante. Assurez-vous que l'adresse IP de l'hôte bastion est autorisée via TCP sur le port 22 pour accéder à la machine distante.
+ Assurez-vous que votre client SSH est installé et fonctionne sur votre machine distante ainsi que sur votre hôte Bastion.
+ Assurez-vous que la configuration de votre pare-feu contient les règles appropriées qui ouvrent le port 22 ou autorisent la connexion au client.
+ Testez votre connexion en utilisant manuellement une connexion SSH sur l'hôte distant depuis l'hôte bastion avant de tenter la migration.
# Glossaire des migrations
Ce glossaire fournit les définitions des termes et concepts clés liés à IIS, à Elastic Beanstalk et à la migration des applications IIS vers Elastic Beanstalk.
## Termes relatifs à Windows, IIS et .NET
****IIS****
Internet Information Services, un logiciel de serveur Web développé par Microsoft pour une utilisation avec Windows Server. IIS héberge des sites Web, des applications Web et des services Web, fournissant ainsi une plate-forme pour exécuter ASP.NET et d'autres technologies Web. Lors de la migration vers Elastic Beanstalk, les sites IIS et leurs configurations sont empaquetés et déployés sur des instances Windows Server dans le cloud. AWS
Les versions 7.0 et ultérieures d'IIS sont prises en charge pour la migration, IIS 10.0 sur Windows Server 2016 ou version ultérieure fournissant l'environnement le plus compatible.
****Framework .NET****
Plate-forme de développement logiciel développée par Microsoft pour créer et exécuter des applications Windows. Il fournit une vaste bibliothèque de classes appelée Framework Class Library (FCL) et prend en charge l'interopérabilité des langages entre plusieurs langages de programmation.
Lors de la migration vers Elastic Beanstalk, les applications créées sur le .NET Framework continuent de s'exécuter sur la même version du framework dans l'environnement cloud. Elastic Beanstalk prend en charge plusieurs versions de .NET Framework (4.x) sur ses plateformes Windows Server.
****.NET Core****
Successeur open source multiplateforme du .NET Framework, conçu pour être plus modulaire et léger. .NET Core (désormais simplement appelé .NET 5 et versions ultérieures) permet aux développeurs de créer des applications qui s'exécutent sous Windows, Linux et macOS.
Lorsque vous migrez des applications basées sur .NET Core vers Elastic Beanstalk, vous pouvez choisir entre des plateformes Windows Server ou des plateformes basées sur Linux, en fonction des exigences et des dépendances de votre application.
****Common Language Runtime (CLR)****
Composant de machine virtuelle du .NET Framework qui gère l'exécution des programmes .NET. Le CLR fournit des services tels que la gestion de la mémoire, la sécurité des types, la gestion des exceptions, la collecte des déchets et la gestion des threads.
Lors de la migration vers Elastic Beanstalk, la version CLR appropriée est automatiquement disponible sur la plate-forme Windows Server que vous sélectionnez, garantissant ainsi la compatibilité avec les exigences de votre application.
****Site****
Conteneur logique dans IIS qui représente une application ou un service Web, identifié par une liaison unique d'adresse IP, de port et d'en-tête d'hôte. Chaque site IIS possède son propre pool d'applications, ses propres liaisons et paramètres de configuration, et peut contenir une ou plusieurs applications.
****Application****
Regroupement de fichiers de contenu et de code au sein d'un site IIS qui gère les demandes relatives à un espace URL spécifique. Les applications dans IIS peuvent avoir leurs propres paramètres de configuration, qui sont généralement stockés dans `web.config` des fichiers.
Lors de la migration vers Elastic Beanstalk, les applications sont préservées avec leur structure de chemin et leurs paramètres de configuration. Le processus de migration garantit que les applications imbriquées conservent leur hiérarchie et leurs chemins d'URL dans l'environnement cloud.
****ApplicationPool****
Fonctionnalité IIS qui isole les applications Web pour améliorer la sécurité, la fiabilité et la gestion des performances. Les pools d'applications définissent l'environnement d'exécution des applications, notamment la version du .NET Framework, le mode pipeline et les paramètres d'identité.
****VirtualDirectory****
Un mappage de répertoires dans IIS qui permet de diffuser du contenu à partir d'un emplacement situé en dehors du répertoire racine du site. Les annuaires virtuels vous permettent d'organiser le contenu sur différents emplacements physiques tout en présentant une structure d'URL unifiée aux utilisateurs.
Lors de la migration vers Elastic Beanstalk, les répertoires virtuels sont conservés avec leurs mappages de chemins. La **eb migrate** commande crée la structure de répertoire et les configurations nécessaires dans l'environnement cloud pour conserver les mêmes chemins d'URL.
****ARR****
Application Request Routing, une extension IIS qui fournit des fonctionnalités d'équilibrage de charge et de proxy pour les serveurs Web. L'ARR permet le routage basé sur les URL, le transfert de requêtes HTTP et la répartition de la charge sur plusieurs serveurs.
Lors de la migration vers Elastic Beanstalk, les configurations ARR sont préservées grâce à l'installation de fonctionnalités ARR sur les instances EC2 et à la configuration de règles de routage appropriées. Pour les scénarios de routage complexes, le processus de migration peut également tirer parti des règles Application Load Balancer pour implémenter des fonctionnalités similaires.
****Réécriture d'URL****
Module IIS qui modifie les demandes en URLs fonction de règles définies avant qu'elles n'atteignent l'application Web. La réécriture d'URL permet la manipulation d'URL, la redirection et la diffusion de contenu en fonction de modèles et de conditions.
Lors de la migration vers Elastic Beanstalk, les règles de réécriture d'URL de vos fichiers sont traduites en règles `web.config` de routage ALB dans la mesure du possible, ou conservées dans la configuration IIS sur les instances EC2. Cela garantit que les modèles d'URL et les redirections continuent de fonctionner comme prévu dans l'environnement cloud.
****msdeploy.exe****
Outil de ligne de commande utilisé pour déployer des applications Web et des sites Web sur des serveurs IIS. Également connu sous le nom de Web Deploy, il permet d'empaqueter, de synchroniser et de déployer des applications Web, des sites Web et des configurations de serveur.
La **eb migrate** commande utilise Web Deploy (version 3.6 ou ultérieure) pour empaqueter vos applications lors de la migration vers Elastic Beanstalk. Cet outil doit être installé sur votre serveur source pour que le processus de migration fonctionne correctement.
****Trajectoire physique****
Emplacement réel du système de fichiers où sont stockés les fichiers de contenu d'un site ou d'une application IIS. Les chemins physiques peuvent pointer vers des répertoires locaux, des partages réseau ou d'autres emplacements de stockage accessibles au serveur IIS.
Lors de la migration vers Elastic Beanstalk, les chemins physiques sont mappés vers les emplacements appropriés sur les instances EC2 de votre environnement. Le processus de migration préserve la structure du contenu tout en garantissant que tous les fichiers sont correctement déployés dans l'environnement cloud.
****Hôte de l'application. Config****
Le fichier de configuration racine pour IIS qui définit les paramètres à l'échelle du serveur et contient la configuration de tous les sites, applications et répertoires virtuels. Ce fichier se trouve dans le `%windir%\System32\inetsrv\config` répertoire et contrôle le comportement général du serveur IIS.
Lors de la migration vers Elastic Beanstalk, les `applicationHost.config` paramètres pertinents sont extraits et appliqués à la configuration IIS sur les instances EC2 de votre environnement. Cela garantit que les paramètres à l'échelle du serveur sont préservés pendant la migration.
****web.config****
Fichier de configuration XML utilisé dans les applications ASP.NET pour contrôler les paramètres, la sécurité et le comportement des applications au niveau de l'application ou du répertoire. `web.config`les fichiers peuvent contenir des paramètres d'authentification, d'autorisation, d'état de session, de compilation et de paramètres d'application personnalisés.
Pendant la migration vers Elastic `web.config` Beanstalk, les fichiers sont conservés et déployés avec votre application. Le processus de migration garantit que les configurations spécifiques aux applications continuent de fonctionner comme prévu dans l'environnement cloud.
****DefaultDocument****
Fonctionnalité IIS qui indique le fichier par défaut à servir lorsqu'un utilisateur demande un répertoire sans spécifier de nom de fichier. Les documents par défaut sont activés par défaut, et IIS 7 définit les fichiers de documents par défaut suivants dans le `applicationHost.config` fichier comme fichiers par défaut à l'échelle du serveur : Default.htm, Default.asp, Index.htm, Index.html, Iisstart.htm.
Lors de la migration vers Elastic Beanstalk, les paramètres de document par défaut sont conservés dans la configuration IIS sur les instances EC2, ce qui garantit que les demandes d'annuaire sont traitées de manière cohérente dans l'environnement cloud.
****System.WebServer****
Section de configuration figurant dans `web.config` ou `applicationHost.config` contenant des paramètres spécifiques à l'IIS pour les modules, les gestionnaires et les autres comportements du serveur. Cette section contrôle la manière dont IIS traite les demandes, gère les modules et configure les fonctionnalités du serveur.
Lors de la migration vers Elastic Beanstalk, les configurations System.WebServer sont conservées dans les fichiers de votre `web.config` application et appliquées à l'installation IIS sur les instances EC2 de votre environnement. Cela garantit que les comportements spécifiques à IIS sont maintenus dans l'environnement cloud.
## Termes relatifs à Elastic Beanstalk
****Plateforme****
Combinaison de composants du système d'exploitation, du langage de programmation, du serveur Web, du serveur d'applications et d'Elastic Beanstalk qui définit la pile logicielle pour exécuter des applications.
Pour les migrations vers Windows, Elastic Beanstalk fournit des plateformes basées sur Windows Server 2016, 2019 et 2022 avec IIS et différentes versions de .NET Framework afin de garantir la compatibilité avec votre environnement source.
****SolutionStack****
Configuration de plate-forme prédéfinie dans Elastic Beanstalk qui spécifie le système d'exploitation, le moteur d'exécution et les autres composants nécessaires pour exécuter une application. Conceptuellement identique à une plate-forme et utilisé de manière interchangeable pour faire fonctionner des environnements.
Au cours de la migration, la **eb migrate** commande sélectionne une pile de solutions appropriée en fonction de la configuration de votre environnement source, garantissant ainsi la compatibilité avec vos applications IIS.
****CreateEnvironment****
Action d'API Elastic Beanstalk qui crée un nouvel environnement pour héberger une version d'application. Cette API est utilisée par la **eb migrate** commande pour fournir les AWS ressources nécessaires à votre application migrée.
Le processus de migration configure les paramètres d'environnement appropriés en fonction de votre environnement IIS source, notamment le type d'instance, les variables d'environnement et les paramètres des options.
****CreateApplicationVersion****
Action d'API Elastic Beanstalk qui crée une nouvelle version d'application à partir d'un bundle source stocké dans Amazon S3. La **eb migrate** commande utilise cette API pour enregistrer votre application IIS packagée en tant que version dans Elastic Beanstalk.
Pendant la migration, les fichiers et la configuration de votre application sont empaquetés, téléchargés sur Amazon S3 et enregistrés en tant que version de l'application avant le déploiement.
****DescribeEvents****
Action d'API Elastic Beanstalk qui extrait une liste d'événements relatifs à un environnement, notamment les déploiements, les modifications de configuration et les problèmes opérationnels. La **eb migrate** commande utilise cette API pour suivre la progression de votre migration.
Vous pouvez également utiliser la **eb events** commande après la migration pour consulter l'historique des événements de votre environnement.
****DescribeEnvironmentHealth****
Action d'API Elastic Beanstalk qui fournit des informations détaillées sur l'état des instances et des autres composants d'un environnement. Cette API est utilisée pour vérifier l'état de votre application migrée après le déploiement.
Après la migration, vous pouvez utiliser la **eb health** commande pour vérifier l'état de votre environnement et identifier les problèmes nécessitant une attention particulière.
****Santé D****
Agent de surveillance dans Elastic Beanstalk qui collecte des métriques, surveille les journaux et indique l'état de santé des instances EC2 dans un environnement. HealthD fournit des rapports de santé améliorés pour vos applications migrées.
Après la migration, HealthD surveille les performances de votre application, l'utilisation des ressources et les taux de réussite des demandes, fournissant ainsi une vue complète de l'état de votre environnement.
****Journaux du bundle****
Fonctionnalité d'Elastic Beanstalk qui compresse et télécharge les journaux des instances EC2 vers Amazon S3 pour un stockage et une analyse centralisés. Cette fonctionnalité vous aide à résoudre les problèmes liés à vos applications migrées.
Après la migration, vous pouvez utiliser la **eb logs** commande pour récupérer et consulter les journaux de votre environnement.
****aws-windows-deployment-manifest.json****
Fichier qui décrit le contenu, les dépendances et la configuration d'un progiciel ou d'une application. Ce manifeste est généré pendant le processus de migration pour définir la manière dont vos applications IIS doivent être déployées sur Elastic Beanstalk.
****section de manifeste personnalisée****
Une section fournit `aws-windows-deployment-manifest.json` un contrôle personnalisé sur le déploiement des applications. Cette section contient des PowerShell scripts et des commandes exécutés au cours du processus de déploiement.
Pendant la migration, des sections de manifeste personnalisées sont générées pour gérer des aspects spécifiques de votre configuration IIS, tels que la configuration du répertoire virtuel, la gestion des autorisations et la configuration du pool d'applications.
****INTERFACE DE LIGNE DE COMMANDE EB****
Outil de ligne de commande qui fournit des commandes pour créer, configurer et gérer les applications et les environnements Elastic Beanstalk. L'EB CLI inclut la **eb migrate** commande spécifiquement destinée à la migration des applications IIS vers Elastic Beanstalk.
Après la migration, vous pouvez continuer à utiliser l'interface de ligne de commande EB pour gérer votre environnement, déployer des mises à jour, surveiller l'état de santé et effectuer d'autres tâches administratives.
****Réglages des options****
Des valeurs de configuration qui définissent la manière dont Elastic Beanstalk approvisionne AWS et configure les ressources de votre environnement. Les paramètres des options sont organisés en espaces de noms qui représentent les différents composants de votre environnement, tels que les équilibreurs de charge, les instances et les processus environnementaux.
Pendant la migration, la **eb migrate** commande génère les paramètres d'options appropriés en fonction de votre configuration IIS afin de garantir que votre environnement cloud correspond aux capacités de votre environnement source. Pour plus d'informations, consultez la section [Options de configuration](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-options-general.html) du manuel Elastic Beanstalk Developer Guide.
****aws:elbv2:listener:default****
Un espace de noms de configuration Elastic Beanstalk pour l'écouteur par défaut sur un Application Load Balancer. Pendant la migration, cet espace de noms est configuré en fonction de vos liaisons de site IIS afin de garantir le bon routage du trafic.
L'écouteur par défaut gère généralement le trafic HTTP sur le port 80, qui est ensuite transféré aux instances de votre application conformément aux règles de routage.
****aws:elbv2:listener:listener\$1port****
Un espace de noms de configuration Elastic Beanstalk pour un port d'écouteur spécifique sur un Application Load Balancer. Cet espace de noms est utilisé pour configurer des écouteurs supplémentaires pour vos applications migrées, tels que le protocole HTTPS sur le port 443.
Pendant la migration, les écouteurs sont créés en fonction des liaisons de ports de vos sites IIS, ce qui garantit que vos applications restent accessibles sur les mêmes ports que dans votre environnement source.
****aws:elbv2:listenerrule:rule\$1name****
Un espace de noms de configuration Elastic Beanstalk permettant de définir des règles de routage pour un écouteur Application Load Balancer. Ces règles déterminent la manière dont les demandes entrantes sont acheminées vers les différents groupes cibles en fonction des modèles de chemin ou des en-têtes d'hôte.
Au cours de la migration, des règles d'écoute sont créées pour correspondre à la structure d'URL de vos applications IIS, afin de garantir que les demandes sont acheminées vers les chemins d'application appropriés.
****aws:elasticbeanstalk:environnement:process:default****
Un espace de noms de configuration Elastic Beanstalk pour le processus par défaut dans un environnement. Cet espace de noms définit la manière dont le processus d'application Web par défaut est configuré, y compris les paramètres de vérification de l'état, les mappages de ports et les paramètres de proxy.
Pendant la migration, le processus par défaut est configuré en fonction des paramètres de votre site IIS principal, afin de garantir une surveillance de l'état et une gestion des demandes appropriées.
****aws:elasticbeanstalk:environnement:process:process\$1name****
Un espace de noms de configuration Elastic Beanstalk pour un processus nommé spécifique dans un environnement. Cet espace de noms vous permet de définir plusieurs processus avec différentes configurations, comme si vous disposiez de plusieurs pools d'applications dans IIS.
Au cours de la migration, des processus supplémentaires peuvent être créés pour représenter différentes liaisons de site par rapport à votre environnement source.
**Note**
Pour plus d'informations sur certains termes décrits dans cette rubrique, consultez les ressources suivantes :
[Actions de l'API Elastic Beanstalk - Référence des API AWS Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/)
*Plateformes Elastic Beanstalk, y compris les [versions prises en charge -](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html) Plateformes prises en charge dans le guide des plateformes AWS Elastic Beanstalk *
Espaces de noms de configuration d'Elastic Beanstalk : dans ce guide [Options générales pour tous les environnements](command-options-general.md)
L'EB CLI ou les commandes spécifiques de l'EB CLI - [Configuration de l'interface de ligne de commande EB (EB CLI) pour gérer Elastic Beanstalk](eb-cli3.md) dans ce guide
## Termes de Python
****pip****
Le programme d'installation de packages pour Python, utilisé pour installer et gérer des packages logiciels écrits en Python. La CLI EB est installée et mise à jour à l'aide de pip.
Au cours du processus de migration, pip est utilisé pour installer le package EB CLI et ses dépendances sur votre serveur source, fournissant ainsi les outils nécessaires à la migration.
****PyPI****
Python Package Index, le référentiel officiel des packages logiciels Python tiers, à partir duquel pip récupère et installe les packages. L'EB CLI et ses dépendances sont hébergées sur PyPI.
Lors de l'installation de l'EB CLI pour la migration, pip se connecte à PyPI pour télécharger et installer les packages nécessaires.
****virtualenv****
Un outil pour créer des environnements Python isolés, permettant à différents projets d'avoir leurs propres dépendances et packages sans conflits. L'utilisation de virtualenv est recommandée lors de l'installation de la CLI EB afin d'éviter les conflits avec d'autres applications Python.
La création d'un environnement virtuel avant l'installation de l'interface de ligne de commande EB garantit que les outils de migration disposent d'un environnement propre et isolé avec les dépendances appropriées.
****pywin33****
Ensemble d'extensions Python qui donnent accès à de nombreux systèmes Windows APIs, permettant ainsi une interaction avec le système d'exploitation Windows et ses composants. L'EB CLI utilise pywin32 pour interagir avec les fonctionnalités spécifiques à Windows lors de la migration.
Au cours du processus de migration, pywin32 est utilisé pour accéder à la configuration IIS, aux paramètres du registre Windows et à d'autres informations système nécessaires pour empaqueter et migrer correctement vos applications.
****pythonnet****
Package qui permet au code Python d'interagir avec les applications .NET Framework et .NET Core. Cette intégration permet à l'EB CLI de fonctionner avec les composants .NET pendant le processus de migration.
Le processus de migration peut utiliser pythonnet pour interagir avec les assemblages et les composants .NET lors de l'analyse et du packaging de vos applications en vue de leur déploiement sur Elastic Beanstalk.
# Réalisation de migrations IIS de base
Cette section vous guide tout au long du processus de migration de vos applications IIS vers Elastic **eb migrate** Beanstalk à l'aide de la commande.
## Exploration de votre environnement IIS
Avant d'apporter des modifications, vous devez connaître les ressources présentes sur votre serveur. Commencez par explorer vos sites IIS en exécutant**eb migrate explore**, comme illustré dans l'exemple suivant :
```
PS C:\migrations_workspace> eb migrate explore
```
Cette commande affiche vos sites IIS. Reportez-vous à la liste suivante :
```
Default Web Site
Intranet
API.Internal
Reports
```
Pour une vue détaillée de la configuration de chaque site, y compris les liaisons, les applications et les répertoires virtuels, ajoutez l'`--verbose`option, comme indiqué dans cet exemple :
```
PS C:\migrations_workspace> eb migrate explore --verbose
```
La liste suivante présente les informations complètes sur votre environnement fournies par la commande :
```
1: Default Web Site:
- Bindings:
- *:80:www.example.com
- *:443:www.example.com
- Application '/':
- Application Pool: DefaultAppPool
- Enabled Protocols: http
- Virtual Directories:
- /:
- Physical Path: C:\inetpub\wwwroot
- Logon Method: ClearText
- Application '/api':
- Application Pool: ApiPool
- Enabled Protocols: http
- Virtual Directories:
- /:
- Physical Path: C:\websites\api
- Logon Method: ClearText
2: Intranet:
...
3. API.Internal:
...
4. Reports:
...
```
### Comprendre le résultat de la découverte
La sortie détaillée fournit les informations essentielles suivantes pour la planification de la migration :
Sites
Le résultat de découverte répertorie tous les sites IIS de votre serveur. Chaque site est identifié par son nom (par exemple, « Site Web par défaut », « Intranet », « API.Internal ») et numéroté de manière séquentielle. Lorsque plusieurs sites existent sur un serveur, la `eb migrate` commande peut empaqueter et déployer chacun d'eux séparément ou ensemble, en fonction de votre stratégie de migration.
Reliures
Les liaisons de protocole révèlent les protocoles (HTTP/HTTPS) utilisés par vos sites et les ports sur lesquels ils fonctionnent. Les informations de liaison incluent les exigences d'en-tête de l'hôte qui définissent les configurations de routage basées sur le domaine.
Applications
Les chemins d'application indiquent à la fois les structures d'application racine et imbriquées au sein de votre configuration IIS. Les attributions de pool d'applications indiquent comment vos applications sont isolées les unes des autres pour la gestion de la sécurité et des ressources.
Répertoires virtuels
Les mappages de chemins physiques indiquent l'emplacement de votre contenu dans le système de fichiers. Les paramètres d'authentification indiquent des exigences d'accès spéciales qui doivent être maintenues après la migration.
## Préparation de la migration
Grâce à une bonne connaissance de votre environnement, assurez-vous que votre serveur répond aux prérequis. Vérifiez d'abord votre version d'IIS à l'aide de la PowerShell commande suivante :
```
PS C:\migrations_workspace> Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\InetStp\" -Name MajorVersion
```
Vous avez besoin d'IIS 7.0 ou version ultérieure. L'outil de migration utilise Web Deploy 3.6 pour empaqueter vos applications. Vérifiez son installation à l'aide de la commande suivante :
```
PS C:\migrations_workspace> Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\IIS Extensions\MSDeploy\3" -Name InstallPath
```
Si Web Deploy n'est pas installé sur votre serveur, vous pouvez le télécharger depuis la page de téléchargement de [Microsoft Web Platform Installer](https://www.iis.net/downloads/microsoft/web-deploy).
## Votre première migration
Commençons par une migration de base du site Web par défaut. L'exemple suivant montre la commande la plus simple,**eb migrate**.
```
PS C:\migrations_workspace> eb migrate
```
Cette commande lance une série d'étapes automatisées, illustrées dans l'exemple de sortie suivant :
```
Identifying VPC configuration of this EC2 instance (i-0123456789abcdef0)
id: vpc-1234567890abcdef0
publicip: true
elbscheme: public
ec2subnets: subnet-123,subnet-456,subnet-789
securitygroups: sg-123,sg-456
elbsubnets: subnet-123,subnet-456,subnet-789
Using .\migrations\latest to contain artifacts for this migration run.
Generating source bundle for sites, applications, and virtual directories...
Default Web Site/ -> .\migrations\latest\upload_target\DefaultWebSite.zip
```
L'outil de migration crée un répertoire structuré contenant vos artefacts de déploiement. La liste suivante montre la structure du répertoire :
```
C:\migration_workspace\
└── .\migrations\latest\
└── upload_target\
├── DefaultWebSite.zip
├── aws-windows-deployment-manifest.json
└── ebmigrateScripts\
├── site_installer.ps1
├── permission_handler.ps1
└── >other helper scripts<
```
## Contrôle de la migration
Pour mieux contrôler le processus de migration, vous pouvez spécifier exactement les sites à migrer à l'aide de la commande suivante :
```
PS C:\migrations_workspace> eb migrate --sites "Default Web Site,Intranet"
```
Vous pouvez également personnaliser le nom de l'environnement et le nom de l'application, comme indiqué dans l'exemple de commande suivant :
```
PS C:\migrations_workspace> eb migrate `
--sites "Default Web Site" `
--application-name "CorporateApp" `
--environment-name "Production"
```
Pour une liste complète des options, voir[**eb migrate**](eb3-migrate.md).
## Surveillance de la progression
Pendant la migration, **eb migrate** fournit des mises à jour de statut en temps réel. Reportez-vous à l'exemple de sortie suivant :
```
...
Creating application version
Creating environment... This may take a few minutes
2024-03-18 18:12:15 INFO Environment details for: Production
Application name: CorporateApp
Region: us-west-2
Deployed Version: app-230320_153045
Environment ID: e-abcdef1234
Platform: 64bit Windows Server 2019 v2.7.0 running IIS 10.0
Tier: WebServer-Standard-1.0
CNAME: production.us-west-2.elasticbeanstalk.com
Updated: 2024-03-20 15:30:45
2025-03-18 18:12:17 INFO createEnvironment is starting.
2025-03-18 18:12:19 INFO Using elasticbeanstalk-us-east-1-180301529717 as Amazon S3 storage bucket for environment data.
2025-03-18 18:12:40 INFO Created security group named: sg-0fdd4d696a26b086a
2025-03-18 18:12:48 INFO Environment health has transitioned to Pending. Initialization in progress (running for 7 seconds). There are no instances.
...
2025-03-18 18:23:59 INFO Application available at EBMigratedEnv-arrreal3.us-east-1.elasticbeanstalk.com.
2025-03-18 18:24:00 INFO Successfully launched environment: EBMigratedEnv-arrreal3
```
## Vérification de la migration
Une fois l'environnement prêt, Elastic Beanstalk propose plusieurs méthodes pour vérifier votre déploiement.
Accédez à votre application
Ouvrez l'URL de votre application (CNAME) dans un navigateur Web pour vérifier qu'elle fonctionne correctement.
Vérifiez la santé de l'environnement
Utilisez la **eb health** commande pour vérifier l'état de votre environnement.
```
PS C:\migrations_workspace> eb health
```
L'image d'écran suivante montre l'état de santé de l'instance, les mesures de réponse des applications et l'utilisation des ressources système.
![\[Le résultat de la commande Web Health indique l'état de l'instance, les mesures de réponse des applications et l'utilisation des ressources du système.\]](http://docs.aws.amazon.com/fr_fr/elasticbeanstalk/latest/dg/images/eb-health-after-migration.png)
Utilisez la **eb logs** commande pour accéder aux journaux afin de résoudre les problèmes éventuels :
```
PS C:\migrations_workspace> eb logs --zip
```
La **eb logs** commande télécharge les journaux `.elasticbeanstalk/logs` dans le répertoire. Pour de plus amples informations, veuillez consulter [Utilisation d'Elastic CloudWatch Beanstalk avec Amazon Logs](AWSHowTo.cloudwatchlogs.md).
Connect aux instances
Si vous avez spécifié une paire de clés lors de la migration, vous pouvez vous connecter à vos instances à l'aide du protocole RDP pour un dépannage direct.
Accédez à la console Elastic Beanstalk
Vous pouvez consulter l'état, les journaux et les propriétés de configuration de l'[environnement via la console de gestion](environments-console.md) de l'environnement correspondant.
## Gestion des artefacts de migration
La **eb migrate** commande crée des artefacts locaux pendant le processus de migration. Ces artefacts contiennent des informations sensibles et peuvent consommer beaucoup d'espace disque au fil du temps. Utilisez la **cleanup** sous-commande pour gérer ces artefacts, comme indiqué dans l'exemple suivant :
```
PS C:\migrations_workspace> eb migrate cleanup
Are you sure you would like to cleanup older artifacts within ./migrations/? (Y/N):
```
Pour forcer le nettoyage sans confirmation, utilisez l'**--force**option suivante :
```
PS C:\migrations_workspace> eb migrate cleanup --force
```
Le processus de nettoyage préserve la migration réussie la plus récente dans le `./migrations/latest` répertoire et supprime les anciens répertoires de migration
# Configuration réseau et paramètres des ports
Cette section décrit les options de configuration réseau pour les migrations IIS, notamment les paramètres VPC, les configurations de port et les déploiements multisites.
## Configuration VPC
La **eb migrate** commande fournit des options de configuration VPC flexibles pour votre environnement Elastic Beanstalk. L'outil peut soit détecter les paramètres VPC à partir d'une instance EC2 source, soit accepter des configurations VPC personnalisées via des paramètres de ligne de commande. Passez [Utilisation d'Elastic Beanstalk avec Amazon VPC](vpc.md) en revue pour comprendre comment configurer Elastic Beanstalk avec VPC.
### Détection automatique des VPC
Lorsqu'il est **eb migrate** exécuté sur une instance EC2, il découvre et utilise automatiquement la configuration VPC des instances EC2 de l'environnement source. L'exemple de sortie suivant illustre les informations de configuration détectées :
```
PS C:\migrations_workspace > eb migrate
Identifying VPC configuration of this EC2 instance (i-0123456789abcdef0):
id: vpc-1234567890abcdef0
publicip: true
elbscheme: public
ec2subnets: subnet-123,subnet-456,subnet-789
securitygroups: sg-123,sg-456
elbsubnets: subnet-123,subnet-456,subnet-789
...
```
La configuration détectée inclut :
+ Identifiant VPC
+ Paramètres d'attribution d'adresses IP publiques
+ Schéma d'équilibrage de charge (public/privé)
+ Attributions de sous-réseaux d'instances EC2
+ Associations de groupes de sécurité
+ Attributions de sous-réseaux d'équilibreur de charge
### Hôtes sur site ou hors AWS cloud
Lorsqu'il est **eb migrate** exécuté à partir d'un serveur sur site ou d'un hôte non AWS cloud, le service Elastic Beanstalk utilise le VPC par défaut de votre compte. AWS La liste suivante présente un exemple de commande et de sortie :
```
PS C:\migrations_worspace> eb migrate `
-k windows-test-pem `
--region us-east-1 `
-a EBMigratedEnv `
-e EBMigratedEnv-test2 `
--copy-firewall-config
Determining EB platform based on host machine properties
Using .\migrations\latest to contain artifacts for this migration run.
...
```
Passez [Utilisation d'Elastic Beanstalk avec Amazon VPC](vpc.md) en revue pour comprendre comment Elastic Beanstalk configure le VPC par défaut pour votre environnement.
### Configuration VPC personnalisée
Pour tout environnement source (EC2, sur site ou hors AWS cloud) dans lequel vous avez besoin de paramètres VPC spécifiques, fournissez un fichier de configuration VPC tel que celui présenté dans l'exemple suivant :
```
{
"id": "vpc-12345678",
"publicip": "true",
"elbscheme": "public",
"ec2subnets": ["subnet-a1b2c3d4", "subnet-e5f6g7h8"],
"securitygroups": "sg-123456,sg-789012",
"elbsubnets": ["subnet-a1b2c3d4", "subnet-e5f6g7h8"]
}
```
Appliquez cette configuration à l'aide de la commande suivante :
```
PS C:\migrations_workspace> eb migrate --vpc-config vpc-config.json
```
**Note**
Le fichier de configuration du VPC nécessite le `id` champ qui spécifie l'ID du VPC. Tous les autres champs sont facultatifs, et Elastic Beanstalk utilisera des valeurs par défaut pour tous les champs que vous ne spécifiez pas.
**Important**
*La migration ignorera tous les paramètres VPC existants de l'environnement source lorsque vous spécifiez le `--vpc-config`* *paramètre.* Lorsque vous utilisez ce paramètre, la migration utilise uniquement les paramètres VPC spécifiés dans le fichier de configuration que vous transmettez. L'utilisation de ce paramètre remplace le comportement par défaut qui consiste à découvrir la configuration VPC de l'instance source ou à utiliser le VPC par défaut.
Utilisez le `--vpc-config` paramètre dans les scénarios suivants :
+ Lorsque vous migrez des environnements non EC2 qui ne possèdent pas de paramètres VPC détectables
+ Lorsque vous migrez vers un VPC différent de celui utilisé par l'environnement source
+ Lorsque vous devez personnaliser les sélections de sous-réseaux ou les configurations de groupes de sécurité
+ Lorsque la découverte automatique n'identifie pas correctement les paramètres VPC souhaités
+ Lorsque vous effectuez une migration depuis un environnement local et que vous ne souhaitez pas utiliser le VPC par défaut
### Configuration de la sécurité du réseau
Par défaut, **eb migrate** ouvre le port 80 sur les instances cibles mais ne copie pas les autres règles du pare-feu Windows depuis la machine source. Pour inclure toutes les configurations de pare-feu, utilisez la commande suivante :
```
PS C:\migrations_workspace> eb migrate --copy-firewall-config
```
Cette commande effectue les actions suivantes :
+ Identifie les ports utilisés par les liaisons de sites IIS
+ Récupère les règles de pare-feu correspondantes
+ Génère PowerShell des scripts pour recréer des règles sur les instances cibles
+ Préserve toutes les règles DENY pour le port 80 depuis la machine source (sinon le port 80 est autorisé par défaut)
Prenons un cas d'utilisation où votre machine source possède les règles de pare-feu spécifiées dans l'exemple suivant :
```
# Source machine firewall configuration
Get-NetFirewallRule | Where-Object {$_.Enabled -eq 'True'} | Get-NetFirewallPortFilter | Where-Object {$_.LocalPort -eq 80 -or $_.LocalPort -eq 443 -or $_.LocalPort -eq 8081}
# Output shows rules for ports 80, 443, and 8081
```
La migration crée un script (`modify_firewall_config.ps1`) qui contient la configuration suivante :
```
New-NetFirewallRule -DisplayName "Allow Web Traffic" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 80,443
New-NetFirewallRule -DisplayName "Allow API Traffic" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 8081
```
L'outil de migration effectue automatiquement les actions suivantes :
+ Extrait HTTP/HTTPS les ports de toutes les liaisons de sites IIS
+ Utilise l'interface Windows Firewall [INetFwPolicy2](https://learn.microsoft.com/en-us/windows/win32/api/netfw/nn-netfw-inetfwpolicy2) pour énumérer les règles de pare-feu
+ Filtre les règles pour n'inclure que celles qui font explicitement référence aux ports spécifiés
+ Traite uniquement les liaisons de sites HTTP et HTTPS et leurs règles de pare-feu associées
+ Préserve les propriétés des règles, notamment le nom d'affichage, l'action, le protocole et l'état activé
+ Gère à la fois les ports individuels et les plages de ports dans les règles de pare-feu
+ Ajoute le script de configuration du pare-feu au manifeste de déploiement
### Configuration de l'équilibreur de charge
Vous pouvez spécifier la configuration du Load Balancer via l'`--vpc-config`argument. Les exemples suivants illustrent les paramètres.
Sélection du schéma
Choisissez entre des schémas d'équilibreur de charge publics et privés :
```
{
"id": "vpc-12345678",
"elbscheme": "private",
"elbsubnets": ["subnet-private1", "subnet-private2"]
}
```
Distribution de sous-réseaux
Pour une haute disponibilité, répartissez les sous-réseaux d'équilibrage de charge entre les zones de disponibilité :
```
{
"elbsubnets": [
"subnet-az1", // Availability Zone 1
"subnet-az2", // Availability Zone 2
"subnet-az3" // Availability Zone 3
]
}
```
**Note**
Alors qu'Elastic Beanstalk prend en charge la création d'environnements avec des équilibreurs de charge d'application, des équilibreurs de charge réseau et des équilibreurs de charge classiques, la commande prend uniquement en charge les **eb migrate** équilibreurs de charge d'application. Pour plus d'informations sur les types d'équilibreurs de charge, consultez la section [Équilibreur de charge pour votre environnement Elastic Beanstalk](using-features.managing.elb.md).
## Déploiements multisites avec configurations de ports
La **eb migrate** commande gère les déploiements IIS multisites complexes dans lesquels les applications peuvent partager des dépendances ou utiliser des ports non standard. Prenons l'exemple suivant d'une configuration d'entreprise typique avec plusieurs sites :
```
```
Pour migrer cette configuration, utilisez les exemples de commande et de paramètres suivants :
```
PS C:\migrations_workspace> eb migrate `
--sites "Default Web Site,InternalAPI,ReportingPortal" `
--copy-firewall-config `
--instance-type "c5.large"
```
La **eb migrate** commande crée un package de déploiement qui préserve l'identité et la configuration de chaque site. La commande génère un `aws-windows-deployment-manifest.json` qui définit la manière dont ces sites doivent être déployés. L'exemple suivant illustre un fichier json généré :
```
{
"manifestVersion": 1,
"deployments": {
"msDeploy": [
{
"name": "DefaultWebSite",
"parameters": {
"appBundle": "DefaultWebSite.zip",
"iisPath": "/",
"iisWebSite": "Default Web Site"
}
}
],
"custom": [
{
"name": "InternalAPI",
"scripts": {
"install": {
"file": "ebmigrateScripts\\install_site_InternalAPI.ps1"
},
"restart": {
"file": "ebmigrateScripts\\restart_site_InternalAPI.ps1"
},
"uninstall": {
"file": "ebmigrateScripts\\uninstall_site_InternalAPI.ps1"
}
}
},
{
"name": "ReportingPortal",
"scripts": {
"install": {
"file": "ebmigrateScripts\\install_site_ReportingPortal.ps1"
},
"restart": {
"file": "ebmigrateScripts\\restart_site_ReportingPortal.ps1"
},
"uninstall": {
"file": "ebmigrateScripts\\uninstall_site_ReportingPortal.ps1"
}
}
}
]
}
}
```
Le processus de migration crée les règles d'écoute Application Load Balancer suivantes qui conservent votre logique de routage d'origine :
+ Le trafic du port 80 est acheminé vers le site Web par défaut
+ Le trafic du port 8081 est acheminé vers l'API interne
+ Le trafic du port 8082 est acheminé vers ReportingPortal
## Configuration et dépendances partagées
Lorsque les sites partagent des configurations ou des dépendances, **eb migrate** gère ces relations de manière appropriée. Reportez-vous à l'exemple suivant où plusieurs sites partagent une configuration commune :
```
```
Le processus de migration exécute les tâches suivantes :
1. Identifie les configurations partagées entre les sites
1. Génère PowerShell des scripts appropriés pour appliquer ces paramètres
1. Maintient la hiérarchie de configuration et l'héritage
## Bonnes pratiques
Nous vous recommandons de suivre les meilleures pratiques pour la configuration réseau de votre application migrée. Les groupes suivants fournissent des directives récapitulatives.
Conception en VPC
+ Suivez les meilleures AWS pratiques en matière de conception de VPC
+ Utiliser des sous-réseaux distincts pour les équilibreurs de charge et les instances EC2
+ Implémenter des tables de routage appropriées et NACLs
+ Envisagez les points de terminaison VPC pour les services AWS
Haute disponibilité
+ Déployer sur plusieurs zones de disponibilité
+ Utiliser au moins deux sous-réseaux pour les équilibreurs de charge
+ Configurer l'auto-scaling sur AZs
+ Mettre en œuvre des bilans de santé appropriés
Sécurité
+ Suivez les meilleures pratiques en matière de sécurité
+ Utiliser les groupes de sécurité comme contrôle d'accès principal
+ Implémenter des listes de contrôle d'accès au réseau (ACLs) pour une sécurité accrue
+ Surveiller les journaux de flux VPC
## Résolution des problèmes
Les problèmes courants de configuration réseau concernent les domaines suivants. Chaque sujet est suivi d'exemples de commandes permettant d'obtenir plus d'informations sur la configuration du réseau et l'état de santé de votre environnement.
Configuration du sous-réseau
```
# Verify subnet availability
PS C:\migrations_workspace> aws ec2 describe-subnets --subnet-ids subnet-id
# Check available IP addresses
PS C:\migrations_workspace>aws ec2 describe-subnets --subnet-ids subnet-id --query 'Subnets[].AvailableIpAddressCount'
```
Accès aux groupes de sécurité
```
# Verify security group rules
PS C:\migrations_workspace> aws ec2 describe-security-groups --group-ids sg-id
# Test network connectivity
PS C:\migrations_workspace> aws ec2 describe-network-interfaces --filters Name=group-id,Values=sg-id
```
État de l'équilibreur de charge
```
# Check load balancer health
PS C:\migrations_workspace> aws elbv2 describe-target-health --target-group-arn arn:aws:elasticloadbalancing:region:account-id:targetgroup/group-name/group-id
```
# Configurations de sécurité et rôles IAM
La **eb migrate** commande gère les configurations AWS de sécurité via les rôles IAM, les profils d'instance et les rôles de service. La compréhension de ces composants garantit un contrôle d'accès approprié et une conformité en matière de sécurité lors de la migration.
## Configuration du profil d'instance
Un profil d'instance sert de conteneur pour un rôle IAM qu'Elastic Beanstalk attache aux instances EC2 de votre environnement. Lors de l'exécution**eb migrate**, vous pouvez spécifier un profil d'instance personnalisé :
```
PS C:\migrations_workspace> eb migrate --instance-profile "CustomInstanceProfile"
```
Si vous ne spécifiez aucun profil d'instance, **eb migrate** crée un profil par défaut avec les autorisations suivantes :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:GetObjectVersion",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::elasticbeanstalk-*",
"arn:aws:s3:::elasticbeanstalk-*/*"
]
}
]
}
```
------
## Gestion des rôles de service
Un rôle de service permet à Elastic Beanstalk AWS de gérer les ressources en votre nom. Spécifiez un rôle de service personnalisé lors de la migration à l'aide de la commande suivante :
```
PS C:\migrations_workspace> eb migrate --service-role "CustomServiceRole"
```
S'il n'est pas spécifié, **eb migrate** crée un rôle de service par défaut nommé `aws-elasticbeanstalk-service-role` avec une politique de confiance qui permet à Elastic Beanstalk d'assumer ce rôle. Ce rôle de service est essentiel pour qu'Elastic Beanstalk puisse surveiller l'état de votre environnement et effectuer des mises à jour de plateforme gérées. Le rôle de service nécessite deux politiques gérées :
+ `AWSElasticBeanstalkEnhancedHealth`- Permet à Elastic Beanstalk de surveiller l'état de l'instance et de l'environnement à l'aide du système de reporting de santé amélioré
+ `AWSElasticBeanstalkManagedUpdates`- Permet à Elastic Beanstalk d'effectuer des mises à jour gérées de la plateforme, y compris la mise à jour des ressources de l'environnement lorsqu'une nouvelle version de plate-forme est disponible
Avec ces politiques, le rôle de service est autorisé à :
+ Création et gestion de groupes Auto Scaling
+ Création et gestion des équilibreurs de charge des applications
+ Importer des journaux sur Amazon CloudWatch
+ Gérer les instances EC2
Pour plus d'informations sur les rôles de service, consultez [Rôle de service Elastic Beanstalk](concepts-roles-service.md) le manuel Elastic Beanstalk Developer Guide.
## Configuration du groupe de sécurité
La **eb migrate** commande configure automatiquement les groupes de sécurité en fonction de vos liaisons de site IIS. Par exemple, si votre environnement source comporte des sites utilisant les ports 80, 443 et 8081, les résultats de configuration suivants sont les suivants :
```
```
Le processus de migration exécute les actions suivantes :
+ Crée un groupe de sécurité d'équilibrage de charge autorisant le trafic entrant sur les ports 80 et 443 depuis Internet (0.0.0.0/0)
+ Crée un groupe de sécurité EC2 autorisant le trafic provenant de l'équilibreur de charge
+ Configure des ports supplémentaires (tels que 8081) si cela est spécifié `--copy-firewall-config`
Par défaut, l'Application Load Balancer est configuré avec un accès public depuis Internet. Si vous devez personnaliser ce comportement, par exemple en restreignant l'accès à des plages d'adresses IP spécifiques ou en utilisant un équilibreur de charge privé, vous pouvez remplacer la configuration par défaut du VPC et du groupe de sécurité à l'aide du paramètre : `--vpc-config`
```
PS C:\migrations_workspace> eb migrate --vpc-config vpc-config.json
```
Par exemple, la `vpc-config.json` configuration suivante crée un équilibreur de charge privé dans un sous-réseau privé :
```
{
"id": "vpc-12345678",
"publicip": "false",
"elbscheme": "internal",
"ec2subnets": ["subnet-private1", "subnet-private2"],
"elbsubnets": ["subnet-private1", "subnet-private2"]
}
```
Pour plus d'informations sur les options de configuration VPC, consultez. [Configuration VPC](dotnet-migrating-applications-network.md#dotnet-migrating-applications-network-vpc)
## Intégration des certificats SSL
Lorsque vous migrez des sites avec des liaisons HTTPS, intégrez les certificats SSL via AWS Certificate Manager (ACM) :
```
PS C:\migrations_workspace> eb migrate --ssl-certificates "arn:aws:acm:region:account:certificate/certificate-id"
```
Cette configuration permet de réaliser les actions suivantes :
+ Associe le certificat à l'Application Load Balancer
+ Maintient la terminaison HTTPS au niveau de l'équilibreur de charge
+ Préserve la communication HTTP interne entre l'équilibreur de charge et les instances EC2
## Authentification Windows
Pour les applications utilisant l'authentification Windows, **eb migrate** préserve les paramètres d'authentification de l'application `web.config` comme suit :
```
```
**Important**
La **eb migrate** commande ne copie pas les profils ou comptes utilisateur de votre environnement source vers les instances Elastic Beanstalk cibles. Tous les comptes ou groupes d'utilisateurs personnalisés que vous avez créés sur votre serveur source devront être recréés sur l'environnement cible après la migration.
Les comptes `IUSR` et groupes Windows intégrés`IIS_IUSRS`, ainsi que tous les autres comptes et groupes intégrés, sont inclus par défaut dans les instances Windows Server cibles. Pour plus d'informations sur les comptes et groupes IIS intégrés, consultez la section [Présentation des comptes d'utilisateurs et de groupes intégrés dans IIS](https://learn.microsoft.com/en-us/iis/get-started/planning-for-security/understanding-built-in-user-and-group-accounts-in-iis) dans la documentation Microsoft.
Si votre application repose sur des comptes utilisateur Windows personnalisés ou sur l'intégration d'Active Directory, vous devrez configurer ces aspects séparément une fois la migration terminée.
## Bonnes pratiques et dépannage
### Gestion des rôles
Mettez en œuvre les meilleures pratiques AWS IAM lors de la gestion des rôles dans vos environnements Elastic Beanstalk :
Création et gestion des rôles
+ Créez des rôles à l'aide de politiques AWS gérées dans la mesure du possible
+ Suivez les [meilleures pratiques de sécurité IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ Utilisez le [générateur AWS de politiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) pour des politiques personnalisées
+ Implémenter [des limites d'autorisation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) pour une sécurité accrue
Surveillance et audit
Activez AWS CloudTrail pour surveiller l'utilisation des rôles :
+ Suivez le [guide de AWS CloudTrail l'utilisateur](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ Configurer l'intégration CloudWatch des journaux pour une surveillance en temps réel
+ Configurer des alertes pour les appels d'API non autorisés
Processus de révision régulier
Établissez un cycle de révision trimestriel pour effectuer les tâches suivantes :
+ Auditez les autorisations non utilisées à l'aide d'[IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)
+ Supprimer les autorisations périmées
+ Mettre à jour les rôles en fonction du principe du moindre privilège
### Gestion des certificats
Mettez en œuvre les pratiques suivantes pour les SSL/TLS certificats dans vos environnements Elastic Beanstalk :
Cycle de vie des certificats
+ Utilisation [AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html)pour la gestion des certificats
+ Activer le [renouvellement automatique](https://docs.aws.amazon.com/acm/latest/userguide/check-certificate-renewal-status.html) des certificats émis par ACM
+ Configurer les [notifications d'expiration](https://docs.aws.amazon.com/acm/latest/userguide/notifications-for-ACM.html)
Normes de sécurité
+ Utiliser TLS 1.2 ou version ultérieure
+ Respectez [les politiques de AWS sécurité](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html#describe-ssl-policies) pour les écouteurs HTTPS
+ Mettre en œuvre le protocole HTTP Strict Transport Security (HSTS) si nécessaire
### Gestion des groupes de sécurité
Mettez en œuvre les meilleures pratiques suivantes en matière de groupes de sécurité :
Gestion des règles
+ Documentez toutes les exigences relatives aux ports personnalisés
+ Utiliser les [journaux de flux VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) pour surveiller le trafic
+ Utilisez les [règles de référence des groupes de sécurité plutôt que les](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) plages d'adresses IP dans la mesure du possible
Audit régulier
Établissez des révisions mensuelles pour effectuer les tâches suivantes :
+ Identifier et supprimer les règles non utilisées
+ Valider source/destination les exigences
+ Vérifiez les règles qui se chevauchent
### Journalisation et surveillance
Pour une surveillance efficace de la sécurité, configurez les journaux suivants :
Journaux d'événements Windows sur les instances EC2
```
# Review Security event log
PS C:\migrations_workspace> Get-EventLog -LogName Security -Newest 50
# Check Application event log
PS C:\migrations_workspace> Get-EventLog -LogName Application -Source "IIS*"
```
CloudWatch Intégration des journaux
Configurez l'agent CloudWatch Logs pour qu'il diffuse les journaux d'événements Windows vers CloudWatch des fins de surveillance et d'alerte centralisées.
Pour les problèmes persistants, collectez ces journaux et contactez-nous AWS Support avec les informations suivantes :
+ ID de l'environnement
+ ID de déploiement (le cas échéant)
+ Messages d'erreur pertinents
+ Chronologie des modifications de sécurité
# Comprendre le mappage de migration entre IIS et Elastic Beanstalk
La migration d'IIS vers Elastic Beanstalk implique de mapper la configuration de votre serveur Windows sur site aux ressources du cloud. AWS La compréhension de ce mappage est essentielle à la réussite des migrations et à la gestion post-migration.
## Sites et applications IIS dans Elastic Beanstalk
Dans IIS, un site Web représente un ensemble d'applications Web et de répertoires virtuels, chacun ayant sa propre configuration et son propre contenu. Lors de la migration vers Elastic Beanstalk, ces composants sont transformés comme suit :
**Sites Web IIS**
Vos sites Web IIS deviennent des applications au sein d'Elastic Beanstalk. La configuration de chaque site Web, y compris ses liaisons, ses pools d'applications et ses paramètres d'authentification, est préservée via le manifeste de déploiement d'Elastic Beanstalk (). `aws-windows-deployment-manifest.json`
Par exemple, si vous avez plusieurs sites tels que *Default Web Site* et *IntranetSite*, regroupe **eb migrate** le contenu et la configuration de chaque site tout en préservant leur isolation.
La commande crée des règles d'écoute Application Load Balancer (ALB) appropriées pour gérer les demandes de routage vers vos applications. Il configure également les groupes de sécurité pour garantir un accès aux ports approprié en fonction de vos liaisons IIS d'origine.
**Pools d'applications**
Les pools d'applications IIS fournissent des fonctionnalités d'isolation des processus de travail, de gestion du temps d'exécution et de recyclage pour vos applications. Dans Elastic Beanstalk, ils sont mappés aux processus environnementaux définis `aws:elasticbeanstalk:environment:process` via l'espace de noms et configurés via IIS sur les instances. EC2
La migration préserve les paramètres critiques du pool d'applications, notamment les suivants :
+ Configurations des modèles de processus : identité (ApplicationPoolIdentityou comptes personnalisés), paramètres de délai d'inactivité et intervalles de recyclage des processus NetworkService
+ Paramètres de version .NET CLR - Maintient la version de .NET Framework que vous avez spécifiée (v2.0, v4.0 ou aucun code managé) pour garantir la compatibilité des applications
+ Mode pipeline géré : préserve les paramètres du mode pipeline intégré ou classique pour conserver votre architecture de traitement des requêtes HTTP
+ Paramètres avancés : longueur de la file d'attente, limites du processeur, seuils de protection en cas de défaillance rapide et limites de temps de démarrage
La **eb migrate** commande préserve les mappages entre les sites et les pools d'applications pendant la migration vers votre environnement Elastic Beanstalk.
Si vos pools d'applications utilisent des programmes de recyclage personnalisés (durées ou seuils de mémoire spécifiques), ceux-ci sont mis en œuvre par le biais de PowerShell scripts du package de déploiement qui configurent les paramètres IIS appropriés sur les EC2 instances.
**Liaisons du site Web**
Les liaisons de site Web IIS, qui définissent la manière dont les clients accèdent à vos applications, sont transformées en configurations Application Load Balancer (ALB) suivantes :
+ Les liaisons de port sont mappées aux règles d'écoute ALB correspondantes
+ Les configurations d'en-tête de l'hôte sont traduites en règles de routage ALB
+ Les sites compatibles SSL utilisent AWS Certificate Manager (ACM) pour la gestion des certificats
## Gestion des répertoires virtuels et des chemins d'application
Les répertoires virtuels et les applications IIS fournissent un mappage de chemins d'URL vers des répertoires physiques. Elastic Beanstalk maintient ces relations par le biais des structures suivantes :
**Répertoires virtuels**
Le processus de migration préserve les chemins physiques de vos répertoires virtuels dans le package de déploiement.
Les mappages de chemins sont configurés dans la configuration IIS sur les EC2 instances, ce qui garantit que votre structure d'URL reste intacte après la migration.
**3 chemins physiques du lecteur**
Par défaut, les environnements Windows Elastic Beanstalk fournissent uniquement le lecteur C : \$1 (volume racine). Dans la version actuelle, les applications dont le contenu se trouve sur des lecteurs (D : \$1, E : \$1, etc.) ne sont pas prises en charge pour la migration.
La **eb migrate** commande détecte automatiquement les chemins physiques situés sur les lecteurs et vous avertit en cas de problème potentiel, comme dans l'exemple suivant :
```
ERROR: Detected physical paths on drive D:\ which are not supported in the current version:
- D:\websites\intranet
- D:\shared\images
Migration of content from non-system drives is not supported. Please relocate this content to the C:\ drive before migration. Otherwise, select only those sites that are on C:\.
```
Si votre application dépend de lecteurs, vous devrez modifier votre application pour stocker tout le contenu sur le lecteur C : \$1 avant la migration.
**Applications imbriquées**
Les applications imbriquées sous des sites Web sont déployées avec leurs configurations de chemin correctes et leurs affectations de pool d'applications appropriées. Le processus de migration préserve tous les ` web.config` paramètres, garantissant ainsi que les configurations spécifiques aux applications continuent de fonctionner comme prévu dans l'environnement cloud.
## Réécriture d'URL et routage des demandes d'applications (ARR)
Si votre déploiement IIS utilise la réécriture d'URL ou le routage des demandes d'application (ARR), **eb migrate** gère ces configurations selon les règles et la configuration suivantes :
**Règles de réécriture d'URL**
Les règles de réécriture d'URL de vos `web.config` fichiers sont traduites en règles de routage ALB dans la mesure du possible. Par exemple, l'entrée suivante devient une règle d'écoute ALB dirigeant le trafic en fonction des en-têtes de l'hôte et des modèles de chemin. :
```
```
**Routage des demandes d'application**
Les configurations ARR sont préservées grâce à l'installation de fonctionnalités ARR sur EC2 les instances. Le processus de migration exécute les tâches suivantes :
+ Configure les paramètres du proxy en fonction de votre environnement source
+ Maintient les règles de réécriture d'URL associées à l'ARR
## Structure des artefacts de migration
Lorsque vous l'exécutez**eb migrate**, il crée un répertoire structuré contenant tous les composants de déploiement nécessaires. La liste suivante décrit la structure du répertoire :
```
C:\migration_workspace\
└── .\migrations\latest\
└── upload_target\
├── [SiteName].zip # One ZIP per IIS site
├── aws-windows-deployment-manifest.json
└── ebmigrateScripts\
├── site_installer.ps1 # Site installation scripts
├── arr_configuration.ps1 # ARR configuration scripts
├── permission_handler.ps1 # Permission management
└── firewall_config.ps1 # Windows Firewall rules
```
Le `aws-windows-deployment-manifest.json` fichier est le fichier de configuration de base qui indique à Elastic Beanstalk comment déployer vos applications. Reportez-vous à l'exemple de structure suivant :
```
{
"manifestVersion": 1,
"deployments": {
"msDeploy": [
{
"name": "Primary Site",
"parameters": {
"appBundle": "DefaultWebSite.zip",
"iisPath": "/",
"iisWebSite": "Default Web Site"
}
}
],
"custom": [
{
"name": "ConfigureARR",
"scripts": {
"install": {
"file": "ebmigrateScripts\\arr_configuration.ps1"
},
"uninstall": {
"file": "ebmigrateScripts\\noop.ps1"
},
"restart": {
"file": "ebmigrateScripts\\noop.ps1"
}
}
}
]
}
}
```
Ce manifeste garantit les résultats suivants pour votre migration :
+ Les applications sont déployées pour corriger les chemins IIS
+ Des configurations personnalisées sont appliquées
+ Les paramètres spécifiques au site sont préservés
+ L'ordre de déploiement est maintenu
# Scénarios de migration avancés
Cette section couvre les scénarios de migration avancés pour les déploiements IIS complexes.
## Migrations multisites avec routage des demandes d'application (ARR)
La **eb migrate** commande détecte et préserve automatiquement les configurations ARR pendant la migration. Lorsqu'il identifie les paramètres ARR dans votre IIS`applicationHost.config`, il génère les PowerShell scripts nécessaires pour réinstaller et configurer ARR sur les EC2 instances cibles.
### Détection de configuration ARR
Le processus de migration examine trois sections de configuration clés dans IIS :
+ `system.webServer/proxy`: Paramètres du proxy ARR de base
+ `system.webServer/rewrite`: règles de réécriture d'URL
+ `system.webServer/caching`: Configuration de la mise en cache
Par exemple, considérez une configuration ARR courante dans laquelle une application `RouterSite` exécutée sur le port 80 envoie des requêtes aux ports 8081 `APIService` et 8082 et `AdminPortal` s'exécute respectivement sur ces ports :
```
```
Le schéma suivant montre comment ces règles sont masquées derrière le port 80 sur le serveur IIS et ne sont pas exposées via les groupes EC2 de sécurité. Seul le port 80 est accessible à l'Application Load Balancer et tout le trafic provenant de celui-ci est acheminé vers le groupe cible sur le port 80.
![\[Architecture Elastic Beanstalk avec routage des demandes d'application (ARR)\]](http://docs.aws.amazon.com/fr_fr/elasticbeanstalk/latest/dg/images/architecture-diagram-with-arr.png)
La commande suivante peut faire migrer cette configuration :
```
PS C:\migrations_workspace> eb migrate --sites "RouterSite,APIService,AdminPortal" `
--copy-firewall-config
```
### Processus de migration ARR
Le processus de migration préserve votre configuration ARR en plusieurs étapes.
Exportation de configuration
L'outil exporte vos paramètres ARR existants depuis les trois sections de configuration clés dans des fichiers XML distincts stockés dans le `ebmigrateScripts` répertoire :
```
ebmigrateScripts\
├── arr_config_proxy.xml
├── arr_config_rewrite.xml
└── arr_config_caching.xml
```
Scripts d'installation
Deux PowerShell scripts sont générés pour gérer la configuration de l'ARR :
1. `arr_msi_installer.ps1`: télécharge et installe le module ARR
1. `arr_configuration_importer_script.ps1`: Importe votre configuration ARR exportée
Intégration du manifeste de déploiement
Les scripts sont intégrés au processus de déploiement par le biais d'entrées dans `aws-windows-deployment-manifest.json` :
```
{
"manifestVersion": 1,
"deployments": {
"custom": [
{
"name": "WindowsProxyFeatureEnabler",
"scripts": {
"install": {
"file": "ebmigrateScripts\\windows_proxy_feature_enabler.ps1"
}
}
},
{
"name": "ArrConfigurationImporterScript",
"scripts": {
"install": {
"file": "ebmigrateScripts\\arr_configuration_importer_script.ps1"
}
}
}
]
}
}
```
### Intégration de l'équilibreur de charge
Le processus de migration traduit vos règles ARR en règles d'écoute Application Load Balancer (ALB) dans la mesure du possible. Par exemple, la configuration ARR ci-dessus donne lieu à des règles ALB qui acheminent le trafic en fonction des modèles de chemin d'URL tout en maintenant le routage interne sur les EC2 instances.
L'environnement qui en résulte conserve votre logique de routage ARR tout en tirant parti de l'infrastructure élastique AWS de l'ARR. Vos applications continuent de fonctionner comme avant, ARR gérant le routage interne tandis que l'Application Load Balancer gère la distribution du trafic externe.
## Migrations multisites sans ARR à l'aide d'un routage basé sur l'hôte
Bien que le routage des demandes d'application (ARR) soit une approche courante pour gérer plusieurs sites dans IIS, vous pouvez également migrer des déploiements multisites directement vers Elastic Beanstalk sans ARR en tirant parti des fonctionnalités de routage basées sur l'hôte de l'Application Load Balancer. Cette approche permet de réduire la complexité et d'améliorer les performances en éliminant une couche de routage supplémentaire.
### Vue d'ensemble du routage basé sur l'hôte
Dans cette approche, chaque site IIS est exposé en dehors de l' EC2 instance, et l'Application Load Balancer achemine le trafic directement vers le port approprié en fonction de l'en-tête de l'hôte. Cela élimine le besoin d'ARR tout en maintenant la séparation entre vos applications.
Prenons l'exemple d'une configuration IIS multisite avec trois sites, chacun ayant sa propre liaison de nom d'hôte :
```
```
Ces sites sont exposés sur les ports 8081, 8082 et 8083 via les EC2 groupes de sécurité. L'Application Load Balancer les achemine vers eux en fonction de la configuration des règles de l'écouteur Load Balancer.
![\[Architecture Elastic Beanstalk sans routage des demandes d'application (ARR)\]](http://docs.aws.amazon.com/fr_fr/elasticbeanstalk/latest/dg/images/architecture-diagram-without-arr.png)
### Processus de migration
Pour migrer cette configuration vers Elastic Beanstalk sans **eb migrate** utiliser ARR, utilisez la commande de l'exemple suivant :
```
PS C:\migrations_workspace> eb migrate --sites "Default Web Site,InternalAPI,ReportingPortal"
```
Le processus de migration configure automatiquement l'Application Load Balancer avec des règles de routage basées sur l'hôte qui dirigent le trafic vers le groupe cible approprié en fonction de l'en-tête de l'hôte. Chaque groupe cible transmet le trafic vers le port correspondant sur vos EC2 instances :
1. En-tête de l'hôte www.example.com → Groupe cible sur le port 8081
1. En-tête d'hôte api.internal → Groupe cible sur le port 8082
1. En-tête de l'hôte reports.internal → Groupe cible sur le port 8083
### Configuration SSL/TLS
Pour sécuriser vos applications, SSL/TLS procédez comme suit :
1. Demandez des certificats pour vos domaines via AWS Certificate Manager(ACM).
1. Configurez les écouteurs HTTPS sur votre Application Load Balancer à l'aide de ces certificats.
1. Mettez à jour la configuration de votre environnement pour inclure les écouteurs HTTPS avec les paramètres d'options de configuration suivants.
```
option_settings:
aws:elb:listener:443:
ListenerProtocol: HTTPS
SSLCertificateId: arn:aws:acm:region:account-id:certificate/certificate-id
InstancePort: 80
InstanceProtocol: HTTP
```
Avec cette configuration, la terminaison SSL se produit au niveau de l'équilibreur de charge et le trafic est transféré vers vos instances via HTTP. Cela simplifie la gestion des certificats tout en maintenant des connexions sécurisées avec les clients.
### Bonnes pratiques
Groupes de sécurité
Configurez les groupes de sécurité pour autoriser le trafic entrant uniquement sur les ports utilisés par vos sites IIS (8081, 8082, 8083 dans cet exemple) à partir du groupe de sécurité Application Load Balancer.
Surveillance de l'état
Configurez les contrôles de santé pour chaque groupe cible afin de garantir que le trafic est uniquement acheminé vers des instances saines. Créez des points de terminaison de contrôle de santé pour chaque application s'ils n'existent pas déjà.
Contrôle
Configurez des CloudWatch alarmes pour surveiller la santé et les performances de chaque groupe cible séparément. Cela vous permet d'identifier les problèmes spécifiques aux applications individuelles.
Mise à l’échelle
Tenez compte des besoins en ressources de toutes les applications lors de la configuration des politiques d'autodimensionnement. Si les besoins en ressources d'une application sont très différents, envisagez de la migrer vers un environnement distinct.
## Gestion des annuaires virtuels
La **eb migrate** commande préserve les structures de répertoires virtuels lors de la migration de vos applications IIS vers Elastic Beanstalk.
### Configuration des autorisations par défaut
Lors de la migration de répertoires virtuels, **eb migrate** établit un ensemble d'autorisations de base en accordant l' ReadAndExecute accès à :
+ IIS\$1IUSRS
+ IUSR
+ Utilisateurs authentifiés
Par exemple, considérez une structure de répertoire virtuel typique :
```
```
### Répertoires virtuels protégés par mot de passe
Lorsqu'il **eb migrate** rencontre des répertoires virtuels protégés par mot de passe, il émet des avertissements et nécessite une intervention manuelle.
L'exemple de configuration suivant provoquera la réponse d'avertissement qui suit l'exemple.
```
```
```
[WARNING] CorporatePortal/secure is hosted at C:\secure\content which is password-protected and won't be copied.
```
Pour garantir la protection par mot de passe, créez un script de déploiement personnalisé tel que le suivant :
```
# PS C:\migrations_workspace> cat secure_vdir_config.ps1
$vdirPath = "C:\secure\content"
$siteName = "CorporatePortal"
$vdirName = "secure"
$username = "DOMAIN\User"
$password = "SecurePassword"
# Ensure directory exists
if (-not (Test-Path $vdirPath)) {
Write-Host "Creating directory: $vdirPath"
New-Item -Path $vdirPath -ItemType Directory -Force
}
# Configure virtual directory with credentials
Write-Host "Configuring protected virtual directory: $vdirName"
New-WebVirtualDirectory -Site $siteName -Name $vdirName `
-PhysicalPath $vdirPath -UserName $username -Password $password
# Set additional permissions as needed
$acl = Get-Acl $vdirPath
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
$username, "ReadAndExecute", "ContainerInherit,ObjectInherit", "None", "Allow"
)
$acl.AddAccessRule($rule)
Set-Acl $vdirPath $acl
```
Ajoutez ce script à votre déploiement en l'incluant dans le manifeste :
```
{
"manifestVersion": 1,
"deployments": {
"custom": [
{
"name": "SecureVirtualDirectory",
"scripts": {
"install": {
"file": "secure_vdir_config.ps1"
}
}
}
]
}
}
```
### Gestion personnalisée des autorisations
La **eb migrate** commande fournit un cadre pour les scripts d'autorisation personnalisés afin de prendre en charge les applications qui nécessitent des autorisations autres que celles par défaut.
```
$paths = @(
"C:\sites\portal\uploads",
"C:\shared\content"
)
foreach ($path in $paths) {
if (-not (Test-Path $path)) {
Write-Host "Creating directory: $path"
New-Item -Path $path -ItemType Directory -Force
}
$acl = Get-Acl $path
# Add custom permissions
$customRules = @(
# Application Pool Identity - Full Control
[System.Security.AccessControl.FileSystemAccessRule]::new(
"IIS AppPool\CorporatePortalPool",
"FullControl",
"ContainerInherit,ObjectInherit",
"None",
"Allow"
),
# Custom Service Account
[System.Security.AccessControl.FileSystemAccessRule]::new(
"NT SERVICE\CustomService",
"Modify",
"ContainerInherit,ObjectInherit",
"None",
"Allow"
)
)
foreach ($rule in $customRules) {
$acl.AddAccessRule($rule)
}
Set-Acl $path $acl
Write-Host "Custom permissions applied to: $path"
}
```
### Bonnes pratiques
Suivez ces bonnes pratiques pour planifier, exécuter, surveiller et vérifier votre migration.
Planification préalable à la migration
Documentez les autorisations existantes et les exigences d'authentification avant la migration. Testez des scripts d'autorisation personnalisés dans un environnement de développement avant de les déployer en production.
Gestion de contenu partagé
Pour les répertoires de contenu partagé, assurez-vous que toutes les autorisations nécessaires au système de fichiers sont correctement configurées par le biais de scripts personnalisés. Envisagez d'utiliser [Amazon FSx pour Windows File Server](https://aws.amazon.com/fsx/windows/) pour les besoins de stockage partagé.
Surveillance et vérification
Surveillez les journaux des applications après la migration pour vérifier l'accès approprié aux répertoires virtuels. Portez une attention particulière aux domaines suivants :
+ Accès aux identités du pool d'applications
+ Autorisations de compte de service personnalisées
+ Connectivité de partage réseau
+ Authentication failures (Échecs d’authentification)
## Paramètres personnalisés du pool d'applications
La **eb migrate** commande ne copie pas les paramètres personnalisés du pool d'applications par défaut. Pour conserver les configurations personnalisées du pool d'applications, suivez cette procédure pour créer et appliquer une section de manifeste personnalisée.
1. Créez une archive de vos artefacts de migration.
```
PS C:\migrations_workspace> eb migrate --archive
```
1. Créez un PowerShell script personnalisé pour configurer les pools d'applications.
```
# PS C:\migrations_workspace> cat .\migrations\latest\upload_target\customize_application_pool_config.ps1
$configPath = "$env:windir\System32\inetsrv\config\applicationHost.config"
[xml]$config = Get-Content -Path $configPath
$newPoolXml = @"
"@
$newPoolXmlNode = [xml]$newPoolXml
# Find the applicationPools section
$applicationPools = $config.SelectSingleNode("//configuration/system.applicationHost/applicationPools")
# Import the new node into the document
$importedNode = $config.ImportNode($newPoolXmlNode.DocumentElement, $true)
$applicationPools.AppendChild($importedNode)
# Save the changes
$config.Save($configPath)
Write-Host "ApplicationHost.config has been updated successfully."
```
1. Mettez à jour le `aws-windows-deployment-manifest.json` fichier pour inclure votre script personnalisé.
```
{
"manifestVersion": 1,
"deployments": {
...
"custom": [
...,
{
"name": "ModifyApplicationPoolConfig",
"description": "Modify application pool configuration from source machine to remove",
"scripts": {
"install": {
"file": "customize_application_pool_config.ps1"
},
"restart": {
"file": "ebmigrateScripts\\noop.ps1"
},
"uninstall": {
"file": "ebmigrateScripts\\noop.ps1"
}
}
}
]
}
}
```
1. Créez un environnement avec le répertoire d'archives mis à jour.
```
PS C:\migrations_workspace> eb migrate `
--archive-dir '.\migrations\latest\upload_target\'
```
L'`--archive-dir`argument indique **eb migrate** d'utiliser le code source qu'il a créé précédemment, en évitant la création de nouvelles archives.
## Déploiement des versions précédentes
**eb migrate**conserve un historique de vos migrations via des annuaires horodatés et des versions d'applications dans Elastic Beanstalk. Chaque migration crée un fichier zip unique qui peut être déployé si nécessaire.
```
PS C:\migrations_workspace> ls .\migrations\
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----l 3/18/2025 10:34 PM latest
d----- 3/16/2025 5:47 AM migration_1742104049.479849
d----- 3/17/2025 9:18 PM migration_1742246303.18056
d----- 3/17/2025 9:22 PM migration_1742246546.565739
...
d----- 3/18/2025 10:34 PM migration_1742337258.30742
```
Le lien `latest` symbolique pointe toujours vers le répertoire des artefacts de migration le plus récemment créé. Outre les journaux d'applications et d'erreurs pertinents, chaque répertoire d'artefacts de migration contient également un `upload_target.zip` fichier que vous pouvez déployer sur Elastic Beanstalk.
```
PS C:\migrations_workspace> ls .\migrations\latest\
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 3/18/2025 10:34 PM upload_target
-a---- 3/18/2025 10:34 PM 13137 application.log
-a---- 3/18/2025 10:34 PM 0 error.log
-a---- 3/18/2025 10:34 PM 1650642 upload_target.zip
```
Vous pouvez déployer le `upload_target.zip` fichier en utilisant **eb migrate** :
```
PS C:\migrations_workspace> eb migrate --zip .\migrations\latest\upload_target.zip
```
# Dépannage et diagnostic
**Essayez Amazon Q Developer CLI pour un dépannage assisté par l'IA**
La CLI Amazon Q Developer peut vous aider à résoudre rapidement les problèmes d'environnement. La Q CLI fournit des solutions en vérifiant l'état de l'environnement, en examinant les événements, en analysant les journaux et en posant des questions de clarification. Pour plus d'informations et des instructions détaillées, consultez la section [Résolution des problèmes liés aux environnements Elastic Beanstalk avec Amazon](https://aws.amazon.com/blogs/devops/troubleshooting-elastic-beanstalk-environments-with-amazon-q-developer-cli/) Q Developer CLI dans les blogs. AWS
Cette section fournit des conseils pour résoudre les problèmes courants susceptibles de survenir lors de la migration des applications IIS vers Elastic Beanstalk.
## Associer une EC2 paire de clés à votre environnement
Vous pouvez vous connecter en toute sécurité aux instances Amazon Elastic Compute Cloud (Amazon EC2) mises en service pour votre application Elastic Beanstalk à l'aide d'une paire de clés Amazon. EC2 Pour obtenir des instructions sur la création d'une paire de clés, consultez la section [Création d'une paire de clés à l'aide d'Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#having-ec2-create-your-key-pair) dans le *guide de EC2 l'utilisateur Amazon*.
La spécification d'un nom de clé **eb migrate** a pour effet d'associer votre environnement Elastic Beanstalk à la paire de clés. Pour des raisons de sécurité, cela n'ouvrira pas le port 3389 sur le groupe de sécurité de votre EC2 instance. Vous pouvez associer des groupes EC2 de sécurité supplémentaires autorisant le trafic du port 3389 à passer **eb config** après la migration initiale.
```
PS C:\migrations_workspace> eb migrate `
--keyname "my-keypair" `
--verbose
```
Lorsque vous créez une paire de clés, Amazon EC2 stocke une copie de votre clé publique. Si vous n'avez plus besoin de l'utiliser pour vous connecter à des instances d'environnement, vous pouvez le supprimer d'Amazon EC2. Pour plus de détails, consultez [Supprimer votre paire de clés](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#delete-key-pair) dans le *guide de EC2 l'utilisateur Amazon*.
Pour plus d'informations sur la connexion aux EC2 instances Windows Amazon, consultez [Connexion à une instance Windows](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connecting_to_windows_instance.html).
## Accès aux journaux
L'EB CLI fournit une **eb logs** fonctionnalité que vous pouvez utiliser pour récupérer les journaux d'un environnement Elastic Beanstalk sans vous connecter à ses instances. EC2 Après l'exécution de**eb migrate**, vous pouvez lancer la **eb logs --zip** commande qui téléchargera et enregistrera les journaux dans le `.elasticbeanstalk\logs` répertoire.
Vous pouvez également consulter les journaux via la console AWS Elastic Beanstalk. Pour de plus amples informations, veuillez consulter [Affichage des journaux des instances Amazon EC2 dans votre environnement Elastic Beanstalk](using-features.logging.md).
## Accès aux artefacts côté client
La **eb migrate** commande stocke les journaux d'applications et d'erreurs générés par les répertoires d'artefacts des migrations **msdeploy** internes.
```
./migrations/
├── latest -> migration_20240308_123456/
└── migration_20240308_123456/
├── application.log
├── error.log
└── upload_target\
```
## Surveillance de la santé de l'environnement
Elastic Beanstalk vous aide à surveiller l'état de santé à l'aide des fonctionnalités améliorées de surveillance de l'état de santé. Il s'agit d'un système de surveillance automatique de l'état de santé qui suit en permanence l'état opérationnel des instances d'application, en tirant parti de mesures intégrées telles que l'utilisation du processeur, la latence, le nombre de demandes et les codes de réponse.
Le système de surveillance de l'état utilise une approche basée sur des agents pour collecter des données au niveau de l'instance et intègre la journalisation et les alertes en temps réel. Elastic Load Balancing (ELB) et Auto Scaling répondent de manière dynamique aux changements d'état de santé, garantissant ainsi une disponibilité et une tolérance aux pannes élevées. Les modes de surveillance avancés, notamment les rapports de santé améliorés, fournissent une visibilité précise du comportement des applications, permettant un dépannage proactif et des mécanismes de restauration automatique.
Exécutez la **eb health** commande EB CLI pour afficher l'état de santé de l'environnement. Les informations suivantes s’affichent :
+ État d'une instance
+ Métriques de réponse des applications
+ Utilisation des ressources du système
+ Événements de déploiement récents
## EC2 optimisation des performances
Par défaut, **eb migrate** sélectionne le type d'instance [c5.2xlarge](https://aws.amazon.com/ec2/instance-types/c5/) pour offrir une première expérience optimale avec Elastic Beanstalk. Vous pouvez modifier ce comportement avec l'**--instance-type**argument suivant :
```
PS C:\migrations_workspace> eb migrate `
--instance-type "t3.large"
```
Pour les environnements de production, tenez compte des facteurs suivants lors de la sélection d'un type d'instance :
+ Besoins en mémoire de vos applications
+ Exigences relatives au processeur pour le traitement des charges de travail
+ Besoins de performance du réseau
+ Objectifs d'optimisation des coûts
## Configuration du volume EBS
Par défaut, Elastic Beanstalk crée uniquement un volume root `C:\` block-device () pour votre environnement. Vous pouvez transmettre des volumes de snapshots Amazon Elastic Block Store supplémentaires avec l'**--ebs-snapshots**option suivante :
```
PS C:\migrations_workspace> eb migrate `
--ebs-snapshots "snap-123456789abc"
```
[Pour des exemples illustrant la manière dont vous pouvez configurer des mappages par blocs avec Elastic Beanstalk, consultez l'article de blog Customize Ephemeral et EBS volumes in Elastic Beanstalk Environments.](https://aws.amazon.com/blogs/devops/customize-ephemeral-and-ebs-volumes-in-elastic-beanstalk-environments/)
Pour les applications nécessitant beaucoup de stockage, envisagez les options suivantes :
+ Utilisation de volumes EBS pour les données persistantes
+ Implémentation d'Amazon S3 pour le contenu statique
+ Utilisation du serveur de fichiers Amazon FSx pour Windows pour les systèmes de fichiers partagés
## Problèmes courants et solutions correspondantes
**Événement :** *installation manquante de Web Deploy*
Si vous rencontrez des erreurs liées à l'impossibilité de trouver Web Deploy, installez Web Deploy 3.6 ou version ultérieure à partir du programme d'[installation de Microsoft Web Platform](https://www.iis.net/downloads/microsoft/web-deploy). L'exemple suivant affiche un message d'erreur possible.
```
Couldn't find msdeploy.exe. Follow instructions here: https://learn.microsoft.com/en-us/iis/install/installing-publishing-technologies/installing-and-configuring-web-deploy
```
**Événement :** *Problèmes d'autorisation lors de la migration*
Si vous rencontrez des erreurs liées aux autorisations, assurez-vous d'exécuter l'EB CLI avec des privilèges administratifs. L'exemple suivant affiche un message d'erreur possible.
```
[ERROR] Access to the path 'C:\inetpub\wwwroot\web.config' is denied.
```
**Événement :** *Problèmes d'identité du pool d'applications*
Si votre application ne démarre pas en raison de problèmes d'identité du pool d'applications, créez un script personnalisé pour configurer les identités du pool d'applications, comme indiqué dans[Paramètres personnalisés du pool d'applications](dotnet-migrating-applications-advanced-scenarios.md#dotnet-migrating-applications-advanced-scenarios-apppool).
**Evénement :** *erreurs de configuration du certificat SSL*
Si les liaisons HTTPS ne fonctionnent pas, assurez-vous d'avoir spécifié un ARN de certificat ACM valide à l'aide du paramètre **eb mibrate** option`--ssl-certificates`.
**Événement :** expiration du *délai de création de l'environnement*
Si le délai de création de l'environnement est expiré, vérifiez les CloudFormation événements dans la console AWS de gestion pour détecter les échecs de création de ressources spécifiques. Les causes courantes incluent les problèmes de configuration des VPC ou les limites de service.
## Obtention de support
Si vous rencontrez des problèmes que vous ne parvenez pas à résoudre, AWS Support collectez les informations suivantes avant de nous contacter :
+ ID d'environnement (`eb status`)
+ Journaux des applications (`eb logs --zip`)
+ Artefacts de migration depuis `.\migrations\latest\`
+ Configuration IIS source (sortie de`eb migrate explore --verbose`)
+ Messages d'erreur détaillés
Pour plus d'informations sur la résolution des problèmes liés à Elastic Beanstalk, consultez. [Résolution des problèmes liés à votre environnement Elastic Beanstalk](troubleshooting.md)
# Comparaison des options de migration : EB CLI et AWS Application Migration Service
AWS propose plusieurs chemins pour la migration des applications Windows vers le cloud. Cette section compare deux options principales : la **eb migrate** commande dans l'EB CLI et AWS Application Migration Service (MGN). Comprendre les différences entre ces approches vous aidera à choisir la stratégie de migration la mieux adaptée à vos besoins spécifiques.
**Comparaison des options de migration**
| Fonctionnalité | CLI WEB (**eb migrate**) | AWS Application Migration Service (MGN) |
| --- | --- | --- |
| Objectif principal | Migration au niveau de l'application de sites Web et d'applications IIS | Réhébergement au niveau du serveur de machines entières (serveurs physiques, virtuels ou cloud) |
| Idéal pour | Applications IIS que vous souhaitez migrer directement vers Elastic Beanstalk avec une reconfiguration minimale | Migrations à grande échelle impliquant de nombreux serveurs ou une infrastructure complexe |
| Approche de découverte | Découverte des sites, applications et configurations IIS au niveau de l'application | Réplication au niveau du serveur de machines entières, y compris le système d'exploitation et les applications |
| Environnement cible | Crée et configure directement des environnements Elastic Beanstalk optimisés pour les applications Windows | Crée EC2 des instances qui nécessitent une configuration supplémentaire pour fonctionner avec Elastic Beanstalk |
| Préservation de la configuration | Préserve automatiquement les configurations spécifiques à l'IIS (sites, pools d'applications, liaisons) | Préserve la configuration complète du serveur, qui peut inclure des composants inutiles |
| Modèle de déploiement | Crée un environnement Elastic Beanstalk propre avec vos applications déployées selon les meilleures pratiques d'Elastic Beanstalk | Crée une réplique de votre serveur source qui peut nécessiter une optimisation pour les opérations dans le cloud |
| Ampleur de la migration | Idéal pour les migrations ciblées d'applications spécifiques | Conçu pour les migrations à grande échelle de nombreux serveurs |
| Étapes postérieures à la migration | Minimal ; l'environnement est prêt à être utilisé avec les outils de gestion Elastic Beanstalk | Nécessite des étapes supplémentaires pour s'intégrer à Elastic Beanstalk, telles que l'exécution d'actions SSM après le lancement |
## Quand utiliser chaque option de migration
**Choisissez **eb migrate** lorsque vous répondez aux exigences suivantes :**
+ Vous souhaitez migrer des applications IIS spécifiques plutôt que des serveurs entiers
+ Votre objectif est d'adopter Elastic Beanstalk comme plateforme de gestion des applications
+ Vous souhaitez tirer parti des fonctionnalités de la plateforme gérée d'Elastic Beanstalk, telles que la facilité de mise à l'échelle, de déploiement et de surveillance
+ Vous préférez un déploiement propre qui suit les AWS meilleures pratiques pour les opérations cloud natives
+ Vous souhaitez minimiser le travail de configuration après la migration
**Choisissez AWS Application Migration Service lorsque vous répondez aux exigences suivantes :**
+ Vous devez migrer un grand nombre de serveurs
+ Vous avez des configurations de serveur complexes qui doivent être préservées exactement
+ Vos applications présentent des problèmes de compatibilité qui nécessitent de maintenir l'environnement de serveur exact
+ Vous souhaitez « soulever et déplacer » en apportant un minimum de modifications à vos applications
+ Vous envisagez de refactoriser ou d'optimiser vos applications après la migration
## Comparaison des flux de travail de migration
**Flux de travail EB CLI (**eb migrate**) :**
1. Installez l'interface de ligne de commande EB sur votre serveur IIS source ou sur un hôte bastion.
1. Exécutez **eb migrate** pour découvrir les applications IIS.
1. La commande regroupe vos applications et configurations.
1. Un environnement Elastic Beanstalk est créé avec les ressources appropriées.
1. Vos applications sont déployées dans le nouvel environnement.
1. Vous pouvez immédiatement gérer vos applications à l'aide des outils Elastic Beanstalk.
**AWS Application Migration Service flux de travail :**
1. Installez l'agent AWS de réplication sur les serveurs sources.
1. Configurez et testez la réplication des données.
1. Lancez des instances de test pour vérifier le fonctionnement.
1. Planifiez le passage à. AWS
1. Lancez des instances de production.
1. Exécutez des actions après le lancement afin d'optimiser votre solution pour le cloud.
1. Si Elastic Beanstalk est la plate-forme cible, une configuration supplémentaire est requise pour l'intégrer à Elastic Beanstalk.
## Conclusion
Elastic Beanstalk est la destination privilégiée pour les AWS applications de la plateforme Windows, car il propose un environnement géré qui simplifie le déploiement, le dimensionnement et la gestion. La **eb migrate** commande fournit un chemin direct vers les applications Elastic Beanstalk pour IIS, avec une découverte et une configuration automatiques qui préservent les paramètres de votre application.
Bien qu'elle AWS Application Migration Service offre de puissantes fonctionnalités pour les migrations de serveurs à grande échelle, elle nécessite des étapes supplémentaires pour s'intégrer à Elastic Beanstalk. Pour la plupart des migrations d'applications IIS pour lesquelles Elastic Beanstalk est la **eb migrate** plate-forme cible, cette solution propose une approche plus rationalisée qui s'aligne sur le modèle de service géré d'Elastic Beanstalk.
Choisissez l'approche de migration la mieux adaptée à vos besoins spécifiques, en tenant compte de facteurs tels que l'échelle, la complexité et l'architecture finale que vous souhaitez utiliser. AWS
Pour plus d'informations AWS Application Migration Service, voir [Qu'est-ce que c'est AWS Application Migration Service ?](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html) dans le guide de AWS Application Migration Service l'utilisateur.