Partager via

Azure App Configuration – Bonnes pratiques

  • Article

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és constituent la partie initiale des clés. Vous pouvez regrouper logiquement un ensemble de clés en ajoutant le même préfixe à leur nom. Les préfixes peuvent être constitués de plusieurs composants reliés par un délimiteur, par exemple /, à la manière d’un chemin d’URL, pour former un espace de noms. De telles hiérarchies sont utiles quand vous stockez des clés pour un grand nombre d’applications et microservices dans un même magasin App Configuration.

Une chose importante à garder à l’esprit est que les clés sont ce à quoi votre code d’application fait référence pour récupérer les valeurs des paramètres correspondants. Les clés ne doivent pas changer, sans quoi vous devez modifier votre code chaque fois que cela se produit.

Les étiquettes représentent un attribut de clé. Elles servent à créer des variantes d’une clé. Par exemple, vous pouvez attribuer des étiquettes à plusieurs versions d’une clé. Une version peut être une itération, un environnement ou d’autres informations contextuelles. Votre application peut demander un ensemble de clés-valeurs totalement différent en spécifiant une autre étiquette. De ce fait, toutes les références de clés restent inchangées dans votre code.

Compositions clé-valeur

App Configuration considère toutes les clés qui y sont stockées comme des entités indépendantes. App Configuration ne tente pas de déduire une quelconque relation entre les clés ou d’hériter des clés-valeurs en fonction de leur hiérarchie. Vous avez la possibilité d’agréger plusieurs ensembles de clés, mais il convient dans ce cas d’utiliser des étiquettes avec un empilement de configuration adéquat dans votre code d’application.

Intéressons-nous à un exemple. Supposez que vous disposez d’un paramètre nommé Asset1, dont la valeur peut varier en fonction de l’environnement de développement. Vous créez une clé nommée « Asset1 » avec une étiquette vide et une étiquette nommée « Development ». Dans la première étiquette, vous placez la valeur par défaut de Asset1, et vous placez une valeur spécifique pour « Development » dans l’autre.

Dans votre code, vous commencez par récupérer les clés-valeurs sans étiquettes, puis vous récupérez une deuxième fois le même ensemble de clés-valeurs avec l’étiquette « Development ». Quand vous récupérez les valeurs à la deuxième fois, les valeurs précédentes des clés sont remplacées. Le système de configuration .NET vous permet d’« empiler » plusieurs ensembles de données de configuration les uns sur les autres. Si une clé se trouve dans plusieurs ensembles, le dernier ensemble la contenant est utilisé. Avec un framework de programmation moderne comme .NET, vous bénéficiez gratuitement de cette fonctionnalité d’empilement si vous utilisez un fournisseur de configuration natif pour accéder à App Configuration. L’extrait de code suivant montre comment vous pouvez implémenter l’empilement dans une application .NET :

// Augment the ConfigurationBuilder with Azure App Configuration
// Pull the connection string from an environment variable
configBuilder.AddAzureAppConfiguration(options => {
    options.Connect(configuration["connection_string"])
           .Select(KeyFilter.Any, LabelFilter.Null)
           .Select(KeyFilter.Any, "Development");
});

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

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 App Configuration, vous pouvez utiliser sa chaîne de connexion, qui est disponible sur le portail Azure. Étant donné que les chaînes de connexion contiennent des informations d’identification, elles sont considérées comme des secrets. Ces secrets doivent être stockés dans Azure Key Vault, et votre code doit s’authentifier auprès de Key Vault pour les récupérer.

Une meilleure option consiste à utiliser la fonctionnalité d’identités managées dans Microsoft Entra ID. Avec les identités managées, vous avez seulement besoin de l’URL de point de terminaison App Configuration pour amorcer l’accès à votre magasin App Configuration. Vous pouvez incorporer l’URL dans votre code d’application (par exemple, dans le fichier appsettings.json). Pour plus de détails, consultez Utiliser des identités managées pour accéder à App Configuration.

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’intégrer des données d’App Configuration dans votre cluster Kubernetes à l’aide de Helm par le biais d’un 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, surtout si vos valeurs de configuration ne changent pas fréquemment. Spécifiez un nouvel intervalle d’actualisation à l’aide de la méthode SetCacheExpiration.

  • 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 avez adopté Configuration sous forme de code et que vous 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 utiliser la tâche Push d’Azure Pipeline.

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, reportez-vous à 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 tirer parti des fonctionnalités de fiabilité d’App Configuration. Il peut être souhaitable 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, reportez-vous à 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 d’une des bibliothèques du fournisseur App Configuration. Ainsi, vous tirerez parti des fonctionnalités intégrées de mise en cache et d’actualisation pour optimiser le volume de demandes envoyées à App Configuration. Pour plus d’informations sur les fournisseurs App Configuration, consultez les articles des guides de démarrage rapide et des tutoriels. 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.

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.

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 ou vos magasins de configuration d’application.

  • 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 Azure App Configuration Push, une tâche de pipeline Azure, dans vos pipelines de génération ou de mise en production pour la synchronisation des données.
  • Vous pouvez également importer des fichiers de configuration dans la configuration de l’application à 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.

Étapes suivantes