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 migrieren

Migrationsverfahren

Das folgende Diagramm veranschaulicht die Migrationsschritte für eine Linux-Arbeitslast:

Diagramm der Schritte zur Migration mit Migration to Containers
  1. Migrationsquelle hinzufügen

    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.

  2. Migration erstellen

    Erstellen Sie ein Migrationsobjekt mit einem ersten Migrationsplan.

  3. Linux-Daten migrieren

    Legen Sie fest, ob Sie Daten migrieren möchten.

  4. Migrationsplan anpassen

    Bearbeiten Sie den Migrationsplan für Ihre spezifischen Anforderungen, bevor Sie die Migration ausführen.

  5. 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.

  6. Migration überwachen

    Überwachen Sie den Fortschritt der Migration und prüfen Sie die entsprechenden Logs.

  7. Migration löschen

    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:

Diagramm der Schritte zur Migration mit Migration to Containers

Führen Sie die folgenden Schritte aus, um mit Migrate zu Containern zu migrieren:

  1. Migrationsquelle hinzufügen

    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.

  2. Migrationsplan erstellen

    Erstellen Sie ein Migrationsobjekt mit einem ersten Migrationsplan.

  3. Migrationsplan anpassen

    Bearbeiten Sie den Migrationsplan für Ihre spezifischen Anforderungen, bevor Sie die Migration ausführen.

  4. 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.

  5. Migration überwachen

    Überwachen Sie den Fortschritt der Migration und prüfen Sie die entsprechenden Logs.

  6. Windows-Container-Image erstellen

    Erstellen Sie mithilfe der generierten Artefakte einen Windows-Container, den Sie dann in einem Cluster bereitstellen können.

  7. Migration löschen

    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:

Diagramm der Schritte zur Migration mit Migration to Containers

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:

  1. Migrationsquelle hinzufügen

    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.

  2. Migration erstellen

    Erstellen Sie ein Migrationsobjekt mit einem ersten Migrationsplan.

  3. Tomcat-Daten migrieren

    Legen Sie fest, ob Sie Daten migrieren möchten.

  4. Migrationsplan anpassen

    Bearbeiten Sie den Migrationsplan für Ihre spezifischen Anforderungen, bevor Sie die Migration ausführen.

  5. 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.

  6. Migration überwachen

    Überwachen Sie den Fortschritt der Migration und prüfen Sie die entsprechenden Logs.

  7. Ein Tomcat-Container-Image erstellen

    Erstellen Sie mithilfe der generierten Artefakte einen Container, den Sie dann in einem Cluster bereitstellen können.

  8. Migration löschen

    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.

WAS-Anwendungen zu einzelnen Anwendungscontainern migrieren

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:

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:

Um binaryAppScanner.jar einzurichten:

  1. Laden Sie die Installationsdatei binaryAppScannerInstaller.jar vom IBM Support herunter. Sie müssen die Lizenzvereinbarung als Teil des Downloads akzeptieren.

  2. 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
    
  3. Geben Sie das Zielverzeichnis für die Extraktion an. z. B. /tmp. Das Installationsprogramm erstellt ein Verzeichnis mit dem Namen /wamt unter dem Zielverzeichnis.

  4. Rufen Sie das /wamt-Verzeichnis auf. Beispiel:

    cd /tmp/wamt
    
  5. 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 /
    
  6. 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
    
  7. 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
    
  8. Speichern Sie die CRD.

Migrationsverfahren

Das folgende Diagramm veranschaulicht die Migrationsschritte für eine WebSphere-Arbeitslast:

WAS-Anwendungen zu einzelnen Anwendungscontainern migrieren

Führen Sie die folgenden Schritte aus, um mit Migrate zu Containern zu migrieren:

  1. Migrationsquelle hinzufügen

    Fügen Sie die Migrationsquelle hinzu, die die Quellplattform darstellt.

  2. Migration erstellen

    Erstellen Sie ein Migrationsobjekt mit einem ersten Migrationsplan.

  3. Migrieren Sie WebSphere-Daten.

    Legen Sie fest, ob Sie Daten migrieren möchten.

  4. Migrationsplan anpassen

    Bearbeiten Sie den Migrationsplan für Ihre spezifischen Anforderungen, bevor Sie die Migration ausführen. Sie migrieren eine WAS-Anwendung pro Migration.

  5. 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.

  6. 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.

  7. Migration überwachen

    Überwachen Sie den Fortschritt der Migration und prüfen Sie die entsprechenden Logs.

  8. Anwendungscontainer-Image erstellen

    Erstellen Sie mithilfe der generierten Artefakte einen Container, den Sie dann in einem Cluster bereitstellen können.

  9. Anwendungs-Container in einem Zielcluster bereitstellen

    Stellen Sie das Image in Ihrem GKE-Cluster bereit.

  10. Migration löschen

    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:

Diagramm der Schritte zur Migration mit Migration to Containers

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:

  1. Migrationsquelle hinzufügen

    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.

  2. Migration erstellen

    Erstellen Sie ein Migrationsobjekt mit einem ersten Migrationsplan.

  3. JBoss-Daten migrieren

    Legen Sie fest, ob Sie Daten migrieren möchten.

  4. Migrationsplan anpassen

    Bearbeiten Sie den Migrationsplan für Ihre spezifischen Anforderungen, bevor Sie die Migration ausführen.

  5. 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.

  6. Migration überwachen

    Überwachen Sie den Fortschritt der Migration und prüfen Sie die entsprechenden Logs.

  7. JBoss-Container-Image erstellen

    Erstellen Sie mithilfe der generierten Artefakte einen Container, den Sie dann in einem Cluster bereitstellen können.

  8. Migration löschen

    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:

Diagramm der Schritte zur Migration mit Migration to Containers

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:

  1. Migrationsquelle hinzufügen

    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.

  2. Migration erstellen

    Erstellen Sie ein Migrationsobjekt mit einem ersten Migrationsplan.

  3. Daten migrieren

    Legen Sie fest, ob Sie Daten migrieren möchten.

  4. Migrationsplan anpassen

    Bearbeiten Sie den Migrationsplan für Ihre spezifischen Anforderungen, bevor Sie die Migration ausführen.

  5. 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.

  6. Migration überwachen

    Überwachen Sie den Fortschritt der Migration und prüfen Sie die entsprechenden Logs.

  7. Apache-Container-Image erstellen

    Erstellen Sie mithilfe der generierten Artefakte einen Container, den Sie dann in einem Cluster bereitstellen können.

  8. Migration löschen

    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:

  1. Migrationsquelle hinzufügen

    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.

  2. Migration erstellen

    Erstellen Sie ein Migrationsobjekt mit einem ersten Migrationsplan.

  3. Migrationsplan anpassen

    Bearbeiten Sie den Migrationsplan für Ihre spezifischen Anforderungen, bevor Sie die Migration ausführen.

  4. Migrieren Sie WordPress-Daten.

    Prüfen und bearbeiten Sie den Datenmigrationsplan für Ihre spezifischen Anforderungen, bevor Sie die Migration ausführen.

  5. 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.

  6. Migration überwachen

    Überwachen Sie den Fortschritt der Migration und prüfen Sie die entsprechenden Logs.

  7. WordPress-Container-Image erstellen

    Erstellen Sie mithilfe der generierten Artefakte einen Container, den Sie dann in einem Cluster bereitstellen können.

  8. Migration löschen

    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

Nächste Schritte