Anwendungen von einer IBM WAS-traditionellen VM migrieren

In den folgenden Abschnitten werden die Schritte beschrieben, mit denen Sie Anwendungen von einer traditionellen IBM WAS-VM migrieren können.

Informationen zu migctl

Migrate to Containers enthält das migctl-Befehlszeilentool, mit dem Sie alle Schritte einer Migration wie unten beschrieben ausführen können. Die Ausführung von migctl hängt von der Art der Verarbeitung ab, die für die Migration verwendet wird:

Wenn Sie in Google Cloud einen Verarbeitungscluster für Google Kubernetes Engine (GKE) oder Anthos verwenden, führen Sie in Cloud Shell migctl aus.
Wenn Sie einen GKE On-Prem-Verarbeitungscluster verwenden, folgen Sie der Installationsanleitung, um migctl auf Ihrer Administrator-Workstation zu installieren und auszuführen.

Migrationsquelle hinzufügen

Bevor Sie mit der Migration beginnen, erstellen Sie eine Migrationsquelle als die Quellplattform, von der Sie migrieren. Diese Quelle wird Ihrem Migrationsplan hinzugefügt. Sie können Migrationsquellen verwenden, die zuvor in Migrate to Containers konfiguriert wurden, um andere Linux- oder Windows-VMs zu migrieren.

Definieren Sie die Migrationsquelle aus der Sie migrieren mit dem Befehl migctl source create:

Erstellen Sie die Quelle für einen in Google Cloud bereitgestellten Verarbeitungscluster:
1. Bei Verwendung von Compute Engine als Migrationsquelle:
  1. Erstellen Sie ein Dienstkonto zur Verwendung von Compute Engine als Migrationsquelle und laden Sie die JSON-Schlüsseldatei herunter, wie unter Dienstkonto konfigurieren beschrieben.
    
    Hinweis: Bei der folgenden Anleitung wird davon ausgegangen, dass der Name der JSON-Schlüsseldatei m4a-ce-src.json lautet.
  2. Erstellen Sie die Quelle mit dem Dienstkonto:
```
migctl source create ce my-was-src --project my-project --json-key m4a-ce-src.json
```
    Dabei gibt m4a-ce-src.json das Dienstkonto an.
2. Bei Verwendung von AWS als Migrationsquelle:
```
migctl source create aws my-was-src --manager-address 1.2.3.4 --cloud-details cloud-details --cloud-extension cloud-extension
```
  Geben Sie den Namen der Migrate for Compute Engine-Erweiterung und den Cloud Details-Namen wie in Migrate for Compute Engine konfiguriert an. Weitere Informationen zu Cloud Details finden Sie unter Migrate for Compute Engine einrichten.
  
  Sie werden zur Eingabe des Passworts für Ihren Migrate for Compute Engine-Verwaltungsserver aufgefordert.
3. Bei Verwendung von Azure als Migrationsquelle:
```
migctl source create azure my-was-src --manager-address 1.2.3.4 --cloud-details cloud-details --cloud-extension cloud-extension
```
  Geben Sie den Namen der Migrate for Compute Engine-Erweiterung und den Cloud Details-Namen wie in Migrate for Compute Engine konfiguriert an. Weitere Informationen zu Cloud Details finden Sie unter Migrate for Compute Engine einrichten.
  
  Sie werden zur Eingabe des Passworts für Ihren Migrate for Compute Engine-Verwaltungsserver aufgefordert.
4. Bei Verwendung von VMware als Migrationsquelle:
```
migctl source create vmware my-was-src --manager-address 1.2.3.4 --cloud-extension cloud-extension
```
  Geben Sie den Namen der Migrate for Compute Engine-Erweiterung wie in Migrate for Compute Engine konfiguriert an.
  
  Sie werden zur Eingabe des Passworts für Ihren Migrate for Compute Engine-Verwaltungsserver aufgefordert.
Erstellen Sie die Quelle für einen lokalen Verarbeitungscluster von Anthos on VMware:
```
migctl source create local-vmware my-was-src --vc '1.2.3.4' --username 'admin'
```
Wobei:

--vc gibt den vCenter-DNS-Namen oder die vCenter-IP-Adresse an.

--username gibt den Nutzernamen für einen Nutzer an, der berechtigt ist, auf vCenter zuzugreifen. Sie werden aufgefordert, das Passwort für den Nutzer einzugeben.
Erstellen Sie die Quelle für einen Verarbeitungscluster von Anthos in AWS:
```
migctl source create local-aws local-aws-src --region my-region --access-key-id my-access-key-id
```
oder:
```
migctl source create local-aws local-aws-src --region my-region --credentials-file-path=credentials.csv
```
Wobei:

--region gibt die Google Cloud-Region Ihres Clusters an.

--access-key-id gibt die AWS-Zugriffsschlüssel-ID für einen Nutzer an, der berechtigt ist, auf AWS zuzugreifen. Sie werden aufgefordert, das Secret für die Zugriffsschlüssel-ID einzugeben. Weitere Informationen finden Sie unter Zugriffsschlüssel für IAM-Nutzer verwalten.

--credentials-file-path gibt den Pfad zu einer CSV-Datei an, die von der AWS-Konsole heruntergeladen wird und die Anmeldedaten enthält. Weitere Informationen zum Erstellen der CSV-Datei finden Sie unter AWS-IAM-Gruppen und -Instanzrollen konfigurieren.

Migration erstellen

Sie beginnen mit der Migration der Anwendungen, indem Sie eine Migration erstellen, was zur Erstellung eines Migrationsplanobjekts führt. Vor dem Ausführen der Migration ist in der Regel eine weitere Überprüfung und Anpassung des erstellten Plans erforderlich wie unten unter Migrationsplan anpassen beschrieben wird.

Zur Konfiguration und zum Monitoring des Migrationsprozesses wird ein Migrationsobjekt verwendet, das als benutzerdefinierte Kubernetes-Ressourcendefinition (CRD) implementiert ist. Weitere Informationen finden Sie in der CRD-Referenz.

Wenn Sie eine Migration erstellen, geben Sie das Flag intent entsprechend der Art Ihrer Arbeitslast an. IBM empfiehlt, in WAS-Anwendungen keine Statusinformationen aufzunehmen, sondern zum Speichern von Statusinformationen externe Daten-Repositories zu nutzen. Der Wert Image bedeutet, dass Sie die Binärdateien und die Konfiguration einer zustandslosen Anwendung migrieren. Dies ist der einzige für herkömmliche WAS-Anwendungen unterstützte intent (Zweck). Weitere Informationen zum Zweck finden Sie unter Migrationszweck festlegen.

So erstellen Sie eine Migration:

Wenn Sie Compute Engine als Migrationsquelle verwenden, beenden Sie die Quell-VM, bevor Sie eine Migration erstellen. Wenn das Migrationsobjekt erstellt wurde, können Sie die VM neu starten.

Erstellen Sie die Migration:

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

Dabei gibt my-was-src die oben erstellte Migrationsquelle und --vm-id den Namen der traditionellen WAS-VM an.

Rufen Sie den Migrationsstatus ab:
```
migctl migration status my-migration -v
```
Hinweis: Wenn eine Fehlermeldung mit "WAS_HOME not found" angezeigt wird, finden Sie weitere Informationen unter Fehler mit der Umgebungsvariable WAS_HOME beheben.

Wenn der Status anzeigt, dass der Vorgang abgeschlossen ist, können Sie mit dem nächsten Schritt fortfahren.

Hinweis: Dieser Vorgang kann einige Minuten dauern.

Migrationsplan anpassen

Prüfen Sie die Datei für den Migrationsplan, die bei der Migration erstellt wurde, und passen Sie sie an, bevor Sie mit der Migration fortfahren. Weitere Informationen finden Sie unter Migrationsplan anpassen.

Sie können auch den Bericht zur Anwendungsmigration prüfen, der vom IBM WebSphere Application Server Migration Toolkit for Application Binaries generiert wird. Das Toolkit generiert für jede Anwendung in der Quell-VM einen HTML-Bericht. Mithilfe des Inhalts dieser HTML-Datei können Sie die Anwendungsmigration evaluieren.

So prüfen Sie den Migrationsbericht für die Anwendung:

Öffnen Sie den Cloud Storage-Browser in der Google Cloud Console.

Zur Seite "Storage-Browser"
Gehen Sie auf Google Cloud Storage im Bucket "Migrationsartefakte" in den Ordner /discovery.
Für jede in der VM gefundene Anwendung wird eine HTML-Datei mit dem folgenden Namen angezeigt:

app-name.ear_MigrationReport.html
Wählen Sie die HTML-Datei aus, um sie anzusehen, oder laden Sie sie lokal herunter, um die Migration zu evaluieren.

So passen Sie den Migrationsplan an:

Zum Anpassen des Migrationsplans laden Sie ihn herunter, bearbeiten Sie ihn und aktualisieren Sie ihn dann mit migctl. Der Migrationsplan wird durch die WebSphereGenerateArtifacts CRD dargestellt:

Laden Sie den Migrationsplan herunter. Der Migrationsplan wird durch das Objekt WebSphereGenerateArtifactsFlow dargestellt:
```
migctl migration get my-migration
```
Wenn Sie diese Datei bearbeiten, erstellen Sie zuerst eine Kopie, damit Sie sie bei Bedarf wiederherstellen können:
```
cp my-migration.yaml my-migration-original.yaml
```
Bearbeiten Sie den heruntergeladenen Migrationsplan my-migration.yaml in einem Texteditor.
1. Achten Sie darauf, dass nur ein path-Attribut vorhanden ist.
  
  Das Objekt WebSphereGenerateArtifactsFlow enthält ein path-Attribut für jede Anwendung, die Migrate to Containers in der traditionellen WAS-VM ermittelt hat. Löschen Sie alle path-Definitionen und alle sharedLibraries-Spezifikationen, sodass nur eine Anwendung angegeben wird. Durch diese Änderung wird sichergestellt, dass jede Anwendung über ein eigenes Container-Image verfügt.
  
  Hinweis: Speichern Sie zuerst eine Kopie des Original-WebSphereGenerateArtifactsFlow-Objekts, damit Sie später alle anderen Anwendungen in der VM migrieren können.
  
  Das Objekt WebSphereGenerateArtifactsFlow listet alle Anwendungen im folgenden Format auf:
```
spec:
appBinariesMigrationToolkit:
  applications:
  -  path: "PATH_TO_APP1"
    sharedLibraries:
    - sharedLibrary1
      sharedLibrary2
  -  path: "PATH_TO_APP2"
    sharedLibraries:
    - sharedLibrary1
  -  path: "PATH_TO_APP3" 
```
2. Der app_name muss für jede Anwendung eindeutig sein.
  
  Das Feld deployment gibt den Namen der Anwendung an, die in der Datei deployment_spec.yaml verwendet wird. Geben Sie für dieses Feld einen eindeutigen Wert für jede Anwendung in der CRD an. Stellen Sie sicher, dass Sie jeden Anwendungscontainer mit einem eigenen eindeutigen Anwendungsnamen bereitstellen.
```
deployment:
 appName: app-name
```
3. Legen Sie den Tag-Namen des Image fest.
  
  Der Wert des Felds image definiert den Namen und den Speicherort von Images, die aus einer migrierten VM erstellt wurden. Standardmäßig wird automatisch ein Tag, das dem Zeitstempel der Migration entspricht, auf den Wert von "image_name" angewendet. Dieses Tag hat das folgende Format:
  
  MM-DD-YYYY--hh:mm:ss
  
  Sie können den Zeitstempel verwenden, um Migrationen zu unterscheiden. Alternativ können Sie ein eigenes Tag anwenden. Beispiel: Bearbeiten Sie die CRD und fügen Sie das Tag rev1 wie im Folgenden gezeigt hinzu:
  
  name: "image_name:rev1"
  Hinweis: Da das Tag zum Speichern der Werte im Cache verwendet wird, muss es für alle CRDs eindeutig sein
  .
4. Legen Sie alle weiteren Attribute fest, die Sie anpassen möchten.
5. Speichern Sie die Datei.
Wenn die Änderungen abgeschlossen sind, laden Sie den bearbeiteten Migrationsplan hoch:
```
migctl migration update my-migration --file my-migration.yaml
```

Sie können die Anwendung jetzt migrieren. Bearbeiten Sie nach Abschluss der Migration für eine Anwendung das Objekt WebSphereGenerateArtifactsFlow für jede zusätzliche Anwendung in der VM, die migriert werden soll.

Migrationsartefakte generieren und prüfen

Sie starten die Migration von VMs mit einem Befehl, der Migrationsartefakte mit dem Verarbeitungscluster generiert, den Sie unter Migrate to Containers installieren erstellt haben.

So führen Sie eine Migration aus und generieren die Migrationsartefakte:

Migration ausführen

migctl migration generate-artifacts my-migration

Rufen Sie den Migrationsstatus ab:
```
migctl migration status my-migration
```

Wenn der Status wiedergibt, dass der Vorgang abgeschlossen ist, prüfen Sie die generierten Artefakte.

Wenn Sie eine Anwendung von einer Quell-VM migrieren, wird eine Reihe von Dateien erstellt. Diese werden als Migrationsartefakte bezeichnet und zur Bereitstellung der migrierten Arbeitslast verwendet. Nach Abschluss der Migration einer Arbeitslast prüfen Sie die für die Bereitstellung verwendeten Migrationsartefakte.

Die Migrationsartefakte befinden sich in einem Cloud Storage-Bucket. Im Bucket sind die folgenden Dateien enthalten:

Dockerfile: Das Dockerfile, mit dem das Image für die migrierte Anwendung erstellt wird.
build.sh: Das Skript zum Erstellen der Arbeitslast für Ihre Bereitstellung mithilfe von gcloud builds.
deployment_spec.yaml: Die YAML-Datei, die zum Bereitstellen der von build.sh erstellten Arbeitslast verwendet wird. Sie können kubectl apply mit dieser Datei verwenden, um die Arbeitslast auf einem Cluster wie einem Produktions- oder Testcluster bereitzustellen. Diese Datei enthält auch alle von der Anwendung benötigten Portzuordnungen.
Für jede Anwendung in der VM gibt es:
- Eine .ear-Datei, die das Binärprogramm der Anwendung enthält.
- Ein .py-Python-Skript, das zum Erstellen des Anwendungscontainers verwendet wird.

So rufen Sie das generierte Artefakt auf:

Laden Sie mit folgendem Befehl die generierten Artefaktdateien herunter:
```
migctl migration get-artifacts my-migration
```
Mit diesem Befehl werden die folgenden Dateien zur Bereitstellung der migrierten Anwendung heruntergeladen: Dockerfile, build.sh, und deployment_spec.yaml.

Im nächsten Abschnitt Anwendungscontainer-Image erstellen wird gezeigt, wie der Anwendungscontainer erstellt wird.
Sie können diese Dateien auch in der Google Cloud Console aufrufen und herunterladen:
1. Öffnen Sie den Cloud Storage-Browser in der Google Cloud Console.
  
  Zur Seite "Storage-Browser"
2. Wählen Sie den für die Migration verwendeten Bucket aus.
3. Für die migrierte Anwendung werden die .ear- und .py-Dateien angezeigt.
4. Sie können die Dateien Dockerfile, build.sh und deployment_spec.yaml zusammen mit allen anderen Artefakten sehen.
5. Wählen Sie eine Datei aus, um deren Inhalt aufzurufen oder die Datei herunterzuladen.

Anwendungs-Container-Image erstellen

Erstellen Sie mithilfe der Migrationsartefakte ein Container-Image für die migrierte Anwendung, das Sie dann im Zielcluster bereitstellen können. Verwenden Sie build.sh, um den Container zu erstellen, der als Teil der Migrationsartefakte angelegt wird:

Erstellen Sie den Anwendungscontainer mit dem Build-Skript:
```
chmod +x ./build.sh
./build.sh`
```
Legen Sie optional den Diensttyp in deployment_spec.yaml fest.

Standardmäßig wird von Migrate to Containers der Diensttyp auf ClusterIP festgelegt. Dadurch ist der Dienst nur für die Pods im Bereitstellungscluster verfügbar.

Wenn Sie extern auf den Dienst zugreifen möchten, legen Sie den Diensttyp auf LoadBalancer oder auf einen anderen von Ihrer Bereitstellung erforderten Typ fest. Beispiele:
```
apiVersion: v1
kind: Service
…
spec:
  …
  type: LoadBalancer
```

Sie können jetzt den Anwendungscontainer bereitstellen.

Anwendungs-Container in einem Zielcluster bereitstellen

Nachdem Sie das Container-Image der Anwendung erstellt haben, stellen Sie es im Zielcluster bereit.

Der Zielcluster muss die unter Systemanforderungen für Migrationen beschriebenen Voraussetzungen erfüllen.
Stellen Sie das Container-Image mithilfe der Datei deployment_spec.yaml bereit:
```
kubectl apply -f deployment_spec.yaml
```
Wenn Sie die Datei deployment_spec.yaml bearbeitet haben, damit der Dienst extern zugänglich ist, wie oben beschrieben, ermitteln Sie die öffentliche IP-Adresse und den Port des Dienstes:
```
kubectl get service
```
In den Spalten Externe IP-Adresse werden die IP-Adresse und der Port angezeigt.
Öffnen Sie die externe IP-Adresse und den Port des Dienstes in einem Browser:

http://IP:PORT

Migrierte Arbeitslasten überwachen

Standardmäßig werden Loginformationen für bereitgestellte Anwendungen von Prozessen, die von init gestartet wurden, in stdout geschrieben.

Sie können auch den Inhalt von /var/log/syslog auf Loginformationen hin prüfen.

Umgang mit Fehlern in der Umgebungsvariablen WAS_HOME

Die Umgebungsvariable WAS_HOME gibt den Installationsort von WAS traditional an, z. B. /opt/IBM/WebSphere/AppServer/. Die Migration to Containers verwendet diesen Wert, wenn Sie eine Migration erstellen, um Skripts auszuführen, die Informationen zu einer Anwendung abrufen und den Pfad eines Anwendungsprofils bestimmen.

Migrate to Containers versucht, den WebSphere-Installationsordner automatisch zu finden. Dazu wird nach gängigen Pfaden gesucht, in denen Linux-Binärdateien installiert sind. Wenn Migrate to Containers den Installationsordner nicht findet oder den von der automatischen Suche bestimmten Ordner überschreiben kann, können Sie den Wert von WAS_HOME festlegen.

Wenn Migrate to Containers beim Erstellen einer Migration den falschen Wert WAS_HOME verwendet, protokolliert Migrate to Containers einen Fehler. Dieser Fehler wird angezeigt, wenn Sie den Status der Migration prüfen:

migctl migration status MIGRATION_NAME -v

Der Fehler wird im folgenden Format angezeigt:

Warning  PodFailure 2m55s (x49 over 123m) WebSphereDiscoveryTask MIGRATION_NAME
Pod reached error state. Retrying by recreating pod. Details: Container `lister` terminated: (no termination message provided).
Container `aggregator` terminated: (no termination message provided).
Container `websphere-discoverer` terminated:
{"code": "DIS-11", "reason": "WAS_HOME not found", "description": "WAS_HOME installation directory was not found"}.

So legen Sie den Wert von WAS_HOME explizit fest:

Wenn Sie migctl zum Erstellen der Migration verwenden, übergeben Sie beim Erstellen der Migration den Wert von WAS_HOME:

migctl  migration create  MIGRATION_NAME \
 --source SOURCE_NAME --vm-id VM_ID --app-type websphere-traditional \
 --parameters WAS_HOME_paths=/FOLDER_PATH/

Wenn Sie CRD-Dateien für die Migration verwenden, bearbeiten Sie die YAML-Datei der Migration, um den Pfad festzulegen:

apiVersion: anthos-migrate.cloud.google.com/v1beta2
kind: Migration
metadata:
name: my-migration
namespace: v2k-system
annotations:
  anthos-migrate.cloud.google.com/initial-intent: Image
spec:
osType: Linux
parameters:
- name: WAS_HOME_paths
  value: /FOLDER_PATH/
sourceSnapshot:
sourceProvider: my-ce-src
sourceId: my-id

Führen Sie den Migrationserstellungsvorgang noch einmal aus.