WebSphere-Anwendungen mit Migrate to Containers in Container migrieren

Last reviewed 2021-12-22 UTC

Dieses Dokument richtet sich an Anwendungsinhaber und Cloud-Architekten, die Java-Anwendungen, die auf IBM WebSphere Application Server (WAS) ausgeführt werden, zu Containern migrieren möchten, die in Google Kubernetes Engine (GKE) oder GKE Enterprise ausgeführt werden. Es führt Sie durch den Prozess der Migration von WAS traditional-Anwendungen zu Containern aus einer Quellumgebung, die lokal ist oder sich in einer privaten Hostingumgebung oder bei einem anderen Cloud-Anbieter befindet. Außerdem werden die Vorteile der Automatisierung Ihrer Migration mit Migrate to Containers hervorgehoben.

Sie sollten entsprechende Kenntnisse über WebSphere haben, bevor Sie versuchen, WebSphere-VMs mit Migrate to Containers zu Containern zu migrieren.

Dieses Dokument enthält auch wichtige Punkte, die Sie bei der Planung einer WAS-Anwendungsmigration zu Containern berücksichtigen sollten. Es ist Teil einer mehrteiligen Reihe zur Migration zu Google Cloud. Weitere Informationen zu der Reihe finden Sie unter Migration zu Google Cloud: Migrationspfad auswählen.

Lesen Sie dieses Dokument, wenn Sie traditionelle WAS-Anwendungen, die einen kompatiblen WAS unter einem kompatiblen Betriebssystem wie Linux ausführen, mit Migrate to Containers aus einer unterstützten Quellumgebung in eine GKE- oder GKE Enterprise-Umgebung migrieren möchten. Solche Quellumgebungen können folgende sein:

• Eine Compute Engine-Umgebung
• Eine VMware vSphere-Umgebung
• Eine Microsoft Azure-VM-Umgebung
• Eine Amazon Elastic Compute Cloud-Umgebung (Amazon EC2)

Migrate to Containers automatisiert die Verwendung des IBM Migration Toolkit for Application Binaries, um alle WAS traditional-Anwendungen auf Ihren WAS traditional-VMs zu erkennen, zu untersuchen und zu migrieren. Anschließend werden diese WAS traditional-Anwendungen in einzelne WebSphere traditional-Container aufgeteilt.

Die Migration von WAS traditional-Anwendungen mit Migrate to Containers zeichnet sich durch einen geringen Platzbedarf (mindestens 1 GB RAM und 2 GB Image-Größe) sowie reduzierte Lizenzkosten (bis zu 70 % Rabatt auf ein WAS Network Deployment-Abo) aus.

Durch die Migration von WAS traditional-Anwendungen mit Migrate to Containers profitieren Sie von mehreren Aspekten einer containerisierten Umgebung. Es gelten die zuvor erwähnten reduzierten Lizenzkosten. Es besteht auch die Möglichkeit einer zukunftssicheren weiteren Modernisierung in integrierte Cloud-Frameworks. Dazu erstellen Sie WAS Liberty- oder Open Liberty-Container für Ihre Anwendungen

WAS Liberty ist eine einfache Produktionslaufzeit für die schnelle web- und cloudbasierte Anwendungsentwicklung und -bereitstellung. Es basiert auf dem Open-Source-Projekt Open Liberty. Unternehmen verwenden sowohl WAS Liberty als auch Open Liberty, um cloudbasierte Java-Mikrodienste zu erstellen.

Durch die Migration zu GKE Enterprise oder GKE werden die WAS Network Deployment Manager-Funktionen in die folgenden Programme übertragen:

• Kubernetes
• Anthos Service Mesh
• Config Sync
• Google Cloud Operations

Das folgende Diagramm zeigt, wie GKE oder GKE Enterprise die zentralisierte Funktionalität (z. B. Hochverfügbarkeit, Arbeitslastplatzierung und zentralisierte Konfiguration) verwaltet, die zuvor von WAS Network Deployment verwaltet wurde. Die anwendungsspezifische Konfiguration wird bei der Erstellung des Docker-Images verwaltet. Die Verwendung einer Docker-Image-basierten Konfiguration ermöglicht Wiederholbarkeit und Automatisierung über CI/CD-Prozesse.

Die Migration von WAS traditional-Anwendungen zu Containern mit Migrate to Containers ist einer der möglichen Schritte auf dem Weg zur Modernisierung der Arbeitslast. Durch die Migration können Sie zum einen die Anwendungen transformieren, sodass sie in einer Cloud-Umgebung ausgeführt werden, und zum anderen die teuren Umschreibungen vermeiden, die zum Modernisieren von WAS traditional-Anwendungen erforderlich sind.

Ideale Migrationskandidaten sind Anwendungen, die auf unterstütztem WebSphere Network Deployment, WebSphere Base oder auf unterstützten Java-Versionen ausgeführt werden, bei denen die Modernisierung durch ein vollständiges Umschreiben aus Ressourcensicht zu teuer oder gar nicht möglich ist. Weitere Informationen zu idealen Migrationskandidaten finden Sie unter VMs mit Migrate to Containers zu Containern migrieren.

Migration zu Google Cloud gestalten

Folgen Sie für die Migration Ihrer WAS traditional-Anwendungen aus Ihrer Quellumgebung zu Containern in Google Cloud dem in der Reihe Migration zu Google Cloud beschriebenen Framework.

Die folgende Grafik veranschaulicht den Migrationsprozess:

Das im vorherigen Diagramm dargestellte Framework umfasst vier Phasen:

1. Bewerten: In dieser Phase bewerten Sie die Quellumgebung sowie die Anwendungen, die Sie zu Google Cloud migrieren möchten, und bestimmen, welche WAS traditional-Anwendungen für die Migration geeignet sind.
2. Plan: In dieser Phase erstellen Sie die grundlegende Infrastruktur für Migrate to Containers, z. B. durch das Bereitstellen der Ressourcenhierarchie und das Einrichten des Netzwerkzugriffs.
3. Bereitstellen: In dieser Phase migrieren Sie die traditionellen WAS-Anwendungen mit Migrate to Containers aus der Quellumgebung zu GKE oder GKE Enterprise.
4. Optimieren: In dieser Phase beginnen Sie, die Cloud-Technologien und -Funktionen zu nutzen.

Quellumgebung und Anwendungen bewerten

In der Bewertungsphase erfassen Sie Informationen über die Quellumgebung und die zu migrierenden Anwendungen. Dadurch können Sie die Größe der benötigten Ressourcen anpassen, sowohl für die Migration als auch für Ihre Zielumgebung.

Die Bewertungsphase umfasst Folgendes:

1. Ein umfassendes Inventar Ihrer Anwendungen erstellen.
2. Die Anwendungen nach ihren Attributen und Abhängigkeiten katalogisieren.
3. Die Teams auf Google Cloud vorbereiten.
4. Einen Test und einen Proof of Concept für Google Cloud erstellen.
5. Die Gesamtbetriebskosten (TCO) der Zielumgebung berechnen.
6. Die Anwendungen auswählen, die als Erstes migriert werden sollen.

Die folgenden Abschnitte basieren auf dem Dokument Migration zu Google Cloud: Arbeitslasten bewerten und erkennen. Sie stellen jedoch Informationen bereit, die sich speziell auf die Bewertung der WAS traditional-Anwendungen beziehen, die Sie mit Migrate to Containers zu Containern migrieren möchten.

Inventar erstellen

Um den Umfang der Migration zu bestimmen, müssen Sie Ihre WAS traditional-Umgebung verstehen. Sammeln Sie dazu Informationen zu Ihren Anwendungen und zu deren Abhängigkeiten.

Unter Inventar Ihrer Anwendungen erstellen wird beschrieben, wie Sie ein Inventar Ihrer Arbeitslasten in Ihrer WAS traditional-Umgebung und der zugehörigen Abhängigkeiten erstellen. Folgen Sie dieser Anleitung und erstellen Sie Ihre Inventare. Wenn Sie mit dieser Arbeit fertig sind, lesen Sie dieses Dokument weiter.

Nachdem Sie ein Inventar Ihrer Arbeitslasten und der zugehörigen Abhängigkeiten erstellt haben, verfeinern Sie das Inventar. Bewerten Sie die Aspekte und Features, die für Ihre Organisation von Interesse sind, wenn sie ihre WAS traditional-Anwendungen mit Migrate to Containers migriert.

Bevor Sie Ihre WAS-Umgebung für die Migration bewerten, schließen Sie die Bewertungsschritte unter VMs mit Migrate to Containers zu Containern migrieren und Migration zu Google Cloud: Arbeitslasten bewerten und erkennen ab. Wenn Sie damit fertig sind, schließen Sie das Inventar Ihrer Arbeitslasten ab.

Beachten Sie Folgendes, um das Inventar Ihrer Arbeitslasten abzuschließen:

• Betriebssysteme, die auf Ihren WAS-VMs ausgeführt werden: Erfassen Sie Informationen zu den Betriebssystemen und den zugehörigen Lizenzen, die auf Ihren WAS-VMs ausgeführt werden. Sorgen Sie außerdem dafür, dass das Betriebssystem ein 64-Bit-Linux-Betriebssystem ist, das unter Kompatible Betriebssysteme und Kubernetes-Versionen aufgeführt ist.

• WAS-Versionen, die Ihre Anwendungen ausführen: Erfassen Sie Informationen zu den WAS-Versionen, die Ihre Anwendungen ausführen, und prüfen Sie, ob sie mit Migrate to Containers kompatibel sind. Migrate to Containers unterstützt die Migration von WAS traditional-Anwendungen (WebSphere Application Server traditional 8.5.5.x- und WebSphere Application Server traditional 9.0.5.x-Versionen) für WAS base- und WAS Network Deployment-Umgebungen:

• In Ihrem WAS bereitgestellte Anwendungen: Prüfen Sie, welche Anwendungen in jedem WAS bereitgestellt sind. Ordnen Sie dann die Abhängigkeiten zwischen Ihren Anwendungen sowie zwischen Ihren Anwendungen und externen Diensten zu. Erfassen Sie als Nächstes Informationen zu den Konfigurationsquellen Ihrer Anwendungen. Sie verwenden beispielsweise:

  • Umgebungsvariablen
  • Nicht standardmäßige WAS-Installationspfade
  • LDAP-Nutzer-Registries
  • Sicherheitsrollenzuordnungen
  • Änderungen zum Anwenden einer Klasse auf die Ladereihenfolge

• Eignungspunktzahl für Migrate to Containers: Prüfen Sie, ob Ihre WAS traditional-Anwendungen für die Migration mit Migrate to Containers geeignet sind. Migrate to Containers stellt ein Tool zur Eignungsbewertung bereit, das Sie auf Ihren WAS traditional-Anwendungen ausführen können, um eine Eignungspunktzahl zu berechnen. Migrate to Containers hat eine Reihe von Mindestanforderungen, um WAS traditional-Anwendungen erfolgreich zu migrieren. Es hat auch einige Einschränkungen bei der Automatisierung der Migration von WAS traditional-Anwendungen. Sie können diese Einschränkungen berücksichtigen, indem Sie die Anwendungen bei der Migration manuell konfigurieren.

• Authentifizierung: WAS bietet mehrere Authentifizierungsmechanismen, z. B. Simple WebSphere Authentication Mechanism (SWAM), Lightweight Third Party Authentication (LTPA) und Kerberos. Sie können nur eine einzige Nutzer-Registry-Implementierung als aktive Nutzer-Registry der WAS-Sicherheitsdomain konfigurieren. Migrate to Containers migriert Authentifizierungsdetails nicht automatisch. Dies bedeutet, dass die Konfiguration der Authentifizierung normalerweise während der Migration eine manuelle Konfiguration erfordert.

• Datenzugriff (JDBC): Die J2EE-Connector-Architektur definiert einen Standardressourcenadapter, der WAS mit Unternehmensinformationssystemen verbindet. Der Adapter stellt die Konnektivität zwischen dem Unternehmensinformationssystem, dem Anwendungsserver und den Anwendungen bereit. Migrate to Containers migriert die JDBC-Konfiguration automatisch zum modernisierten WAS-Container. Prüfen Sie, ob die Verbindung zwischen den migrierten Anwendungen und den vorhandenen Datenspeichern aktiviert ist.

• Messaging (JMS): WAS unterstützt die asynchrone Kommunikation über die JMS-Programmierschnittstelle (Java Messaging Service). Migrate to Containers migriert automatisch JMS-Konfigurationsinformationen. Für bestimmte Konfigurationen wie SSL sind jedoch einige manuelle Migrationsschritte erforderlich.

• E-Mail: WAS unterstützt das Senden von E-Mails über die JavaMail API. Migrate to Containers migriert JavaMail-Konfigurationsdateien nicht automatisch. Konfigurieren Sie diese Dateien während der Migrationsphase manuell.

Bewertung abschließen

Nachdem Sie die Inventare erstellt haben, die sich auf Ihre Umgebung und Ihre WAS traditional-Arbeitslasten beziehen, schließen Sie die restlichen Aktivitäten der Bewertungsphase ab, die unter Migration zu Google Cloud: Arbeitslasten bewerten und erkennen beschrieben sind. Wenn Sie mit dieser Arbeit fertig sind, lesen Sie dieses Dokument weiter.

Grundlage planen und aufbauen

Nachdem Sie die Anleitung unter Grundlage beim Migrieren von VMs planen und aufbauen befolgt haben, vervollständigen Sie Ihre WAS-Grundlage:

1. Bestätigen Sie den Namen des Cloud Storage-Buckets.

2. Laden Sie die Datei binaryAppScanner.jar hoch, die als Teil der IBM WebSphere Application Server Migration Toolkit for Application Binaries verfügbar ist. Führen Sie dazu die folgenden Schritte aus:

   1. Laden Sie die Installationsdatei binaryAppScannerInstaller.jar 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 im Zielverzeichnis.

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

      cd /tmp/wamt
      

   5. Laden Sie die Datei binaryAppScanner.jar in das Stammverzeichnis eines Cloud Storage-Buckets hoch:

      gsutil cp binaryAppScanner.jar gs://BUCKET_NAME
      

      Dabei steht BUCKET_NAME für den Namen Ihres Cloud Storage-Buckets.

Unter Migrate to Containers einrichten wird beschrieben, wie Sie Migrate to Containers und dessen Abhängigkeiten bereitstellen und konfigurieren. Folgen Sie dieser Anleitung, um Migrate to Containers einzurichten.

Wenn Sie mit dieser Arbeit fertig sind, lesen Sie dieses Dokument weiter.

WAS traditional-Anwendungen zu Containern migrieren

Weitere Informationen zur Bereitstellungsphase der Migration finden Sie unter VMs zu Containern migrieren.

Migrationsplan generieren und prüfen

Erstellen Sie einen Migrationsplan für Migrate to Containers für Ihre WAS traditional-Anwendungen:

1. Quellumgebungen als Migrate to Containers-Migrationsquellen konfigurieren: Zur Migration Ihrer WAS traditional-Anwendungen benötigt Migrate to Containers Informationen zu den Quellumgebungen, in denen Ihre VMs ausgeführt werden. Sie haben diese Informationen mithilfe der Aufgaben erfasst, die im Abschnitt Inventar erstellen in diesem Dokument beschrieben wurden. Weitere Informationen zum Konfigurieren von Quellumgebungen finden Sie unter Migrationsquelle hinzufügen.

2. Migrationspläne erstellen: Wenn Sie angeben möchten, welche WAS traditional-Anwendungen Sie von einer Quellumgebung zu einer unterstützten Zielumgebung migrieren möchten, erstellen Sie einen Migrationsplan. Sie können beispielsweise konfigurieren, wo Sie Ihre nichtflüchtigen Daten speichern möchten.

   Weitere Informationen zum Erstellen und Überwachen von Migrationsplänen finden Sie unter Migration erstellen.

   Zum Erstellen der Migration müssen Sie die Befehlszeile verwenden. Sie können die Google Cloud Console nicht verwenden. Der vollständige Befehl lautet so:

   migctl migration create my-migration
     --source my-was-src
     --vm-id PROJECT_ID
     --intent Image
     --os-type Linux
     --app-type websphere-traditional
   

   Dabei ist PROJECT_ID die ID, die Ihrem Migrationsprojekt zugewiesen ist, und Image der Wert für das Intent-Flag. Sie verwenden "Image" aufgrund der zustandslosen Art der Arbeitslast.

3. Migrationspläne prüfen und anpassen: Nachdem Sie Migrationspläne für jede der zu migrierenden VMs generiert haben, prüfen und passen Sie jeden Migrationsplan an, um sicherzustellen, dass er Ihren Anforderungen entspricht. Weitere Informationen zum Anpassen von Migrationsplänen finden Sie unter Migrationsplan anpassen.

Migrationsartefakte und Bereitstellungsdeskriptoren generieren

Zum Generieren der Ziel-WAS-Artefakte für Ihre Anwendungen extrahiert Migrate to Containers die Anwendungen, die auf den in den Migrationsplänen konfigurierten VMs ausgeführt werden. Anschließend werden mehrere Artefakte erstellt und in einem Cloud Storage-Bucket platziert. Migrate to Containers generiert auch die Bereitstellungsdeskriptoren, die Sie anpassen und zum Bereitstellen von Instanzen der Container-Images in der Zielumgebung verwenden können.

Für jede migrierte Anwendung erstellt Migrate to Containers einen Ordner mit Docker-Kontext, den Binärdateien der Anwendung, einem Build-Script und einem WAS-Konfigurationsscript.

Sie können den Fortschritt der Containerartefakte beobachten, die Sie erstellen und migrieren. Weitere Informationen zum Überwachen einer Migration finden Sie unter Migrierte Arbeitslasten überwachen.

Generierte Ressourcen und Deskriptoren prüfen und validieren

Nachdem Sie mit Migrate to Containers Containerartefakte und Bereitstellungsdeskriptoren generiert haben, prüfen und aktualisieren Sie diese Artefakte und Deskriptoren, um sicherzustellen, dass sie Ihren Anforderungen entsprechen. Berücksichtigen Sie beispielsweise die folgenden Aspekte:

• Container-Image-Deskriptoren: Prüfen Sie die mit Migrate to Containers generierten Container-Image-Deskriptoren und achten Sie darauf, dass sie für die Containerarbeitslast geeignet sind. Informationen zum Aktualisieren von Container-Image-Deskriptoren finden Sie unter Anwendungs-Image erstellen. Sie können Attribute hinzufügen und iFixes installieren.
• Logging auf Anwendungsebene: Migrate to Containers schreibt automatisch WAS-Logs im JSON-Format. Informationen zum grundlegenden Logging finden Sie unter Logging-Konfiguration.

Weitere Informationen zum Überprüfen von Containerartefakten und Bereitstellungsdeskriptoren finden Sie unter Generierte Bereitstellungsdateien prüfen.

Containerisierte Arbeitslasten in GKE oder GKE Enterprise bereitstellen und validieren

Wenn die Bereitstellungsdeskriptoren für Ihre Arbeitslasten bereit sind, gehen Sie so vor:

1. Anwendungscontainer-Image erstellen: Erstellen Sie im Ordner mit den Anwendungsartefakten ein Anwendungscontainer-Image für die migrierten Arbeitslasten:

   bash ./build.sh
   

2. Migrierte Anwendungen in der Zielumgebung bereitstellen: Stellen Sie Ihre migrierten Anwendungen bereit:

   kubectl apply -f deployment_spec.yaml
   

3. Migrierte Arbeitslasten überwachen: Nach der Bereitstellung Ihres WAS traditional-Anwendungscontainers können Sie Informationen zur Leistung in der Zielumgebung erfassen. Weitere Informationen finden Sie unter Migrierte Arbeitslasten überwachen.

4. Migrierte Arbeitslasten einbinden: Sobald die in der Zielumgebung bereitgestellten Arbeitslasten funktionieren, binden Sie die Erstellung von Containerartefakten sowie die Bereitstellungsprozesse der Arbeitslasten in Ihre Bereitstellungsprozesse und Pipelines ein. Wenn Sie derzeit keinen automatisierten Bereitstellungsprozess haben und Ihre Arbeitslasten manuell bereitstellen, wird empfohlen, dass Sie von manuellen zu automatisierten Bereitstellungen migrieren.

Migrate to Container deinstallieren

Nachdem Sie die Migration Ihrer Arbeitslasten mit Migrate to Containers abgeschlossen haben, wird empfohlen, dass Sie:

1. Achten Sie darauf, dass Sie alle Verweise auf die Artefakte haben, die während der Migrate to Containers generiert wurden.
2. Migrate to Containers deinstallieren

Wenn Sie mit der in diesem Abschnitt beschriebenen Arbeit fertig sind, kehren Sie zu diesem Dokument zurück.

Umgebung nach der Migration optimieren

Informationen zum Abschließen der Migration finden Sie in den Richtlinien unter Umgebung nach der Migration optimieren.

Sie können diese WAS-spezifischen Optimierungen für Ihre migrierten WAS traditional-Anwendungen ausführen:

• Konfiguration externalisieren: Wenn Sie einen WAS traditional-Container erstellen, kann es zwischen Umgebungen zu Konfigurationsänderungen kommen. Damit der Container nicht für jede Umgebung neu erstellt werden muss, wird empfohlen, die WAS-Konfiguration in Attribute zu externalisieren und ConfigMaps zu verwenden, um diese Attribute beim Start des Containers festzulegen.
• Vertrauliche Daten sichern: Passwörter und andere vrtrauliche Daten sollten in Kubernetes-Secrets abgelegt werden. Verwenden Sie Kubernetes-Secrets, um Konfigurationsplatzhalter beim Containerstart zu ersetzen.

Nächste Schritte

• Best Practices zum Erstellen und Betreiben von Containern.
• Mehr über Best Practices zum Ausführen kostenoptimierter Kubernetes-Anwendungen in GKE erfahren
• VMs mit Migrate to Containers in Container migrieren
• Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center