将 WebLogic Server 应用程序迁移到 Azure 应用程序服务上的 JBoss EAP
本指南介绍在需要迁移现有 WebLogic Server 应用程序以使之使用 JBoss EAP 在 Azure 应用程序服务上运行时应注意的事项。
预迁移
若要确保迁移成功,请在开始之前完成以下各节中所述的评估和清点步骤。
如果你无法满足这些预迁移要求中的任何一个,请参阅配套的迁移指南,将你的应用程序迁移到虚拟机:将 WebLogic Server 应用程序迁移到 Azure 虚拟机
清点服务器容量
记录当前生产服务器的硬件(内存、CPU、磁盘)、平均值和峰值请求计数,以及资源利用率。 无论选择了哪种迁移路径,都将需要此信息。 例如,它有助于指导应用程序服务计划的选择。
可用应用程序服务计划层的列表显示内存、CPU 核心、存储和定价信息。 请注意,应用程序服务上的 JBoss EAP 仅在高级 V3 和独立 V2 应用程序服务计划层级上可用。
清点所有机密
在出现“配置即服务”技术(如 Azure Key Vault)之前,没有有关“机密”的明确定义的概念。 你只能使用一组不同的配置设置,这些设置可以有效地充当我们现在所称的“机密”。 在应用服务器(如 WebLogic Server)中,这些机密位于许多不同的配置文件和配置存储中。 检查生产服务器上的所有属性和配置文件中是否有机密和密码。 请确保在 WAR 中检查 weblogic.xml。 还可以在应用程序中查找包含密码或凭据的配置文件。 有关详细信息,请参阅 Azure Key Vault 基本概念。
清点所有证书
记录用于公共 SSL 终结点的所有证书。 可以通过运行以下命令来查看生产服务器上的所有证书:
keytool -list -v -keystore <path to keystore>
清点 JNDI 资源
清点所有 JNDI 资源。 例如,数据库等数据源可能具有关联的 JNDI 名称,该名称允许 JPA 正确地将 EntityManager
的实例绑定到特定数据库。 有关 JNDI 资源和数据库的详细信息,请参阅 Oracle 文档中的 WebLogic Server Data Sources(WebLogic Server 数据源)。 其他 JNDI 相关资源(如 JMS 消息代理)可能需要迁移或重新配置。 有关 JMS 配置的详细信息,请参阅 Oracle WebLogic Server 12.2.1.4.0。
检查域配置
WebLogic Server 中的主要配置单元是域。 因此,config.xml 文件包含了大量的配置,进行迁移时必须仔细考虑这些配置。 此文件包含对存储在子目录中的其他 XML 文件的引用。 Oracle 建议你正常情况下使用管理控制台来配置 WebLogic Server 的可管理对象和服务,并允许 WebLogic Server 保留 config.xml 文件。 有关详细信息,请参阅 Domain Configuration Files(域配置文件)。
在应用程序中
检查 WEB-INF/weblogic.xml 文件和/或 WEB-INF/web.xml 文件。
确定是否使用了会话复制
如果应用程序依赖于会话复制,则无论是否有 Oracle Coherence*Web,都可以使用两个选项:
- 重构应用程序,使用数据库进行会话管理。
- 重构应用程序,将 Azure Redis 服务的会话外部化。 有关详细信息,请参阅 Azure Cache for Redis。
对于所有这些选项,最后是掌握 WebLogic 如何执行 HTTP 会话状态复制。 有关详细信息,请参阅 Oracle 文档中的 HTTP 会话状态复制。
记录数据源
如果应用程序使用任何数据库,则需捕获以下信息:
- 数据源名称是什么?
- 连接池配置是什么?
- 在哪里可以找到 JDBC 驱动程序 JAR 文件?
有关 WebLogic 中的 JDBC 驱动程序的详细信息,请参阅 Using JDBC Drivers with WebLogic Server(将 JDBC 驱动程序与 WebLogic Server 配合使用)。
确定是否已自定义 WebLogic
确定进行了以下哪些自定义,并捕获已完成的操作。
- 是否更改了启动脚本? 此类脚本包括 setDomainEnv、commEnv、startWebLogic 和 stopWebLogic。
- 是否有任何特定参数传递到 JVM?
- 是否存在添加到服务器 classpath 中的 JAR?
确定是否需要连接到本地
如果应用程序需要访问任何本地服务,则需预配 Azure 的某个连接服务。 有关详细信息,请参阅将本地网络连接到 Azure。 或者,你需要重构应用程序,以便使用本地资源公开的公开可用的 API。
确定 Java 消息服务 (JMS) 队列或主题是否正在使用中
如果应用程序使用 JMS 队列或主题,则需将其迁移到外部托管的 JMS 服务器。 Azure 服务总线和高级消息队列协议 (AMQP) 可成为那些使用 JMS 的项目的理想迁移策略。 有关详细信息,请参阅将 Java Message Service 1.1 与 Azure 服务总线标准和 AMQP 1.0 配合使用。
如果已配置 JMS 持久存储,则必须捕获其配置,并在迁移后应用它。
确定是否使用自己的自定义创建的共享 Java EE 库
如果使用共享 Java EE 库功能,则可使用两个选项:
- 重构应用程序代码以删除库上的所有依赖项,并改将功能直接合并到应用程序中。
- 将库添加到服务器 classpath。
确定是否使用了 OSGi 捆绑
如果使用了添加到 WebLogic 服务器的 OSGi 捆绑,则需将等效的 JAR 文件直接添加到 Web 应用程序。
确定应用程序是否包含特定于 OS 的代码
如果应用程序包含的代码有主机 OS 的依赖项,则需重构该代码,删除那些依赖项。 例如,如果应用程序在 Windows 上运行,则可能需要将文件系统路径中的 /
或 \
替换为 File.Separator
或 Paths.get
。
确定 Oracle 服务总线是否正在使用中
如果应用程序使用 Oracle 服务总线 (OSB),则需捕获 OSB 的配置方式。 有关详细信息,请参阅 About the Oracle Service Bus Installation(关于 Oracle 服务总线安装)。
确定应用程序是否由多个 WAR 组成
如果应用程序由多个 WAR 组成,则应将这些 WAR 中的每一个都视为单独的应用程序,并通过本指南了解这其中的每个应用程序。
确定应用程序是否打包为 EAR
如果应用程序打包为 EAR 文件,请务必检查 application.xml 和 weblogic-application.xml 文件并捕获其配置。
确定在生产服务器上运行的所有外部进程和守护程序
如果在应用程序服务器外运行任何进程(如监视守护程序),则需消除它们或将它们迁移到其他位置。
验证支持的 Java 版本是否正常运行
Azure 应用程序服务上的 JBoss EAP 支持 Java 8 和 11。 因此,需验证应用程序能否使用该受支持的版本正确运行。 如果当前服务器使用受支持的 JDK(如 Oracle JDK 或 IBM OpenJ9),则此验证尤其重要。
若要获取当前的 Java 版本,请登录到生产服务器并运行以下命令:
java -version
确定应用程序是否依赖于计划的作业
计划的作业(如 Quartz 计划程序任务或 Unix cron 作业)不应与 Azure 应用程序服务配合使用。 Azure 应用程序服务不会阻止你部署内含计划任务的应用程序。 但是,如果应用程序横向扩展,则同一个计划的作业可能会按照计划期间运行多次。 这种情况可能会导致意外的后果。
若要在 Azure 上执行计划的作业,请考虑将 Azure Functions 与计时器触发器配合使用。 有关详细信息,请参阅适用于 Azure Functions 的计时器触发器。 无需将作业代码本身迁移到函数中。 函数可以直接在应用程序中调用 URL 来触发作业。
注意
若要防止恶意使用,可能需确保作业调用终结点要求使用凭据。 在这种情况下,触发器函数需要提供凭据。
确定是否使用了 WebLogic 脚本编写工具 (WLST)
如果你当前使用 WLST 执行部署,则需要评估它正在做什么。 如果 WLST 在部署过程中更改应用程序的任何(运行时)参数,则需要确保这些参数符合以下选项之一:
- 它们已外部化为应用设置。
- 它们已嵌入应用程序中。
- 在部署过程中,它们使用的是 JBoss CLI。
如果 WLST 执行的工作超出了上述范围,则在迁移过程中你将需要执行一些其他工作。
确定应用程序是否使用特定于 WebLogic 的 API
如果应用程序使用特定于 WebLogic 的 API,则需要重构应用程序以不使用它们。 例如,如果使用了 Java API Reference for Oracle WebLogic Server(适用于 Oracle WebLogic Server 的 Java API 参考)中提到的类,则表示你已在应用程序中使用了特定于 WebLogic 的 API。 适用于应用的 Red Hat 迁移工具包可帮助删除和重构这些依赖项。
确定应用程序是否使用实体 Bean 或 EJB 2.x 样式的 CMP Bean
如果你的应用程序使用实体 Bean 或 EJB 2.x 样式的 CMP Bean,则需要重构应用程序以不使用它们。
确定是否使用了 Java EE 应用程序客户端功能
如果你的客户端应用程序使用 Java EE 应用程序客户端功能连接到你的(服务器)应用程序,则需要重构客户端应用程序和(服务器)应用程序以使用 HTTP API。
确定是否使用了部署计划
如果使用部署计划来执行部署,则需要评估部署计划正在执行的操作。 如果部署计划是直接部署,则可部署 Web 应用程序,无需进行任何更改。 如果部署计划较为复杂,则需确定是否可以使用 JBoss CLI 在部署过程中正确配置应用程序。 如果无法使用 JBoss CLI,则需重构应用程序,使之不再需要部署计划。
确定是否使用了 EJB 计时器
如果应用程序使用 EJB 计时器,则需要验证 EJB 计时器代码是否可以由每个 JBoss EAP 实例独立触发。 需要进行此验证,因为当应用程序服务水平缩放时,每个 EJB 计时器都将在其自己的 JBoss EAP 实例上触发。
验证是否以及如何使用文件系统
使用应用程序服务器上的文件系统需要重新配置,在极少数情况下需要体系结构更改。 文件系统可能由 WebLogic 共享模块或你的应用程序代码使用。 可以识别下面的部分或所有情况。
只读静态内容
如果你的应用程序当前提供静态内容,则需要为该静态内容提供备用位置。 可能需要考虑将静态内容移到 Azure Blob 存储,并添加 Azure CDN,方便用户在全球范围内快速下载。
动态发布的静态内容
如果应用程序允许那些通过应用程序上传/生成但在创建后不可变的静态内容,则可将上述 Azure Blob 存储和 Azure CDN 与 Azure 函数配合使用,以便处理上传和 CDN 刷新操作。 我们提供了一个示例实现供你使用。
动态或内部内容
对于应用程序频繁写入和读取的文件(例如临时数据文件)或仅对应用程序可见的静态文件,可以将 Azure 存储挂载到应用程序服务文件系统中。
确定是否使用了 JCA 连接器
如果应用程序使用 JCA 连接器,则必须验证 JCA 连接器是否可以在 JBoss EAP 上使用。 如果 JCA 实现与 WebLogic 绑定,则必须重构应用程序以不使用 JCA 连接器。 如果可以使用它,那么需要将 JAR 添加到服务器 classpath 中,并将所需的配置文件放在 JBoss EAP 服务器目录中的正确位置,使其可用。
确定应用程序是否使用资源适配器
如果应用程序需要资源适配器 (RA),则它需要与 JBoss EAP 兼容。 若要确定此 RA 在独立的 JBoss EAP 实例上是否正常工作,需将其部署到服务器并对其进行正确配置。 如果 RA 工作正常,则需要将 JAR 添加到应用程序服务实例的服务器 classpath 中,并将必要的配置文件放在 JBoss EAP 服务器目录中的正确位置,使其可供使用。
确定是否使用 JAAS
如果应用程序使用的是 JAAS,则需要捕获 JAAS 的配置方式。 如果使用的是数据库,则可以将其转换为 JBoss EAP 上的 JAAS 域。 如果它是自定义实现,则需要验证它是否可在 JBoss EAP 上使用。
确定是否使用了 WebLogic 群集分析
最可能的情况是,你已将应用程序部署到多个 WebLogic 服务器上,以实现高可用性。 Azure 应用程序服务能够缩放;但如果你使用了 WebLogic 群集 API,则需要重构代码以消除对该 API 的使用。
迁移
适用于应用的 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 应用程序服务配置 Java 应用的设置 Java 运行时选项部分。
迁移外部化参数
如果需要使用外部参数,则需要将其设置为应用设置。 有关详细信息,请参阅配置应用设置。
迁移启动脚本
如果原始应用程序使用了自定义启动脚本,则需要将其迁移到 Bash 脚本。 有关详细信息,请参阅自定义应用服务器配置。
填充机密
使用“应用程序设置”存储特定于应用程序的任何机密。 如果打算在多个应用程序中使用相同的一个或多个机密,或者需要精细的访问策略和审核功能,请改用 Azure Key Vault 引用。 有关详细信息,请参阅为 Azure 应用程序服务配置 Java 应用的使用 Key Vault 引用部分。
配置自定义域和 SSL
如果应用程序将在自定义域上可见,则需将 Web 应用程序映射到它。 有关详细信息,请参阅教程:将现有的自定义 DNS 名称映射到 Azure 应用程序服务。
然后,需要将该域的 TLS/SSL 证书绑定到应用程序服务 Web 应用。 有关详细信息,请参阅在 Azure 应用程序服务中使用 TLS/SSL 绑定保护自定义 DNS 名称。
迁移数据源、库和 JNDI 资源
若要迁移数据源,请按照为 Azure 应用程序服务配置 Java 应用的配置数据源部分中的步骤操作。
按照为 Azure 应用程序服务配置 Java 应用的 JBoss EAP 部分中的说明迁移任何其他服务器级类路径依赖关系。
迁移任何其他共享服务器级 JDNI 资源。 有关详细信息,请参阅为 Azure 应用程序服务配置 Java 应用的 JBoss EAP 部分。
迁移 JCA 连接器和 JAAS 模块
按照安装模块和依赖项中的说明,迁移任何 JCA 连接器和 JAAS 模块。
注意
如果遵循每个应用程序一个 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 应用程序。