Migrer des applications Spring Boot vers Azure Spring Apps
Remarque
Azure Spring Apps est le nouveau nom du service Azure Spring Cloud. Bien que le service ait un nouveau nom, vous verrez l’ancien nom à divers endroits pendant un certain temps, car nous travaillons à mettre à jour les ressources telles que les captures d’écran, les vidéos et les diagrammes.
Ce guide décrit ce que vous devez savoir quand vous souhaitez migrer une application Spring Boot existante à exécuter sur Azure Spring Apps.
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 parvenez pas à respecter ces conditions de prémigration, consultez les guides de migration suivants :
- Migrer des applications JAR exécutables vers des conteneurs sur Azure Kubernetes Service (aide planifiée)
- Migrer des applications JAR exécutables vers des machines virtuelles Azure (aide planifiée)
Inspecter les composants d’application
Identifier l’état local
Dans les environnements PaaS, il n’est pas garanti qu’une application s’exécute exactement une fois à un moment donné. Même si vous configurez une application pour qu’elle s’exécute dans une instance unique, une instance dupliquée peut être créée dans les cas suivants :
- L’application doit être déplacée vers un hôte physique en raison d’une défaillance ou d’une mise à jour du système
- L’application est en cours de mise à jour
Dans ces cas-là, l’instance d’origine restera en cours d’exécution jusqu’à la fin du démarrage de la nouvelle instance. Cela présente les implications significatives suivantes pour votre application :
- Aucun Singleton ne peut être garanti comme véritablement unique.
- Toutes les données qui n’ont pas été rendues persistantes dans le stockage externe seront probablement perdues beaucoup plus tôt qu’elles ne le seraient sur un serveur physique ou une machine virtuelle unique.
Avant de migrer vers Azure Spring Apps, vérifiez que votre code ne contient pas d’état local qui ne doit pas être perdu ou dupliqué. Si l’état local existe, modifiez le code pour stocker cet état en dehors de l’application. Les applications prêtes pour le cloud stockent généralement l’état de l’application à des emplacements tels que les suivants :
- Cache Azure pour Redis
- Azure Cosmos DB
- Une autre base de données externe, telle qu’Azure SQL, Azure Database pour MySQL ou Azure Database pour PostgreSQL.
Déterminer si le système de fichiers est utilisé et de quelle manière
Recherchez les instances où vos services écrivent et/ou lisent à partir du système de fichiers local. Identifiez où les fichiers temporaires/à courte durée de vie sont écrits et lus, et où les fichiers à longue durée de vie sont écrits et lus.
Remarque
Azure Spring Apps fournit 5 Go de stockage temporaire par instance Azure Spring Apps, monté en /tmp
. Si des fichiers temporaires sont écrits au-delà de cette limite ou à un emplacement différent, des modifications du code seront nécessaires.
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.
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.
Déterminer si l’un des services 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 pouvez avoir besoin de remplacer toute utilisation de /
ou \
dans les chemins de système de fichiers par File.Separator
ou Paths.get
.
Basculer vers une plateforme prise en charge
Azure Spring Apps propose des versions spécifiques de Java et des versions spécifiques de Spring Boot et Spring Cloud. Pour garantir sa compatibilité, migrez d’abord votre application vers l’une des versions prises en charge de Java dans son environnement actuel, puis passez aux étapes de migration restantes. Veillez à tester entièrement la configuration obtenue. Utilisez la dernière version stable de votre distribution Linux dans ces 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
Pour les versions prises en charge de Java, Spring Boot et Spring Cloud, ainsi que des instructions pour la mise à jour, consultez Préparer une application pour le déploiement dans Azure Spring Apps.
Déterminer si votre application s’appuie sur des tâches planifiées
Les travaux planifiés, tels que les tâches du planificateur de quartz ou les travaux cron Unix, ne doivent PAS être utilisés avec Azure Spring Apps. Azure Spring Apps 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.
Identifier les versions Spring Boot
Examinez les dépendances de chaque application en cours de migration pour déterminer sa version Spring Boot.
Maven
Dans les projets Maven, la version Spring Boot se trouve généralement dans l’élément <parent>
du fichier POM :
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.7.10</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>
Gradle
Dans les projets Gradle, la version Spring Boot se trouve généralement dans la section plugins
, comme la version du plug-in org.springframework.boot
:
plugins {
id 'org.springframework.boot' version '2.7.10'
id 'io.spring.dependency-management' version '1.0.15.RELEASE'
id 'java'
}
Pour toutes les applications qui utilisent Spring Boot 1. x, suivez le guide de migration vers Spring Boot 2.0 pour les mettre à jour vers une version de Spring Boot prise en charge. Pour connaître les versions prises en charge, consultez la section Des versions Spring Boot et Spring Cloud de Préparer une application pour le déploiement dans Azure Spring Apps.
Identifier les solutions d’agrégation de journaux
Identifiez les solutions d’agrégation de journaux utilisées par les applications que vous migrez. Vous devez configurer les paramètres de diagnostic dans la migration pour rendre les événements journalisés disponibles pour la consommation. Pour plus d’informations, consultez la section Vérifier la journalisation de la console et configurer les paramètres de diagnostic.
Identifier les agents de Gestion des performances des applications (APM)
Identifiez les agents de surveillance des performances des applications en cours d’utilisation avec vos applications. Azure Spring Apps prend en charge l’intégration à Application Recommandations, New Relic, Elastic APM, Dynatrace et AppDynamics. Si l’application utilise un APM pris en charge, configurez l’intégration dans la migration. Si l’application n’utilise pas un APM pris en charge, envisagez d’utiliser l’application Recommandations à la place. Pour plus d’informations, consultez la section Migration .
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 trouverez généralement la configuration de ces ressources dans le dossier src/main/directory dans un fichier généralement nommé application.properties ou application.yml.
Bases de données
Pour les bases de données SQL, identifiez la chaîne de connexion.
Pour une application Spring boot, les chaînes de connexion apparaissent généralement dans les fichiers de configuration.
Voici un exemple de 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 de fichier application.yaml :
spring:
data:
mongodb:
uri: mongodb://mongouser:[email protected]:27017
Pour plus d’informations sur les scénarios de configuration possibles, consultez la documentation Spring Data :
Répartiteurs de messages JMS
Identifiez le ou les répartiteurs utilisés en recherchant les dépendances pertinentes dans le manifeste de la build (en général 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 de fichier build.gradle :
dependencies {
...
compile("com.ibm.mq:com.ibm.mq.allclient:9.0.4.0")
...
}
Une fois que vous avez identifié le ou les répartiteurs en cours d’utilisation, recherchez les paramètres correspondants. Dans les applications Spring Boot, vous les trouverez généralement dans les fichiers application.properties et application.yml dans le répertoire de l’application.
Voici un exemple ActiveMQ tiré 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=tryandguess
Pour plus d’informations sur la configuration d’ActiveMQ, consultez la documentation sur la messagerie Spring Boot.
Voici un exemple IBM MQ tiré d’un fichier application.yaml :
ibm:
mq:
queueManager: qm1
channel: dev.ORDERS
connName: localhost(14)
user: admin
password: big$ecr3t
Pour plus d’informations sur la configuration d’IBM MQ, consultez la documentation sur les composants d’IBM MQ Spring.
Identifier les caches externes
Identifiez les caches externes en cours d’utilisation. Redis est fréquemment utilisé par le biais de Spring Data Redis. Pour plus d’informations sur la configuration, consultez la documentation de Spring Data Redis.
Déterminez si les données de session sont mises en cache par le biais de Spring Session en recherchant la configuration correspondante (en Java ou XML).
Fournisseurs d’identité
Identifiez les fournisseurs d’identité utilisés par votre application. Pour plus d’informations sur la façon dont les fournisseurs d’identité peuvent être configurés, consultez les rubriques suivantes :
- Pour la configuration d’OAuth2, consultez la référence dans Spring Security.
- Pour la configuration d’Auth0 dans Spring Security, consultez la documentation sur Auth0 dans Spring Security.
- Pour la configuration de PingFederate dans Spring Security, consultez les instructions relatives à PingFederate Auth0.
Identifier les clients qui reposent sur un port non standard
Azure Spring Apps remplace le server.port
paramètre dans l’application déployée. Si l’un des clients dépend de la disponibilité de l’application sur un port autre que 443, vous devez le modifier.
Toutes les autres ressources externes
Il n’est pas possible de décrire dans ce guide toutes les dépendances externes possibles. Après la migration, il vous incombe de vérifier que vous pouvez satisfaire à toutes les dépendances externes de votre application.
Secrets et sources de configuration d’inventaire
Mots de passe d’inventaire et chaînes sécurisées
Recherchez les secrets et mots de passe dans l’ensemble des propriétés, des fichiers de configuration et des variables d’environnement dans le ou les déploiements de production. Dans une application Spring Boot, ces chaînes se trouvent généralement dans le fichier application.properties ou application.yml.
Inventorier les certificats
Documentez tous les certificats utilisés pour les points de terminaison SSL publics ou la communication avec les bases de données back-end et 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>
Inspecter l’architecture de déploiement
Documenter la configuration matérielle requise pour chaque service
Documentez les informations suivantes pour votre application Spring Boot :
- Nombre d’instances en cours d’exécution
- Nombre de processeurs alloués à chaque instance
- Quantité de mémoire vive allouée à chaque instance
Documenter la géoréplication/distribution
Déterminez si les instances de votre application Spring Boot sont actuellement distribuées entre plusieurs régions ou centres de données. Documentez les conditions de disponibilité/contrat SLA pour les applications que vous migrez.
Migration
Créer une instance et des applications Azure Spring Apps
Provisionnez une instance Azure Spring Apps dans votre abonnement Azure, si elle n’existe pas déjà. Ensuite, créez-y une application. Pour plus d’informations, consultez Démarrage rapide : Déployer votre première application sur Azure Spring Apps.
Vérifier la journalisation de la console et configurer les paramètres de diagnostic
Configurez la journalisation afin que toute la sortie soit routée vers la console et non vers des fichiers.
Une fois qu’une application est déployée sur Azure Spring Apps, ajoutez un paramètre de diagnostic pour rendre les événements journalisés disponibles pour la consommation, par exemple via Azure Monitor Log Analytics.
Pile LogStash/ELK
Si vous utilisez la pile LogStash/ELK pour l’agrégation des journaux, configurez le paramètre de diagnostic pour envoyer en streaming la sortie de la console à un hub d’événements Azure. Ensuite, utilisez le plug-in LogStash EventHub pour ingérer les événements journalisés dans LogStash.
Splunk
Si vous utilisez Splunk pour l’agrégation des journaux, configurez le paramètre de diagnostic pour envoyer en streaming la sortie de la console au Stockage Blob Azure. Ensuite, utilisez le module complémentaire Splunk pour les services Microsoft Cloud pour ingérer les événements journalisés dans Splunk.
Configurer un stockage persistant
Si une partie de votre application lit ou écrit dans le système de fichiers local, vous devez configurer le stockage persistant pour remplacer le système de fichiers local. Pour plus d’informations, consultez Utiliser un stockage persistant intégré dans Azure Spring Apps.
Vous devez écrire les fichiers temporaires dans le répertoire /tmp
. Pour l’indépendance du système d’exploitation, vous pouvez obtenir ce répertoire à l’aide de System.getProperty("java.io.tmpdir")
. Vous pouvez également utiliser java.nio.Files::createTempFile
pour créer des fichiers temporaires.
Migrer tous les certificats vers Key Vault
Azure Spring Apps ne fournit pas d’accès au magasin de clés JRE. Vous devez donc migrer des certificats vers Azure KeyVault et modifier le code de l’application pour accéder aux certificats dans KeyVault. Pour plus d’informations, consultez Bien démarrer avec les certificats Key Vault et Bibliothèque de client de certificats Azure Key Vault pour Java.
Configurer les intégrations de gestion des performances des applications (APM)
Azure Spring Apps offre les intégrations APM suivantes. Suivez les liens pour activer l’APM dont vous avez besoin.
- Agent in-process Java Recommandations d’application
- Agent Java APM élastique
- Dynatrace Java OneAgent
- AppDynamics Java Agent
- Agent Java New Relic
Si votre application n’utilise pas un APM pris en charge, envisagez d’utiliser l’application Recommandations à la place. Azure Spring Apps offre une intégration approfondie à Application Recommandations pour la gestion des performances et la réponse en temps réel aux aberrations.
Désactiver les clients et les points de terminaison de métriques dans vos applications
Supprimez tous les clients de métriques utilisés ou tous les points de terminaison de métriques exposés dans vos applications.
Déployer l’application
Déployez chacun des microservices migrés (sans inclure les serveurs Spring Cloud Config et Registry), comme décrit dans Démarrage rapide : Déployer votre première application sur Azure Spring Apps.
Configurer les paramètres externes et les secrets par service
Vous pouvez injecter des paramètres de configuration par service dans chaque service en tant que variables d’environnement. Dans le portail Azure, effectuez les étapes suivantes :
- Accédez à l’instance Azure Spring Apps et sélectionnez Applications.
- Sélectionnez le service à configurer.
- Sélectionnez Configuration.
- Entrez les variables à configurer.
- Sélectionnez Enregistrer.
Migrer et activer le fournisseur d’identité
Si l’une des applications Spring Cloud nécessite une authentification ou une autorisation, vérifiez qu’elle est configurée pour accéder au fournisseur d’identité :
- 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 local, envisagez d’implémenter une solution d’identité hybride avec l’ID Microsoft Entra. Pour plus d’informations, consultez la documentation sur les identités hybrides.
- Si le fournisseur d’identité est une autre solution locale, telle que PingFederate, consultez la rubrique d’installation personnalisée de Microsoft Entra Connecter pour configurer la fédération avec l’ID Microsoft Entra. Vous pouvez également utiliser Spring Security pour utiliser votre fournisseur d’identité par le biais d’OAuth2/OpenID Connect ou SAML.
Exposer l’application
Par défaut, les applications déployées sur Azure Spring Apps ne sont pas visibles en externe. Vous pouvez exposer votre application en la rendant publique avec la commande suivante :
az spring app update --name <application name> --is-public true
Ignorez cette étape si vous utilisez ou envisagez d’utiliser une passerelle Spring Cloud. Pour plus d’informations, consultez la section suivante :
Post-migration
Maintenant que vous avez terminé la migration, vérifiez que votre application fonctionne comme prévu. Vous pouvez ensuite rendre votre application plus native Cloud en appliquant les recommandations suivantes.
Activez éventuellement le fonctionnement de votre application avec Spring Cloud Registry. Cela permet à votre application d’être découverte dynamiquement par d’autres applications et clients Spring déployés. Pour plus d’informations, consultez Préparer une application pour le déploiement dans Azure Spring Apps. Ensuite, modifiez les clients d’application pour qu’ils utilisent Spring Cloud LoadBalancer. Cela permet au client d’obtenir des adresses de toutes les instances en cours d’exécution de l’application et de trouver une instance qui fonctionne si une autre instance devient endommagée ou ne répond pas. Pour plus d’informations, consultez Spring Astuces : Spring Cloud Load Balancer dans le blog Spring.
Au lieu de rendre votre application publique, vous pouvez ajouter une instance Spring Cloud Gateway. Spring Cloud Gateway fournit un point de terminaison unique pour toutes les applications déployées dans votre instance Azure Spring Apps. Si Spring Cloud Gateway est déjà déployé, vérifiez qu’il est configuré pour router le trafic vers votre application récemment déployée.
Envisagez d’ajouter un serveur Spring Cloud Config pour gérer et contrôler de manière centralisée la configuration de toutes vos applications Spring Cloud. Tout d’abord, créez un dépôt Git pour héberger la configuration et configurez l’instance Azure Spring Apps pour l’utiliser. Pour plus d’informations, consultez Configurer une instance Spring Cloud Config Server pour votre service. Ensuite, migrez votre configuration en effectuant les étapes suivantes :
Dans le répertoire src/main/resources de l’application, créez un fichier bootstrap.yml avec le contenu suivant :
spring: application: name: <your-application-name>
Dans le référentiel Git de configuration, créez un <fichier your-application-name.yml>, où
your-application-name
est le même que dans l’étape précédente. Déplacez les paramètres du fichier application.yml dans src/main/resources vers le nouveau fichier que vous venez de créer. Si les paramètres figuraient précédemment dans un fichier .properties, convertissez-les d’abord au format YAML. Vous pouvez trouver des outils en ligne ou des plug-ins IntelliJ pour effectuer cette conversion.Créez un fichier application.yml dans le répertoire ci-dessus. Vous pouvez utiliser ce fichier pour définir des paramètres et des ressources qui seront partagés entre toutes les applications sur l’instance Azure Spring Apps. Ces paramètres incluent généralement des sources de données, des paramètres de journalisation, la configuration Spring Boot Actuator, entre autres.
Validez et envoyez (push) ces modifications dans le dépôt Git.
Supprimez le fichier application.properties ou application.yml de l’application.
Ajoutez un pipeline de déploiement afin de bénéficier de déploiements automatiques et cohérents. Des instructions sont disponibles pour Azure Pipelines, pour GitHub Actions et pour Jenkins.
Utilisez des déploiements intermédiaires pour tester les modifications de code en production avant qu’elles soient disponibles pour une partie ou l’ensemble de vos utilisateurs finaux. Pour plus d’informations, consultez Configurer un environnement de préproduction dans Azure Spring Apps.
Ajoutez des liaisons de service pour connecter votre application aux bases de données Azure prises en charge. Ces liaisons de service éliminent la nécessité de fournir des informations de connexion, y compris des informations d’identification, à vos applications Spring Cloud.
Envisagez d’utiliser azure Application Recommandations pour surveiller les performances et les interactions de vos applications. Pour plus d’informations, consultez Agent In-process Java d’Application Insights dans Azure Spring Apps.
Ajoutez des groupes d’actions et des règles d’alerte Azure Monitor pour détecter et résoudre rapidement les conditions aberrantes. Pour plus d’informations, consultez Tutoriel : Surveiller les ressources Spring Cloud à l’aide d’alertes et de groupes d’actions.
Envisagez de répliquer le déploiement d’Azure Spring Apps dans une autre région pour une latence plus faible et une fiabilité et une tolérance de panne plus élevées. Utilisez Azure Traffic Manager pour équilibrer la charge entre les déploiements, ou utilisez Azure Front Door pour ajouter le déplacement SSL et le pare-feu d’applications web avec la protection DDoS.
Si la géoréplication n’est pas nécessaire, ajoutez une passerelle d’application Azure pour ajouter le déplacement SSL et le pare-feu d’applications web avec la protection DDoS.