Partager via


Azure App Configuration – Bonnes pratiques

Cet article décrit les modèles courants et les bonnes pratiques à observer quand vous utilisez Azure App Configuration.

Regroupements de clés

App Configuration propose deux options pour organiser les clés :

  • Préfixes de clés
  • Étiquettes

Vous pouvez regrouper vos clés avec une de ces options ou les deux.

Les préfixes de clé vous permettent de regrouper les clés associées à l’aide d’un préfixe commun dans leurs noms. Les préfixes peuvent inclure plusieurs segments séparés par des délimiteurs tels que / ou :, formant un espace de noms hiérarchique. Cette approche est utile lors du stockage de clés de configuration pour plusieurs applications ou microservices au sein d’un magasin App Configuration unique.

Il est important de se rappeler que les clés sont directement référencées par le code de votre application pour récupérer leurs valeurs correspondantes. Par conséquent, les clés doivent rester stables pour éviter les modifications de code. Si nécessaire, vous pouvez utiliser le fournisseur App Configuration pour découper les préfixes de clé au moment de l’exécution.

Les étiquettes vous permettent de créer des variantes d’une clé, telles que différentes versions ou paramètres spécifiques à l’environnement. En affectant des étiquettes, vous pouvez conserver plusieurs valeurs pour la même clé. Votre application peut ensuite récupérer différents ensembles de valeurs de clé en spécifiant l’étiquette appropriée, ce qui permet à vos références de clé dans le code de rester cohérentes.

Compositions clé-valeur

App Configuration traite chaque clé stockée dans celle-ci en tant qu’entité indépendante. Elle ne déduit pas les relations entre les clés ou hérite des valeurs en fonction de la hiérarchie des clés. Toutefois, vous pouvez agréger efficacement plusieurs ensembles de clés à l’aide d’étiquettes combinées à un empilement configurationnel dans votre application.

Prenons un exemple où vous avez un paramètre de configuration nommé TestApp :MySetting, dont la valeur varie en fonction de l’environnement. Vous pouvez créer deux clés portant le même nom, mais attribuer des étiquettes différentes, une avec aucune étiquette (valeur par défaut) et un autre développement étiqueté. La clé sans étiquette contient la valeur par défaut, tandis que la clé étiquetée contient la valeur spécifique à l’environnement.

Dans votre code d’application, vous chargez d’abord les valeurs de clé par défaut (sans étiquette), puis chargez les valeurs de clé propres à l’environnement à l’aide de l’étiquette de développement . Lors du chargement du deuxième jeu, toutes les clés correspondantes remplacent les valeurs précédemment chargées. Cette approche vous permet d'empiler plusieurs ensembles de configuration, la dernière valeur chargée prenant la priorité. Les fournisseurs App Configuration sur les langages et les plateformes pris en charge offrent cette fonctionnalité de pile.

L’exemple suivant montre comment implémenter la composition clé-valeur dans une application .NET :

configBuilder.AddAzureAppConfiguration(options => {
    options.Connect(new Uri("<your-app-config-endpoint>"), new DefaultAzureCredential())
           // Load all keys that start with `TestApp:` and compose with two different labels
           .Select(keyFilter: "TestApp:*", labelFilter: LabelFilter.Null)
           .Select(keyFilter: "TestApp:*", labelFilter: "Development");
});

La rubrique Utilisation d’étiquettes pour permettre différentes configurations selon les environnements fournit un exemple complet.

Actualisation de la configuration

Azure App Configuration prend en charge l’actualisation de la configuration dynamique sans nécessiter de redémarrage d’une application. Les fournisseurs App Configuration peuvent surveiller les modifications de configuration à l’aide de deux approches :

Surveillance de toutes les clés sélectionnées

Dans cette approche, le fournisseur surveille toutes les clés sélectionnées. Si une modification est détectée dans l’une des valeurs de clé sélectionnées, la configuration entière est rechargée. Cette approche garantit des mises à jour immédiates sans nécessiter de modifications clés supplémentaires.

configBuilder.AddAzureAppConfiguration(options =>
{
    options.Connect(new Uri("<your-app-config-endpoint>"), new DefaultAzureCredential())
           // Load all keys that start with `TestApp:` and have no label
           .Select(keyFilter: "TestApp:*", labelFilter: LabelFilter.Null)
           .ConfigureRefresh(refreshOptions =>
           {
               // Trigger full configuration refresh when any selected key changes.
               refreshOptions.RegisterAll();
           });
});

Surveillance d’une clé sentinelle

Vous pouvez également surveiller une clé individuelle, souvent appelée clé sentinelle. Cette approche est utile lors de la mise à jour de plusieurs valeurs clés. En mettant à jour la clé Sentinel uniquement une fois toutes les autres modifications de configuration terminées, vous assurez que votre application recharge la configuration une seule fois, en conservant la cohérence.

configBuilder.AddAzureAppConfiguration(options =>
{
    options.Connect(new Uri("<your-app-config-endpoint>"), new DefaultAzureCredential())
           // Load all keys that start with `TestApp:` and have no label
           .Select(keyFilter: "TestApp:*", labelFilter: LabelFilter.Null)
           .ConfigureRefresh(refreshOptions =>
           {
               // Trigger full configuration refresh only if the `SentinelKey` changes.
               refreshOptions.Register("SentinelKey", refreshAll: true);
           });
});

Les deux approches sont disponibles via les fournisseurs d'App Configuration sur l'ensemble des langages et plateformes pris en charge.

Pour réduire le risque d’incohérences de configuration, utilisez des instantanés de configuration pour garantir l’intégrité de la configuration.

Références à des données externes

App Configuration est conçu pour stocker toutes les données de configuration que vous enregistreriez normalement dans des fichiers de configuration ou des variables d’environnement. Toutefois, certains types de données peuvent être mieux adaptés à d’autres sources. Par exemple, stockez les secrets dans Key Vault, les fichiers dans Stockage Azure, les informations d’appartenance dans des groupes Microsoft Entra ou les listes de clients dans une base de données.

Vous pouvez toujours tirer parti d’App Configuration en enregistrant une référence à des données externes dans une valeur clé. Vous pouvez utiliser le type de contenu pour différencier chaque source de données. Lorsque votre application lit une référence, elle charge les données réelles à partir de la source référencée, en supposant qu’elle dispose de l’autorisation nécessaire pour la source. Si vous modifiez l’emplacement de vos données externes, il vous suffit de mettre à jour la référence dans App Configuration au lieu de mettre à jour et de redéployer l’ensemble de votre application.

La fonctionnalité Référence Key Vault d’App Configuration est un exemple de ce cas. Elle permet aux secrets requis pour une application d’être mis à jour en fonction des besoins, tandis que les secrets sous-jacents sont conservés dans Key Vault.

Amorçage d’App Configuration

Pour accéder à un magasin Azure App Configuration, vous pouvez vous authentifier à l’aide d’une chaîne de connexion ou d’un ID Microsoft Entra. Bien que les chaînes de connexion soient facilement disponibles dans le portail Azure, elles contiennent des informations d’identification et doivent être traitées comme des secrets. Si vous choisissez cette approche, stockez la chaîne de connexion en toute sécurité dans Azure Key Vault et assurez-vous que votre application s’authentifie auprès de Key Vault pour la récupérer.

Une approche plus sécurisée et recommandée consiste à utiliser l’authentification Microsoft Entra ID. Si votre application est hébergée dans Azure( par exemple sur Azure Kubernetes Service, App Service ou Azure Functions), vous pouvez utiliser des identités managées fournies par l’ID Microsoft Entra. Les identités managées éliminent la nécessité de gérer explicitement les secrets. Avec cette méthode, votre application nécessite uniquement l’URL du point de terminaison App Configuration, qui peut être incorporée en toute sécurité dans le code de votre application ou les fichiers de configuration.

Pour plus d’informations, consultez Utiliser des identités gérées pour accéder à la configuration des applications.

Accès Azure Kubernetes Service à App Configuration

Les options suivantes sont disponibles pour les charges de travail hébergées dans Azure Kubernetes Service (AKS) pour accéder à Azure App Configuration. Ces options s’appliquent également à Kubernetes en général.

  • Ajoutez Azure App Configuration Kubernetes Provider à votre cluster AKS. Le fournisseur Kubernetes s’exécute en tant que pod dans le cluster. Il peut construire des ConfigMaps et des Secrets à partir de clés-valeurs et de références Key Vault dans Azure App Configuration. Le ConfigMap et le Secret sont consommables en tant que variables d’environnement ou fichiers montés sans nécessiter de modification dans votre code d’application. Si plusieurs applications s’exécutent dans le même cluster AKS, elles peuvent toutes accéder aux ConfigMaps et Secrets générés, ce qui élimine la nécessité de requêtes spécifiques adressées à App Configuration. Le fournisseur Kubernetes prend également en charge les mises à jour de configuration dynamique. Il s’agit de l’option recommandée si elle est possible pour vous.

  • Mettez à jour votre application pour utiliser des bibliothèques de fournisseurs Azure App Configuration. Les bibliothèques de fournisseurs sont disponibles dans de nombreux frameworks et langages, tels que ASP.NET, .NET, Java Spring, JavaScript/Node.js et Python. Cette approche vous donne un accès complet aux fonctionnalités d’App Configuration, notamment la configuration dynamique et la gestion des fonctionnalités. Vous disposez d’un contrôle précis des données à charger et du choix du magasin App Configuration source pour chaque application.

  • Intégrez au déploiement Kubernetes en utilisant Helm. Si vous ne souhaitez pas mettre à jour votre application ou ajouter un nouveau pod à votre cluster AKS, vous avez la possibilité d’apporter des données d’App Configuration à votre cluster Kubernetes à l’aide de Helm via le déploiement. Cette approche permet à votre application de continuer à accéder à la configuration à partir de variables et de Secrets Kubernetes. Vous pouvez exécuter la mise à niveau Helm chaque fois que vous souhaitez que votre application incorpore de nouvelles modifications de configuration.

Accès d’App Service ou Azure Functions à App Configuration

Utilisez le fournisseur App Configuration ou les bibliothèques du SDK pour accéder directement à App Configuration dans votre application. Cette approche vous donne un accès complet aux fonctionnalités d’App Configuration, notamment la configuration dynamique et la gestion des fonctionnalités. Votre application s’exécutant sur App Service ou Azure Functions peut obtenir l’accès à votre magasin App Configuration via l’une des méthodes suivantes :

Vous pouvez également rendre vos données App Configuration accessibles à votre application en tant que paramètres d’application ou variables d’environnement. Avec cette approche, vous pouvez éviter d’avoir à modifier votre code d’application.

Réduire le nombre de requêtes adressées à App Configuration

Un nombre excessif de requêtes envoyées à App Configuration peut entraîner des frais de limitation de requêtes ou de dépassement. Pour réduire le nombre de requêtes effectuées :

  • Augmentez l’intervalle d’actualisation, en particulier si vos valeurs de configuration ne changent pas fréquemment. Spécifiez un nouvel intervalle d’actualisation à l’aide de la méthode SetRefreshInterval.

  • Surveillez une seule clé Sentinel, plutôt que de surveiller des clés individuelles. Actualisez toute la configuration uniquement si la clé Sentinel est modifiée. Pour obtenir un exemple, consultez Utiliser la configuration dynamique dans une application ASP.NET Core.

  • Utilisez le fournisseur Kubernetes App Configuration si vous exécutez plusieurs charges de travail dans un cluster Kubernetes, chacune extrayant les données d’App Configuration individuellement. Le fournisseur Kubernetes récupère les données d’App Configuration et les met à disposition en tant que ConfigMaps et Secrets Kubernetes. De cette façon, vos charges de travail peuvent accéder aux données via ConfigMaps et Secrets sans avoir à extraire les données d’App Configuration séparément.

  • Activez la géoréplication du magasin de votre App Configuration et répartissez vos demandes sur plusieurs réplicas. Par exemple, utilisez un réplica différent de chaque région géographique pour une application déployée au niveau mondial. Chaque réplica d'App Configuration dispose de son propre quota de requêtes. Cette configuration vous donne un modèle pour la scalabilité et la résilience améliorée contre les pannes temporaires et régionales.

Importation des données de configuration dans App Configuration

App Configuration vous offre la possibilité d’importer en bloc vos paramètres de configuration à partir de vos fichiers config actuels à l’aide du Portail Azure ou de l’interface CLI. Vous pouvez également utiliser les mêmes options pour exporter des valeurs clés depuis App Configuration, par exemple entre des magasins associés. Si vous adoptez Configuration en tant que code et gérez vos configurations dans GitHub ou Azure DevOps, vous pouvez configurer l’importation continue du fichier de configuration à l’aide de GitHub Actions ou d’Azure Pipeline Import Task.

Déploiement multirégional dans App Configuration

Si votre application est déployée dans plusieurs régions, nous vous recommandons d'activer la géoréplication de votre magasin d'App Configuration. Vous pouvez laisser votre application se connecter principalement au réplica correspondant à la région où les instances de votre application sont déployées et leur permettre de basculer vers des réplicas dans d'autres régions. Cette configuration réduit la latence entre votre application et App Configuration, répartit la charge, car chaque réplica a des quotas de limitation distincts et améliore la résilience de votre application contre les pannes temporaires et régionales. Pour plus d’informations, consultez Résilience et récupération d’urgence.

Création d’applications avec une résilience élevée

Les applications s’appuient souvent sur la configuration pour démarrer, ce qui rend la haute disponibilité d’Azure App Configuration critique. Pour améliorer la résilience, les applications doivent utiliser les fonctionnalités de fiabilité d’App Configuration et envisager de prendre les mesures suivantes en fonction de vos besoins spécifiques.

  • Approvisionnez dans des régions avec prise en charge des zones de disponibilité Azure. Les zones de disponibilité permettent aux applications d’être résilientes aux pannes du centre de données. App Configuration offre une redondance de zone pour tous les clients sans frais supplémentaires. La création de votre magasin App Configuration dans des régions avec prise en charge des zones de disponibilité est recommandée. Vous pouvez consulter la liste des régions dans lesquelles App Configuration a activé la prise en charge des zones de disponibilité.
  • Activez la géoréplication et autorisez votre application à basculer ou à répartir la charge entre les réplicas. Cette configuration vous donne un modèle pour la scalabilité et une résilience améliorée contre les défaillances temporaires et les pannes régionales. Pour plus d’informations, consultez Résilience et récupération d’urgence.
  • Déployez la configuration avec des pratiques de déploiement sécurisées. Les modifications de configuration incorrectes ou accidentelles peuvent fréquemment entraîner un temps d’arrêt de l’application. Vous devez éviter d’apporter des modifications de configuration qui affectent directement la production à partir du portail Azure, par exemple. Dans les pratiques de déploiement sécurisées, vous utilisez un modèle de déploiement d’exposition progressif afin de réduire le rayon d’explosion potentiel des problèmes causés par le déploiement. Si vous adoptez les pratiques de déploiement sécurisées, vous pouvez générer et tester un instantané de configuration avant de le déployer en production. Pendant le déploiement, vous pouvez mettre à jour les instances de votre application pour récupérer progressivement le nouvel instantané. Si des problèmes sont détectés, vous pouvez annuler la modification en redéployant le dernier instantané correct connu (LKG). L’instantané est immuable, garantissant ainsi la cohérence parmi tous les déploiements. Vous pouvez utiliser des instantanés avec la configuration dynamique. Utilisez un instantané pour votre configuration fondamentale, et la configuration dynamique pour les remplacements de configuration d’urgence et les indicateurs de fonctionnalité.
  • Incluez la configuration avec votre application. Si vous souhaitez garantir que votre application a toujours accès à une copie de la configuration, ou si vous préférez éviter toute dépendance d’exécution envers App Configuration, vous pouvez extraire la configuration à partir d’App Configuration au moment de la génération ou de la mise en production et l’inclure avec votre application. Pour en savoir plus, consultez les exemples d’intégration d’App Configuration à votre pipeline CI/CD ou à votre déploiement Kubernetes.
  • Utilisez des fournisseurs App Configuration. Les applications jouent un rôle essentiel dans l’obtention d’une résilience élevée, car elles peuvent tenir compte des problèmes survenant durant leur exécution, tels que les problèmes de réseau, et répondre aux défaillances plus rapidement. Les fournisseurs App Configuration offrent une gamme de fonctionnalités de résilience intégrées, notamment la découverte automatique des réplicas, le basculement de réplica, les nouvelles tentatives de démarrage avec des délais d’expiration personnalisables, la mise en cache de configuration et des stratégies adaptatives pour une actualisation fiable de la configuration. Nous vous recommandons vivement d’utiliser des fournisseurs App Configuration pour tirer parti de ces fonctionnalités. Si ce n’est pas une option, vous devez envisager d’implémenter des fonctionnalités similaires dans votre solution personnalisée pour atteindre le niveau de résilience le plus élevé.

Applications clientes dans App Configuration

Lorsque vous utilisez App Configuration dans des applications clientes, veillez à prendre en compte deux facteurs principaux. Tout d’abord, si vous utilisez la chaîne de connexion dans une application cliente, vous risquez d’exposer au public la clé d’accès de votre magasin App Configuration. Deuxièmement, l’échelle classique d’une application cliente est susceptible de donner lieu à des demandes excessives à votre magasin App Configuration, ce qui peut entraîner des frais de dépassement ou une limitation. Pour plus d’informations sur la limitation, consultez la FAQ.

Pour résoudre ces problèmes, nous vous recommandons d’utiliser un service proxy entre vos applications clientes et votre magasin App Configuration. Le service proxy peut s’authentifier en toute sécurité auprès de votre magasin App Configuration sans problème de sécurité de type fuite d’informations d’authentification. Vous pouvez créer un service proxy à l’aide de l’une des bibliothèques de fournisseurs App Configuration. Vous pouvez donc tirer parti des fonctionnalités de mise en cache et d’actualisation intégrées pour optimiser le volume de requêtes envoyées à App Configuration. Pour plus d’informations sur l’utilisation des fournisseurs App Configuration, consultez les articles de prise en main. Le service proxy traite la configuration de vos applications clientes à partir de son cache. De votre côté, vous évitez les deux problèmes potentiels mentionnés dans cette section.

Il est important de tenir compte que, lors de la présentation de la configuration aux applications clientes, les valeurs de configuration sont visibles pour les utilisateurs finaux. Veillez à éviter une exposition involontaire des données sensibles. Par exemple, les noms d’utilisateurs et de groupes dans les paramètres de ciblage des indicateurs de fonctionnalité peuvent être considérés comme EUII (Informations d’identification de l’utilisateur final). Pour atténuer ce risque, envisagez d’utiliser une ressource distincte de magasin de configuration d'application dédiée à la configuration de l'application cliente, ou segmentez la configuration à l’aide de mécanismes de filtrage tels que les préfixes de clé, les étiquettes ou balises, et appliquez le filtrage sur le serveur proxy en conséquence.

Applications mutualisées dans App Configuration

Une application mutualisée repose sur une architecture où une instance partagée de votre application sert plusieurs clients ou locataires. Par exemple, vous pouvez disposer d’un service de messagerie qui offre à vos utilisateurs des comptes distincts et des expériences personnalisées. Votre application gère généralement des configurations différentes pour chaque locataire. Voici quelques considérations architecturales relatives à l’utilisation d’App Configuration dans une application mutualisée. Vous pouvez également consulter l’exemple de code pour la configuration d’application multi-locataire.

Configuration sous forme de code

La configuration en tant que code est une pratique qui consiste à gérer les fichiers de configuration dans votre système de contrôle de code source, par exemple un référentiel Git. Elle offre des avantages comme la traçabilité et un processus d’approbation pour les modifications de configuration. Si vous adoptez la configuration sous forme de code, App Configuration a des outils pour vous aider à gérer vos données de configuration dans des fichiers et à les déployer dans le cadre de votre processus de génération, de mise en production ou CI/CD. De cette façon, vos applications peuvent accéder aux données les plus récentes à partir de votre magasin App Configuration.

  • Pour GitHub, vous pouvez importer des fichiers de configuration à partir de votre dépôt GitHub dans votre magasin App Configuration à l’aide de GitHub Actions
  • Pour Azure DevOps, vous pouvez inclure l’importation Azure App Configuration , une tâche de pipeline Azure, dans vos pipelines de génération ou de mise en production pour la synchronisation des données.
  • Pour d’autres, vous pouvez importer des fichiers de configuration dans App Configuration à l’aide d’Azure CLI dans le cadre de votre système CI/CD. Pour plus d’informations, consultez az appconfig kv import.

Ce modèle vous permet d’inclure des étapes de validation et de test avant de valider les données dans la configuration de l’application. Si vous utilisez plusieurs magasins de configuration d’application, vous pouvez également envoyer les données de configuration de manière incrémentielle ou en une seule fois.

Étape suivante