Utiliser le service de configuration des applications pour Tanzu
Remarque
Les plans Essentiel, Standard et Entreprise seront déconseillés à compter de la mi-mars 2025, avec une période de mise hors service de 3 ans. Nous vous recommandons de passer à Azure Container Apps. Pour plus d’informations, consultez l’annonce de mise hors service d’Azure Spring Apps.
Le plan de consommation standard et dédiée sera déconseillé à compter du 30 septembre 2024, avec un arrêt complet après six mois. Nous vous recommandons de passer à Azure Container Apps. Pour plus d’informations, consultez Migrer le plan de consommation standard et dédiée Azure Spring Apps vers Azure Container Apps.
Cet article s’applique à :❌ De base/Standard ✔️ Entreprise
Cet article explique comment utiliser le service de configuration des applications pour VMware Tanzu avec le plan Azure Spring Apps Enterprise.
Le service de configuration des applications pour VMware Tanzu est l’un des composants commerciaux de VMware Tanzu. Il permet une gestion native Kubernetes des ressources ConfigMap
qui sont renseignées avec les propriétés définies dans un ou plusieurs dépôts Git.
Le service de configuration des applications est l’emplacement central dans lequel vous pouvez gérer les propriétés externes des applications dans tous les environnements. Pour comprendre les différences par rapport à Spring Cloud Config Server dans les plans De base et Standard, consultez la section Utiliser le service de configuration des applications pour la configuration externe dans Migrer une instance du plan Azure Spring Apps De base ou Standard vers le plan Entreprise.
Le service de configuration d’application est proposé en deux versions : Gen1 et Gen2. La version Gen1 sert principalement aux clients existants à des fins de rétrocompatibilité et n'est prise en charge que jusqu'au 30 avril 2024. Les nouvelles instances de service doivent utiliser Gen2. La version Gen2 utilise le flux comme back-end pour communiquer avec les référentiels Git et offre de meilleures performances par rapport à Gen1.
Le tableau suivant présente les relations entre les sous-composants :
Génération du service de configuration des applications | Sous-composants |
---|---|
Première génération | application-configuration-service |
Deuxième génération | application-configuration-service flux-source-controller |
Le tableau suivant présente quelques données de référence à titre indicatif. Cependant, la taille du dépôt Git est un facteur clé qui a un impact significatif sur les données de performance. Nous vous recommandons de ne stocker que les fichiers de configuration nécessaires dans le dépôt Git afin qu'il reste petit.
Génération du service de configuration des applications | Durée d’actualisation de moins de 100 modèles | Durée d’actualisation de moins de 250 modèles | Durée d’actualisation de moins de 500 modèles |
---|---|---|---|
Première génération | 330 s | 840 s | 1 500 s |
Deuxième génération | 13 s | 100 s | 378 s |
Gen2 fournit également plus de vérifications de sécurité lorsque vous vous connectez à un dépôt Git distant. Gen2 exige une connexion sécurisée si vous utilisez HTTPS, et vérifie la clé et l'algorithme hôte corrects lorsque vous utilisez une connexion SSH.
Vous pouvez choisir la version du service de configuration d’application lorsque vous créez une instance de service Azure Spring Apps Enterprise. La version par défaut est Gen1. Vous pouvez également passer à Gen2 après la création de l'instance, mais la rétrogradation n'est pas prise en charge. La mise à jour ne nécessite aucune interruption de service, mais nous vous recommandons de la tester dans un environnement d'essai avant de la transférer dans un environnement de production.
Prérequis
- Une instance du plan Azure Spring Apps Enterprise déjà approvisionnée, dans laquelle est activé le service de configuration des applications. Pour plus d’informations, consultez Démarrage rapide : Générer et déployer des applications sur Azure Spring Apps à l’aide du plan Enterprise.
Gestion des paramètres du service de configuration des applications
Le service de configuration des applications prend en charge Azure DevOps, GitHub, GitLab et Bitbucket pour le stockage de vos fichiers de configuration.
Pour gérer les paramètres du service, ouvrez la section Paramètres. Dans cette section, vous pouvez configurer les aspects clés suivants :
- Génération : mettez à niveau la génération de service.
- Intervalle d’actualisation : ajustez la fréquence à laquelle le service vérifie les mises à jour à partir des référentiels Git.
- Référentiels : ajoutez de nouvelles entrées ou modifiez des entrées existantes. Cette fonction vous permet de contrôler les référentiels que les moniteurs de service utilisent pour extraire des données.
Si votre génération de service actuelle est Gen1, vous pouvez effectuer une mise à niveau vers Gen2 pour bénéficier de meilleures performances. Pour plus d’informations, consultez la section Mise à niveau de Gen1 vers Gen2.
L’intervalle d’actualisation spécifie la fréquence (en secondes) de vérification des mises à jour dans le référentiel. La valeur minimale est de 0, ce qui désactive l’actualisation automatique. Pour bénéficier de performances optimales, définissez cet intervalle sur une valeur minimale de 60 secondes.
Le tableau suivant décrit les propriétés de chaque entrée de référentiel :
Propriété | Requis ? | Description |
---|---|---|
Name |
Oui | Nom unique pour étiqueter chaque dépôt Git. |
Patterns |
Oui | Modèles à rechercher dans les dépôts Git. Pour chaque motif, utilisez un format tel que {application} ou {application}/{profile} plutôt que {application}-{profile}.yml. Séparez les modèles par des virgules. Pour plus d’informations, consultez la section Modèle de cet article. |
URI |
Oui | Un URI Git (par exemple, https://github.com/Azure-Samples/piggymetrics-config ou git@github.com:Azure-Samples/piggymetrics-config ) |
Label |
Oui | Nom de branche à rechercher dans le dépôt Git. |
Search path |
Non | Chemins de recherche facultatifs séparés par des virgules pour rechercher les sous-répertoires du dépôt Git. |
Modèle
La configuration est tirée des back-ends Git en utilisant ce que vous définissez dans un modèle. Un modèle est une combinaison de {application}/{profil}, comme décrit dans les instructions suivantes.
- {application} - Le nom d’une application dont vous récupérez la configuration. La valeur
application
est considérée comme l’application par défaut et comprend des informations de configuration partagées entre plusieurs applications. Toute autre valeur se rapporte à une application spécifique et inclut les propriétés de l’application spécifique ainsi que les propriétés partagées pour l’application par défaut. - {profile} - Facultatif. Nom d’un profil dont vous pouvez récupérer les propriétés. Une valeur vide, ou la valeur
default
, comprennent des propriétés qui sont partagées entre tous les profils. Les valeurs non définies par défaut incluent des propriétés pour le profil spécifié et des propriétés pour le profil par défaut.
Authentification
La capture d’écran suivante montre les trois types d’authentification de dépôt qui sont pris en charge par le service de configuration des applications.
La liste suivante décrit les trois types d’authentification :
Dépôt public.
Vous n’avez pas besoin d’une configuration supplémentaire de l’authentification lorsque vous utilisez un dépôt public. Sélectionnez Public dans le formulaire Authentification.
Le tableau suivant affiche la propriété configurable que vous pouvez utiliser pour configurer un dépôt Git public :
Propriété Requis ? Description CA certificate
Non Nécessaire uniquement lorsqu’un certificat auto-signé est utilisé pour l’URL du dépôt Git. Dépôt privé avec authentification de base.
Le tableau suivant affiche les propriétés configurables que vous pouvez utiliser pour configurer un dépôt Git privé avec une authentification de base :
Propriété Requis ? Description username
Oui Nom d’utilisateur utilisé pour accéder au dépôt. password
Oui Mot de passe utilisé pour accéder au dépôt. CA certificate
Non Nécessaire uniquement lorsqu’un certificat auto-signé est utilisé pour l’URL du dépôt Git. Dépôt privé avec authentification SSH.
Le tableau suivant affiche les propriétés configurables que vous pouvez utiliser pour configurer un dépôt Git privé avec SSH :
Propriété Requis ? Description Private key
Oui Clé privée qui identifie l’utilisateur Git. Les clés privées chiffrées à l’aide d’une phrase secrète ne sont pas prises en charge. Host key
Non pour Gen1
Oui pour Gen2Clé hôte du serveur Git. Si vous vous connectez au serveur via Git sur la ligne de commande, la clé d’hôte se trouve dans votre fichier .ssh/known_hosts. N’incluez pas le préfixe de l’algorithme, car il est spécifié dans Host key algorithm
.Host key algorithm
Non pour Gen1
Oui pour Gen2Algorithme pour hostKey
:ssh-dss
,ssh-rsa
,ecdsa-sha2-nistp256
,ecdsa-sha2-nistp384
ouecdsa-sha2-nistp521
. (Obligatoire si vous fournissez uneHost key
).Strict host key checking
Non Valeur facultative qui indique si le back-end doit être ignoré s’il rencontre une erreur lors de l’utilisation de la Host key
fournie. Les valeurs valides sonttrue
etfalse
. La valeur par défaut esttrue
.
Pour valider l’accès à l’URI cible, sélectionnez Valider. Une fois la validation terminée, sélectionnez Appliquer pour mettre à jour les paramètres de configuration.
Mettre à jour de Gen1 à Gen2
Le service de configuration d’application Gen2 offre de meilleures performances que Gen1, en particulier lorsque vous avez un grand nombre de fichiers de configuration. Nous vous recommandons l’utilisation de Gen2, d’autant plus que Gen1 sera bientôt mis hors service. La mise à jour de Gen1 à Gen2 ne nécessite aucune interruption de service, mais nous vous recommandons de la tester dans un environnement d'essai avant de la transférer dans un environnement de production.
Gen2 nécessite plus de propriétés de configuration que Gen1 lors de l’utilisation de l’authentification SSH. Vous devez mettre à jour les propriétés de configuration de votre application pour qu’elle fonctionne avec Gen2. Le tableau suivant présente les propriétés requises pour Gen2 lors de l’utilisation de l’authentification SSH :
Propriété | Description |
---|---|
Host key |
Clé hôte du serveur Git. Si vous vous connectez au serveur via Git sur la ligne de commande, la clé d’hôte se trouve dans votre fichier .ssh/known_hosts. N’incluez pas le préfixe de l’algorithme, car il est spécifié dans Host key algorithm . |
Host key algorithm |
Algorithme pour hostKey : ssh-dss , ssh-rsa , ecdsa-sha2-nistp256 , ecdsa-sha2-nistp384 ou ecdsa-sha2-nistp521 . |
Procédez comme suit pour effectuer une mise à niveau de Gen1 à Gen2 :
Dans le Portail Microsoft Azure, accédez à la page Service de configuration d’application pour votre instance de service Azure Spring Apps.
Sélectionnez la section Paramètres, puis sélectionnez Gen2 dans le menu déroulant Génération.
Pour valider l’accès à l’URI cible, sélectionnez Valider. Une fois la validation terminée, sélectionnez Appliquer pour mettre à jour les paramètres de configuration.
Prise en charge polyglotte
Le service de configuration d’application fonctionne de manière transparence avec les applications Spring Boot. Les propriétés générées par le service sont importées en tant que configurations externes par Spring Boot et injectées dans les beans. Vous n’avez pas besoin d’écrire du code supplémentaire. Vous pouvez utiliser les valeurs à l’aide de l’annotation @Value
, accessible via l’abstraction Environnement de Spring ou les lier à des objets structurés à l’aide de l’annotation @ConfigurationProperties
.
Le service de configuration des applications prend également en charge les applications polyglottes telles que dotNET, Go, Python, etc. Pour accéder aux fichiers de configuration que vous spécifiez pour charger pendant le déploiement d’applications polyglotte dans les applications, essayez d’accéder à un chemin d’accès de fichier que vous pouvez récupérer via une variable d’environnement avec un nom tel que AZURE_SPRING_APPS_CONFIG_FILE_PATH
. Vous pouvez accéder à tous vos fichiers de configuration sous ce chemin d'accès. Pour accéder aux valeurs des propriétés dans les fichiers de configuration, utilisez les bibliothèques de fichiers en lecture/écriture existantes pour votre application.
Actualiser les stratégies
Lorsque vous modifiez et validez vos configurations dans un référentiel Git, plusieurs étapes sont effectuées avant que ces modifications ne soient reflétées dans vos applications. Ce processus, bien qu’automatisé, implique les étapes et composants distincts suivants, chacun avec sa propre échéance et sa propre comportement :
- Interrogation par le service de configuration d’application : le service de configuration d’application interroge régulièrement les référentiels Git principaux pour détecter toute modification. Cette interrogation se produit à une fréquence déterminée, définie par l’intervalle d’actualisation. Lorsqu’une modification est détectée, le service de configuration d’application met à jour la
ConfigMap
Kubernetes. - Mise à jour et interaction de
ConfigMap
avec le cache kubelet : dans Azure Spring Apps, ceConfigMap
est monté en tant que volume de données dans l’application appropriée. Toutefois, ce processus est naturellement retardé en raison de la fréquence à laquelle le kubelet actualise son cache pour reconnaître les modifications dansConfigMap
. - L’application lit la configuration mise à jour : votre application s’exécutant dans l’environnement Azure Spring Apps peut accéder aux valeurs de configuration mises à jour. Les beans existants dans le contexte Spring ne sont pas automatiquement actualisés pour utiliser les configurations mises à jour.
Ces étapes sont résumées dans le diagramme suivant :
Vous pouvez ajuster l’intervalle d’actualisation de l’interrogation du service de configuration d’application pour qu’il corresponde à vos besoins spécifiques. Pour appliquer les configurations mises à jour dans votre application, il est nécessaire de la redémarrer ou de l’actualiser.
Dans les applications Spring, les propriétés sont conservées ou référencées en tant que beans dans le contexte Spring. Pour charger de nouvelles configurations, envisagez d’utiliser les méthodes suivantes :
Redémarrez-la. Le redémarrage de l’application charge toujours la nouvelle configuration.
Appelez le point de terminaison
/actuator/refresh
qui est exposé sur le client de configuration via Spring Actuator.Pour utiliser cette méthode, ajoutez la dépendance suivante au fichier pom.xml de votre client de configuration.
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency>
Vous pouvez également activer le point de terminaison Actuator en ajoutant la configuration suivante :
management.endpoints.web.exposure.include=refresh, bus-refresh, beans, env
Après avoir rechargé les sources de propriété en appelant le point de terminaison
/actuator/refresh
, les attributs liés à@Value
dans les beans comportant l’annotation@RefreshScope
sont actualisés.@Service @Getter @Setter @RefreshScope public class MyService { @Value private Boolean activated; }
Utilisez curl avec le point de terminaison d’application pour actualiser la nouvelle configuration, comme illustré dans l’exemple suivant :
curl -X POST http://{app-endpoint}/actuator/refresh
Utilisez
FileSystemWatcher
pour surveiller les modifications apportées au fichier et actualiser le contexte à la demande.FileSystemWatcher
est une classe fournie avecspring-boot-devtools
qui surveille des répertoires spécifiques pour détecter les modifications de fichiers. Vous pouvez également utiliser un autre utilitaire avec une fonction similaire. La première option exige que les utilisateurs lancent activement l’actualisation, tandis que la dernière option peut surveiller les modifications de fichiers et appeler automatiquement l’actualisation lors de la détection des mises à jour. Vous pouvez récupérer le chemin d’accès du fichier à l’aide de la variable d’environnementAZURE_SPRING_APPS_CONFIG_FILE_PATH
, comme indiqué dans la section Prise en charge polyglotte.
Configurer les paramètres du service de configuration des applications
Pour configurer le service de configuration des applications, procédez comme suit :
Sélectionnez Service de configuration de l’application.
Sélectionnez Vue d’ensemble pour afficher l’état de l’exécution et les ressources qui sont allouées au service de configuration des applications.
Sélectionnez Paramètres et ajoutez une nouvelle entrée dans la section Dépôts avec les informations du back-end Git.
Pour valider l’accès à l’URI cible, sélectionnez Valider. Une fois la validation terminée, sélectionnez Appliquer pour mettre à jour les paramètres de configuration.
Configurer le certificat TLS pour accéder au backend Git avec un certificat auto-signé pour Gen2
Cette étape est facultative. Si vous utilisez un certificat auto-signé pour le backend Git, vous devez configurer le certificat TLS pour accéder au backend Git.
Vous devez d’abord charger le certificat dans Azure Spring Apps. Pour plus d'informations, consultez la certification Importer un certificats de Utiliser des certificats TLS/SSL dans votre application dans Azure Spring Apps.
Procédez comme suit pour configurer le certificat TLS :
Utiliser le service de configuration des applications avec les applications
Lorsque vous utilisez le service de configuration d’application avec un back-end Git, vous devez lier l’application au service de configuration d’application.
Suivez les étapes suivantes pour utiliser le service de configuration des applications avec des applications :
Ouvrez l’onglet Liaison d’application.
Sélectionnez Lier l’application et choisissez une application à partir du menu déroulant. Sélectionnez Appliquer pour établir la liaison.
Remarque
Lorsque vous modifiez l’état de liaison, vous devez redémarrer ou redéployer l’application pour que le changement prenne effet.
Dans le menu de navigation, sélectionnez Applications pour afficher la liste de toutes les applications.
Pour la colonne
name
, sélectionnez l’application cible pour laquelle configurer des modèles.Dans le volet de navigation, sélectionnez Configuration puis Paramètres généraux.
Dans la liste déroulante Modèles de fichier config, choisissez un ou plusieurs modèles dans la liste. Pour plus d’informations, consultez la section Modèle.
Sélectionnez Enregistrer.
Lier une application au service de configuration d’application
Vous pouvez maintenant choisir de lier votre application au service de configuration d’application lors de la création d'une nouvelle application.
Pour créer une nouvelle application et la lier au service de configuration des applications, procédez comme suit :
Dans le volet de navigation, sélectionnez Applications pour afficher toutes vos applications.
Sélectionnez Créer une application pour créer une application.
Entrer un nom pour votre nouvelle application.
Sélectionnez l’onglet Lier puis sélectionnez Service de configuration des applications dans le menu déroulant.
Sélectionnez Créer pour terminer la création de votre application et la lier au service de configuration d’application.
Activer ou désactiver le service de configuration d’application après la création du service
Vous pouvez activer et désactiver le service de configuration d’application après la création du service à l'aide du Portail Microsoft Azure ou de l'interface de ligne de commande Azure. Avant de désactiver le service de configuration des applications, vous devez en dissocier toutes vos applications.
Pour activer ou désactiver le service de configuration des applications, procédez comme suit :
- Accédez à votre ressource de service puis sélectionnez Service de configuration des applications.
- Sélectionnez Gérer.
- Sélectionnez ou désélectionnez Activer le service de configuration d’application, puis sélectionnez Enregistrer.
- Vous pouvez maintenant afficher l’état du service de configuration d’application dans la page Service de configuration d’application.
Examiner le fichier config dans ConfigMap
La section suivante vous montre comment examiner le contenu du fichier config extrait par le service de configuration de l’application des dépôts Git en amont dans le ConfigMap
Kubernetes associé. Pour plus d’informations, consultez la section Stratégies d’actualisation de cet article.
Affecter un rôle Azure
Tout d’abord, le rôle Azure Azure Spring Apps Application Configuration Service Config File Pattern Reader Role
doit vous être attribué.
Effectuez les étapes suivantes pour attribuer un rôle Azure :
Ouvrez le Portail Azure et accédez à votre instance de service Azure Spring Apps.
Dans le volet de navigation, sélectionnez Contrôle d’accès (IAM).
Dans la page Contrôle d’accès (IAM), sélectionnez Ajouter, puis Ajouter une attribution de rôle.
Dans la page Ajout de l’attribution de rôle, dans la liste Nom, recherchez et sélectionnez le rôle cible, puis sélectionnez Suivant.
Sélectionnez Membres, puis recherchez et sélectionnez votre nom d’utilisateur.
Sélectionnez Vérifier + attribuer.
Examiner le fichier de configuration avec Azure CLI
Utilisez la commande suivante pour afficher le contenu du fichier config par Modèle:
az spring application-configuration-service config show \
--resource-group <resource-group-name> \
--service <Azure-Spring-Apps-instance-name> \
--config-file-pattern <pattern>
Cette commande produit une sortie JSON semblable à celle de l’exemple suivant :
{
"configurationFiles": {
"application.properties": [
"example.property.application.name: example-service",
"example.property.cloud: Azure"
]
},
"metadata": {
"gitRevisions": "[{\"url\":\"{gitRepoUrl}\",\"revision\":\"{revisionInfo}\"}]"
}
}
Remarque
Les propriétés metadata
et gitRevisions
ne sont pas disponibles pour la version Gen1 de l'Application Configuration Service.
Vous pouvez également utiliser cette commande avec le paramètre --export-path {/path/to/target/folder}
pour exporter le fichier config vers le dossier spécifié. Elle prend en charge les chemins d’accès relatifs et les chemins d’accès absolus. Si vous ne spécifiez pas de chemin d’accès, la commande utilise celui du répertoire actif par défaut.
Examiner le fichier config dans l’application
Après avoir lié l’application au service de configuration de l’application et défini le Modèle pour le déploiement de l’application, comme décrit dans la section Utiliser le service de configuration de l’application avec des applications de cet article, le ConfigMap
contenant le fichier config du modèle doit être monté sur le conteneur de l’application. Pour vérifier les fichiers config dans chaque instance du déploiement de l’application, effectuez les étapes suivantes :
Connectez-vous à l’une des instances d’application. Pour plus d’informations, consultez Se connecter à une instance d’application pour la résolution des problèmes.
Utilisez la commande
echo $AZURE_SPRING_APPS_CONFIG_FILE_PATH
pour rechercher les dossiers contenant les fichiers config. Une liste d’emplacements séparés par des virgules s’affiche, comme illustré dans l’exemple suivant :$ echo $AZURE_SPRING_APPS_CONFIG_FILE_PATH /etc/azure-spring-cloud/configmap/acs-default-payment-default-e9d46,/etc/azure-spring-cloud/configmap/acs-default-catalog-default-616f4
Vérifiez le contenu du fichier config à l’aide de commandes telles que
cat
.
Remarque
Les informations de révision Git ne sont pas disponibles dans l'application.
Inspecter les journaux d’activité
Les sections suivantes vous expliquent comment consulter les journaux d'application à l'aide de l'interface de ligne de commande Azure ou du Portail Microsoft Azure.
Utiliser le streaming de journaux en temps réel
Vous pouvez diffuser en continu les journaux en temps réel avec Azure CLI. Pour plus d’informations, consultez Diffuser en continu les journaux des composants Azure Spring Apps en temps réel. Les exemples suivants montrent comment utiliser des commandes Azure CLI pour diffuser en continu de nouveaux journaux pour les sous-composants application-configuration-service
et flux-source-controller
.
Utilisez la commande suivante pour diffuser en continu des journaux pour application-configuration-service
:
az spring component logs \
--resource-group <resource-group-name> \
--service <Azure-Spring-Apps-instance-name> \
--name application-configuration-service \
--all-instances \
--follow
Utilisez la commande suivante pour diffuser en continu des journaux pour flux-source-controller
:
az spring component logs \
--resource-group <resource-group-name> \
--service <Azure-Spring-Apps-instance-name> \
--name flux-source-controller \
--all-instances \
--follow
Utiliser Log Analytics
Les sections suivantes vous expliquer comment activer et afficher les journaux système à l’aide de Log Analytics.
Paramètres de diagnostic pour Log Analytics
Vous devez activer les journaux système et envoyer les journaux à votre instance Log Analytics avant d'interroger les journaux du service de configuration des applications. Pour activer les journaux système dans le Portail Microsoft Azure, procédez comme suit :
Ouvrez votre instance Azure Spring Apps.
Dans le volet de navigation, sélectionnez Paramètres de diagnostic.
Sélectionnez Ajouter un paramètre de diagnostic ou Paramètre de modification pour un paramètre existant.
Dans la section Journaux, sélectionnez la catégorie Journaux système.
Dans la section Détails de la destination, sélectionnez Envoyer à l’espace de travail Log Analytics, puis votre espace de travail.
Sélectionnez Enregistrer pour mettre à jour le paramètre.
Vérifiez les journaux d’activité dans Log Analytics
Pour vérifier les journaux d’activité application-configuration-service
et flux-source-controller
à l’aide du Portail Microsoft Azure, procédez comme suit :
Veillez à activer les journaux système. Pour plus d’informations, consultez la section Paramètres de diagnostic de Log Analytics.
Ouvrez votre instance Azure Spring Apps.
Dans le menu de navigation, sélectionnez Journaux puis sélectionnez Vue d’ensemble.
Utilisez les exemples de requêtes suivants dans le volet d’édition des requêtes. Ajustez l’intervalle de temps, puis sélectionnez Exécuter pour rechercher les journaux.
Pour visualiser les journaux pour
application-configuration-service
, utilisez la requête suivante :AppPlatformSystemLogs | where LogType in ("ApplicationConfigurationService") | project TimeGenerated , ServiceName , LogType, Log , _ResourceId | limit 100
Pour visualiser les journaux pour
flux-source-controller
, utilisez la requête suivante :AppPlatformSystemLogs | where LogType in ("Flux") | project TimeGenerated , ServiceName , LogType, Log , _ResourceId | limit 100
Remarque
Quelques minutes peuvent s’écouler avant que les journaux ne soient disponibles dans Log Analytics.
Examiner les révisions Git des fichiers de configuration
Vous pouvez trouver la révision Git du fichier de configuration du Modèle dans les journaux du service de configuration des applications. L’exemple de journal suivant indique que le fichier de configuration du modèle payment/default
fait l’objet d’un tirage (pull) avec example-commit-id
depuis la branche main
du référentiel https://github.com/Azure-Samples/acme-fitness-store-config
. Vous pouvez découvrir comment interroger des journaux dans la section Consulter les journaux.
Applied ConfigMap ({config-map-name}) for content (payment/default) from Git repositories https://github.com/Azure-Samples/acme-fitness-store-config@main@sha1:{example-commit-id}
Vous pouvez également trouver la révision Git en utilisant Azure CLI. Pour plus d’informations, consultez la section Examiner le fichier de configuration avec Azure CLI.
Remarque
La révision Git n’est pas disponible pour la version Gen1 du service de configuration des applications.
Résoudre les problèmes connus
Si les dernières modifications ne sont pas reflétées dans les applications, consultez les éléments suivants en fonction de la section Stratégies d’actualisation :
- Vérifiez que le référentiel Git est correctement mis à jour en vérifiant les éléments suivants :
- Vérifiez que la branche du fichier config souhaité est mise à jour.
- Vérifiez que le modèle configuré dans le service de configuration d’application correspond aux fichiers config mis à jour.
- Vérifiez que l’application est liée au service de configuration d’application.
- Vérifiez que le service de configuration des applications utilise les révisions Git correctes comme décrit dans la section Examiner les révisions Git des fichiers de configuration.
- Vérifiez que le
ConfigMap
contenant le fichier config du Modèle utilisé par l’application est mis à jour, comme décrit dans la section Examiner le fichier config dans ConfigMap de cet article. Si ce n’est pas le cas, soumettez un ticket. - Vérifiez que
ConfigMap
est monté sur l’application en tant que fichier, comme décrit dans la section Examiner le fichier config dans l’application de cet article. Si le fichier n’est pas mis à jour, attendez l’intervalle d’actualisation de Kubernetes (1 minute) ou forcez une actualisation en redémarrant l’application.
Après avoir vérifié ces éléments, les applications doivent être en mesure de lire les configurations mises à jour. Si les applications ne sont toujours pas mises à jour, soumettez un ticket.