Herkömmliche Arbeitslasten modernisieren
In diesem Thema wird beschrieben, wie Sie VM-basierte Arbeitslasten in Container modernisieren, die in Google Kubernetes Engine (GKE), dem GKE-Cluster oder der Cloud Run-Plattform ausgeführt werden. Sie können Arbeitslasten von VMs migrieren, die auf VMware oder Compute Engine ausgeführt werden, sodass Sie die Flexibilität haben, Ihre vorhandenen Arbeitslasten zu containerisieren.
Zur Modernisierung (auch als Migration bezeichnet) verwenden Sie einen Verarbeitungscluster, den Sie mit den Schritten in Migrate to Container installieren erstellt haben.
Der grundlegende Ablauf zur Migration einer Arbeitslast ist bei den unterstützten Arbeitslasttypen ähnlich. Es gibt einige Unterschiede zwischen Arbeitslasttypen. Daher müssen Sie Ihren Arbeitslasttyp in den folgenden Abschnitten für einen Überblick über das Verfahren und detaillierte Informationen pro Schritt identifizieren.
Unterstützte Arbeitslasten
- Linux-VM
- Windows IIS-Anwendung
- Tomcat-Anwendung
- WebSphere traditional-Anwendungen
- JBoss
- Apache
- WordPress-Websites
Linux-VM migrieren
Migrationsverfahren
Das folgende Diagramm veranschaulicht die Migrationsschritte für eine Linux-Arbeitslast:
-
Zum Starten einer Migration konfigurieren Sie eine Quelle, die die Quellplattform darstellt, aus der die Migration erfolgt. Wenn Sie bereits eine Quelle aus einer früheren Migration haben und die VMs, die Sie migrieren, von derselben Quelle stammen, können Sie sie wiederverwenden.
-
Erstellen Sie ein Migrationsobjekt mit einem ersten Migrationsplan.
-
Legen Sie fest, ob Sie Daten migrieren möchten.
-
Bearbeiten Sie den Migrationsplan für Ihre spezifischen Anforderungen, bevor Sie die Migration ausführen.
-
Führen Sie die Migration aus, um die Container-Artefakte zu extrahieren, einschließlich des Container-Images und des Dockerfiles. Verwenden Sie diese Artefakte, um den Container in Ihrer Testumgebung oder in der Produktion bereitzustellen.
-
Überwachen Sie den Fortschritt der Migration und prüfen Sie die entsprechenden Logs.
-
Löschen Sie die Migration, um alle von ihr verwendeten Ressourcen freizugeben.
Windows-IIS-Anwendung migrieren
Migrationsverfahren
Das folgende Diagramm veranschaulicht die Migrationsschritte für eine Windows-Arbeitslast:
Führen Sie die folgenden Schritte aus, um mit Migrate zu Containern zu migrieren:
-
Sie starten eine Migration. Konfigurieren Sie dazu eine Quelle, die die Quellplattform darstellt, von der Sie migrieren möchten. Wenn Sie bereits eine Quelle aus einer früheren Migration haben und die VMs, die Sie migrieren, von derselben Quelle stammen, können Sie sie wiederverwenden.
-
Erstellen Sie ein Migrationsobjekt mit einem ersten Migrationsplan.
-
Bearbeiten Sie den Migrationsplan für Ihre spezifischen Anforderungen, bevor Sie die Migration ausführen.
-
Führen Sie die Migration aus, um die Containerartefakte zu extrahieren, die das Dockerfile und andere Dateien enthalten, die zum Erstellen eines Container-Images erforderlich sind.
-
Überwachen Sie den Fortschritt der Migration und prüfen Sie die entsprechenden Logs.
Windows-Container-Image erstellen
Erstellen Sie mithilfe der generierten Artefakte einen Windows-Container, den Sie dann in einem Cluster bereitstellen können.
-
Löschen Sie die Migration, um alle von ihr verwendeten Ressourcen freizugeben.
Unterstützte Features
Migrate to Containers: Windows unterstützt derzeit die Migration von IIS .NET Framework-Websites. Sie können die Websites in einzelne Bilder unterteilen oder diese nach Bedarf gruppieren.
Führen Sie die Offlinebewertung der Befehlszeile des Discovery-Clients im Migrationscenter aus, um festzustellen, welche Websites auf einer Quell-VM migriert werden können.
Tomcat-Server migrieren
Das folgende Diagramm veranschaulicht die Migrationsschritte für eine Tomcat-Arbeitslast:
Wenn Sie Ihre Daten mit Tomcat-Arbeitslasten migrieren, können Sie die Features und die Architektur von Tomcat für folgende Aufgaben nutzen:
- Teilmengen von Anwendungen automatisch in einzelne Container aufteilen.
- Vorhandene Schlüsselspeicher, Truststores und Zertifikate der Tomcat-Anwendung von der Quell-VM erhalten.
- Optimale Speicherzuweisung für JVM-Anwendungen dynamisch ermitteln.
- Bestimmte Datenvolumen und Datenvolumenanforderungen aus Ihren Quell-VMs kopieren.
Vorbereitung
- Einen Linux-VM-basierten Apache Tomcat-Anwendungsserver der Version 8.5 oder höher.
- Ermitteln Sie die Eignung der Arbeitslast für die Migration, indem Sie eine Offlinebewertung ausführen.
- Cloud-Cluster für die Migration von Linux-VMs konfigurieren
Migrationsverfahren
Führen Sie die folgenden Schritte aus, um mit Migrate zu Containern zu migrieren:
-
Sie starten eine Migration. Konfigurieren Sie dazu eine Quelle, die die Quellplattform darstellt, von der Sie migrieren möchten. Wenn Sie bereits eine Quelle aus einer früheren Migration haben und die VMs, die Sie migrieren, von derselben Quelle stammen, können Sie sie wiederverwenden.
-
Erstellen Sie ein Migrationsobjekt mit einem ersten Migrationsplan.
-
Legen Sie fest, ob Sie Daten migrieren möchten.
-
Bearbeiten Sie den Migrationsplan für Ihre spezifischen Anforderungen, bevor Sie die Migration ausführen.
-
Führen Sie die Migration aus, um die Containerartefakte zu extrahieren, die das Dockerfile und andere Dateien enthalten, die zum Erstellen eines Container-Images erforderlich sind.
-
Überwachen Sie den Fortschritt der Migration und prüfen Sie die entsprechenden Logs.
Ein Tomcat-Container-Image erstellen
Erstellen Sie mithilfe der generierten Artefakte einen Container, den Sie dann in einem Cluster bereitstellen können.
-
Löschen Sie die Migration, um alle von ihr verwendeten Ressourcen freizugeben.
Nicht unterstützte Funktionen
Folgende Tomcat-Funktionen werden nicht unterstützt:
Clustering/Sitzungsreplikation.
Windows-Unterstützung für Tomcat-Migrationen mit Windows-Arbeitslasten.
WebSphere-typische Anwendungen migrieren
Übersicht über die Migration
IBM WebSphere Application Server (WAS) traditional ist ein Software-Framework, das Java-basierte Arbeitslasten hostet. Mit Migrate to Containers können Sie Anwendungsarbeitslasten, die in WAS traditional ausgeführt werden, modernisieren, indem Sie sie in Anwendungscontainer konvertieren. Sie können die Anwendungscontainer dann im GKE- oder GKE Enterprise-Cluster in Google Cloud bereitstellen.
Informationen zur Migration von WebSphere Application Server traditional-Anwendungen
Eine WAS traditional VM kann mehrere Anwendungen enthalten. Mit Migrate to Containers können Sie die Modernisierung von WAS-Anwendungen in Container automatisieren, indem Sie bereitgestellte Anwendungen in der Quell-VM ermitteln und automatisch die Konfiguration für die Modernisierung vorschlagen.
Google erfordert, dass Sie jede Anwendung zu ihrem eigenen Container-Image (ibmcom/websphere-traditional
, ibmcom/websphere-liberty
oder openliberty/open-liberty
) migrieren. Sie können die migrierten Anwendungen dann einzeln testen und bereitstellen, anstatt mehrere Anwendungen gemeinsam testen und bereitstellen zu müssen.
Die Migrationsquelle kann WAS ND oder WAS base sein. Das Ziel ist ein Liberty- oder WAS traditional-Basiscontainer und die entsprechenden ND-Clustering-Features werden an Kubernetes delegiert.
Voraussetzungen
Prüfen Sie anhand der folgenden Systemanforderungen, ob Ihre Migrations- und Bereitstellungsumgebungen mit Migrate to Containers kompatibel sind.
Voraussetzungen für die Migration von WAS traditional-Apps
Prüfen Sie vor der Migration, ob Ihre IBM WAS traditional-Umgebungen und Migrationsverarbeitungscluster die unten beschriebenen Anforderungen erfüllen.
WAS traditional Systemanforderungen
Migrate to Containers unterstützt die Migration von Anwendungen, die in den folgenden Versionen von IBM WAS gehostet werden:
- WebSphere-Application Server 8.5.5.x
- WebSphere-Application Server traditional 9.0.5.x
Damit Migrate to Containers eine VM mit einer WAS traditional-Anwendung verarbeiten kann, extrahiert Migrate to Container zwei Arten von Konfigurationen aus der VM:
Die Konfiguration der einzelnen Anwendungen.
Die Konfiguration des Zielprofils. In einem Profil wird die Laufzeitumgebung eines WAS definiert, einschließlich Ports, JVM-Einstellungen und mehr.
Die Migrate to Containers-Software automatisiert die Verwendung des IBM WebSphere Application Server Migration Toolkit for Application Binaries in Ihrem GKE Enterprise- oder GKE-Cluster, um Migrationsberichte und Konfigurationsskripts zu ermitteln, zu bewerten und zu generieren. Sie sind allein für die Beschaffung, Lizenzierung und die Verwendung des Toolkits verantwortlich.
Bevor Sie mit der Migration beginnen können, müssen Sie das Toolkit in einen Google Cloud Storage-Bucket in Ihrem Konto hochladen. Weitere Informationen zu diesem Verfahren finden Sie unter BinaryAppScanner.jar einrichten.
Kompatible VM-Betriebssysteme
Migrate to Containers unterstützt die Migration von WAS traditional Anwendungen von VMs mit den 64-Bit-Linux-Betriebssystemen, die unter Kompatible VM-Betriebssysteme aufgeführt sind.
Anforderungen für Verarbeitungscluster
Google Kubernetes Engine (GKE)- oder GKE Enterprise-Cluster verwenden, um die Migrate to Containers-Komponenten auszuführen, die die Transformationen ausführen, die zum Migrieren einer Anwendung aus einer Quelle-VM zu einem Zielcontainer erforderlich sind. Für Anwendungen in einer WAS VM:
Der Verarbeitungscluster kann als bereitgestellt werden:
Für den Verarbeitungscluster muss ein Linux-Betriebssystem verwendet werden, das unter Kompatible Betriebssysteme für Verarbeitungscluster aufgeführt ist.
Weitere Informationen zum Erstellen jedes Verarbeitungstypclusters finden Sie unter Typ des Verarbeitungsclusters auswählen.
Anforderungen für die Bereitstellung migrierter Anwendungen
Prüfen Sie nach der Migration der Anwendungen, ob die Anwendungsumgebung und der Zielcluster die unten beschriebenen Anforderungen erfüllen.
Anforderungen an Zielcluster
Verwenden Sie einen GKE (Google Kubernetes Engine)-, GKE Enterprise-Cluster in Google Cloud oder Google Distributed Cloud Virtual for Bare Metal. Der Zielcluster muss ein Linux-Betriebssystem verwenden, das unter Kompatible Betriebssysteme für Arbeitslastcluster aufgeführt ist.
Im Rahmen einer Migration erstellt Migrate to Containers ein Docker-Image für eine migrierte WAS-Anwendung und lädt es in eine Docker-Registry hoch. Der Zielcluster muss Lesezugriff auf die Docker-Registry haben, wie hier beschrieben.
Unterstützte Zielcontainer
- WebSphere-Anwendungsserver
- WebSphere-Application Server Liberty
- Open Liberty
Hinweise
Führen Sie vor Beginn der Migration die folgenden Aufgaben aus.
Migrate to Containers installieren
Installieren Sie Migrate for Containers auf Ihrem Verarbeitungscluster. Ein Verarbeitungscluster ist ein GKE-Cluster (Google Kubernetes Engine) oder GKE Enterprise-Cluster, auf dem Migrate to Containers-Komponenten installiert sind und für den Sie VMs migrieren. Alle Installationsanweisungen finden Sie unter Installationsübersicht.
Optional: Migrate to Virtual Machines einrichten
Wenn Sie Migrate to Containers verwenden möchten, um Websphere-Arbeitslasten von VMware zu Google Cloud zu migrieren, müssen Sie die Migrate to Virtual Machines einrichten, die den Transport übernimmt.
Weitere Informationen finden Sie unter Migrate to Virtual Machines einrichten.
Die binaryAppScanner.jar-Datei einrichten
Migrate to Containers automatisiert die Verwendung der binaryAppScanner.jar
-Datei, die im IBM WebSphere Application Server Migration Toolkit for Application Binaries verfügbar ist, um Konfigurationsinformationen und Dateien für WAS-Anwendungen in der Quell-VM zu extrahieren.
Vor einer Migration müssen Sie Folgendes tun:
Akzeptieren Sie die Lizenzvereinbarung, laden Sie das IBM WebSphere Application Server Migration Toolkit for Application Binaries herunter und extrahieren Sie die Datei
binaryAppScanner.jar
.Erstellen Sie ein Dockerfile und bereiten Sie das Plug-in mit dem Binärscanner vor.
Um binaryAppScanner.jar
einzurichten:
Laden Sie die Installationsdatei
binaryAppScannerInstaller.jar
vom IBM Support herunter. Sie müssen die Lizenzvereinbarung als Teil des Downloads akzeptieren.Führen Sie den folgenden Befehl aus, um die Datei
binaryAppScanner.jar
zu extrahieren und die Lizenzvereinbarung zu akzeptieren:java -jar binaryAppScannerInstaller.jar --acceptLicense --verbose
Geben Sie das Zielverzeichnis für die Extraktion an. z. B.
/tmp
. Das Installationsprogramm erstellt ein Verzeichnis mit dem Namen/wamt
unter dem Zielverzeichnis.Rufen Sie das /wamt-Verzeichnis auf. Beispiel:
cd /tmp/wamt
Erstellen Sie mit den folgenden Befehlen zwei Dockerfiles:
FROM us-docker.pkg.dev/migrate-modernize-public/modernize-plugins-prod/websphere-traditional-container-discover:1.3.1 ADD binaryAppScanner.jar /
FROM us-docker.pkg.dev/migrate-modernize-public/modernize-plugins-prod/websphere-traditional-container-extract:1.3.1 ADD binaryAppScanner.jar /
Erstellen und übertragen Sie die Docker-Images:
gcloud builds submit --timeout 1h -t gcr.io/PROJECT_ID/websphere-traditional-container-discover-with-scanner:1.3.1 --project PROJECT_ID gcloud builds submit --timeout 1h -t gcr.io/PROJECT_ID/websphere-traditional-container-extract-with-scanner:1.3.1 --project PROJECT_ID
Bearbeiten Sie die Plug-in-CRD, um sie mit dem Binärscanner zu bündeln:
$ kubectl edit appxplugins.anthos-migrate.cloud.google.com -n v2k-system websphere-traditional-container # Set the value of spec.discoveryImage and spec.generateArtifactsImage: apiVersion: anthos-migrate.cloud.google.com/v1beta2 kind: AppXPlugin metadata: namespace: v2k-system name: websphere-traditional-container labels: anthos-migrate.cloud.google.com/preview-type: public annotations: anthos-migrate.cloud.google.com/display-name: WebSphere traditional container spec: discoverImage: gcr.io/PROJECT_ID/websphere-traditional-container-discover-with-scanner:1.3.1 discoverCommand: - /ko-app/websphere-traditional - discover generateArtifactsImage: gcr.io/PROJECT_ID/websphere-traditional-container-extract-with-scanner:1.3.1 generateArtifactsCommand: - /ko-app/websphere-traditional - extract parameterDefs: - name: was-home usage: Path of the WebSphere WAS_HOME on the original instance. envVar: APPX_WAS_HOME
Speichern Sie die CRD.
Migrationsverfahren
Das folgende Diagramm veranschaulicht die Migrationsschritte für eine WebSphere-Arbeitslast:
Führen Sie die folgenden Schritte aus, um mit Migrate zu Containern zu migrieren:
-
Fügen Sie die Migrationsquelle hinzu, die die Quellplattform darstellt.
-
Erstellen Sie ein Migrationsobjekt mit einem ersten Migrationsplan.
Migrieren Sie WebSphere-Daten.
Legen Sie fest, ob Sie Daten migrieren möchten.
-
Bearbeiten Sie den Migrationsplan für Ihre spezifischen Anforderungen, bevor Sie die Migration ausführen. Sie migrieren eine WAS-Anwendung pro Migration.
-
Führen Sie die Migration aus, um die Containerartefakte zu extrahieren, die das Dockerfile und andere Dateien enthalten, die zum Erstellen eines Container-Images erforderlich sind.
Migrationsartefakte generieren und prüfen
Führen Sie die Migration aus, um den Anwendungscontainer zu generieren. Sie können den Migrationsprozess überwachen und die Artefakte prüfen, wenn sie vorbereitet sind, um das bereitstellbare Anwendungs-Image zu erstellen.
-
Überwachen Sie den Fortschritt der Migration und prüfen Sie die entsprechenden Logs.
Anwendungscontainer-Image erstellen
Erstellen Sie mithilfe der generierten Artefakte einen Container, den Sie dann in einem Cluster bereitstellen können.
Anwendungs-Container in einem Zielcluster bereitstellen
Stellen Sie das Image in Ihrem GKE-Cluster bereit.
-
Löschen Sie die Migration, um alle von ihr verwendeten Ressourcen freizugeben.
JBoss-Server migrieren
Das folgende Diagramm veranschaulicht die Migrationsschritte für eine JBoss-Arbeitslast:
Wenn Sie Ihre JBoss-Arbeitslasten mit Migrate to Containers migrieren, können Sie die Features und die Architektur von JBoss nutzen, um bestimmte Datenvolumen und Datenvolumenanforderungen von Ihren Quell-VMs zu kopieren.
Vorbereitung
JBoss AS-Anwendungsserver v8.1.0 und höher oder JBoss EAP-Anwendungsserver v7.0, v7.1, v7.2, v7.3 und v7.4.
Konfigurieren Sie einen Google Cloud-Cluster für die Migration von VMs.
Migrationsverfahren
Führen Sie die folgenden Schritte aus, um mit Migrate zu Containern zu migrieren:
-
Sie starten eine Migration, indem Sie eine Quelle konfigurieren, die die Quellplattform darstellt, von der Sie migrieren möchten. Wenn Sie bereits eine Quelle aus einer früheren Migration haben und die VMs, die Sie migrieren, von derselben Quelle stammen, können Sie sie wiederverwenden.
-
Erstellen Sie ein Migrationsobjekt mit einem ersten Migrationsplan.
-
Legen Sie fest, ob Sie Daten migrieren möchten.
-
Bearbeiten Sie den Migrationsplan für Ihre spezifischen Anforderungen, bevor Sie die Migration ausführen.
-
Führen Sie die Migration aus, um die Containerartefakte zu extrahieren, die das Dockerfile und andere Dateien enthalten, die zum Erstellen eines Container-Images erforderlich sind.
-
Überwachen Sie den Fortschritt der Migration und prüfen Sie die entsprechenden Logs.
JBoss-Container-Image erstellen
Erstellen Sie mithilfe der generierten Artefakte einen Container, den Sie dann in einem Cluster bereitstellen können.
-
Löschen Sie die Migration, um alle von ihr verwendeten Ressourcen freizugeben.
Nicht unterstützte Funktionen
Folgende JBoss-Funktionen werden nicht unterstützt:
- Sensible Daten und Secrets: Sensible Daten und Secrets, die im Verzeichnis
JBOSS_HOME/standalone
gespeichert sind, werden nicht entfernt. Diese Daten werden in das Container-Image aufgenommen. - JBoss-Logger-Konfiguration: Die Logger-Konfiguration wird unverändert vom Quellcomputer übernommen. Es wird während des Migrationsprozesses nur dann geändert, wenn
jbossServer.tar.gz
vor dem Erstellen des JBoss-Containers manuell geändert wird. - Speicherzuordnung: Die Zuweisung von Java-VM-Ressourcen (Java Virtual Machine) wird aus dem Community-Container übernommen und ist nicht von den JVM-Ressourcen der Quellmaschine abhängig.
- Umgebungsvariablen: Umgebungsvariablen und JVM-Parameter der Quellmaschine werden nicht in das Container-Image migriert.
- Offlinebewertung: Die Ermittlung der Eignung der JBoss-Arbeitslast für die Migration wird nicht unterstützt.
Apache-Server migrieren
Das folgende Diagramm veranschaulicht die Migrationsschritte für eine Apache-Arbeitslast:
Wenn Sie Ihre Daten mit Apache-Arbeitslasten migrieren, können Sie die Features und die Architektur von Apache für folgende Aufgaben nutzen:
- Bestimmte Datenvolumen und Datenvolumenanforderungen aus Ihren Quell-VMs kopieren.
Vorbereitung
- Einen Linux-VM-basierten Apache 2-Webserver.
- Google Cloud-Cluster für die Migration von Linux-VMs konfigurieren.
Migrationsverfahren
Führen Sie die folgenden Schritte aus, um mit Migrate zu Containern zu migrieren:
-
Sie starten eine Migration. Konfigurieren Sie dazu eine Quelle, die die Quellplattform darstellt, von der Sie migrieren möchten. Wenn Sie bereits eine Quelle aus einer früheren Migration haben und die VMs, die Sie migrieren, von derselben Quelle stammen, können Sie sie wiederverwenden.
-
Erstellen Sie ein Migrationsobjekt mit einem ersten Migrationsplan.
-
Legen Sie fest, ob Sie Daten migrieren möchten.
-
Bearbeiten Sie den Migrationsplan für Ihre spezifischen Anforderungen, bevor Sie die Migration ausführen.
-
Führen Sie die Migration aus, um die Containerartefakte zu extrahieren, die das Dockerfile und andere Dateien enthalten, die zum Erstellen eines Container-Images erforderlich sind.
-
Überwachen Sie den Fortschritt der Migration und prüfen Sie die entsprechenden Logs.
Apache-Container-Image erstellen
Erstellen Sie mithilfe der generierten Artefakte einen Container, den Sie dann in einem Cluster bereitstellen können.
-
Löschen Sie die Migration, um alle von ihr verwendeten Ressourcen freizugeben.
Nicht unterstützte Funktionen
Apache 1-Arbeitslasten werden nicht unterstützt.
Folgende Apache-Funktionen werden nicht unterstützt:
Zertifikate.
Windows-Unterstützung für Apache-Migrationen mit Windows-Arbeitslasten.
WordPress-Website migrieren
Wenn Sie Ihre WordPress-Arbeitslasten mit Migrate to Containers migrieren, können Sie die Features und die Architektur von WordPress nutzen, um bestimmte Datenvolumen und Datenvolumenanforderungen von Ihren Quell-VMs zu kopieren.
Vorbereitung
- WordPress ab Version 4.0, ausgeführt auf einem Linux-VM-basierten Apache 2-Webserver.
- Google Cloud-Cluster für die Migration von Linux-VMs konfigurieren.
Migrationsverfahren
Führen Sie die folgenden Schritte aus, um mit Migrate zu Containern zu migrieren:
-
Sie starten eine Migration, indem Sie eine Quelle konfigurieren, die die Quellplattform darstellt, von der Sie migrieren möchten. Wenn Sie bereits eine Quelle aus einer früheren Migration haben und die VMs, die Sie migrieren, von derselben Quelle stammen, können Sie sie wiederverwenden.
-
Erstellen Sie ein Migrationsobjekt mit einem ersten Migrationsplan.
-
Bearbeiten Sie den Migrationsplan für Ihre spezifischen Anforderungen, bevor Sie die Migration ausführen.
Migrieren Sie WordPress-Daten.
Prüfen und bearbeiten Sie den Datenmigrationsplan für Ihre spezifischen Anforderungen, bevor Sie die Migration ausführen.
-
Führen Sie die Migration aus, um die Containerartefakte zu extrahieren, die das Dockerfile und andere Dateien enthalten, die zum Erstellen eines Container-Images erforderlich sind.
-
Überwachen Sie den Fortschritt der Migration und prüfen Sie die entsprechenden Logs.
WordPress-Container-Image erstellen
Erstellen Sie mithilfe der generierten Artefakte einen Container, den Sie dann in einem Cluster bereitstellen können.
-
Löschen Sie die Migration, um alle von ihr verwendeten Ressourcen freizugeben.
Nicht unterstützte Funktionen
WordPress-Websites, die auf anderen Hosts als Linux VM VM-basiertem Apache 2-Webserver ausgeführt werden, werden nicht unterstützt.
Folgende WordPress-Funktionen werden nicht unterstützt:
Migration der WordPress-Datenbank
Weitere Informationen zum Migrieren einer Anwendung, die auf einer Datenbank basiert, finden Sie unter Sicherstellen, dass Datenbanken zugänglich sind.
Exportieren Sie lokal auf dem WordPress-Server gespeicherte Daten wie Medien-Uploads, Plug-ins und Themen auf ein NFS-Laufwerk.
Weitere Informationen zum Exportieren lokal gespeicherter Daten nach NFS finden Sie unter NFS-Bereitstellungen als nichtflüchtige Volumes definieren.
Horizontale Skalierung der migrierten Bereitstellung
Die lokal auf dem WordPress-Server gespeicherten Daten werden auf den nichtflüchtigen Speicher von Compute Engine exportiert, der im Pod für die migrierte Bereitstellung bereitgestellt wird. Ein nichtflüchtiger Compute Engine-Speicher kann nicht an mehrere Pods angehängt werden und verhindert daher die horizontale Skalierung der migrierten Bereitstellung.
Zertifikate und sensible Daten in Kubernetes-Secret-Objekte exportieren