Automatisering av flow-levering i Apache NiFi

Hei alle sammen!

Automatisering av flow-levering i Apache NiFi

Oppgaven er som fÞlger - det finnes et flow, illustrert pÄ bildet ovenfor, som mÄ distribueres pÄ N servere med Apache NiFi. 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 dokumentasjonen og det er viktig Ă„ ikke glemme Ă„ konfigurere NiFi-instansen for Ă„ tillate S2S, se here.

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:

  1. Push. Dataene sendes fra klientinstansen ved hjelp av Remote Process Group (RPG). PĂ„ serverinstansen tas dataene imot via Input Port
  2. 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 den offisielle dokumentasjonen. 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:

  1. det tar mer tid Ä oppdatere flowet. Man mÄ logge inn pÄ alle serverne
  2. det oppstÄr feil ved oppdatering av malene. Her ble det oppdatert, men glemte her
  3. 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:

  1. Bruke MiNiFi i stedet for NiFi
  2. NiFi CLI
  3. NiPyAPI

Bruk av MiNiFi

Apache MiNiFy — 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 denne artikkelen 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:

  1. I minifi finnes ikke alle prosessorene fra nifi.
  2. 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 beskrivelsen 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 herfrÄ.

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:

Automatisering av flow-levering i Apache NiFi

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.

Automatisering av flow-levering i Apache NiFi

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. here.

Automatisering av flow-levering i Apache NiFi
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.

Automatisering av flow-levering i Apache NiFi

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. Dokumentasjonsiden inneholder nĂždvendig informasjon for Ă„ jobbe med biblioteket. Quick start er beskrevet i. prosjekt 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 here.

Vi koblar registry til instansen nifi ved hjelp av

nipyapi.versioning.create_registry_client

I 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_clients

Vi finn bucket for vidare sĂžk etter flow i bĂžtta

nipyapi.versioning.get_registry_bucket

Etter Ă„ ha funne bucket, leitar vi etter flow

nipyapi.versioning.get_flow_in_bucket

Vidare 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_groups

og 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_ver

Deployer process group:

nipyapi.versioning.deploy_flow_version

KjĂžrer prosessorar:

nipyapi.canvas.schedule_process_group

I 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_transmission

SĂ„, 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 — send en melding!

Kilde: habr.com

KjĂžp pĂ„litelig hosting for nettsteder med DDoS-beskyttelse, VPS VDS-servere đŸ”„ KjĂžp pĂ„litelig hosting for nettsteder med DDoS-beskyttelse, VPS VDS-servere | ProHoster