5 Minuten Lesezeit (997 Worte)

Let's commit! Dataflows versionieren mit der NiFi Registry

Donnerstag, 28. April 2022

Nutzen Sie bereits Apache NiFi oder planen Sie es? Dann sollten Sie sich das zugehörige Subprojekt NiFi Registry anschauen! Mit der Apache NiFi Registry können Sie Ihre Dataflows schnell und einfach versionieren, sichern und exportieren.

In diesem Blogbeitrag wollen wir auf die Besonderheiten der Registry, die allgemeine Vorgehensweise und natürlich die in der Praxis auftretenden Fallstricke und Tücken aufmerksam machen.

Ursprung und Ziele

In Apache NiFi war es schon lange möglich, existierende Flows als Templates zu exportieren. Allerdings fehlte die Möglichkeit, die Flows ordentlich zu versionieren. Es war sehr umständlich, zu älteren Versionen des Dataflows zurückzukehren. Erstmals wurde der Wunsch nach einem „Flow Management"-System 2015 in einem Feature Proposal geäußert. Die Idee wurde im Laufe der nächsten drei Jahre konkretisiert und am 01. Januar 2018 die erste Version 0.1.0 veröffentlicht. Seit 2021 die Apache NiFi Version 1.15.0 erschienen ist und alle Subprojekte in einer Codebase vereint wurden, ist die Registry ebenfalls in der Version 1.15.0 verfügbar.

Mittlerweile hat sich viel in der Entwicklung getan und die Registry ist auch bei den großen Distributoren (Cloudera) fester Bestandteil einer Dataflow-Umgebung.

Und wie funktioniert es?

Um eine Registry in NiFi zu nutzen, muss diese zunächst in der NiFi UI angelegt werden. Dies geschieht über den Menüpunkt Registry Clients in den Controller Settings.

Abbildung 1: Hinzufügen einer Registry

Es lassen sich drei Werte eintragen:

Der Name der Registry
Die URL
Eine Beschreibung

Während die Registry im Browser nur über den Pfad "/nifi-registry" erreichbar ist, muss dieser beim Anlegen zwingend entfernt werden.

Browser: https://registry:18443/nifi-registry
NiFi: https://registry:18443

Im Übrigen können in NiFi mehrere "Registries" hinterlegt werden. Dadurch ist es möglich, dass ein NiFi Cluster in der Produktionsumgebung auf die Registry der Testumgebung zugreifen kann, um z.B. eine neue Version eines Dataflows zu "deployen". Weiterhin ist es möglich, dass sich mehrere NiFi Cluster eine Registry teilen.

Alles im Eimer?

Die Registry kennt zwei wichtige Begrifflichkeiten:

Flow: Eine NiFi Prozessgruppe, die im Registry versioniert wird.
Bucket: In einem Bucket werden alle zusammengehörigen Flows gespeichert.

Dies bedeutet, dass zunächst ein Bucket in der Registry angelegt werden muss, bevor wir dort Flows ablegen können.

Ein Bucket benötigt immer einen eindeutigen Namen und kann durch eine optionale Beschreibung ergänzt werden. Dazu gibt es die Möglichkeit einen Bucket als "public" zu markieren, der dann für jeden zugänglich ist.

Abbildung 2: Anlegen eines neuen Buckets

Lassen Sie sich nicht von den roten Buttons täuschen (Abb. 2). Dies liegt nicht an einer falschen Eingabe, sondern ist dem Design der Registry UI geschuldet.

Nachdem ein Bucket angelegt wurde, können Prozessgruppen versioniert werden. Dies geht in NiFi über einen Rechtsklick auf die gewünschte Prozessgruppe und die neue Option Version 🠒 Start version control. Im erscheinenden Popup-Fenster erfolgt nun die initiale Konfiguration für den Dataflow.

Auch hier gilt, dass der Flow Name in dem Bucket eindeutig sein muss. In der Praxis hat es sich bewiesen, dass hierbei der gleiche Name, wie die betreffende Prozessgruppe sinnvoll ist. Zusätzlich sollte eine sprechende "Flow Description" eingefügt werden. Nach dem Klick auf "Save" erscheint über der Prozessgruppe ein grüner Haken. Dies bedeutet, dass die Prozessgruppe mit der Registry synchron ist und es keine neuen Änderungen oder Versionen gibt.

Werden nun Änderungen in der Prozessgruppe vorgenommen, so wird von "Local changes" gesprochen. Was genau verändert wurde, zeigt die Option "Show Local Changes" an.

Abbildung 3: Speichern eines ersten Data Flows

Leider fehlt aktuell die Möglichkeit nur einzelne Änderungen zu "committen". Es werden immer alle oder keine Änderungen (revert) bestätigt. Von einem "revert" wird gesprochen, wenn alle Änderungen verworfen werden und der Dataflow dadurch auf den Stand der letzten Version zurückgesetzt wird. Neue Änderungen können durch einen "Commit" in einer neuen Version des Dataflows manifestiert werden.

Bei einem "Commit" gibt es die Option eine "Commit Message", bzw. ein "Version Comment" zu hinterlegen. Dies ist unbedingt zu empfehlen, um später nachvollziehen zu können, welche Änderungen in welcher Version getätigt wurden.

Ist eine Prozessgruppe synchron mit der Registry, lässt sich auch beliebig zwischen den jeweiligen Versionen wechseln. Hierbei muss keine Reihenfolge beachtet werden. Es kann problemlos von Version 1 auf Version 8 gewechselt werden.

Flowversion, was steckt drin?

Einer der häufigsten Irrtümer ist der nahe liegende Gedanke, dass eine Flowversion alle Inhalte enthält, um den Dataflow konsistent auf einem anderen Cluster zu starten.

Dies ist allerdings ein Trugschluss, denn in der NiFi Registry wird nur die sogenannte "Flow Definition" gespeichert. Vereinfacht gesagt sind dies alle Komponenten, die auf den ersten Blick in der NiFi UI zu sehen sind. Dazu gehören:

Prozessoren
Weitere Prozessgruppen
Funnels
Connection
Input / Output Ports
Labels

Controller Services und deren Konfiguration werden nicht gespeichert. Das bedeutet in der Praxis: Wird die Version einer Prozessgruppe gewechselt und der betreffende Controller Service existiert nicht mehr, so wird nicht automatisch ein neuer angelegt. Der betreffende Prozessor ist dann „invalid" und der Dataflow lässt sich nicht direkt starten.

Obacht beim Versionieren

Neben dem Fakt, dass doch "nur" die Flow Definition gespeichert wird, gibt es weitere Fallstricke, die es zu beachten gilt.

Ein typischer Fall ist die sogenannte "nested version control". Dies bedeutet eine Prozessgruppe ist bereits versioniert, eine Kindprozessgruppe wird dann zusätzlich in der Registry hinterlegt. Dieses Vorgehen resultiert nicht direkt in einem Fehler, ist allerdings sehr unschön. Wird beispielsweise die Version der Kindprozessgruppe gewechselt, ist dies automatisch ein "local change" der übergeordneten Prozessgruppe.

Solch ein Vorgehen gilt es zu vermeiden.

Fazit

Trotz der einen oder anderen Hürde, ist der Einsatz der NiFi Registry zu empfehlen. Die Möglichkeit Dataflows überhaupt versionieren zu können, bietet nicht nur Entwicklern mehr Optionen, sondern ermöglicht einen sicheren und konsistenten Rollout-Prozess der Dataflows.

Die Integration der Registry in Apache NiFi ist einfach und die anschließende Versionierung der Dataflows ist intuitiv.

Haben Sie weitere Fragen zur NiFi Registry, oder möchten eine Umgebung aufsetzen? Sprechen Sie uns gerne an!