将 JBoss EAP 应用程序迁移到 Azure Kubernetes 服务上的 WildFly

项目
05/30/2023

本指南介绍在需要迁移现有 JBoss EAP 应用程序以使之在 Azure Kubernetes 服务容器中的 WildFly 上运行时应注意的事项。

预迁移

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

清点服务器容量

记录当前生产服务器的硬件（内存、CPU、磁盘）、平均值和峰值请求计数，以及资源利用率。无论选择了哪种迁移路径，都将需要此信息。例如，这有助于指导选择节点池中 VM 的大小、容器要使用的内存量以及容器需要多少 CPU。

可以在 AKS 中调整节点池的大小。若要了解如何操作，请参阅在 Azure Kubernetes 服务（AKS）中调整节点池大小。

清点所有机密

检查生产服务器上的所有属性和配置文件中是否有机密和密码。请确保在 WAR 中检查 jboss-web.xml。还可以在应用程序中查找包含密码或凭据的配置文件。

请考虑将这些机密存储到 Azure KeyVault 中。有关详细信息，请参阅 Azure Key Vault 基本概念。

清点所有证书

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

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

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

在 Azure Kubernetes 服务上使用 WildFly 需要特定版本的 Java，因此需要确认应用程序使用受支持的版本正确运行。

注意

如果当前服务器在不受支持的 JDK（如 Oracle JDK 或 IBM OpenJ9）上运行，则此验证尤其重要。

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

java -version

请参阅要求，了解使用什么版本来运行 WildFly。

清点 JNDI 资源

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

确定是否使用了会话复制

如果应用程序依赖于会话复制，则必须更改应用程序，摆脱此依赖关系。

在应用程序中

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

记录数据源

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

数据源名称是什么？
连接池配置是什么？
在哪里可以找到 JDBC 驱动程序 JAR 文件？

有关详细信息，请参阅 JBoss EAP 文档中的 About JBoss EAP Datasources（关于 JBoss EAP 数据源）。

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

使用应用程序服务器上的文件系统需要重新配置，在极少数情况下需要体系结构更改。文件系统可供 JBoss EAP 模块或应用程序代码使用。可以标识以下部分所述的部分或全部方案。

只读静态内容

如果应用程序当前提供静态内容，则需为其提供一个备用位置。可能需要考虑将静态内容移到 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 存储共享作为持久卷进行装载。有关详细信息，请参阅在 Azure Kubernetes 服务中动态创建永久性卷并将其用于 Azure 文件存储。

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

计划作业（如“硅计划程序”任务或 Unix cron 作业）不应与Azure Kubernetes 服务（AKS）一起使用。 Azure Kubernetes 服务不会阻止你部署内含计划任务的应用程序。但是，如果应用程序横向扩展，则同一个计划的作业可能会按照计划期间运行多次。这种情况可能会导致意外的后果。

若要在 AKS 群集上执行计划的作业，请按需定义 Kubernetes CronJob。有关详细信息，请参阅使用 CronJob 运行自动化任务。

确定是否需要连接到本地

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

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

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

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

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

如果应用程序使用特定于 JBoss EAP 的 API，则需重构它，摆脱这些依赖关系。

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

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

确定是否使用了 Java EE 应用程序客户端功能

如果客户端应用程序使用了 Java EE 应用程序客户端功能连接到（服务器）应用程序，则需要重构客户端应用程序和（服务器）应用程序以使用 HTTP API。

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

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

确定是否使用了 EJB 计时器

如果应用程序使用了 EJB 计时器，则需要验证每个 WildFly 实例是否可以独立触发 EJB 计时器代码。需要进行此验证是因为在 Azure Kubernetes 服务部署方案中，每个 EJB 计时器都将在其自己的 WildFly 实例上触发。

确定是否使用了 JCA 连接器

如果应用程序使用 JCA 连接器，请验证是否可以在 WildFly 上使用 JCA 连接器。如果 JCA 实现与 JBoss EAP 相关联，则必须重构应用程序，摆脱该依赖关系。如果可以在 WildFly 上使用 JCA 连接器，则必须将这些 JAR 添加到服务器 classpath 中，并将所需的配置文件放在 WildFly 服务器目录中的正确位置，使其可用。

确定是否使用了 JAAS

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

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

如果应用程序需要资源适配器 (RA)，则它需要与 WildFly 兼容。若要确定此 RA 在独立的 WildFly 实例上是否正常工作，需将其部署到服务器并对其进行正确配置。如果可以正常使用 RA，则需将这些 JAR 添加到 Docker 映像的服务器 classpath 中，并将所需的配置文件放在 WildFly 服务器目录中的正确位置，使其可用。

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

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

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

如果将应用程序打包为 EAR 文件，请务必检查 application.xml 文件并捕获配置。

注意

如果希望能够独立缩放每个 Web 应用程序，以便更好地使用 AKS 资源，则应将 EAR 分解为单独的 Web 应用程序。

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

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

执行就地测试

在创建容器映像之前，请将应用程序迁移到要在 AKS 上使用的 JDK 和 WildFly 版本。全面测试应用程序，确保兼容性和性能。

迁移

预配 Azure 容器注册表和 Azure Kubernetes 服务

使用以下命令创建容器注册表和 Azure Kubernetes 群集（带有对注册表具有“读取者”角色的服务主体）。确保根据群集的网络要求选择相应的网络模型。

az group create \
    --resource-group $resourceGroup \
    --location eastus
az acr create \
    --resource-group $resourceGroup \
    --name $acrName \
    --sku Standard
az aks create \
    --resource-group $resourceGroup \
    --name $aksName \
    --attach-acr $acrName \
    --network-plugin azure

创建 WildFly 的 Docker 映像

若要创建 Dockerfile，需要符合以下先决条件：

受支持的 JDK。
安装 WildFly。
JVM 运行时选项。
可以通过某种方法传入环境变量（如果适用）。

然后，可以执行以下部分所述的步骤（如果适用）。对于 Dockerfile 和 Web 应用程序，可以从使用 WildFly 容器快速入门存储库着手。

配置 KeyVault FlexVolume
设置数据源
设置 JNDI 资源
查看 WildFly 配置

配置 KeyVault FlexVolume

创建 Azure KeyVault 并填充所有必要的机密。有关详细信息，请参阅快速入门：使用 Azure CLI 在 Azure Key Vault 中设置和检索机密。然后，配置 KeyVault FlexVolume，使这些机密可供 Pod 访问。

还需要更新用于启动 WildFly 的启动脚本。此脚本必须在启动服务器之前将证书导入 WildFly 使用的密钥存储。

设置数据源

若要配置 WildFly 以访问数据源，需将 JDBC 驱动程序 JAR 添加到 Docker 映像，然后执行相应的 JBoss CLI 命令。生成 Docker 映像时，这些命令必须设置数据源。

以下步骤提供了有关 PostgreSQL、MySQL 和 SQL Server 的说明。

下载 PostgreSQL、MySQL 或 SQL Server 的 JDBC 驱动程序。

解压缩已下载的存档，获取驱动程序 .jar 文件。
创建一个名称类似于 module.xml 的文件，并添加以下标记。将 <module name> 占位符（包括尖括号）替换为适用于 PostgreSQL 的 org.postgres、适用于 MySQL 的 com.mysql 或适用于 SQL Server 的 com.microsoft。将 <JDBC .jar file path> 替换为上一步骤中 .jar 文件的名称，包括将文件置于 Docker 映像中时所在位置的完整路径，例如 /opt/database。
```
<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="<module name>">
    <resources>
       <resource-root path="<JDBC .jar file path>" />
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>
```

创建一个名称类似于 datasource-commands.cli 的文件，并添加以下代码。将 <JDBC .jar file path> 替换为在上一步使用的值。将 <module file path> 替换为上一步中的文件名和路径，例如 /opt/database/module.xml。

PostgreSQL

batch
module add --name=org.postgres --resources=<JDBC .jar file path> --module-xml=<module file path>
/subsystem=datasources/jdbc-driver=postgres:add(driver-name=postgres,driver-module-name=org.postgres,driver-class-name=org.postgresql.Driver,driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource)
data-source add --name=postgresDS --driver-name=postgres --jndi-name=java:jboss/datasources/postgresDS --connection-url=$DATABASE_CONNECTION_URL --user-name=$DATABASE_SERVER_ADMIN_FULL_NAME --password=$DATABASE_SERVER_ADMIN_PASSWORD --use-ccm=true --max-pool-size=5 --blocking-timeout-wait-millis=5000 --enabled=true --driver-class=org.postgresql.Driver --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter --jta=true --use-java-context=true --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
reload
run batch
shutdown

MySQL

batch
module add --name=com.mysql --resources=<JDBC .jar file path> --module-xml=<module file path>
/subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-class-name=com.mysql.cj.jdbc.Driver)
data-source add --name=mysqlDS --jndi-name=java:jboss/datasources/mysqlDS --connection-url=$DATABASE_CONNECTION_URL --driver-name=mysql --user-name=$DATABASE_SERVER_ADMIN_FULL_NAME --password=$DATABASE_SERVER_ADMIN_PASSWORD --use-ccm=true --max-pool-size=5 --blocking-timeout-wait-millis=5000 --enabled=true --driver-class=com.mysql.cj.jdbc.Driver --jta=true --use-java-context=true --exception-sorter-class-name=com.mysql.cj.jdbc.integration.jboss.ExtendedMysqlExceptionSorter
reload
run batch
shutdown

SQL Server

batch
module add --name=com.microsoft --resources=<JDBC .jar file path> --module-xml=<module file path>
/subsystem=datasources/jdbc-driver=sqlserver:add(driver-name=sqlserver,driver-module-name=com.microsoft,driver-class-name=com.microsoft.sqlserver.jdbc.SQLServerDriver,driver-datasource-class-name=com.microsoft.sqlserver.jdbc.SQLServerDataSource)
data-source add --name=sqlDS --jndi-name=java:jboss/datasources/sqlDS --driver-name=sqlserver --connection-url=$DATABASE_CONNECTION_URL --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter
reload
run batch
shutdown

更新应用程序的 JTA 数据源配置：

打开应用的 src/main/resources/META-INF/persistence.xml 文件，找到 <jta-data-source> 元素。替换其内容，如下所示：

PostgreSQL

<jta-data-source>java:jboss/datasources/postgresDS</jta-data-source>

MySQL

<jta-data-source>java:jboss/datasources/mysqlDS</jta-data-source>

SQL Server

<jta-data-source>java:jboss/datasources/postgresDS</jta-data-source>

将以下内容添加到 Dockerfile，以便在生成 Docker 映像时创建数据源

RUN /bin/bash -c '<WILDFLY_INSTALL_PATH>/bin/standalone.sh --start-mode admin-only &' && \
sleep 30 && \
<WILDFLY_INSTALL_PATH>/bin/jboss-cli.sh -c --file=/opt/database/datasource-commands.cli && \
sleep 30

确定要使用的 DATABASE_CONNECTION_URL，它因数据库服务器而异，并且不同于 Azure 门户中的值。此处所示的 URL 格式是必需的，方便 WildFly 使用：

PostgreSQL

jdbc:postgresql://<database server name>:5432/<database name>?ssl=true

MySQL

jdbc:mysql://<database server name>:3306/<database name>?ssl=true\&useLegacyDatetimeCode=false\&serverTimezone=GMT

SQL Server

jdbc:sqlserver://<database server name>:1433;database=<database name>;user=<admin name>;password=<admin password>;encrypt=true;trustServerCertificate=false;hostNameInCertificate=*.database.windows.net;loginTimeout=30;

在以后创建部署 YAML 时，需使用适当的值传递环境变量 DATABASE_CONNECTION_URL、DATABASE_SERVER_ADMIN_FULL_NAME 和 DATABASE_SERVER_ADMIN_PASSWORD。

若要详细了解如何通过 WildFly 配置数据库连接性，请参阅 PostgreSQL、MySQL 或 SQL Server。

设置 JNDI 资源

若要设置每个 JNDI 资源，需要在 WildFly 上进行配置，并且通常需要执行以下步骤：

下载必要的 JAR 文件，并将其复制到 Docker 映像中。
创建一个 WildFly module.xml 文件，该文件引用那些 JAR 文件。
创建特定 JNDI 资源所需的任何配置。
创建要在 Docker 生成期间使用的 JBoss CLI 脚本，以便注册 JNDI 资源。
将所有内容添加到 Dockerfile。
在部署 YAML 中传递适当的环境变量。

以下示例演示了创建 JNDI 资源以通过 JMS 连接到 Azure 服务总线所需的步骤。

下载 Apache Qpid JMS 提供程序

解压缩已下载的存档，获取 .jar 文件。

创建一个名称类似于 module.xml 的文件，并在 /opt/servicebus 中添加以下标记。请确保 JAR 文件的版本号与前一步骤的 JAR 文件的名称相符。

<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="org.jboss.genericjms.provider">
 <resources>
  <resource-root path="proton-j-0.31.0.jar"/>
  <resource-root path="qpid-jms-client-0.40.0.jar"/>
  <resource-root path="slf4j-log4j12-1.7.25.jar"/>
  <resource-root path="slf4j-api-1.7.25.jar"/>
  <resource-root path="log4j-1.2.17.jar"/>
  <resource-root path="netty-buffer-4.1.32.Final.jar" />
  <resource-root path="netty-codec-4.1.32.Final.jar" />
  <resource-root path="netty-codec-http-4.1.32.Final.jar" />
  <resource-root path="netty-common-4.1.32.Final.jar" />
  <resource-root path="netty-handler-4.1.32.Final.jar" />
  <resource-root path="netty-resolver-4.1.32.Final.jar" />
  <resource-root path="netty-transport-4.1.32.Final.jar" />
  <resource-root path="netty-transport-native-epoll-4.1.32.Final-linux-x86_64.jar" />
  <resource-root path="netty-transport-native-kqueue-4.1.32.Final-osx-x86_64.jar" />
  <resource-root path="netty-transport-native-unix-common-4.1.32.Final.jar" />
  <resource-root path="qpid-jms-discovery-0.40.0.jar" />
 </resources>
 <dependencies>
  <module name="javax.api"/>
  <module name="javax.jms.api"/>
 </dependencies>
</module>

在 /opt/servicebus 中创建 jndi.properties 文件。

connectionfactory.${MDB_CONNECTION_FACTORY}=amqps://${DEFAULT_SBNAMESPACE}.servicebus.windows.net?amqp.idleTimeout=120000&jms.username=${SB_SAS_POLICY}&jms.password=${SB_SAS_KEY}
queue.${MDB_QUEUE}=${SB_QUEUE}
topic.${MDB_TOPIC}=${SB_TOPIC}

创建一个名称类似于 servicebus-commands.cli 的文件，并添加以下代码。

batch
/subsystem=ee:write-attribute(name=annotation-property-replacement,value=true)
/system-property=property.mymdb.queue:add(value=myqueue)
/system-property=property.connection.factory:add(value=java:global/remoteJMS/SBF)
/subsystem=ee:list-add(name=global-modules, value={"name" => "org.jboss.genericjms.provider", "slot" =>"main"}
/subsystem=naming/binding="java:global/remoteJMS":add(binding-type=external-context,module=org.jboss.genericjms.provider,class=javax.naming.InitialContext,environment=[java.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory,org.jboss.as.naming.lookup.by.string=true,java.naming.provider.url=/opt/servicebus/jndi.properties])
/subsystem=resource-adapters/resource-adapter=generic-ra:add(module=org.jboss.genericjms,transaction-support=XATransaction)
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd:add(class-name=org.jboss.resource.adapter.jms.JmsManagedConnectionFactory, jndi-name=java:/jms/${MDB_CONNECTION_FACTORY})
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd/config-properties=ConnectionFactory:add(value=${MDB_CONNECTION_FACTORY})
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd/config-properties=JndiParameters:add(value="java.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory;java.naming.provider.url=/opt/servicebus/jndi.properties")
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd:write-attribute(name=security-application,value=true)
/subsystem=ejb3:write-attribute(name=default-resource-adapter-name, value=generic-ra)
run-batch
reload
shutdown

将以下内容添加到 Dockerfile，以便在生成 Docker 映像时创建 JNDI 源

RUN /bin/bash -c '<WILDFLY_INSTALL_PATH>/bin/standalone.sh --start-mode admin-only &' && \
sleep 30 && \
<WILDFLY_INSTALL_PATH>/bin/jboss-cli.sh -c --file=/opt/servicebus/servicebus-commands.cli && \
sleep 30

在以后创建部署 YAML 时，需使用适当的值传递环境变量 MDB_CONNECTION_FACTORY、DEFAULT_SBNAMESPACE、SB_SAS_POLICY、SB_SAS_KEY、MDB_QUEUE、SB_QUEUE、MDB_TOPIC 和 SB_TOPIC。

查看 WildFly 配置

查看 WildFly Admin Guide（WildFly 管理指南），该指南涵盖了上一指南未涵盖的任何其他预迁移步骤。

构建 Docker 映像并将其推送到 Azure 容器注册表

创建 Dockerfile 后，需要生成 Docker 映像并将其发布到 Azure 容器注册表。

如果你使用了我们的 WildFly 容器快速入门 GitHub 存储库，则构建映像并将其推送到 Azure 容器注册表的过程相当于调用以下三个命令。

在这些示例中，MY_ACR 环境变量保存 Azure 容器注册表的名称，MY_APP_NAME 变量保存要在 Azure 容器注册表中使用的 Web 应用程序的名称。

生成 WAR 文件：

mvn package

登录到 Azure 容器注册表：

az acr login --name ${MY_ACR}

生成并推送映像：

az acr build --image ${MY_ACR}.azurecr.io/${MY_APP_NAME} --file src/main/docker/Dockerfile .

也可使用 Docker CLI 在本地生成并测试映像，如以下命令所示。此方法可以简化在一开始部署到 ACR 之前对映像进行的测试和优化。但是，它要求安装 Docker CLI 并确保 Docker 后台程序正在运行。

生成映像：

docker build -t ${MY_ACR}.azurecr.io/${MY_APP_NAME}

在本地运行映像：

docker run -it -p 8080:8080 ${MY_ACR}.azurecr.io/${MY_APP_NAME}

现在可以在 http://localhost:8080 上访问你的应用程序。

登录到 Azure 容器注册表：

az acr login --name ${MY_ACR}

向 Azure 容器注册表推送映像：

docker push ${MY_ACR}.azurecr.io/${MY_APP_NAME}

若要更深入地了解如何在 Azure 中生成和存储容器映像，请参阅 Learn 模块：使用 Azure 容器注册表生成和存储容器映像。

预配公共 IP 地址

如果想要从内部网络或虚拟网络之外访问应用程序，则需要公共静态 IP 地址。应在群集的节点资源组内预配此 IP 地址，如以下示例中所示：

export nodeResourceGroup=$(az aks show \
    --resource-group $resourceGroup \
    --name $aksName \
    --query 'nodeResourceGroup' \
    --output tsv)
export publicIp=$(az network public-ip create \
    --resource-group $nodeResourceGroup \
    --name applicationIp \
    --sku Standard \
    --allocation-method Static \
    --query 'publicIp.ipAddress' \
    --output tsv)
echo "Your public IP address is ${publicIp}."

部署到 AKS

创建并应用 Kubernetes YAML 文件。有关详细信息，请参阅快速入门：使用 Azure CLI 部署Azure Kubernetes 服务群集。如果要创建外部负载均衡器（不管是针对应用程序，还是针对入口控制器），请确保提供在上一部分以 LoadBalancerIP 形式预配的 IP 地址。

包括环境变量形式的外部化参数。有关详细信息，请参阅为容器定义环境变量。不要包括机密（如密码、API 密钥和 JDBC 连接字符串）。这些在下一部分中有所介绍。

创建部署 YAML 时，请确保包含内存和 CPU 设置，以便正确调整容器的大小。

配置持久性存储

如果应用程序需要非易失性存储，请配置一个或多个持久性卷。

迁移计划的作业

若要在 AKS 群集上执行计划的作业，请按需定义 Kubernetes CronJob。有关详细信息，请参阅使用 CronJob 运行自动化任务。

迁移后

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

建议

考虑向分配给入口控制器或应用程序负载均衡器的 IP 地址添加 DNS 名称。有关详细信息，请参阅在 AKS 中使用静态公共 IP 地址创建入口控制器。
考虑为应用程序添加 HELM 图表。可以通过 Helm 图表将应用程序部署参数化，供更多样化的客户使用和自定义。
设计和实施 DevOps 策略。若要在提高开发速度的同时保持可靠性，请考虑通过 Azure Pipelines 自动进行部署和测试。有关详细信息，请参阅生成并部署到 AKS。
为群集启用 Azure 监视。有关详细信息，请参阅启用对已部署的 AKS 群集的监视。这样 Azure Monitor 就可以收集容器日志、跟踪利用率，等等。
考虑通过 Prometheus 公开特定于应用程序的指标。 Prometheus 是在 Kubernetes 社区中广泛采用的开源指标框架。可以配置 Azure Monitor 中的 Prometheus 指标抓取，而不是托管你自己的 Prometheus 服务器，以便进行应用程序指标聚合，并自动响应或升级异常情况。有关详细信息，请参阅使用适用于容器的 Azure Monitor 配置 Prometheus 指标的抓取。
设计和实施业务连续性和灾难恢复策略。对于关键应用程序，请考虑多区域部署体系结构。有关详细信息，请参阅 AKS 中的业务连续性和灾难恢复的最佳做法。
查看 Kubernetes 版本支持策略。你有责任持续更新 AKS 群集，确保其始终运行受支持的版本。有关详细信息，请参阅升级 AKS 群集。
让所有负责群集管理和应用程序开发的团队成员查看相关的 AKS 最佳做法。有关详细信息，请参阅群集操作员和开发人员在 AKS 上生成并管理应用程序的最佳做法。
确保部署文件指定滚动更新的完成方式。有关详细信息，请参阅 Kubernetes 文档中的滚动更新部署。
设置自动缩放以处理高峰时间负载。有关详细信息，请参阅自动缩放群集以满足 AKS 上的应用程序需求。
考虑监视代码缓存大小并在 Dockerfile 中添加 JVM 参数 -XX:InitialCodeCacheSize 和 -XX:ReservedCodeCacheSize，进一步优化性能。有关详细信息，请参阅 Oracle 文档中的 Codecache Tuning（Codecache 优化）。

将 JBoss EAP 应用程序迁移到 Azure Kubernetes 服务上的 WildFly

预迁移

清点服务器容量

清点所有机密

清点所有证书

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

清点 JNDI 资源

确定是否使用了会话复制

在应用程序中

记录数据源

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

只读静态内容

动态发布的静态内容

动态或内部内容

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

确定是否需要连接到本地

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

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

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

确定是否使用了 Java EE 应用程序客户端功能

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

确定是否使用了 EJB 计时器

确定是否使用了 JCA 连接器

确定是否使用了 JAAS

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

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

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

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

执行就地测试

迁移

预配 Azure 容器注册表和 Azure Kubernetes 服务

创建 WildFly 的 Docker 映像

配置 KeyVault FlexVolume

设置数据源

设置 JNDI 资源

查看 WildFly 配置

构建 Docker 映像并将其推送到 Azure 容器注册表

预配公共 IP 地址

部署到 AKS

配置持久性存储

迁移计划的作业

迁移后

建议

反馈

反馈

其他资源