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

Cet article suppose que vous avez déjà créé une 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. Dans les sections suivantes, nous aborderons cette structure, expliquerons chaque partie et 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:
        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

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.

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.

msvcRuntimes

Les applications Windows IIS peuvent comporter des installations de versions d'environnement d'exécution Microsoft Visual C++. Ces environnements d'exécution sont automatiquement détectés sur la VM source et inclus dans le plan de migration. Vous pouvez modifier la liste des environnements d'exécution dans le plan de migration en modifiant les membres de msvcRuntimes :

    msvcRuntimes:
        - MSVC2012_x64
        - MSVC2013_x64
        - MSVC2015_x64
        - MSVC2012_x86
        - MSVC2013_x86
        - MSVC2015_x86

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

certaines fonctionnalités suggérées ne sont pas requises par les sites migrés (ce qui 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).

target

La section cible indique l'image Windows de base qui est utilisée (par exemple, 1909). Ce champ a rarement besoin d'être modifié.

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

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.

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 du kubelet, consultez la section Configurer des vérifications d'activité, d'aptitude et de démarrage dans la documentation de Kubernetes.

Modifier les vérifications d'état IIS

Les vérifications d'état peuvent surveiller le temps 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 les redémarrera pas.

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 lors de la personnalisation du 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.

Pour désactiver les vérifications, supprimez la section probes du fichier yaml.

images:
name: IMAGE_NAME
      probes:
        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

useractions

useractions spécifie des fichiers et des clés de registre supplémentaires à migrer.

Exemple useractions -

      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 `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 aux actions utilisateur.
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.

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.

apppools

La section apppools décrit les pools d'applications créés sur les pods migrés.

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. Pour en savoir plus, consultez la section 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 fichier AppXGenerateArtifactsFlow, qui représente le plan de migration, afin de 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 de 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.

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

Rubriques avancées

Les sections suivantes traitent de sujets plus larges. Chacune peut nécessiter de modifier le plan de migration.

Configurer SSL

Il n'est pas facile d'extraire des certificats SSL d'une VM source. Il n'est pas non plus recommandé d'installer des certificats SSL et des clés privées dans une image Docker. Dans ce contexte, Migrate to Containers offre plusieurs façons de gérer SSL pour Windows.

Utiliser un certificat autosigné généré automatiquement

Par défaut, un conteneur Windows disposant d'une liaison HTTPS se voit attribuer un certificat autosigné qui est automatiquement généré lors de l'initialisation du conteneur Docker. Cette configuration vous permet de tester la charge de travail migrée, mais ne peut pas être utilisée dans un environnement de production. Le certificat est autosigné et regénéré à chaque nouvelle exécution du conteneur.

Recommandé : utiliser Cloud Load Balancing, Ingress ou Anthos Service Mesh

Vous pouvez personnaliser les liaisons du plan de migration pour utiliser le protocole HTTP. Utilisez ensuite Cloud Load Balancing, Ingress ou Anthos Service Mesh en tant qu'interface HTTPS pour sécuriser l'accès externe. Cette option vous permet de sécuriser la communication externe sans inclure de certificats au sein du cluster.

Pour personnaliser la liaison, modifiez la définition de site dans l'objet AppXGenerateArtifactsFlow qui représente la migration pour définir protocol sur http :

sites:
  site:
  - applications:
    - path: /
      virtualdirectories:
        - path: /
          physicalpath: '%SystemDrive%\inetpub\wwwroot'
          bindings:
          - port: 8080
            protocol: http
          name: Default Web Site

Vous pouvez ensuite transférer des requêtes depuis l'interface HTTPS vers le chemin HTTP et le port de la charge de travail Windows.

Stocker des certificats SSL en tant que secrets Kubernetes

Il est recommandé d'utiliser Cloud Load Balancing, Ingress ou Anthos Service Mesh en tant qu'interface HTTPS pour sécuriser l'accès externe. Cependant, vous pouvez également stocker des certificats SSL en tant que secrets Kubernetes et les installer lors de l'exécution dans le conteneur.

Pour utiliser des certificats SSL stockés en tant que secrets Kubernetes, vous devez modifier l'image de déploiement du conteneur. Pour en savoir plus, consultez la page Déployer une charge de travail Windows sur un cluster cible.

Configurer des charges de travail migrées pour utiliser un compte de service gMSA

Les charges de travail d'application Windows IIS sont souvent associées à Active Directory (AD) et fonctionnent à l'aide d'identités de domaine. Lorsque vous migrez ces VM vers des conteneurs, les conteneurs eux-mêmes ne sont pas joints au domaine, mais leurs nœuds de cluster Kubernetes hôtes peuvent être associés à un domaine.

Lorsque vous déployez vos conteneurs migrés sur un cluster, vous pouvez utiliser un compte de service géré de groupe (gMSA). Utilisez ce compte de service gMSA pour exécuter le conteneur sous une identité de compte de service spécifique. Vous associez un compte de service gMSA dans un cluster Kubernetes dans le cadre de la configuration du pod plutôt qu'en tant que configuration d'identité statique dans l'image du conteneur.

Pour pouvoir utiliser un compte de service gMSA dans un conteneur Windows migré, vous devez effectuer les tâches suivantes :

Modifier le plan de migration pour définir les propriétés nécessaires à la configuration du conteneur migré pour qu'il utilise un compte de service gMSA. Ce processus de configuration est décrit dans la section suivante.
Pour pouvoir utiliser un compte de service gMSA, configurez le cluster de traitement qui héberge le conteneur déployé. Pour en savoir plus, consultez la page Déployer une charge de travail Windows sur un cluster cible.

À propos du compte de service gMSA

Vous trouverez plus d'informations sur le compte de service gMSA dans la documentation Google Cloud et dans d'autres documentations. Par exemple, consultez les articles suivants :

Configurer Active Directory pour permettre aux VM de s'associer automatiquement à un domaine dans la documentation de Google Cloud.
Utiliser un compte de service géré de groupe dans la documentation Google Cloud.
Configure your app to use a gMSA (Configurer votre application pour utiliser un compte de service administré de groupe) dans la documentation Microsoft.
Créer un compte de service gMSA et configurer le pod pour l'utiliser dans la documentation de Kubernetes.

Permettre l'utilisation de gMSA dans Migrate to Containers

Lorsque vous migrez des charges de travail depuis des VM vers des conteneurs Windows, vous devez transformer la configuration de l'application IIS et des autres services Windows configurés pour utiliser des identités AD. Cette transformation est nécessaire pour chaque VM source Windows.

Migrate to Containers vous aide à transformer vos charges de travail. Il détecte automatiquement la configuration des pools d'applications IIS et ajoute des recommandations au plan de migration généré. Vous pouvez ensuite évaluer ces recommandations et les modifier en fonction de votre environnement et de vos exigences spécifiques.

Si Migrate to Containers détermine que la configuration d'un pool d'applications ne nécessite pas de compte de service gMSA, il conserve la configuration d'origine du pool d'applications. C'est le cas, par exemple, lorsqu'un type de compte intégré, tel que "ApplicationPoolIdentity", "NetworkService", "LocalSystem" ou "LocalService" est utilisé.

Configurer un compte de service gMSA

Migrate to Containers ajoute les propriétés suivantes, avec les valeurs recommandées, au plan de migration généré. Vous pouvez ensuite les modifier en fonction de vos besoins afin de contrôler le compte de service gMSA :

enablegmsa : valeurs autorisées :
- 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.
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 Understanding identities in IIS (Présentation des identités dans IIS) et Application Pool Identities (Identités de pool d'applications).

En règle générale, un conteneur ne peut se voir attribuer qu'un seul compte de service gMSA, ce qui signifie que pour pouvoir utiliser l'identité gMSA, vous devez généralement définir identitytype sur NetworkService. Pour en savoir plus, consultez Configure your app to use a gMSA (Configurer votre application pour utiliser un compte de service administré de groupe).

Voici un exemple de plan de migration contenant les propriétés enablegmsa et identitytype :

migrationPlan:
    applications:
      iis:
        # Allowed values include: auto (default), all
        enablegmsa: auto|all
        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

Générer des artefacts pour un compte de service gMSA

Lorsque vous exécutez le plan de migration pour générer les artefacts de conteneur, Migrate to Containers ajoute automatiquement les directives Dockerfile nécessaires pour attribuer le compte NetworkService. Pour en savoir plus, consultez Configurer votre application pour utiliser un compte de service gMSA.

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 sur la configuration des LCA, consultez la section Configurer des listes de contrôle d'accès.

Enregistrement du fichier DLL de l'objet COM

Depuis la version 1.13.0, les fichiers DLL qui exposent des objets COM sont automatiquement analysés et enregistrés. Au cours de la phase d'extraction, tous les fichiers copiés sont analysés afin d'identifier les DLL enregistrées en tant qu'objets COM, qui sont ensuite enregistrés dans le conteneur.

Ce processus se déroule sans entrée utilisateur. Toutefois, vous pouvez influencer ce processus en ajoutant des fichiers DLL à copier. Si nécessaire, ces DLL sont vérifiées à tour de rôle et enregistrées.

Surveillance des services Windows

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:\MyProcess
          target: C:\MyProcess

Étapes suivantes

Linux

Migrer à l'aide de Google Cloud

Déploiement

Examiner les artefacts générés.
Configurer la journalisation.
Installer des volumes externes.
Déployer une charge de travail sur un cluster cible.
Déployer des VM migrées.
Mettre à jour des images post-migration
Surveiller la charge de travail migrée.
Testez votre application à migrer et validez la migration.

Personnaliser le plan de migration pour les services IIS Windows

Avant de commencer

Structure du plan de migration

globalSettings

image

msvcRuntimes

pathEnvVarAdditionalEntries

Modifier la section "Image"

target

images

name

probes

Modifier les vérifications d'état IIS

useractions

Modifier useractions

Paramètres spécifiques au serveur IIS

sites

apppools

enablegmsa

Chaînes de connexion

Modifier les sections des chaînes de connexion

Dépendances externes de chaîne de connexion

security

Rubriques avancées

Configurer SSL

Utiliser un certificat autosigné généré automatiquement

Recommandé : utiliser Cloud Load Balancing, Ingress ou Anthos Service Mesh

Stocker des certificats SSL en tant que secrets Kubernetes

Configurer des charges de travail migrées pour utiliser un compte de service gMSA

À propos du compte de service gMSA

Permettre l'utilisation de gMSA dans Migrate to Containers

Configurer un compte de service gMSA

Générer des artefacts pour un compte de service gMSA

Enregistrement du fichier DLL de l'objet COM

Surveillance des services Windows

Étapes suivantes

Linux

Migrer à l'aide de Google Cloud

Déploiement

Windows

Migrer à l'aide de Google Cloud

Déployer

Tomcat

Migrer à l'aide d'un ordinateur local

Migrer à l'aide de Google Cloud

Déployer

WebSphere

Migrer à l'aide d'un ordinateur local

Migrer à l'aide de Google Cloud

Déployer

JBoss

Migrer à l'aide d'un ordinateur local

Migrer à l'aide de Google Cloud

Déployer

Apache

Migrer à l'aide d'un ordinateur local

Migrer à l'aide de Google Cloud

Déployer

WordPress

Migrer à l'aide de Google Cloud

Déployer

Modifier `useractions`