Migrer des applications JBoss EAP vers JBoss EAP sur Azure App Service

  • Article

Ce guide décrit ce que vous devez savoir pour migrer une application JBoss EAP existante dans le but de l’exécuter sur JBoss EAP dans une instance Azure App Service.

Prémigration

Pour garantir la réussite de la migration, avant de commencer, effectuez les étapes d’évaluation et d’inventaire décrites dans les sections suivantes.

Inventorier la capacité des serveurs

Documentez le matériel (mémoire, processeur, disque) du ou des serveurs de production actuels ainsi que le nombre moyen et maximal de requêtes et l’utilisation des ressources. Vous aurez besoin de ces informations, quel que soit le chemin de migration que vous choisissez. Il est utile, par exemple, de guider la sélection de la taille des machines virtuelles dans votre pool de nœuds, la quantité de mémoire à utiliser par le conteneur et le nombre de partages d’UC dont le conteneur a besoin.

Il est possible de redimensionner les pools de nœuds dans AKS. Pour en savoir plus, consultez Redimensionner des pools de nœuds dans Azure Kubernetes Service (AKS).

Inventorier tous les secrets

Recherchez les secrets et mots de passe dans l’ensemble des propriétés et fichiers de configuration présents sur le ou les serveurs de production. Veillez à vérifier jboss-web.xml dans vos fichiers WAR. Vous pouvez également trouver des fichiers de configuration contenant des mots de passe ou des informations d’identification au sein de votre application.

Envisagez de stocker ces secrets dans Azure Key Vault. Pour plus d’informations, consultez Concepts de base d’Azure Key Vault.

Vous pouvez utiliser des secrets Key Vault dans votre instance App Service avec des références Key Vault. Les références Key Vault vous permettent d’utiliser les secrets de votre application tout en les maintenant sécurisés et chiffrés au repos. Pour en savoir plus, consultez la section Utiliser des références Key Vault pour App Service et Azure Functions.

Inventorier tous les certificats

Documentez tous les certificats utilisés pour les points de terminaison SSL publics. Vous pouvez voir tous les certificats présents sur les serveurs de production en exécutant la commande suivante :

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

Valider le bon fonctionnement de la version Java prise en charge

JBoss EAP sur les machines virtuelles Azure nécessite une version prise en charge de Java. Pour obtenir des conseils sur la version du JDK à utiliser, consultez configurations prises en charge dans la documentation Red Hat.

Remarque

Cette validation s’avère particulièrement importante si votre serveur actuel s’exécute sur un JDK non pris en charge (comme Oracle JDK ou IBM OpenJ9).

Pour obtenir votre version actuelle de Java, connectez-vous à votre serveur de production et exécutez la commande suivante :

java -version

Inventorier les ressources externes

Les ressources externes, comme les sources de données, les répartiteurs de messages JMS, etc., sont injectées par le biais de l’interface JNDI (Java Naming and Directory Interface). Certaines de ces ressources peuvent nécessiter une migration ou une reconfiguration.

Au sein de votre application

Inspectez les fichiers WEB-INF/jboss-web.xml et/ou WEB-INF/web.xml. Recherchez les éléments <Resource> à l’intérieur de l’élément <Context>.

Sources de données

Les sources de données sont des ressources JNDI dont l’attribut type a la valeur javax.sql.DataSource. Pour chaque source de données, réunissez les informations suivantes :

  • Quel est le nom de la source de données ?
  • Quelle est la configuration du pool de connexions ?
  • Où trouver le fichier JAR du pilote JDBC ?

Pour plus d’informations, consultez About JBoss EAP Datasources (À propos des sources de données JBoss EAP) dans la documentation de JBoss EAP.

Toutes les autres ressources externes

Il n’est pas possible de décrire toutes les dépendances externes possibles dans ce guide. Il incombe à votre équipe de vérifier que vous pouvez satisfaire à toutes les dépendances externes de votre application après la migration.

Déterminer si la réplication de session est utilisée

Si votre application s’appuie sur la réplication de session, vous devez changer votre application pour supprimer cette dépendance. App Service n’autorise pas les instances à communiquer directement entre elles.

Déterminer si le système de fichiers est utilisé et de quelle manière

Toute utilisation du système de fichiers sur le serveur d’applications nécessite une reconfiguration ou, dans de rares cas, des modifications architecturales. Le système de fichiers peut être utilisé par les modules JBoss EAP ou par votre code d’application. Vous pouvez identifier une partie ou l’ensemble des scénarios décrits dans les sections suivantes.

Contenu statique en lecture seule

Si votre application sert actuellement du contenu statique, vous aurez besoin d’un autre emplacement pour lui. Vous pouvez envisager de déplacer du contenu statique vers le Stockage Blob Azure et d’ajouter Azure CDN pour accélérer globalement les téléchargements. Pour plus d’informations, consultez Hébergement de sites web statiques dans le service Stockage Azure et Démarrage rapide : Intégrer un compte de stockage Azure à Azure CDN. Vous pouvez également déployer directement le contenu statique sur une application dans le plan Azure Spring Apps Enterprise. Pour plus d’informations, consultez Déployer des fichiers statiques web.

Contenu statique publié dynamiquement

Si votre application autorise le contenu statique chargé/produit par votre application mais immuable après sa création, vous pouvez utiliser le Stockage Blob Azure et Azure CDN comme décrit ci-dessus, avec une fonction Azure pour gérer les chargements et l’actualisation du réseau CDN. Nous avons mis à votre disposition un exemple d’implémentation dans Chargement et préchargement CDN de contenu statique avec Azure Functions. Vous pouvez également déployer directement le contenu statique sur une application dans le plan Azure Spring Apps Enterprise. Pour plus d’informations, consultez Déployer des fichiers statiques web.

Contenu dynamique ou interne

Pour les fichiers fréquemment écrits et lus par votre application (comme les fichiers de données temporaires) ou les fichiers statiques uniquement visibles pour votre application, vous pouvez utiliser le stockage de fichiers local associé à votre plan de service d’application. Pour plus d’informations, consultez Fonctionnalités du système d’exploitation sur Azure App Service et Compréhension du système de fichiers Azure App Service.

Déterminer si votre application s’appuie sur des tâches planifiées

Les tâches planifiées, comme les tâches Quartz Scheduler ou les travaux cron Unix, NE doivent PAS être utilisées avec Azure App Service. Azure App Service ne vous empêche pas de déployer une application contenant des tâches planifiées en interne. Toutefois, si votre application a fait l’objet d’un scale-out, la même tâche planifiée peut s’exécuter plusieurs fois par période planifiée. Cette situation peut entraîner des conséquences inattendues.

Inventoriez toutes les tâches planifiées en cours d’exécution sur le ou les serveurs de production, à l’intérieur ou à l’extérieur de votre code d’application.

Déterminer si une connexion à un service local est nécessaire

Si votre application doit accéder à vos services locaux, vous devez provisionner l’un des services de connectivité d’Azure. Pour plus d'informations, consultez Choisir une solution pour connecter un réseau local à Azure. Vous avez également besoin de refactoriser votre application pour qu’elle utilise les API publiques disponibles que vos ressources locales exposent.

Déterminer si les files d’attente ou les rubriques JMS (Java Message Service) sont en cours d’utilisation

Si votre application utilise des files d’attente ou des rubriques JMS, vous devez les migrer vers un serveur JMS hébergé en externe. Azure Service Bus et le protocole AMQP (Advanced Message Queuing Protocol) peuvent être une excellente stratégie de migration pour ceux qui utilisent JMS. Pour plus d’informations, consultez Utiliser JMS avec Azure Service Bus et AMQP 1.0.

Si des magasins persistants JMS ont été configurés, vous devez capturer leur configuration et les appliquer après la migration.

Déterminer si des connecteurs JCA sont utilisés

Si votre application utilise des connecteurs JCA, vérifiez que vous pouvez utiliser le connecteur JCA sur JBoss EAP. Si vous pouvez utiliser le connecteur JCA sur JBoss EAP, vous devez, pour qu’il soit disponible, ajouter les fichiers JAR au classpath du serveur et placer les fichiers de configuration nécessaires au bon emplacement dans les répertoires de serveur JBoss EAP.

Déterminer si JAAS est en cours d’utilisation

Si votre application utilise JAAS, vous devez capturer la façon dont il est configuré. Si elle utilise une base de données, vous pouvez la convertir en domaine JAAS sur JBoss EAP. S’il s’agit d’une implémentation personnalisée, vous devez valider qu’elle peut être utilisée sur JBoss EAP.

Déterminer si votre application utilise un adaptateur de ressource

Si votre application nécessite un adaptateur de ressources (RA), il doit être compatible avec JBoss EAP. Déterminez si l’adaptateur RA fonctionne correctement sur une instance autonome de JBoss EAP en le déployant sur le serveur et en le configurant correctement. Si l’adaptateur RA fonctionne correctement, ajoutez les fichiers JAR au classpath du serveur d’App Service, et placez les fichiers config nécessaires à l’emplacement approprié dans les répertoires du serveur JBoss EAP pour qu’il soit disponible.

Déterminer si votre application est composée de plusieurs WAR

Si votre application est composée de plusieurs WAR, vous devez traiter chacun de ces WAR comme des applications distinctes et suivre ce guide pour chacun d’entre eux.

Déterminer si votre application est empaquetée en tant que fichier EAR

Si votre application est empaquetée en tant que fichier EAR, veillez à examiner le fichier application.xml et à capturer la configuration.

Remarque

Si vous souhaitez pouvoir mettre à l’échelle chacune de vos applications web indépendamment pour une meilleure utilisation de vos ressources App Service, vous devez scinder le fichier EAR en applications web distinctes.

Identifier tous les processus et démons extérieurs exécutés sur les serveurs de production

Si vous avez des processus qui s’exécutent en dehors du serveur d’applications, comme les démons de supervision, vous devez les éliminer ou les migrer ailleurs.

Effectuer des tests sur place

Avant de créer des images conteneur, migrez votre application vers les versions du JDK et de JBoss EAP que vous comptez utiliser sur App Service. Testez l’application minutieusement pour garantir sa compatibilité et ses performances.

Notes sur les fonctionnalités de JBoss EAP sur App Service

Si vous utilisez JBoss EAP sur App Service, veillez à tenir compte des remarques suivantes.

  • Console de gestion JBoss EAP : la console web JBoss n’est pas exposée sur App Service. Au lieu de cela, le portail Azure fournit les API de gestion de votre application, et vous devez procéder au déploiement avec Azure CLI, le plug-in Maven Azure ou d’autres outils de développement Azure.

  • Transactions : les instances d’application étant exécutées sans état, l’API Transactions n’est donc pas prise en charge actuellement. Pour plus d’informations, consultez la gestion des transactions sur JBoss EAP dans la documentation de Red Hat.

  • Mode domaine managé : dans un environnement de production multiserveur, le mode domaine managé dans JBoss EAP offre des fonctionnalités managées centralisées. Toutefois, avec JBoss EAP sur App Service, la plateforme App Service assume la responsabilité de la configuration et de la gestion de vos instances de serveur. App Service élimine la nécessité du mode de domaine managé de JBoss EAP. Le mode de domaine convient bien aux déploiements multiserveurs basés sur des machines virtuelles. Pour plus d’informations, consultez À propos des domaines managés dans la documentation de Red Hat.

  • Clustering serveur à serveur : depuis le 15 mars 2022, le déploiement en cluster de JBoss EAP est pris en charge en préversion publique. Cette prise en charge signifie que vous n’avez plus besoin de supprimer les fonctionnalités suivantes de vos applications avant de pouvoir les déployer sur App Service :

    • Haricots de session avec état.
    • Transactions distribuées.
    • Fonctionnalités similaires qui nécessitent une communication d’instance à instance ou une haute disponibilité.

    Pour plus d’informations, consultez l’annonce de publication et la section Clustering dans JBoss EAP de Configurer une application Java pour Azure App Service.

Migration

Red Hat Migration Shared Computer Toolkit for Apps

La Shared Computer Toolkit de migration Red Hat pour Applications est une extension gratuite pour Visual Studio Code. Cette extension analyse le code et la configuration de votre application pour fournir des recommandations pour la migration vers le cloud à partir d’un emplacement local. Pour plus d’informations, consultez Migration Shared Computer Toolkit pour la vue d’ensemble des applications.

Le contenu de ce guide vous aidera à traiter les autres composants du parcours de migration, tels que le choix du type de plan App Service approprié, la externalisation de votre état de session et l’utilisation d’Azure pour gérer vos instances EAP au lieu de l’interface de gestion JBoss.

Provisionner Azure App Service pour le runtime JBoss EAP

Utilisez les commandes suivantes pour créer un groupe de ressources et un plan Azure App Service. Une fois le plan App Service créé, un plan d’application web Linux est créé à l’aide du runtime JBoss EAP. Vous pouvez créer des sites JBoss EAP uniquement aux niveaux de plan App Service Premium V3 et Isolé V2.

Vérifiez que les variables d’environnement spécifiées ont les valeurs appropriées.

Remarque

Les plans Premium V3 et Isolé V2 sont tous deux éligibles aux tarifs d’instance réservée, ce qui peut réduire vos coûts. Pour plus d’informations sur les niveaux de plan App Service et les tarifs d’instance réservée, consultez Tarifs d’App Service.

az group create --resource-group $resourceGroup --location eastus
az acr create --resource-group $resourceGroup --name $acrName --sku Standard
az appservice plan create \
    --resource-group $resourceGroup \
    --name $jbossAppService \
    --is-linux \
    --sku P1V2
az webapp create \
    --resource-group $resourceGroup \
    --name $jbossWebApp \
    --plan $jbossAppServicePlan \
    --runtime "JBOSSEAP|7-java8"
    #  Or use "JBOSSEAP|7-java11" if you're using Java 11

Créer l’application

Générez l’application à l’aide de la commande Maven suivante.

mvn clean install -DskipTests

Déployer l’application

Si votre application est générée à partir d’un fichier POM Maven, utilisez le plug-in Webapp pour Maven pour créer l’application web et déployer votre application. Pour plus d’informations, consultez Démarrage rapide : Créer une application Java sur Azure App Service.

Pour automatiser le déploiement des applications JBoss EAP, vous pouvez utiliser la tâche Azure Pipelines pour application web ou l’action GitHub pour les déploiements sur Azure Web Apps.

Configurer les sources de données

Il existe trois étapes de base lors de l’inscription d’une source de données avec JBoss EAP : chargement du pilote JDBC, ajout du pilote JDBC en tant que module et inscription du module. Pour plus d’informations, consultez Datasource Management dans la documentation de JBoss EAP. App Service est un service d’hébergement sans état. Par conséquent, les commandes de configuration pour l’ajout et l’inscription du module de source de données doivent être scriptées et appliquées au démarrage du conteneur.

Pour configurer des sources de données, effectuez les étapes suivantes.

  1. Obtenez le pilote JDBC de votre base de données.

  2. Créez un fichier de définition de module XML pour le pilote JDBC. L’exemple ci-dessous est une définition de module pour PostgreSQL. Veillez à remplacer la valeur resource-root path par le chemin du pilote JDBC que vous utilisez.

    <?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="org.postgres">
    <resources>
    <!-- ***** IMPORTANT: REPLACE THIS PLACEHOLDER *******-->
    <resource-root path="/home/site/deployments/tools/postgresql-42.2.12.jar" />
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>

  3. Placez vos commandes CLI JBoss dans un fichier nommé jboss-cli-commands.cli. Les commandes JBoss doivent ajouter le module et l’inscrire en tant que source de données. L’exemple ci-dessous montre les commandes d’interface de ligne de commande JBoss pour PostgreSQL.

    module add --name=org.postgres --resources=/home/site/deployments/tools/postgresql-42.2.12.jar --module-xml=/home/site/deployments/tools/postgres-module.xml

/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=${POSTGRES_CONNECTION_URL,env.POSTGRES_CONNECTION_URL:jdbc:postgresql://db:5432/postgres} --user-name=${POSTGRES_SERVER_ADMIN_FULL_NAME,env.POSTGRES_SERVER_ADMIN_FULL_NAME:postgres} --password=${POSTGRES_SERVER_ADMIN_PASSWORD,env.POSTGRES_SERVER_ADMIN_PASSWORD:example} --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

  4. Créez un script de démarrage appelé startup_script.sh, qui appelle les commandes CLI JBoss. L’exemple ci-dessous montre comment appeler le fichier jboss-cli-commands.cli. Vous configurerez plus tard App Service pour exécuter ce script au démarrage de l’instance.

    $JBOSS_HOME/bin/jboss-cli.sh --connect --file=/home/site/deployments/tools/jboss-cli-commands.cli

  5. À l’aide du client FTP de votre choix, chargez le pilote JDBC, jboss-cli-commands.cli, startup_script.sh et la définition de module dans /site/deployments/tools/.

  6. Configurez votre site pour exécuter startup_script.sh au démarrage du conteneur. Dans le Portail Azure, accédez à Configuration > Général Paramètres > Commande de démarrage. Affectez au champ de commande de démarrage la valeur /home/site/deployments/tools/startup_script.sh, puis sélectionnez Enregistrer.

  7. Redémarrez l’application web, ce qui entraîne l’exécution du script de configuration.

  8. Mettez à jour la configuration de la source de données JTA pour votre application. Ouvrez le fichier src/main/resources/META-INF/persistence.xml de votre application et recherchez l’élément <jta-data-source>. Remplacez son contenu comme indiqué ici :

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

Créer l’application

Générez l’application à l’aide de la commande Maven suivante.

mvn clean install -DskipTests

Déployer l’application

Si votre application est générée à partir d’un fichier POM Maven, utilisez le plug-in Webapp pour Maven pour créer l’application web et déployer votre application. Pour plus d’informations, consultez Démarrage rapide : Créer une application Java sur Azure App Service.

Pour automatiser le déploiement des applications JBoss EAP, vous pouvez utiliser la tâche Azure Pipelines pour application web ou l’action GitHub pour les déploiements sur Azure Web Apps.

Post-migration

Maintenant que vous avez migré votre application vers Azure App Service, vous devez vérifier qu’elle fonctionne comme prévu. Une fois que vous avez terminé, vous recevez nos recommandations qui vous permettent de rendre votre application plus native dans le cloud.

Recommandations