Installing Migrate to Containers

This topic describes how to install Migrate to Containers on a processing cluster.

A processing cluster is a Google Kubernetes Engine (GKE) or GKE Enterprise cluster with Migrate to Containers components installed, and which you use to migrate VMs before deploying them to your production cluster.

Using the steps in this topic, you use the migctl command-line tool or the Google Cloud console to install the required Migrate to Containers components on a GKE cluster you've already created.

After you have deployed your migrated VMs as images to a production cluster, assuming the processing cluster is no longer needed to perform new migrations, you can delete the processing cluster.

About migctl

Along with support in the Google Cloud console, Migrate to Containers includes the migctl command-line tool that you can use to perform all parts of a migration:

To learn how to download migctl, see Migrate to Containers downloads.

Before you begin

Installing Migrate to Containers

migctl on Google Cloud

Use migctl commands to install Migrate to Containers and configure it with the basics you need for migrating.

  1. Ensure that you created a service account for accessing Container Registry and Cloud Storage, and download the JSON key file, as described in Configuring a service account.

  2. Visit the GKE menu in Google Cloud console.

    Visit the GKE menu

  3. In the list of clusters, locate the cluster you will be using as a processing cluster and click its Connect button.

  4. In the Connect to the cluster dialog, under Command-line access, click Run in Cloud Shell to run the connect command in Cloud Shell.

    gcloud container clusters get-credentials my-cluster --zone us-central1-c --project my-project
    
  5. Set up Migrate to Containers components on your processing cluster by running the migctl setup install command in Cloud Shell and specifying the installation service account:

    migctl setup install --json-key=m4a-install.json
    
  6. Validate the Migrate to Containers installation by running the migctl doctor command.

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

    migctl doctor
    [!] Deployment
        Validation checks failed.
    

    In the following example output, the check mark indicates that Migrate to Containers has been successfully deployed and that the necessary data repositories have been configured.

    migctl doctor
    [✓] Deployment
    [✓] Docker registry
    [✓] Artifacts repo
    [!] Source Status
    

    See Defining data repositories if there is an error associated with the Docker registry or artifacts repository.

migctl on Google Distributed Cloud Virtual for Bare Metal

  1. Set your default project ID:
    gcloud config set project project-id
  2. Deploy migctl on your admin workstation:
    wget https://modernize-release.storage.googleapis.com/v1.15.0/linux/amd64/migctl
    sudo cp migctl /usr/local/bin/
    sudo chmod +x /usr/local/bin/migctl
    . <(migctl completion bash)
  3. Set up Migrate to Containers components on your processing cluster by running the migctl setup install command:
    migctl setup install --anthos-bm --gcp-project myproject --gcp-region us-central1 --json-key m4a-install.json
    When given all of the arguments including --gcp-project, --gcp-region and --json-key, migctl will create a default docker registry and artifact repositories in Container Registry and Cloud Storage respectively. This means that the migration images and artifacts will be uploaded to Google Cloud. It is possible to configure other docker registries and set them as default for migration or set them to be used for a specific migration.
  4. Validate the Migrate to Containers installation by running the migctl doctor command. Before installation has completed, you might see a message such as the following. If so, wait a few minutes for installation to finish before running migctl doctor.
    migctl doctor
      [!] Deployment
          Validation checks failed.
    In the following example output, the check mark indicates that Migrate to Containers has been successfully deployed but you have not yet configured the necessary data repositories:
    migctl doctor
      [✓] Deployment
      [!] Docker registry
      [!] Artifacts repo
      [!] Source Status
  5. Configure the data repositories required by the cluster as described in Defining data repositories.
  6. If necessary, configure an HTTPS proxy for outbound internet access as described in Configuring an HTTPS proxy.

Console

  1. Open the Migrate to Containers page in the Google Cloud console.

    Go to the Migrate to Containers page

  2. Click the Processing Clusters tab to display a table containing the available clusters.

  3. Click Add Processing Cluster.

  4. Select the type of the workload to migrate as either Linux or Windows, then select Next.

  5. Select the cluster from the drop-down list, then select Next.

  6. Select the bucket for the Artifacts repository.

    By default, Migrate to Containers uses Cloud Storage with the specified bucket name. You can optionally set the bucket name here. Make sure you have reviewed the requirements described in Defining data repositories.

  7. Select the Image repository project name.

    By default, Migrate to Containers uses the current project for Container Registry. You can optionally change the project name here. Make sure you have reviewed the requirements described in Defining data repositories.

  8. Click Continue.

  9. Specify the Artifacts repository service account used to access Cloud Storage. You can either create a new service account or select an existing one. See Configuring service accounts for more information.

  10. Click Continue to review your settings, then click Deploy to install Migrate to Containers on your cluster.

  11. When the installation completes, you see the cluster name on the Processing Clusters tab with a status of Ready.

Installation options

You can create clusters of many sizes and configurations. For example, you might have a cluster with several node pools. You then use one node pool for processing migrations, one node-pool for running workloads, and another node pool for other operations.

By default, Migrate to Containers is installed on all cluster nodes. To control which nodes are used by Migrate to Containers, you can use the --node-selectors and --tolerations options to the migctl setup install command:

  • --node-selectors LABEL1=VALUE1,LABEL2=VALUE2,...

    Specifies a comma-separated list of label-value pairs that determine the nodes used by Migrate to Containers. See Creating and managing labels for more on using labels.

  • --tolerations KEY1=VALUE1:EFFECT1,KEY2=VALUE2:EFFECT2,...

    Specifies a comma-separated list of key-value pairs associated with an effect which together specify a node taint. A toleration means that the pods can run on the node taint specified by the key-value and effect.

    If you omit EFFECT and/or VALUE, then the tolerations matches taints with KEY,VALUE (for any EFFECT) and/or KEY (for any VALUE:EFFECT).

    See Controlling scheduling with node taints for more on node taints.

What's next