Migrer les applications Spring Cloud vers Azure Container Apps

Article
10/07/2024

Ce guide décrit les éléments à connaître lorsque vous souhaitez migrer une application Spring Cloud existante pour qu'elle s'exécute 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

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.

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 la documentation de Spring Cloud.

Identifier les versions Spring Cloud

Examinez les dépendances de chaque application que vous migrez, afin de déterminer la version des composants Spring Cloud qu’elle utilise.

Maven

Dans les projets Maven, la version de Spring Cloud est généralement définie dans la propriété spring-cloud.version :

  <properties>
    <spring-cloud.version>2023.0.2</spring-cloud.version>
  </properties>

Gradle

Dans les projets Gradle, la version de Spring Cloud est généralement définie dans le bloc « extra properties » :

ext {
  set('springCloudVersion', "2023.0.2")
}

Vous devez mettre à jour toutes les applications pour utiliser les versions prises en charge de Spring Cloud. Pour connaître les versions prises en charge, consultez la documentation 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 Cloud, vous trouverez généralement la configuration de ces ressources à l’un des emplacements suivants :

Dans le dossier src/main/resources, dans un fichier généralement appelé application.properties ou application.yml.
Dans le référentiel Spring Cloud Config Server que vous avez identifié à l'étape précédente.

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 Cloud, vous les trouvez généralement dans les fichiers application.properties et application.yml du répertoire de l'application, ou dans le référentiel Spring Cloud Config Server.

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 tous les fournisseurs d’identité et toutes les applications Spring Cloud qui nécessitent l’authentification et/ou l’autorisation. Pour plus d'informations sur la façon dont vous pouvez configurer les fournisseurs d'identité, consultez les ressources suivantes :

Pour la configuration d’OAuth2, consultez le guide de démarrage rapide de Spring Cloud 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.

Ressources configurées via VMware Tanzu Application Service (TAS) (anciennement Pivotal Cloud Foundry)

Pour les applications gérées avec TAS, les ressources externes, y compris les ressources décrites précédemment, sont souvent configurées par le biais de liaisons de service TAS. Pour examiner la configuration de ces ressources, utilisez l’interface CLI TAS (Cloud Foundry) afin d’afficher la variable VCAP_SERVICES pour l’application.

# Log into TAS, if needed (enter credentials when prompted)
cf login -a <API endpoint>

# Set the organization and space containing the application, if not already selected during login.
cf target org <organization name>
cf target space <space name>

# Display variables for the application
cf env <Application Name>

Examinez la variable VCAP_SERVICES pour connaître les paramètres de configuration des services externes liés à l’application. Pour plus d’informations, consultez la documentation TAS (Cloud Foundry).

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 et tous les fichiers de configuration, ainsi que toutes les variables d'environnement sur les déploiements de production, afin de détecter d'éventuelles chaînes secrètes et mots de passe. Dans une application Spring Cloud, vous pouvez généralement trouver de telles chaînes dans le fichier application.properties ou application.yml dans les services individuels ou dans le référentiel Spring Cloud Config Server.

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>

Déterminer si Spring Cloud Vault est utilisé

Si vous utilisez Spring Cloud Vault pour stocker des secrets et y accéder, identifiez le magasin de stockage des secrets (par exemple, HashiCorp Vault ou CredHub). Identifiez ensuite tous les secrets utilisés par le code d’application.

Localiser la source du serveur de configuration

Si votre application utilise un serveur de configuration Spring Cloud, identifiez l'endroit où la configuration est stockée. Vous trouverez généralement ce paramètre dans le fichier bootstrap.yml ou bootstrap.properties, ou parfois dans le fichier application.yml ou application.properties. La configuration ressemble à l'exemple suivant :

spring.cloud.config.server.git.uri: file://${user.home}/spring-cloud-config-repo

Bien que git soit le plus souvent utilisé comme datastore de sauvegarde de Spring Cloud Config Server, comme indiqué précédemment, l'un des autres backends possibles peut être utilisé. Consultez la documentation du serveur Spring Cloud Config pour obtenir des informations sur d'autres backends, tels que la base de données relationnelle (JDBC), SVN et le système de fichiers local.

Inspecter l’architecture de déploiement

Documenter la configuration matérielle requise pour chaque service

Pour chacun de vos services Spring Cloud (sauf le serveur de configuration, le registre ou la passerelle), documentez les informations suivantes :

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 applications Spring Cloud 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.

Identifier les clients qui contournent le registre de services

Identifiez toutes les applications clientes qui appellent l’un des services à migrer sans utiliser le registre de services Spring Cloud. Après la migration, ces appels ne seront plus possibles. Mettez à jour ces clients pour qu’ils utilisent Spring Cloud OpenFeign avant la migration.

Migration

Supprimez les configurations restreintes

L'environnement Azure Container Apps propose des serveurs Eureka, Spring Cloud Config Server et Admin gérés. Lorsqu'une application est liée au composant Java, Azure Container Apps injecte les propriétés associées en tant que variables d'environnement système. Selon la conception de la configuration externalisée de Spring Boot, les propriétés de l'application définies dans votre code ou packagées dans des artefacts sont écrasées par les variables d'environnement du système.

Si vous définissez l'une des propriétés suivantes via un argument de ligne de commande, une propriété système Java ou une variable d'environnement du conteneur, vous devez la supprimer pour éviter les conflits et les comportements inattendus :

SPRING_CLOUD_CONFIG_COMPONENT_URI
SPRING_CLOUD_CONFIG_URI
SPRING_CONFIG_IMPORT
eureka.client.fetch-registry
eureka.client.service-url.defaultZone
eureka.instance.prefer-ip-address
eureka.client.register-with-eureka
SPRING_BOOT_ADMIN_CLIENT_INSTANCE_PREFER-IP
SPRING_BOOT_ADMIN_CLIENT_URL

Créer un environnement géré et des applications Azure Container Apps.

Provisionnez une application Azure Container Apps dans votre abonnement Azure sur un environnement géré existant ou créez-en un nouveau pour chaque service que vous migrez. Vous n'avez pas besoin de créer des applications fonctionnant en tant que serveurs de registre et de configuration Spring Cloud. Pour plus d’informations, consultez Démarrage rapide : Déployer votre première application de conteneur avec le portail Azure.

Préparer le serveur Config de Spring Cloud

Configurez le serveur Config dans votre composant Azure Container Apps for Spring. Pour plus d'informations, voir Configurer les paramètres du composant Config Server for Spring dans Azure Container Apps.

Remarque

Si votre référentiel Spring Cloud Config actuel se trouve sur le système de fichiers local ou dans les locaux, vous devez d'abord migrer ou répliquer vos fichiers de configuration vers un référentiel basé sur le cloud, tel que GitHub, Azure Repos ou BitBucket.

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 les secrets du coffre Spring Cloud vers Azure Key Vault

Vous pouvez injecter des secrets directement dans des applications par le biais de Spring à l’aide d’Azure Key Vault Spring Boot Starter. Pour plus d’informations, consultez Guide pratique pour utiliser Spring Boot Starter pour Azure Key Vault.

Remarque

La migration peut vous obliger à renommer certains secrets. Mettez à jour votre code d’application en conséquence.

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)

Si vous avez déjà configuré des variables liées à l'APM dans le conteneur, il ne vous reste plus qu'à vous assurer que la connexion à la plateforme APM cible peut être établie. Si la configuration APM fait référence à des variables d'environnement du conteneur, vous devez définir les variables d'environnement d'exécution en conséquence sur Azure Container Apps. Les informations sensibles, telles que la chaîne de connexion, doivent être traitées de manière sécurisée. Vous pouvez soit la spécifier en tant que secret, soit référencer un secret stocké dans Azure Key Vault.

Configurer les paramètres externes et les secrets par service

Vous pouvez injecter des paramètres de configuration dans chaque conteneur sous forme de variables d'environnement. Toute modification des variables crée une nouvelle révision pour l'application existante. Les secrets sont des paires clé-valeur et restent valides à travers toutes les révisions.

Migrer et activer le fournisseur d’identité

Si l'une des applications Spring Cloud nécessite une authentification ou une autorisation, utilisez les directives suivantes pour vous assurer 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 obtenir de l’aide, 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.

Mettre à jour les applications clientes

Mettez à jour la configuration de toutes les applications clientes pour utiliser les points de terminaison Azure Container Apps publiés pour les applications migrées.

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.

Si vos applications utilisent des composants Spring Cloud Netflix hérités, envisagez de les remplacer par des alternatives actuelles, comme indiqué dans le tableau suivant :

Ancien	Actuel
Spring Cloud Eureka	Registre de service Spring Cloud
Spring Cloud Netflix Zuul	Spring Cloud Gateway
Spring Cloud Netflix Archaius	Serveur de configuration Spring Cloud
Spring Cloud Netflix Ribbon	Spring Cloud LoadBalancer (équilibreur de charge côté client)
Spring Cloud Hystrix	Spring Cloud Circuit Breaker + Resilience4J
Spring Cloud Netflix Turbine	Micrometer + Prometheus

Partager via

Migrer les applications Spring Cloud vers Azure Container Apps

Prémigration

Inspecter les composants d’application

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

Contenu statique en lecture seule

Contenu statique publié dynamiquement

Déterminer si l’un des services contient du code propre au système d’exploitation

Basculer vers une plateforme prise en charge

Identifier les versions Spring Boot

Maven

Gradle

Identifier les versions Spring Cloud

Maven

Gradle

Identifier les solutions d’agrégation de journaux

Identifier les agents de Gestion des performances des applications (APM)

Inventorier les ressources externes

Bases de données

Répartiteurs de messages JMS

Identifier les caches externes

Fournisseurs d’identité

Ressources configurées via VMware Tanzu Application Service (TAS) (anciennement Pivotal Cloud Foundry)

Toutes les autres ressources externes

Secrets et sources de configuration d’inventaire

Mots de passe d’inventaire et chaînes sécurisées

Inventorier les certificats

Déterminer si Spring Cloud Vault est utilisé

Localiser la source du serveur de configuration

Inspecter l’architecture de déploiement

Documenter la configuration matérielle requise pour chaque service

Documenter la géoréplication/distribution

Identifier les clients qui contournent le registre de services

Migration

Supprimez les configurations restreintes

Créer un environnement géré et des applications Azure Container Apps.

Préparer le serveur Config de Spring Cloud

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

Configurer un stockage persistant

Migrer les secrets du coffre Spring Cloud vers Azure Key Vault

Migrer tous les certificats vers Key Vault

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

Configurer les paramètres externes et les secrets par service

Migrer et activer le fournisseur d’identité

Mettre à jour les applications clientes

Post-migration

Commentaires

Ressources supplémentaires