Azure App Configuration – Questions fréquentes (FAQ)

Cet article répond aux questions fréquentes sur Azure App Configuration.

En quoi App Configuration est-il différent d’Azure Key Vault ?

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.

Dois-je stocker les secrets dans App Configuration ?

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.

Mes données sont-elles chiffrées par App Configuration ?

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.

En quoi App Configuration est-il différent des paramètres Azure App Service ?

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.

Existe-t-il des limitations de taille sur les clés et les valeurs stockées dans App Configuration ?

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.

Cette limite 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 plus d’informations, consultez Azure subscription and service limits (Limites de service et d’abonnement Azure).

Comment dois-je stocker les configurations pour plusieurs environnements (test, intermédiaire, production, etc) ?

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.

Quels sont les modes d’utilisation recommandés d’App Configuration ?

Prenez connaissance des bonnes pratiques.

Quel est le coût d’App Configuration ?

Il existe deux niveaux tarifaires :

  • Niveau Gratuit
  • Niveau standard

Si vous avez créé un magasin avant l’introduction du niveau Standard, il passe automatiquement au niveau Gratuit lors de la mise à la disposition générale. Vous pouvez choisir de passer au niveau Standard ou de rester au niveau Gratuit.

En revanche, vous ne pouvez pas passer un magasin du niveau Standard au niveau Gratuit. Au niveau Gratuit, vous pouvez créer un magasin, puis importer des données de configuration dans ce magasin.

Quel niveau App Configuration dois-je utiliser ?

Les deux niveaux App Configuration offrent des fonctionnalités de base, notamment des paramètres de configuration, indicateurs de fonctionnalité, références Key Vault, instantanés de configuration, opérations de gestion de base, métriques et journaux.

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

  • Ressources par abonnement : Une ressource se compose d’un magasin de configuration unique. Au niveau gratuit, chaque abonnement est limité à un magasin de configuration par région. Au niveau Standard, 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 d’instantanés. Au niveau standard, chaque magasin de configuration peut utiliser jusqu’à 1 Go de stockage standard et 1 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. Au niveau Standard, 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. Quand le quota horaire est épuisé, les demandes peuvent retourner le code d’état HTTP 429 indiquant un trop grand nombre de demandes 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.

  • Contrat de niveau de service (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 Gratuit ne présente aucun contrat de niveau de service.

  • Fonctionnalités : les deux 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 étiquettes de service et la redondance de zone de disponibilité. Le niveau Standard offre 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 géoréplication.

  • Coût : Au niveau Standard, les magasins génèrent des frais d’utilisation quotidiens. Chaque jour, les 200 000 premières requêtes sont comprises dans les frais quotidiens. Au-delà de l'allocation quotidienne, les requêtes génèrent aussi des frais de dépassement. Au niveau Gratuit, l'utilisation d'un magasin ne génère pas de frais.

Puis-je passer un magasin du niveau Gratuit au niveau Standard ? Puis-je passer un magasin du niveau Standard au niveau Gratuit ?

Vous pouvez à tout moment passer du niveau Gratuit au niveau Standard.

En revanche, vous ne pouvez pas passer un magasin du niveau Standard au niveau Gratuit. Au niveau Gratuit, vous pouvez créer un magasin, puis importer des données de configuration dans ce magasin.

Où résident les données stockées dans App Configuration ?

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.

Comment App Configuration garantit-il une haute disponibilité des données ?

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 avec zone de disponibilité se composent d’au moins 3 zones de disponibilité, où chacune est 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é.

Amérique Europe Moyen-Orient Afrique Asie-Pacifique
Brésil Sud France Centre Qatar Central Australie Est
Centre du Canada Italie Nord Émirats arabes unis Nord Inde centrale
USA Centre Allemagne Centre-Ouest Israël Central Japon Est
USA Est Europe Nord Centre de la Corée
USA Est 2 Norvège Est Asie Sud-Est
États-Unis - partie centrale méridionale Sud du Royaume-Uni Asie Est
Gouvernement américain - Virginie Europe Ouest Chine Nord 3
USA Ouest 2 Suède Centre
USA Ouest 3 Suisse Nord
Pologne Centre

Est-ce qu’il y a des limites au nombre de requêtes adressées à App Configuration ?

Les magasins de configuration dans le niveau Gratuit sont limités à 1 000 requêtes par jour. Les magasins de configuration dans le niveau Standard peuvent subir une limitation temporaire quand le taux de demande dépasse 30 000 demandes par heure.

Quand un magasin atteint sa limite au niveau Standard, il peut retourner le code d’état HTTP 429 pour certaines demandes effectuées jusqu’à la fin de l’heure. 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.

Si votre application rencontre régulièrement des réponses du code d’état HTTP 429, envisagez de la reconcevoir pour réduire le nombre de requêtes effectuées. Pour plus d’informations, consultez comment réduire les demandes adressées à App Configuration.

Mon application reçoit des réponses de code d’état HTTP 429. Pourquoi ?

Vous allez recevoir une réponse de code d’état HTTP 429 dans les circonstances suivantes :

  • Dépassement du nombre limite de requêtes quotidiennes pour un magasin dans le niveau Gratuit.
  • Dépassement du nombre limite de requêtes par heure pour un magasin dans le niveau Standard.
  • Limitation temporaire due à une grosse rafale de requêtes†.
  • Limitation momentanée due à une utilisation excessive de la bande passante†.
  • Tentative de création ou de modification d’une clé 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.

†Un magasin de configuration peut être confronté à une limitation temporaire s’il reçoit une grosse rafale de requêtes ou de transferts d’un volume excessif de données. Les clients App Configuration, comme le kit de développement logiciel (SDK) Azure, les bibliothèques du fournisseur de configuration et les tâches Azure Pipelines, effectuent automatiquement de nouvelles tentatives sur les requêtes limitées. Pour toutes les applications qui utilisent l’un de ces clients, ou un client personnalisé qui effectue une nouvelle tentative sur des requêtes limitées, cette limitation temporaire doit passer inaperçue, le cas échéant.

Comment faire estimer le nombre de demandes que ma demande peut envoyer à App Configuration ?

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 soyez en cours d’exécution sur Kubernetes, App Service ou des machines virtuelles, 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, de sorte qu’elle envoie 120 (=3600/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 qu'étant donné que les demandes de clé sentinelle sont fréquentes et pour la plupart inchangées, la majorité d'entre elles ne seront pas prises en compte dans les limites de quota horaire du magasin†.

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 demande de App Configuration peut récupérer jusqu’à 100 clés-valeurs. Il faudra donc 10 demandes (=1000/100) 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 sur ces demandes, seulement 1 000 (=500x2) demandes environ utilisent le quota horaire disponible. Mettez à jour les nombres de cet exemple pour qu’ils correspondent à votre configuration et à votre conception spécifiques afin de disposer d’une mémoire tampon suffisante par rapport à la limite de limitation horaire. Pour plus d’informations, consultez comment réduire les demandes adressées à App Configuration.

†Les magasins de niveau gratuit n'ont pas de demandes fréquentes et répétées exclues de leur limite quotidienne.

Pourquoi ne puis-je pas créer de magasin App Configuration portant le même nom que celui que je viens de supprimer ?

Tous les magasins App Configuration au niveau standard ont automatiquement activé la fonctionnalité suppression réversible. Lorsqu’un magasin App Configuration de niveau standard 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.

Comment puis-je restaurer un magasin App Configuration que j’ai supprimé par erreur ?

Tous les magasins App Configuration au niveau standard prennent en charge la fonctionnalité suppression réversible, qui ne peut pas être désactivée. 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.

Puis-je créer et mettre à jour des indicateurs de fonctionnalités ou des références Key par programmation ?

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.

Guide pratique pour utiliser des profils Java Spring dans App Configuration

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 App Configuration charge les paires clé-valeur avec les étiquettes correspondant aux profils Spring actifs actuels (${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.

Clé Étiquette Valeur
/application/config.message dev Hello from dev
/application/config.message prod Hello from prod

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.

Comment activer la gestion des fonctionnalités dans les applications Blazor ou en tant que services délimités dans les applications .NET ?

À 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. Cette opération est généralement effectuée en inspectant HttpContext par le biais du modèle singleton IHttpContextAccessor. Toutefois, ce modèle ne fonctionne pas pour les applications serveur Blazor où des services délimités doivent être utilisés à la place. Dans ce cas, la méthode AddScopedFeatureManagement doit être utilisée.

Comment puis-je recevoir des annonces sur les nouvelles versions et d’autres informations relatives à App Configuration ?

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

Comment puis-je signaler un problème ou faire une suggestion ?

Vous pouvez nous contacter directement sur GitHub.

Étapes suivantes