Préparer un cluster Windows pour le déploiement

Cette page présente certains scénarios pouvant vous obliger à personnaliser les artefacts de migration.

Avant de commencer

Ce document suppose que vous avez effectué la migration.

Vérifier que le cluster cible dispose d'un accès en lecture au registre Docker

Dans le cadre d'une migration, Migrate to Containers importe des images Docker représentant une VM migrée dans un registre Docker. Ces images Docker représentent les fichiers et répertoires de la VM en cours de migration.

Pour le registre Docker, vous pouvez choisir d'utiliser :

• Container Registry

• Tout registre Docker compatible avec l'authentification de base

Pour en savoir plus, consultez la page Définir des dépôts de données.

Déployer une charge de travail dans un projet Google Cloud autre que celui utilisé pour la migration

Il s'agit souvent de plusieurs projets Google Cloud dans votre environnement. Si vous effectuez une migration dans un projet Google Cloud, puis que vous souhaitez déployer la charge de travail migrée vers un cluster d'un autre projet, vous devez vous assurer que les autorisations sont correctement configurées.

Par exemple, vous effectuez la migration dans le projet A. Dans ce cas, la charge de travail migrée est copiée dans un bucket Container Registry du projet A. Exemple :

gcr.io/project-a/image_name:image_tag

Vous souhaitez ensuite déployer la charge de travail sur un cluster du projet B. Si vous ne configurez pas les autorisations correctement, le pod de la charge de travail ne parvient pas à s'exécuter, car le cluster du projet B ne dispose pas d'un accès en extraction d'images au projet A. Vous verrez ensuite un événement sur le pod contenant un message sous la forme suivante :

Failed to pull image "gcr.io/project-a/image_name:image_tag...
pull access denied...
repository does not exist or may acquire 'docker login'...

Tous les projets qui ont activé l'API Compute Engine disposent d'un compte de service par défaut Compute Engine, qui possède l'adresse e-mail suivante :

[e-mail]

Où PROJECT_NUMBER est le numéro du projet B.

Pour contourner ce problème, assurez-vous que le compte de service par défaut Compute Engine du projet B dispose des autorisations nécessaires pour accéder au bucket Container Registry. Par exemple, vous pouvez utiliser la commande gsutil suivante pour activer l'accès :

gsutil iam ch serviceAccount:[e-mail]:objectViewer gs://artifacts.project-a.appspot.com

Déployer des charges de travail sur le cluster de traitement

Important : L'interface utilisateur Migrate to Containers dans la console Google Cloud, migctl, et les CRD utilisant des clusters de traitement pour migrer des charges de travail vers Google Cloud sont désormais obsolètes. Ils sont pris en charge pour les utilisateurs existants jusqu'en mai 2024, après quoi ils ne seront plus disponibles.

Vous pouvez déployer la charge de travail migrée sur le cluster utilisé pour effectuer la migration, appelé cluster de traitement Migrate to Containers. Dans la plupart des situations, aucune configuration supplémentaire n'est requise sur le cluster de traitement, car il dispose déjà d'un accès en lecture ou en écriture au registre Docker pour effectuer la migration.

Déployer sur un cluster cible en utilisant Container Registry en tant que registre Docker

Pour vous assurer qu'un cluster cible a accès à Container Registry, créez un secret Kubernetes contenant les identifiants requis pour accéder à Container Registry :

1. Créez un compte de service pour déployer une migration, comme décrit dans la section Créer un compte de service pour accéder à Container Registry et à Cloud Storage.

   Ce processus vous permet de télécharger un fichier de clé JSON nommé m4a-install.json.

2. Créez un secret Kubernetes contenant les identifiants requis pour accéder à Container Registry :

   kubectl create secret docker-registry gcr-json-key \
    --docker-server=gcr.io --docker-username=_json_key --docker-password="$(cat ~/m4a-install.json.json)" \
    --docker-email=[e-mail]

   où :

   • docker-registry spécifie le nom du secret Kubernetes, gcr-json-key dans cet exemple.
   • docker-server=gcr.io spécifie Container Registry comme serveur.
   • docker-username=_json_key indique que le nom d'utilisateur est contenu dans le fichier de clé JSON.
   • docker-password indique d'utiliser un mot de passe du fichier de clé JSON.
   • docker-email spécifie l'adresse e-mail du compte de service.

3. Définissez le secret Kubernetes de l'une des manières suivantes :

   • Modifiez la valeur imagePullSecrets par défaut :

     kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "gcr-json-key"}]}'

   • Modifiez le fichier deployment_spec.yaml pour ajouter la valeur imagePullSecrets à la définition spec.template.spec. Lorsque vous utilisez WebSphere traditionnel, le fichier yaml de déploiement est nommé twas_deployment_spec.yaml, liberty_deployment_spec.yaml ou openliberty_deployment_spec.yaml, selon votre cible.

     spec:
       containers:
       - image: gcr.io/PROJECT_ID/mycontainer-instance:v1.0.0
         name: mycontainer-instance
         ...
       volumes:
       - hostPath:
           path: /sys/fs/cgroup
           type: Directory
         name: cgroups
       imagePullSecrets:
       - name: gcr-json-key

     Remplacez PROJECT_ID par l'ID du projet.

4. Déployez le secret de la charge de travail, si secrets.yaml existe. Un fichier de secrets existe pour les charges de travail basées sur Tomcat et les charges de travail basées sur WebSphere traditionnel avec Liberty. Le fichier Liberty est nommé liberty-secrets.yaml.

   kubectl apply -f secrets.yaml

Déployer sur un cluster cible en utilisant un registre Docker avec une authentification de base

Si vous utilisez un registre Docker pour stocker des images de migration, celui-ci doit être compatible avec l'authentification de base à l'aide d'un nom d'utilisateur et d'un mot de passe. Dans la mesure où il existe de nombreuses manières de configurer une connexion en lecture seule à un registre Docker, vous devez utiliser la méthode appropriée pour votre plate-forme de cluster et votre registre Docker.

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.

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

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

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

2. Configurez le cluster cible qui héberge le conteneur déployé.

Configurer un cluster de traitement compatible avec l'utilisation d'un compte de service gMSA

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 configurer un cluster hébergeant le conteneur Windows migré de sorte qu'il soit compatible avec l'utilisation d'un compte de service gMSA, vous devez avoir :

1. configuré Active Directory pour permettre aux VM de s'associer automatiquement à un domaine ;

2. configuré un compte de service gMSA pour les pods et les conteneurs Windows.

Remarque : Active Directory limite les noms d'ordinateurs à 15 caractères, ce qui peut entraîner un conflit de noms avec vos nœuds. Pour en savoir plus et connaître les solutions de contournement, consultez l'article Utiliser un compte de service gMSA.

Pour en savoir plus, consultez les ressources suivantes :

• Créer des comptes de service gMSA pour les conteneurs Windows
• Créer un compte de service géré de groupe
• 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.

Déployer un conteneur lors du stockage de certificats SSL sous forme de secrets Kubernetes

Nous vous recommandons d'utiliser Cloud Load Balancing ,Ingress ou Anthos Service Mesh en tant qu'interface HTTPS pour sécuriser l'accès externe à votre conteneur déployé. Cette option vous permet de sécuriser la communication externe sans inclure de certificats au sein du cluster. Pour en savoir plus, consultez la section Personnaliser un plan de migration.

Vous pouvez également stocker des certificats SSL (Secure Sockets Layer) en tant que secrets Kubernetes et les installer lors de l'exécution dans le conteneur.

Attention: Nous vous déconseillons de stocker les certificats SSL en tant que secrets Kubernetes, car cela peut entraîner des problèmes de sécurité.

Pour utiliser les secrets Kubernetes, procédez comme suit :

1. Créez un fichier PFX en incluant le certificat et le mot de passe.

2. Créez un fichier YAML de configuration qui définit l'accès au site :

   sites:
    - sitename: "sitename"
      sslport: 443
      pfxpath: c:\sslconfig\pfx
      password: "password"
      thumbprint: "3e858d0551fc0536f52d411dad92b680a4fad4da"

   Où :

   • sitename indique le nom du site configuré pour utiliser SSL. La propriété sites peut contenir plusieurs entrées sitename.

   • sslport spécifie le port d'écoute des connexions SSL (généralement 443).

   • pfxpath spécifie le chemin d'accès au fichier PFX. Configurez-le dans le cadre du déploiement volumeMounts du pod.

   • password spécifie le mot de passe du fichier PFX.

   • thumbprint spécifie l'empreinte SHA1 du fichier PFX qui peut être récupérée à l'aide de la commande PowerShell :

     Get-PfxCertificate -FilePath "path to pfx"

     Vous pouvez également l'afficher dans le gestionnaire de certificats Windows.

3. Créez le secret Kubernetes :

   kubectl create secret generic secret-name --from-file=pfx=path-to-pfx --from-file=config=path-to-config

4. Créez le volume et l'installation de volume dans le déploiement de l'image :

   apiVersion: v1
   kind: Pod
   metadata:
    name: iis-pod
    labels:
      app: iis-server-simple
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      containers:
      - name: iis-server
        image: your-image-url
        volumeMounts:
        - name: ssl-secret
          mountPath: c:\sslconfig
        env:
        - name: M4A_CERT_YAML
          value: c:\sslconfig\config
      volumes:
      - name: ssl-secret
        secret:
          secretName: secret-name

   Où :

   • mountPath est le même chemin que celui spécifié par pfxpath dans le fichier de configuration que vous avez créé à l'étape 2.
   • M4A_CERT_YAML est une variable d'environnement définie sur le chemin d'accès complet au fichier YAML de configuration que vous avez créé à l'étape 2.
   • secret-name correspond au nom du secret que vous avez créé à l'étape 3.

des certificats SSL.

Il est recommandé de ne pas stocker de clés privées de certificats SSL dans une image de conteneur, car elles sont accessibles à toute personne qui lit l'image. Migrate to Containers fournit plusieurs méthodes de gestion de 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 le plan de migration 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
  

  Remarque : Seuls les protocoles HTTP et HTTPS sont autorisés pour le paramètre protocol. Tout protocole autre que HTTP/HTTPS est ignoré et ne sera pas traité.

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 plus d'informations, consultez la section Déployer un conteneur lors du stockage de certificats SSL sous forme de secrets Kubernetes.

Configurer la journalisation dans Cloud Logging

Migrate to Containers utilise l'outil LogMonitor pour extraire les journaux d'un conteneur Windows et les transférer vers votre cluster GKE. Ces journaux sont ensuite automatiquement transférés vers Cloud Logging, qui fournit une suite d'outils permettant de surveiller vos conteneurs.

Par défaut, Migrate to Containers active la journalisation IIS pour surveiller les journaux IIS, et transfère également les journaux d'événements d'application ou système à Cloud Logging.

Configurer la journalisation

L'expansion du fichier artifacts.zip généré crée plusieurs répertoires, dont le répertoire m4a. Le répertoire contient un dossier pour chaque image. Le répertoire m4a inclut le fichier LogMonitorConfig.json que vous pouvez modifier afin de contrôler la journalisation.

Pour en savoir plus sur la modification du fichier LogMonitorConfig.json, consultez la page Créer un fichier de configuration.

Définir les LCA

Certaines applications IIS nécessitent de définir des autorisations de listes de contrôle d'accès (LCA) spécifiques pour les fichiers et les dossiers afin que les applications fonctionnent correctement. Migrate to Containers analyse automatiquement toutes les applications IIS migrées et ajoute les autorisations spécifiques définies dans la VM source qui s'appliquent aux comptes IIS (le compte IUSR et le groupe IIS_IUSRS), puis les applique aux fichiers et répertoires copiés dans l'image de conteneur générée.

Étant donné que les images de conteneurs Windows ne permettent pas de définir des LCA dans le cadre de la commande Docker COPY, celles-ci sont définies dans un script appelé set_acls.bat. Migrate to Containers crée automatiquement set_acls.bat dans le répertoire de l'image générée pour votre application Windows spécifique. Migrate to Containers appelle ensuite set_acls.bat lorsque vous exécutez la commande docker build.

Modifiez set_acls.bat pour ajouter ou supprimer des autorisations personnalisées, ou modifier des autorisations qui ne sont pas liées à des utilisateurs IIS spécifiques et qui n'ont pas été détectées par Migrate to Containers.

Le script utilise l'outil intégré icacls de Windows pour définir les autorisations.

À propos du cache Global Assembly Cache .NET

Migrate to Containers analyse l'image source .NET du cache Global Assembly Cache (GAC) pour les ressources .NET installées sur la machine source et non disponibles dans les images officielles. Toute DLL détectée est copiée dans le contexte Docker et installée lors de la création de l'image cible par un script d'utilitaire install_gac.ps1.

Tous les assemblages .NET sont copiés dans le contexte Docker dans le répertoire m4a\gac. Pour supprimer les assemblages de l'image, supprimez-les du répertoire m4a\gac.

Enregistrement du fichier DLL de l'objet COM

Les DLL qui exposent des objets COM sont automatiquement analysées et enregistrées. 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 l'une après l'autre et enregistrées.

Remarque : Les objets COM .NET ne sont pas compatibles.

Étapes suivantes

• Découvrez comment créer et déployer des charges de travail Windows IIS.