Utiliser le service de configuration des applications pour Tanzu

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 :

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.

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 :

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 Gen2	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	Non pour Gen1 Oui pour Gen2	Algorithme pour hostKey : ssh-dss, ssh-rsa, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384 ou ecdsa-sha2-nistp521. (Obligatoire si vous fournissez une Host 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 sont true et false. La valeur par défaut est true.

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 :

Procédez comme suit pour effectuer une mise à niveau de Gen1 à Gen2 :

1. Dans le Portail Microsoft Azure, accédez à la page Service de configuration d’application pour votre instance de service Azure Spring Apps.

2. Sélectionnez la section Paramètres, puis sélectionnez Gen2 dans le menu déroulant Génération.

   

3. 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, ce ConfigMap 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 dans ConfigMap.
• 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 avec spring-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’environnement AZURE_SPRING_APPS_CONFIG_FILE_PATH, comme indiqué dans la section Prise en charge polyglotte.

Configurer les paramètres du service de configuration des applications

az spring application-configuration-service git repo add \
    --name <entry-name> \
    --patterns <patterns> \
    --uri <git-backend-uri> \
    --label <git-branch-name>

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.

az spring application-configuration-service git repo add \
    --name <entry-name> \
    --patterns <patterns> \
    --uri <git-backend-uri> \
    --label <git-branch-name> \
    --ca-cert-name <ca-certificate-name>

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.

az spring application-configuration-service bind --app <app-name>
az spring app deploy \
    --name <app-name> \
    --artifact-path <path-to-your-JAR-file> \
    --config-file-pattern <config-file-pattern>

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.

az spring app create \ 
    --resource-group <resource-group> \ 
    --service <service-name> \ 
    --name <app-name> \ 
    --bind-application-configuration-service 

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.

az spring application-configuration-service create \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-service-instance-name>

az spring application-configuration-service delete \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-service-instance-name>

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é.

az role assignment create \
    --role "Azure Spring Apps Application Configuration Service Config File Pattern Reader Role" \
    --scope "<service-instance-resource-id>" \
    --assignee "<your-identity>"

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}\"}]"
  }
}

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 :

1. 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.

2. 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
   

3. Vérifiez le contenu du fichier config à l’aide de commandes telles que cat.

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 :

1. Ouvrez votre instance Azure Spring Apps.

2. Dans le volet de navigation, sélectionnez Paramètres de diagnostic.

3. Sélectionnez Ajouter un paramètre de diagnostic ou Paramètre de modification pour un paramètre existant.

4. Dans la section Journaux, sélectionnez la catégorie Journaux système.

5. Dans la section Détails de la destination, sélectionnez Envoyer à l’espace de travail Log Analytics, puis votre espace de travail.

6. 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 :

1. Veillez à activer les journaux système. Pour plus d’informations, consultez la section Paramètres de diagnostic de Log Analytics.

2. Ouvrez votre instance Azure Spring Apps.

3. Dans le menu de navigation, sélectionnez Journaux puis sélectionnez Vue d’ensemble.

4. 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
     

     

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.

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.

Contenu connexe

Azure Spring Apps