Monolithische VM migrieren – Migration und Bereitstellung

Wichtig: Die Migrate to Containers-UI in der Google Cloud Console,migctl und CRDs, die Verarbeitungscluster zum Migrieren von Arbeitslasten zu Google Cloud verwenden, wurden verworfen. Sie werden für bestehende Nutzer bis Mai 2024 unterstützt. Danach sind sie nicht mehr verfügbar. Wenn Sie mit Migrate to Containers noch nicht vertraut sind, verwenden Sie die Migrate to Containers CLI, um Migrationen auf Ihrem lokalen Computer auszuführen. Weitere Informationen finden Sie unter Architektur der Migrate to Containers CLI.

Wenn ein Verarbeitungscluster eingerichtet und Migrate to Containers installiert ist, können Sie die Migration ausführen. Zuerst müssen Sie eine relevante Migrationsquelle für Ihren Verarbeitungscluster hinzufügen und einen Migrationsplan für Ihre VM generieren. Nachdem Sie den Plan geprüft und an Ihre Anforderungen angepasst haben, können Sie Kubernetes-Artefakte für den GKE-Cluster generieren und bereitstellen, in dem der Rest Ihrer Anwendung bereits ausgeführt wird.

Ziele

Am Ende dieser Anleitung haben Sie Folgendes gelernt:

• Wie Sie eine Migrationsquelle hinzufügen.
• Wie Sie einen Migrationsplan aus Ihrer VM-Arbeitslast erstellen.
• Wie Sie den Migrationsplan prüfen und anpassen.
• Wie Sie Migrationsartefakte für den GKE-Cluster generieren und bereitstellen.

Hinweis

Diese Anleitung ist eine Fortsetzung der Anleitung Erkennung und Bewertung. Bevor Sie mit dieser Anleitung beginnen, befolgen Sie die Anweisungen auf dieser Seite, um die Erkennungs-Tools auf der monolithischen VM auszuführen und Ihren Verarbeitungscluster zu erstellen.

Monolithische VM beenden

Bevor Sie die Migration ausführen, müssen Sie die monolithische VM beenden, um eine versehentliche Unterbrechung oder Datenkorruption zu vermeiden, die auftreten kann, wenn Daten während der Migrationsprozesse verschoben werden.

Hinweis: In einer Produktionsumgebung können Sie für Ihre Nutzer geplante Ausfallzeiten planen oder ein Duplikat der nicht in der Produktion verwendeten VM migrieren.

1. Rufen Sie in der Google Cloud Console die Seite „VM-Instanzen“ auf.

   Zur Seite "VM-Instanzen"

2. Klicken Sie auf das Kästchen am linken Ende der Zeile für die VM ledgermonolith-service.

3. Klicken Sie oben auf der Seite auf die Schaltfläche Beenden, um die VM zu beenden.

4. Warten Sie, bis die VM vollständig beendet wurde. Dies kann 1–2 Minuten dauern.

Migrieren Sie die VM.

Bevor Sie die VM migrieren können, müssen Sie eine Migrationsquelle erstellen, die die Quellplattform (Compute Engine oder VMWare) darstellt.

Quelle hinzufügen

1. Rufen Sie in der Google Cloud Console die Seite Migrate to Containers auf.

   Zur Seite "Migrate to Containers"

2. Klicken Sie auf dem Tab Quellen und Kandidaten auf Quelle hinzufügen.

3. Wählen Sie unter Verarbeitungscluster auswählen den Migrationsverarbeitungscluster aus der Drop-down-Liste aus und klicken Sie auf Weiter.

4. Geben Sie den Namen der Quelle als ledgermonolith-source an.

5. Legen Sie den Quelltyp auf Compute Engine fest und klicken Sie auf Weiter.

6. Achten Sie darauf, dass das richtige Projekt als Quellprojekt ausgewählt ist.

7. Erstellen Sie ein Dienstkonto, mit dem Sie Compute Engine als Migrationsquelle verwenden können. Wählen Sie dazu Neues Dienstkonto erstellen aus.

8. Klicken Sie auf Weiter und dann auf Quelle hinzufügen.

Migration erstellen

1. Rufen Sie in der Google Cloud Console die Seite Migrate to Containers auf.

   Zur Seite "Migrate to Containers"

2. Klicken Sie auf dem Tab Migrationen auf Migration erstellen.

3. Legen Sie Name der Migration auf ledgermonolith-migration fest.

4. Wählen Sie die Migrationsquelle aus, die Sie im vorherigen Schritt erstellt haben: ledgermonolith-source.

5. Legen Sie die Arbeitslasttyp auf Linux system container fest.

6. Legen Sie als Instanzname ledgermonolith-service fest.

7. Klicken Sie auf Migration erstellen. Dies kann 1–2 Minuten dauern.

   Wenn die Migration abgeschlossen ist, wird in der Spalte Status der Eintrag Migrationsplan generiert angezeigt.

8. Klicken Sie in der Tabelle auf den Namen der Migration ledgermonolith-migration, um die Detailseite zu öffnen.

9. Erstellen Sie auf dem Tab Datenkonfiguration ein neues Volume, um die PostgreSQL-Datenbank /var/lib/postgresql der VM zu migrieren. Die Konfiguration sollte so aussehen:

   volumes:
    - deploymentPvcName: ledgermonolith-db
      folders:
     # Folders to include in the data volume, e.g. "/var/lib/postgresql"
     # Included folders contain data and state, and therefore are automatically excluded from a generated container image
      - /var/lib/postgresql
      newPvc:
        spec:
          accessModes:
          - ReadWriteOnce
          resources:
            requests:
              storage: 10G
   

   Dadurch wird die Datenbank während der gesamten Migration beibehalten. Klicken Sie anschließend auf Save (Speichern).

10. Achten Sie darauf, dass Ihr Dienst im Migrationsplan unter deployment den Namen ledgermonolith-service, den Port 8080 und das Protokoll TCP hat. Das Objekt sollte so aussehen:

    ...
    endpoints:
      - name: ledgermonolith-service
        port: 8080
        protocol: TCP
    ...
    

11. Klicken Sie auf Speichern und Artefakte erstellen, um den Migrationsprozess zu starten. Dieser Vorgang dauert etwa 7–8 Minuten.

    Migrate to Containers generiert für diese VM folgende Artefakte:

    • Ein Docker-Image des VM-Prozesses
    • Ein StatefulSet und ein Service, um den neu migrierten Prozess auszuführen
    • Ein Namespace und ein DaemonSet für die Containerlaufzeit.
    • Ein PersistentVolumeClaim und ein PersistentVolume für die PostgreSQL-Datenbank.

Migrierte Arbeitslast bereitstellen

Im vorangegangenen Abschnitt haben Sie Ihre monolithische VM erfolgreich zu einer Reihe von Kubernetes-Ressourcen migriert, die in einem Cluster bereitgestellt werden können. Sie können diese Ressourcen nun auf Ihrem Bank of Anthos-Cluster bereitstellen, die Anwendung so rekonfigurieren, dass sie mit dem richtigen Endpunkt für Ihren neu migrierten Verzeichnisdienst spricht, und prüfen, ob alles funktioniert.

1. Nachdem die Migrationsartefakte generiert wurden, können Sie eine Verbindung zum Verarbeitungscluster herstellen und die Artefakte in Ihre Cloud Shell-Umgebung herunterladen.

   gcloud container clusters get-credentials migration-processing --zone COMPUTE_ZONE --project PROJECT_ID
   cd ${HOME}/bank-of-anthos/src/ledgermonolith/
   migctl migration get-artifacts ledgermonolith-migration
   

2. Stellen Sie eine Verbindung zum Bank of Anthos-Cluster her und stellen Sie die generierten Kubernetes-Ressourcen bereit. Installieren Sie außerdem eine Containerlaufzeit mit migctl für den Cluster, damit Sie den neu migrierten Pod ausführen können.

   gcloud container clusters get-credentials boa-cluster --zone COMPUTE_ZONE --project=PROJECT_ID
   migctl setup install --runtime
   kubectl apply -f ${HOME}/bank-of-anthos/src/ledgermonolith/deployment_spec.yaml
   

   Fetching cluster endpoint and auth data.
   kubeconfig entry generated for boa-cluster.
   
   applying resources to the cluster
   namespace/v2k-system created
   daemonset.apps/runtime-deploy-node created
   
   statefulset.apps/ledgermonolith-service created
   service/ledgermonolith-service-java created
   persistentvolumeclaim/data-pvc-0-4e1b2e0e-021f-422a-8319-6da201a960e5 created
   persistentvolume/pvc-4d41e0f2-569e-415d-87d9-019490f18b1c created
   

3. Bearbeiten Sie die ConfigMap, die die Verzeichnishosts enthält, sodass sie auf Ihren neuen Kubernetes-Pod verweisen, nicht auf die monolithische Verzeichnis-VM, die nicht mehr verwendet wird.

   sed -i 's/'.c.PROJECT_ID.internal'//g' ${HOME}/bank-of-anthos/src/ledgermonolith/config.yaml
   kubectl apply -f ${HOME}/bank-of-anthos/src/ledgermonolith/config.yaml
   

4. Löschen Sie alle Pods, um sie mit der neuen Konfiguration neu zu erstellen.

   kubectl delete pods --all
   

   Mit dem folgenden Befehl können Sie den Status der Pods aufrufen:

   kubectl get pods
   

   Es kann einige Minuten dauern, bis alle Pods einsatzbereit sind.

   NAME                           READY   STATUS    RESTARTS   AGE
   accounts-db-0                  1/1     Running   0          5m43s
   contacts-d5dcdc87c-jbrhf       1/1     Running   0          5m44s
   frontend-5768bd978-xdvpl       1/1     Running   0          5m44s
   ledgermonolith-service-0       1/1     Running   0          5m44s
   loadgenerator-8485dfd-582xv    1/1     Running   0          5m44s
   userservice-8477dfcb46-rzw7z   1/1     Running   0          5m43s
   

5. Wenn alle Pods auf Running gesetzt sind, können Sie die externe IP-Adresse des LoadBalancer frontend ermitteln.

   kubectl get service frontend
   

   NAME       TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)        AGE
   frontend   LoadBalancer   10.79.248.161   ##.##.##.##.    80:31304/TCP   46m
   

6. Öffnen Sie einen Browser und rufen Sie die Webseite unter der oben angegebenen externen IP-Adresse auf. Verwenden Sie dabei HTTP und nicht HTTPS.

   http://EXTERNAL_IP
   

   Sie sollten sich mit den Standardanmeldedaten anmelden und Transaktionen sehen können. Die angezeigten Transaktionen stammen aus dem monolithischen Verzeichnis, das nun in einen Kubernetes-Container migriert wurde.

   

Nächste Schritte

Sie wissen nun, wie Sie einen Migrationsplan aus Ihrer VM-Arbeitslast erstellen und anpassen sowie die Migration Ihrer VM in containerisierte Artefakte durchführen können. Nun können Sie zum nächsten Abschnitt des Tutorials übergehen: Optimierung.

Denken Sie nach Abschluss der Anleitung daran, Ihr Google Cloud-Projekt und Ihre Ressourcen zu bereinigen.

Bereinigen

Um unnötige Google Cloud-Gebühren zu vermeiden, sollten Sie die für diese Anleitung verwendeten Ressourcen direkt nach dem Beenden löschen. Diese Ressourcen sind:

• Der GKE-Cluster boa-cluster
• Der GKE-Cluster migration-processing
• Die Compute Engine-VM ledgermonolith-service

Sie können diese Ressourcen entweder manuell löschen oder das Projekt in der unten stehenden Anleitung löschen. Dadurch werden auch alle Ressourcen entfernt.

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:

• Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
• Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, statt das gesamte Projekt.

Wenn Sie mehrere Architekturen, Anleitungen und Kurzanleitungen durcharbeiten möchten, können Sie die Überschreitung von Projektkontingenten verhindern, indem Sie Projekte wiederverwenden.

Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.

Zur Seite „Ressourcen verwalten“

Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.

Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.

Nächste Schritte

• Weitere Informationen zur Optimierung (Tag 2)