将 WebSphere 应用程序迁移到 Azure 应用程序服务上的 JBoss EAP
本指南介绍在需要迁移现有 WebSphere 应用程序以使之使用 JBoss EAP 在 Azure 应用程序服务上运行时应注意的事项。
预迁移
若要确保迁移成功,请在开始之前完成以下各节中所述的评估和清点步骤。
清点服务器容量
记录当前生产服务器的硬件(内存、CPU、磁盘)、平均值和峰值请求计数,以及资源利用率。 无论选择了哪种迁移路径,都将需要此信息。 例如,它有助于指导应用程序服务计划的选择。
可用应用程序服务计划层的列表显示内存、CPU 核心、存储和定价信息。 请注意,应用程序服务上的 JBoss EAP 仅在高级 V3 和独立 V2 应用程序服务计划层级上可用。
清点所有机密
检查生产服务器或服务器上的所有属性和配置文件是否有任何密钥和密码。 请确保在 WAR 中检查 ibm-web-bnd.xml。 还可以在应用程序中查找包含密码或凭据的配置文件。 对于 Spring Boot 应用程序,这些文件可能包括 application.properties 或 application.yml 文件。
清点所有证书
记录用于公共 SSL 终结点的所有证书。 可以通过运行以下命令来查看生产服务器上的所有证书:
keytool -list -v -keystore <path to keystore>
验证支持的 Java 版本是否正常运行
Azure 应用程序服务上的 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 Blob 存储和 Azure CDN 与 Azure 函数配合使用,以便处理上传和 CDN 刷新操作。 我们提供了一个示例实现,用于通过 Azure Functions 进行静态内容的上传和 CDN 预加载操作。
动态或内部内容
对于应用程序频繁写入和读取的文件(如临时数据文件)或只有应用程序可见的静态文件,可以将 Azure 存储挂载到应用程序服务文件系统中。 有关详细信息,请参阅将 Azure 存储装载为应用程序服务中的本地共享。
确定应用程序是否依赖于计划的作业
计划的作业(如 Quartz 计划程序任务或 Unix cron 作业)不应与 Azure 应用程序服务配合使用。 Azure 应用程序服务不会阻止你部署内含计划任务的应用程序。 但是,如果应用程序横向扩展,则同一个计划的作业可能会按照计划期间运行多次。 这种情况可能会导致意外的后果。
若要在 Azure 上执行计划的作业,请考虑将 Azure Functions 与计时器触发器配合使用。 有关详细信息,请参阅适用于 Azure Functions 的计时器触发器。 无需将作业代码本身迁移到函数中。 函数可以直接在应用程序中调用 URL 来触发作业。
注意
若要防止恶意使用,可能需确保作业调用终结点要求使用凭据。 在这种情况下,触发器函数需要提供凭据。
确定是否需要连接到本地
如果应用程序需要访问任何本地服务,则需预配 Azure 的某个连接服务。 有关详细信息,请参阅将本地网络连接到 Azure。 或者,你需要重构应用程序,以便使用本地资源公开的公开可用的 API。
确定 Java 消息服务 (JMS) 队列或主题是否正在使用中
如果应用程序使用 JMS 队列或主题,则需将其迁移到外部托管的 JMS 服务器。 Azure 服务总线和高级消息队列协议 (AMQP) 可成为那些使用 JMS 的项目的理想迁移策略。 有关详细信息,请参阅将 Java Message Service 1.1 与 Azure 服务总线标准和 AMQP 1.0 配合使用。
如果已配置 JMS 持久存储,则必须捕获其配置,并在迁移后应用它。
确定应用程序是否使用特定于 WebSphere 的 API
如果应用程序使用特定于 WebSphere 的 API,则需要重构应用程序以不使用它们。 适用于应用的 Red Hat 迁移工具包可帮助删除和重构这些依赖项。
确定应用程序是否使用实体 Bean 或 EJB 2.x 样式的 CMP Bean
如果应用程序使用实体 Bean 或 EJB 2.x 样式的 CMP Bean,则需要重构应用程序以删除这些依赖项。
确定是否使用了 JavaEE 应用程序客户端功能
如果客户端应用程序使用了 JavaEE 应用程序客户端功能连接到(服务器)应用程序,则需要重构客户端应用程序和(服务器)应用程序以使用 HTTP API。
确定应用程序是否包含特定于 OS 的代码
如果应用程序包含的代码有主机 OS 的依赖项,则需重构该代码,删除那些依赖项。 例如,如果应用程序在 Windows 上运行,则可能需要将文件系统路径中的 /
或 \
替换为 File.Separator
或 Paths.get
。
确定是否使用了 EJB 计时器
如果应用程序使用 EJB 计时器,则需要验证 EJB 计时器代码是否可以由每个 JBoss EAP 实例独立触发。 需要进行此验证,因为当应用程序服务水平缩放时,每个 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 添加到应用程序服务实例的服务器 classpath 中,并将必要的配置文件放在 JBoss EAP 服务器目录中的正确位置,使其可供使用。
确定应用程序是否由多个 WAR 组成
如果应用程序由多个 WAR 组成,则应将这些 WAR 中的每一个都视为单独的应用程序,并通过本指南了解这其中的每个应用程序。
确定应用程序是否打包为 EAR
如果应用程序打包为 EAR 文件,请务必检查 application.xml 和 ibm-application-bnd.xml 文件并捕获其配置。
确定在生产服务器上运行的所有外部进程和守护程序
如果在应用程序服务器外运行任何进程(如监视守护程序),则需消除它们或将它们迁移到其他位置。
迁移
适用于应用的 Red Hat 迁移工具包
Red Hat Migration Toolkit for Applications 是 Visual Studio Code 的免费扩展。 此扩展分析应用程序代码和配置,为将 Jakarta EE 应用程序从其他应用服务器迁移到 JBoss EAP 提供建议,例如删除对专有 API 的依赖项。 如果要从本地迁移到云,该扩展还会提供建议。 有关详细信息,请参阅 Migration Toolkit for Applications 概述。
本指南的内容将帮助解决迁移过程中的其他组件,例如选择正确的应用程序服务计划类型、将会话状态外部化,以及使用 Azure 来管理 EAP 实例而不是 JBoss 管理接口。
预配应用程序服务计划
从可用服务计划列表中,选择规格达到或超过当前生产硬件规格的计划。
注意
如果计划运行过渡/Canary 部署或使用部署槽位,应用程序服务计划必须包含该附加容量。 建议对 Java 应用程序使用高级或更高等级的计划。
创建和部署 Web 应用
需要在应用程序服务计划中为部署到 JBoss EAP 服务器的每个 WAR 文件创建一个 Web 应用程序。
注意
虽然可以将多个 WAR 文件部署到单个 Web 应用,但这根本没有必要。 如果将多个 WAR 文件部署到单个 Web 应用,则会妨碍每个应用程序根据其自身的使用需求进行缩放。 另外,这样还会增加后续部署管道的复杂性。 如果单个 URL 上需要有多个可用的应用程序,请考虑使用路由解决方案,如 Azure 应用程序网关。
Maven 应用程序
如果应用程序是从 Maven POM 文件生成的,则请使用 Maven 的 Webapp 插件来创建 Web 应用并部署应用程序。 有关详细信息,请参阅快速入门:在 Azure 应用程序服务中创建 Java 应用的配置 Maven 插件部分。
非 Maven 应用程序
如果无法使用 Maven 插件,则需通过如下所示的其他机制来预配 Web 应用:
创建 Web 应用程序后,请使用可用的部署机制之一来部署应用程序。 有关详细信息,请参阅将文件部署到应用程序服务。
迁移 JVM 运行时选项
如果应用程序需要特定的运行时选项,请使用最适合的机制来指定它们。 有关详细信息,请参阅在 Azure 应用程序服务中部署和配置 Tomcat、JBoss 或 Java SE 应用中的设置 Java 运行时选项部分。
填充机密
使用“应用程序设置”存储特定于应用程序的任何机密。 如果打算在多个应用程序中使用相同的一个或多个机密,或者需要精细的访问策略和审核功能,请改用 Azure Key Vault 引用。 有关详细信息,请参阅在 Azure 应用程序服务和 Azure Functions 中使用密钥保管库引用作为应用程序设置。
配置自定义域和 SSL
如果应用程序将在自定义域上可见,则需将 Web 应用程序映射到它。 有关详细信息,请参阅教程:将现有的自定义 DNS 名称映射到 Azure 应用程序服务。
然后,需要将该域的 TLS/SSL 证书绑定到应用程序服务 Web 应用。 有关详细信息,请参阅在 Azure 应用程序服务中使用 TLS/SSL 绑定保护自定义 DNS 名称。
迁移数据源、库和 JNDI 资源
要迁移数据源,请按照在 Azure 应用程序服务中为 Tomcat、JBoss 或 Java SE 应用配置数据源中的步骤进行操作。
迁移任何其他服务器级 classpath 依赖项。 有关详细信息,请参阅在 Azure 应用程序服务中为 Tomcat、JBoss 或 Java SE 应用配置数据源。
迁移任何其他共享服务器级 JDNI 资源。 有关详细信息,请参阅在 Azure 应用程序服务中为 Tomcat、JBoss 或 Java SE 应用配置数据源。
注意
如果遵循每个应用程序一个 WAR 的推荐体系结构,请考虑将服务器级 Classpath 库和 JNDI 资源迁移到你的应用程序中。 这样做将大大简化组件治理和变更管理。 如果要为每个应用程序部署多个 WAR,则应查看本指南开头提到的配套指南之一。
迁移计划的作业
至少,应将计划的作业移动到 Azure VM,这样它们就不再是应用程序的一部分。 或者,你可以选择使用 Azure 服务(如 Azure Functions、SQL 数据库和事件中心)将它们现代化为事件驱动的 Java。
重启和冒烟测试
最后,需重启 Web 应用以应用所有配置更改。 重启完成后,请验证应用程序是否正常运行。
迁移后
将应用程序迁移到 Azure 应用程序服务后,即应验证其运行是否符合预期。 完成此操作后,可以参考我们提供的一些建议,使应用程序的云原生性更好。
建议
如果选择使用 /home 目录进行文件存储,请考虑将其替换为 Azure 存储。 有关详细信息,请参阅将 Azure 存储作为本地共享装载到应用程序服务中的自定义容器中。
如果你在 /home 目录中有包含连接字符串、SSL 密钥和其他机密信息的配置,请考虑在可能的情况下将 Azure 密钥保管库和参数注入与应用程序设置相结合。 有关详细信息,请参阅使用应用程序服务和 Azure Functions 的 Key Vault 引用和配置应用程序服务应用。
请考虑使用部署槽位实现可靠的部署,不需停机。 有关详细信息,请参阅设置 Azure 应用程序服务中的过渡环境。
设计和实施 DevOps 策略。 若要在提高开发速度的同时保持可靠性,请考虑通过 Azure Pipelines 自动进行部署和测试。 有关详细信息,请参阅生成和部署到 Java Web 应用。 如果你使用的是部署槽位,则可以自动部署到槽位并随后进行槽位交换。 有关详细信息,请参阅使用 Azure Pipelines 部署到应用程序服务的示例:部署到槽位部分。
设计和实施业务连续性和灾难恢复策略。 对于关键应用程序,请考虑多区域部署体系结构。 有关详细信息,请参阅高可用性多区域 Web 应用程序。