Windows-Cluster für die Bereitstellung vorbereiten

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

Hinweis

Docker-Registry auswählen und einrichten

Im Rahmen der Bereitstellung erstellen Sie ein 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 beliebige Docker-Registry, die die Basisauthentifizierung unterstützt

Wir empfehlen, Artifact Registry zu verwenden, und zwar im selben Projekt wie den Bereitstellungscluster. Die GKE kann standardmäßig auf die Registry zugreifen. Weitere Informationen finden Sie in den Anforderungen für die Integration in die 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 Application-Arbeitslasten sind häufig in Active Directory (AD) eingebunden 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. Damit lässt sich der Container innerhalb einer bestimmten Dienstkontoidentität ausführen. Ein gMSA fügen Sie 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. Es 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. Das ist beispielsweise der Fall, wenn ein integrierter 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 als Host für den bereitgestellten Container verwendeten Zielcluster konfigurieren.

Zielcluster für gMSA konfigurieren

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

Damit ein Cluster, der den migrierten Windows-Container hostet, gMSA unterstützt, 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, Cloud Load Balancing, Ingress oder Cloud Service Mesh als HTTPS-Frontend 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 SSL-Zertifikate (Secure Sockets Layer) auch 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 SHA-1-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, die auf den vollständigen 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, private Schlüssel für SSL-Zertifikate 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 erzeugtes 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 selbst signiert und wird bei jeder Ausführung des Containers neu erzeugt.

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

Sie können die Bindungen im Migrationsplan anpassen, um HTTP zu verwenden. Nutzen Sie dann Cloud Load Balancing, Ingress oder Cloud Service Mesh als HTTPS-Frontend, um den externen Zugriff zu schützen. Mit dieser Option können Sie die externe Kommunikation schützen, 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 schützen. 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 von Containern bietet.

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

Logging konfigurieren

Durch das Maximieren der generierten artifacts.zip-Datei werden mehrere Verzeichnisse erstellt, darunter das Verzeichnis m4a. Es enthält für jedes Image einen Ordner. Das Verzeichnis m4a enthält auch die Datei LogMonitorConfig.json, die Sie bearbeiten können, um das Logging zu steuern.

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

ACLs festlegen

Für einige IIS-Anwendungen müssen Sie bestimmte Datei- und Ordnerberechtigungen für ACLs (Access Control Lists) 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 to Containers erstellt set_acls.bat automatisch im Verzeichnis des generierten Images für Ihre jeweilige Windows-Anwendung. Die Datei set_acls.bat wird aufgerufen, wenn Sie den Befehl docker build ausführen.

Sie können set_acls.bat bearbeiten und benutzerdefinierte Berechtigungen hinzufügen oder entfernen beziehungsweise Berechtigungen 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.

Informationen zu .NET Global Assembly Cache

Migrate to Containers scannt das Quell-Image .NET Global Assembly Cache (GAC) nach .NET-Ressourcen, die auf der Quellmaschine 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 Dienstprogrammscript 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 von COM-Objekten

DLLs, die COM-Objekte verfügbar machen, werden automatisch gescannt und registriert. Beim Extrahieren werden die kopierten Dateien auf DLLs gescannt, die als COM-Objekte registriert sind. Anschließend werden diese im Container registriert.

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

Nächste Schritte