Migrate JBoss EAP applications to JBoss EAP on Azure VMs
This guide describes what you should be aware of when you want to migrate an existing JBoss EAP application to run on JBoss EAP in Azure VMs.
Pre-migration
To ensure a successful migration, before you start, complete the assessment and inventory steps described in the following sections.
Define what you mean by "migration complete"
This guide, and the corresponding Azure Marketplace offers, are a starting point to accelerate the migration of your JBoss EAP workloads to Azure. It's important to define the scope of your migration effort. For example, are you doing a strict "lift and shift" from your existing infrastructure to Azure Virtual Machines? If so, you may be tempted to work in some "lift and improve" as you migrate.
It's better to stick as close to pure "lift and shift" as possible, accounting for the necessary changes as detailed in this guide. Define what you mean by "migration complete" so that you know when you've reached this milestone. When you've reached your "migration complete", you can take a snapshot of your virtual machines as described in Create a snapshot of a virtual hard disk. It's safer to do the improvements after you've verified that you can successfully restore from your snapshot. That way you can proceed without fear of losing the migration progress you've achieved thus far.
Determine whether the prebuilt Azure Marketplace offers are a good starting point
Red Hat and Microsoft have partnered to bring a set of Azure solution templates to Azure Marketplace to provide a solid starting point for migrating to Azure. You can see the list of offers in the JBoss EAP on Azure Virtual Machines section of Red Hat JBoss EAP on Azure.
To get a feel for the prebuilt Azure Marketplace offer, see Quickstart: Deploy a JBoss EAP cluster on Azure Virtual Machines (VMs).
If none of the existing offers are a good starting point, you have to reproduce the deployment by hand using the resources available in Azure Virtual Machines. For more information, see What is IaaS?
Determine whether the JBoss EAP version is compatible
Your existing JBoss EAP version must be compatible with the version in the infrastructure-as-a-service (IaaS) offers. The Azure portal pages for the offers show which versions of JBoss EAP are available. For more information, see the JBoss EAP Cluster on VMs offer on the Azure portal. If your existing JBoss EAP version isn't compatible with the versions available in the offer, you have to reproduce the deployment by hand using Azure IaaS resources. For more information, see What is IaaS?
Ensure you have the necessary licenses
When using the prebuilt Azure Marketplace offers, you must have current licenses from Red Hat for all of your JBoss EAP servers. Moving them to Azure, you can choose between the following deployment options to meet your needs:
- Deploy on Red Hat Enterprise Linux pay-as-you-go virtual machines. This option is known as PAYG.
- Move your Red Hat JBoss EAP and Red Hat Enterprise Linux subscriptions to Azure through the Red Hat Cloud Access program. This option is known as BYOS.
In both options, for license portability, you're asked for the Pool ID from Red Hat. Make sure you have this ID on hand before trying the offers.
The prebuilt Azure Marketplace offers include support for Red Hat Satellite for license management. For an overview on Red Hat Satellite, see Red Hat Satellite.
Note
If you don't have an EAP entitlement, you can sign up for a free developer subscription through the Red Hat Developer Subscription for Individuals. Save aside the account details for use as the RHSM username and RHSM password in the prebuilt Azure Marketplace offers.
The steps for discovering your Pool ID are explained in the Prerequisites section in Quickstart: Deploy a JBoss EAP cluster on Azure Virtual Machines (VMs).
Inventory server capacity
Document the hardware (memory, CPU, disk) of the current production server(s) and the average and peak request counts and resource utilization. You'll need this information regardless of the migration path you choose. It's useful, for example, to help guide selection of the size of the VMs in your node pool, the amount of memory to be used by the container, and how many CPU shares the container needs.
It's possible to resize node pools in AKS. To learn how, see Resize node pools in Azure Kubernetes Service (AKS).
Inventory all secrets
Check all properties and configuration files on the production server or servers for any secrets and passwords. Be sure to check the jboss-web.xml file in your WARs. Configuration files that contain passwords or credentials may also be found inside your application.
Consider storing those secrets in Azure KeyVault. For more information, see Azure Key Vault basic concepts.
Inventory all certificates
Document all the certificates used for public SSL endpoints. You can view all certificates on the production server(s) by running the following command:
keytool -list -v -keystore <path to keystore>
Validate that the supported Java version works correctly
JBoss EAP on Azure VMs requires a supported version of Java. For guidance on which version of the JDK to use, see Supported Configurations in the Red Hat documentation.
Note
This validation is especially important if your current server is running on an unsupported JDK (such as Oracle JDK or IBM OpenJ9).
To obtain your current Java version, sign in to your production server and run the following command:
java -version
Inventory external resources
External resources, such as data sources, JMS message brokers, and others are injected via Java Naming and Directory Interface (JNDI). Some such resources may require migration or reconfiguration.
Inside your application
Inspect the WEB-INF/jboss-web.xml and/or WEB-INF/web.xml files. Look for <Resource>
elements inside the <Context>
element.
Datasources
Datasources are JNDI resources with the type
attribute set to javax.sql.DataSource
. For each datasource, document the following information:
- What is the datasource name?
- What is the connection pool configuration?
- Where can I find the JDBC driver JAR file?
For more information, see About JBoss EAP Datasources in the JBoss EAP documentation.
All other external resources
It isn't feasible to document every possible external dependency in this guide. It's your team's responsibility to verify that you can satisfy every external dependency of your application after the migration.
Determine whether and how the file system is used
Any usage of the file system on the application server requires reconfiguration or, in rare cases, architectural changes. JBoss EAP modules or your application code may use the file system. You may identify some or all of the scenarios described in the following sections.
Read-only static content
If your application currently serves static content, you'll need an alternate location for it. You may wish to consider moving static content to Azure Blob Storage and adding Azure CDN for lightning-fast downloads globally. For more information, see Static website hosting in Azure Storage and Quickstart: Integrate an Azure storage account with Azure CDN. You can also directly deploy the static content to an app in the Azure Spring Apps Enterprise plan. For more information, see Deploy web static files.
Dynamically published static content
If your application allows for static content that is uploaded/produced by your application but is immutable after its creation, you can use Azure Blob Storage and Azure CDN as described above, with an Azure Function to handle uploads and CDN refresh. We've provided a sample implementation for your use at Uploading and CDN-preloading static content with Azure Functions. You can also directly deploy the static content to an app in the Azure Spring Apps Enterprise plan. For more information, see Deploy web static files.
Determine whether a connection to on-premises is needed
If your application needs to access any of your on-premises services, you'll need to provision one of Azure's connectivity services. For more information, see Choose a solution for connecting an on-premises network to Azure. Alternatively, you'll need to refactor your application to use publicly available APIs that your on-premises resources expose.
Determine whether Java Message Service (JMS) Queues or Topics are in use
If your application is using JMS Queues or Topics, you'll need to migrate them to an externally hosted JMS server. Azure Service Bus and the Advanced Message Queuing Protocol (AMQP) can be a great migration strategy for those using JMS. For more information, see Use JMS with Azure Service Bus and AMQP 1.0.
If JMS persistent stores have been configured, you must capture their configuration and apply it after the migration.
Determine whether JCA connectors are in use
If your application uses JCA connectors, validate that you can use the JCA connector on JBoss EAP. If you can use the JCA connector on JBoss EAP, then for it to be available, you must add the JARs to the server classpath and put the necessary configuration files in the correct location in the JBoss EAP server directories.
Determine whether JAAS is in use
If your application is using JAAS, you'll need to capture how JAAS is configured. If it's using a database, you can convert it to a JAAS domain on JBoss EAP. If it's a custom implementation, you'll need to validate that it can be used on JBoss EAP.
Determine whether your application is composed of multiple WARs
If your application is composed of multiple WARs, you should treat each of those WARs as separate applications and go through this guide for each of them.
Determine whether your application is packaged as an EAR
If your application is packaged as an EAR file, be sure to examine the application.xml file and capture the configuration.
Note
If you want to be able to scale each of your web applications independently for better use of your Azure VM resources, you should break up the EAR into separate web applications.
Identify all outside processes and daemons running on the production servers
If you have any processes running outside the application server, such as monitoring daemons, you'll need to eliminate them or migrate them elsewhere.
Migration
Select a JBoss EAP on Azure Virtual Machines offer
The offers described in the following sections are available for JBoss EAP on Azure Virtual Machines.
During the deployment of an offer, you're asked to choose the virtual machine size for your JBoss EAP server nodes. It's important to consider all aspects of sizing (memory, processor, disk) in your choice of VM size. For more information, see Sizes for Cloud Services (classic).
JBoss EAP on Azure Virtual Machine Scale Sets
Virtual Machine Scale Sets provide groups of load-balanced, highly scalable virtual machines for workloads of any size. For more information, see What are Virtual Machine Scale Sets?
JBoss EAP on Clustered Virtual Machines
If you prefer, a traditional cluster of VMs using the JBoss EAP clustering mechanism is suitable for a lift and shift from deployments that are already using this feature. For more information, see Clustering in Web Applications in the JBoss EAP documentation. The prebuilt Azure Marketplace offer includes support for domain mode. For an overview of EAP Domains and domain mode, see Domain Management.
JBoss EAP Single Server
If you only need a single server, perhaps for testing and evaluation, or for lightweight workloads, there's an offer that deploys a JBoss EAP single server on a single VM.
Red Hat Migration Toolkit for Apps
The Red Hat Migration Toolkit for Applications is a free extension for Visual Studio Code. This extension analyzes your application code and configuration to provide recommendations for migrating to the cloud from on-premises. For more information, see Migration Toolkit for Applications overview.
The contents of this guide help you address the other components of the migration journey, such as choosing the correct VM size, and externalizing your session state.
Post-migration
After you've reached the migration goals you defined in the pre-migration step, perform some end-to-end acceptance testing to verify that everything works as expected. For information about some potential post-migration enhancements, see the following articles:
Use Azure Storage to serve static content mounted to the virtual machines. For more information, see Attach or detach a data disk for a lab virtual machine in Azure DevTest Labs.
Deploy your applications to your migrated JBoss EAP cluster with Azure DevOps. For more information, see Get started with Azure DevOps documentation.
Enhance your network topology with advanced load balancing services. For more information, see Using load-balancing services in Azure.
Use Azure Managed Identities to manage secrets and assign role-based access to Azure resources. For more information, see What are managed identities for Azure resources?
Integrate Java EE authentication and authorization with Microsoft Entra ID. For more information, see Integrating Microsoft Entra ID with applications getting started guide.
Use Azure Key Vault to store any information that functions as a "secret". For more information, see Azure Key Vault basic concepts.