Rediger

Migrate JBoss EAP applications to JBoss EAP on Azure VMs

  • Artikel

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 JBoss EAP Server on Azure VM using the Azure portal.

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. Write down 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 JBoss EAP Server on an Azure virtual machine using the Azure portal.

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 Configuring a Red Hat JBoss EAP 7 Cluster 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: