Migrating a monolith VM - Migration and deployment

With a processing cluster set-up and Migrate for Anthos and GKE installed, you are ready to perform the migration. First, you need to add a relevant migration source for your processing cluster as well as generate a migration plan for your VM. After reviewing and customizing the plan to your needs, you are able to generate and deploy Kubernetes artifacts onto the GKE cluster where the rest of your application is already running.

Objectives

At the end of this tutorial, you will have learned how to:

  • Add a migration source.
  • Create a migration plan from your VM workload.
  • Review and customize the migration plan.
  • Generate and deploy migration artifacts to your GKE cluster.

Before you begin

This tutorial is a follow-up of the Discovery and assessment tutorial. Before starting this tutorial, follow the instructions on that page to run the discovery tools on the monolith VM and create your processing cluster.

Stop the monolith VM

Before you perform the migration, you must stop the monolith VM to avoid unintentional disruption or data corruption which could occur if data is in movement during migration processes.

  1. In the Google Cloud Console, go to the VM instances page.

    Go to the VM instances page

  2. Select the checkbox at the left end of the row for the ledgermonolith-service VM.

  3. At the top of the page, click the Stop button to stop the VM.

  4. Wait for the VM to be fully stopped. This may take 1-2 minutes.

Migrate the VM

Now that your migration candidate VM is fully stopped, you can start preparing for the migration and execute it. You first need to create a source to designate your processing cluster as the designated cluster for your Compute Engine migration. Then, you can initiate a full migration of your VM.

Add a source

  1. Open the Migrate for Anthos and GKE page in the Cloud Console.

    Go to the Migrate for Anthos and GKE page

  2. In the Sources tab, click Add Source.

  3. Select the migration-processing cluster from the drop-down list and click Next.

  4. Specify the Name of the migration as ledgermonolith-source.

  5. Set the Source type to Compute Engine and click Next.

  6. Ensure the right project is selected as the source project.

  7. Create a service account that enables you to use Compute Engine as a migration source by selecting Create a new service account.

  8. Click Next and then Add Source.

Create a migration

  1. Open the Migrate for Anthos and GKE page in the Cloud Console.

    Go to the Migrate for Anthos and GKE page

  2. In the Migrations tab, click Create Migration.

  3. Set the Migration name as ledgermonolith-migration.

  4. Select the migration source you created in the previous step: ledgermonolith-source.

  5. Set the VM OS type to Linux.

  6. Set the source Instance name to ledgermonolith-service.

  7. Set the Migration intent as Image & Data.

  8. Click Create Migration. This may take 1-2 minutes.

    When the migration completes, the Status column displays Migration plan generated.

  9. In the table, click on the Name of your migration,ledgermonolith-migration to open the details page.

  10. Select the YAML tab.

  11. In the migration plan, under dataVolumes, replace the placeholder <folder> with the location of the VM's PostgreSQL database, /var/lib/postgresql. The object should look like this:

    ...
    dataVolumes:
      # Folders to include in the data volume, e.g. "/var/lib/mysql"
      # Included folders contain data and state, and therefore are automatically   excluded from a generated container image
      # Replace the placeholder with the relevant path and add more items if needed
      - folders:
        - /var/lib/postgresql
    ...
    

    This will make sure that you persist the database throughout the migration.

  12. Still in the migration plan, under deployment, make sure that your service has the name ledgermonolith-service, port 8080, and protocol TCP. The object should look like this:

    ...
    endpoints:
      - name: ledgermonolith-service
        port: 8080
        protocol: TCP
    ...
    
  13. Click Save and generate artifacts to begin the migration process. This process will take approximately 7-8 minutes.

    The artifacts generated by Migrate for Anthos and GKE for this VM are:

    • A Docker image of the VM process.
    • A StatefulSet and a Service to run the newly migrated process.
    • A Namespace and a DaemonSet to hold the container runtime.
    • A PersistentVolumeClaim and a PersistentVolume to hold the PostgreSQL database.

Deploy the migrated workload

In the previous section, you have successfully migrated your monolith VM to a set of Kubernetes resources that can be deployed in a cluster. You can now deploy these resources onto your Bank of Anthos cluster, reconfigure the application for it to talk to the right endpoint for your newly migrated ledger service, and verifying that it all works.

  1. Now that the migration artifacts has been generated, you can connect to the processing cluster and download the artifacts to your Cloud Shell environment.

    gcloud container clusters get-credentials migration-processing --zone COMPUTE_ZONE --project PROJECT_ID
    migctl migration get-artifacts ledgermonolith-migration
    
  2. Connect to the Bank of Anthos cluster and deploy the generated Kubernetes resources. Additionally, install a container runtime using migctl for your cluster to be able to run your newly migrated Pod.

    gcloud container clusters get-credentials boa-cluster --zone COMPUTE_ZONE
    migctl setup install --runtime
    kubectl apply -f 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. Edit the ConfigMap containing the ledger hosts to point to your new Kubernetes Pod, rather than the ledger monolith VM that is no longer in service.

    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. Delete all Pods to recreate them with your new configuration.

    kubectl delete pods --all
    

    You can view the state of the Pods using the following command:

    kubectl get pods
    

    It may take a few minutes for all the Pods to be up and running.

    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. Once all the Pods are set to Running, you can find the frontend LoadBalancer's external IP address.

    kubectl get service frontend
    
    NAME       TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)        AGE
    frontend   LoadBalancer   10.79.248.161   ##.##.##.##.    80:31304/TCP   46m
    
  6. Open a browser and visit the web page at the external IP address found above (be sure to use HTTP, rather than HTTPS).

    http://EXTERNAL_IP
    

    You should be able to login with the default credentials and see transactions. The transactions you see are coming from the ledger monolith which has now been migrated to a Kubernetes container.

    Screenshot of Bank of Anthos

Summary

You have started this tutorial with a live application composed of multiple services, some living in a GKE cluster and some living on a VM in Compute Engine. With only a few easy steps and without any code change or difficult refactorization, you have successfully migrated a monolithic service along with a database from a VM to the GKE cluster, thus reducing compute costs and increasing the ease of development for developers.

Clean up

To avoid unnecessary Google Cloud charges, you should delete the resources used for this tutorial as soon as you are done with it. These resources are:

  • The boa-cluster GKE cluster
  • The migration-processing GKE cluster
  • The ledgermonolith-service Compute Engine VM

You can either delete these resources manually, or follow the steps below to delete your project, which will also get rid of all resources.

  • In the Cloud Console, go to the Manage resources page.

    Go to Manage resources

  • In the project list, select the project that you want to delete, and then click Delete.
  • In the dialog, type the project ID, and then click Shut down to delete the project.
  • What's next