Migrer des applications Spring Cloud vers Azure Container Apps

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

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.

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 la documentation 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 spring Cloud est généralement définie dans la spring-cloud.version propriété :

  <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 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 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 à 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éférentiels JPA
• Référentiels JDBC
• Référentiels Cassandra
• Référentiels MongoDB

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 Cloud, vous pouvez généralement les trouver dans les fichiers application.properties et application.yml dans le 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 à 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 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 OAuth2, consultez le guide de démarrage rapide Spring Cloud 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.

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) pour afficher la VCAP_SERVICES variable de 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 VCAP_SERVICES variable pour 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 ces chaînes dans le fichier application.properties ou application.yml dans des services individuels ou dans le référentiel Spring Cloud Config Server.

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>

Déterminer si Spring Cloud Vault est utilisé

Si vous utilisez Spring Cloud Vault pour stocker et accéder aux secrets, identifiez le magasin de secrets sous-jacent, 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’emplacement où la configuration est stockée. Vous trouvez 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 Spring Cloud Config Server pour plus d’informations sur d’autres back-ends, 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 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 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 utiliser Spring Cloud OpenFeign avant la migration.

Migration

Supprimez les configurations restreintes

L’environnement Azure Container Apps offre un serveur Eureka Server managé, Spring Cloud Config Server et Un administrateur. Lorsqu’une application est liée au composant Java, Azure Container Apps injecte des propriétés associées en tant que variables d’environnement système. Selon la conception de configuration externalisée Spring Boot , les propriétés d’application définies dans votre code ou empaquetées dans les artefacts sont remplacées par des variables d’environnement système.

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

• 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 et des applications gérés Azure Container Apps

Provisionnez une application Azure Container Apps dans votre abonnement Azure sur un environnement managé existant ou créez-en une 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 Quickstart : Déployer votre première application conteneur à l’aide du portail Azure.

Préparer le serveur Config de Spring Cloud

Configurez le serveur de configuration dans votre Azure Container Apps pour le composant Spring. Pour plus d’informations, consultez les paramètres Configure du composant Config Server for Spring dans Azure Container Apps.

Remarque

Si votre dépôt Spring Cloud Config actuel se trouve sur le système de fichiers local ou local, 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.

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

Vous pouvez injecter des secrets directement dans des applications via Spring à l’aide du Azure KeyVault Spring Boot Starter. Pour plus d’informations, consultez How to use the Spring Boot Starter for 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é 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)

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 à partir 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 le connection string, doivent être gérées en toute sécurité. Vous pouvez le spécifier en tant que secret ou 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 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 obtenir des conseils, consultez la documentation sur l’identité hybride.
• 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.

Mettre à jour les applications clientes

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

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.

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

  Hérité	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 Load Balancer (load balancer côté client)
  Spring Cloud Hystrix	Spring Cloud Circuit Breaker + Résilience4J
  Spring Cloud Netflix Turbine	Micrometer + Prometheus