Modernize traditional workloads

This topic describes how to modernize VM-based workloads into containers that run on Google Kubernetes Engine (GKE), GKE cluster, or the Cloud Run platform. You can migrate workloads from VMs running on VMware or Compute Engine, giving you the flexibility to containerize your existing workloads.

To perform the modernization (also referred to as migration), you use a processing cluster that you created with the steps in Installing Migrate to Containers.

The basic flow to migrate a workload is similar across supported workloads types. There are some differences between workload types, so you need to identify your workload type in the sections below for an outline of the procedure and detailed information per step.

Supported workloads

Migrate a Linux VM

Migration procedure

The following diagram illustrates the migration steps for a Linux workload:

Diagram of steps to migrate with Migrate to Containers
  1. Add a migration source.

    You start a migration by configuring a source that represents the source platform from which you will be migrating. If you already have a source from a previous migration and the VMs you're migrating are from the same source, you can re-use it.

  2. Create a migration.

    Create a migration object with an initial migration plan.

  3. Migrate Linux data.

    Choose whether you want to migrate data or not.

  4. Customize your migration plan.

    Edit the migration plan for your specific requirements before executing the migration.

  5. Execute the migration.

    Execute the migration to extract the container artifacts, including the container image and Dockerfile. Use these artifacts to deploy the container to your testing environment or to production.

  6. Monitor a migration.

    Monitor the progress of a migration and inspect migration activity logs.

  7. Delete a migration.

    Delete the migration to free up any resources used by it.

Migrate a Windows IIS application

Migration procedure

The following diagram illustrates the migration steps for a Windows workload:

Diagram of steps to migrate with Migrate to Containers

The steps to migrate with Migrate to Containers are the following:

  1. Add a migration source.

    You start a migration by configuring a source that represents the source platform from which you are migrating. If you already have a source from a previous migration and the VMs you're migrating are from the same source, you can re-use it.

  2. Create a migration plan.

    Create a migration object with an initial migration plan".

  3. Customize your migration plan.

    Edit the migration plan for your specific requirements before executing the migration.

  4. Execute the migration.

    Execute the migration to extract the container artifacts, which include the Dockerfile and other files necessary to build a container image.

  5. Monitor the migration.

    Monitor the progress of a migration and inspect migration activity logs.

  6. Build a Windows container image

    Use the generated artifacts to build a Windows container that you can then deploy to a cluster.

  7. Delete a migration.

    Delete the migration to free up any resources used by it.

Supported features

Migrate to Containers: Windows currently supports migrating IIS .Net framework sites. You may split the sites into single purpose images, or group them as you wish.

To have a better indication of which sites can be migrated on a source VM, try running the Migration Center discovery client CLI offline assessment.

Migrate a Tomcat server

The following diagram illustrates the migration steps for a Tomcat workload:

Diagram of steps to migrate with Migrate to Containers

When you use Migrate to Containers to migrate your Tomcat workloads, you can leverage Tomcat's features and architecture to:

  • Automatically separate subsets of applications into individual containers.
  • Retain your Tomcat application's existing keystores, truststores, and certificates from the source VM.
  • Dynamically determine optimal memory allocation for JVM applications.
  • Copy specific data volumes and data volume claims from your source VMs.

Prerequisites

  • A Linux VM based Apache Tomcat app server v8.5 and later.
  • Determine the fit of the workload for migration by running an offline assessment.
  • Configure a Cloud cluster for migrating Linux VMs.

Migration procedure

The steps to migrate with Migrate to Containers are the following:

  1. Add a migration source.

    You start a migration by configuring a source that represents the source platform from which you are migrating. If you already have a source from a previous migration and the VMs you're migrating are from the same source, you can re-use it.

  2. Create a migration.

    Create a migration object with an initial migration plan".

  3. Migrate Tomcat data.

    Choose whether you want to migrate data or not.

  4. Customize your migration plan.

    Edit the migration plan for your specific requirements before executing the migration.

  5. Execute the migration.

    Execute the migration to extract the container artifacts, which include the Dockerfile and other files necessary to build a container image.

  6. Monitor the migration.

    Monitor the progress of a migration and inspect migration activity logs.

  7. Build a Tomcat container image

    Use the generated artifacts to build a container that you can then deploy to a cluster.

  8. Delete a migration.

    Delete the migration to free up any resources used by it.

Unsupported features

The following Tomcat features are not supported:

  • Clustering/Session replication.

  • Windows support for Tomcat migrations using Windows workloads.

Migrate WebSphere traditional applications

Migration overview

IBM WebSphere Application Server (WAS) traditional is a software framework that hosts Java-based workloads. Migrate to Containers lets you modernize app workloads running in WAS traditional by converting them to application containers. You can then deploy the app containers to GKE or GKE Enterprise cluster on Google Cloud.

About migrating WebSphere Application Server traditional apps

A WAS traditional VM can contain multiple apps. Migrate to Containers helps you automate the modernization of WAS apps to containers by discovering deployed apps in the source VM and automatically suggesting the configuration for the modernization.

Google requires that you migrate each app to its own container image (ibmcom/websphere-traditional, ibmcom/websphere-liberty or openliberty/open-liberty). You can then test and deploy the migrated apps individually, rather than having to test and deploy multiple apps together.

Migrate WAS apps to individual app containers.

The migration source can be WAS ND or WAS base. The target will be a Liberty or traditional WAS base container, and the respective ND clustering features will be delegated to Kubernetes.

Requirements

Confirm that your migration and deployment environments are compatible with Migrate to Containers by reviewing the following system requirements.

Requirements for migrating WAS traditional apps

Before you begin migrating, ensure that your IBM WAS traditional environment and migration processing cluster meet the requirements described below.

WAS traditional system requirements

Migrate to Containers supports the migration of apps hosted on the following versions of IBM WAS:

  • WebSphere Application Server traditional 8.5.5.x
  • WebSphere Application Server traditional 9.0.5.x

In order for Migrate to Containers to process a VM containing a WAS traditional app, Migrate to Containers extracts two types of configurations from the VM:

  • The configuration of each application.

  • The configuration of the target profile. A profile defines the runtime environment of a WAS including ports, JVM settings, and more.

The Migrate to Containers software automates the use of the IBM WebSphere Application Server Migration Toolkit for Application Binaries in your GKE Enterprise or GKE cluster to discover, assess, and generate migration reports and configuration scripts. You are solely responsible for procuring, licensing, and using the toolkit.

Before you can start a migration, you must upload the toolkit to a Google Cloud Storage bucket in your account. See Set up the binaryAppScanner.jar for this procedure.

Compatible VM operating systems

Migrate to Containers supports migrations of WAS traditional apps from VMs installed with the 64-bit Linux operating systems listed at Compatible VM operating systems.

Processing cluster requirements

Use a Google Kubernetes Engine (GKE) or GKE Enterprise cluster to run the Migrate to Containers components that perform the transformations required to migrate an app from a source VM to a target container. For apps in a WAS VM:

The processing cluster must use a Linux operating system listed at Compatible processing cluster operating systems.

See Choose the type of processing cluster for information on creating each type of processing cluster.

Requirements for deploying migrated apps

After migrating your apps, ensure that your application environment and target cluster meet the requirements described below.

Target cluster requirements

Use a Google Kubernetes Engine (GKE), GKE Enterprise cluster on Google Cloud, or Google Distributed Cloud Virtual for Bare Metal. The target cluster must use a Linux operating system listed at Compatible workload cluster operating systems.

As part of performing a migration, Migrate to Containers creates a Docker image representing a migrated WAS app and uploads it to a Docker registry. You must ensure the target cluster has read access to the Docker registry as described here.

Supported target containers
  • WebSphere Application Server traditional
  • WebSphere Application Server Liberty
  • Open Liberty

Before you begin

Before you begin a migration, you must first perform the following tasks.

Install Migrate to Containers

Install Migrate to Containers on your processing cluster. A processing cluster is a Google Kubernetes Engine (GKE) or GKE Enterprise cluster with Migrate to Containers components installed, and which you use to migrate VMs. See Installation overview for all installation instructions.

Optionally set up Migrate to Virtual Machines

To use Migrate to Containers to migrate Websphere workloads to Google Cloud from VMware you must set up Migrate to Virtual Machines which handles the transport.

For more information, see Set up Migrate to Virtual Machines.

Set up the binaryAppScanner.jar

Migrate to Containers automates the use of the binaryAppScanner.jar, available as part of the IBM WebSphere Application Server Migration Toolkit for Application Binaries, to extract configuration information and files for WAS applications in the source VM.

Before you can perform a migration, you must:

To set up binaryAppScanner.jar:

  1. Download the installer file, binaryAppScannerInstaller.jar, from IBM Support.You must accept the license agreement as part of the download.

  2. Run the following command to extract the binaryAppScanner.jar file and to accept the License Agreement:

    java -jar binaryAppScannerInstaller.jar --acceptLicense --verbose
    
  3. Specify the target directory for the extraction. For example, /tmp. The installer creates a directory named /wamt below the target directory.

  4. Navigate to the /wamt directory. For example:

    cd /tmp/wamt
    
  5. Create two Dockerfiles with the following commands:

    FROM us-docker.pkg.dev/migrate-modernize-public/modernize-plugins-prod/websphere-traditional-container-discover:1.3.1
    ADD binaryAppScanner.jar /
    
    FROM us-docker.pkg.dev/migrate-modernize-public/modernize-plugins-prod/websphere-traditional-container-extract:1.3.1
    ADD binaryAppScanner.jar /
    
  6. Build and push the docker images:

    gcloud builds submit --timeout 1h -t gcr.io/PROJECT_ID/websphere-traditional-container-discover-with-scanner:1.3.1 --project PROJECT_ID
    gcloud builds submit --timeout 1h -t gcr.io/PROJECT_ID/websphere-traditional-container-extract-with-scanner:1.3.1 --project PROJECT_ID
    
  7. Edit the plugin CRD to bundle it with binary-scanner as following:

    $ kubectl edit appxplugins.anthos-migrate.cloud.google.com -n v2k-system websphere-traditional-container
    
    # Set the value of spec.discoveryImage and spec.generateArtifactsImage:
    
    apiVersion: anthos-migrate.cloud.google.com/v1beta2
    kind: AppXPlugin
    metadata:
      namespace: v2k-system
      name: websphere-traditional-container
      labels:
        anthos-migrate.cloud.google.com/preview-type: public
      annotations:
        anthos-migrate.cloud.google.com/display-name: WebSphere traditional container
    spec:
      discoverImage: gcr.io/PROJECT_ID/websphere-traditional-container-discover-with-scanner:1.3.1
      discoverCommand:
      - /ko-app/websphere-traditional
      - discover
      generateArtifactsImage: gcr.io/PROJECT_ID/websphere-traditional-container-extract-with-scanner:1.3.1
      generateArtifactsCommand:
      - /ko-app/websphere-traditional
      - extract
      parameterDefs:
      - name: was-home
        usage: Path of the WebSphere WAS_HOME on the original instance.
        envVar: APPX_WAS_HOME
    
  8. Save the CRD.

Migration procedure

The following diagram illustrates the migration steps for a WebSphere workload:

Migrate WAS apps to individual app containers.

The steps to migrate with Migrate to Containers are the following:

  1. Add a migration source.

    Add the migration source that represents the source platform.

  2. Create a migration.

    Create a migration object with an initial migration plan.

  3. Migrate WebSphere data.

    Choose whether you want to migrate data or not.

  4. Customize the migration plan.

    Edit the migration plan for your specific requirements before executing the migration. You migrate one WAS app per migration.

  5. Execute the migration.

    Execute the migration to extract the container artifacts, which include the Dockerfile and other files necessary to build a container image.

  6. Generate and review migration artifacts.

    Perform the migration to generate the app container. You can monitor the migration process, and when finished, review the artifacts in preparation for building the deployable app image.

  7. Monitor the migration.

    Monitor the progress of a migration and inspect migration activity logs.

  8. Build an app container image.

    Use the generated artifacts to build a container that you can then deploy to a cluster.

  9. Deploy an app container to a target cluster.

    Deploy the image to your target cluster.

  10. Delete a migration.

    Delete the migration to free up any resources used by it.

Migrate a JBoss server

The following diagram illustrates the migration steps for a JBoss workload:

Diagram of steps to migrate with Migrate to Containers

When you use Migrate to Containers to migrate your JBoss workloads, you can leverage the features and architecture of JBoss to copy specific data volumes and data volume claims from your source VMs.

Prerequisites

  • JBoss AS app server v8.1.0 and later, or, JBoss EAP app server v7.0, v7.1, v7.2, v7.3, and v7.4.

  • Configure a Google Cloud cluster for migrating VMs.

Migration procedure

The steps to migrate with Migrate to Containers are the following:

  1. Add a migration source.

    You start a migration by configuring a source that represents the source platform from which you're migrating. If you already have a source from a previous migration and the VMs you're migrating are from the same source, you can reuse it.

  2. Create a migration.

    Create a migration object with an initial migration plan.

  3. Migrate JBoss data.

    Choose whether you want to migrate data or not.

  4. Customize your migration plan.

    Edit the migration plan for your specific requirements before executing the migration.

  5. Execute the migration.

    Execute the migration to extract the container artifacts, which include the Dockerfile and other files necessary to build a container image.

  6. Monitor the migration.

    Monitor the progress of a migration and inspect migration activity logs.

  7. Build a JBoss container image

    Use the generated artifacts to build a container that you can then deploy to a cluster.

  8. Delete a migration.

    Delete the migration to free up any resources used by it.

Unsupported features

The following JBoss features are not supported:

  • Sensitive data and secrets - Sensitive data and secrets stored inside the JBOSS_HOME/standalone directory will not be removed. This data will be included in the container image.
  • JBoss logger configuration - The logger configuration will be taken as is from the source machine. It will not be modified during the migration process unless the jbossServer.tar.gz is modified manually before building the JBoss container.
  • Memory allocation - Java Virtual Machine (JVM) resources allocation will be taken from the community container and will not depend on the source machine JVM resources.
  • Environment variables - Environment variables and JVM parameters from the source machine will not be migrated to the container image.
  • Offline assessment - Determining the fit of your JBoss workload for migration is not supported.

Migrate an Apache server

The following diagram illustrates the migration steps for an Apache workload:

Diagram of steps to migrate with Migrate to Containers

When you use Migrate to Containers to migrate your Apache workloads, you can leverage Apache's features and architecture to:

  • Copy specific data volumes and data volume claims from your source VMs.

Prerequisites

  • A Linux VM based Apache 2 Webserver.
  • Configure a Google Cloud cluster for migrating Linux VMs.

Migration procedure

The steps to migrate with Migrate to Containers are the following:

  1. Add a migration source.

    You start a migration by configuring a source that represents the source platform from which you are migrating. If you already have a source from a previous migration and the VMs you're migrating are from the same source, you can re-use it.

  2. Create a migration.

    Create a migration object with an initial migration plan.

  3. Migrate data.

    Choose whether you want to migrate data or not.

  4. Customize your migration plan.

    Edit the migration plan for your specific requirements before executing the migration.

  5. Execute the migration.

    Execute the migration to extract the container artifacts, which include the Dockerfile and other files necessary to build a container image.

  6. Monitor the migration.

    Monitor the progress of a migration and inspect migration activity logs.

  7. Build an Apache container image

    Use the generated artifacts to build a container that you can then deploy to a cluster.

  8. Delete a migration.

    Delete the migration to free up any resources used by it.

Unsupported features

Apache 1 workloads are not supported.

The following Apache features are not supported:

  • Certificates.

  • Windows support for Apache migrations using Windows workloads.

Migrate a WordPress site

When you use Migrate to Containers to migrate your WordPress workloads, you can leverage the features and architecture of WordPress to copy specific data volumes and data volume claims from your source VMs.

Prerequisites

  • WordPress version 4.0 or later, running on a Linux VM-based Apache 2 web servers.
  • Configure a Google Cloud cluster for migrating Linux VMs.

Migration procedure

The steps to migrate with Migrate to Containers are the following:

  1. Add a migration source.

    You start a migration by configuring a source that represents the source platform from which you're migrating. If you already have a source from a previous migration and the VMs you're migrating are from the same source, you can reuse it.

  2. Create a migration.

    Create a migration object with an initial migration plan.

  3. Customize your migration plan.

    Edit the migration plan for your specific requirements before executing the migration.

  4. Migrate WordPress data.

    Review and edit the data migration plan for your specific requirements before executing the migration.

  5. Execute the migration.

    Execute the migration to extract the container artifacts, which include the Dockerfile and other files necessary to build a container image.

  6. Monitor the migration.

    Monitor the progress of a migration and inspect migration activity logs.

  7. Build a WordPress container image

    Use the generated artifacts to build a container that you can then deploy to a cluster.

  8. Delete a migration.

    Delete the migration to free up any resources used by it.

Unsupported features

WordPress sites running on hosts other than Linux VM-based Apache 2 web server are not supported.

The following WordPress features are not supported:

  • WordPress database migration.

    For more information on migrating an application that relies on a database, see Ensure databases are accessible.

  • Exporting data stored locally on the WordPress server, such as media uploads, plugins, and themes, to an NFS drive.

    For more information on exporting locally stored data to NFS, see Define NFS mounts as Persistent Volumes.

  • Horizontal scaling of the migrated deployment.

    The data stored locally on the WordPress server is exported to Compute Engine persistent disk, which is mounted to the migrated deployment pod. A Compute Engine persistent disk cannot be attached to multiple pods and therefore prevents horizontal scaling of the migrated deployment.

  • Exporting certificates and sensitive data to Kubernetes secret objects.

What's next