Spring Cloud : comment gérer la configuration des microservices (partie 2)

Dans la première partie de cet article, nous avons vu comment mettre en place un scénario simple avec un serveur Spring Cloud Config et le pendant client. Le serveur a été configuré avec un indigène profile, et la configuration a été stockée dans le classpath, dans un sous-dossier nommé configuration. La démo était constituée d’une seule instance d’un serveur et d’un client.

Dans la deuxième partie, nous montrerons comment configurer Spring Cloud Config pour se connecter et utiliser un référentiel Git externe. Ensuite, dans les sections suivantes, nous parlerons de l’actualisation des données de configuration sans redémarrer les services.

Configuration du microservice par le référentiel Git : côté serveur

Spring Cloud Config utilise un référentiel Git par défaut. Dans la première partie de cet article, nous avons vu comment basculer sur un référentiel basé sur filesystem/classpath, en définissant la propriété spring.profiles.active au native valeur. Pour utiliser un dépôt Git, nous devons plutôt définir les éléments suivants :

spring:
  cloud:
   config:
     server:
       git:
         uri: https://github.com/mcasari/spring-cloud-config-git-server-repo.git
         username: ${github.username}
         password: ${github.password}
         cloneOnStart: true

Nous avons défini un URI sur un exemple de référentiel public dans l’exemple ci-dessus. Même si cela n’est pas nécessaire dans ce cas, nous avons également mis un nom d’utilisateur et un mot de passe pour montrer comment nous configurerions l’accès à un référentiel privé protégé. Pour un référentiel privé, nous pouvons transmettre les informations d’identification d’un utilisateur qui a accès à ce référentiel et comme mot de passe, nous pouvons définir un jeton de sécurité généré expressément à l’aide du panneau d’administration GitHub. Dans l’exemple, nous avons utilisé des espaces réservés pour les valeurs de nom d’utilisateur et de mot de passe, qui peuvent être fournis en tant qu’arguments Java dans la commande de démarrage :

java -jar -Dgithub.username=<myusername> -Dgithub.password=<mygithubtoken> spring-cloud-config-git-server-1.0-SNAPSHOT.jar

Dans le cas d’un référentiel public, le nom d’utilisateur et le mot de passe seront simplement ignorés.

Le cloneOnStart La propriété nous permet de configurer le moment où le serveur est censé cloner le référentiel. Par défaut, le serveur le fait lorsque les données de configuration sont demandées pour la première fois. Si nous le réglons sur trueil sera déclenché lors de la phase de démarrage à la place.

Configuration du microservice par le référentiel Git : côté client

Du point de vue du côté client, rien ne change par rapport à la discussion dans la première partie de cet article. Nous pouvons utiliser le morceau de configuration suivant dans le application.yml fichier si nous voulons contacter le serveur en utilisant l’hôte et le port par défaut (localhost:8888):

config: 
   import: "optional:configserver:"

ou, si nous devons définir une adresse plus précise :

  config:
     import: "optional:configserver:http://configserverhost:8888"

Et si le serveur est protégé par un nom d’utilisateur et un mot de passe, il faut aussi :

  cloud:
    config:
      username: myusername
      password: mypassword

Exécution du serveur et du client

Nous pouvons exécuter le serveur et le client de la même manière que nous l’avons fait pour le scénario de profil natif :

java -jar spring-cloud-config-git-server-1.0-SNAPSHOT.jar 
... 
java -jar spring-cloud-config-git-client-1.0-SNAPSHOT.jar

Configuration du microservice par le référentiel Git : rechargement de la configuration

Revenons un instant à la configuration décrite dans les sections précédentes. Si nous clonons le référentiel Git localement, apportons quelques modifications aux propriétés, les validons, les poussons et vérifions le serveur de configuration par ses points de terminaison, nous verrons les valeurs mises à jour. Mais, si nous appelons les services REST du client, nous verrons toujours les anciennes valeurs. En effet, le client a besoin que son contexte Spring soit rechargé d’une manière ou d’une autre, pour actualiser les propriétés du bean.

Rechargement manuel des haricots de printemps

Spring Cloud fournit un actionneur spécifique »rafraîchir” endpoint, que nous pouvons appeler par HTTP POST demande. Ce point de terminaison a pour effet de recharger les beans marqués du @RefreshScope annotation. Pour construire une démo simplifiée, on peut éviter d’introduire une couche de sécurité dans l’application cliente. Nous pouvons y parvenir simplement en ne définissant pas de démarreur de sécurité dans le Maven POM. De cette façon, nous pourrons appeler librement le point de terminaison de rafraîchissement.

Supposons que nous ayons un bean défini comme ceci :

@Component
@RefreshScope 
@ConfigurationProperties(prefix = "myproperties")
public class DemoClient {
	private List<String> properties = new ArrayList<String>();

	public List<String> getProperties() {
		return properties;
	}

	@Value("${myproperty}")
	private String myproperty;

	public String getMyproperty() {
		return myproperty;
	}
}

Et une classe contrôleur avec deux services REST :

@RestController
public class ConfigClientController {

	private static final Logger LOG = LoggerFactory.getLogger(ConfigClientController.class);
	
	@Autowired
	private DemoClient demoClient;
	
	@GetMapping("/getProperties")
	public List<String> getProperties() {
		LOG.info("Properties: " + demoClient.getProperties().toString());
		return demoClient.getProperties();
	}
	
	@GetMapping("/getProperty")
	public String getProperty() {
		LOG.info("Property: " + demoClient.getMyproperty().toString());
		return demoClient.getMyproperty();
	}
}

Ensuite, apportons quelques modifications au properties et myProperty champs, validez-les et poussez-les, et enfin appelez le point de terminaison d’actualisation par un HTTP POST demande:

curl -X POST http://localhost:8081/actuator/refresh

Si nous appelons ensuite les deux services REST clients, nous verrons les valeurs mises à jour.

Rechargement automatique des haricots de printemps

De toute évidence, l’option de recharger manuellement les propriétés de configuration n’est pas la meilleure solution. Nous préférerions un scénario où après un Git pousser opération, le système est automatiquement mis à jour vers le nouvel état de configuration, sans aucun redémarrage et sans qu’il soit nécessaire d’exécuter manuellement une actualisation sur des beans spécifiques. L’image ci-dessous décrit un disponible architecture implémenter une telle fonctionnalité.

Pour faire fonctionner la première partie de l’architecture ci-dessus, nous devons faire quelques configurations. GitHub, comme d’autres outils logiciels de contrôle de version, fournit une fonctionnalité nommée Webhook. UN Webhook est une définition d’un point de terminaison que GitHub peut invoquer en transmettant les informations impliquées dans un push à la branche Git principale.

UN /monitor point de terminaison est disponible dans Configuration cloud de printemps et peut être activé par le spring-cloud-config-monitor dépendance:

<dependency>
 <groupId>org.springframework.cloud</groupId>
 <artifactId>spring-cloud-config-monitor</artifactId>
</dependency>

et l’ajout d’un élément de configuration dans le application.yml déposer:

spring:
 cloud:
   config:
     server:
       monitor:
         github:
           enabled: true

Nous pouvons configurer le /monitor point de terminaison en tant que Webhook dans le référentiel GitHub afin que GitHub puisse l’appeler pour notifier toute modification apportée au serveur de configuration.

Une fois les éléments ci-dessus mis en place, l’élément suivant de l’architecture est un courtier de messages qui agit comme un entonnoir pour les événements provenant du serveur de configuration et provenant d’une notification Webhook et comme source pour les clients censés consommer ces notifications (en tant qu’événements de type RefreshRemoteApplicationEvent). Nous pouvons choisir entre Kafka et RabbitMQ en tant que courtiers de messages. Dans cet article, nous utiliserons RabbitMQ.

Pour exécuter une démonstration de l’architecture ci-dessus dans un environnement local, le moyen le plus simple serait d’exécuter une image Docker de RabbitMQ :

docker run -d --name rabbit -p 5672:5672 -p 15672:15672 rabbitmq:management

Le client et le serveur ont tous deux besoin de la dépendance suivante pour pouvoir se connecter au courtier de messages RabbitMQ :

<dependency>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-starter-bus-amqp</artifactId>
 </dependency>

Et la configuration suivante dans le application.yml déposer:

  rabbitmq:
     host: localhost
     port: 5672
     username: guest
     password: guest

Une fois que nous avons exécuté toutes les pièces, le serveur de configuration et le client seront liés au courtier de messages par un RabbitMQ échange nommé SpringCloudBuscomme nous pouvons le voir dans la capture d’écran suivante.

Tester l’architecture ci-dessus serait problématique dans un environnement local : nous pouvons connecter notre serveur de configuration au référentiel Git distant, mais pas l’inverse. Pour surmonter cette situation, nous pouvons simuler la Webhook caractéristique en faisant un mannequin HTTP POST prétendant qu’il s’agit d’une véritable notification push Git. Nous pouvons utiliser n’importe quel outil que nous voulons pour faire l’appel POST, ici nous utilisons un curl commande:

curl -H "X-Github-Event: push" -H "Content-Type: application/json" -X POST -d '{"commits": [{"modified": ["client-service.yaml"]}]}' http://localhost:8888/monitor

Dans cet appel, nous transmettons le type d’événement en tant qu’en-tête HTTP spécifique, et dans le corps JSON de la requête POST, nous spécifions quel fichier a été modifié.

Note: Dans un système Windows, nous aurons des problèmes avec le caractère guillemet simple, nous devons donc les remplacer par des guillemets doubles et échapper ceux à l’intérieur du contenu JSON, comme ceci : curl -H "X-Github-Event: push" -H "Content-Type: application/json" -X POST -d "{\"commits\": [{\"modified\": [\"client-service.yaml\"]}]}" http://localhost:8888/monitor

Récapitulatif rapide

Pour résumer, pour exécuter un exemple de test complet, nous pouvons effectuer les étapes suivantes :

• Exécutez l’instance RabbitMQ par Docker.
• Exécutez le serveur de configuration et les applications client en utilisant leurs jars exécutables avec le java-jar commande.
• Cloner la télécommande…