Windows-Cluster für die Bereitstellung vorbereiten

Auf dieser Seite wird beschrieben, wie Sie Ihren Windows-Cluster für die Bereitstellung vorbereiten.

Hinweise

Docker-Registry auswählen und einrichten

Im Rahmen der Bereitstellung erstellen Sie das Docker-Image Ihres Containers und laden es in eine Docker-Registry hoch.

Für die Docker-Registry können Sie Folgendes verwenden:

  • Artifact Registry

  • Jede Docker-Registry, die die Basisauthentifizierung unterstützt

Wir empfehlen, Artifact Registry im selben Projekt wie der Bereitstellungscluster zu verwenden. GKE kann standardmäßig auf die Registry zugreifen. Weitere Informationen finden Sie in den Anforderungen an die Einbindung in GKE.

Wenn Sie eine private Docker-Registry verwenden möchten, finden Sie hier Informationen zum Konfigurieren der Registry.

Migrierte Arbeitslasten für die Verwendung von gMSA konfigurieren

Windows-IIS-Anwendungsarbeitslasten sind häufig Active Directory (AD) und arbeiten mit Domainidentitäten. Wenn Sie diese VMs in Container migrieren, sind die Container selbst nicht Teil der Domain. Stattdessen können die Kubernetes-Hostclusterknoten in die Domain eingebunden werden.

Beim Bereitstellen der migrierten Container in einem Cluster können Sie ein gruppenverwaltetes Dienstkonto (Group Managed Service Account, gMSA) verwenden. Verwenden Sie gMSA, um den Container innerhalb einer bestimmten Dienstkontoidentität auszuführen. Sie fügen ein gMSA im Kubernetes-Cluster als Teil der Pod-Konfiguration und nicht als statische Identitätskonfiguration innerhalb des Container-Images hinzu.

Migrate to Containers unterstützt Sie beim Transformieren Ihrer Arbeitslasten. Migration to Containers erkennt die Konfiguration von IIS-Anwendungspools automatisch und fügt dem generierten Migrationsplan Empfehlungen hinzu. Sie können diese Empfehlungen dann auswerten und an Ihre Umgebung und Anforderungen anpassen.

Wenn Migrate to Containers feststellt, dass für die Konfiguration eines Anwendungspools kein gMSA erforderlich ist, wird die ursprüngliche Konfiguration des Anwendungspools beibehalten. Beispiel: Wenn ein vordefinierter Kontotyp wie ApplicationPoolIdentity, NetworkService, LocalSystem oder LocalService verwendet wird.

Damit ein gMSA in einem migrierten Windows-Container unterstützt werden kann, müssen Sie:

  1. den Migrationsplan bearbeiten, um die erforderlichen Attribute so zu konfigurieren, dass der migrierte Container ein gMSA verwendet.

  2. Den Zielcluster konfigurieren, der den bereitgestellten Container hostet.

Zielscluster für gMSA konfigurieren

Sie fügen ein gMSA im Kubernetes-Cluster als Teil der Pod-Konfiguration und nicht als statische Identitätskonfiguration innerhalb des Container-Images hinzu.

Um einen Cluster zu konfigurieren, der den migrierten Windows-Container zur Unterstützung von gMSA hostet, müssen Sie:

  1. Active Directory für VMs für den automatischen Domainbeitritt konfigurieren.

  2. gMSA für Windows-Pods und -Container konfigurieren.

Hier finden Sie weitere Informationen:

Container beim Speichern von SSL-Zertifikaten als Kubernetes-Secrets bereitstellen

Wir empfehlen, ein Cloud Load Balancing, Ingress oder Cloud Service Mesh als HTTPS-Front-End zum Schutz des externen Zugriffs auf den bereitgestellten Container zu verwenden. Mit dieser Option können Sie die externe Kommunikation sichern, ohne Zertifikate in den Cluster einzubeziehen. Weitere Informationen finden Sie unter Migrationsplan anpassen.

Sie können auch SSL-Zertifikate (Secure Sockets Layer) als Kubernetes-Secrets speichern und zur Laufzeit im Container bereitstellen.

So verwenden Sie Kubernetes-Secrets:

  1. Erstellen Sie eine PFX-Datei mit dem Zertifikat und dem Passwort.

  2. Erstellen Sie eine YAML-Konfigurationsdatei, die den Websitezugriff definiert:

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

    Dabei gilt:

    • sitename gibt den Namen der Website an, die zur Verwendung von SSL konfiguriert ist. Das Attribut sites kann mehrere sitename-Einträge enthalten.

    • sslport gibt den Port an, der auf SSL-Verbindungen überwacht werden soll (normalerweise 443).

    • pfxpath gibt den Pfad zur PFX-Datei an. Konfigurieren Sie ihn als Teil des volumeMounts-Deployments des Pods.

    • password gibt das Passwort für die PFX-Datei an.

    • thumbprint gibt den SHA1-Fingerabdruck der PFX-Datei an, die mit folgendem PowerShell-Befehl abgerufen werden kann:

      Get-PfxCertificate -FilePath "path to pfx"

      Alternativ können Sie sie im Windows-Zertifikat-Manager ansehen.

  3. Erstellen Sie das Kubernetes-Secret:

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

  4. Erstellen Sie das Volume und die Volume-Bereitstellung im Deployment des Images:

    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

    Dabei gilt:

    • mountPath ist der gleiche Pfad wie durch pfxpath in der Konfigurationsdatei angegeben, die Sie in Schritt 2 erstellt haben.
    • M4A_CERT_YAML ist eine Umgebungsvariable, für die der vollständige Pfad zur YAML-Konfigurationsdatei festgelegt ist, die Sie in Schritt 2 erstellt haben.
    • secret-name ist der Name des Secrets, das Sie in Schritt 3 erstellt haben.

SSL konfigurieren

Es wird empfohlen, die privaten Schlüssel von SSL-Zertifikaten nicht in einem Container-Image zu speichern, da sie für jeden zugänglich sind, der das Image liest. Migrate to Containers bietet mehrere Möglichkeiten für den Umgang mit SSL für Windows.

Selbst signiertes, automatisch erzeugtes Zertifikat verwenden

Standardmäßig wird einem Windows-Container mit einer HTTPS-Bindung ein selbst signiertes, automatisch generiertes Zertifikat zugewiesen, das bei der Initialisierung des Docker-Containers generiert wird. Diese Konfiguration können Sie zwar zum Testen Ihrer migrierten Arbeitslast verwenden, jedoch nicht in einer Produktionsumgebung. Das Zertifikat ist sowohl selbst signiert als auch bei jeder Ausführung des Containers neu generiert.

Empfohlen: Cloud Load Balancing, Ingress oder Cloud Service Mesh verwenden

Sie können die Bindungen im Migrationsplan zur Verwendung von HTTP anpassen. Verwenden Sie dann Cloud Load Balancing, Ingress oder Cloud Service Mesh als HTTPS-Frontend, um den externen Zugriff zu sichern. Mit dieser Option können Sie die externe Kommunikation sichern, ohne Zertifikate in den Cluster einzubeziehen.

  • Zum Anpassen der Bindung bearbeiten Sie die Definition site im Migrationsplan, die die Migration darstellt, um protocol auf http festzulegen:

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

Sie können dann Anfragen vom HTTPS-Frontend an den HTTP-Pfad und Port der Windows-Arbeitslast weiterleiten.

SSL-Zertifikate als Kubernetes-Secrets speichern

Die Verwendung von Cloud Load Balancing, Ingress oder Cloud Service Mesh als HTTPS-Frontend wird empfohlen, um den externen Zugriff zu sichern. Allerdings können Sie SSL-Zertifikate auch als Kubernetes-Secrets speichern und zur Laufzeit im Container bereitstellen.

Zum Verwenden von SSL-Zertifikaten, die als Kubernetes-Secrets gespeichert sind, müssen Sie das Deployment-Image des Containers bearbeiten. Weitere Informationen finden Sie unter Container beim Speichern von SSL-Zertifikaten als Kubernetes-Secrets bereitstellen.

Logging in Cloud Logging konfigurieren

Migrate to Containers verwendet das Tool LogMonitor, um Logs aus einem Windows-Container zu extrahieren und an den GKE-Cluster weiterzuleiten. Diese Logs werden dann automatisch an Cloud Logging weitergeleitet, das eine Reihe von Tools für das Monitoring Ihrer Container bietet.

Migrate to Containers aktiviert standardmäßig IIS-Logging für das Monitoring von IIS-Logs und leitet außerdem die Anwendungs-/Systemereignislogs an Cloud Logging weiter.

Logging konfigurieren

Durch das Maximieren der generierten artifacts.zip-Datei werden mehrere Verzeichnisse erstellt, darunter das Verzeichnis m4a. Das Verzeichnis enthält für jedes Image einen Ordner. Das Verzeichnis m4a enthält die Datei LogMonitorConfig.json, die Sie zum Steuern des Loggings bearbeiten können.

Weitere Informationen zum Bearbeiten von LogMonitorConfig.json finden Sie unter Konfigurationsdatei erstellen.

ACLs festlegen

Für einige IIS-Anwendungen müssen Sie bestimmte ACL-Berechtigungen (Access Control Lists) für Dateien und Ordner festlegen, damit die Anwendungen korrekt ausgeführt werden. Migrate to Containers scannt alle migrierten IIS-Anwendungen automatisch und fügt alle in der Quell-VM definierten Berechtigungen hinzu, die speziell für IIS-Konten (das Konto IUSR und die Gruppe IIS_IUSRS) gelten. Anschließend werden die Berechtigungen auf die kopierten Dateien und Verzeichnisse im generierten Container-Image angewendet.

Da Windows-Container-Images das Festlegen von ACLs im Rahmen des Docker-Befehls COPY nicht unterstützen, werden die ACLs in einem Script namens set_acls.bat festgelegt. Migrate for Container erstellt automatisch set_acls.bat im Verzeichnis des generierten Images für Ihre jeweilige Windows-Anwendung. Anschließend ruft Migrate to Containers set_acls.bat auf, wenn Sie den Befehl docker build ausführen.

Bearbeiten Sie set_acls.bat, um benutzerdefinierte Berechtigungen hinzuzufügen oder zu entfernen bzw. Berechtigungen zu bearbeiten, die sich nicht auf bestimmte IIS-Nutzer beziehen und daher von Migrate to Containers nicht erkannt wurden.

Das Skript verwendet das integrierte Windows-Tool icacls, um Berechtigungen festzulegen.

.NET Global Assembly Cache

Migrate to Containers scannt das Quell-Image ".NET Global Assembly Cache" (GAC) nach .NET-Ressourcen, die auf dem Quellcomputer installiert und nicht als Teil der offiziellen Images verfügbar sind. Jede erkannte DLL wird in den Docker-Kontext kopiert und im Rahmen des Ziel-Image-Builds durch ein Dienstprogrammskript namens install_gac.ps1 installiert.

Alle .NET-Assemblies werden in den Docker-Kontext unter das Verzeichnis m4a\gac kopiert. Wenn Sie Assemblies aus dem Image entfernen möchten, löschen Sie sie aus dem Verzeichnis m4a\gac.

DLL-Registrierung des COM-Objekts

DLLs, die COM-Objekte verfügbar machen, werden automatisch gescannt und registriert. Während der Extraktionsphase werden die kopierten Dateien auf DLLs gescannt, die als COM-Objekte registriert sind, die dann im Container registriert werden.

Dieser Vorgang erfolgt ohne Nutzereingabe. Sie können jedoch diesen Prozess beeinflussen, indem Sie weitere zu kopierende DLLs hinzufügen. Bei Bedarf werden diese DLLs wiederum geprüft und registriert.

Nächste Schritte

  • Informationen zum Erstellen und Bereitstellen von Windows-basierten Arbeitslasten.