Partager via

Migrer des applications Spring Boot vers Azure App Service

Ce guide décrit ce que vous devez savoir quand vous souhaitez migrer une application Spring Boot existante vers 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.

Basculer vers une plateforme prise en charge

App Service propose des versions spécifiques de Java SE. Pour garantir la compatibilité, migrez votre application vers l’une des versions prises en charge de son environnement actuel avant de poursuivre l’une des étapes restantes. Veillez à tester entièrement la configuration résultante. Utilisez la dernière version stable de votre distribution Linux dans de tels tests.

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

Sur Azure App Service, les fichiers binaires pour Java 8 sont fournis à partir d’Eclipse Temurin. Pour Java 11, 17 et toutes les futures versions LTS de Java, App Service fournit la build Microsoft d’OpenJDK. Ces fichiers binaires sont disponibles gratuitement sur les sites suivants :

Inventorier les ressources externes

Identifiez les ressources externes, telles que les sources de données, les répartiteurs de messages JMS et les URL d’autres services. Dans les applications Spring Boot, vous pouvez généralement trouver la configuration de ces ressources dans le dossier src/main/directory , dans un fichier généralement appelé application.properties ou application.yml. En outre, vérifiez les variables d’environnement du déploiement de production pour connaître les paramètres de configuration pertinents.

Bases de données

Pour une application Spring Boot, les chaînes de connexion apparaissent généralement dans les fichiers de configuration lorsqu’elles dépendent d’une base de données externe. Voici un exemple à partir d’un fichier application.properties :

spring.datasource.url=jdbc:mysql://localhost:3306/mysql_db
spring.datasource.username=dbuser
spring.datasource.driver-class-name=com.mysql.jdbc.Driver

Voici un exemple à partir d’un fichier application.yaml :

spring:
  data:
    mongodb:
      uri: mongodb://mongouser:deepsecret@mongoserver.contoso.com:27017

Pour plus d’informations sur les scénarios de configuration possibles, consultez la documentation Spring Data :

Répartiteurs de messages JMS

Identifiez le répartiteur ou les répartiteurs en cours d’utilisation en recherchant les dépendances pertinentes dans le manifeste de build (généralement, un fichier pom.xml ou build.gradle ).

Par exemple, une application Spring Boot utilisant ActiveMQ contient généralement cette dépendance dans son fichier pom.xml :

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-activemq</artifactId>
</dependency>

Les applications Spring Boot utilisant des répartiteurs commerciaux contiennent généralement des dépendances directement sur les bibliothèques de pilotes JMS des répartiteurs. Voici un exemple à partir d’un fichier build.gradle :

    dependencies {
      ...
      compile("com.ibm.mq:com.ibm.mq.allclient:9.4.0.5")
      ...
    }

Une fois que vous avez identifié le répartiteur ou les répartiteurs en cours d’utilisation, recherchez les paramètres correspondants. Dans les applications Spring Boot, vous pouvez généralement les trouver dans les fichiers application.properties et application.yml dans le répertoire de l’application.

Remarque

Microsoft recommande d’utiliser le flux d’authentification le plus sécurisé disponible. Le flux d’authentification décrit dans cette procédure, par exemple pour les bases de données, les caches, la messagerie ou les services IA, nécessite un niveau de confiance très élevé dans l’application et comporte des risques non présents dans d’autres flux. Utilisez ce flux uniquement lorsque des options plus sécurisées, telles que les identités managées pour les connexions sans mot de passe ou sans clé, ne sont pas viables. Pour les opérations d’ordinateur local, préférez les identités utilisateur pour les connexions sans mot de passe ou sans clé.

Voici un exemple ActiveMQ à partir d’un fichier application.properties :

spring.activemq.brokerurl=broker:(tcp://localhost:61616,network:static:tcp://remotehost:61616)?persistent=false&useJmx=true
spring.activemq.user=admin
spring.activemq.password=<password>

Pour plus d’informations sur la configuration d’ActiveMQ, consultez la documentation sur la messagerie Spring Boot.

Voici un exemple IBM MQ à partir d’un fichier application.yaml :

ibm:
  mq:
    queueManager: qm1
    channel: dev.ORDERS
    connName: localhost(14)
    user: admin
    password: <password>

Pour plus d’informations sur la configuration IBM MQ, consultez la documentation sur les composants IBM MQ Spring.

Identifier les caches externes

Identifiez les caches externes en cours d’utilisation. Fréquemment, Redis est utilisé via Spring Data Redis. Pour plus d’informations sur la configuration, consultez la documentation Spring Data Redis .

Déterminez si les données de session sont mises en cache via Spring Session en recherchant la configuration respective (en Java ou XML).

Fournisseurs d’identité

Identifiez les fournisseurs d’identité utilisés par votre application. Pour plus d’informations sur la configuration des fournisseurs d’identité, consultez les informations suivantes :

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 chaque dépendance externe de votre application peut être satisfaite après une migration App Service.

Secrets d’inventaire

Mots de passe et chaînes sécurisées

Vérifiez toutes les propriétés et tous les fichiers de configuration et toutes les variables d’environnement sur le ou les déploiements de production pour les chaînes secrètes et les mots de passe. Dans une application Spring Boot, ces chaînes sont probablement trouvées dans application.properties ou application.yml.

Certificats d’inventaire

Documentez tous les certificats utilisés pour les points de terminaison SSL publics ou la communication avec les bases de données principales et d’autres systèmes. 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>

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. Vous pouvez identifier une partie ou l’ensemble des scénarios suivants.

Contenu statique en lecture seule

Si votre application sert actuellement du contenu statique, vous avez besoin d’un autre emplacement pour celui-ci. Vous devez envisager de déplacer du contenu statique vers stockage Blob Azure et d’ajouter Azure Front Door pour des téléchargements rapides globalement. Pour plus d’informations, consultez Hébergement de sites web statiques dans Stockage Azure et Intégrer un compte Stockage Azure à Azure Front Door.

Cas spéciaux

Certains scénarios de production peuvent nécessiter des modifications supplémentaires ou imposer des limitations supplémentaires. Bien que ces scénarios soient peu fréquents, il est important de s’assurer qu’ils sont inapplicables à votre application ou correctement résolus.

Déterminer si l’application s’appuie sur des travaux planifiés

Les travaux planifiés, tels que les tâches du planificateur de quartz ou les travaux cron, ne peuvent pas être utilisés avec App Service. 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.

Stockez tous les travaux planifiés, à l’intérieur ou en dehors du processus d’application.

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.

Identifier tous les processus/démons externes s’exécutant sur le ou les serveurs de production

Les processus exécutés en dehors du serveur d’applications, tels que les démons de surveillance, devront être migrés ailleurs ou éliminés.

Identifier la gestion des requêtes non HTTP ou de plusieurs ports

App Service ne prend en charge qu’un seul point de terminaison HTTP sur un seul port. Si votre application écoute plusieurs ports ou accepte des requêtes à l’aide de protocoles autres que HTTP, n’utilisez pas Azure App Service.

Migration

Paramétrer la configuration

Vérifiez que toutes les coordonnées de ressources externes (telles que les chaînes de connexion de base de données) et d’autres paramètres personnalisables peuvent être lues à partir de variables d’environnement. Si vous migrez une application Spring Boot, tous les paramètres de configuration doivent déjà être externalisables. Pour plus d’informations, consultez La configuration externalisée dans la documentation Spring Boot.

Voici un exemple qui référence une SERVICEBUS_CONNECTION_STRING variable d’environnement à partir d’un fichier application.properties :

spring.jms.servicebus.connection-string=${SERVICEBUS_CONNECTION_STRING}
spring.jms.servicebus.topic-client-id=contoso1
spring.jms.servicebus.idle-timeout=10000

Provisionner un plan App Service

Dans la liste des plans de service disponibles, sélectionnez le plan dont les spécifications répondent ou dépassent celles du matériel de production actuel.

Remarque

Si vous envisagez d’exécuter des déploiements de préproduction/contrôle de validité ou d’utiliser des emplacements de déploiement, le plan App Service doit inclure cette capacité supplémentaire. Nous vous recommandons d’utiliser des plans Premium ou plus élevés pour les applications Java.

Créez le plan App Service.

Créer et déployer une ou plusieurs applications web

Vous devez créer une application web sur votre plan App Service (en choisissant « Java SE » comme pile d’exécution) pour chaque fichier JAR exécutable que vous envisagez d’exécuter.

Applications Maven

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 en savoir plus, consultez Démarrage rapide : créer une application Java sur Azure App Service.

Applications non-Maven

Si vous ne pouvez pas utiliser le plug-in Maven, vous devez provisionner l’application web par le biais d’autres mécanismes, comme :

Une fois l’application web créée, utilisez l’un des mécanismes de déploiement disponibles pour déployer votre application. Si possible, votre application doit être chargée sur /home/site/wwwroot/app.jar. Si vous ne souhaitez pas renommer votre fichier JAR en app.jar, vous pouvez charger un script shell avec la commande pour exécuter votre fichier JAR. Collez ensuite le chemin complet de ce script dans la zone de texte Fichier de démarrage dans la section Configuration du portail. Le script de démarrage ne s’exécute pas dans le répertoire dans lequel il est placé. Par conséquent, utilisez toujours des chemins d’accès absolus pour référencer les fichiers dans votre script de démarrage (par exemple : java -jar /home/myapp/myapp.jar).

Migrer des options de runtime JVM

Si votre application nécessite des options d’exécution spécifiques, utilisez le mécanisme le plus approprié pour les spécifier.

Configurer un domaine personnalisé et SSL

Si votre application web est visible sur un domaine personnalisé, elle devra être mappée à ce domaine. Pour plus d’informations, consultez Tutoriel : Mapper un nom DNS personnalisé existant à Azure App Service.

Ensuite, vous devez lier le certificat SSL pour ce domaine à votre application web App Service. Pour plus d’informations, consultez Sécuriser un nom DNS personnalisé avec une liaison SSL dans Azure App Service.

Importer des certificats d'arrière-plan

Tous les certificats permettant de communiquer avec les systèmes principaux, tels que les bases de données, doivent être mis à la disposition d’App Service. Pour plus d’informations, consultez Ajouter un certificat SSL dans App Service.

Migrer des coordonnées de ressources externes et d’autres paramètres

Procédez comme suit pour migrer des chaînes de connexion et d’autres paramètres.

Remarque

Pour tous les paramètres d’application Spring Boot paramétrés avec des variables dans la section Paramétrer la configuration , ces variables d’environnement doivent être définies dans la configuration de l’application. Tous les paramètres d’application Spring Boot qui ne sont pas explicitement paramétrés avec des variables d’environnement peuvent toujours être remplacés par le biais de la configuration de l’application. Par exemple:

spring.jms.servicebus.connection-string=${CUSTOMCONNSTR_SERVICE_BUS}
spring.jms.servicebus.topic-client-id=contoso1
spring.jms.servicebus.idle-timeout=1800000

Configuration de l’application App Service

Migrer des tâches planifiées

Pour exécuter des travaux planifiés sur Azure, envisagez d’utiliser un déclencheur minuteur pour Azure Functions. Vous n’avez pas besoin de migrer le code de la tâche lui-même dans une fonction. La fonction peut simplement appeler une URL dans votre application pour déclencher la tâche. Si ces exécutions de travaux doivent être appelées dynamiquement et/ou suivies de manière centralisée, envisagez d’utiliser Spring Batch.

Vous pouvez également créer une application de logique avec un déclencheur de récurrence pour appeler l’URL sans écrire de code en dehors de votre application. Pour plus d’informations, consultez Vue d’ensemble : Qu’est-ce qu’Azure Logic Apps ? et Créer, planifier et exécuter des tâches et des workflows récurrents avec le déclencheur Périodicité dans Azure Logic Apps.

Remarque

Pour empêcher toute utilisation malveillante, vous devrez probablement veiller à ce que le point de terminaison d’appel de tâche demande des informations d’identification. Ainsi, la fonction du déclencheur a besoin de fournir les informations d’identification.

Migrer et activer le fournisseur d’identité

Si votre application nécessite une authentification ou une autorisation, vérifiez qu’elle est configurée pour accéder au fournisseur d’identité à l’aide des instructions suivantes :

  • Si le fournisseur d’identité est l’ID Microsoft Entra, aucune modification ne doit être nécessaire.
  • Si le fournisseur d’identité est une forêt Active Directory locale, envisagez d’implémenter une solution d’identité hybride avec l’ID Microsoft Entra. Pour plus d’informations, consultez la documentation sur l’identité hybride.
  • Si le fournisseur d’identité est une autre solution locale, telle que PingFederate, consultez la rubrique Installation personnalisée de Microsoft Entra Connect pour configurer la fédération avec l’ID Microsoft Entra. Vous pouvez également utiliser Spring Security pour utiliser votre fournisseur d’identité via OAuth2/OpenID Connect ou SAML.

Redémarrage et test de détection de fumée

Enfin, vous avez besoin de redémarrer votre application web pour appliquer tous les changements de configuration. Une fois le redémarrage terminé, vérifiez que votre application s’exécute correctement.

Après la migration

Maintenant que votre application a migré vers Azure App Service, vous devez vérifier qu’elle fonctionne comme prévu. Une fois que vous avez fait cela, nous avons des recommandations pour vous qui peuvent rendre votre application plus native dans le cloud.

Recommandations

  • Last updated on