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 Anthos 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:

When using a Google Kubernetes Engine (GKE) or Anthos processing cluster in Google Cloud, run migctl in Cloud Shell.
When using an Anthos on bare metal processing cluster, you can install and run migctl on your admin workstation.

Before you begin

Complete the migration prerequisites for your migration environment:
- Prerequisites for migrating Linux VMs using Google Cloud processing clusters.
- Prerequisites for migrating Windows IIS Applications using Google Cloud processing clusters.
Configure your environment as described in Enabling Google services and configuring service accounts.
Configure a processing cluster.

This cluster is a Google Kubernetes Engine (GKE) or Anthos cluster created specifically for migrating VMs with Migrate to Containers.
To run the install or uninstall commands with migctl, it is recommended that you have admin permissions for the cluster on which you're installing.

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.

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.

Note: The following instructions assume that the name of the JSON key file is m4a-install.json.
Visit the GKE menu in Google Cloud console.

Visit the GKE menu
In the list of clusters, locate the cluster you will be using as a processing cluster and click its Connect button.
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
```
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
```
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
```
Note: Source Status shows [!] until you define your first migration source. See Adding a migration source more (Linux) or Adding a migration source more (Windows).
Note: By default, Migrate to Containers uses the Container Registry (GCR) for the Docker registry and Cloud Storage for the artifacts repository. If you want to add additional repositories, see Defining data repositories.

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

migctl on Anthos on bare metal

Set your default project ID:
```
gcloud config set project project-id
```
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)
```
Note:
The final command requires that you have installed the bash completion package. If you have not installed it, you can install it for your specific Linux version. For example, for CentOS, install it by using the command:
```
sudo yum -y install bash-completion
```
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.
Note: The only supported artifact repositories are Cloud Storage and S3. For more information see Defining data repositories.
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
```
Note: Source Status shows [!] until you define your first migration source. See Adding a migration source more (Linux) or Adding a migration source more (Windows).

Note: Artifacts repo and Docker registry show [✓] when you have installed a default repo.
Configure the data repositories required by the cluster as described in Defining data repositories.
If necessary, configure an HTTPS proxy for outbound internet access as described in Configuring an HTTPS proxy.

Console

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

Go to the Migrate to Containers page
Click the Processing Clusters tab to display a table containing the available clusters.
Click Add Processing Cluster.
Select the type of the workload to migrate as either Linux or Windows, then select Next.

Note: The system requirements for the cluster are different for migrating Linux and Windows workloads, and for on-prem migrations. See Configuring a cluster overview for more.
Select the cluster from the drop-down list, then select Next.

Note: If you do not have an existing cluster, select Create a new Kubernetes Engine Cluster. See Configuring a cluster overview for more.
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.
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.
Click Continue.
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.
Click Continue to review your settings, then click Deploy to install Migrate to Containers on your cluster.
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

Learn how to upgrade to the latest version.
Learn how to define data repositories.
Learn how to configure an HTTPS proxy.