Hei alle sammen!

Oppgaven er som fÞlger - det finnes et flow, illustrert pÄ bildet ovenfor, som mÄ distribueres pÄ N servere med . Flow er test- slik at en fil genereres og sendes til en annen NiFi-instans. Datatransfer skjer via NiFi Site to Site-protokollen.
NiFi Site to Site (S2S) er en sikker, lett konfigurerbar metode for dataoverfĂžring mellom NiFi-instansene. Hvordan S2S fungerer kan ses i og det er viktig Ă„ ikke glemme Ă„ konfigurere NiFi-instansen for Ă„ tillate S2S, se .
I tilfeller der det er snakk om dataoverfĂžring via S2S, kalles den ene instansen klient og den andre server. Klienten sender data, serveren mottar. Det finnes to metoder for Ă„ konfigurere dataoverfĂžring mellom dem:
- Push. Dataene sendes fra klientinstansen ved hjelp av Remote Process Group (RPG). PĂ„ serverinstansen tas dataene imot via Input Port
- Dra. Serveren mottar data ved hjelp av RPG, klienten sender med Output port.
Flowet for distribusjonen lagres i Apache Registry.
Apache NiFi Registry er et delprosjekt av Apache NiFi, som utgjĂžr et verktĂžy for lagring av flows og versjonskontroll. En slags GIT. Informasjon om installasjon, konfigurasjon og bruk av registry kan finnes i . Flowet for lagring samles i en process group og lagres i denne formen i registry. Vi kommer tilbake til dette senere i artikkelen.
I starten, nÄr N er et lite tall, leveres og oppdateres flowet manuelt pÄ en rimelig tid.
Men med Ăžkningen av N blir problemene flere:
- det tar mer tid Ä oppdatere flowet. Man mÄ logge inn pÄ alle serverne
- det oppstÄr feil ved oppdatering av malene. Her ble det oppdatert, men glemte her
- menneskelig feil ved utfĂžrelse av mange ensartede operasjoner
Alt dette fÞrer oss til konklusjonen om at prosessen mÄ automatiseres. Jeg har forsÞkt fÞlgende lÞsninger pÄ dette problemet:
- Bruke MiNiFi i stedet for NiFi
- NiFi CLI
- NiPyAPI
Bruk av MiNiFi
â delprosjekt Apache NiFi. MiNiFy â en kompakt agent som bruker de samme prosessorene som NiFi, og gjĂžr det mulig Ă„ lage de samme flowene som i NiFi. Agentens lettvektsdesign oppnĂ„s delvis ved at MiNiFy ikke har et grafisk grensesnitt for konfigurering av flow. FravĂŠret av et grafisk grensesnitt i MiNiFy betyr at man mĂ„ lĂžse problemet med distribusjon av flow til minifi. Siden MiNiFy aktivt brukes i IOT, er det mange komponenter, og prosessen med Ă„ levere flow til slutt-instansene av minifi mĂ„ automatiseres. En kjent oppgave, eller hva?
En lĂžsning pĂ„ denne oppgaven hjelper et annet delprosjekt â MiNiFi C2 Server. Dette produktet er ment Ă„ vĂŠre et sentralt punkt i arkitekturen for utrulling av konfigurasjoner. Hvordan man konfigurerer miljĂžet er beskrevet i pĂ„ HabrĂ©, og informasjonen er tilstrekkelig for Ă„ lĂžse den angitte oppgaven. MiNiFi sammen med C2-serveren oppdaterer automatisk konfigurasjonen sin. Den eneste ulempe med denne tilnĂŠrmingen er at man mĂ„ lage maler pĂ„ C2 Server; en enkel commit til registry er ikke tilstrekkelig.
Alternativet beskrevet i artikkelen ovenfor er fungerende og ikke vanskelig Ä implementere, men man mÄ ikke glemme fÞlgende:
- I minifi finnes ikke alle prosessorene fra nifi.
- Versjoner av prosessorene i Minifi er bak i forhold til versjonene av prosessorene i NiFi.
Ved publisering var den nyeste versjonen av NiFi â 1.9.2. Versjonen av prosessorene i den nyeste versjonen av MiNiFi â 1.7.0. Prosessorer kan legges til i MiNiFi, men pĂ„ grunn av versjonsforskjellen mellom prosessorene NiFi og MiNiFi kan det hende at det ikke fungerer.
NiFi CLI
IfÞlge av verktÞyet pÄ den offisielle nettsiden, er dette et verktÞy for automatisering av interaksjonen mellom NiFi og NiFi Registry innen levering av flow eller prosesshÄndtering. For Ä begynne Ä bruke dette verktÞyet mÄ det lastes ned .
Vi kjĂžrer verktĂžyet
.\/bin\/cli.sh
_ ___ _
Apache (_) .' ..](_) ,
_ .--. __ _| |_ __ )
[ `.-. | [ |'-| |-'[ | \/
| | | | | | | | | | ' '
[___||__][___][___] [___]', ,'
`'
CLI v1.9.2
Type 'help' to see a list of available commands, use tab to auto-complete.
For Ä laste inn den nÞdvendige flow fra registry, mÄ vi vite identifikatorene for bÞtta (bucket identifier) og selve flowen (flow identifier). Disse dataene kan man fÄ enten via cli eller i webgrensesnittet til NiFi registry. I webgrensesnittet ser det slik ut:

Med CLI gjĂžres det slik:
#> registry list-buckets -u http://nifi-registry:18080
# Name Id Description
- -------------- ------------------------------------ -----------
1 test_bucket 709d387a-9ce9-4535-8546-3621efe38e96 (empty)
#> registry list-flows -b 709d387a-9ce9-4535-8546-3621efe38e96 -u http://nifi-registry:18080
# Name Id Description
- ------------ ------------------------------------ -----------
1 test_flow d27af00a-5b47-4910-89cd-9c664cd91e85
Vi kjĂžrer import av prosessgruppe fra registry:
#> nifi pg-import -b 709d387a-9ce9-4535-8546-3621efe38e96 -f d27af00a-5b47-4910-89cd-9c664cd91e85 -fv 1 -u http://nifi:8080
7f522a13-016e-1000-e504-d5b15587f2f3
Et viktig punkt â enhver instans av nifi kan angis som vert for prosessgruppen vi legger til.
Prosessgruppen er lagt til med stoppede prosessorer, mÄ starte dem.
#> nifi pg-start -pgid 7f522a13-016e-1000-e504-d5b15587f2f3 -u http://nifi:8080
Flott, prosessorene har startet. Men ifÞlge oppgavens krav mÄ NiFi-instansene sende data til andre instanser. La oss anta at vi har valgt Push-metoden for datatransport. For Ä organisere datatransfer, mÄ vi aktivere overfÞring av data pÄ den tilfÞjede Remote Process Group (RPG), som allerede er en del av vÄrt flow.

Jeg fant ingen mĂ„te Ă„ aktivere datatransfer pĂ„ i dokumentasjonen, CLI eller andre kilder. Hvis du vet hvordan dette gjĂžres â vennligst skriv det i kommentarfeltet.
Siden vi har bash og er klare til Ă„ gĂ„ hele veien â la oss finne en lĂžsning! Vi kan bruke NiFi API for Ă„ lĂžse dette problemet. Vi bruker fĂžlgende metode, ID tar vi fra eksemplene ovenfor (i vĂ„rt tilfelle er det 7f522a13-016e-1000-e504-d5b15587f2f3). Beskrivelse av metodene i NiFi API. .

I body mÄ vi sende JSON av fÞlgende format:
{
"revision": {
"clientId": "value",
"version": 0,
"lastModifier": "value"
},
"state": "value",
"disconnectedNodeAcknowledged": true
}
Parametrene som mÄ fylles ut for at det skal "fungere":
state â status for datatransport. Tilgjengelig er TRANSMITTING for Ă„ aktivere datatransport, STOPPED for Ă„ deaktivere.
version â versjon av prosessoren
versjon som standard vil vĂŠre 0 ved opprettelse, men disse parameterne kan hentes ved Ă„ bruke metoden.

For de som liker bash-skript kan denne metoden virke nyttig, men jeg synes det er vanskelig â bash-skript er ikke min favoritt. Den neste metoden er mer interessant og mer praktisk, etter min mening.
NiPyAPI
NiPyAPI â et bibliotek for Python for interaksjon med NiFi-instanser. inneholder nĂždvendig informasjon for Ă„ jobbe med biblioteket. Quick start er beskrevet i. pĂ„ github.
VĂ„r skript for distribusjon av konfigureringen â et program pĂ„ Python. La oss gĂ„ videre til koding.
Vi konfigurerer innstillingene for videre arbeid. Vi trenger fĂžlgende parametere:
nipyapi.config.nifi_config.host = 'http://nifi:8080/nifi-api' #stien til nifi-api instansen der vi distribuerer prosessgruppen
nipyapi.config.registry_config.host = 'http://nifi-registry:18080/nifi-registry-api' #stien til nifi-registry-api registry
nipyapi.config.registry_name = 'MyBeutifulRegistry' #navn pÄ registry, som det vil bli kalt i NiFi-instansen
nipyapi.config.bucket_name = 'BucketName' #navn pÄ bucket som vi henter flow fra
nipyapi.config.flow_name = 'FlowName' #navn pÄ flow vi henter.
Vidare vil eg setje inn namna pÄ metodane til dette biblioteket som er beskreven .
Vi koblar registry til instansen nifi ved hjelp av
nipyapi.versioning.create_registry_clientI dette steget kan ein ogsÄ legge til ei sjekk for Ä sjÄ om registry allereie er lagt til instansen. For dette kan ein bruke metoden
nipyapi.versioning.list_registry_clientsVi finn bucket for vidare sĂžk etter flow i bĂžtta
nipyapi.versioning.get_registry_bucketEtter Ă„ ha funne bucket, leitar vi etter flow
nipyapi.versioning.get_flow_in_bucketVidare er det viktig Ă„ forstĂ„ om denne process group allereie er lagt til. Process group plasserast etter koordinatar, og det kan oppstĂ„ situasjoner der ein komponent ligg pĂ„ toppen av ein annan. Eg har testet dette, og det kan skje đ For Ă„ fĂ„ tak i alle lagde process groups, brukar vi metoden
nipyapi.canvas.list_all_process_groupsog vidare kan vi leita, til dĂžmes etter namn.
Eg vil ikkje beskrive prosessen for oppdatering av mal, berre seie at dersom det blir lagt til prosessorar i den nye versjonen av malen, sĂ„ er det ikkje problem med at meldingar hoper seg opp i kĂžane. Men dersom prosessorar blir fjerna, kan det oppstĂ„ problem (nifi tillĂšt ikkje Ă„ fjerne prosessorar dersom det har hopa seg opp meldingar foran). Dersom du er interessert i korleis eg lĂžyste dette problemet â send meg ein melding, skal vi snakke om dette. Kontaktinformasjon pĂ„ slutten av artikkelen. La oss gĂ„ vidare til steget for Ă„ legge til process group.
Under feilsÞking av skriptet stÞtte eg pÄ ei lÞysing som ikkje alltid hentar den nyaste versjonen av flow, sÄ eg anbefaler Ä fÞrst avklare denne versjonen:
nipyapi.versioning.get_latest_flow_verDeployer process group:
nipyapi.versioning.deploy_flow_versionKjĂžrer prosessorar:
nipyapi.canvas.schedule_process_groupI blokka om CLI stod det at i remote process group vert dataoverfĂžring ikkje aktivert automatisk? NĂ„r eg implementerte skriptet, stĂžtte eg ogsĂ„ pĂ„ dette problemet. PĂ„ det tidspunktet fekk eg ikkje til Ă„ aktivere dataoverfĂžring ved hjelp av API, sĂ„ eg bestemte meg for Ă„ skrive til utviklaren av biblioteket NiPyAPI og spĂžrje om rĂ„d/hjelp. Utviklaren svarte meg, vi diskuterte problemet, og han sa han trengte tid til Ă„ âsjĂ„ pĂ„ nokoâ. Og sĂ„, etter nokre dagar, kjem det eit brev der han skriver ei funksjon i Python som lĂžyste problemet mitt med oppstart!!! PĂ„ det tidspunket var versjonen av NiPyAPI 0.13.3, og der var det sjĂžlvsagt ingenting slikt. Men i den nye versjonen 0.14.0 som kom ut for ikkje lenge sidan, var denne funksjonen allereie inkludert i biblioteket. Her kjem,
nipyapi.canvas.set_remote_process_group_transmissionSĂ„, ved hjelp av NiPyAPI-biblioteket har vi koblet til registeret, implementert flowet, og til og med startet prosessorene og dataoverfĂžringen. Videre kan vi finpusse koden, legge til ulike sjekker, logging og alt det der. Men det er en helt annen historie.
Blant de alternativene jeg har vurdert for automatisering, virker det siste som det mest praktiske. For det fÞrste er det likevel kode i python, hvor man kan integrere hjelpeprogrammer og dra nytte av alle fordelene med programmeringssprÄket. For det andre utvikles NiPyAPI aktivt, og hvis det oppstÄr problemer, kan man kontakte utvikleren. For det tredje er NiPyAPI et mer fleksibelt verktÞy for Ä samhandle med NiFi nÄr man lÞser komplekse oppgaver. For eksempel i Ä bestemme om kÞene for meldinger i flowet er tomme nÄ og om man kan oppdatere prosessgruppen.
Det var alt. Jeg har beskrevet tre tilnĂŠrminger til automatisering av leveranser av flow til NiFi, hvor man kan mĂžte fallgruver utvikleren kan stĂžte pĂ„, og gitt fungerende kode for Ă„ automatisere leveransen. Hvis dette ogsĂ„ interesserer deg, slik det gjĂžr meg â
Kilde: habr.com
