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.
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.
When using an Anthos on bare metal processing cluster, you can install and run
migctlon 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.
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
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.
Visit the GKE menu in Google Cloud console.
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 installcommand 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
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 [!] 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 Anthos on bare metal
- Set your default project ID:
gcloud config set project project-id
- Deploy migctl on your admin workstation:
sudo cp migctl /usr/local/bin/
sudo chmod +x /usr/local/bin/migctl
. <(migctl completion bash)
- 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.jsonWhen given all of the arguments including
migctlwill 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.
- 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
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
- 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.
Open the Migrate to Containers page in the Google Cloud console.
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.
Select the cluster from the drop-down list, then select Next.
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.
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.
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
migctl setup install command:
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.
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.
- Learn how to upgrade to the latest version.
- Learn how to define data repositories.
- Learn how to configure an HTTPS proxy.