Migration d’applications WebLogic Server vers WildFly dans Azure Kubernetes Service

Article
09/27/2024

Ce guide décrit ce que vous devez savoir lorsque vous souhaitez migrer une application WebLogic Server existante pour qu’elle s’exécute sur WildFly dans un conteneur Azure Kubernetes 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.

Si vous ne pouvez pas répondre aux exigences de pré-migration, consultez le guide de migration complémentaire :

Migrer des applications WebLogic Server vers des machines virtuelles Azure

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. Cela est utile, par exemple, pour 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 parts CPU nécessaires pour le conteneur.

Il est possible de redimensionner les pools de nœuds dans AKS. Pour savoir comment, consultez la section Redimensionner les pools de nœuds dans Azure Kubernetes Service (AKS).

Inventorier tous les secrets

Avant l’avènement des technologies de « configuration en tant que service » comme Azure Key Vault, le concept de « secrets » n’était pas bien défini. Vous aviez plutôt un ensemble disparate de paramètres de configuration qui fonctionnaient en réalité comme ce que nous appelons maintenant des « secrets ». Avec les serveurs d’applications comme WebLogic Server, ces secrets se trouvent dans de nombreux fichiers de configuration et magasins de configurations différents. 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 WebLogic.xml dans vos WAR. Vous pouvez également trouver des fichiers de configuration contenant des mots de passe ou des informations d’identification au sein de votre application. Pour plus d’informations, consultez Concepts de base d’Azure Key Vault.

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>

Inventorier les ressources JNDI

Inventoriez toutes les ressources JNDI. Par exemple, des sources de données comme les bases de données peuvent avoir un nom JNDI associé qui permet à JPA de lier correctement des instances de EntityManager à une base de données en particulier. Pour plus d’informations sur les ressources et les bases de données JNDI, consultez WebLogic Server Data Sources dans la documentation Oracle. D’autres ressources liées à JNDI, telles que les répartiteurs de messages JMS, peuvent nécessiter une migration ou une reconfiguration. Pour plus d’informations sur la configuration de JMS, voir Oracle WebLogic Server 12.2.1.4.0.

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

Si votre application s’appuie sur la réplication de session, avec ou sans Oracle Coherence*Web, vous avez deux options :

Refactorisez votre application afin d’utiliser une base de données pour la gestion des sessions.
Refactorisez votre application pour externaliser la session dans Azure Redis Service. Pour plus d’informations, consultez Azure Cache pour Redis.

Documenter les sources de données

Si votre application utilise des bases de données, vous devez capturer 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 sur les pilotes JDBC dans WebLogic, consultez Using JDBC Drivers with WebLogic Server.

Déterminer si WebLogic a été personnalisé

Déterminez quelles personnalisations parmi les suivantes ont été apportées et capturez ce qui a été fait.

Est-ce que les scripts de démarrage ont changé ? Ces scripts comprennent setDomainEnv, commEnv, startWebLogic et stopWebLogic.
Est-ce que des paramètres spécifiques ont été transmis à JVM ?
Est-ce que des fichiers JAR ont été ajoutés au classpath du serveur ?

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 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 en savoir plus, consulter Utiliser Java Message Service 1.1 avec Azure Service Bus standard 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 vous utilisez vos propres bibliothèques Shared Java EE que vous avez créées

Si vous utilisez la fonctionnalité de bibliothèque Shared Java EE, vous avez deux options :

Refactorisez votre code d’application pour supprimer toutes les dépendances de vos bibliothèques et incorporez plutôt la fonctionnalité directement dans votre application.
Ajoutez les bibliothèques dans le classpath du serveur.

Déterminer si les bundles OSGi sont utilisés

Si vous avez utilisé des bundles OSGi ajoutés à WebLogic Server, vous devez ajouter les fichiers JAR équivalents directement à votre application web.

Déterminer si votre application contient du code propre au système d’exploitation

Si votre application contient du code avec des dépendances vis-à-vis du système d’exploitation hôte, vous devez la refactoriser pour supprimer ces dépendances. Par exemple, vous devrez peut-être remplacer toute utilisation de / ou \ dans les chemins d'accès au système de fichiers par File.Separator ou Paths.get si votre application fonctionne sous Windows.

Déterminer si Oracle Service Bus est en cours d’utilisation

Si votre application utilise Oracle Service Bus (OSB), vous devez capturer la façon dont il est configuré. Pour plus d’informations, consultez About the Oracle Service Bus Installation.

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 les fichiers application.xml et weblogic-application.xml et à capturer leurs configurations.

Remarque

Si vous souhaitez pouvoir mettre à l’échelle chacune de vos applications Web de manière indépendante pour une meilleure utilisation de vos ressources Azure Kubernetes Service, vous devez décomposer le RAE 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.

Valider le bon fonctionnement de la version Java prise en charge

L’utilisation de WildFly sur Azure Kubernetes Service nécessite une version spécifique de Java. Vous devez donc vérifier que votre application s’exécute correctement avec cette version prise en charge.

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

Pour obtenir des conseils sur la version à utiliser pour l’exécution de WildFly, consultez Requirements (Exigences).

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

Les tâches planifiées, telles que les tâches Quartz Scheduler ou les tâches cron Unix, ne doivent PAS être utilisées avec Azure Kubernetes Service (AKS). Azure Kubernetes 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.

Pour exécuter des tâches planifiées sur votre cluster AKS, définissez des CronJobs Kubernetes selon les besoins. Pour plus d’informations, consultez Exécution de tâches automatisées avec un CronJob.

Déterminer si l’outil de script WebLogic est utilisé

Si vous utilisez actuellement l’outil de script WebLogic (WLST) pour effectuer le déploiement, vous devrez évaluer ce qu’il fait. Si WLST modifie des paramètres (d’exécution) de votre application dans le cadre du déploiement, assurez-vous que ces paramètres sont conformes à l’une des options suivantes :

Les paramètres sont externalisés en tant que paramètres de l’application.
Les paramètres sont intégrés dans votre application.
Les paramètres utilisent la CLI de JBoss pendant le déploiement.

Si WLST fait plus que ce qui est mentionné ci-dessus, vous aurez du travail supplémentaire à faire pendant la migration.

Déterminer si votre application utilise des API propres à WebLogic

Si votre application utilise des API propres à WebLogic, vous devez la refactoriser pour supprimer ces dépendances. Par exemple, si vous avez utilisé une classe mentionnée dans la Référence de l’API Java pour Oracle WebLogic Server, vous avez utilisé une API propre à WebLogic dans votre application. Vous devrez refactoriser pour supprimer la référence.

Déterminer si votre application utilise des Entity Beans ou des CMP Beans de style EJB 2.x

Si votre application utilise des Entity Beans ou des CMP Beans de style EJB 2.x, vous devez refactoriser votre application pour supprimer ces dépendances.

Déterminer si la fonctionnalité Java EE Application Client est en cours d’utilisation

Si vous avez des applications clientes qui se connectent à votre application (serveur) à l’aide de la fonctionnalité Java EE Application Client, vous devez refactoriser vos applications clientes et votre application (serveur) de manière à ce qu’elles utilisent des API HTTP.

Déterminer si un plan de déploiement a été utilisé

Si votre application a été déployée à l’aide d’un plan de déploiement, évaluez ce que fait le plan de déploiement. Si le plan de déploiement correspond à un déploiement simple, vous pourrez déployer votre application web sans aucune modification. Si le plan de déploiement est plus élaboré, déterminez si vous pouvez utiliser la CLI de JBoss pour configurer correctement votre application dans le cadre du déploiement. S’il n’est pas possible d’utiliser la CLI de JBoss, remaniez votre application de manière à ce qu’un plan de déploiement ne soit plus nécessaire.

Déterminer si des minuteurs EJB sont en cours d’utilisation

Si votre application utilise des minuteurs EJB, vous devez vérifier que le code du minuteur EJB peut être déclenché par chaque instance WildFly de manière indépendante. Cette validation est nécessaire car, dans le scénario de déploiement Azure Kubernetes Service, chaque minuteur EJB est déclenché sur sa propre instance WildFly.

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 changements architecturaux. Le système de fichiers peut être utilisé par les modules partagés de WebLogic ou par le code de votre application. Vous pouvez identifier certains ou tous les 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 le contenu statique vers Azure Blob Storage et d'ajouter Azure CDN pour des téléchargements rapides à l'échelle mondiale. 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.

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.

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 monter des partages de stockage Azure en tant que volumes persistants. Pour en savoir plus, consultez la section Créer et utiliser un volume avec Azure Files dans Azure Kubernetes Service (AKS).

Déterminer si des connecteurs JCA sont utilisés

Si votre application utilise des connecteurs JCA, vous devez vérifier que ceux-ci peuvent être utilisés dans WildFly. Si l’implémentation JCA est liée à WebLogic, vous devez refactoriser votre application pour supprimer cette dépendance. Si vous pouvez l’utiliser, vous devez ajouter les fichiers JAR au classpath du serveur et placer les fichiers de configuration nécessaires dans le bon répertoire du serveur WildFly pour que ceux-ci soient disponibles.

Déterminer si votre application utilise un adaptateur de ressource

Si votre application nécessite un adaptateur de ressources (RA), celui-ci doit être compatible avec WildFly. Déterminez si le RA fonctionne correctement sur une instance autonome de WildFly en le déployant sur le serveur et en le configurant comme il faut. S’il fonctionne correctement, vous devez ajouter les fichiers JAR au classpath du serveur de l’image Docker et placer les fichiers de configuration nécessaires dans le bon répertoire du serveur WildFly pour que ceux-ci soient disponibles.

Déterminer si JAAS est en cours d’utilisation

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

Déterminer si le clustering WebLogic est utilisé

Vous avez très probablement déployé votre application sur plusieurs serveurs WebLogic pour bénéficier d’une haute disponibilité. Azure Kubernetes Service est capable de se mettre à l’échelle, mais si vous avez utilisé l’API WebLogic Cluster, vous devez remanier votre code pour éliminer l’utilisation de cette API.

Effectuer des tests sur place

Avant de créer vos images conteneur, migrez votre application vers les versions JDK et WildFly que vous envisagez d’utiliser sur AKS. Testez l’application minutieusement pour garantir sa compatibilité et ses performances.

Migration

Provisionner Azure Container Registry et Azure Kubernetes Service

Utilisez les commandes suivantes pour créer un registre de conteneurs et un cluster Azure Kubernetes avec un principal de service ayant le rôle Lecteur sur le registre. Veillez à choisir le modèle réseau adapté aux exigences de mise en réseau de votre cluster.

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

Créer une image Docker pour WildFly

Pour créer un Dockerfile, vérifiez que les prérequis suivants sont respectés :

Un JDK pris en charge
Une installation de WildFly
Vos options de runtime JVM
Un moyen de passer des variables d’environnement (le cas échéant)

Vous pouvez ensuite effectuer les étapes décrites dans les sections suivantes, le cas échéant. Vous pouvez utiliser le dépôt WildFly Container Quickstart comme point de départ pour votre Dockerfile et votre application web.

Configurer un FlexVolume de coffre de clés
Configurer les sources de données
Configurer les ressources JNDI
Passer en revue la configuration de WildFly

Configurer un FlexVolume de coffre de clés

Créez un coffre de clés Azure et renseignez tous les secrets nécessaires. Pour plus d’informations, consultez Démarrage rapide : Définir et récupérer un secret depuis Azure Key Vault à l’aide d’Azure CLI. Ensuite, configurez un FlexVolume de coffre de clés pour rendre ces secrets accessibles aux pods.

Vous devez également mettre à jour le script de démarrage utilisé pour démarrer WildFly. Ce script doit importer les certificats dans le magasin de clés utilisé par WildFly avant de démarrer le serveur.

Configurer les sources de données

Pour configurer WildFly afin d’accéder à une source de données, vous devez ajouter le fichier JAR du pilote JDBC à votre image Docker, puis exécuter les commandes CLI JBoss appropriées. Ces commandes doivent configurer la source de données lors de la génération de votre image Docker.

Les étapes suivantes fournissent des instructions pour PostgreSQL, MySQL et SQL Server.

Téléchargez le pilote JDBC pour PostgreSQL, MySQL ou SQL Server.

Décompressez l’archive téléchargée pour obtenir le fichier .jar de pilote.
Créez un fichier avec un nom tel que module.xml et ajoutez le balisage suivant. Remplacez l’espace réservé <module name> (y compris les accolades) par org.postgres pour PostgreSQL, com.mysql pour MySQL ou com.microsoft pour SQL Server. Remplacez <JDBC .jar file path> par le nom du fichier .jar de l’étape précédente, y compris le chemin complet à l’emplacement où le fichier sera placé dans votre image Docker, par exemple dans /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>
```

Créez un fichier avec un nom tel que datasource-commands.cli et ajoutez le code suivant. Remplacez <JDBC .jar file path> par la valeur que vous avez utilisée à l’étape précédente. Remplacez <module file path> par le nom de fichier et le chemin de l’étape précédente, par exemple /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

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 :

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

Ajoutez ce qui suit à votre Dockerfile pour que la source de données soit créée quand vous générez votre image 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

Déterminez les valeurs DATABASE_CONNECTION_URL à utiliser car elles varient selon chaque serveur de base de données et diffèrent de celles sur le portail Azure. Les formats d’URL indiqués ici sont obligatoires pour une utilisation par 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;

Quand vous créerez votre fichier YAML de déploiement à un stade ultérieur, vous devrez passer les variables d’environnement DATABASE_CONNECTION_URL, DATABASE_SERVER_ADMIN_FULL_NAME et DATABASE_SERVER_ADMIN_PASSWORD avec les valeurs appropriées.

Pour plus d’informations sur la configuration de la connectivité de base de données avec WildFly, consultez PostgreSQL, MySQL ou SQL Server.

Configurer les ressources JNDI

Pour configurer chaque ressource JNDI nécessaire sur WildFly, vous devez généralement effectuer les étapes suivantes :

Téléchargez les fichiers JAR nécessaires et copiez-les dans l’image Docker.
Créez un fichier WildFly module.xml référençant ces fichiers JAR.
Créez une configuration requise par la ressource JNDI spécifique.
Créez un script CLI JBoss à utiliser durant la génération Docker pour inscrire la ressource JNDI.
Ajoutez tout à Dockerfile.
Passez les variables d’environnement appropriées dans votre fichier YAML de déploiement.

L’exemple ci-dessous montre les étapes nécessaires à la création de la ressource JNDI pour la connectivité JMS à Azure Service Bus.

Téléchargez le fournisseur Apache Qpid JMS.

Décompressez l’archive téléchargée pour obtenir les fichiers .jar.

Créez un fichier avec un nom tel que module.xml et ajoutez le balisage suivant dans /opt/servicebus. Vérifiez que les numéros de version des fichiers JAR correspondent aux noms des fichiers JAR de l’étape précédente.

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

Créez un fichier jndi.properties dans /opt/servicebus.

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}

Créez un fichier avec un nom tel que servicebus-commands.cli et ajoutez le code suivant.

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

Ajoutez ce qui suit à votre Dockerfile pour créer la ressource JNDI quand vous générez votre image 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/servicebus/servicebus-commands.cli && \
sleep 30

Quand vous créerez votre fichier YAML de déploiement à un stade ultérieur, vous devrez passer les variables d’environnement MDB_CONNECTION_FACTORY, DEFAULT_SBNAMESPACE, SB_SAS_POLICY, SB_SAS_KEY, MDB_QUEUE, SB_QUEUE, MDB_TOPIC et SB_TOPIC avec les valeurs appropriées.

Passer en revue la configuration de WildFly

Consultez le guide d’administration de WildFly pour découvrir les étapes de prémigration supplémentaires non couvertes par les instructions précédentes.

Générer l’image Docker et l’envoyer (push) à Azure Container Registry.

Après avoir créé le Dockerfile, vous devez générer l’image Docker et la publier sur votre registre de conteneurs Azure.

Si vous avez utilisé notre dépôt GitHub WildFly Container Quickstart, le processus de génération de l’image et de son envoi (push) à votre registre de conteneurs Azure revient à appeler les trois commandes suivantes.

Dans ces exemples, la variable d’environnement MY_ACR contient le nom de votre registre de conteneurs Azure et la variable MY_APP_NAME contient le nom de l’application web que vous souhaitez utiliser sur votre registre de conteneurs Azure.

Générez le fichier WAR :

mvn package

Connectez-vous à votre registre de conteneurs Azure :

az acr login --name ${MY_ACR}

Générez et envoyez (push) l’image :

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

Vous pouvez également utiliser l’interface CLI de Docker pour générer et tester l’image localement, comme indiqué dans les commandes suivantes. Cette approche peut simplifier le test et l’affinage de l’image avant son déploiement initial sur ACR. Toutefois, vous devez installer l’interface CLI de Docker et vérifier que le démon Docker est en cours d’exécution.

Générez l’image :

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

Exécutez l’image localement :

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

Vous pouvez maintenant accéder à votre application sur http://localhost:8080.

Connectez-vous à votre registre de conteneurs Azure :

az acr login --name ${MY_ACR}

Envoyez (push) l’image à votre registre de conteneurs Azure :

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

Pour plus d’informations sur la génération et le stockage d’images conteneur dans Azure, consultez le module Learn Créer et stocker des images conteneur avec Azure Container Registry.

Provisionner une adresse IP publique

Si votre application doit être accessible à l’extérieur de vos réseaux internes ou virtuels, vous avez besoin d’une adresse IP statique publique. Vous devez provisionner cette adresse IP dans le groupe de ressources du nœud de votre cluster, comme indiqué dans l’exemple suivant :

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}."

Déployer sur Azure Kubernetes Service (AKS)

Créez et appliquez un ou plusieurs fichiers YAML Kubernetes. Pour plus d’informations, consultez Démarrage rapide : Déployer un cluster Azure Kubernetes Service (AKS) à l’aide d’Azure CLI. Si vous créez un équilibreur de charge externe (que ce soit pour votre application ou un contrôleur d’entrée), veillez à fournir l’adresse IP provisionnée dans la section précédente en tant que LoadBalancerIP.

Incluez les paramètres externalisés en tant que variables d’environnement. Pour plus d’informations, consultez Définir des variables d’environnement pour un conteneur. N’incluez pas de secrets (comme des mots de passe, des clés API et des chaînes de connexion JDBC). Ceux-ci sont traités dans la section suivante.

Veillez à inclure des paramètres de mémoire et de processeur lors de la création de votre fichier YAML de déploiement pour que vos conteneurs soient correctement dimensionnés.

Configurer un stockage persistant

Si votre application nécessite un stockage non volatile, configurez un ou plusieurs volumes persistants.

Migrer des tâches planifiées

Post-migration

Maintenant que vous avez effectué la migration de votre application vers Azure Kubernetes Service, vous devez vérifier qu’elle fonctionne comme prévu. Une fois que vous avez fait cela, consultez les recommandations suivantes pour rendre votre application plus cloud-native.

Recommandations

Envisagez d’ajouter un nom DNS à l’adresse IP allouée à votre contrôleur d’entrée ou à votre équilibreur de charge d’application. Pour plus d’informations, veuillez consulter la section Utiliser TLS avec un contrôleur d’entrée sur Azure Kubernetes Service (AKS).
Envisagez d’ajouter des graphiques HELM pour votre application. Un graphique Helm vous permet de paramétrer le déploiement de votre application pour qu’un ensemble de clients plus diversifié puisse l’utiliser et la personnaliser.
Concevez et implémentez une stratégie DevOps. Pour maintenir la fiabilité tout en accélérant le développement, envisagez d’automatiser les déploiements et les tests avec Azure Pipelines. Pour en savoir plus, consultez la section Construire et déployer vers Azure Kubernetes Service avec Azure Pipelines.
Activez la supervision Azure pour le cluster. Pour plus d’informations, consultez Activer le monitoring pour des clusters Kubernetes. Azure Monitor peut ainsi collecter les journaux de conteneurs, faire le suivi de l’utilisation, etc.
Envisagez d’exposer des métriques propres à l’application par le biais de Prometheus. Prometheus est un framework de métriques open source largement adopté par la communauté Kubernetes. Vous pouvez configurer la capture de métriques Prometheus dans Azure Monitor au lieu d’héberger votre propre serveur Prometheus pour permettre l’agrégation des métriques à partir de vos applications, ainsi que la réponse automatisée ou l’escalade des conditions anormales. Pour en savoir plus, consulter Activer Prometheus et Grafana.
Concevez et implémentez une stratégie de continuité de l’activité et de reprise d’activité. Pour les applications stratégiques, envisagez une architecture de déploiement multirégion. Pour en savoir plus, consulter Aperçu de la haute disponibilité et de la reprise après sinistre pour Azure Kubernetes Service (AKS).
Passez en revue la stratégie de prise en charge des versions de Kubernetes. Il vous incombe de continuellement mettre à jour votre cluster AKS pour veiller à ce qu’il exécute toujours une version prise en charge. Pour en savoir plus, consulter Options de mise à niveau pour les clusters Azure Kubernetes Service (AKS).
Demandez à tous les membres d’équipe responsables de l’administration des clusters et du développement des applications d’examiner les bonnes pratiques AKS pertinentes. Pour en savoir plus, consulter Meilleures pratiques des opérateurs de cluster et des développeurs pour créer et gérer des applications sur Azure Kubernetes Service (AKS).
Vérifiez que votre fichier de déploiement spécifie la façon dont les mises à jour propagées sont effectuées. Pour plus d’informations, consultez la rubrique sur le déploiement des mises à jour propagées dans la documentation Kubernetes.
Configurez la mise à l’échelle automatique pour faire face aux pics de charge. Pour plus d’informations, consultez Utiliser l'autoscaler de cluster dans Azure Kubernetes Service (AKS).
Envisagez de superviser la taille du cache de code et d’ajouter les paramètres JVM -XX:InitialCodeCacheSize et -XX:ReservedCodeCacheSize dans le Dockerfile pour améliorer davantage les performances. Pour plus d’informations, consultez la rubrique sur le paramétrage de codecache dans la documentation Oracle.

Partager via

Migration d’applications WebLogic Server vers WildFly dans Azure Kubernetes Service

Prémigration

Inventorier la capacité des serveurs

Inventorier tous les secrets

Inventorier tous les certificats

Inventorier les ressources JNDI

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

Documenter les sources de données

Déterminer si WebLogic a été personnalisé

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

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

Déterminer si vous utilisez vos propres bibliothèques Shared Java EE que vous avez créées

Déterminer si les bundles OSGi sont utilisés

Déterminer si votre application contient du code propre au système d’exploitation

Déterminer si Oracle Service Bus est en cours d’utilisation

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

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

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

Valider le bon fonctionnement de la version Java prise en charge

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

Déterminer si l’outil de script WebLogic est utilisé

Déterminer si votre application utilise des API propres à WebLogic

Déterminer si votre application utilise des Entity Beans ou des CMP Beans de style EJB 2.x

Déterminer si la fonctionnalité Java EE Application Client est en cours d’utilisation

Déterminer si un plan de déploiement a été utilisé

Déterminer si des minuteurs EJB sont en cours d’utilisation

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

Contenu statique en lecture seule

Contenu statique publié dynamiquement

Contenu dynamique ou interne

Déterminer si des connecteurs JCA sont utilisés

Déterminer si votre application utilise un adaptateur de ressource

Déterminer si JAAS est en cours d’utilisation

Déterminer si le clustering WebLogic est utilisé

Effectuer des tests sur place

Migration

Provisionner Azure Container Registry et Azure Kubernetes Service

Créer une image Docker pour WildFly

Configurer un FlexVolume de coffre de clés

Configurer les sources de données

Configurer les ressources JNDI

Passer en revue la configuration de WildFly

Générer l’image Docker et l’envoyer (push) à Azure Container Registry.

Provisionner une adresse IP publique

Déployer sur Azure Kubernetes Service (AKS)

Configurer un stockage persistant

Migrer des tâches planifiées

Post-migration

Recommandations

Commentaires

Ressources supplémentaires