Hybrid Cloud Tutorial

Einführung

Sowohl im eigenen Haus bzw. Rechenzentrum als auch in der Cloud besteht der Bedarf der Integration verschiedener Systeme und Services.

Um Systeme im eigenen Haus zu integrieren, bietet Virtimo das Produkt INUBIT an. Zur Anbindung diverse Systeme und Services aus der Cloud bzw. dem Internet steht IGUASU zur Verfügung.

Es bietet sich nun an diese beiden Welten miteinander zu verbinden. Genau zu diesem Zweck gibt es die Hybrid Cloud Verbindung. Hierüber werden INUBIT und IGUASU auf eine innovative, sichere und einfach zu verwendende Weise verbunden.

Hierzu gibt es IGUASU-Connectoren in INUBIT und INUBIT-Prozessoren in IGUASU.

Client-to-Cloud initiierte Duplex-Verbindung

Um eine möglichst hohe Sicherheit zu gewährleisten und gleichzeitig den Konfigurationsaufwand des heimischen Netzes in Bezug auf Firewalls und Port-Freischaltungen zu minimieren, wird die Verbindung zwischen On-Prem und Cloud immer von dem On-Prem System - also INUBIT - hergestellt.

Die Verbindung in Form eines Secure Web Sockets wird dann ständig aufrechterhalten. Sollte sie einmal abbrechen, wird sie sofort von der On-Prem Seite (INUBIT) wieder hergestellt.

Über diese Verbindung können sowohl von der On-Prem Seite (INUBIT) also auch aus der Cloud (IGUASU) Workflows/Flows auf dem jeweils anderen System gestartet werden.

Maximale Sicherheit durch die verwendung von mTLS

Die Verbindung ist notwendigerweise immer durch mTLS/SSL gesichert. Das bedeutet, dass beide Seiten (IGUASU und INUBIT) über Zertifikate ihre Identität beweisen und die Verbindung über SSL gesichert ist.

Die notwendigen Zertifikate werden dabei von IGUASU generiert. Für INUBIT werden sie dann heruntergeladen und an der Verbindung konfiguriert. In IGUASU müssen sie nur noch konfiguriert werden, da der notwendige Teil nach der Generierung schon vorhanden ist.

Beispielhafte Anwendungsfälle

Wie oben beschrieben, können nach der Verbindung der Systeme von beiden Seiten aus Prozesse des anderen Systems gestartet werden. Mögliche Szenarien, die damit abbildbar wären, sind:

INUBIT → IGUASU

Aus einem lokalen Workflow in INUBIT soll ein spezifisches System in der Cloud aufgerufen werden, für welches IGUASU eine einfache Anbindung bereitstellt
- Das Schreiben einer Nachricht in ein AWS-System wie S3 oder Kinesis
- Kommunikation mit einem Kafka-System - also Beispielsweise das Schreiben auf ein Kafka-Topic und das Empfangen der Nachrichten eines anderen Topics, welche dann zu Aufrufen von INBUIT Workflows führen
Teile der Prozesse, die bisher mit INUBIT umgesetzt sind, sollen dynamisiert werden sodass sie hohe Lastspitzen über skalierende Flows in der Cloud abbilden
- Das könnte für Teile gelten, die grundsätzlich besonders hohe Last erzeugen
- Aber auch für Bereiche die nur zu bestimmten Zeiten eine hohe Anforderung an die Last stellen - wie z.B. Shops an Weihnachen oder das Versenden von Benachrichtrigungen zu bestimmten Zeiten

IGUASU → INUBIT

Aus einem Flow in der Cloud soll für einen Kunden die Adresse erfragt werden, wobei die Kundendaten On-Prem gehalten werden
- Es kann ganz gezielt der einzelne Datensatz erfragt werden. Die Datenbank selbst muss dafür nicht im Internet stehen, sondern es wird über den Weg der beiden sicher verbundenen Integrations-Produkte nur das eine Datum übertragen
Ein interner Service, der keinesfalls allgemein im Internet stehen soll, wird in einem Cloud-Flow benötigt
Es soll auf das interne SAP oder eine AS/400 zugegriffen werden

Inhalt dieses Tutorials

Um das Zusammenspiel einer lokalen INUBIT Installation und IGUASU in der Cloud zu veranschaulichen, wird Ihnen in diesem Tutorial gezeigt, wie die Verbindung zwischen beiden Komponenten hergestellt werden kann.

Mit diesem Tutorial werden Sie lernen, wie Sie die benötigten Zertifikate in IGUASU erstellen können und wie diese für die sichere Kommunikation der Anwendungen genutzt werden. Zudem wird Ihnen veranschaulicht, wie die INUBIT-spezifischen Prozessoren in IGUASU eingestellt werden können, sodass sowohl Nachrichten vom INUBIT empfangen als auch Daten zurück an die On-premises Installation gesendet werden können.

Der finale Flow der beiden Kommunikationsmöglichkeiten ist in der folgenden Abbildung ersichtlich.

Teil 1: Erstellung der benötigten Zertifikate und Schlüssel

Um eine sichere Verbindung zwischen beiden Komponenten zu ermöglichen, müssen zunächst die entsprechenden Zertifikate und Keys generiert werden. Um diesen Prozess zu unterstützen, bietet IGUASU einen integrierten Zertifikatsmanager, in der die Generierung der benötigten Elemente vereinfacht möglich ist.

Zum Aufruf des Zertifikatsmanagers muss das globale Menü geöffnet und zu den Einstellungen im Menü navigiert werden. Im Menü auf der linken Seite befindet sich nun der Unterpunkt Certificates, mit dem der Manager aufgerufen werden kann

Zur Einsicht des Zertifikatsmanagers werden die entsprechenden Nutzerberechtigungen in IGUASU benötigt. Sollten Sie den Zertifikatsmanager in den Einstellungen nicht sehen können, wenden Sie sich bitte an Ihren Administrator.

Im Zertifikatsmanager können nun alle bereits vorhandenen Zertifikate und Keystores in einer tabellarischen Auflistung gesehen werden. Im Rahmen dieses Tutorials soll ein Keystore und ein Zertifikat generiert werden, mit dem die Kommunikation zwischen dem IGUASU und der lokalen INUBIT-Installation erfolgen kann. Für diesen Zweck kann der Add Keystore-Button genutzt werden, über den die Option Generate Private Key/Certificate ausgewählt werden soll, um einen neuen Key und Zertifikat zu generieren.

Im Anschluss öffnet sich ein neues Fenster, in dem der Name der Domäne angegeben werden muss (ohne das Protokoll oder dem Port) und optional ein Passwort für die Keys, die im Anschluss erstellt werden.

Danach ist der neu erstellte Keystore sichtbar, über den die entsprechenden Schlüssel heruntergeladen werden können. Zum Download des Private Keys und des Public Keys/Zertifikats kann der Schlüssel-Button verwenden werden, über den beide Optionen zur Verfügung stehen.

Das Passwort, das im ersten Fenster definiert wird, ist für die generierten Keys, nicht aber für den Keystore. Dieser wird im zweiten Fenster innerhalb des Keystores definiert und wird zudem nicht auf dem Server gespeichert. Daher sollten Sie darauf achten, diesen sicher aufzubewahren, wenn Sie den Keystore erneut öffnen möchten. Während das erste Key-Passwort optional ist, ist der Keystore Passwort im zweiten Fenster wichtig, um die Keys und Zertifikate sicher aufzubewahren.

Beide angelegten Elemente werden bei der Konfiguration der Services in IGUASU und den Konnektoren in INUBIT benötigt, was in den folgenden Abschnitten des Tutorials genauer beschrieben wird.

Teil 2: Konfiguration der Websockets und SSL Services

Nachdem der Private und Public Key bzw. das Zertifikat erstellt wurden, können die Services konfiguriert werden, die für die Verwendung der INUBIT-Prozessoren benötigt werden. Zunächst wird der StandardRestrictedSSLContextService benötigt, in dem die Keystore Informationen abgerufen werden, um eine sichere Kommunikation zwischen den Komponenten zu ermöglichen.

Zur Konfiguration des Keystores muss zunächst der Pfad angegeben werden, in dem dieser gespeichert ist. Um diesen Schritt zu vereinfachen, kann die Expression Language genutzt werden, um nicht den ganzen Pfad angeben zu müssen. Durch den Aufruf ${IGUASU_KEYSTORES_PATH} wird der hinterlegte Keystore Pfad aufgerufen, sodass nur noch der Name des Keystores in dem entsprechenden Ordner ausgewählt werden muss. Der Eintrag sollte an dieser Stelle daher wie folgt aussehen: ${IGUASU_KEYSTORES_PATH}/<Name des Keystores>.

Zudem wird das definierte Keystore Passwort, welches zuvor im Fenster des Keystores definiert wurde, benötigt, um die entsprechenden Keys aufzurufen. Falls zuvor zudem ein Key Passwort, also das optionale Passwort welches am Anfang der Erstellung eines Keystores erfragt wird, hinterlegt wurde, müsste dieser ebenfalls in dem Service hinterlegt werden. Zudem kann der Keystore Typ im Service ebenfalls hinterlegt. Da der Keystore allerdings in IGUASU erstellt wurde, kann der Standard-Typ PKCS12 unverändert bleiben.

Nach der Erstellung des SSL-Context-Services wird zudem der HybridWebSocketServerController benötigt, um die Websocket-Verbindung zwischen den beiden Systemen zu realisieren. Die Konfiguration ist allerdings vergleichsweise eher unkompliziert, da lediglich der Listening Port und ein SSL Context Service benötigt werden. Als SSL Context Service kann der zuvor erstellte Service im Dropdown-Menü ausgewählt werden. Als Listening Port wird hingegen der Port benötigt, der zuvor vom Administrator für die Kommunikation von IGUASU mit dem INUBIT-System freigegeben wurde. Im Rahmen dieses Tutorials ist das Port 9001, dieser kann allerdings bei Ihnen ein anderer sein.

Mit diesen Angaben sollte der konfigurierte Service wie folgt aussehen:

Es ist nur für IGUASU notwendig, einen Port freizugeben. Für das INUBIT System ist dieser Schritt nicht erforderlich.

Mit der Erstellung beider Services können im Anschluss die benötigten Prozessoren abschließend konfiguriert werden, die für die Kommunikation mit INUBIT benötigt werden.

Teil 3: Kommunikation INUBIT → IGUASU

In diesem Abschnitt wird erläutert, wie Nachrichten vom INUBIT an das IGUASU in der Cloud versendet werden können.

3.1 Empfangen der Daten mit dem ListenInubit-Prozessor

Um eine Kommunikation zwischen den beiden Systemen zu ermöglichen, müssen zunächst die entsprechenden Elemente in IGUASU erstellt werden, um die Daten empfangen und antworten zu können. Das Empfangen der Daten von einem INUBIT-System läuft hierbei über den ListenInubit-Prozessor, der als Startpunkt des Flows in IGUASU dienen wird.

Zur Konfiguration des Prozessors stehen vier Properties zur Verfügung. Als erste Einstellungsmöglichkeit muss hierbei der Listener Identifier definiert werden, der zum Differenzieren und Identifizieren der Listener genutzt werden kann.

Zusätzlich muss ein Listener Controller festgelegt werden. Für diese Einstellungsmöglichkeit wird der zuvor erstellte HybridWebsocketServerController-Service verwendet, über den unter anderem die Port-Konfiguration erfolgt ist.

Des Weiteren muss ein Name für den Prozessor angegeben werden, der ebenfalls für die Identifizierung des Flows genutzt wird. Der Eintrag der an dieser Stelle definiert wird, ist im späteren Verlauf bei der Konfiguration des IGUASU-Konnektors in INUBIT sichtbar und ermöglicht es dadurch, den richtigen Einstiegspunkt in der Cloud zu finden.

Zusätzlich muss eine Beschreibung hinterlegt werden, der ebenfalls in INUBIT sichtbar ist und dadurch zusätzlich das Finden des richtigen Listeners im anderen System vereinfacht.

Mit der abgeschlossenen Konfiguration sollte der Prozessor wie folgt aussehen:

3.2 Verarbeitung der Daten und der RespondInubit-Prozessor

Nachdem die Daten durch den ListenInubit-Prozessor in IGUASU empfangen werden können, kann die Verarbeitung erfolgen. An dieser Stelle wäre es möglich, einen komplexen Flow zu erstellen, externe Services vereinfacht zu integrieren und verschiedene Zweige der Verarbeitung zu erstellen. Um es allerdings im Rahmen dieses Tutorials simpel zu halten, da der Fokus vermehrt auf der Kommunikation der beiden Systeme liegt, soll nur ein einfacher Verarbeitungsschritt erfolgen.

Für diesen Zweck wird der ReplaceText-Prozessor verwendet, mit dem der FlowFile Inhalt geändert werden soll. Hierbei soll der Inhalt vollständig geändert werden, weswegen die Replacement Strategy Always Replace genutzt werden soll. Als Replacement Value kann ein beliebiger Text stehen, da es an dieser Stelle nur dazu dient in INUBIT die Veränderung durch IGUASU kenntlich zu machen. In diesem Beispiel wurde The IGUASU Response at mit der aktuellen Uhrzeit eingetragen. Eine mögliche Konfiguration kann der folgenden Abbildung entnommen werden.

Um am Ende der Verarbeitung die Daten erneut an INUBIT zu versenden bzw. um generell eine Response zu erzeugen, wird der RespondInubit-Prozessor verwendet. Die Konfiguration ist bei diesem Prozessor allerdings vergleichbar sehr simpel, da nur ein Listener Controller definiert werden muss. Ähnlich wie beim ListenInubit-Prozessor an dieser Stelle der HybridWebsocketServerController-Service verwendet.

Damit ist der Flow in IGUASU zum Empfangen und verarbeiten der Daten aus INUBIT bereits abgeschlossen.

3.3 Konfiguration der IGUASU Konnektoren in INUBIT

Um Nachrichten von einer lokalen INUBIT-Installation an IGUASU in der Cloud zu senden, muss in INUBIT zunächst ein Workflow angelegt werden. Um die Kommunikation zwischen den beiden Systemen zu vereinfachen, bietet INUBIT für diesen Zweck den IGUASU-Konnektor an, mit dem die Verbindung über Websockets aufgebaut werden kann.

Zur Konfiguration des IGUASU-Konnektors in INUBIT wird zum einen die URL benötigt, über den IGUASU erreichbar ist, und das entsprechende Zertifikat sowie der Key, die in Abschnitt 1 erstellt wurden. Eine umfangreiche Beschreibung der Konfiguration dieser Elemente finden Sie in der INUBIT Dokumentation im Abschnitt IGUASU-Konnektoren.

Sollte Ihnen bei der Konfiguration des Konnektors kein IGUASU Listener angezeigt werden, achten Sie darauf, dass der Zustand des Prozessors auf Running gesetzt sein muss, damit dieser aufrufbar ist.

Nachdem nun ebenfalls die Konfigurationen in INUBIT abgeschlossen sind, kann der Workflow gestartet werden, wodurch Daten in INUBIT generiert werden. Im Anschluss sollten diese Informationen in IGUASU durch den ListenInubit-Prozessor empfangen werden, die im Anschluss als FlowFile sichtbar sind. Nach der Veränderung des Inhalts durch den ReplaceText-Prozessor gelangen die Daten im Anschluss erneut zurück an INUBIT, wo diese mit dem neuen Text und den zusätzlichen Metadaten, die in Form von Attributen in IGUASU hinzugefügt wurden, dargestellt werden.

Am Ende des angelegten Flows sollten die Daten in IGUASU wie in der folgenden Abbildung aussehen.

Teil 4: Kommunikation IGUASU > INUBIT

Während es im dritten Teil dieses Tutorials um die Kommunikation ging, die durch INUBIT gestartet wird und bei der eine Response durch IGUASU zurückgesendet wurde, ist es ebenfalls möglich, einen Workflow durch IGUASU zu initiieren.

4.1 IGUASU-Konnektor als Listener

Um Prozesse abzubilden, in denen das IGUASU einen INUBIT Workflow aufruft, bietet das System ebenfalls einen individuellen Prozessor an. Um diese Daten aus IGUASU allerdings zu empfangen, muss zunächst ein IGUASU Konnektor in INUBIT erstellt werden, an den die in IGUASU generierten Daten gesendet werden können. Ähnlich wie zuvor finden Sie alle Informationen zur Konfiguration in INUBIT im Abschnitt IGUASU-Konnektoren.

4.2 Daten übertragen mit dem InvokeInubit-Prozessor

Nachdem die Konfiguration in INUBIT abgeschlossen ist und ein Listener zur Verfügung steht, an den Daten übertragen werden können, kann die Konfiguration in IGUASU erfolgen. Zum Senden von Anfragen vom IGUASU and INUBIT kann der InvokeInubit-Prozessor genutzt werden. Um das im Rahmen dieses Tutorials zu demonstrieren, müssen zunächst Daten in IGUASU generiert werden, die an das INUBIT System übertragen werden können.

Zur Erstellung eines einfachen FlowFiles kann wie in anderen Tutorials bereits der GenerateFlowFile-Prozessor verwendet werden. Um die Übertragung der Daten im vollen Umfang abzubilden, soll hierbei ein eindeutiger Inhalt und ein Attribut für das entsprechende FlowFile erstellt werden. Daher wird zum einen die Option Custom Text konfiguriert, in der beispielsweise der folgende Text eingefügt werden kann: This is the text from IGUASU at ${now()}. Zudem kann ein Attribut festgelegt werden, die als Metadaten ebenfalls an INUBIT übertragen werden und im System im Anschluss als Variable zur Verfügung stehen. Für diesen Zweck kann eine dynamische Property verwendet werden, um ein Attribut zu erstellen. Als Attribut eignet sich beispielsweise die eindeutige ID des FlowFiles, sodass Value with UUID: ${UUID()} eingetragen werden kann.

Die vollständige Konfiguration des GenerateFlowfile-Prozessors sieht im Anschluss wie folgt aus:

Anschließend kann der InvokeInubit-Prozessor erstellt werden, mit dem diese generierten Daten an INUBIT übertragen werden können. Zur Konfiguration muss zunächst erneut ein Listener Controller definiert werden, für den erneut der zuvor erstellte HybridWebSocketServerController genutzt wird. Als Nächstes muss die Choose Listener Option konfiguriert werden, wobei zwei unterschiedliche Optionen zur Verfügung stehen. Zum einen kann die Möglichkeit Use 'Listener Identifier' field verwendet werden, um die ID des Listeners in INUBIT festzulegen, an die das FLowFile übertragen werden soll. Wenn allerdings bereits eine Verbindung zwischen den beiden Systemen besteht, sollten alle Listener im DropDown-Menü des Listener Identifiers zur Verfügung stehen, wo Sie den zuvor erstellten Listener auswählen können.

Wenn Ihnen diese Auswahl der Listener nicht zur Verfügung stehen, empfiehlt es sich zunächst Teil 3 dieses Tutorials abzuschließen, wodurch eine Verbindung zwischen beiden Systemen aufgebaut wird. Im Anschluss sollte Ihnen der zuvor erstellte Listener in der Auswahl zur Verfügung stehen.

Zudem können Sie optional die Einstellung Target unavailable konfigurieren, wodurch das Verhalten bei Verbindungsproblemen definiert werden kann. Hierbei bietet sich die Option Route in "unavailable" Relation an, durch die ein Zweig mit weiteren Verarbeitungsschritten definiert werden können. Im Rahmen dieses Tutorials soll an dieser Stelle nur ein Funnel eingefügt werden, der als Endpunkt dienen soll.

Der finale Workflow sieht im Anschluss wie folgt aus:

Wenn der GenerateFlowFile-Prozessor nun mit Run Once ausgeführt wird, werden die definierten Daten generiert und im Anschluss an den erstellten Listener in INUBIT versandt.