Azure App Configuration – Questions fréquentes (FAQ)

App Configuration permet aux développeurs de gérer les paramètres d’application et de contrôler la disponibilité des fonctionnalités. Il vise à simplifier de nombreuses tâches impliquant l’utilisation de données de configuration complexes.

App Configuration prend en charge :

• Les espace de noms hiérarchiques
• L’étiquetage
• Le requêtes étendues
• La récupération par lots
• Les opérations de gestion spécialisées
• Une interface utilisateur de gestion des fonctionnalités

App Configuration et Key Fault sont complémentaires. D’ailleurs, il est conseillé d’utiliser les deux côte à côte dans la plupart des déploiements d’applications.

Même si App Configuration offre une sécurité renforcée, Key Vault reste le meilleur emplacement de stockage pour les secrets d’application. Key Vault propose un chiffrement au niveau du matériel, des stratégies d’accès précises, ainsi que des opérations de gestion, comme la rotation des certificats.

Vous pouvez créer des paires clé-valeur App Configuration qui font référence à des secrets stockés dans Key Vault. Pour plus d’informations, consultez Utiliser des références Key Vault dans une application ASP.NET Core.

Oui. App Configuration chiffre toujours toutes les données en transit et au repos. Toutes les communications réseau sont sur TLS 1.2 ou TLS 1.3. App Configuration prend en charge le chiffrement au repos avec des clés gérées par Microsoft ou par le client.

Azure App Service vous permet de définir des paramètres d’application pour chaque instance App Service. Ces paramètres sont transmis en tant que variables d’environnement au code de l’application. Vous pouvez associer un paramètre à un emplacement de déploiement spécifique, si vous le souhaitez. Pour plus d’informations, consultez Configuration des paramètres de l’application.

En revanche, Azure App Configuration vous permet de définir des paramètres qui peuvent être partagés entre plusieurs applications. Cela comprend les applications qui s’exécutent dans App Service, de même que d'autres plateformes. Votre code d'application accède à ces paramètres via les fournisseurs de configuration pour .NET et Java, par le biais du kit de développement logiciel (SDK) Azure, ou directement via les API REST.

Vous pouvez ajouter des références à vos données App Configuration dans les paramètres d’application de votre instance App Service. Vous pouvez également importer et exporter des paramètres entre App Service et App Configuration. Cela vous permet de configurer rapidement un nouveau magasin App Configuration en fonction des paramètres App Service existants. Vous pouvez aussi partager la configuration avec une application existante qui s’appuie sur les paramètres App Service.

Il existe une limite de 10 Ko pour une seule paire clé-valeur ainsi que pour les attributs tels que l’étiquette, le type de contenu, les étiquettes de marquage et d’autres métadonnées. Il n’existe aucune limite au nombre de clés et d’étiquettes tant que leur taille totale est inférieure à la limite de stockage.

Cette limite clé-valeur doit être suffisante pour un seul paramètre dans la plupart des applications. Si vous trouvez que le paramètre est supérieur à cette limite, vous pouvez stocker vos données ailleurs et ajouter une référence à ces données dans App Configuration.

Pour obtenir la liste complète des limites, consultez Limites du service et de l’abonnement Azure.

Vous contrôlez qui peut accéder à App Configuration au niveau de chaque magasin. Utilisez un magasin distinct pour chaque environnement qui nécessite des autorisations différentes. Il s’agit de l’approche qui offre la meilleure isolation sur le plan de la sécurité.

Si vous n’avez pas besoin d’un isolement de sécurité entre les environnements, vous pouvez utiliser des étiquettes pour différencier les valeurs de configuration. La rubrique Utilisation d’étiquettes pour permettre différentes configurations selon les environnements fournit un exemple complet.

Prenez connaissance des bonnes pratiques.

Il existe trois niveaux tarifaires : Gratuit, Standard et Premium. Si vous souhaitez découvrir des informations détaillées sur la tarification, consultez la page Tarification d’App Configuration.

Tous les niveaux App Configuration offrent des fonctionnalités de base, notamment des paramètres de configuration, indicateurs de fonctionnalité, références Key Vault, captures instantanées de configuration, opérations de gestion de base, métriques et journaux d’activité.

Voici quelques considérations relatives au choix d'un niveau.

• Objectif : le niveau Gratuit est idéal pour évaluer le service dans des environnements hors production, ce qui vous permet d’explorer ses fonctionnalités sans frais. Le niveau Standard est adapté à des cas d’utilisation à volume moyen en production, ce qui fournit un équilibre entre les performances et la rentabilité. Pour les besoins en production à volume élevé ou au niveau de l’entreprise, le niveau Premium offre le plus haut niveau de performance et de scalabilité, ce qui permet à vos applications de bien fonctionner, même avec une charge importante.

• Ressources par abonnement : Une ressource se compose d’un magasin de configuration unique. Chaque abonnement est limité à un magasin de configuration par région au niveau Gratuit. Aux niveaux Standard et Premium, les abonnements ne sont pas limités en termes de magasins de configuration.

• Stockage par ressource : au niveau Gratuit, chaque magasin de configuration est limité à 10 Mo de stockage standard et à 10 Mo de stockage de captures instantanées. Au niveau Standard, chaque magasin de configuration peut utiliser jusqu’à 1 Go de stockage standard et 1 Go supplémentaire de stockage de captures instantanées. Au niveau Premium, chaque magasin de configuration peut utiliser jusqu’à 4 Go de stockage standard et 4 Go supplémentaire de stockage d’instantanés.

• Historique des révisions : App Configuration stocke l'historique des différentes modifications apportées aux clés. Au niveau Gratuit, cet historique est stocké pendant sept jours. Aux niveaux Standard et Premium, cet historique est stocké pendant 30 jours.

• Quota de requêtes : Au niveau Gratuit, les magasins sont limités à 1 000 requêtes par jour. Lorsqu’un magasin atteint 1 000 requêtes, il renvoie le code d’état HTTP 429 pour toutes les requêtes jusqu’à minuit UTC.

  Au niveau Standard, les magasins sont limités à 30 000 demandes par heure. Une fois le quota horaire épuisé, les demandes supplémentaires peuvent renvoyer le code d’état HTTP 429 indiquant un nombre trop important de requêtes, jusqu’à la fin de l’heure. Au fur et à mesure de l’envoi de demandes au-delà du quota, un pourcentage plus élevé de celles-ci peut retourner le code d’état 429.

  Les magasins de niveau Premium n’ont aucune limite de quota sur les requêtes, ce qui garantit que l’accès au magasin n’est jamais bloqué.

• Débit : les magasins App Configuration de tous les niveaux ont une allocation de débit. Les requêtes dépassant cette limite reçoivent une réponse de type code d’état HTTP 429. Les magasins du niveau Gratuit n’ont aucun débit garanti.

  Les magasins du niveau Standard autorisent un taux d’exécution† allant jusqu’à 300 RPS (requêtes par seconde) pour les requêtes de lecture, et jusqu’à 60 RPS pour les requêtes d’écriture.

  Les magasins du niveau Premium autorisent un taux† d’exécution allant jusqu’à 450 RPS pour les requêtes de lecture, et jusqu’à 100 RPS pour les requêtes d’écriture.

  †Le taux d’exécution est généralement mesuré en tant que nombre moyen de requêtes traitées par un magasin App Configuration sans limitation sur une période spécifiée.

• Contrat de niveau de service : le niveau Gratuit n’a pas de Contrat SLA. Le niveau Standard offre un SLA avec une disponibilité de 99,9 % (99,95 % si la géoréplication est activée). Le niveau Premium offre un SLA avec une disponibilité de 99,9 % (99,99 % si la géoréplication est activée).

• Fonctionnalités : tous les niveaux incluent des fonctionnalités, notamment le chiffrement avec des clés gérées par Microsoft, l’authentification via une clé d’accès ou Microsoft Entra ID, le contrôle d’accès en fonction du rôle (RBAC), l’identité managée, les balises de service et la redondance de zone de disponibilité. Les niveaux Standard et Premium offrent plus de fonctionnalités, notamment la prise en charge de Private Link, le chiffrement avec des clés gérées par le client, la protection contre la suppression réversible et la capacité de géoréplication.

• Coût : l’utilisation d’un magasin de niveau Gratuit ne génère pas de frais.

  Les magasins du niveau Standard ont une charge d’utilisation quotidienne qui inclut les 200 000 premières requêtes chaque jour. Les requêtes au-delà de cette allocation quotidienne donnent lieu à des frais.

  Les magasins du niveau Premium ont également un charge d’utilisation quotidienne et incluent un réplica. Chaque jour, les 800 000 premières requêtes pour l’origine et les 800 000 premières requêtes pour le réplica sont incluses dans les frais journaliers. Les requêtes dépassant cette allocation quotidienne entraînent des frais de dépassement.

Vous pouvez mettre à niveau un magasin App Configuration à tout moment. Par exemple, pour passer du niveau Gratuit au niveau Standard ou Premium ou du niveau Standard vers le niveau Premium.

Vous ne pouvez pas passer à une version antérieure du magasin App Configuration. Par exemple, vous ne pouvez pas passer du niveau Premium au niveau Standard, ou du niveau Standard au niveau Gratuit. Toutefois, vous pouvez créer un magasin au niveau souhaité, puis importer des données de configuration dans ce magasin.

Les données client stockées dans App Configuration résident dans la région où le magasin App Configuration du client a été créé. Les données client sont répliquées vers une autre région uniquement si le client active la géoréplication pour cette région. Cela s’applique à toutes les régions disponibles. Les clients peuvent déplacer leurs données, les copier ou y accéder à partir de n’importe quel emplacement dans le monde.

Azure App Configuration prend en charge la géoréplication pour renforcer la résilience aux pannes régionales.

Azure App Configuration prend en charge les Zones de disponibilité Azure pour protéger votre application et vos données contre les défaillances d’un centre de données unique. Toutes les régions pour lesquelles des zones de disponibilité sont activées se composent d’au moins trois zones de disponibilité, chacune étant un centre de données physiquement indépendant. Pour la résilience, cette prise en charge dans App Configuration est activée pour tous les clients sans frais supplémentaires. Voici les régions pour lesquelles App Configuration a activé la prise en charge des zones de disponibilité. Pour plus d'informations, consultez Régions et zones de disponibilité dans Azure.

Voici les régions dans lesquelles App Configuration a activé la prise en charge des zones de disponibilité.

Les magasins App Configuration ont des quotas de requêtes différents en fonction de leur niveau. Les magasins du niveau Gratuit sont limités à 1 000 requêtes par jour, les magasins du niveau Standard à 30 000 requêtes par heure et les magasins du niveau Premium n’ont aucune limite de requêtes, ce qui garantit un accès ininterrompu.

Les magasins App Configuration ont des allocations de débit en fonction de leur niveau. Les magasins du niveau gratuit n’ont pas de débit garanti. Les magasins du niveau Standard prennent en charge un taux d’exécution allant jusqu’à 300 RPS (requêtes par seconde) pour les opérations de lecture, et jusqu’à 60 RPS pour les opérations d’écriture. Les magasins du niveau Premium prennent en charge des taux d’exécution allant jusqu’à 450 RPS pour les opérations de lecture, et jusqu’à 100 RPS pour les opérations d’écriture.

Prenons un exemple et supposons que vous disposez d’une application avec 1 000 paramètres de configuration. Votre application charge tous ces paramètres à partir de App Configuration au démarrage. Après cela, il recherche une clé sentinelle pour les modifications de configuration toutes les 30 secondes. Que vous exécutiez Kubernetes, App Service ou des machines virtuelles, nous supposons que 50 instances de votre application s’exécutent simultanément.

Tout d’abord, nous allons estimer les demandes de surveillance de la configuration. Chaque instance de votre application envoie une requête pour la clé sentinelle à App Configuration toutes les 30 secondes. Ainsi, elle envoie 120 (=3 600/30) requêtes en une heure. Étant donné que vous avez 50 instances de votre application, votre application envoie 6 000 (=120x50) demandes au total toutes les heures pour la surveillance de la configuration. Notez que dans la mesure où les requêtes de clé sentinelle sont fréquentes et pour la plupart inchangées, la majorité d’entre elles ne sont pas prises en compte dans les limites de quota† horaires du magasin pour un magasin de niveau Standard.

Ensuite, nous allons estimer les demandes de chargement/rechargement de configuration. Votre application charge tous les paramètres au démarrage ou chaque fois qu’une modification de clé sentinelle est détectée. Chaque requête adressée à App Configuration peut récupérer jusqu’à 100 paires clé-valeur. 10 requêtes (=1 000/100) sont donc nécessaires pour charger tous les paramètres. Étant donné que vous avez 50 instances d’application, vous envoyez 500 (=10x50) de requêtes au total lorsque votre application redémarre ou recharge sa configuration.

Enfin, mettons-les ensemble. En supposant que vous avez mis à jour la clé sentinelle deux fois dans l’heure, votre magasin App Configuration recevra donc 7 000 (=6 000+ 500 x 2) demandes totales pour cette heure. Notez que parmi ces requêtes, seules 1 000 (=500x2) requêtes environ utilisent le quota horaire disponible pour un magasin de niveau Standard. Mettez à jour les chiffres de cet exemple en fonction des spécificités de votre configuration et de votre conception. Vous disposerez ainsi d’une mémoire tampon suffisante par rapport à la limite de quota horaire.

†Les magasins de niveau gratuit n’ont pas de requêtes fréquentes et répétées exclues de leur limite quotidienne.

Votre application peut recevoir une réponse « Code d’état HTTP 429 » dans les cas suivants :

• Dépassement du quota de requêtes quotidiennes pour un magasin du niveau Gratuit.
• Dépassement du quota de requêtes par heure pour un magasin du niveau Standard.
• Dépassement de l’allocation de débit pour un magasin de n’importe quel niveau.
• Dépassement de l’allocation de bande passante pour un magasin de n’importe quel niveau.
• Tentative de création ou de modification d’une paire clé-valeur alors que le quota de stockage est dépassé.

Examinez le corps de la réponse 429 connaître pour la raison spécifique de l’échec de la requête. Vous pouvez également collecter des journaux d’activité pour votre magasin App Configuration dans Azure Monitor et configurer des alertes pour la métrique Rapport d’utilisation du quota de requêtes.

La réception de réponses « Code d’état HTTP 429 » momentanées n’entraîne généralement aucun préjudice, car les clients App Configuration les gèrent correctement. Toutefois, si votre application rencontre régulièrement des réponses « Code d’état HTTP 429 », tenez compte des options suivantes :

• Mettez à niveau votre magasin vers le niveau Premium : ce niveau n’impose aucune limite de quota pour les requêtes. Il comporte un quota de stockage et une limite de débit plus élevés.
• Utilisez des fournisseurs App Configuration : les fournisseurs ont des fonctionnalités intégrées de nouvelle tentative et de mise en cache, ainsi que de nombreuses autres fonctionnalités de résilience. Veillez à effectuer une mise à jour vers la dernière version du fournisseur pour bénéficier de toutes les dernières améliorations.
• Utiliser les kits de développement logiciel App Configuration si votre application doit envoyer des demandes d’écriture. Bien que les kits SDK ne soient pas aussi riches en fonctionnalités que les fournisseurs, ils effectuent automatiquement une nouvelle tentative en cas de réponse de type code d’état HTTP 429 ou autres erreurs passagères.
• Incluez la logique de nouvelle tentative dans les clients personnalisés si vous ne pouvez pas utiliser les fournisseurs App Configuration ou les kits de développement logiciel. L’en-tête retry-after-ms dans la réponse indique un délai d’attente suggéré (en millisecondes) avant d’effectuer une nouvelle tentative de requête.
• Distribuez les requêtes sur plusieurs instances clientes : cela permet d’obtenir le débit maximal de votre magasin App Configuration.
• Réduisez le nombre de requêtes adressées à App Configuration : suivez les instructions pour réduire le nombre de requêtes.
• Améliorez la résilience de votre application : envisagez d’intégrer la réplication géographique pour permettre le basculement et l’équilibrage de charge. Consultez les meilleures pratiques pour créer des applications hautement résilientes.

La fonctionnalité de suppression réversible est automatiquement activée sur tous les magasins App Configuration aux niveaux Standard et Premium. Quand un magasin App Configuration de niveau Standard ou Premium est supprimé, son nom est réservé pendant la période de rétention. Pour recréer un magasin portant le même nom avant l’expiration de la période de rétention, vous devez d’abord vider le magasin supprimé de manière réversible, à condition que la protection contre la suppression définitive ne soit pas activée dans le magasin. Si la protection contre la suppression définitive est activée, vous devez attendre que la période de rétention soit écoulée. Utilisez la fonction de suppression définitive ou définissez une période de rétention plus courte si vous devez souvent recréer un magasin portant le même nom. Les flux de travail qui nécessitent la recréation d’un magasin portant le même nom doivent prévoir une heure entre le vidage d’un magasin de configuration et l’exécution de la création suivante. Cette recommandation est en place, car une fois qu’un vidage est demandé, le nettoyage réel des ressources du magasin de configuration est effectué de manière asynchrone, ce qui nécessite un peu plus de temps pour finaliser. Pour éviter d’avoir toute attente, il est recommandé d’utiliser des noms uniques pour les flux de travail qui créent des magasins de configuration éphémères.

Tous les magasins App Configuration aux niveaux Standard et Premium prennent en charge la fonctionnalité de suppression réversible que vous ne pouvez pas désactiver. Vous pouvez récupérer un magasin supprimé au cours de sa période de rétention. Suivez ces instructions pour récupérer un magasin App Configuration supprimé par erreur.

Oui. Bien que vous puissiez gérer les indicateurs de fonctionnalités et les références Key Vault dans App Configuration via le Portail Azure ou l’interface CLI, vous pouvez également les créer et les mettre à jour par programmation à l’aide de Kits de développement logiciel (SDK) App Configuration. Par conséquent, vous pouvez écrire votre portail de gestion personnalisé ou les gérer dans votre CI/CD par programmation. L’indicateur de fonctionnalité et les API de référence Key Vault sont disponibles dans les Kits de développement logiciel (SDK) de tous les langages pris en charge. Modifiez les exemples de liens pour obtenir des exemples dans chaque langage pris en charge.

L’évaluation et la consommation des indicateurs de fonctionnalités dans votre application nécessitent les bibliothèques de gestion des fonctionnalités et des fournisseurs App Configuration, qui sont disponibles dans .NET et Java Spring. Pour plus d’informations, modifiez la section Gestion des fonctionnalités sous Démarrages rapides et Tutoriels.

Les profils Spring permettent de séparer les composants de votre application, notamment la configuration, et de les rendre disponibles uniquement dans certains environnements ou quand des bibliothèques spécifiques sont utilisées.

Nous vous recommandons de définir l’étiquette de vos paires clé-valeur pour qu’elle corresponde à vos profils Spring. Par défaut, la bibliothèque de fournisseurs Spring d’App Configuration charge les paires clé-valeur avec les étiquettes qui correspondent aux profils Spring actifs (${spring.profiles.active}), si le filtre d’étiquette n’est pas défini explicitement. En l’absence de profil Spring actif défini, les paires clé-valeur ne portant « aucune étiquette » sont chargées.

Par exemple, avec les profils dev et prod, vous créez des paires clé-valeur correspondantes avec les étiquettes suivantes.

Quand le profil Spring est défini sur dev, la valeur de config.message est Hello from dev. Quand le profil Spring est défini sur prod, la valeur de config.message est Hello from prod.

Ce comportement par défaut peut être remplacé en définissant le filtre d’étiquette dans votre fichier de démarrage. La bibliothèque de fournisseurs Spring charge les paires clé-valeur avec les étiquettes spécifiées, quel que soit le profil Spring actif.

spring.cloud.azure.appconfiguration.stores[0].selects[0].label-filter: my-label

Pour sélectionner d’autres étiquettes et vos profils Spring, vous pouvez utiliser un filtre d’étiquette comme ',${spring.profiles.active}', qui permettent de sélectionner toutes les clés sans étiquette et celles correspondant à vos profils Spring. Les étiquettes les plus à droite sont prioritaires quand des clés en double sont trouvées.

À compter de la version 3.1.0, la bibliothèque Microsoft.FeatureManagement permet d’exécuter des services de gestion des fonctionnalités, y compris des filtres de fonctionnalités, en tant que services délimités dans les applications .NET basées sur l’injection de dépendances. Pour tirer parti de cette fonctionnalité, vous pouvez simplement remplacer l’appel AddFeatureManagement dans votre code par AddScopedFeatureManagement, comme indiqué dans l’extrait de code suivant :

services.AddScopedFeatureManagement();

Les filtres de fonctionnalités peuvent évaluer un indicateur de fonctionnalité en fonction des propriétés d’une requête HTTP. Ceci est habituellement effectué en inspectant le HttpContext via le IHttpContextAccessormodèle singleton . Toutefois, ce modèle ne fonctionne pas pour les applications Blazor Server, où des services à l’étendue délimitée doivent être utilisés à la place. Dans ce cas, la méthode AddScopedFeatureManagement doit être utilisée.

Abonnez-vous à notre référentiel d’annonces GitHub.

Vous pouvez nous contacter directement sur GitHub.

• À propos d’Azure App Configuration