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:
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 WertimagePullSecrets
der Definitionspec.template.spec
hinzuzufügen. Wenn Sie WebSphere verwenden, lautet die YAML-Bereitstellungsdatei je nach Zieltwas_deployment_spec.yaml
,liberty_deployment_spec.yaml
oderopenliberty_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ßtliberty-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 Attributsites
kann mehreresitename
-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 desvolumeMounts
-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 durchpfxpath
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, umprotocol
aufhttp
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 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.