Windows-Cluster für die Bereitstellung vorbereiten

Auf dieser Seite werden einige Szenarien erläutert, in denen Sie die Migrationsartefakte möglicherweise anpassen müssen.

Hinweise

In diesem Thema wird davon ausgegangen, dass Sie die Migration abgeschlossen haben.

Der Zielcluster muss Lesezugriff auf die Docker-Registry haben.

Im Rahmen einer Migration lädt Migrate to Containers Docker-Images hoch, die eine in eine Docker-Registry migrierte VM darstellen. Diese Docker-Images stellen die Dateien und Verzeichnisse der migrierten VM dar.

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

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

Weitere Informationen finden Sie unter Daten-Repositories definieren.

Arbeitslast in einem anderen Google Cloud-Projekt bereitstellen als dem, das für die Migration verwendet wird

Oft haben Sie mehrere Google Cloud-Projekte in Ihrer Umgebung. Wenn Sie eine Migration in einem Google Cloud-Projekt ausführen, die migrierte Arbeitslast jedoch in einem Cluster in einem anderen Projekt bereitstellen möchten, müssen Sie prüfen, ob die Berechtigungen richtig konfiguriert sind.

Führen Sie beispielsweise die Migration in Projekt A aus. Die migrierte Arbeitslast wird in diesem Fall in einen Container Registry-Bucket in Projekt A kopiert. Beispiel:

gcr.io/project-a/image_name:image_tag

Anschließend stellen Sie die Arbeitslast in einem Cluster in Projekt B bereit. Wenn Sie die Berechtigungen nicht korrekt konfigurieren, kann der Arbeitslast-Pod nicht ausgeführt werden, da der Cluster in Projekt B keinen Image-Pull-Zugriff auf Projekt A hat. Dann sehen Sie ein Ereignis im Pod mit einer Nachricht im Format:

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

Alle Projekte, für die die Compute Engine API aktiviert wurde, haben ein Compute Engine-Standarddienstkonto mit der folgenden E-Mail-Adresse:

PROJECT_NUMBER-compute@developer.gserviceaccount.com

Dabei ist PROJECT_NUMBER die Projektnummer für Projekt B.

Achten Sie zur Umgehung dieses Problems darauf, dass das Compute Engine-Standarddienstkonto für Projekt B die erforderlichen Berechtigungen für den Zugriff auf den Container Registry-Bucket hat. Sie können den Zugriff beispielsweise mit dem folgenden gsutil-Befehl aktivieren:

gsutil iam ch serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com:objectViewer gs://artifacts.project-a.appspot.com

Arbeitslasten im Verarbeitungscluster bereitstellen

Sie können die migrierte Arbeitslast auf demselben Cluster bereitstellen, mit dem Sie auch die Migration durchgeführt haben. Diese Migration wird als der Verarbeitungscluster von Migrate to Containers bezeichnet. In den meisten Fällen müssen Sie keine zusätzliche Konfiguration für den Verarbeitungscluster vornehmen, da der Cluster bereits einen Lese- oder Schreibzugriff auf die Docker-Registry benötigt, um eine Migration auszuführen.

In einem Zielcluster bereitstellen, wobei Container Registry als Docker-Registry verwendet wird

Erstellen Sie ein Kubernetes-Secret mit den für den Zugriff auf Container Registry erforderlichen Anmeldedaten, um sicherzustellen, dass ein Zielcluster Zugriff auf die Container Registry hat:

Erstellen Sie ein Dienstkonto zum Bereitstellen einer Migration, wie unter Dienstkonto für den Zugriff auf Container Registry und Cloud Storage erstellen beschrieben.

In diesem Vorgang laden Sie eine JSON-Schlüsseldatei namens m4a-install.json herunter.
Erstellen Sie ein Kubernetes-Secret mit den für den Zugriff auf Container Registry erforderlichen Anmeldedaten:
```
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=account@project.iam.gserviceaccount.com
```
Dabei gilt:
- docker-registry gibt den Namen des Kubernetes-Secrets an, in diesem Beispiel gcr-json-key.
- docker-server=gcr.io gibt Container Registry als Server an.
- docker-username=_json_key gibt an, dass der Nutzername in der JSON-Schlüsseldatei enthalten ist.
- docker-password angibt, dass ein Passwort aus der JSON-Schlüsseldatei verwendet wird.
- docker-email die E-Mail-Adresse des Dienstkontos angibt.
Legen Sie das Kubernetes-Secret so fest:
- Ändern Sie den Standardwert imagePullSecrets:
```
kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "gcr-json-key"}]}'
```
- Bearbeiten Sie die Datei deployment_spec.yaml, um den Wert imagePullSecrets der Definition spec.template.spec hinzuzufügen. Wenn Sie WebSphere verwenden, lautet die YAML-Bereitstellungsdatei je nach Ziel twas_deployment_spec.yaml, liberty_deployment_spec.yaml oder openliberty_deployment_spec.yaml.
```
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
```
  Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.
Stellen Sie das Arbeitslast-Secret bereit, falls secrets.yaml vorhanden ist. Für Tomcat-basierte Arbeitslasten und WebSphere-basierte herkömmliche Arbeitslasten mit Liberty ist eine Secret-Datei vorhanden. Die Liberty-Datei heißt liberty-secrets.yaml.
```
kubectl apply -f secrets.yaml
```

In einem Zielcluster mithilfe einer Docker-Registry mit Basisauthentifizierung bereitstellen

Wenn Sie eine Docker-Registry zum Speichern von Migrations-Images verwenden, muss die Registry die Basisauthentifizierung mit einem Nutzernamen und einem Passwort unterstützen. Da es mehrere Möglichkeiten zum Konfigurieren einer schreibgeschützten Verbindung zu einer Docker-Registry gibt, sollten Sie die für Ihre Clusterplattform und Docker-Registry geeignete Methode verwenden.

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

den Migrationsplan bearbeiten, um die erforderlichen Attribute so zu konfigurieren, dass der migrierte Container ein gMSA verwendet.
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:

Hier finden Sie weitere Informationen:

gMSAs für Windows-Container erstellen
Verwaltetes Dienstkonto für Gruppe erstellen
gMSA verwenden in der Google Cloud-Dokumentation
Konfigurieren Ihrer App für die Verwendung eines gMSAs in der Microsoft-Dokumentation

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

Wir empfehlen, ein Cloud Load Balancing, Ingress oder Anthos 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 SSL-Zertifikate (Secure Sockets Layer) auch als Kubernetes-Secrets speichern und zur Laufzeit im Container bereitstellen.

So verwenden Sie Kubernetes-Secrets:

Erstellen Sie eine PFX-Datei mit dem Zertifikat und dem Passwort.
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.

Erstellen Sie das Kubernetes-Secret:

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

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, 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 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 Anthos Service Mesh verwenden

Sie können die Bindungen im Migrationsplan zur Verwendung von HTTP anpassen. Verwenden Sie dann Cloud Load Balancing, Ingress oder Anthos Service Mesh als HTTPS-Frontend, um den externen Zugriff zu sichern finden Sie weitere Informationen. 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 für die Migration, um protocol auf http festzulegen:
```
sites:
  site:
  - applications:
    - path: /
      virtualdirectories:
        - path: /
          physicalpath: '%SystemDrive%\inetpub\wwwroot'
          bindings:
          - port: 8080
            protocol: http
          name: Default Web Site
```
Hinweis: In der Einstellung protocol sind nur HTTP- und HTTPS-Protokolle zulässig. Alle Protokolle außer HTTP/HTTPS werden übersprungen und nicht verarbeitet.

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