Migrer des applications Spring Boot vers Azure Container Apps

Article
10/07/2024

Ce guide décrit ce que vous devez savoir lorsque vous souhaitez migrer une application Spring Boot existante pour l'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 (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 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 garanti comme 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 :

Cache Azure pour 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 propose 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 File fournit un stockage permanent et peut être partagé entre plusieurs conteneurs. Pour plus d'informations, voir Utiliser 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 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 prend en charge du 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 Azure Function pour gérer les chargements et déclencher des rafraîchissements du CDN si nécessaire. 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 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.

Basculer vers une plateforme prise en charge

Si vous créez votre fichier Docker manuellement et déployez l'application conteneurisée vers Azure Container Apps, vous prenez le contrôle total de votre déploiement, y compris des 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 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 connaître les versions prises en charge de Java, Spring Boot et Spring Cloud, ainsi que les applications de mise à jour, consultez la présentation de Java sur Azure Container Apps.

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

Les applications éphémères telles que les tâches cron Unix ou les applications à courte durée de vie basées sur le framework Spring Batch doivent s'exécuter en tant que tâche sur Azure Container Apps. Pour plus d'informations, consultez la rubrique Emplois dans les Container Apps Azure. Si votre application est de longue durée et exécute régulièrement des tâches à l'aide d'un framework de planification tel 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 section plugins, comme la version du plug-in org.springframework.boot :

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 de Spring Boot antérieures à 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 de Spring Boot prise en charge. Pour connaître les versions prises en charge, consultez les versions de Spring Boot et de Spring Cloud.

Identifier les solutions d’agrégation de journaux

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 la section Assurer 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 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é d'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 trouverez généralement 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 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: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 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 courtiers commerciaux contiennent généralement des dépendances directement sur les bibliothèques de pilotes JMS des courtiers. Voici un exemple de 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 les trouverez généralement 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 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=<password>

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: <password>

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 Container Apps vous permet d'exposer le port en fonction de la configuration de vos ressources Azure Container Apps. Par exemple, une application Spring Boot écoute le port 8080 par défaut, mais il peut être défini avec server.port ou la 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

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 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 Démarrage rapide : Déployer votre première application de conteneur avec le 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.

Après le déploiement d'une application dans 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 surveillance tierces. Vous avez également la possibilité de désactiver les données des journaux et d'afficher les journaux uniquement au moment de l'exécution. Pour obtenir des instructions de configuration détaillées, consultez les options de stockage et de surveillance des journaux dans 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, voir Utiliser 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é dans Azure Container Apps ou utiliser un certificat géré gratuit fourni par Azure Container Apps. L'utilisation d'Azure Key Vault pour gérer les certificats est une approche recommandée. Pour plus d'informations, consultez la rubrique Certificats dans les Container Apps Azure.

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

Que votre application soit déployée à partir d'une image de conteneur ou de 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 d’Azure Monitor Application Insights avec Spring Boot.

Déployer l’application

Déployez chacun des microservices migrés (à l'exception de Spring Cloud Config Server et Spring Cloud Service Registry), comme décrit dans Déployer des Container Apps 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, voir 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 devrait être nécessaire.
Si le fournisseur d'identité est une forêt Active Directory locale, envisagez de mettre en œuvre 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 Installation personnalisée 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é par le biais d’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 Réseaux dans un environnement Azure Container Apps.

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. Ce composant permet à votre application d'être découverte dynamiquement par d'autres applications et clients Spring déployés. Pour plus d'informations, voir Configurer les paramètres du composant Eureka Server for Spring dans Azure Container Apps. Modifiez ensuite la configuration de toutes les applications clientes pour qu'elles utilisent le Spring Client Load Balancer. Le Spring Client Load Balancer permet au client d'obtenir les adresses de toutes les instances en cours d'exécution de l'application et de trouver une instance qui fonctionne si une autre instance est corrompue ou ne répond plus. Pour plus d'informations, consultez Spring Tips : Spring Cloud Load Balancer dans le blog de 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 environnement 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, voir Configurer les paramètres 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 <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 avez créé. 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.
3. Créez un fichier application.yml dans le répertoire ci-dessus. Vous pouvez utiliser ce fichier pour définir les paramètres et les ressources qui sont 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 la section Configurer le composant Spring Boot Admin 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 les pipelines Azure et pour les actions GitHub.
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 la rubrique Déploiement bleu-vert dans Azure Container 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'activer la pile de développement Java pour collecter les mesures du cœur de la JVM pour vos applications. Pour plus d'informations, consultez les mesures pour les applications Java dans Azure Container 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 la section Configurer des alertes dans Azure Container Apps.
Envisagez de répliquer votre application dans les zones de la région en activant la redondance des zones 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 la rubrique Fiabilité dans Azure Container Apps.
Envisagez de protéger Azure Container Apps contre les exploits et vulnérabilités courants en utilisant le pare-feu Web Application Firewall sur Application Gateway. Pour plus d'informations, voir Protéger les applications Container Apps Azure avec le pare-feu Web Application Firewall sur Application Gateway.

Partager via