streamalism.org

1. Overzicht

In dit artikel gaan we kijken naar het nieuwe Spring Cloud Bus-project. Spring Cloud Bus gebruikt lichtgewicht message broker om gedistribueerde systeemknooppunten te koppelen. Het primaire gebruik is om configuratiewijzigingen of andere managementinformatie te verzenden. We kunnen het zien als een gedistribueerde actuator.

Het project gebruikt AMQP-broker als transport, maar Apache Kafka of Redis kan worden gebruikt in plaats van RabbitMQ. Andere transporten worden nog niet ondersteund.

In de loop van deze tutorial gaan we RabbitMQ gebruiken als ons belangrijkste transport - dat we natuurlijk al draaiende zullen hebben.

2. Vereisten

Voordat we beginnen, is het aan te raden om de "Quick Intro to Spring Cloud Configuration" al te hebben voltooid. We gaan een bestaande cloudconfiguratieserver en -client gebruiken om ze uit te breiden en automatische meldingen over configuratiewijzigingen toe te voegen.

2.1. RabbitMQ

Laten we beginnen met RabbitMQ, dat we aanbevelen om als RabbitMQ uit te voeren als een docker-image. Dit is vrij eenvoudig in te stellen - om RabbitMQ lokaal te laten draaien, moeten we Docker installeren en de volgende opdrachten uitvoeren zodra Docker met succes is geïnstalleerd:

docker pull rabbitmq: 3-beheer

Deze opdracht haalt de RabbitMQ docker-afbeelding samen met de beheerplug-in die standaard is geïnstalleerd en ingeschakeld.

Vervolgens kunnen we RabbitMQ uitvoeren:

havenarbeider run -d --hostnaam mijn-konijn --naam een-konijn -p 15672: 15672 -p 5672: 5672 konijnmq: 3-beheer

Nadat we de opdracht hebben uitgevoerd, kunnen we naar de webbrowser gaan en // localhost: 15672 openen, waar het inlogformulier van de beheerconsole wordt weergegeven. De standaard gebruikersnaam is: 'gast'; wachtwoord: 'gast'. RabbitMQ zal ook luisteren op poort 5672.

3. Actuator toevoegen aan Cloud Config Client

We zouden zowel de cloudconfiguratieserver als de cloudconfiguratieclient moeten hebben. Om configuratiewijzigingen te vernieuwen, is elke keer een herstart van de client vereist - wat niet ideaal is.

Laten we de configuratieclient stoppen en annoteren ConfigClient controller klasse met @RefreshScope:

@SpringBootApplication @RestController @RefreshScope openbare klasse SpringCloudConfigClientApplication {// Code hier ...}

Laten we tot slot het pom.xml bestand en voeg Actuator toe:

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

De laatste versie vind je hier.

Standaard zijn alle gevoelige eindpunten die door de actuator worden toegevoegd, beveiligd. Dit bevat ‘/ Vernieuwen ' eindpunt. Voor de eenvoud zullen we de beveiliging uitschakelen door bij te werken bootstrap.properties:

management.security.enabled = false

Bovendien worden vanaf Spring Boot 2 actuator-eindpunten niet standaard weergegeven. Om ze beschikbaar te maken voor toegang, moeten we dit toevoegen in een application.yml:

management: endpoints: web: exposure: include: "*"

Laten we eerst de client starten en de gebruikersrol bijwerken vanuit de bestaande 'Ontwikkelaar' naar 'Programmeur' in het eigenschappenbestand op GitHub. De configuratieserver toont direct bijgewerkte waarden; de klant zal dat echter niet doen. Om de klant nieuwe bestanden te laten zien, hoeven we alleen maar een leeg POST-verzoek te sturen naar ‘/ Vernieuwen ' eindpunt, dat is toegevoegd door actuator:

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

We krijgen het JSON-bestand terug met bijgewerkte eigenschappen:

[ "Gebruikersrol" ]

Ten slotte kunnen we controleren of de gebruikersrol is bijgewerkt:

$> curl // localhost: 8080 / whoami / Mr_Pink Hallo Mr_Pink! U bent een (n) programmeur en uw wachtwoord is 'd3v3L'.

De gebruikersrol is met succes bijgewerkt en door te bellen ‘/ Vernieuwen ' eindpunt. Client heeft de configuratie bijgewerkt zonder opnieuw op te starten.

4. Spring Cloud Bus

Door Actuator te gebruiken, kunnen we klanten vernieuwen. In de cloudomgeving zouden we echter naar elke afzonderlijke client moeten gaan en de configuratie opnieuw moeten laden door toegang te krijgen tot het actuator-eindpunt.

Om dit probleem op te lossen, kunnen we Spring Cloud Bus gebruiken.

4.1. Cliënt

We moeten de cloudconfiguratieclient bijwerken zodat deze zich kan abonneren op RabbitMQ-uitwisseling:

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

De laatste versie vind je hier.

Om wijzigingen in de configuratieclient te voltooien, moeten we RabbitMQ-details toevoegen en cloudbus inschakelen in een application.yml het dossier:

--- spring: rabbitmq: host: localhost poort: 5672 gebruikersnaam: guest wachtwoord: guest cloud: bus: ingeschakeld: waar vernieuwing: ingeschakeld: waar 

Houd er rekening mee dat we de standaard gebruikersnaam en wachtwoord gebruiken. Dit moet worden bijgewerkt voor echte productietoepassingen. Voor deze tutorial is dit prima.

Nu heeft de client een ander eindpunt ‘/ Bus-refresh '. Het aanroepen van dit eindpunt zal leiden tot:

• haal de laatste configuratie op van de configuratieserver en werk de configuratie bij, geannoteerd door @RefreshScope
• stuur een bericht naar de AMQP-uitwisseling met informatie over de vernieuwingsgebeurtenis
• alle aangemelde knooppunten zullen ook hun configuratie bijwerken

Op deze manier hoeven we niet naar individuele knooppunten te gaan en de configuratie-update te activeren.

4.2. Server

Laten we tot slot twee afhankelijkheden toevoegen aan de configuratieserver om configuratiewijzigingen volledig te automatiseren.

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

De laatste versie vind je hier.

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

De meest recente versie vind je hier.

We zullen gebruiken spring-cloud-config-monitor om configuratiewijzigingen te volgen en gebeurtenissen uit te zenden met RabbitMQ als transport.

We hoeven alleen maar te updaten application.properties en geef RabbitMQ details:

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

4.3. GitHub-webhook

Alles is nu ingesteld. Zodra de server op de hoogte wordt gesteld van configuratiewijzigingen, zal deze dit als een bericht naar RabbitMQ verzenden. De client zal naar berichten luisteren en de configuratie bijwerken wanneer een configuratiewijziginggebeurtenis wordt verzonden. Maar hoe gaat een server nu met de wijziging om?

We moeten een GitHub-webhook configureren. Laten we naar GitHub gaan en onze opslagplaats met configuratie-eigenschappen openen. Laten we nu selecteren Instellingen en Webhook. Laten we verder klikken Voeg webhook toe knop.

Payload-URL is de URL voor onze configuratieserver '/monitor' eindpunt. In ons geval zal de URL er ongeveer zo uitzien:

// root: [e-mail beveiligd] _IP: 8888 / monitor

We moeten gewoon veranderen Inhoudstype in het vervolgkeuzemenu naar applicatie / json. Ga vervolgens alsjeblieft weg Geheim leeg en klik op Voeg webhook toe knop - daarna zijn we helemaal klaar.

5. Testen

Laten we ervoor zorgen dat alle applicaties actief zijn. Als we teruggaan en de klant controleren, wordt dit weergegeven Gebruikersrol net zo 'Programmeur' en gebruikerswachtwoord net zo 'd3v3L‘:

$> curl // localhost: 8080 / whoami / Mr_Pink Hallo Mr_Pink! U bent een (n) programmeur en uw wachtwoord is 'd3v3L'.

Eerder moesten we gebruiken ‘/ Vernieuwen ' eindpunt om configuratiewijzigingen opnieuw te laden. Laten we het eigenschappenbestand openen, wijzigen Gebruikersrol terug naar Ontwikkelaar en druk op de wijzigingen:

user.role = Programmeur

Als we de klant nu controleren, zien we:

$> curl // localhost: 8080 / whoami / Mr_Pink Hallo Mr_Pink! U bent een (n) ontwikkelaar en uw wachtwoord is 'd3v3L'.

De Config-client heeft de configuratie bijna gelijktijdig bijgewerkt zonder opnieuw te starten en zonder expliciete vernieuwing. We kunnen teruggaan naar GitHub en de onlangs gemaakte webhook openen. Helemaal onderaan staan ​​recente leveringen. We kunnen er een selecteren bovenaan de lijst (ervan uitgaande dat dit de eerste wijziging was - er zal er sowieso maar één zijn) en JSON onderzoeken die naar de configuratieserver is verzonden.

We kunnen ook configuratie- en serverlogboeken controleren, en we zullen vermeldingen zien:

o.s.cloud.bus.event.RefreshListener: Op afstand vernieuwingsverzoek ontvangen. Sleutels vernieuwd []

6. Conclusie

In dit artikel hebben we de bestaande springcloud-configuratieserver en -client genomen en het actuator-eindpunt toegevoegd om de clientconfiguratie te vernieuwen. Vervolgens hebben we Spring Cloud Bus gebruikt om configuratiewijzigingen uit te zenden en clientupdates te automatiseren. We hebben ook GitHub Webhook geconfigureerd en de hele installatie getest.

Zoals altijd is de code die tijdens de discussie is gebruikt, te vinden op GitHub.