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 :

  1. 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.

  2. 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.

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ètre identitytype. Dans ce cas, identitytype est toujours interprété comme NetworkService.

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ù :

  • name spécifie le nom de la connexion.
  • providername spécifie éventuellement le type de fournisseur de données. Migrate to Containers n'accepte que la valeur System.Data.SqlClient. est compatible avec le fournisseur de données .NET Framework :
    • System.Data.SqlClient
    • System.Data.OleDb
    • System.Data.Odbc
    • System.Data.OracleClient
  • connectionstring spé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ù :

  • providers spécifie le fournisseur de vos protocoles de sécurité ;
  • user correspond au nom d'utilisateur ;
  • access indique les autorisations de l'utilisateur. Les types d'accès sont les verbes HTTP (POST, GET, PUT, PATCH, DELETE) ;
  • role correspond à un rôle d'autorisation spécifique.

Étapes suivantes