Execute a migration

You begin migrating VMs with a command that generates target container artifacts and extracts them using the processing cluster you created in Installing Migrate to Containers.

This topic describes how to execute a migration to:

• Extract workload artifacts from the VM into a container image and data volume (for stateful workloads).
• Copy a container image of your VM into a container registry.
• Generate migration deployment artifacts you can use for production deployments.

Once this step has completed, you'll be able to:

• Test the image and data volume (for stateful workloads) on the processing cluster.

  Though you haven't yet deployed the image to a separate cluster, it is runnable and testable. Once migration is complete, the image is not connected with the source VM.

• Deploy the image and data volume (for stateful workloads) to another cluster.

Before you begin

To succeed, you should have first done the following:

• Create a migration to generate a migration plan.
• Customize the migration plan according to your workload type:
  • Linux - Customize the migration plan.
  • Windows - Customize the migration plan.
  • Tomcat - Customize the migration plan.
  • WebSphere (Pre-GA) - Customize the migration plan.

Execute the migration and generating artifacts

Use the migctl migration generate-artifacts command or the GCP Console to generate target container artifacts as part of processing a VM for migration.

Note: When generating artifacts, migctl queries the current health of the artifact repositories. If the configured repository is not valid, migctl prints a message indicating whether or not the repository is ready, and an associated error message.

migctl

1. Execute the migration:

   migctl migration generate-artifacts my-migration

2. Get the migration status:

   migctl migration status my-migration

Console

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

   Go to the Migrate to Containers page

2. Click the Migrations tab to display a table containing the available migrations.

3. In the row for the desired migration, select Generate artifacts in the Next steps dropdown.

4. View the status of a migration by:

   • Viewing the Status column for the row for your migration.

   • Clicking the migration Name. The migration Details tab opens. Click the Monitoring tab to see the detailed status, or the Events tab to see migration events.

5. When the Status of the migration is Artifacts generated you can move on to the next step.

CRD

Linux, Windows, and Tomcat

1. Get the name of the AppXGenerateArtifactsFlow using the name specified in the Migration yaml when you created the migration:

   kubectl get migrations.anthos-migrate.cloud.google.com -n v2k-system my-migration  -o jsonpath={.status.migrationPlanRef.name}

2. Create an AppXGenerateArtifactsTask my-generate.yaml file to define a generate artifacts task.

   In this file, migration specifies the migration name when you created the migration, and flow represents the AppxGenerateArtifactsFlow of the migration which you got on previous step:

   apiVersion: anthos-migrate.cloud.google.com/v1beta2
   kind: AppXGenerateArtifactsTask
   metadata:
    name: my-migration-task
    namespace: v2k-system
   spec:
    migration:
      name:  my-migration
    flow:
      name:  appx-generateartifactsflow-my-migration

3. Apply the file:

   kubectl apply -f my-generate.yaml

When you generate artifacts for workloads, Migrate to Containers writes the artifacts and then uploads them to a Cloud Storage bucket. The artifact directory file contains:

• Dockerfile - The Dockerfile used to build the image for your migrated VM.
• deployment_spec.yaml - The YAML file that configures your workload.

• secrets.yaml - A Tomcat-based directory will also contain a secrets file.

  You can use kubectl apply with this file to deploy the workload to a cluster, such as a production or test cluster.

• Directories and files that are extracted from the source and used by the Dockerfile.

WebSphere (Pre-GA)

The migration artifacts are located in a Cloud Storage bucket. Included in the bucket are the following files:

• Dockerfile.twas and Dockerfile.openliberty: The Dockerfile.twas and Dockerfile.openliberty files used to build the image for your migrated app.

• build.sh: The script to build container images for the migrated applications, using gcloud builds.

• twas_deployment_spec.yaml: The YAML file used to deploy the workload image created by build.sh. You can use kubectl apply with this file to deploy the workload to a cluster, such as a production or test cluster. This file also includes any port mappings required by the app.

  Note: When using Open Liberty as your WebSphere target, the deployment yaml is named openliberty_deployment_spec.yaml and it accompanies a secrets file named liberty-secrets.yaml.

• For each app in the VM, the following is generated:

  • An .ear file containing the application binary.

  • A .py Python script used to build the app container.

What's next

Linux

Migrate

1. Add a migration source.
2. Create a migration plan.
3. Migrate data.
4. Customize your migration plan.
5. Execute the migration.
6. Monitor a migration.
7. Delete a migration.

Deploy

1. Review generated artifacts.
2. Configure logging.
3. Mounting external volumes.
4. Deploy a workload to a target cluster.
5. Deploy migrated VMs.
6. Post-migration image updates.
7. Monitor migrated workload.
8. Test your migrate app and validate the migration.

Windows

Migrate

1. Add a migration source.
2. Create a migration plan.
3. Customize your migration plan.
4. Execute the migration.
5. Monitor the migration.
6. Build a Windows container image.
7. Delete a migration.

Deploy

1. Deploy a workload to a target cluster.
2. Deploy migrated VMs.
3. Monitor migrated workload.
4. Test your migrate app and validate the migration.

Tomcat

Migrate

1. Add a migration source.
2. Create a migration.
3. Migrate data.
4. Customize your migration plan.
5. Execute the migration.
6. Monitor the migration.
7. Build a Tomcat container image.
8. Delete a migration.

Deploy

1. Deploy a workload to a target cluster.
2. Deploy migrated VMs.
3. Monitor migrated workload.
4. Test your migrate app and validate the migration.

WebSphere (Pre-Ga)

Migrate

1. Migration overview.
2. Requirements.
3. Before you begin.
4. Add a migration source.
5. Create a migration plan.
6. Migrate data.
7. Customize the migration plan.
8. Execute the migration.
9. Monitor the migration.
10. Build an app container image.
11. Deploy an app container to a target cluster.
12. Delete a migration.
13. Troubleshooting.

Deploy

1. Deploy a workload to a target cluster.
2. Deploy migrated VMs.
3. Monitor migrated workload.
4. Test your migrate app and validate the migration.