Tomcat-Arbeitslasten migrieren

Migrate for Anthos and GKE beschleunigen die Containerisierung herkömmlicher Arbeitslasten und Bereitstellungen in GKE- und Anthos-Clustern.

Migration

Mit dieser öffentlichen Vorschau können Sie jetzt Ihre Tomcat-Arbeitslasten, die auf Linux-VMs ausgeführt werden, durch Konvertierung in Anwendungscontainer modernisieren. Sie können die Anwendungscontainer dann hier bereitstellen:

Wenn Sie Ihre Tomcat-Arbeitslasten mit Migrate for Anthos and GKE 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 verwalten.
Optimale Speicherzuweisung für JVM-Anwendungen dynamisch ermitteln.
Bestimmte Datenvolumen und Datenvolumenanforderungen aus Ihren Quell-VMs kopieren.

Vorbereitung

Wenn Sie Ihre Tomcat-Anwendungen migrieren möchten, müssen Sie Folgendes tun:

Verwenden Sie Linux VM-basierte Apache Tomcat-Anwendungsserver v8.5 und höher.
Installieren Sie Migrate for Anthos and GKE 1.10.2.

Migrationsprozess

Der Migrationsprozess für Tomcat-Anwendungen ähnelt dem aktuellen Linux-Migrationsprozess, mit den folgenden Einschränkungen:

Wichtige Hinweise für Mfit:
- Sie müssen das Eignungsbewertungstool mfit ausführen, bevor Sie die Migration der Tomcat-Arbeitslast starten, um die Datenerfassungsphase abzuschließen.
- Es gibt mehrere Tomcat-spezifische mfit-Regeln, mit denen Sie Ihre Arbeitslast bewerten können. Weitere Informationen zu den Tomcat-spezifischen mfit-Regeln finden Sie in der Dokumentation zu Tomcat mfit.
- Geben Sie die Option --readonly nicht an. Die Option --readonly verhindert, dass mfit erfasste Daten zu Tomcat auf der VM speichert, und verweigert Migrate for Anthos and GKE den Zugriff auf diese Daten.
- Verwenden Sie nicht die Option ./mfit discover. Sie müssen das Skript zur Datenerfassung auf einer VM ausführen, um mithilfe der Tomcat OSS-Community-Images Informationen für die Containerisierung abzurufen.
Weitere Hinweise:
- Sie müssen das Flag --workload–type mit der Option tomcat angeben, wenn Sie migctl ausführen, um den Migrationsplan zu erstellen.
- Bearbeiten Sie zum Anpassen der Migration die YAML-Datei des Migrationsplans. Diese Datei hat ein Tomcat-spezifisches Format, das unten unter Migrationsplan anpassen beschrieben wird.
- Wenn Sie die Migrationsartefakte erstellen, erstellt Migrate for Anthos and GKE eine build.sh-Datei, mit der Sie dann das Deployment-Container-Image erstellen.
- Wenn Sie eine Datenmigration zusammen mit der Tomcat-Anwendungsmigration durchführen möchten, können Sie die YAML-Datenkonfigurationsdatei (my-migration.data.yaml)) bearbeiten.
  
  Weitere Informationen zum Format der YAML-Datei für die Datenmigration finden Sie weiter unten unter Konfiguration der Datenmigration anpassen.

Tomcat-Arbeitslastmigration durchführen

So führen Sie eine Tomcat-Arbeitslastmigration aus:

mfit ausführen: mfit ist das Eignungsbewertungstool, mit dem Sie die Eignung der vorhandenen Tomcat-Arbeitslast für die Migration bewerten können.
Verarbeitungscluster konfigurieren: Installieren Sie die Migrate for Anthos- and GKE-Komponenten in einem GKE-Cluster, den Sie bereits erstellt haben, um die Migration und Containerisierung Ihrer VM-basierten Arbeitslasten zu verarbeiten.

Weitere Informationen zum ordnungsgemäßen Konfigurieren eines Verarbeitungsclusters abhängig von der Zielumgebung finden Sie unter Migrate for Anthos and GKE installieren.
Migrationsquelle hinzufügen: Fügen Sie die Migrationsquelle hinzu, die die Quellplattform darstellt, aus der Sie migrieren möchten. Wenn Sie beispielsweise eine VM von Compute Engine migrieren:
```
 migctl source create ce my-src --project my-project --json-key json-key-file
```
Weitere Informationen zum Hinzufügen von Migrationsquellen und die entsprechende Syntax für Migrationsquellen finden Sie in der Dokumentation zu Migrationsquelle hinzufügen.
Migration erstellen: Erstellen Sie einen Migrationsplan, den Sie vor der Migration prüfen und anpassen können.

Zum Erstellen eines Migrationsplans für Tomcat-Arbeitslasten können Sie den folgenden migctl-Befehl verwenden, wobei das Flag --workload-type auf tomcat gesetzt ist:
```
 migctl migration create my-migration --source my-src --vm-id my-vm --workload-type tomcat
```
Wobei:
- my-migration: Gibt den Namen der Migration an.
- my-src: Gibt den Namen der Migrationsquelle an, die Sie im vorherigen Schritt erstellt haben.
Hinweis: Wenn Sie eine Compute Engine-VM migrieren, müssen Sie die VM vor dem Erstellen der Migration ausschalten.
Migrationsplan prüfen: Zum Prüfen der YAML-Datei mit Ihrem Migrationsplan (einschließlich Konfigurieren der erforderlichen Speicher- und Arbeitsspeicherlimits, Aufteilungseinstellungen für Tomcat und Zertifikatseinstellungen) führen Sie die folgenden Schritte aus:
1. Laden Sie den Migrationsplan (my-migration.yaml) und die Konfiguration der Datenmigration (my-migration.data.yaml)-Dateien) herunter:
```
migctl migration get my-migration
```
  Mit diesem Befehl werden Dateien mit den Namen my-migration.yaml und my-migration.data.yaml heruntergeladen.
2. Öffnen Sie my-migration.yaml in einem Texteditor und rufen Sie die Migrationsdetails auf. Ändern Sie bei Bedarf die Details, um den Migrationsplan anzupassen. Informationen zum Anpassen des Migrationsplans finden Sie unten im Abschnitt Migrationsplan anpassen.
3. Wenn die Änderungen abgeschlossen sind, laden Sie die Datei hoch.
```
migctl migration update my-migration --main-config my-migration.yaml
```
Optional: Konfiguration der Datenmigration konfigurieren: Mit Migrate for Anthos and GKE können Sie nichtflüchtige Ordner aus den Tomcat-Arbeitslasten mit der Datenmigrationskonfigurationsdatei (my-migration.data.yaml) migrieren. Die Datei my-migration.data.yaml ist standardmäßig leer.

So konfigurieren Sie my-migration.data.yaml:
1. Laden Sie Ihre Konfigurationsdateien für die Datenmigration (my-migration.data.yaml) und die Migrationsplandateien (my-migration.yaml) mit dem folgenden Befehl herunter:
```
migctl migration get my-migration
```
  Dieser Befehl gibt Dateien mit den Namen my-migration.yaml und my-migration.data.yaml zurück.
2. Bearbeiten Sie my-migration.data.yaml in einem Texteditor.
3. Wenn die Änderungen abgeschlossen sind, laden Sie die Datei hoch.
```
migctl migration update my-migration --data-config my-migration.data.yaml
```
Hinweis: Das Aktualisieren Ihres Datenmigrations- und Migrationsplans kann in einem Schritt kombiniert werden, indem Sie sowohl YAML-Dateien bearbeiten als auch den Befehl $ migctl migration update my-migration --main-config my-migration.yaml --data-config my- migration.data.yaml ausführen
Migrationsartefakte generieren: Führen Sie die Migration aus, um die Containerartefakte zu generieren:
```
migctl migration generate-artifacts my-migration
```
Weitere Informationen zum Generieren von Migrationsartefakten finden Sie in der Dokumentation zu Migration ausführen.
Artefakte prüfen: Führen Sie den folgenden Befehl aus, um die Artefakte für die Erstellung des bereitstellungsfähigen Container-Images vorzubereiten:
```
migctl migration get-artifacts my-migration
```
Mit diesem Befehl wird ein separates Verzeichnis für jeden in Ihrem Migrationsplan aufgeführten Tomcat-Server erstellt. Migrate for Anthos and GKE erstellt entsprechend dem Migrationsplan für jedes Server-Image ein entsprechendes verschachteltes Verzeichnis. Diese verschachtelten Verzeichnisse enthalten Image-Artefakte, um das Image zu erstellen und bereitzustellen.

In jedem Verzeichnis sind mehrere Artefakte enthalten:
- Die Datei build.sh, mit der Sie das Container-Image für den Tomcat-Server erstellen können
- Die Datei deployment_spec.yaml, die Sie zum Bereitstellen des Container-Images verwenden
- Die Datei cloudbuild.yaml, mit der Sie das Image später als Teil einer CI-/CD-Pipeline neu erstellen können
- Die Datei volumes.yaml, die eine Aufschlüsselung der migrierten Datenvolumen enthält
Weitere Informationen zum Prüfen Ihrer Migrationsartefakte finden Sie unter Schritt 9 unten: volumes.yaml prüfen.

Hinweis: Wenn Sie Secrets in Ihrem Migrationsplan definieren und verknüpfen, wird eine Datei mit dem Namen „secrets.sh“ erstellt. Sie können secrets.sh verwenden, um Kubernetes-Secret-Objekte für Ihre bereitgestellten Anwendungen zu erstellen.
Weitere Informationen zum Prüfen Ihrer Migrationsartefakte finden Sie unter Migrationsartefakte prüfen
.
Optional: volumes.yaml prüfen:

Eines der Artefakte, die Migrate for Anthos and GKE nach Abschluss einer Migration generiert, heißt volumes.yaml.

Die volumes.yaml enthält Informationen zu den PVCs, PVs und PDs, in die Daten im Rahmen der Datenmigration kopiert wurden. Sie können diese Informationen verwenden, wenn Sie die migrierte Arbeitslast vor der Bereitstellung ändern möchten, um die kopierten Daten für Ihre Arbeitslast zugänglich zu machen.

Die Datei volumes.yaml hat folgendes Format:
```
volumes:
       deployment pvc name:
         pvc:
           full pvc yaml
         pv:
           full pvc yaml
```
Weitere Informationen zum Definieren einer PVC- oder PV-Datei yaml finden Sie in der Kubernetes-Dokumentation.

Hinweis: Sie können mit volumes.yaml keine Änderungen an der Anordnung Ihrer Daten vornehmen. Weitere Informationen zum Definieren Ihrer Datenvolumen finden Sie unten unter Konfiguration der Datenmigration anpassen.
Container-Image erstellen: Verwenden Sie die in den Migrationsartefakten erstellte Datei build.sh, um das Container-Image für Ihren Tomcat-Server zu erstellen.
1. Wechseln Sie in das Verzeichnis, das die generierten Artefakte für Ihr Tomcat-Image enthält.
  
  Führen Sie beispielsweise den folgenden Befehl aus, um in das Verzeichnis für einen Tomcat-Server namens latest und ein Image mit dem Namen app zu wechseln:
```
cd latest/app
```
2. Legen Sie Ihre Google Cloud-Projekt-ID und die Image-Version fest:
```
export PROJECT_ID=my_project VERSION=latest
```
3. Führen Sie das Skript build.sh aus, um Ihr Container-Image zu erstellen und in die Container Registry hochzuladen:
```
bash ./build.sh
```
Anwendungscontainer bereitstellen: Stellen Sie Ihre migrierte Anwendung im Zielcluster bereit:
```
sed -e "s/\${PROJECT_ID}/${PROJECT_ID}/g" -e "s/\${VERSION}/${VERSION}/g"
 deployment_spec.yaml | kubectl apply -f -
```
Weitere Informationen zum Bereitstellen eines Anwendungscontainers in einem Zielcluster finden Sie in der Dokumentation Anwendungscontainer in einem Zielcluster bereitstellen.

Migrationsplan anpassen

Wenn Sie den Migrationsplan erstellen, generiert Migrate for Anthos and GKE eine YAML-Datei, die Informationen für jeden erkannten Tomcat-Server enthält. Sie müssen den Migrationsplan bearbeiten, um die Attribute jedes Tomcat-Servers anzupassen, bevor Sie die Migrationsartefakte erstellen.

Wenn Sie die Migration anpassen möchten, sollten Sie den Migrationsplan (my-migration.yaml) bearbeiten:

tomcatServers:
    - name: latest
      catalinaBase: /opt/tomcat/latest
      catalinaHome: /opt/tomcat/home
      secrets: # files to extract from the server container images into secrets
        - name: my-vm-latest-ssl
          path: /usr/local/ssl
          files:
            - server.crt
            - server.pem
        - name: my-vm-latest-keystore
          path: /usr/home/tomcat
          files:
            - .keystore
            - .truststore
      images:
        - name: my-vm-latest-docs # name of the image for build and deployment
          fromImage: tomcat:8.5.66-jdk16-openjdk # for the resulting container image
          applications: # list of applications to include in the image
            - /opt/tomcat/latest/latest/webapps/docs
          additionalFiles: # external required paths
            - /opt/libraries/postgres.jar
          logConfigPaths: # of the contained web apps. Must be under catalina base
            - /opt/tomcat/latest/virtualHost/webapps/docs/WEB-INF/classes/log4j2.xml
          ports: # to create Kubernetes services associated with the resulting deployment
            - 8080
          resources:
            memory:
              limits: 2048M
              requests: 1280M
          secrets: # to mount in the container image
            - my-vm-latest-ssl
            - my-vm-latest-keystore
        - name: another-image
          . . .
    - name: another-server
      . . .

In my-migration.yaml:

name: Gibt den Namen des Tomcat-Servers an, der aus dem Namen catalinaBase bestimmt wird. Bei Migrate for Anthos and GKE wird bei einer Namenskollision ein Suffix angehängt.
catalinaBase/Home: Auf der Tomcat-Serverebene definiert
secrets: Secrets können in zwei Bereichen definiert werden:
- Serverbereich: Sie können die secrets-Felder name, path und files im Serverbereich definieren.
- Image-Bereich: Sie können secrets-Felder als Liste von Stringpfaden im Image-Bereich definieren.
images: Enthält einen Eintrag für jede Anwendung und einen Eintrag für alle Anwendungen zusammen. Wenn in Ihrer Arbeitslast keine Tomcat-Server gefunden wurden, enthält das Attribut images einen einzelnen Beispieleintrag, den Sie zur Überprüfung definieren können.
- name – gibt den Namen des generierten Container-Images in folgendem Format an:
```
tomcat-name
```
  Für einen Tomcat-Server namens latest lautet imageName beispielsweise:
```
Tomcat-latest
```
- fromImage – Wird einmal für alle Anwendungen auf demselben Tomcat-Server ermittelt.
additionalFiles – Wird auf Serverebene ermittelt und allen Anwendungen zugewiesen.
- ports – Wie in Ihrem Tomcat-Server definiert, können Connectors mit relevanten Anwendungen verknüpft werden.
- Resources – Nur automatisch für das einheitliche Image vorgeschlagen.
- Ein Image mit allen Anwendungen wird ebenfalls bereitgestellt.

Secrets und Zertifikate definieren

Wenn Sie eine neue Tomcat-Migration erstellen, scannt ein Discovery-Prozess die Serverkonfigurationen, um die Nutzung von Zertifikaten zu erkennen. Die Zertifikatspfade werden den verschiedenen erkannten Anwendungen zugeordnet.

Diese Zertifikate werden im Migrationsplan auf Server- und Image-Ebene angezeigt:

Serverbereich: Secrets, die Sie im Serverbereich aufnehmen, werden aus den resultierenden Image-Artefakten ausgeschlossen. Ein dediziertes Artefaktskript namens secrets.sh automatisiert die Erstellung von Kubernetes-Secret-Objekten aus ihren lokalen Pfaden.
Image-Bereich: Secrets, die Sie im Image-Bereich aufnehmen, führen zur automatischen Bereitstellung der entsprechenden Secrets in den bereitgestellten Containern. Wenn im Migrationsplan ein Secret-Pfad als relativer Pfad festgelegt ist, wird der Bereitstellungspfad relativ zum Image-Installationsverzeichnis der Tomcat-Community festgelegt.

Mit dem folgenden Befehl können Sie Kubernetes-Secret-Objekte mit dem Artefakt secrets.sh mit Migrate for Anthos end GKE erstellen:

bash ./secrets.sh namespace of deployments secret file secret file …

Logging von Webanwendungen

Migrate for Anthos and GKE unterstützt das Logging mit log4j v2, logback und log4j v1.x, die sich in CATALINA_HOME befinden. Pfade außerhalb von CATALINA_HOME werden nicht unterstützt.

Migrate for Anthos and GKE erstellt eine zusätzliche Archivdatei mit geänderten Log-Konfigurationen und konvertiert alle Dateityp-Appender in Konsolen-Appender. Sie können den Inhalt dieses Archivs als Referenz für die Aktivierung der Logerfassung und des Streamings an eine Logerfassungslösung (z. B. Google Cloud Logging) verwenden.

Arbeitsspeicherzuweisung

Während des Migrationsvorgangs versucht Migrate for Anthos and GKE, Speicherlimits des maximalen Heaps von Tomcat Java Heap auf Quell-VMs zu ermitteln. Wenn auf einer Quell-VM Speicherlimits erkannt werden, setzt Migrate for Anthos and GKE festgelegt.anfängliche (requests ) undmaximale (limits ) Speicherlimits für Ihren migrierten Container.

Wenn Sie Speicherlimits für Anwendungen angeben möchten, die in einzelne Container migriert wurden, oder wenn Ihre Speicher-VMs keine Speicherlimits gefunden haben, können Sie die Speicherlimits direkt im Migrationsplan bearbeiten. Verwenden Sie dazu das folgende Format:

tomcatServers:
    - name: latest
      . . .
      images:
        - name: tomcat-latest
          . . .
          resources:
            memory:
              limits: 2048M
              requests: 1280M

Wenn in Ihrem Migrationsplan Speicherbegrenzungen definiert wurden, wird die Dockerdatei (die zusammen mit anderen Artefakten nach einer erfolgreichen Migration erstellt wird) Ihre Deklaration widerspiegeln:

FROM tomcat:8.5.66-jdk16-openjdk

# Add JVM environment variables for tomcat
ENV CATALINA_OPTS="${CATALINA_OPTS} -XX:MaxRAMPercentage=50 -XX:InitialRAMPercentage=50 -XX:+UseContainerSupport <additional variables>"

Tomcat-Umgebungsvariablen festlegen

Wenn Sie CATLINA_OPTS im Dockerfile festlegen möchten, das nach einer erfolgreichen Migration zusammen mit anderen Artefakten generiert wird, können Sie zunächst das Feld catalinaOpts in Ihrem Migrationsplan ergänzen:

tomcatServers:
    - name: latest
      . . .
      images:
        - name: tomcat-latest
          . . .
          resources:
            . . .
          catalinaOpts: "-Xms512M -Xmx1024M"

Migrate for Anthos and GKE parsen Ihre catalinaOpts-Daten in Ihr Dockerfile:

FROM 8.5.66-jdk16-openjdk-slim

## setenv.sh script detected.
## Modify env variables on the script and add definitions to the migrated tomcat server,
## if needed (less recommended than adding env variables directly to CATALINA_OPTS) by uncomment the line below
#ADD --chown=root:root setenv.sh /usr/local/tomcat/bin/setenv.sh

    # Add JVM environment variables for the tomcat server
ENV CATALINA_OPTS="${CATALINA_OPTS} -XX:MaxRAMPercentage=50 -XX:InitialRAMPercentage=50 -Xss10M"

Sie können Tomcat-Umgebungsvariablen auch mithilfe des Skripts setenv.sh festlegen, das sich im Ordner /bin Ihres Tomcat-Servers befindet. Weitere Informationen zu Tomcat-Umgebungsvariablen finden Sie in der Tomcat-Dokumentation.

Wenn Sie setenv.sh zum Festlegen Ihrer Tomcat-Umgebungsvariablen verwenden, müssen Sie das Dockerfile bearbeiten.

Datenmigrationskonfiguration anpassen

Mit Migrate for Anthos and GKE können Sie während des Migrationsprozesses Datenmengen oder Datenvolumen-Anforderungen angeben, die von Ihren Tomcat-Arbeitslasten migriert werden sollen.

Um die Datenmigration in Ihrem Migrationsprozess zu ermöglichen, müssen Sie in Ihrer Datenkonfigurationsdatei (my-migration.data.yaml) Informationen über Ihr Zieldatenvolumen oder Ihre Anforderung in dem unten angegebenen Format angeben:

dataConfig:
      volumes:
        - deploymentPvcName:
          existingPvc:
            Name: my-pvc
          folders:
            - /bin
            - /opt
        - newPvc:
            accessModes:
            - ReadWriteOnce
            resources:
              requests:
                storage: 10G
          folders:
            - /bin
            - /opt

Wobei:

deploymentPvcName: Der PVC-Name, der von Migrate for Anthos and GKE in Ihrer bereitgestellten Arbeitslast für den Zugriff auf dieses Volume verwendet werden soll. (Wird nicht in Tomcat-Migrationen verwendet).
existingPvc:
- name: Der Name einer vorhandenen PVC. Legen Sie fest, ob Sie Datenvolumen in eine bestehende PVC migrieren möchten. Andernfalls muss nil angegeben werden.
newPvc: Legen Sie fest, ob Sie Ihre Datenvolumen auf eine neue PVC migrieren möchten. Sie können Ihre PVC mit der PVC-Standardsyntax definieren.

Weitere Informationen zur Kubernetes-PVC-Spezifikation finden Sie in der Kubernetes-Dokumentation.
folders:

Sie können Ihre Datenkonfigurationsdatei für verschiedene Anwendungsfälle für die Datenmigration bearbeiten, darunter:

Keine Datenmigration
Vorhandenen PersistentVolumeClaim (PVC) verwenden
Neue Volumes auf der migrierten VM erstellen
Mehrere PVCs mit mehreren Dateipfaden migrieren

Keine Datenmigration

Wenn Sie während der Migration keine Daten migrieren möchten, sollten Sie Ihre generierte Datenkonfigurationsdatei (my-migration.data.yaml) leer lassen. Die Datenkonfigurationsdatei wird standardmäßig leer erstellt.

Vorhandenen PersistentVolumeClaim (PVC) verwenden

Sie können Ihre Daten mit einem vorhandenen PersistentVolumeClaim (PVC) migrieren, wenn Sie bereits den gewünschten Speicher für die migrierten Daten zugewiesen haben und einen PVC haben, in dem Ihre Daten gespeichert werden sollen.

Sie können in der Datenkonfigurationsdatei (my-migration.data.yaml) einen vorhandenen PVC definieren, indem Sie das vorhandene Volume im Feld existingPvc übergeben.

Der PVC muss vor der Migration vorhanden sein. In diesem Fall würde Ihre Datenkonfigurationsdatei so aussehen:

dataConfig:
      volumes:
        - deploymentPvcName:
          existingPvc:
            name: my-pvc
          newPvc: # must be nil
          folders:
            - /bin
            - /opt

Neue Datenvolumen auf den migrierten VMs erstellen

Wenn Sie keinen Speicher vorab zugewiesen haben und Ihr Speicher während des Migrationsprozesses erstellt werden soll, können Sie ein leeres existingPvc-Feld übergeben und den Speicher angeben, der im Feld newPvc erstellt werden soll:

dataConfig:
      volumes:
        - deploymentPvcName:
          existingPvc: #must be nil
          newPvc:
            accessModes:
            - ReadWriteOnce
            resources:
              requests:
                storage: 10G
          folders:
            - /bin
            - /opt

Wenn Sie die Details Ihres Sicherungsspeichers nicht berücksichtigen möchten, sollten Sie für die Speicherklasse einen leeren String verwenden.

Wenn Sie eine bestimmte Speicherklasse deklarieren möchten, sollten Sie ein Speicherklassenobjekt in demselben Cluster vorbereiten, der Ihren Speicher gemäß Ihren Anforderungen erstellt.

Mehrere PVCs mit mehreren Dateipfaden migrieren

Sie können den Satz von Verzeichnissen unter dem Listenfeld folders jedes Eintrags in der Liste volume für jeden in Ihrer Datenkonfigurationsdatei (my-migration.data.yaml) aufgeführten PVC angeben:

dataConfig:
      volumes:
        - deploymentPvcName:
          existingPvc:
            name: my-pvc
          folders:
            - /bin
            - /opt
        - newPvc:
            accessModes:
            - ReadWriteOnce
            resources:
              requests:
                storage: 10G
          folders:
            - /bin
            - /opt

Die Pfade, die Sie unter folders in der Konfigurationsdatei auflisten, werden in dieselben Pfade in den Ziel-PVCs kopiert.

Datenmigration: Nächste Schritte

Nachdem Sie Ihre Datenkonfigurationsdatei geprüft haben, sollten Sie mit dem Schritt 7: Artefakte generieren des Migrationsprozesses fortfahren.

Sie können Ihre migrierten Volumes mit dem Artefakt volumes.yaml prüfen, das während des Tomcat-Migrationsprozesses erstellt wurde.

Nicht unterstützte Funktionen

Die folgenden Tomcat-Features werden in dieser Version nicht unterstützt:

Versionsverwaltung für die Migration: Migrate for Anthos and GKE unterstützen keine Migration zu Images mit unterschiedlichen Versionen von Tomcat und Java.
Clustering/Sitzungsreplikation.
Windows-Unterstützung für Tomcat-Migrationen mit Windows-Arbeitslasten.
Java-Version/Anbietererkennung: Migrate for Anthos and GKE empfiehlt eine vordefinierte Java-Version und einen Anbieter, die dann zum Auswählen des Tomcat-Images verwendet werden, anstatt es automatisch zu erkennen.

Fehlerbehebung

Bei der Migration Ihrer Arbeitslast für Tomcat können Fehler auftreten.

Wenn der Fehler build.sh ausgegeben wird:

manifest for ... not found: manifest unknown: manifest unknown

Diese Fehlermeldung gibt an, dass das übergeordnete Image für Ihre Arbeitslast fehlt. Es gibt zwei Lösungen, um diesen Fehler zu beheben:

Bearbeiten Sie die Extraktionskonfigurationsdatei mit einem vorhandenen Image und führen Sie ihn noch einmal aus. Schritt 7: Artefakte generieren
Bearbeiten Sie die Deklaration FROM des Dockerfiles, um auf ein vorhandenes Image zu verweisen, und führen Sie build.sh noch einmal aus.