Migrating a monolith VM - Discovery and assessment

Before you are able to migrate VM workloads using Migrate to Containers, you must first confirm that the workloads are suited for migration. You will learn how you can quickly assess that fit using discovery tools. Additionally, you will get ready for the migration phase by creating a processing cluster which you install Migrate to Containers onto.

Objectives

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

• Determine your workload's fit for migration by using the Linux discovery tool.
• Create a processing cluster specific to your migration environment.
• Install Migrate to Containers.

Before you begin

This tutorial is a follow-up of the Overview and setup tutorial. Before starting this tutorial, follow the instructions on that page to set up your project and deploy Bank of Anthos.

Use the discovery tools

In this section, you learn how to use the migration CLI tools to collect information on your candidate monolith VM and process whether that VM is suited for migration using Migrate to Containers.

1. Still using Cloud Shell, create an SSH session into your ledger monolith VM. If asked for a passphrase, leave it blank by pressing the enter key.

   gcloud compute ssh ledgermonolith-service --tunnel-through-iap
   

2. Create a directory for the Linux discovery tool's collection script and analysis tool.

   mkdir m4a && cd m4a
   

3. Download the collection script to the VM and make it executable.

   curl -O "https://mfit-release.storage.googleapis.com/1.11.0/mfit-linux-collect.sh"
   chmod +x mfit-linux-collect.sh
   

4. Download the analysis tool, mfit, to the VM and make it executable.

   curl -O "https://mfit-release.storage.googleapis.com/1.11.0/mfit"
   chmod +x mfit
   

5. Run the collection script on the VM.

   sudo ./mfit-linux-collect.sh
   

   The collection script generates a TAR archive named m4a-collect-ledgermonolith-service-TIMESTAMP.tar and saves it in the current directory. The timestamp is in the format YYYY-MM-DD-hh-mm.

6. Run the analysis tool to import the archive, assess the VM, and generate a report.

   ./mfit assess sample m4a-collect-ledgermonolith-service-TIMESTAMP.tar --format json > ledgermonolith-mfit-report.json
   

   The analysis tool generates a JSON file named analysis-report-<timestamp>.json and saves it in the current directory.

7. Exit from the SSH session.

   exit
   

8. To view the output of the migration discovery tool, you first copy the resulting report from the VM to your Cloud Shell environmment.

   gcloud compute scp --tunnel-through-iap \
     ledgermonolith-service:~/m4a/ledgermonolith-mfit-report.json ${HOME}/
   

9. Download the analysis report to your local machine.

   cloudshell download ${HOME}/ledgermonolith-mfit-report.json
   

10. Open the Migrate to Containers page in the Cloud console.

    Go to the Migrate to Containers page

11. In the Fit Assessment tab, click Browse and select the JSON report you have just downloaded on your local machine.

12. Click Open. This is going to read the report and generate the results in a readable format. Notice your ledgermonolith-service VM in the list of assessed VMs.

13. Open your VM's detailed report by clicking on its name.

    The VM's fit result should say Needs minor effort with an added suggested because of the integrated database which is inside the VM. Everything else looks good.

Create a processing cluster

In the following step, you create the GKE cluster that is used as a processing cluster. This is where you install Migrate to Containers and execute the migration. You are intentionally not using the same cluster as the one where Bank of Anthos is running to not disrupt its services. Once the migration is successfully completed, you can safely delete this processing cluster.

1. Create a new Kubernetes cluster to use as a processing cluster.

   Note: Be sure you specify the same zone here that you specified when creating the VM.

   gcloud container clusters create migration-processing \
     --project=PROJECT_ID --zone=COMPUTE_ZONE --machine-type e2-standard-4 \
     --image-type ubuntu --num-nodes 1 \
     --subnetwork default --scopes "https://www.googleapis.com/auth/cloud-platform" \
     --addons HorizontalPodAutoscaling,HttpLoadBalancing
   

2. Open the Migrate to Containers page in the Cloud console.

   Go to the Migrate to Containers page

3. In the Processing Clusters tab, click Add Processing Cluster.

4. Select Linux as the workloads type then click Next.

5. Select the cluster you created above, migration-processing, from the drop-down list, then click Next.

6. Execute each of the commands in Cloud Shell to:

   • Create a service account that allows Migrate to Containers to access Container Registry and Cloud Storage.
   • Install Migrate to Containers components.
   Note: You are prompted to authorize Cloud Shell when you run the first command.

7. Use the last Cloud Shell command to monitor the installation status.

   Before the installation has completed, you might see a message such as the following. If so, wait a few minutes for the installation to finish before running migctl doctor again.

   [!] Deployment
      validation job is in-progress
   

   In the following example output, the check mark indicates that Migrate to Containers has been successfully deployed.

   [✓] Deployment
   [✓] Docker Registry
   [✓] Artifacts Repository
   [✗] Source Status
      No source was configured. Use 'migctl source create' to define one.
   [!] Default storage class
   

   Note: It's normal that Source Status shows [✗] until you define your first migration source.

8. Select Done after installation succeeds.

Next steps

Now that you have learned how to use the migration discovery tools to assess if your VM is suited for migration using Migrate to Containers, as well as creating your processing cluster in preparation for the migration, you can move on to the next section of the tutorial, Migration and deployment.

If you end the tutorial here, don't forget to clean up your Google Cloud project and resources.

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.

Caution: Deleting a project has the following effects:

• Everything in the project is deleted. If you used an existing project for this tutorial, when you delete it, you also delete any other work you've done in the project.
• Custom project IDs are lost. When you created this project, you might have created a custom project ID that you want to use in the future. To preserve the URLs that use the project ID, such as an appspot.com URL, delete selected resources inside the project instead of deleting the whole project.

If you plan to explore multiple tutorials and quickstarts, reusing projects can help you avoid exceeding project quota limits.

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.