Stay organized with collections Save and categorize content based on your preferences.

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:

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.

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.

  • 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

Windows

Tomcat

WebSphere (Pre-Ga)