Migrationsplan für Tomcat-Server anpassen

Prüfen Sie die Datei für den Migrationsplan, die bei der Migration erstellt wurde. Passen Sie die Datei vor der Migration an. Die Details Ihres Migrationsplans werden verwendet, um die Containerartefakte der Arbeitslast aus der Quelle zu extrahieren.

In diesem Abschnitt werden der Inhalt der Migration und die Arten von Anpassungen dargestellt, die Sie vor dem Ausführen der Migration und vor dem Erstellen von Deployment-Artefakten prüfen sollten.

Hinweis

In diesem Thema wird davon ausgegangen, dass Sie bereits eine Migration erstellt haben und die Migrationsplandatei vorhanden ist.

Migrationsplan bearbeiten

Nachdem Sie das Dateisystem kopiert und analysiert haben, finden Sie den Migrationsplan im neuen Verzeichnis, das im angegebenen Ausgabepfad erstellt wird: ANALYSIS_OUTPUT_PATH/config.yaml.

Bearbeiten Sie den Migrationsplan nach Bedarf und speichern Sie die Änderungen.

Prüfen Sie die Details Ihres Migrationsplans und die Leitbemerkungen, um nach Bedarf Informationen hinzuzufügen. Berücksichtigen Sie insbesondere Änderungen in folgenden Abschnitten.

Docker-Image angeben

Im Migrationsplan generieren wir ein Docker-Community-Image-Tag basierend auf der Tomcat-Version, der Java-Version und dem Java-Anbieter.

Tomcat-Version: Die Tomcat-Version wird erkannt und in eine Hauptversion konvertiert (Nebenversionen werden nicht unterstützt). Wenn wir keine Tomcat-Version erkennen, enthält baseImage.name einen leeren String.
Java-Version: Die Java-Version hängt vom Parameter java-version ab. Die Standardeinstellung ist 11.
Java-Anbieter: Der Java-Anbieter ist auf eine Konstante festgelegt: temurin.

Das Docker-Community-Image-Tag, das für die Tomcat-Version 9.0, die Java-Version 11 und den Java-Anbieter temurin generiert wird, lautet beispielsweise tomcat:9.0-jre11-temurin.

Im Migrationsplan stellt das Feld baseImage.name das Docker-Image-Tag dar, das als Basis des Container-Images verwendet wird.

Die ursprünglichen Tomcat- und Java-Versionen auf der Quell-VM sind in discovery-report.yaml enthalten, das von der ersten Erkennung generiert wird.

Wenn Sie das Docker-Community-Image ändern oder ein eigenes Docker-Image bereitstellen möchten, können Sie baseImage.name in Ihrem Migrationsplan mit dem folgenden Format ändern:

tomcatServers:
    - name: latest
      . . .
      images:
        - name: tomcat-latest
          . . .
          baseImage:
            name: BASE_IMAGE_NAME

Ersetzen Sie BASE_IMAGE_NAME durch das Docker-Image, das Sie als Basis für das Container-Image verwenden möchten.

Tomcat-Installationspfad aktualisieren

Wenn Ihr Zielimage während der Migration einen nicht standardmäßigen CATALINA_HOME-Pfad hat, können Sie einen benutzerdefinierten CATALINA_HOME-Pfad angeben. Bearbeiten Sie das Zielfeld catalinaHome direkt im Migrationsplan:

tomcatServers:
  - name: latest
    . . .
    images:
      - name: tomcat-latest
        . . .
        baseImage:
          name: BASE_IMAGE_NAME
          catalinaHome: PATH

Ersetzen Sie PATH durch den Tomcat-Installationspfad.

Nutzer und Gruppe anpassen

Wenn Ihr Ziel-Image während der Migration mit einem anderen Nutzer und einer anderen Gruppe als root:root ausgeführt wird, können Sie einen benutzerdefinierten Nutzer und eine benutzerdefinierte Gruppe angeben, unter denen die Anwendung ausgeführt werden soll. Bearbeiten Sie den Nutzer und die Gruppe direkt im Migrationsplan:

tomcatServers:
  - name: latest
    . . .
    images:
      - name: tomcat-latest
        . . .
        userName: USERNAME
        groupName: GROUP_NAME

Ersetzen Sie Folgendes:

USERNAME: Nutzername, den Sie verwenden möchten
GROUP_NAME: der zu verwendende Gruppenname

SSL konfigurieren

Wenn Sie eine neue Tomcat-Migration erstellen, scannt ein Erkennungsprozess den Server auf die verschiedenen erkannten Anwendungen.

Nach der Erkennung werden die folgenden Felder im Migrationsplan automatisch ausgefüllt:

excludeFiles: listet die Dateien und Verzeichnisse auf, die von der Migration ausgeschlossen werden sollen.

Standardmäßig werden alle während der Erkennung enthaltenen vertraulichen Pfade und Zertifikate automatisch hinzugefügt und von der Migration ausgeschlossen. Wenn Sie einen Pfad aus dieser Liste entfernen, wird die Datei oder das Verzeichnis in das Container-Image hochgeladen. Wenn Sie eine Datei oder ein Verzeichnis aus dem Container-Image ausschließen möchten, fügen Sie den Pfad zu dieser Liste hinzu.

sensitiveDataPaths: listet alle sensiblen Pfade und Zertifikate auf, die sich im Erkennungsprozess befinden.

Zum Hochladen der Zertifikate in das Repository legen Sie das Feld includeSensitiveData auf true fest:

# Sensitive data which will be filtered out of the container image.
# If includeSensitiveData is set to true the sensitive data will be mounted on the container.

includeSensitiveData: true
tomcatServers:
- name: latest
  catalinaBase: /opt/tomcat/latest
  catalinaHome: /opt/tomcat/latest
  # Exclude files from migration.
  excludeFiles:
  - /usr/local/ssl/server.pem
  - /usr/home/tomcat/keystore
  - /usr/home/tomcat/truststore
  images:
  - name: tomcat-latest
    ...
    # If set to true, sensitive data specified in sensitiveDataPaths will be uploaded to the artifacts repository.
    sensitiveDataPaths:
    - /usr/local/ssl/server.pem
    - /usr/home/tomcat/keystore
    - /usr/home/tomcat/truststore

Nach Abschluss der Migration werden die Secrets der Secret-Datei secrets.yaml im Artefakte-Repository hinzugefügt.

Logging von Webanwendungen

Migrate to Containers unterstützt das Logging mit log4j v2, logback und log4j v1.x, die sich in CATALINA_HOME befinden.

Migrate to Containers 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 verwenden, um die Logerfassung zu aktivieren und an eine Lösung zur Logerfassung (z. B. Google Cloud Logging) zu streamen.

Arbeitsspeicherzuweisung

Während des Migrationsprozesses können Sie die Speicherlimits von Anwendungen angeben, die in einzelne Container migriert werden. Bearbeiten Sie die Speicherlimits direkt im Migrationsplan im folgenden Format:

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

Der empfohlene Wert für limit ist 200 % von Xmx, was die maximale Java-Heap-Größe ist. Der empfohlene Wert für requests ist 150% von Xmx.

Führen Sie den folgenden Befehl aus, um den Wert von Xmx anzuzeigen:

ps aux | grep catalina

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

FROM tomcat:8.5-jdk11-openjdk

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

Dies definiert die anfängliche und maximale Größe auf 50 % des Limits. Dadurch kann sich die Größe des Tomcat-Java-Heaps je nach Änderung des Pod-Speicherlimits ändern.

Tomcat-Umgebungsvariablen festlegen

Wenn Sie CATALINA_OPTS in der Dockerfile festlegen möchten, die nach einer erfolgreichen Migration zusammen mit anderen Artefakten generiert wird, können Sie das Feld catalinaOpts in Ihrem Migrationsplan ergänzen: Das folgende Beispiel zeigt ein aktualisiertes catalinaOpts-Feld:

tomcatServers:
    - name: latest
      . . .
      images:
        - name: tomcat-latest
          . . .
          resources:
            . . .
          catalinaOpts: "-Xss10M"

Migrate to Containers parst Ihre catalinaOpts-Daten für das Dockerfile. Das folgende Beispiel zeigt die Ausgabe des Parsings:

FROM 8.5-jdk11-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.0 -XX:InitialRAMPercentage=50.0 -Xss10M"

Sie können Tomcat-Umgebungsvariablen auch mithilfe des Scripts setenv.sh festlegen, das sich im Ordner /bin auf Ihrem Tomcat-Server 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.

Tomcat-Systemdiagnose festlegen

Sie können die Ausfallzeit und den Bereitschaftsstatus Ihrer verwalteten Container überwachen. Geben Sie dazu Tests im Migrationsplan Ihres Tomcat-Webservers an. Mit einem Monitoring der Systemdiagnose können Sie die Ausfallzeiten migrierter Container reduzieren und ein besseres Monitoring bereitstellen.

Unbekannte Systemstatus können zu einer Beeinträchtigung der Verfügbarkeit, zu falsch-positivem Verfügbarkeits-Monitoring und zu einem möglichen Datenverlust führen. Ohne eine Systemdiagnose kann kubelet den Zustand eines Containers nur „vermuten“ und sendet Traffic eventuell an eine nicht bereite Containerinstanz. Dies kann zu Trafficverlusten führen. Außerdem kann Kubelet keine Container erkennen, die sich in einem fixierten Zustand befinden, d. h. es kann diese nicht neu starten.

Eine Systemdiagnose funktioniert durch Ausführen einer kleinen skriptbasierten Anweisung beim Starten des Containers. Das Script prüft jeden Zeitraum auf erfolgreiche Bedingungen, die durch die Art der verwendeten Diagnose definiert sind. Der Zeitraum wird im Migrationsplan durch ein periodSeconds-Feld definiert. Sie können diese Skripts manuell ausführen oder definieren.

Weitere Informationen zu kubelet-Diagnosen finden Sie in der Kubernetes-Dokumentation unter Aktivitäts-, Bereitschafts- und Startprüfungen konfigurieren.

Es gibt zwei Arten von Prüfungen, die konfiguriert werden können. Beide Prüfungen werden in der probe-v1-core-Referenz definiert und haben dieselbe Funktion wie die entsprechenden Felder von container-v1-core

Aktivitätsprüfung: Aktivitätsprüfungen werden verwendet, um festzustellen, wann ein Container neu gestartet werden muss.

Hinweis: Wenn ein Prozess in Ihrem Container selbst abstürzen kann, wenn ein Problem auftritt oder er fehlerhaft wird, benötigen Sie nicht unbedingt eine Aktivitätsprüfung. Kubelet führt automatisch die richtige Aktion gemäß dem restartPolicy des Pods aus.

Bereitschaftsprüfung: Bereitschaftsprüfungen werden verwendet, um festzustellen, wann ein Container bereit ist, Traffic anzunehmen. Wenn Sie nur dann Traffic an einen Pod senden möchten, wenn eine Prüfung erfolgreich ist, geben Sie eine Bereitschaftsprüfung an. Eine Bereitschaftsprüfung kann ähnlich funktionieren wie eine Aktivitätsprüfung. Eine Bereitschaftsprüfung in den Spezifikationen gibt jedoch an, dass ein Pod ohne Trafficempfang gestartet wird, und Traffic nur nach erfolgreicher Prüfung empfängt.

Nach der Erkennung wird die Diagnosekonfiguration dem Migrationsplan hinzugefügt. Die Prüfungen können in der Standardkonfiguration verwendet werden, wie im folgenden Beispiel gezeigt. Entfernen Sie den Abschnitt probes aus der YAML-Datei, um die Prüfungen zu deaktivieren.

tomcatServers:
- name: latest
  images:
  - name: tomcat-latest
    ports:
    - 8080
    probes:
      livenessProbe:
        tcpSocket:
          port: 8080
      readinessProbe:
        tcpSocket:
          port: 8080

Sie können diesen Migrationsplan ändern, um einen vorhandenen Tomcat-HTTP-Endpunkt zu verwenden.

tomcatServers:
- name: latest
  images:
  - name: tomcat-latest
    ports:
    - 8080
    probes:
      livenessProbe:
       httpGet:
          path: /healthz
          port: 8080
          httpHeaders:
          - name: Custom-Header
            value: Awesome
        initialDelaySeconds: 3
        periodSeconds: 3
      readinessProbe:
        httpGet:
        tcpSocket:
          port: 8080

Es gibt vier vordefinierte Möglichkeiten, einen Container mithilfe einer Diagnose zu prüfen. Bei jeder Diagnose muss genau einer dieser vier Mechanismen definiert werden:

exec: Führt einen angegebenen Befehl im Container aus. Die Ausführung wird als erfolgreich bewertet, wenn der Statuscode für den Exit 0 ist.
grpc: Führt einen Remote-Prozeduraufruf mit gRPC aus. gRPC-Prüfungen sind eine Alphafunktion.
httpGet: Führt eine HTTP-GET-Anfrage an die IP-Adresse des Pods an einem angegebenen Port und Pfad aus. Die Anfrage wird als erfolgreich bewertet, wenn der Statuscode größer oder gleich 200 und kleiner als 400 ist.
tcpSocket: Führt eine TCP-Prüfung der IP-Adresse des Pods an einem angegebenen Port durch. Die Diagnose gilt als erfolgreich, wenn der Port geöffnet ist.

Standardmäßig aktiviert ein Migrationsplan die Prüfmethode tcpSocket. Sie können den Migrationsplan manuell konfigurieren, um andere Prüfmethoden zu verwenden. Sie können benutzerdefinierte Befehle und Skripts auch über den Migrationsplan definieren.

Definieren Sie eine ausführbare Bereitschaftsprüfung und ein Script, um die Logik zu implementieren und um externe Abhängigkeiten für die Bereitschaftsprüfung hinzuzufügen.

Tomcat-Clustering-Konfiguration überprüfen

Tomcat-Clustering wird verwendet, um Sitzungsinformationen für alle Tomcat-Knoten zu replizieren. Dadurch können Sie beliebige Backend-Anwendungsserver aufrufen, ohne Informationen zu Clientsitzungen zu verlieren. Weitere Informationen zur Clustering-Konfiguration finden Sie in der Tomcat-Dokumentation unter Clustering/Sitzungsreplikation – Anleitung.

Die Tomcat-Clustering-Klasse heißt SimpleTcpListener und verwendet Multicast-Heartbeat-Nachrichten für die Peer-Erkennung. Multicast wird von Cloud-Umgebungen nicht unterstützt. Daher müssen Sie die Clustering-Konfiguration ändern oder nach Möglichkeit entfernen.

Wenn ein Load-Balancer so konfiguriert ist, dass eine fixierte Sitzung auf dem Backend-Tomcat-Server ausgeführt und verwaltet wird, kann er das in der Engine-Konfiguration in server.xml konfigurierte Attribut jvmRoute verwenden.

Wenn Ihre Quellumgebung eine nicht unterstützte Clustering-Konfiguration verwendet, ändern Sie die Datei server.xml, um entweder die Konfiguration zu deaktivieren, oder verwenden Sie eine unterstützte Konfiguration.

Tomcat v8.5 oder höher: Clustering muss in Tomcat-Version 8.5 deaktiviert sein. Zum Deaktivieren des Clusterings müssen Sie den Abschnitt <Cluster … /> in server.xml auskommentieren.
Tomcat v9 oder höher: In Tomcat Version 9 oder höher können Sie die Cluster-Klasse mit KubernetesMembershipService aktivieren. KubernetesMembershipService ist eine Kubernetes-spezifische Klasse, die die Kubernetes APIs für die Peer-Erkennung verwendet.
- Kubernetes-Anbieter: Im Folgenden finden Sie eine Beispielkonfiguration für einen Kubernetes-Anbieter:
```
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
<Channel className="org.apache.catalina.tribes.group.GroupChannel">
<Membership className="org.apache.catalina.tribes.membership.cloud.CloudMembershipService" membershipProviderClassName="org.apache.catalina.tribes.membership.cloud.KubernetesMembershipProvider"/>
</Channel>
</Cluster>
```
- DNS-Anbieter: Verwenden Sie den DNSMembershipProvider, um die DNS APIs für die Peer-Erkennung zu verwenden. Im Folgenden finden Sie eine Beispielkonfiguration für einen DNS-Anbieter:
```
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
<Channel className="org.apache.catalina.tribes.group.GroupChannel">
<Membership className="org.apache.catalina.tribes.membership.cloud.CloudMembershipService" membershipProviderClassName="org.apache.catalina.tribes.membership.cloud.DNSMembershipProvider"/>
</Channel>
</Cluster>
```
- jvmRoute: Wenn Ihr Load-Balancer einen jvmRoute-Wert benötigt, sollte der Wert von statisch in den POD-Namen geändert werden. Dadurch wird Tomcat so konfiguriert, dass dem Sitzungscookie mit dem POD-Namen ein Suffix hinzugefügt wird. Dies kann vom Frontend-Load-Balancer verwendet werden, um Traffic an den richtigen Tomcat-POD weiterzuleiten. Ändern Sie den Wert in der Datei server.xml so:
```
<Engine name="Catalina" defaultHost="localhost" jvmRoute="${HOSTNAME}">
```

Tomcat-Proxy-Konfiguration prüfen

Wenn der Tomcat-Proxy so konfiguriert ist, dass er hinter einem Reverse-Proxy ausgeführt wird, oder wenn Sie mehrere Proxy-Konfigurationseinstellungen im Abschnitt Connector von server.xml verwenden, müssen Sie prüfen, ob dieselben Proxy-Konfigurationen nach der Migration weiterhin gelten, nachdem sie für die Ausführung in Kubernetes migriert wurden.

Wählen Sie zum Ausführen einer funktionierenden containerisierten Tomcat-Anwendung eine der folgenden Konfigurationsänderungen für die Reverse-Proxy-Konfiguration aus:

Proxykonfiguration deaktivieren: Wenn die migrierte Anwendung nicht mehr hinter einem Reverse-Proxy ausgeführt wird, können Sie die Proxykonfiguration deaktivieren. Entfernen Sie dazu proxyName und proxyPort aus der Connector-Konfiguration.
Proxy migrieren: Migrieren Sie die Proxy-VM und behalten Sie alle vorhandenen Tomcat-Konfigurationen bei.
Ingress als Ersatz für den Reverse-Proxy konfigurieren: Wenn für den Reverse-Proxy keine benutzerdefinierte oder ausgefeilte Logik implementiert wurde, können Sie eine Ingress-Ressource konfigurieren, um die migrierte Tomcat-Anwendung verfügbar zu machen. Dieser Prozess verwendet denselben FQDN, der vor der Migration verwendet wurde. Zum Konfigurieren eines Ingress müssen Sie prüfen, ob der Tomcat-Kubernetes-Service type: Nodeport ist. Im Folgenden finden Sie eine Beispielkonfiguration eines Ingress:
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-tomcat-ingress
spec:
  rules:
  - host: APP_DOMAIN
    http:
      paths:
      - pathType: ImplementationSpecific
        backend:
          service:
            name: my-tomcat-service
            port:
              name: my-tomcat-port
```
Hinweis: Wenn der Reverse-Proxy zum Entlasten von SSL-Traffic verwendet wurde, sollten Sie Ingress mit SSL-Zertifikaten konfigurieren. Weitere Informationen zur Verwendung von SSL-Zertifikaten finden Sie unter Mehrere SSL-Zertifikate beim HTTPS-Load-Balancing mit Ingress verwenden.
Cloud Service Mesh mit Cloud Load Balancing konfigurieren: Wenn Sie GKE Enterprise verwenden, können Sie Ihre Anwendung mit Anthos Service Mesh verfügbar machen. Weitere Informationen zum Freigeben von Service Mesh-Anwendungen finden Sie unter Von Edge zu Mesh: Service Mesh-Anwendungen über GKE Ingress verfügbar machen.

Java-Proxy-Konfiguration überprüfen

Bei der Migration zu Containern müssen Sie die Verfügbarkeit Ihrer Proxyserver in Ihrer neuen Umgebung prüfen. Wenn der Proxyserver nicht verfügbar ist, wählen Sie eine der folgenden Konfigurationsänderungen für den Proxy aus:

Proxy deaktivieren: Wenn der ursprüngliche Proxy nicht mehr verwendet wird, deaktivieren Sie die Proxykonfiguration. Entfernen Sie alle Proxyeinstellungen entweder aus dem Script setenv.sh oder aus der Konfigurationsdatei, in der sie auf Ihrem Tomcat-Server verwaltet werden.
Proxyeinstellungen ändern: Wenn Ihre Kubernetes-Umgebung einen anderen Proxy für ausgehenden Traffic verwendet, können Sie Ihre Proxyeinstellungen in setenv.sh oder in einer anderen Datei ändern, sodass sie auf den neuen Proxy verweist.

Nächste Schritte

Migration ausführen