Personnaliser le plan de migration pour les services IIS Windows
Examinez le fichier de plan de migration renseigné lors de la création de la migration. Vous pouvez le personnaliser avant de poursuivre l'exécution de la migration. Les informations de votre plan de migration servent à l'extraction des artefacts de conteneur de charge de travail de la VM source.
Cette section décrit le contenu du plan de migration et les types de personnalisations que vous pouvez envisager avant d'exécuter la migration et de générer des artefacts de déploiement.
Avant de commencer
Ce document suppose que vous avez déjà créé un plan de migration et que vous disposez du fichier de plan de migration qui en résulte.
Structure du plan de migration
Voici la structure complète du plan de migration. Les sections suivantes décrivent cette structure, en présentent chaque partie et expliquent comment la modifier.
globalSettings:
globalIis:
enablegmsa: string
apppools:
- enable32bitapponwin64: bool
identitytype: string
managedruntimeversion: string
name: string
connectionStrings:
add:
- connectionstring: string
name: string
providername: string
security:
authentication:
windowsAuthentication:
enabled: bool
providers:
- value: string
authorization:
add:
- access_type: string
roles: string
users: string
verbs: string
remove:
- roles: string
users: string
verbs: string
image:
extraFeatures:
- string
target:
baseVersion: string
requirements:
- string
warnings:
- string
msvcRuntimes:
- string
pathEnvVarAdditionalEntries:
- string
images:
- name: string
probes:
enabled: bool
livenessProbe:
probehandler:
exec:
command:
- string
- string
initialdelayseconds: int
timeoutseconds: int
periodseconds: int
successthreshold: int
failurethreshold: int
terminationgraceperiodseconds: optional[int]
readinessProbe:
probehandler:
exec:
command:
- string
- string
initialdelayseconds: int
timeoutseconds: int
periodseconds: int
successthreshold: int
failurethreshold: int
terminationgraceperiodseconds: optional[int]
useractions:
files:
- source: string
target: string
registry:
currentcontrolset:
- path: string
software:
- path: string
workloads:
sites:
site:
- applications:
- applicationpool: string
path: string
virtualdirectories:
- path: string
physicalpath: string
bindings:
- port: int
protocol: string
sslflags: int
connectionstrings:
- connectionstring: string
name: string
providername: string
name: string
security:
authentication:
windowsAuthentication:
enabled: bool
providers:
- value: string
authorization:
add:
- access_type: string
roles: string
users: string
verbs: string
remove:
- roles: string
users: string
verbs: string
serverautostart: bool
version: string
La section globalSettings
La section globalSettings décrit les exigences de base pour les pods exécutant des sites IIS à partir de cette VM. Le processus de découverte recherche les configurations générales dans la VM source et les utilise pour renseigner cette section. Ces configurations contiennent des champs présents dans les configurations d'image spécifiques, comme décrit dans la section suivante, et affectent toutes les images en même temps.
La section image
La section image, qui fait suite à globalSettings, contient la liste des fonctionnalités Windows à installer sur les pods. Le processus de découverte remplit cette section avec toutes les fonctionnalités Windows qui existent sur la VM d'origine et peuvent être installées sur un conteneur Windows.
La section msvcRuntimes
Lors de la migration d'une application, il peut dépendre d'une ou de plusieurs versions spécifiques de Microsoft Visual C++ Runtime (MSVCRT). Migrate to Containers détecte automatiquement les environnements d'exécution installés sur la VM source et les a inclus dans le plan de migration.
Vous pouvez modifier la liste des environnements d'exécution dans le plan de migration en ajoutant ou en supprimant des membres de msvcRuntimes:
La liste complète des valeurs possibles est la suivante : (L'environnement d'exécution 2015 inclut également la compatibilité avec 2017, 2019 et 2022.)
msvcRuntimes:
- MSVC2012_x64
- MSVC2013_x64
- MSVC2015_x64
- MSVC2012_x86
- MSVC2013_x86
- MSVC2015_x86
La section pathEnvVarAdditionalEntries
Les applications Windows IIS peuvent inclure des entrées de variable d'environnement PATH qui ne sont pas par défaut, qui sont automatiquement détectées sur la VM source et incluses dans le plan de migration. Vous pouvez modifier les variables d'environnement PATH en modifiant les membres de pathEnvVarAdditionalEntries :
pathEnvVarAdditionalEntries:
- "C:\\myDllsFolder"
- "C:\\ProgramData\\SomeSoftware"
Modifier la section "Image"
Vous pouvez modifier la section image dans les cas suivants :
Certaines fonctionnalités suggérées ne sont pas requises par les sites migrés. Cela peut se produire si la VM source cible des usages autres que l'hébergement de sites IIS.
Vous avez modifié les sections d'IIS dans le plan de migration et ajouté des configurations qui dépendent de fonctionnalités Windows supplémentaires (par exemple, l'authentification Windows dépend de la fonctionnalité d'authentification Windows).
La section target
La section target spécifie l'image Windows de base que vous utilisez (par exemple 1909). Il est rare que vous ayez besoin de modifier ce champ.
La section images
Chaque sous-élément de la section images spécifie une seule image de sortie.
Dans le fichier ZIP des artefacts, chaque image possède un sous-répertoire distinct, avec ses propres fichiers Dockerfile et deployment_spec.yaml (consultez la section Déployer l'image du conteneur).
Le champ name
Le champ name décrit le nom de l'image.
Il affecte le nom du sous-répertoire de l'image et le fichier deployment_spec.yaml dans les artefacts.
Le champ probes
Le champ probes décrit la configuration de la vérification d'état de l'image. Pour en savoir plus sur les vérifications de kubelet, consultez la section Configurer des vérifications d'activité, d'aptitude et de démarrage.
Modifier les vérifications d'état IIS
Les vérifications d'état peuvent surveiller l'état d'arrêt et l'état de préparation de vos conteneurs gérés. La surveillance de l'état peut réduire les temps d'arrêt des conteneurs migrés et améliorer la surveillance.
Des états de santé inconnus peuvent entraîner une dégradation des disponibilités, une surveillance des disponibilités suggérant un faux positif et une perte potentielle de données. Sans vérification d'état, kubelet ne peut supposer que l'état d'un conteneur et peut envoyer du trafic vers une instance de conteneur qui n'est pas prête. Si l'instance n'est pas prête, vous risquez de perdre du trafic. Kubelet peut également ne pas détecter les conteneurs dans un état figé et ne pas les redémarrer.
Une vérification de l'état fonctionne en exécutant une petite instruction scriptée au démarrage du conteneur. Le script recherche les conditions de réussite, qui sont définies par le type de vérification utilisé, à chaque période. La période est définie dans le plan de migration par un champ periodSeconds. Vous pouvez définir ces vérifications manuellement lorsque vous personnalisez le plan de migration.
Vous avez le choix entre trois types de vérifications. Toutes reposent sur la vérification probe v1 core, définie dans la documentation de référence sur probe v1 core, et partagent la même fonction que les champs correspondants de container v1 core.
Vérification d'activité : les vérifications d'activité permettent de savoir quand redémarrer un conteneur.
Vérification d'aptitude : les vérifications d'aptitude permettent de savoir quand un conteneur est prêt à accepter du trafic. Pour commencer à envoyer du trafic à un pod uniquement lorsqu'une vérification réussit, spécifiez une vérification d'aptitude. Une vérification d'aptitude peut agir de la même manière qu'une vérification d'activité. Cependant, une vérification d'aptitude indique qu'un pod démarre sans recevoir de trafic et ne commence à recevoir du trafic qu'une fois la vérification réussie.
Vérification de démarrage : le kubelet utilise des vérifications de démarrage pour savoir quand une application de conteneur a démarré. Si une telle vérification est configurée, elle désactive les vérifications d'activité et d'aptitude jusqu'à ce qu'elle aboutisse, en s'assurant que ces vérifications n'interfèrent pas avec le démarrage de l'application.
Une fois la détection effectuée, la configuration de la vérification est ajoutée au plan de migration. Les vérifications peuvent être utilisées dans leur configuration par défaut, comme indiqué dans l'exemple suivant. La configuration par défaut utilise la commande exec pour les vérifications d'activité et d'aptitude. Toutes deux utilisent un script PowerShell appelé probe.ps1, qui appelle l'outil de ligne de commande IIS appcmd pour vérifier l'état des sites IIS.
Les vérifications sont désactivées par défaut. Pour les activer, définissez l'option enabled sur true.
images: name: IMAGE_NAME probes: enabled: false livenessProbe: probehandler: exec: command: - powershell.exe - C:\m4a\probe.ps1 initialdelayseconds: 0 timeoutseconds: 1 periodseconds: 10 successthreshold: 1 failurethreshold: 3 terminationgraceperiodseconds: null readinessProbe: probehandler: exec: command: - powershell.exe - C:\m4a\probe.ps1 initialdelayseconds: 0 timeoutseconds: 1 periodseconds: 10 successthreshold: 1 failurethreshold: 3 terminationgraceperiodseconds: null
La section windowsServices
Les conteneurs Windows créés lors d'une migration exécutent et surveillent un seul service Windows IIS. Toutefois, certaines charges de travail peuvent nécessiter l'exécution de services supplémentaires pour fonctionner correctement (y compris une base de données, un mécanisme de journalisation, un proxy, etc.).
Pour exécuter des services supplémentaires dans le conteneur migré, ajoutez des entrées à la section windowsServices et copiez les binaires nécessaires dans la section useractions.
version: v1
globalSettings:
target:
…
globalIIS:
…
images:
- name: migrated-image-zgwb2
workloads:
sites:
site:
- applications:
...
bindings:
- port: 80
protocol: http
name: Default Web Site
…
windowsServices:
- MyService
useractions:
files:
- source: C:\Program Files\MyService
target: C:\Program Files\MyService
registry:
currentcontrolset:
- key: services\MyService
La section useractions
La section useractions spécifie les fichiers et clés de registre supplémentaires que vous souhaitez migrer.
Exemple :
useractions: files: - source: DRIVE:\FOLDER-OR-FILE-PATH target: DRIVE:\FOLDER-OR-FILE-PATH - source: C:\myfolder target: C:\myfolder - source: D:\myfile target: D:\myfile - source: D:\myfile target: C:\myfile ... registry: currentcontrolset: - path: KEY ... software: - path: KEY ...
Les chemins d'accès spécifiés pour currentcontrolset et software correspondent à des clés dans le registre Hive HKEY_LOCAL_MACHINE\System\CurrentControlSet ou HKEY_LOCAL_MACHINE\Software.
Modifier la section useractions
Par défaut, les seuls fichiers copiés dans l'image sont les répertoires virtuels de sites dans l'image spécifiée.
Si votre code ou vos configurations importent des fichiers depuis l'extérieur de ce répertoire, vous devez les ajouter à la section useractions.
De plus, toutes les valeurs de registre dont dépend votre code doivent être ajoutées en modifiant la section useractions registry.
Paramètres spécifiques au serveur IIS
Les paramètres liés à IIS sont divisés en paramètres liés à des sites spécifiques, qui font partie de la spécification de l'image, et en paramètres liés à tous les sites, qui sont placés à la suite de la section gloabalIis.
La section sites
La section sites décrit les sites qui sont migrés vers une image spécifique. Il est possible que plusieurs images contiennent le même site.
Si vous souhaitez utiliser Cloud Load Balancing, Ingress ou Cloud Service Mesh pour gérer la configuration SSL, vous devez définir protocol sur http :
sites: site: - applications: - path: / virtualdirectories: - path: / physicalpath: '%SystemDrive%\inetpub\wwwroot' bindings: - port: 8080 protocol: http name: Default Web Site
La section apppools
La section apppools décrit les pools d'applications créés sur les pods migrés.
Le champ identitytype spécifie l'identité IIS d'un pool d'applications en tant que ApplicationPoolIdentity (valeur par défaut), NetworkService, LocalSystem ou LocalService.
Pour en savoir plus, consultez les pages Comprendre les identités dans IIS et Identités du pool d'applications.
Voici un exemple de plan de migration contenant les propriétés identitytype :
migrationPlan: applications: iis: applicationhost: apppools: - name: DefaultAppPool # Allowed values include: ApplicationPoolIdentity (default), NetworkService, LocalSystem, LocalService identitytype="NetworkService" - managedruntimeversion: v4.0 name: .NET v4.5 Classic - managedruntimeversion: v4.0 name: .NET v4.5
Lorsque vous exécutez le plan de migration pour générer les artefacts de conteneur, Migrate to Containers ajoute automatiquement les instructions Dockerfile nécessaires en fonction du paramètre de champ identitytype.
Par exemple, si vous définissez identitytype sur NetworkService, l'instruction se présente sous la forme suivante :
RUN c:\windows\system32\inetsrv\appcmd.exe set apppool \"DefaultAppPool\" \"/-processModel.identityType:NetworkService\";Migrate to Containers ajoute automatiquement des instructions de lecture de LCA aux dossiers du site en fonction du type identitytype de la cible et pour le compte utilisateur intégré IUSR.
Cela est effectué automatiquement pour les éléments du système de fichiers d'application dans lesquels le compte d'application d'origine a été spécifié soit explicitement, soit par héritage.
Pour en savoir plus, consultez la section Configurer des listes de contrôle d'accès.
Le champ enablegmsa
Le champ enablegmsa joue le rôle de sucre syntaxique du plan de migration. Il s'agit d'un raccourci pour écraser le champ identity du pool d'applications.
Les valeurs acceptées pour le champ enablegmsa sont les suivantes:
auto(valeur par défaut) : convertit le conteneur migré pour utiliser un compte de service gMSA lorsque Migrate to Containers détermine que sa configuration actuelle n'est pas autorisée.all: convertit toujours le conteneur migré pour utiliser un compte de service gMSA et ignorer le paramètreidentitytype. Dans ce cas,identitytypeest toujours interprété commeNetworkService.
Voici un exemple de plan de migration contenant les propriétés enablegmsa :
migrationPlan: applications: iis: # Allowed values include: auto (default), all enablegmsa: auto|all
Pour en savoir plus, consultez Configurer votre application pour utiliser un compte de service gMSA.
Chaînes de connexion
Les chaînes de connexion définissent une connexion entre la charge de travail de conteneur migrée et un fournisseur de données du framework .NET.
Migrate to Containers accepte les chaînes de connexion au niveau du site et du champ d'application global.
Pour ajouter une chaîne de connexion à un site, modifiez la définition de site dans le plan de migration pour définir la propriété connectionstrings:
sites: site: # Add the site connection strings here. connectionstrings: - name: connectionname1 providername: System.Data.SqlClient connectionstring: Database=connectedDB1;Password=Welcome1;User=admin; - name: connectionname2 providername: System.Data.OleDb connectionstring: Database=connectedDB2;Password=Welcome2;User=admin; - applications: - path: / virtualdirectories: ...
Pour ajouter une chaîne de connexion au niveau global (la rendant accessible à tous les sites), modifiez les chaînes de connexion placées directement à la suite de globalIis :
globalIis: enablegmsa: auto connectionStrings: connectionstring: - name: connectionname3 providername: System.Data.SqlClient connectionstring: Database=connectedDB3;Password=Welcome3;User=admin; applicationhost: ...
Où :
namespécifie le nom de la connexion.providernamespécifie éventuellement le type de fournisseur de données. Migrate to Containers n'accepte que la valeurSystem.Data.SqlClient. est compatible avec le fournisseur de données .NET Framework :System.Data.SqlClientSystem.Data.OleDbSystem.Data.OdbcSystem.Data.OracleClient
connectionstringspécifie les chaînes de connexion utilisées pour se connecter au fournisseur de données.
Modifier les sections des chaînes de connexion
Migrate to Containers copie automatiquement les chaînes de connexion détectées dans la VM migrée vers le plan de migration.
Certaines chaînes de connexion peuvent ne pas être détectées et doivent être ajoutées en modifiant le plan de migration comme indiqué ci-dessus (à savoir, si les chaînes de connexion se trouvent dans une section cryptée du fichier applicationhost.config).
Pour savoir comment déterminer les chaînes de connexion à ajouter à votre plan de migration, consultez la section Extraction de chaînes de connexion au moment de l'exécution dans la documentation Microsoft.
Dépendances externes de chaîne de connexion
- Les chaînes de connexion peuvent contenir des dépendances, telles qu'une référence à un fichier sur le site, ou à un utilisateur Windows associé au site. Vous pouvez ajouter au plan de migration des actions utilisateur personnalisées pour copier un fichier supplémentaire dans le système de fichiers. Modifiez manuellement le Dockerfile pour ajouter un utilisateur Windows.
- Les chaînes de connexion peuvent contenir des dépendances, telles qu'une référence à une source de données externe. Ces dépendances doivent être migrées manuellement pour vous assurer que la charge de travail du conteneur migré a bien accès à la source de données.
La section security
Les sections security contiennent les sous-sections relatives à l'authentification et à l'autorisation.
- L'authentification Windows valide les utilisateurs Active Directory.
- L'autorisation Windows est le mécanisme qui permet de spécifier les utilisateurs autorisés à accéder à un site Web IIS en fonction du type d'accès. Les types d'accès sont les verbes HTTP (POST, GET, PUT, PATCH, DELETE).
Comme pour les chaînes de connexion, pour définir l'autorisation ou l'authentification pour tous les sites, modifiez globalIis comme dans l'exemple suivant. Pour définir l'autorisation ou l'authentification pour un site spécifique, modifiez l'élément de site.
globalIis: security: authentication: windowsAuthentication: providers: - NTLM authorization: - add: user:John access: role: - remove: user:Jane access: GET role: ...
Où :
providersspécifie le fournisseur de vos protocoles de sécurité ;usercorrespond au nom d'utilisateur ;accessindique les autorisations de l'utilisateur. Les types d'accès sont les verbes HTTP (POST, GET, PUT, PATCH, DELETE) ;rolecorrespond à un rôle d'autorisation spécifique.
Étapes suivantes
- Découvrez comment exécuter la migration.