TOC

Spring Cloud Bus

Spring Cloud Bus

1. Vue d'ensemble

Dans cet article, nous allons examiner le nouveau projet Spring Cloud Bus. Spring Cloud Bus utilise un courtier de messages léger pour lier des nœuds de système distribués. La principale utilisation est de diffuser les modifications de configuration ou d'autres informations de gestion. Nous pouvons le considérer comme unActuator distribué.

Le projet utilise le courtier AMQP comme moyen de transport, mais Apache Kafka ou Redis peut être utilisé à la place de RabbitMQ. Les autres transports ne sont pas encore supportés.

Au cours de ce didacticiel, nous allons utiliser RabbitMQ comme transport principal - que nous allons naturellement déjà utiliser.

2. Conditions préalables

Avant de commencer, il est recommandé d'avoir déjà terminé "Quick Intro to Spring Cloud Configuration". Nous allons utiliser un serveur et un client de configuration cloud existants pour les étendre et ajouter des notifications automatiques sur les modifications de configuration.

2.1. RabbitMQ

Commençons par RabbitMQ, que nous recommandons d'exécuter en tant queRabbitMQ as a docker image. C'est assez simple à configurer - pour que RabbitMQ s'exécute localement, nous devonsinstall Docker et exécuter les commandes suivantes une fois que Docker est installé avec succès: 

docker pull rabbitmq:3-management

Cette commande extrait l'image du menu fixe RabbitMQ avec le plug-in de gestion installé et activé par défaut.

Ensuite, nous pouvons lancer RabbitMQ: 

docker run -d --hostname my-rabbit --name some-rabbit -p 15672:15672 -p 5672:5672 rabbitmq:3-management

Une fois que nous avons exécuté la commande, nous pouvons aller dans le navigateur Web et ouvrirhttp://localhost:15672, qui affichera le formulaire de connexion à la console de gestion. Le nom d'utilisateur par défaut est:‘guest'; mot de passe:‘guest'. RabbitMQ écoutera également sur le port 5672.

3. Ajouter un actionneur au client Cloud Config

Nous devrions avoir un serveur de configuration cloud et un client de configuration cloud en cours d'exécution. Pour actualiser les modifications de configuration, un redémarrage du client est requis à chaque fois - ce qui n'est pas idéal.

Arrêtons la configuration du client et annotons la classe de contrôleurConfigClient avec@RefreshScope: 

@SpringBootApplication
@RestController
@RefreshScope
public class SpringCloudConfigClientApplication {
    // Code here...
}

Enfin, mettons à jour le fichierpom.xml et ajoutons Actuator: 


    org.springframework.boot
    spring-boot-actuator
    1.5.5.RELEASE

La dernière version peut être trouvéehere.

Par défaut, tous les points d'extrémité sensibles ajoutés par l'actionneur sont sécurisés. Cela inclut le point de terminaison‘/refresh'. Pour plus de simplicité, nous désactiverons la sécurité en mettant à jourbootstrap.properties: 

management.security.enabled=false

Commençons par démarrer le client et mettre à jour le rôle utilisateur de‘Developer' vers‘Programmer' dans le fichier de propriétés sur GitHub. Le serveur de configuration affichera immédiatement les valeurs mises à jour; cependant, le client ne le fera pas. Pour que le client voie les nouveaux fichiers, il suffit d'envoyer une requête POST vide au point de terminaison‘/refresh', qui a été ajoutée par l'actionneur: 

$> curl -X POST http://localhost:8080/refresh

Nous allons récupérer le fichier JSON indiquant les propriétés mises à jour: 

[
  "user.role"
]

Enfin, nous pouvons vérifier si le rôle de l'utilisateur a été mis à jour: 

$> curl http://localhost:8080/whoami/Mr_Pink
Hello Mr_Pink! You are a(n) Programmer and your password is 'd3v3L'.

Le rôle utilisateur a été mis à jour avec succès et en appelant le point de terminaison‘/refresh'. Le client a mis à jour la configuration sans redémarrer.

4. Spring Cloud Bus

En utilisant Actuator, nous pouvons actualiser les clients. Cependant, dans l'environnement en nuage, nous devrions accéder à chaque client et recharger la configuration en accédant au point de terminaison de l'actionneur.

Pour résoudre ce problème, nous pouvons utiliser Spring Cloud Bus.

4.1. Client

Nous devons mettre à jour le client de configuration dans le cloud afin qu'il puisse s'abonner à l'échange RabbitMQ: 


    org.springframework.cloud
    spring-cloud-starter-bus-amqp
    1.3.1.RELEASE

La dernière version peut être trouvéehere.

Pour compléter les modifications du client de configuration, nous devons simplement ajouter les détails de RabbitMQ à un fichierapplication.yml: 

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

Veuillez noter que nous utilisons le nom d'utilisateur et le mot de passe par défaut. Cela doit être mis à jour pour la vie réelle, les applications de production. Pour ce tutoriel c'est très bien.

Maintenant, le client aura un autre point de terminaison‘/bus/refresh'. L'appel de ce noeud final entraînera:

  • obtenir la dernière configuration du serveur de configuration et mettre à jour sa configuration annotée par@RefreshScope

  • envoyer un message à l'échange AMQP pour l'informer de l'actualisation de l'événement

  • tous les nœuds abonnés mettront également à jour leur configuration

De cette façon, nous n'avons pas besoin d'accéder aux nœuds individuels et de déclencher la mise à jour de la configuration.

4.2. Serveur

Enfin, ajoutons deux dépendances au serveur de configuration pour automatiser complètement les modifications de configuration. 


    org.springframework.cloud
    spring-cloud-config-monitor
    1.3.1.RELEASE

La dernière version peut être trouvéehere. 


    org.springframework.cloud
    spring-cloud-starter-stream-rabbit
    1.2.1.RELEASE

La version la plus récente peut être trouvéehere.

Nous utiliseronsspring-cloud-config-monitor pour surveiller les changements de configuration et diffuser les événements en utilisant RabbitMQ comme transport.

Nous avons juste besoin de mettre à jourapplication.properties et de donner des détails à RabbitMQ: 

spring.rabbitmq.host=localhost
spring.rabbitmq.port=5672
spring.rabbitmq.username=guest
spring.rabbitmq.password=guest

4.3. Webhook GitHub

Tout est réglé maintenant. Une fois que le serveur est informé des modifications de configuration, il le diffuse sous forme de message à RabbitMQ. Le client écoute les messages et met à jour sa configuration lorsque l'événement de modification de configuration est transmis. Cependant, comment un serveur va maintenant à propos de la modification?

Nous devons configurer un GitHub Webhook. Allons sur GitHub et ouvrons notre référentiel contenant les propriétés de configuration. Maintenant, sélectionnonsSettings etWebhook. Cliquons sur le boutonAdd webhook.

L'URL de la charge utile est l'URL du point de terminaison de notre serveur de configuration‘/monitor'. Dans notre cas, l'URL ressemblera à ceci:

http://root:[.cf_email # [email protected] #_ IP: 8888 / moniteur]

Nous devons juste changerContent type dans le menu déroulant enapplication/json. Ensuite, laissezSecret vide et cliquez sur le boutonAdd webhook - après cela, nous sommes tous prêts.

5. Essai

Vérifions que toutes les applications sont en cours d’exécution. Si nous revenons en arrière et vérifions le client, il afficherauser.role comme‘Programmer' etuser.password comme «d3v3L»: 

$> curl http://localhost:8080/whoami/Mr_Pink
Hello Mr_Pink! You are a(n) Programmer and your password is 'd3v3L'.

Auparavant, nous devions utiliser le point de terminaison‘/refresh' pour recharger les modifications de configuration. Ouvrons le fichier de propriétés, changeonsuser.role enDeveloper et transmettons les modifications: 

user.role=Programmer

Si nous vérifions maintenant le client, nous verrons: 

$> curl http://localhost:8080/whoami/Mr_Pink
Hello Mr_Pink! You are a(n) Developer and your password is 'd3v3L'.

Le client de configuration a mis à jour sa configuration sans redémarrer et sans actualisation explicite presque simultanément. Nous pouvons revenir à GitHub et ouvrir le Webhook récemment créé. Tout en bas, il y a les livraisons récentes. Nous pouvons en sélectionner un en haut de la liste (en supposant qu'il s'agisse du premier changement - il n'y en aura qu'un seul de toute façon) et examiner le JSON envoyé au serveur de configuration.

Nous pouvons également vérifier les journaux de configuration et de serveur, et nous verrons les entrées suivantes: 

o.s.cloud.bus.event.RefreshListener: Received remote refresh request. Keys refreshed []

6. Conclusion

Dans cet article, nous avons utilisé le client et le serveur de configuration Spring Cloud existants et ajouté un point de terminaison d'actionneur pour actualiser la configuration du client. Nous avons ensuite utilisé Spring Cloud Bus pour diffuser les modifications de configuration et automatiser les mises à jour des clients. Nous avons également configuré GitHub Webhook et testé l’ensemble de la configuration.

Comme toujours, le code utilisé lors de la discussion se trouveover on GitHub.

Related