Customize migration plan for WordPress sites

You should review the migration plan file that resulted from creating a migration. Customize the file before executing the migration. The details of your migration plan are used to extract the workload container artifacts from the source.

This section describes the contents of the migration and the kinds of customizations that you might consider before you execute the migration and generate deployment artifacts.

Before you begin

This topic assumes that you've already created a migration and have the migration plan file.

Set up the database

WordPress requires a database connection, Migrate to Containers does not automatically migrate it. Ensure that the database is accessible from the target cluster.

Edit the migration plan

You can edit the migration plan by using the migctl tool or the Google Cloud console.

migctl

You must download the migration plan before you can edit it:

  1. Download the migration plan.

    migctl migration get my-migration

  2. Edit the downloaded migration plan, my-migration.yaml, in a text editor.

  3. When your edits are complete, save and upload the revised migration plan:

    migctl migration update my-migration --main-config my-migration.yaml

  4. Repeat these steps if more edits are necessary.

Console

Edit the migration plan in the Google Cloud console by using the YAML editor.

  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 your desired migration, select the migration Name to open the Details tab.

  4. Select the YAML tab.

  5. Edit the migration plan as necessary.

  6. When you are done editing, you can either:

    1. Save the migration plan. You will then have to manually execute the migration to generate the migration artifacts. Use the procedure shown in Executing a migration.

    2. Save and generate the artifacts. Execute the migration by using your edits to generate the migration artifacts. The process is the same as described in Executing a migration. You can then monitor the migration as described in Monitoring a migration.

CRD

You must download the migration plan, edit it, then apply it. The migration plan is stored inside the appXGenerateArtifactsConfig field of the AppXGenerateArtifactsFlowSpec CRD.

  1. Get the name of the AppXGenerateArtifactsFlow:

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

    The naming pattern is returned in the form of appx-generateartifactsflow-id.

  2. Get the migration plan by name and write to a file named my-plan.yaml:

    kubectl -n v2k-system get appxgenerateartifactsflows.anthos-migrate.cloud.google.com -o jsonpath=            {.spec.appXGenerateArtifactsConfig} appx-generateartifactsflow-id > my-plan.yaml

  3. Edit the migration plan as necessary.

  4. Apply the file:

    kubectl patch appxgenerateartifactsflows.anthos-migrate.cloud.google.com --type merge -n v2k-system --patch '{"spec": {"appXGenerateArtifactsConfig": '"$(jq -n --rawfile plan my-plan.yaml '$plan')"'}}' appx-generateartifactsflow-id

Migration plan structure

The migration plan for a JBoss workload has the following structure, which you can customize as described in the following sections.

sites:
- # Image name. Edit this to change the artifacts naming.
  imageName: wordpress
  # Parent WordPress image for the generated container image.
  fromImage: wordpress:6.1-php7.4-apache
  # WordPress root directory.
  rootDirectory: /var/www/html/
  # Database connection values.
  databaseValues:
  - name: DB_NAME
    value: database_name_here
  - name: DB_USER
    value: username_here
  - name: DB_PASSWORD
    value: password_here
  - name: DB_HOST
    value: host_here

To add information as needed, review your migration plan details and guiding comments.

Specifically, consider edits around the following sections.

Specify the Docker image

On the migration plan, we generate a Docker community image tag based on the WordPress version.

If you want to change the Docker community image, or provide your own docker image, you can modify the fromImage tag in your migration plan using the following format:

# Parent WordPress image for the generated container image.
  fromImage: wordpress:6.1-php7.4-apache

Specify the database connection configuration

The databaseValues section contains the database connection configuration extracted from the VM. Modify these values to change the database connection.

These values are passed to the migrated pod.

Data migration plan structure

The data migration plan for a WordPress workload has the following structure:

volumes:
- deploymentPvcName: wordpress-pvc
  folders:
  - /var/www/html/wp-content
  newPvc:
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 10G

The uploaded content, plugins, and themes that reside in the wp-content folder in your WordPress VM are exported to a PVC. The PVC is attached and mounted to the migrated pod.

If you updated the data configuration plan, upload it to continue with the migration.

What's next

Linux

Migrate using Google Cloud

  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 using Google Cloud

  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. Prepare a cluster for deployment.
  2. Deploy migrated VMs.
  3. Monitor migrated workload.
  4. Test your migrate app and validate the migration.

Tomcat

Migrate using local machine

  1. Set up for migration.
  2. Copy the file system.
  3. Create a migration plan.
  4. Customize your migration plan.
  5. Execute the migration.
  6. Manage usage statistics.

Migrate using Google Cloud

  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 and deploy container images.
  8. Delete a migration.

Deploy

  1. Prepare a cluster for deployment.
  2. Build and deploy container images.
  3. Monitor migrated workload.
  4. Test your migrate app and validate the migration.

WebSphere

Migrate using local machine

  1. Set up for migration.
  2. Copy the file system.
  3. Create a migration plan.
  4. Customize your migration plan.
  5. Execute the migration.
  6. Manage usage statistics.

Migrate using Google Cloud

  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. Prepare a cluster for deployment.
  2. Build and deploy container images.
  3. Monitor migrated workload.
  4. Test your migrate app and validate the migration.

JBoss

Migrate using local machine

  1. Set up for migration.
  2. Copy the file system.
  3. Create a migration plan.
  4. Customize your migration plan.
  5. Execute the migration.
  6. Manage usage statistics.

Migrate using Google Cloud

  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 and deploy container images.
  8. Delete a migration.

Deploy

  1. Prepare a cluster for deployment.
  2. Build and deploy container images.
  3. Monitor migrated workload.
  4. Test your migrate app and validate the migration.

Apache

Migrate using local machine

  1. Set up for migration.
  2. Copy the file system.
  3. Create a migration plan.
  4. Customize your migration plan.
  5. Execute the migration.
  6. Manage usage statistics.

Migrate using Google Cloud

  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 an Apache container image.
  8. Delete a migration.

Deploy

  1. Prepare a cluster for deployment.
  2. Build and deploy container images.
  3. Monitor migrated workload.
  4. Test your migrate app and validate the migration.

WordPress

Migrate using Google Cloud

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

Deploy

  1. Prepare a cluster for deployment.
  2. Build and deploy container images.
  3. Monitor migrated workload.
  4. Test your migrate app and validate the migration.