Préparer un cluster Windows pour le déploiement

Cette page explique comment préparer votre cluster Windows pour le déploiement.

Avant de commencer

Choisir et configurer votre registre Docker

Lors de votre déploiement, vous créez et importez l'image Docker de votre conteneur dans un registre Docker.

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

  • Artifact Registry

  • Tout registre Docker compatible avec l'authentification de base

La solution recommandée consiste à utiliser Artifact Registry dans le même projet que le cluster de déploiement. GKE peut accéder au registre par défaut. Pour en savoir plus, consultez les exigences d'intégration à GKE.

Si vous souhaitez utiliser un registre Docker privé, découvrez comment le configurer.

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.

Pour en savoir plus, consultez les ressources suivantes :

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

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.

Configurer 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 Cloud Service Mesh

Vous pouvez personnaliser les liaisons du plan de migration pour utiliser le protocole HTTP. Utilisez ensuite Cloud Load Balancing, Ingress ou Cloud 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

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

Étapes suivantes