Customize migration plan for WebSphere servers

Preview

This product or feature is covered by the Pre-GA Offerings Terms of the Google Cloud Terms of Service. Pre-GA products and features might have limited support, and changes to pre-GA products and features might not be compatible with other pre-GA versions. For more information, see the launch stage descriptions.

Review application migration reports

You can review the application migration report generated by the IBM WebSphere Application Server Migration Toolkit for Application Binaries. The toolkit generates an HTML report for each app in the source VM. View the HTML file to evaluate the app migration.

To review the application migration report:

1. Open the Cloud Storage browser in the Google Cloud console:

   Open the Cloud Storage browser

2. Navigate to the /output folder in the migration artifacts bucket on Google Cloud Storage.

3. For each app discovered in the VM you will see an HTML file named:

   app-name.ear_MigrationReport.html

4. Select the HTML file to view it, or download it locally, to evaluate the migration.

Edit the migration plan

To edit the migration plan, download the migration plan, edit it, then update it using migctl. The migration plan is represented by the AppXGenerateArtifactsFlow CRD:

1. Download the migration plan. The migration plan is represented by a AppXGenerateArtifactsFlow object:

   migctl migration get my-migration

2. Because you are going to edit this file, first make a copy so that you can recover it:

   cp my-migration.yaml my-migration-original.yaml

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

   1. Ensure that you only have one path property.

      The AppXGenerateArtifactsFlow object contains a path property for every app that Migrate to Containers discovered in the WAS traditional VM. Delete all but one path definition, and any sharedLibraries specifications, so that only one app is specified. This edit ensures that each app has its own container image.

      Note: Ensure that you first save a copy of the original AppXGenerateArtifactsFlow object so that you can later migrate any other apps in the VM.

      The AppXGenerateArtifactsFlow object lists all apps in the form:

      spec:
      appBinariesMigrationToolkit:
        applications:
        -  path: "PATH_TO_APP1"
          sharedLibraries:
          - sharedLibrary1
            sharedLibrary2
        -  path: "PATH_TO_APP2"
          sharedLibraries:
          - sharedLibrary1
        -  path: "PATH_TO_APP3" 

   2. Ensure that the app_name is unique for each app.

      The deployment field specifies the name of the app used in the deployment_spec.yaml file. Set this field to a unique value for each app in the CRD. You must ensure that you deploy each app container with its own unique app name.

      deployment:
       appName: app-name

   3. Set the tag name of the image.

      The image field value defines the name and location of images created from a migrated VM. By default, a tag corresponding to the timestamp of the migration is automatically applied to the "image_name" value. This tag is in the form:

      MM-DD-YYYY--hh:mm:ss

      You can use the timestamp to differentiate migrations. Alternatively, you can apply your own tag. For example, edit the CRD and add the rev1 tag as shown below:

      name: "image_name:rev1"

      Note: Because the tag is used to cache values, ensure that the tag is unique for all CRDs.

   4. Set any other properties you want to customize.

   5. Save the file.

4. When your edits are complete, upload the edited migration plan:

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

You can now migrate the app. After you complete the migration for one app, edit the AppXGenerateArtifactsFlow object for each additional app in the VM that you want to migrate.

Select applications

On the migration plan, the application field represents the applications to migrate. If you do not want to migrate all applications, You can remove them.

applications:
- appName: hello-world-servlet-ear
  httpEndpoints:
  - httpPort: 9080
    httpsPort: 9443
    id: defaulthttpendpoint
  image:
    name: hello-world-servlet-ear
  path: /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/config/cells/m4a-twas-ndNode01Cell/applications/Hello-World-Servlet.ear
…
- appName: commons-ejb-ear-provided-ear
  httpEndpoints:
  - httpPort: 9080
    httpsPort: 9443
    id: defaulthttpendpoint
  image:
    name: commons-ejb-ear-provided-ear
  path: /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/config/cells/m4a-twas-ndNode01Cell/applications/commons-ejb-ear-provided.ear
  sharedLibraries:
  - /opt/IBM/WebSphere/AppServer/sharedJars/commons-io-2.8.0.jar

Set the scanner options

On the migration plan, the scannerOptions field represents the argument to pass to the IBM WebSphere Application Server Migration Toolkit for Application Binaries. You can edit the arguments.

scannerOptions:
  # Setting 'includeSensitiveData: true' will upload sensitive data, if exists, such as private keys, to the artifacts repository
  includeSensitiveData: false
  sourceAppServer: was90

Note: In order to collect sensitive data, on the migration plan, under scannerOptions, modify the value of includeSensitiveData: to be true. Notice that set includeSensitiveData: true will cause uploading sensitive artifacts into the user repository. On openliberty, the sensitive data will be stored in a secret file artifact that is used when building 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

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.

JBoss

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 JBoss 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.

Apache

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 an Apache 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.

WordPress

Migrate

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