JBoss EAP to WildFly on Azure Kubernetes Service

Introduction

Kubernetes is an open-source framework for containerized application deployment, scalability, and administration. It's equivalent to the cloud's operating system. A Kubernetes cluster comprises a control plane (or brain) and worker nodes, which operate your workloads.

This tutorial outlines the steps to take when migrating an existing JBoss EAP application to WildFly in an Azure Kubernetes Service container.

Also see, kubernetes interview questions

Migrate JBoss EAP applications to WildFly on Azure Kubernetes Service

Pre-migration

Before you begin, perform the evaluation and inventory steps outlined in the following sections to ensure a successful migration.

Inventory server capacity

Document the current production server(s)' hardware (memory, CPU, disk) and the average and peak request counts and resource usage. This information will be required regardless of the migration path you pick. It may assist in guiding the size of the VMs in your node pool, the amount of RAM consumed by the container, and how many CPU shares the container requires.

Inventory all secrets

Check all production server(s) properties and configuration files for any secrets or passwords. Check the jboss-web.xml file in your WARs. Configuration files containing passwords or credentials may potentially be discovered within your application.

Consider using Azure KeyVault to store those secrets.

Inventory all certificates

All certificates used for public SSL endpoints should be documented. Run the following command to examine all certificates on the production server(s):

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

Validate that the supported Java version works correctly

Since WildFly on Azure Kubernetes Service requires a certain version of Java, you must ensure that your application works properly with that supported version.

Sign in to your production server and perform the following command to determine your current Java version:

java -version

Inventory JNDI resources

Inventory all JNDI resources. Some, such as JMS message brokers, may need to be migrated or reconfigured.

Determine whether session replication is used

If your application is dependent on session replication, you will need to modify it to eliminate this dependence.

Inside your application

Examine the files WEB-INF/jboss-web.xml and/or WEB-INF/web.xml.

Document datasources

If your application makes use of databases, you must collect the following information:

• What is the name of the datasource?
• What is the configuration of the connection pool?
• Where can I get the JDBC driver JAR?

Determine whether and how the file system is used

Any use of the application server's file system will need reconfiguration or, in rare situations, architectural modifications. JBoss EAP modules or your application code may use the file system. You may identify any or all of the events detailed in the following sections.

Read-only static content

If your application presently delivers static content, you'll need to find a new home for it. Consider migrating static material to Azure Blob Storage and adding Azure CDN for worldwide lightning-fast downloads. 

Dynamically published static content

If your application supports static material that is uploaded/produced by your application but is immutable once created, you may use Azure Blob Storage and Azure CDN as stated above, together with an Azure Function to manage uploads and CDN updates. For your convenience, we've included an example implementation at Uploading and CDN-preloading static content with Azure Functions.

Dynamic or internal content

You may mount Azure Storage shares as permanent volumes for files that are often written and read by your application (such as transitory data files) or static files that are accessible exclusively to your application.

Determine whether your application relies on scheduled jobs

Scheduled jobs, such as Quartz Scheduler tasks or Unix cron jobs, are incompatible with Azure Kubernetes Service. The Azure Kubernetes Service will not restrict you from deploying an application using scheduled tasks internally. If your application is scaled out, the same planned job may run many times throughout the scheduled period. This circumstance has the potential to have unforeseen repercussions.

Define Kubernetes CronJobs as needed to execute scheduled jobs on your AKS cluster.

For more information, see Running Automated Tasks with a CronJob.

Determine whether a connection to on-premises is needed

If your application requires access to any of your on-premises services, you must configure one of Azure's connection services. See Choose a solution for connecting an on-premises network to Azure for additional details. Alternatively, you must rework your application to leverage publically available APIs exposed by your on-premises resources.

Determine whether Java Message Service (JMS) Queues or Topics are in use

If you use JMS Queues or Topics in your application, you must transfer them to an externally hosted JMS server. For individuals that use JMS, Azure Service Bus and the Advanced Message Queuing Protocol (AMQP) might be an excellent migration methods. If you have set up JMS persistent stores, you must save their configuration and apply it after the transfer.

Determine whether your application uses JBoss-EAP-specific APIs

If your program relies on JBoss-EAP APIs, you must modify it to eliminate such dependencies.

Determine whether your application uses Entity Beans or EJB 2.x-style CMP Beans

If your program relies on Entity Beans or EJB 2.x style CMP beans, you must restructure it to eliminate these dependencies.

Determine whether the Java EE Application Client feature is in use

If you have client apps that use the Java EE Application Client feature to connect to your (server) application, you must rework both your client applications and your (server) application to use HTTP APIs.

Determine whether your application contains OS-specific code

If your application has code that is dependent on the host OS, you must rework it to eliminate such dependencies. For example, in file system paths, you may need to replace any usage of '/' or '\' with File.Separator or Paths.get.

Determine whether EJB timers are in use

If your application makes use of EJB timers, you must ensure that the EJB timer code may be triggered separately by each WildFly instance. Because each EJB timer will be activated on its own WildFly instance in the Azure Kubernetes Service deployment scenario, this validation is required.

Determine whether JCA connectors are in use

Verify that you can utilize the JCA connector on WildFly if your application supports JCA connectors. If the JCA implementation is dependent on JBoss EAP, your application must be refactored to remove that requirement. Suppose you want to utilize the JCA connector on WildFly. In that case, you must first add the JARs to the server classpath and place the appropriate configuration files in the WildFly server directories.

Determine whether JAAS is in use

If your application uses JAAS, you must document how it is configured. If it's using a database, you may use WildFly to convert it to a JAAS domain. If it is a customized implementation, you must ensure it can be used on WildFly.

Determine whether your application uses a Resource Adapter

If your application requires a Resource Adapter (RA), it must be WildFly compliant. Determine whether the RA works correctly on a solitary instance of WildFly by deploying and configuring it on the server. If the RA performs correctly, you'll need to add the JARs to the Docker image's server classpath and place the relevant configuration files in the WildFly server directory for it to be available.

Determine whether your application is composed of multiple WARs

If your application is made up of many WARs, you should treat each one as a unique application and follow these guidelines for each one.

Determine whether your application is packaged as an EAR

If your application is packaged as an EAR file, inspect the application.xml file and make a note of the configuration.

Identify all outside processes and daemons running on the production servers

If you have any processes operating outside the application server, such as monitoring daemons, you must terminate or relocate them.

Perform in-place testing

Migrate your application to the JDK and WildFly versions that you wish to run on AKS before producing your container images. To verify compatibility and performance, extensively test the program.

Migration

Provision Azure Container Registry and Azure Kubernetes Service

Create a container registry and an Azure Kubernetes cluster with a Service Principal that has the Reader role on the registry using the commands below. Make sure you select the correct network model for your cluster's networking requirements.

az group create -g $resourceGroup -l eastus
az acr create -g $resourceGroup -n $acrName --sku Standard
az aks create -g $resourceGroup -n $aksName --attach-acr $acrName --network-plugin azure

Create a Docker image for WildFly

The following requirements must be met in order to construct a Dockerfile:

• Supported JDK.
• WildFly installation.
• Your JVM runtime options.
• A method for passing in environment variables (if applicable).
   

Then, when appropriate, proceed with the instructions outlined in the following sections. The WildFly Container Quickstart repo may be used as a starting point for your Dockerfile and web application.

1. Configure KeyVault FlexVolume
2. Set up data sources
3. Set up JNDI resources
4. Review WildFly configuration

Configure KeyVault FlexVolume

Create an Azure KeyVault and populate it with all of the required secrets. Then, establish a KeyVault FlexVolume to provide pods access to those secrets.

You'll also need to tweak the startup script that WildFly uses to get up and running. Before launching the server, this script must import the certificates into the WildFly keystore.

Set up data sources

To enable WildFly to connect to a data source, add the JDBC driver JAR to your Docker image and then run the relevant JBoss CLI commands. When creating your Docker image, you must use these commands to configure the data source.

The instructions for PostgreSQL, MySQL, and SQL Server are provided in the following steps.

Download the PostgreSQL, MySQL, or SQL Server JDBC driver. Get the driver.jar file by unpacking the downloaded archive.

Make a file called module.xml and add the following markup to it. Replace the <module name> placeholder (including the angle brackets) with org.postgres for PostgreSQL, com.mysql for MySQL, or com.microsoft for SQL Server. Replace <JDBC .jar file path> with the name of the .jar file from the previous step, including the entire path to the file's location in your Docker image, such as /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>

Create a file called datasource-commands.cli and add the following code to it. Replace <JDBC .jar file path> with the value from the previous step. As an example, substitute /opt/database/module.xml for < module file path> using the file name and location from the previous step.

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

Update your application's JTA datasource configuration: Locate the <jta-data-source> element in your application's src/main/resources/META-INF/persistence.xml file. Replace its contents with the following:

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>

Add the following to your Dockerfile to ensure that the data source is generated when your Docker image is built.

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

Determine the DATABASE CONNECTION URL to use, as it varies each database server and differs from the values on the Azure portal. WildFly requires the following URL formats to be used:

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;

When you create your deployment YAML later, you must supply the following environment variables, DATABASE_CONNECTION_URL, DATABASE_SERVER_ADMIN_FULL_NAME, and DATABASE_SERVER_ADMIN_PASSWORD, with the right values.

Set up JNDI resources

In general, you will take the following procedures to configure each JNDI resource on WildFly:

1. Download the required JAR files and place them in the Docker image.
2. Create a WildFly module.xml file that references the JAR files.
3. Create any settings required by the particular JNDI resource.
4. Create a JBoss CLI script to register the JNDI resource during the Docker build.
5. Include everything in the Dockerfile.
6. In your deployment YAML, provide the required environment variables.
    

The steps required to construct the JNDI resource for JMS connection to Azure Service Bus are shown below.

Install the Apache Qpid JMS provider. 
To obtain the .jar files, unpack the downloaded archive.

In /opt/servicebus, create a file called module.xml and add the following content. Ensure that the JAR file version numbers match the names of the JAR files from the previous step.

<?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>

In /opt/servicebus, create a jndi.properties file.

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}

Create a file called servicebus-commands.cli and add the following code to it.

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

Add the following to your Dockerfile to ensure that the JNDI resource is generated when your Docker image is built.

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

Later on, while generating your deployment YAML, you will need to give the necessary values for the environment variables MDB_CONNECTION_FACTORY, DEFAULT_SBNAMESPACE, and SB_SAS_POLICY, SB_SAS_KEY, MDB_QUEUE, SB_QUEUE, MDB_TOPIC, and SB_TOPIC.

Review WildFly configuration

Check the WildFly Admin Guide for any extra pre-migration tasks that were not covered in the earlier instructions.

Build and push the Docker image to Azure Container Registry

Following the creation of the Dockerfile, you must build the Docker image and publish it to your Azure container registry.

If you utilized the WildFly Container Quickstart GitHub repo provided by Microsoft, generating and publishing your image to your Azure container registry would be equivalent to running the three commands below.

The MY_ACR environment variable carries the name of your Azure container registry in these examples, and the MY_APP_NAME variable has the name of the web application you wish to utilize on your Azure container registry.

Build the WAR file:

mvn package

 

Log in to your Azure container registry as follows:

az acr login -n ${MY_ACR}

 

Create and push the image:

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

Alternatively, as illustrated in the following instructions, you may use Docker CLI to first create and test the image locally. This method simplifies testing and tweaking the picture prior to initial deployment to ACR. However, you must install the Docker CLI and check that the Docker daemon is functioning.
 

Create the image:

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

 

Locally run the image:

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

 

Your application is now accessible at http://localhost:8080.
 

Log in to your Azure container registry as follows:

az acr login -n ${MY_ACR}

 

Upload the image to your Azure container registry as follows:

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

 

Provision a Public IP address

A public static IP address is required if your application is to be accessible from outside your internal or virtual network(s). As illustrated in the following example, you should supply this IP address within your cluster's node resource group:

Azure CLI

nodeResourceGroup=$(az aks show -g $resourceGroup -n $aksName --query 'nodeResourceGroup' -o tsv)
publicIp=$(az network public-ip create -g $nodeResourceGroup -n applicationIp --sku Standard --allocation-method Static --query 'publicIp.ipAddress' -o tsv)
echo "Your public IP address is ${publicIp}."

Deploy to AKS

Make and use your Kubernetes YAML file (s). 

If you're configuring an external load balancer (for your application or an ingress controller), use the IP address specified in the previous section as the LoadBalancerIP.

Include externalized parameters as environment variables.

Do not include any secrets (such as passwords, API keys, and JDBC connection strings). 

When building your deployment YAML, add memory and CPU parameters to ensure that your containers are suitably scaled.

Configure persistent storage

Configure one or more Persistent Volumes if your application requires non-volatile storage.

Migrate scheduled jobs

Define Kubernetes CronJobs as needed to run scheduled jobs on your AKS cluster.

Post-migration

After migrating your application to Azure Kubernetes Service, you should ensure that it operates as expected. After that, we have some suggestions for making your application more cloud-native.

Recommendations

• Consider assigning a DNS name to your ingress controller or application load balancer's IP address. See Create an ingress controller with a static public IP address in AKS for additional details.
• Consider incorporating HELM charts into your application. With a helm chart, you may parameterize your application deployment for usage and modification by a broader range of consumers.
• Create and execute a DevOps strategy. Consider automating deployments and testing using Azure Pipelines to preserve dependability while enhancing the development pace. See Build and deploy to AKS for additional details.
• Make Azure Monitoring available for the cluster. For further information, see Enable monitoring of an already deployed AKS cluster. This enables Azure Monitor to gather container logs and track utilization, etc.
• Consider using Prometheus to expose application-specific metrics. Prometheus is a popular open-source metrics system in the Kubernetes community. Instead of maintaining your own Prometheus server, you may configure Prometheus Metrics scraping in Azure Monitor to enable metrics aggregation from your apps and automatic reaction to or escalation of anomalous events. For further details, read Configure Prometheus metrics scraping with Azure Monitor for containers.
• Create and implement a business continuity and disaster recovery strategy. Consider a multi-region deployment architecture for mission-critical applications. See Best practices for business continuity and disaster recovery in AKS for more information.
• Examine the version support policy for Kubernetes. You must keep your AKS cluster updated always to run a supported version. See Upgrade an AKS cluster for further details.
• Review the relevant AKS best practices with all team members responsible for cluster administration and application development. See Cluster operator and developer best practices for building and managing AKS applications for additional information.
• Check that your deployment file specifies how rolling updates are performed. More information may be found in the Kubernetes documentation under Rolling Update Deployment.
• Set up auto-scaling to handle peak traffic. See Automatically scale a cluster to suit application demands on AKS for additional details.
• To improve speed, consider monitoring the code cache capacity and adding the JVM parameters -XX:InitialCodeCacheSize and -XX:ReservedCodeCacheSize to the Dockerfile. More information may be found in the Oracle documentation under Codecache Tuning.

 

Read about Batch Operating System here.