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.
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 IISapplicationHost.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 :
<!-- Original IIS ARR Configuration -->
<rewrite>
<rules>
<rule name="Route to API" stopProcessing="true">
<match url="^api/(.*)$" />
<action type="Rewrite" url="http://backend:8081/api/{R:1}" />
</rule>
<rule name="Route to Admin" stopProcessing="true">
<match url="^admin/(.*)$" />
<action type="Rewrite" url="http://backend:8082/admin/{R:1}" />
</rule>
</rules>
</rewrite>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.
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
ebmigrateScriptsré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 :
-
arr_msi_installer.ps1: télécharge et installe le module ARR -
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 :
<sites> <site name="Default Web Site" id="1"> <bindings> <binding protocol="http" bindingInformation="*:8081:www.example.com" /> </bindings> </site> <site name="InternalAPI" id="2"> <bindings> <binding protocol="http" bindingInformation="*:8082:api.internal" /> </bindings> </site> <site name="ReportingPortal" id="3"> <bindings> <binding protocol="http" bindingInformation="*:8083:reports.internal" /> </bindings> </site> </sites>
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.
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 :
En-tête de l'hôte www.example.com → Groupe cible sur le port 8081
En-tête d'hôte api.internal → Groupe cible sur le port 8082
En-tête de l'hôte reports.internal → Groupe cible sur le port 8083
Configuration SSL/TLS
Pour sécuriser vos applications avec le protocole SSL/TLS, procédez comme suit :
-
Demandez des certificats pour vos domaines via AWS Certificate Manager(ACM).
-
Configurez les écouteurs HTTPS sur votre Application Load Balancer à l'aide de ces certificats.
-
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à.
- Surveillance
-
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_IUSRS
-
IUSR
-
Utilisateurs authentifiés
Par exemple, considérez une structure de répertoire virtuel typique :
<site name="CorporatePortal">
<application path="/" applicationPool="CorporatePortalPool">
<virtualDirectory path="/" physicalPath="C:\sites\portal" />
<virtualDirectory path="/shared" physicalPath="C:\shared\content" />
<virtualDirectory path="/reports" physicalPath="D:\reports" />
</application>
</site>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.
<virtualDirectory path="/secure"
physicalPath="C:\secure\content"
userName="DOMAIN\User"
password="[encrypted]" />[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
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.
-
Créez une archive de vos artefacts de migration.
PS C:\migrations_workspace>eb migrate --archive -
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 = @" <!-- Original IIS Configuration --> <applicationPools> <add name="CustomPool" managedRuntimeVersion="v4.0" managedPipelineMode="Integrated"> <processModel identityType="SpecificUser" userName="AppPoolUser" password="[encrypted]" /> <recycling> <periodicRestart time="00:00:00"> <schedule> <add value="02:00:00" /> <add value="14:00:00" /> </schedule> </periodicRestart> </recycling> </add> </applicationPools> "@ $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." -
Mettez à jour le
aws-windows-deployment-manifest.jsonfichier 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" } } } ] } } -
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-dirargument 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 migrateconserve 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
