在 Azure App 服务 上将 WebSphere 应用程序迁移到 JBoss EAP

本指南介绍在想要迁移现有 WebSphere 应用程序以使用 JBoss EAP 在 Azure App 服务上运行时应注意的内容。

预迁移

若要确保迁移成功,请在开始之前完成以下各节中所述的评估和清点步骤。

清点服务器容量

记录当前生产服务器的硬件(内存、CPU、磁盘)、平均值和峰值请求计数,以及资源利用率。 无论选择了哪种迁移路径,都将需要此信息。 例如,帮助指导选择App 服务计划非常有用。

可用App 服务计划层的列表显示内存、CPU 核心、存储和定价信息。 请注意,App 服务上的 JBoss EAP 仅适用于 高级版 V3独立 V2 App 服务 计划层。

清点所有机密

检查生产服务器或服务器上的所有属性和配置文件,了解任何机密和密码。 请确保在 WAR 中检查 ibm-web-bnd.xml。 还可以在应用程序中查找包含密码或凭据的配置文件。 这些文件可能包括 Spring Boot 应用程序、 application.propertiesapplication.yml 文件。

清点所有证书

记录用于公共 SSL 终结点的所有证书。 可以通过运行以下命令来查看生产服务器上的所有证书:

keytool -list -v -keystore <path to keystore>

验证支持的 Java 版本是否正常运行

Azure App 服务上的 JBoss EAP 支持 Java 8 和 11。 因此,需验证应用程序能否使用该受支持的版本正确运行。 如果当前服务器使用受支持的 JDK(如 Oracle JDK 或 IBM OpenJ9),则此验证尤其重要。

若要获取当前的 Java 版本,请登录到生产服务器并运行以下命令:

java -version

清点 JNDI 资源

清点所有 JNDI 资源。 某些资源(如 JMS 消息代理)可能需要迁移或重新配置。

在应用程序中

检查 WEB-INF/ibm-web-bnd.xml 文件和/或 WEB-INF/web.xml 文件。

确定是否使用数据库

如果应用程序使用任何数据库,则需捕获以下信息:

  • 数据源名称。
  • 连接池配置。
  • JDBC 驱动程序 JAR 文件的位置。

确定是否使用以及如何使用文件系统

使用应用程序服务器上的文件系统需要重新配置,在极少数情况下需要体系结构更改。 文件系统可由 WebSphere 共享模块或应用程序代码使用。 可以识别下面的部分或所有情况。

只读静态内容

如果应用程序当前提供静态内容,则需为其提供一个备用位置。 可能需要考虑将静态内容移到 Azure Blob 存储,并添加 Azure CDN,方便用户在全球范围内快速下载。 有关详细信息,请参阅 Azure 存储中的静态网站托管快速入门:将 Azure 存储帐户与 Azure CDN 集成。 还可以直接将静态内容部署到 Azure Spring Apps Enterprise 计划中的应用。 有关详细信息,请参阅 部署 Web 静态文件

动态发布的静态内容

如果应用程序允许那些通过应用程序上传/生成但在创建后不可变的静态内容,则可将上述 Azure Blob 存储和 Azure CDN 与 Azure 函数配合使用,以便处理上传和 CDN 刷新操作。 我们提供了一个示例实现,用于通过 Azure Functions 进行静态内容的上传和 CDN 预加载操作。 还可以直接将静态内容部署到 Azure Spring Apps Enterprise 计划中的应用。 有关详细信息,请参阅 部署 Web 静态文件

动态或内部内容

对于应用程序经常写入和读取的文件(例如临时数据文件),或仅对应用程序可见的静态文件,可以将Azure 存储装载到App 服务文件系统中。 有关详细信息,请参阅从 Linux 上的应用服务中的 Azure 存储提供内容

确定应用程序是否依赖于计划的作业

计划的作业(如 Quartz 计划程序任务或 Unix cron 作业)不应与 Azure 应用服务配合使用。 Azure 应用服务不会阻止你部署内含计划任务的应用程序。 但是,如果应用程序横向扩展,则同一个计划的作业可能会按照计划期间运行多次。 这种情况可能会导致意外的后果。

若要在 Azure 上执行计划的作业,请考虑将 Azure Functions 与计时器触发器配合使用。 有关详细信息,请参阅适用于 Azure Functions 的计时器触发器。 无需将作业代码本身迁移到函数中。 函数可以直接在应用程序中调用 URL 来触发作业。

注意

若要防止恶意使用,可能需确保作业调用终结点要求使用凭据。 在这种情况下,触发器函数需要提供凭据。

确定是否需要连接到本地

如果应用程序需要访问任何本地服务,则需预配 Azure 的某个连接服务。 有关详细信息,请参阅选择用于将本地网络连接到 Azure 的解决方案。 或者,你需要重构应用程序,以便使用本地资源公开的公开可用的 API。

确定 Java 消息服务 (JMS) 队列或主题是否正在使用中

如果应用程序使用 JMS 队列或主题,则需将其迁移到外部托管的 JMS 服务器。 Azure 服务总线和高级消息队列协议 (AMQP) 可成为那些使用 JMS 的项目的理想迁移策略。 有关详细信息,请参阅将 JMS 与 Azure 服务总线和 AMQP 1.0 配合使用

如果已配置 JMS 持久存储,则必须捕获其配置,并在迁移后应用它。

确定应用程序是否使用特定于 WebSphere 的 API

如果应用程序使用特定于 WebSphere 的 API,则需要重构应用程序以不使用它们。 Red Hat Migration Toolkit for Apps 可帮助删除和重构这些依赖项。

确定应用程序是否使用实体 Bean 或 EJB 2.x 样式的 CMP Bean

如果应用程序使用实体 Bean 或 EJB 2.x 样式的 CMP Bean,则需要重构应用程序以删除这些依赖项。

确定是否使用 Java企业版应用程序客户端功能

如果客户端应用程序使用 Java 连接到(服务器)应用程序企业版应用程序客户端功能,则需要重构客户端应用程序和(服务器)应用程序才能使用 HTTP API。

确定应用程序是否包含特定于 OS 的代码

如果应用程序包含的代码有主机 OS 的依赖项,则需重构该代码,删除那些依赖项。 例如,可能需要将文件系统路径中使用的 /\ 替换为 File.SeparatorPaths.get

确定是否使用了 EJB 计时器

如果应用程序使用 EJB 计时器,则需要验证每个 JBoss EAP 实例是否可以单独触发 EJB 计时器代码。 需要此验证,因为当App 服务水平缩放时,每个 EJB 计时器都将在其自己的 JBoss EAP 实例上触发。

确定是否使用了 JCA 连接器

如果应用程序使用 JCA 连接器,则需要验证 JCA 连接器是否可以在 JBoss EAP 上使用。 如果 JCA 实现绑定到 WebSphere,则需要重构应用程序以删除对 JCA 连接器的依赖项。 如果可以使用 JCA 连接器,则需要将 JAR 添加到服务器类路径。 还需要将必要的配置文件放在 JBoss EAP 服务器目录中的正确位置,以便其可用。

确定是否使用了 JAAS

如果应用程序使用 JAAS,则需要捕获 JAAS 的配置方式。 如果使用的是数据库,则可以将其转换为 JBoss EAP 上的 JAAS 域。 如果它是自定义实现,则需要验证它是否可在 JBoss EAP 上使用。

确定应用程序是否使用资源适配器

如果应用程序需要资源适配器 (RA),则它需要与 JBoss EAP 兼容。 若要确定此 RA 在独立的 JBoss EAP 实例上是否正常工作,需将其部署到服务器并对其进行正确配置。 如果 RA 正常工作,则需要将 JAR 添加到App 服务实例的服务器类路径,并将所需的配置文件放在 JBoss EAP 服务器目录中的正确位置,以便其可用。

确定应用程序是否由多个 WAR 组成

如果应用程序由多个 WAR 组成,则应将这些 WAR 中的每一个都视为单独的应用程序,并通过本指南了解这其中的每个应用程序。

确定应用程序是否打包为 EAR

如果应用程序打包为 EAR 文件,请务必检查 application.xmlibm-application-bnd.xml 文件并捕获其配置。

确定在生产服务器上运行的所有外部进程和守护程序

如果在应用程序服务器外运行任何进程(如监视守护程序),则需消除它们或将它们迁移到其他位置。

迁移

Red Hat Migration Toolkit for Apps

Red Hat Migration Toolkit for Applications 是 Visual Studio Code 的免费扩展。 此扩展分析应用程序代码和配置,以提供将 Jakarta 企业版 应用程序从其他应用服务器迁移到 JBoss EAP 的建议,例如删除对专有 API 的依赖项。 如果要从本地迁移到云,该扩展还会提供建议。 有关详细信息,请参阅 Migration Toolkit for Applications 概述

本指南的内容将帮助你解决迁移旅程的其他组件,例如选择正确的App 服务计划类型、外部化会话状态,以及使用 Azure 管理 EAP 实例而不是 JBoss 管理接口。

预配应用服务计划

从可用服务计划列表中,选择其规格满足或超过当前生产硬件规格的计划。

注意

如果计划运行过渡/Canary 部署或使用部署槽位,应用服务计划必须包含该附加容量。 建议对 Java 应用程序使用高级或更高等级的计划。

创建该应用服务计划

创建和部署 Web 应用

需要针对部署到 JBoss EAP 服务器的每个 WAR 文件在App 服务计划上创建 Web 应用。

注意

虽然可以将多个 WAR 文件部署到单个 Web 应用,但这根本没有必要。 如果将多个 WAR 文件部署到单个 Web 应用,则会妨碍每个应用程序根据其自身的使用需求进行缩放。 另外,这样还会增加后续部署管道的复杂性。 如果单个 URL 上需要有多个可用的应用程序,请考虑使用路由解决方案,如 Azure 应用程序网关

Maven 应用程序

如果应用程序是从 Maven POM 文件生成的,则请使用 Maven 的 Webapp 插件来创建 Web 应用并部署应用程序。 有关详细信息,请参阅快速入门的“配置 Maven 插件”部分:在Azure App 服务上创建 Java 应用。

非 Maven 应用程序

如果无法使用 Maven 插件,则需通过如下所示的其他机制来预配 Web 应用:

创建 Web 应用后,请使用其中一种可用的部署机制来部署应用程序。 有关详细信息,请参阅将文件部署到App 服务

迁移 JVM 运行时选项

如果应用程序需要特定的运行时选项,请使用最适合的机制来指定它们。 有关详细信息,请参阅“为Azure App 服务配置 Java 应用的”设置 Java 运行时选项“部分。

填充机密

使用“应用程序设置”存储特定于应用程序的任何机密。 如果想要在多个应用程序之间使用相同的机密或机密,或者需要精细的访问策略和审核功能,请改用 Azure 密钥库引用。 有关详细信息,请参阅“为 Azure App 服务 配置 Java 应用”的“使用 KeyVault 引用”部分。

配置自定义域和 SSL

如果应用程序将在自定义域上可见,则需将 Web 应用程序映射到它。 有关详细信息,请参阅教程:将现有的自定义 DNS 名称映射到 Azure 应用服务

然后,需要将该域的 TLS/SSL 证书绑定到 App 服务 Web 应用。 有关详细信息,请参阅在 Azure 应用服务中使用 TLS/SSL 绑定保护自定义 DNS 名称

迁移数据源、库和 JNDI 资源

若要迁移数据源,请按照配置 java 应用的“配置 java 应用”部分中的步骤操作,Azure App 服务。

按照配置 Java 应用的 JBoss EAP 部分中的说明迁移任何其他服务器级类路径依赖项,Azure App 服务

迁移任何其他共享服务器级 JDNI 资源。 有关详细信息,请参阅“为 Azure App 服务配置 Java 应用的 JBoss EAP”部分。

注意

如果遵循每个应用程序一个 WAR 的建议体系结构,请考虑将服务器级类路径库和 JNDI 资源迁移到应用程序中。 这样做将大大简化组件治理和变更管理。 如果要为每个应用程序部署多个 WAR,则应查看本指南开头提及的一个配套指南。

迁移计划的作业

至少应将计划作业移动到 Azure VM,使其不再是应用程序的一部分。 或者,可以选择使用 Azure Functions、SQL 数据库 和事件中心等 Azure 服务将其现代化为事件驱动的 Java。

重启和冒烟测试

最后,需重启 Web 应用以应用所有配置更改。 重启完成后,请验证应用程序是否正常运行。

迁移后

将应用程序迁移到 Azure 应用服务后,即应验证其运行是否符合预期。 完成此操作后,可以参考我们提供的一些建议,使应用程序的云原生性更好。

建议

  • 如果选择使用 /home 目录进行文件存储,请考虑将其替换为 Azure 存储。 有关详细信息,请参阅装载Azure 存储作为App 服务中自定义容器中的本地共享。

  • 如果在 /home 目录中配置了包含连接字符串、SSL 密钥和其他机密信息,请考虑尽可能将 Azure 密钥库 和参数注入与应用程序设置结合使用。 有关详细信息,请参阅对 App 服务 和 Azure Functions 使用密钥库参考,并配置App 服务应用

  • 请考虑使用部署槽位实现可靠的部署,不需停机。 有关详细信息,请参阅设置 Azure 应用服务中的过渡环境

  • 设计和实施 DevOps 策略。 若要在提高开发速度的同时保持可靠性,请考虑通过 Azure Pipelines 自动进行部署和测试。 有关详细信息,请参阅 生成并部署到 Java Web 应用。 如果使用部署槽位,则可以自动部署到槽和后续槽交换。 有关详细信息,请参阅“部署到 Azure Web 应用的”部分。

  • 设计和实施业务连续性和灾难恢复策略。 对于关键应用程序,请考虑多区域部署体系结构。 有关详细信息,请参阅高可用性多区域 Web 应用程序