使用 Migrate to Containers 将 WebSphere 应用迁移到容器

Last reviewed 2021-12-22 UTC

本文档适用于希望将 IBM WebSphere Application Server (WAS) 上运行的 Java 应用迁移到 Google Kubernetes Engine (GKE)GKE Enterprise 中运行的容器的应用所有者和云架构师。该文档会指导您完成将 WAS 传统应用从本地环境、私有托管环境或其他云服务提供商中的来源环境迁移到容器的过程。还重点介绍了使用 Migrate to Containers 自动执行迁移的优势。

在尝试使用 Migrate to Containers 将 WebSphere 虚拟机迁移到容器之前,您应事先学习 WebSphere 知识。

本文档还包含您在规划 WAS 应用迁移到容器时需要考虑的要点。本文是关于如何迁移到 Google Cloud 的系列文章中的一篇。如果您想要了解该系列文章,请参阅迁移到 Google Cloud:选择迁移路径

如果您计划使用 Migrate to Containers 将在兼容的操作系统(例如 Linux)上运行兼容 WAS 的 WAS 传统应用从支持的来源环境迁移到 GKE 或 GKE Enterprise 环境,请阅读本文档。这些来源环境可能包括以下环境:

Migrate to Containers 会自动使用 IBM Migration Toolkit for Application Binaries 来发现、检查和迁移 WAS 传统虚拟机中的所有 WAS 传统应用。然后,它会将这些 WAS 传统应用拆分到单独的 WebSphere 传统容器中。

Migrate to Containers 会发现、检查、迁移所有 WAS 传统应用并将其拆分到单独的 WebSphere 容器中。

使用 Migrate to Containers 迁移 WAS 传统应用需要较小的占用空间(最小 1 GB RAM 和 2 GB 映像大小)和较低的许可费用(WAS Network Deployment 订阅最高可节省 70%)。

通过使用 Migrate to Containers 迁移 WAS 传统应用,您可以受益于容器化环境的多个方面。之前讨论的许可费用降低。您还可以通过为您的应用创建 WAS LibertyOpen Liberty,对内置云框架进行进一步的面向未来的现代化改造。

WAS Liberty 是轻量级生产运行时,用于快速开发和部署基于 Web 和基于云的应用。WAS Liberty 基于开源 Open Liberty 项目构建而成。公司使用 WAS Liberty 和 Open Liberty 来构建基于云的 Java 微服务。

迁移到 GKE Enterprise 或 GKE 会将 WAS Network Deployment 管理器功能分流到以下产品:

下图展示了 GKE 或 GKE Enterprise 如何管理之前由 WAS Network Deployment 管理的集中式功能(例如,高可用性、工作负载部署位置和集中式配置)。特定于应用的配置是在 Docker 映像构建时进行管理的。使用基于 Docker 映像的配置可以通过 CI/CD 流程实现可重复性和自动化。

迁移会将 WAS Network Deployment 管理器功能分流到 Kubernetes、Anthos Service Mesh、Config Sync 和 Google Cloud Operations WAS Network Deployment 环境和 WAS Base 环境可以迁移到 WAS Liberty 或 Open Liberty 容器。

使用 Migrate to Containers 将 WAS 传统应用迁移到容器是工作负载现代化改造之旅中可能执行的一个步骤。迁移可帮助您转换应用,使其在云环境中运行,并避免对 WAS 传统应用进行现代化改造所需的费用高昂的重写。

理想的迁移候选对象是在受支持的 WebSphere Network Deployment、WebSphere Base 或受支持的 Java 版本上运行的应用,通过完全重写进行这些应用现代化改造的费用很高(从资源方面考虑),或者完全无法实现。如需详细了解理想的迁移候选对象,请参阅使用 Migrate to Containers 将虚拟机迁移到容器

设计迁移到 Google Cloud 的过程

如需将 WAS 传统应用从来源环境迁移到 Google Cloud 中运行的容器,请按照迁移到 Google Cloud 系列中所述的框架进行操作。

下图说明了迁移过程的路径:

迁移路径包含四个阶段。

上图演示的框架有四个阶段:

  1. 评估:在此阶段,您将评估来源环境、评估要迁移到 Google Cloud 的应用,并评估哪些 WAS 传统应用适合迁移。
  2. 规划:在此阶段,您将为 Migrate to Containers 创建基本基础架构,例如预配资源层次结构和设置网络访问。
  3. 部署:在此阶段,您将使用 Migrate to Containers 将 WAS 传统应用从来源环境迁移到 GKE 或 GKE Enterprise。
  4. 优化:在此阶段,您将开始利用云技术和功能。

评估来源环境和应用

评估阶段,您将收集有关来源环境和要迁移的应用的信息。这样做可帮助您合理调整所需的资源 - 无论是针对迁移还是目标环境。

在评估阶段,您将执行以下操作:

  1. 构建一个完整的应用清单。
  2. 根据应用的属性和依赖项对应用进行分类。
  3. 为您的团队开展 Google Cloud 培训和指导
  4. 针对 Google Cloud 构建实验和概念验证。
  5. 计算目标环境的总拥有成本 (TCO)。
  6. 选择您首先要迁移的应用。

以下部分依赖于《迁移到 Google Cloud:评估和发现工作负载》。 但是,它们提供了在评估您要使用 Migrate to Containers 迁移到容器的 WAS 传统应用时所需的特定信息。

构建您的清单

如需确定迁移范围,您必须了解自己的 WAS 传统环境。如需了解您的环境,请收集有关应用及其依赖项的信息。

构建应用清单介绍了如何在 WAS 传统环境中构建工作负载清单及其依赖项。请按照该指导信息操作并构建清单。完成该工作后,请继续阅读本文档。

现在您已构建了工作负载的清单及其依赖项,接下来可以优化该清单。评估您的组织在使用 Migrate to Containers 迁移其 WAS 传统应用时涉及的方面和功能。

在评估您的 WAS 环境以进行迁移之前,请完成使用 Migrate to Containers 将虚拟机迁移到容器以及“迁移到 Google Cloud:评估和发现您的工作负载”中的评估工作。完成该工作后,请完成工作负载清单。

如需完成工作负载清单,请考虑以下事项:

  • WAS 虚拟机中运行的操作系统:收集有关在 WAS 虚拟机中运行的操作系统及其许可的信息,并确保操作系统是兼容的操作系统和 Kubernetes 版本中列出的 64 位 Linux 操作系统。
  • 运行应用的 WAS 版本:收集有关运行应用的 WAS 版本的信息,并确保它们与 Migrate to Containers 兼容。Migrate to Containers 支持为 WAS BaseWAS Network Deployment 环境迁移传统 WAS 应用(WebSphere Application Server 传统 8.5.5.x 版本和 WebSphere Application Server 传统 9.0.5.x 版本)。

  • WAS 中部署的应用:评估在每个 WAS 中部署的应用。然后,映射应用之间以及应用与外部服务之间的依赖项。接下来,收集有关应用的配置来源的信息。例如,您是否在使用:

    • 环境变量
    • 非标准 WAS 安装路径
    • LDAP 用户注册表
    • 安全角色映射
    • 将类应用于加载器顺序的修改
  • Migrate to Containers 适合度分数:评估您的 WAS 传统应用是否适合使用 Migrate to Containers 进行迁移。Migrate to Containers 提供了可在 WAS 传统应用上运行的适合度评估工具,用于计算适合度分数。Migrate to Containers 满足一组最低要求,才能成功迁移 WAS 传统应用。在自动执行 WAS 传统应用迁移时,Migrate for Anthos 还存在一些限制。如需解决这些限制,您可以在迁移应用时手动进行配置。

  • 身份验证:WAS 提供了多种身份验证机制,例如简单的 WebSphere 身份验证机制 (SWAM)、轻量级第三方身份验证 (LTPA) 和 Kerberos。您只能将一个用户注册表实现配置为 WAS 安全网域的活跃用户注册表。Migrate to Containers 不会自动迁移身份验证详细信息。这意味着,配置身份验证通常需要在迁移期间进行一些手动配置。

  • 数据访问 (JDBC):J2EE 连接器架构定义了将 WAS 连接到企业信息系统的标准资源适配器。该适配器在企业信息系统、应用服务器和应用之间提供连接。Migrate to Containers 会自动将 JDBC 配置迁移到现代化的 WAS 容器。确保您已在迁移的应用和现有数据存储区之间启用连接。

  • 消息传递 (JMS):WAS 支持通过 Java 通讯服务 (JMS) 编程接口进行异步通信。Migrate to Containers 会自动迁移 JMS 配置信息。但是,某些配置(例如 SSL)需要一些手动迁移工作。

  • 邮件:WAS 支持通过 JavaMail API 发送电子邮件。Migrate to Containers 不会自动迁移 JavaMail 配置文件。在迁移阶段手动配置这些文件。

完成评估

构建与您的环境和 WAS 传统工作负载相关的清单后,请完成迁移到 Google Cloud:评估和发现工作负载中所述的评估阶段的其余活动。完成该工作后,请继续阅读本文档。

规划和构建基础

按照迁移虚拟机时规划和构建基础中的指导信息操作后,请完成 WAS 基础:

  1. 确认 Cloud Storage 存储桶的名称
  2. 按照以下步骤上传作为 IBM WebSphere Application Server Migration Toolkit for Application Binaries 的一部分提供的 binaryAppScanner.jar 文件:

    1. 下载 binaryAppScannerInstaller.jar 安装程序文件。在下载过程中,您必须接受许可协议。
    2. 运行以下命令以提取 binaryAppScanner.jar 文件并接受许可协议:

      java -jar binaryAppScannerInstaller.jar --acceptLicense --verbose
      
    3. 指定提取的目标目录,例如 /tmp。安装程序会在目标目录内创建一个名为 /wamt 的目录。

    4. 导航到 /wamt 目录,例如:

      cd /tmp/wamt
      
    5. binaryAppScanner.jar 文件上传到 Cloud Storage 存储桶的根目录:

      gsutil cp binaryAppScanner.jar gs://BUCKET_NAME
      

      其中 BUCKET_NAME 是您的 Cloud Storage 存储桶的名称。

设置 Migrate to Containers 介绍了如何预配和配置 Migrate to Containers 及其依赖项。按照该指南设置 Migrate to Containers。

完成该工作后,请继续阅读本文档。

将 WAS 传统应用迁移到容器

如需详细了解迁移的部署阶段,请按照将虚拟机迁移到容器中的指导信息进行操作。

生成并查看迁移计划

为 WAS 传统应用创建 Migrate to Containers 迁移计划:

  1. 将来源环境配置为 Migrate to Containers 迁移来源:为了迁移 WAS 传统应用,Migrate to Containers 需要有关运行虚拟机的源环境的信息。您可以通过执行本文档的构建您的清单部分中所述的任务来收集这些信息。如需详细了解如何配置来源环境,请参阅添加迁移来源
  2. 创建迁移计划:如需指定要从来源环境迁移到受支持的目标环境的 WAS 传统应用,请创建迁移计划,例如您可以配置要存储永久性数据的位置。

    如需详细了解如何创建和监控迁移计划,请参阅创建迁移

    如需创建迁移,您必须使用命令行,不能使用 Google Cloud 控制台。完整命令如下所示:

    migctl migration create my-migration
      --source my-was-src
      --vm-id PROJECT_ID
      --intent Image
      --os-type Linux
      --app-type websphere-traditional
    

    其中 PROJECT_ID 是分配给迁移项目的 ID,Image 是意图标志的值。由于工作负载的无状态特性,您使用“映像”。

  3. 查看并自定义迁移计划:为要迁移的每个虚拟机生成迁移计划后,请查看并自定义每个迁移计划,以确保其符合您的要求。如需详细了解如何自定义迁移计划,请参阅自定义迁移计划

生成迁移工件和部署描述符

如需为应用生成目标 WAS 工件,Migrate to Containers 需要提取您在迁移计划中配置的虚拟机中运行的应用。然后,它会创建多个工件并将其放入 Cloud Storage 存储桶中。Migrate to Containers 还会生成部署描述符,您可以进行自定义并使用它们在目标环境中部署容器映像的实例。

对于每个迁移的应用,Migrate to Containers 会创建一个包含 Docker 上下文、应用二进制文件、构建脚本和 WAS 配置脚本的文件夹。

您可以监控您创建和迁移的容器工件的进度。如需详细了解如何监控迁移,请参阅监控迁移的工作负载

检查和验证生成的资源和描述符

使用 Migrate to Containers 生成容器工件和部署描述符后,请查看并更新这些工件和描述符,以确保它们符合您的要求 - 例如,请考虑以下几个方面:

  • 容器映像描述符:查看使用 Migrate to Containers 生成的容器映像描述符,并验证它们是否足以满足容器工作负载的需求。如果需要更新容器映像描述符,请参阅构建应用映像。您可以添加属性安装 iFix
  • 应用级日志记录:Migrate to Containers 自动写入 JSON 格式的 WAS 日志。如需更改为基本日志记录,请参阅日志记录配置

如需详细了解如何查看容器工件和部署描述符,请参阅查看生成的部署文件

将容器化工作负载部署到 GKE 或 GKE Enterprise 并进行验证

工作负载的部署描述符准备就绪后,请执行以下操作:

  1. 构建应用容器映像:在您要构建的应用工件文件夹中为迁移的工作负载构建应用容器映像:

    bash ./build.sh
    
  2. 在目标环境中部署迁移的应用:部署迁移的应用:

    kubectl apply -f deployment_spec.yaml
    
  3. 监控迁移后的工作负载:部署 WAS 传统应用容器后,您可以收集有关它们在目标环境中的表现的信息。如需了解详情,请参阅监控迁移的工作负载

  4. 集成迁移的工作负载:您在目标环境中部署的工作负载运行后,请将工作负载的容器工件生成和部署流程与您的部署流程和流水线集成。如果您目前未部署自动部署流程并且手动部署工作负载,建议您从手动部署迁移到自动部署

卸载 Migrate to Containers

使用 Migrate to Containers 完成工作负载迁移后,建议您执行以下操作:

  1. 确保您拥有 Migrate to Containers 在迁移过程中生成的工件的所有引用。
  2. 卸载 Migrate to Containers

完成本部分中描述的工作后,请返回本文档。

迁移后优化环境

如需完成迁移,请参阅迁移后优化环境中的准则。

您可以为迁移的 WAS 传统应用执行以下特定于 WAS 的优化:

  • 外部化配置:构建传统 WAS 容器时,环境之间可能存在配置更改。如需避免为每个环境重新构建容器,建议您将 WAS 配置外部化为属性,并在容器启动时使用 ConfigMap 设置这些属性。
  • 保护敏感数据:密码和任何其他敏感数据都应放入 Kubernetes Secret 中。在容器启动时使用 Kubernetes Secret 替换配置占位符。

后续步骤