Migrer des applications Spring Boot vers Azure Container Apps

Ce guide décrit ce que vous devez savoir quand vous souhaitez migrer une application Spring Boot existante à exécuter sur Azure Container 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 (conseils planifiés)
Migrer des applications JAR exécutables vers Azure Virtual Machines (conseils planifiés)

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 tous ces cas, l'instance d'origine reste en cours d'exécution jusqu'à ce que la nouvelle instance ait fini de démarrer. Ce schéma peut avoir les conséquences suivantes, potentiellement importantes, pour votre application :

Aucun singleton ne peut être assuré d'être véritablement unique.
Toutes les données non persistées vers un stockage extérieur seront probablement perdues plus tôt qu'elles ne le seraient sur un seul serveur physique ou une seule machine virtuelle.

Avant de migrer vers Azure Container Apps, assurez-vous 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 dans des emplacements tels que les options suivantes :

Azure Cache for Redis
Azure Cosmos DB
Une autre base de données externe, telle que Azure SQL, Azure Database for MySQL ou Azure Database for PostgreSQL.
Azure Storage, utilisé pour stocker des données non structurées ou même des objets sérialisés.

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.

Azure Container Apps offre plusieurs types de stockage. Le stockage éphémère peut lire et écrire des données temporaires et être disponible pour un conteneur ou une réplique en cours d'exécution. Azure Fichier fournit un stockage permanent et peut être partagé entre plusieurs conteneurs. Pour plus d’informations, consultez Utilisez les montages de stockage dans Azure Container Apps.

Contenu statique en lecture seule

Si votre application sert actuellement du contenu statique, vous avez besoin d'un autre emplacement pour celui-ci. Vous pouvez envisager de déplacer du contenu statique vers Azure Blob Storage et d’ajouter des Azure CDN pour les téléchargements rapides à l’échelle mondiale. Pour plus d’informations, consultez le site web Static qui héberge dans Azure Storage et Quickstart : Intégrer un compte Azure storage avec Azure CDN.

Contenu statique publié dynamiquement

Si votre application prend en charge le contenu statique, qu’il soit chargé ou généré par l’application elle-même, qui reste inchangé après sa création, vous pouvez intégrer Azure Blob Storage et Azure CDN. Vous pouvez également utiliser une fonction Azure pour gérer les chargements et déclencher des actualisations CDN si nécessaire. Nous avons fourni un exemple d'implémentation pour votre utilisation à Téléchargement et préchargement de contenu statique avec CDN 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 devrez peut-être remplacer toute utilisation de / ou \ dans les chemins du système de fichiers par File.Separator ou Paths.get si votre application s’exécute sur Windows.

Basculer vers une plateforme prise en charge

Si vous créez manuellement votre fichier Dockerfile et déployez une application conteneurisée sur Azure Container Apps, vous contrôlez complètement votre déploiement, y compris les versions JRE/JDK.

Pour le déploiement à partir d’artefacts, Azure Container Apps propose également des versions spécifiques de Java (8, 11, 17 et 21) et des versions spécifiques des composants Spring Boot et Spring Cloud. Pour garantir la compatibilité, commencez par migrer 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 Java sur Azure Container Apps vue d’ensemble.

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

Une application éphémère telle que des travaux cron Unix ou des applications courtes basées sur l’infrastructure Spring Batch doit s’exécuter en tant que travail sur Azure Container Apps. Pour plus d’informations, consultez Tâches dans Azure Container Apps. Si votre application est une application à long terme et exécute régulièrement des tâches à l’aide d’une infrastructure de planification telle que Quartz ou Spring Batch, Azure Container Apps peut héberger cette application. Cependant, l'application doit gérer la mise à l'échelle de manière appropriée pour éviter les conditions de course où les mêmes instances d'application sont exécutées plus d'une fois par période planifiée lors d'un scale-out ou d'une mise à niveau continue.

Inventoriez toutes les tâches planifiées exécutées sur les serveurs de production, à l'intérieur ou à l'extérieur du code de votre 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>3.3.3</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>

Gradle

Dans les projets Gradle, la version Spring Boot se trouve généralement dans la plugins section, en tant que version du org.springframework.boot plug-in :

plugins {
  id 'org.springframework.boot' version '3.3.3'
  id 'io.spring.dependency-management' version '1.1.6'
  id 'java'
}

Pour toutes les applications utilisant des versions Spring Boot antérieures à la version 3.x, suivez le guide de migration Spring Boot 2.0 ou le Guide de migration Spring Boot 3.0 pour les mettre à jour vers une version Spring Boot prise en charge. Pour connaître les versions prises en charge, consultez les versions Spring Boot et Spring Cloud.

Identifier les solutions d’agrégation de journaux de fichiers logs

Identifiez toutes les solutions d'agrégation de journaux utilisées par les applications que vous migrez. Vous devez configurer les paramètres de diagnostic lors de la migration pour rendre les événements journalisés disponibles à la consommation. Pour plus d’informations, consultez 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 gestion des performances des applications utilisés par vos applications. Azure Containers Apps n'offre pas de prise en charge intégrée pour l'intégration d'APM. Vous devez préparer votre image de conteneur ou intégrer l'outil APM directement dans votre code. Si vous souhaitez mesurer les performances de votre application mais que vous n'avez pas encore intégré APM, envisagez d'utiliser Azure Application Insights. 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 pouvez généralement trouver la configuration de ces ressources dans le dossier src/main/resources , dans un fichier généralement appelé application.properties ou application.yml.

Bases de données

Pour une application Spring Boot, les chaînes de connexion apparaissent généralement dans les fichiers de configuration lorsqu'elle dépend 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 courtiers commerciaux contiennent généralement des dépendances directement sur les bibliothèques de pilotes JMS des courtiers. 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 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 vous 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. Redis est fréquemment utilisé par le biais de 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 correspondante (dans 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 OAuth2, consultez la référence Spring Security.
Pour obtenir la configuration d’Auth0 Spring Security, consultez la documentation Auth0 Spring Security.
Pour la configuration de PingFederate Spring Security, consultez les instructions Auth0 PingFederate.

Identifier les clients qui reposent sur un port non standard

Azure Container Apps vous permet d’exposer le port en fonction de votre configuration de ressource Azure Container Apps. Par exemple, une application Spring Boot écoute sur le port 8080 par défaut, mais elle peut être configurée avec server.port ou avec une variable d'environnement SERVER_PORT selon vos besoins.

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

Vérifiez toutes les propriétés, les fichiers de configuration et les variables d'environnement dans le(s) déploiement(s) de production pour y déceler des chaînes secrètes et des mots de passe. Dans une application Spring Boot, vous pouvez généralement trouver ces chaînes dans le fichier 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 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 actives
Nombre de processeurs alloués à chaque instance
Quantité de mémoire vive allouée à chaque instance

Documenter la géoréplication et la répartition

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 un environnement Azure Container Apps et déployer des applications

Provisionnez une instance Azure Container Apps dans votre abonnement Azure. Son environnement d'hébergement sécurisé est créé en même temps. Pour plus d’informations, consultez Quickstart : Déployer votre première application conteneur à l’aide du portail Azure.

Vérifier la journalisation de la console et configurer les paramètres de diagnostic

Configurez votre journal pour vous assurer que toutes les sorties sont acheminées vers la console plutôt que vers des fichiers.

Une fois qu’une application est déployée sur Azure Container Apps, vous pouvez configurer les options de journalisation dans votre environnement Container Apps pour définir une ou plusieurs destinations des journaux. Ces destinations peuvent inclure Azure Monitor Log Analytics, Azure Event Hub ou même d’autres solutions de supervision tierces. Vous avez également la possibilité de désactiver la journalisation et d'afficher les journaux uniquement pendant l'exécution. Pour obtenir des instructions de configuration détaillées, consultez Log storage and monitoring options in Azure Container Apps.

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. Vous pouvez spécifier le chemin à monter dans le conteneur via les paramètres de l'application et l'aligner sur le chemin utilisé par votre application. Pour plus d’informations, consultez Utilisez les montages de stockage dans Azure Container Apps.

Migrer tous les certificats vers Key Vault

Azure Containers Apps prend en charge la communication sécurisée entre les applications. Votre application n'a pas besoin de gérer le processus d'établissement d'une communication sécurisée. Vous pouvez charger le certificat privé pour Azure Container Apps ou utiliser un certificat managé gratuit fourni par Azure Container Apps. L’utilisation de Azure Key Vault pour gérer les certificats est une approche recommandée. Pour plus d’informations, consultez Certificates dans Azure Container Apps.

Configurez les intégrations de gestion des performances des applications (APM)

Que votre application soit déployée à partir d'une image conteneur ou d'un code, Azure Container Apps n'interfère pas avec votre image ou votre code. Par conséquent, l'intégration de votre application à un outil APM dépend de vos préférences et de votre mise en œuvre.

Si votre application n'utilise pas un APM pris en charge, Azure Application Insights est une option. Pour plus d’informations, consultez Utilisation Azure Monitor Application Insights avec Spring Boot.

Déployer l’application

Déployez chacun des microservices migrés (à l'exclusion de Spring Cloud Config Server et Spring Cloud Service Registry), comme décrit dans Déployer des applications de conteneur Azure avec la commande "az containerapp up".

Configurer les paramètres externes et les secrets par service

Vous pouvez injecter des paramètres de configuration dans chaque application sous forme de variables d'environnement. Vous pouvez définir ces variables comme des entrées manuelles ou comme des références à des secrets. Pour plus d’informations sur la configuration, consultez Gérer les variables d’environnement sur Azure Container Apps.

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 Microsoft Entra ID, aucune modification ne doit être nécessaire.
Si le fournisseur d’identité est une forêt on-premises Active Directory, envisagez d’implémenter une solution d’identité hybride avec Microsoft Entra ID. 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 Custom de Microsoft Entra Connect pour configurer la fédération avec Microsoft Entra ID. Vous pouvez également utiliser Spring Security pour utiliser votre fournisseur d’identité via OAuth2/OpenID Connect ou SAML.

Exposer l’application

Par défaut, une application déployée sur Azure Container Apps est accessible via une URL d’application. Si votre application est déployée dans le contexte d'un environnement géré avec son propre réseau virtuel, vous devez déterminer le niveau d'accessibilité de l'application pour autoriser les entrées publiques ou les entrées à partir de votre réseau virtuel uniquement. Pour plus d’informations, consultez Networking dans l'environnement des Azure Container Apps.

Après la 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. Ce composant permet à votre application d'être découverte dynamiquement par d'autres applications et clients Spring déployés. Pour plus d’informations, consultez les paramètres Configure du composant Eureka Server for Spring dans Azure Container Apps. Ensuite, modifiez tous les clients d’application pour utiliser le Load Balancer Spring Client. Le client Spring Load Balancer 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 non réactive. Pour plus d’informations, consultez Spring Tips : Spring Cloud Load Balancer dans le blog Spring.
Au lieu de rendre votre application publique, envisagez d’ajouter une instance Spring Cloud Gateway . Spring Cloud Gateway fournit un point de terminaison unique pour toutes les applications déployées dans votre environnement de Azure Container Apps. Si une Spring Cloud Gateway est déjà déployée, assurez-vous qu'une règle de routage est configurée pour acheminer le trafic vers votre application nouvellement déployée.
Envisagez d'ajouter un serveur Spring Cloud Config pour gérer de manière centralisée et contrôler la configuration des versions de toutes vos applications Spring Cloud. Tout d'abord, créez un référentiel Git pour héberger la configuration et configurez l'app instance pour qu'elle l'utilise. Pour plus d’informations, consultez les paramètres Configure du composant Config Server for Spring dans Azure Container Apps. Ensuite, migrez votre configuration en effectuant les étapes suivantes :
1. 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>
```
2. Dans le référentiel Git de configuration, créez un fichier <nom-de-votre-application>.yml, qui est le même que dans l’étape précédente. Déplacez les paramètres de application.yml fichier dans src/main/resources vers le nouveau fichier que vous avez créé. Si les paramètres étaient précédemment dans un fichier .properties, convertissez-les d'abord en YAML. Vous pouvez trouver des outils en ligne ou des plug-ins IntelliJ pour effectuer cette conversion.
3. 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 partagés entre toutes les applications de l’environnement Azure Container 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.
4. Validez et envoyez (push) ces modifications dans le dépôt Git.
5. Supprimez le fichier application.properties ou application.yml de l’application.
Envisagez d'ajouter le composant géré Admin for Spring pour activer une interface d'administration pour les applications Web Spring Boot qui exposent des points de terminaison d'actionneur. Pour plus d’informations, consultez Configure du composant d’administration Spring Boot dans Azure Container Apps.
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 et pour GitHub Actions.
Envisagez d'utiliser les révisions des applications Container Apps, les étiquettes de révision et les poids du trafic d'entrée pour activer le déploiement bleu-vert, qui vous permet de tester les modifications de code en production avant qu'elles ne soient mises à la disposition d'une partie ou de la totalité de vos utilisateurs finaux. Pour plus d’informations, consultez Déploiement Blue-Green dans Azure Container Apps.
Envisagez d’ajouter 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’activer la pile de développement Java pour collecter les métriques principales JVM pour vos applications. Pour plus d’informations, consultez les métriques Java pour les applications Java dans Azure Container Apps.
Envisagez d’ajouter Azure Monitor règles d’alerte et des groupes d’actions pour détecter et résoudre rapidement les conditions aberrantes. Pour plus d’informations, consultez Configurer des alertes dans Azure Container Apps.
Envisagez de répliquer votre application dans les zones de la région en activant la redondance de zone d'Azure Container Apps. Le trafic est équilibré en termes de charge et automatiquement acheminé vers les répliques en cas de panne d'une zone. Pour plus d’informations sur les paramètres redondants, consultez Reliability in Azure Container Apps.
Envisagez de protéger Azure Container Apps contre les attaques et vulnérabilités courantes à l’aide de Web Application Firewall sur Application Gateway. Pour plus d’informations, consultez Protéger Azure Container Apps avec Web Application Firewall sur Application Gateway.

Commentaires

Est-ce que cette page vous a été utile?

Last updated on 2026-03-11