streamalism.org

1. Oversikt

I denne artikkelen skal vi se på det nye Spring Cloud Bus-prosjektet. Spring Cloud Bus bruker lettvektsmegler for å koble distribuerte systemnoder. Den primære bruken er å kringkaste konfigurasjonsendringer eller annen administrasjonsinformasjon. Vi kan tenke på det som en distribuert aktuator.

Prosjektet bruker AMQP-megler som transport, men Apache Kafka eller Redis kan brukes i stedet for RabbitMQ. Andre transporter støttes ikke ennå.

I løpet av denne opplæringen skal vi bruke RabbitMQ som vår viktigste transport - som vi naturlig nok allerede vil kjøre.

2. Forutsetninger

Før vi begynner, anbefales det at du allerede har fullført "Quick Intro to Spring Cloud Configuration". Vi skal ta en eksisterende cloud config-server og klient for å utvide dem og legge til automatiske varsler om konfigurasjonsendringer.

2.1. RabbitMQ

La oss starte med RabbitMQ, som vi anbefaler å kjøre som RabbitMQ som et dockerbilde. Dette er ganske enkelt å sette opp - for å få RabbitMQ til å kjøre lokalt, må vi installere Docker og kjøre følgende kommandoer når Docker er installert med hell:

docker pull rabbitmq: 3-management

Denne kommandoen trekker RabbitMQ-dockerbildet sammen med administrasjonsplugin installert og aktivert som standard.

Deretter kan vi kjøre RabbitMQ:

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

Når vi har utført kommandoen, kan vi gå til nettleseren og åpne // localhost: 15672, som viser påloggingsskjemaet for administrasjonskonsollen. Standard brukernavn er: 'gjest'; passord: 'gjest'. RabbitMQ vil også lytte på port 5672.

3. Legge til aktuator i Cloud Config Client

Vi bør ha cloud config server og cloud config client begge kjører. For å oppdatere konfigurasjonsendringer kreves en omstart av klienten hver gang - noe som ikke er ideelt.

La oss stoppe konfigureringsklienten og kommentere ConfigClient kontrollerklasse med @RefreshScope:

@SpringBootApplication @RestController @RefreshScope offentlig klasse SpringCloudConfigClientApplication {// Kode her ...}

Til slutt, la oss oppdatere pom.xml fil og legg til aktuator:

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

Den siste versjonen finner du her.

Som standard er alle følsomme sluttpunkter som er lagt til av aktuatoren sikret. Dette inkluderer '/forfriske' endepunkt. For enkelhets skyld vil vi slå av sikkerhet ved å oppdatere bootstrap.properties:

management.security.enabled = false

I tillegg, fra og med Spring Boot 2, blir ikke aktuatorendepunktene eksponert som standard. For å gjøre dem tilgjengelige for tilgang, må vi legge til dette i en application.yml:

ledelse: sluttpunkter: web: eksponering: inkluderer: "*"

La oss starte klienten først og oppdatere brukerrollen fra eksisterende ‘Utvikler’ til 'Programmerer' i eiendomsfilen på GitHub. Config-serveren vil vise oppdaterte verdier med en gang; klienten vil imidlertid ikke. For å få klienten til å se nye filer, trenger vi bare å sende en tom POST-forespørsel til '/forfriske' endepunkt, som ble lagt til av aktuatoren:

$> krøll -X POST // localhost: 8080 / aktuator / oppdatering

Vi får JSON-filen tilbake med oppdaterte egenskaper:

["user.role"]

Til slutt kan vi sjekke om brukerrollen ble oppdatert:

$> curl // localhost: 8080 / whoami / Mr_Pink Hei Mr_Pink! Du er (n) programmerer og passordet ditt er 'd3v3L'.

Brukerrollen ble oppdatert og ved å ringe '/forfriske' endepunkt. Klient oppdatert konfigurasjon uten å starte på nytt.

4. Spring Cloud Bus

Ved å bruke Actuator kan vi oppdatere klienter. I skymiljøet trenger vi imidlertid å gå til hver enkelt klient og laste opp konfigurasjonen ved å få tilgang til aktuatorens endepunkt.

For å løse dette problemet kan vi bruke Spring Cloud Bus.

4.1. Klient

Vi må oppdatere cloud config-klienten slik at den kan abonnere på RabbitMQ-utveksling:

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

Den siste versjonen finner du her.

For å fullføre konfigurasjonsklientendringene må vi legge til RabbitMQ-detaljer og aktivere skybussen i en application.yml fil:

--- vår: rabbitmq: vert: localhost port: 5672 brukernavn: gjestepassord: gjestesky: buss: aktivert: sann oppdatering: aktivert: sann 

Vær oppmerksom på at vi bruker standard brukernavn og passord. Dette må oppdateres for virkelige applikasjoner for produksjon. For denne opplæringen er dette greit.

Nå vil klienten ha et annet endepunkt ‘/ Buss-oppdatering’. Å ringe dette endepunktet vil føre til:

• få den siste konfigurasjonen fra konfigureringsserveren og oppdater konfigurasjonen sin kommentert av @RefreshScope
• send en melding til AMQP-sentralen med informasjon om oppdateringshendelsen
• alle abonnerte noder vil også oppdatere konfigurasjonen

På denne måten trenger vi ikke gå til individuelle noder og utløse konfigurasjonsoppdatering.

4.2. Server

Til slutt, la oss legge til to avhengigheter til konfigureringsserveren for å automatisere konfigurasjonsendringene fullt ut.

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

Den siste versjonen finner du her.

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

Den siste versjonen finner du her.

Vi vil bruke vår-sky-konfigurasjonsmonitor for å overvåke konfigurasjonsendringer og kringkaste hendelser ved å bruke RabbitMQ som transport.

Vi trenger bare å oppdatere application.properties og gi RabbitMQ detaljer:

spring.rabbitmq.host = localhost spring.rabbitmq.port = 5672 spring.rabbitmq.username = gjest vår.rabbitmq.password = gjest

4.3. GitHub Webhook

Alt er satt nå. Når serveren får beskjed om konfigurasjonsendringer, vil den kringkaste dette som en melding til RabbitMQ. Kunden vil lytte til meldinger og oppdatere konfigurasjonen når konfigurasjonsendringshendelsen overføres. Men hvordan en server vil nå om endringen?

Vi må konfigurere en GitHub Webhook. La oss gå til GitHub og åpne konfigurasjonsegenskapene til lagringsplass. La oss nå velge Innstillinger og Webhook. La oss klikke på Legg til webhook knapp.

Nyttelast-URL er URL-adressen til konfigureringsserveren vår '/Observere' endepunkt. I vårt tilfelle vil URL-en være omtrent slik:

// root: [email protected] _IP: 8888 / monitor

Vi trenger bare å endre oss Innholdstype i rullegardinmenyen til søknad / json. Gå igjen Hemmelig tom og klikk på Legg til webhook -knappen - etter det er vi klare.

5. Testing

La oss sørge for at alle applikasjoner kjører. Hvis vi går tilbake og sjekker klienten, vil det vises user.role som 'Programmerer' og bruker passord som 'd3v3L‘:

$> curl // localhost: 8080 / whoami / Mr_Pink Hei Mr_Pink! Du er (n) programmerer og passordet ditt er 'd3v3L'.

Tidligere måtte vi bruke '/forfriske' endepunkt for å laste inn konfigurasjonsendringer. La oss åpne eiendomsfilen, endre user.role tilbake til Utvikler og skyv endringene:

user.role = Programmerer

Hvis vi sjekker klienten nå, ser vi:

$> curl // localhost: 8080 / whoami / Mr_Pink Hei Mr_Pink! Du er (n) utvikler og passordet ditt er 'd3v3L'.

Config-klienten oppdaterte konfigurasjonen uten å starte på nytt og uten eksplisitt oppdatering nesten samtidig. Vi kan gå tilbake til GitHub og åpne den nylig opprettede Webhook. Helt nederst er det nylige leveranser. Vi kan velge en øverst på listen (forutsatt at dette var den første endringen - det vil bare være en uansett) og undersøke JSON som er sendt til konfigureringsserveren.

Vi kan også sjekke konfigurasjons- og serverlogger, og vi vil se oppføringer:

o.s.cloud.bus.event.RefreshListener: Mottatt forespørsel om ekstern oppdatering. Nøklene oppdateres []

6. Konklusjon

I denne artikkelen tok vi eksisterende vårskyskonfigurasjonsserver og klient og la til aktuatorendepunkt for å oppdatere klientkonfigurasjonen. Deretter brukte vi Spring Cloud Bus til å kringkaste konfigurasjonsendringer og automatisere klientoppdateringer. Vi konfigurerte også GitHub Webhook og testet hele oppsettet.

Som alltid kan koden som ble brukt under diskusjonen finnes på GitHub.