emissary
8.17.0
Einführung
Mindestanforderungen
Erste Schritte
Kontaktieren Sie uns
Emissary ist eine P2P-basierte datengesteuerte Workflow-Engine, die in einem heterogenen, möglicherweise weit verstreuten, mehrstufigen P2P-Netzwerk von Rechenressourcen läuft. Workflow-Abläufe sind nicht wie in herkömmlichen Workflow-Engines vorgeplant, sondern werden entdeckt, wenn mehr Informationen über die Daten ermittelt werden. In einem Emissary-Workflow findet normalerweise keine Benutzerinteraktion statt, vielmehr werden die Daten zielorientiert verarbeitet, bis sie einen Abschlussstatus erreichen.
Emissary ist hochgradig konfigurierbar, macht aber in dieser Basisimplementierung fast nichts. Von Benutzern dieses Frameworks wird erwartet, dass sie Klassen bereitstellen, die emissary.place.ServiceProviderPlace erweitern, um Arbeiten an emissary.core.IBaseDataObject-Nutzdaten auszuführen.
Es können verschiedene Dinge erledigt werden und der Arbeitsablauf wird in Phasen verwaltet, z. B. STUDIEREN, ID, KOORDINIEREN, TRANSFORMIEREN, ANALYSE, IO, ÜBERPRÜFEN.
Die für die Steuerung des Workflows verantwortlichen Klassen sind emissary.core.MobileAgent und davon abgeleitete Klassen, die den Pfad einer Reihe verwandter Nutzlastobjekte durch den Workflow verwalten, und emissary.directory.DirectoryPlace, das die verfügbaren Dienste, deren Kosten und verwaltet Qualität und halten Sie das P2P-Netzwerk verbunden.
Linux- oder MacOSX-Betriebssystem
JDK 11
Apache Maven 3.5+
Lesen Sie den DEVELOPING.md-Leitfaden durch, um Informationen zum Installieren erforderlicher Komponenten, zum Abrufen des Quellcodes sowie zum Erstellen und Ausführen von Emissary zu erhalten.
Führen Sie mvn clean package aus, um Emissary zu kompilieren, zu testen und zu verpacken
[INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 9.132 s [INFO] Finished at: 2022-01-10T22:31:05Z [INFO] ------------------------------------------------------------------------
Es gibt ein Bash-Skript in Emissary, das alles ausführt. Es befindet sich im Emissary-Verzeichnis der obersten Ebene. Das Skript führt die Klasse emissary.Emissary aus, die über mehrere Picocli-Befehle zur Verarbeitung verschiedener Funktionen verfügt.
Wenn das Emissary -Skript ohne Argumente ausgeführt wird, erhalten Sie eine Auflistung aller Konfigurationsunterbefehle und eine kurze Beschreibung.
./emissary
Wenn Sie ./emissary help ausführen, erhalten Sie die gleiche Ausgabe wie beim Ausführen ohne Argumente. Wenn Sie detailliertere Informationen zu einem Befehl sehen möchten, fügen Sie nach Hilfe den Befehlsnamen hinzu. Sehen Sie sich beispielsweise alle Argumente mit Beschreibungen für den Serverbefehl an und führen Sie Folgendes aus:
./emissary help server
Die übrigen Befehle haben alle Argumente (-b oder --projectBase) , die festgelegt werden können, aber sie müssen mit PROJECT_BASE übereinstimmen.
Das Konfigurationsverzeichnis ist standardmäßig /config, kann aber auch mit (-c oder --config) übergeben werden. Wenn Sie vom Git-Checkout aus ausführen, sollten Sie target als projectBase verwenden. Fühlen Sie sich frei, die Konfigurationsdateien in target/config zu ändern, bevor Sie beginnen.
Die Protokollierung erfolgt durch Logback. Sie können mit dem Argument --logbackConfig auf eine benutzerdefinierte Datei verweisen.
Weitere Informationen finden Sie in der Hilfe -c für jeden Befehl.
Dieser Befehl startet einen Emissary-Server und initialisiert alle konfigurierten Orte, einen Abholort und Abgabefilter. Es startet im Standalone-Modus, wenn -m oder --mode nicht angegeben ist. Standardmäßig wird die Anzahl der MobileAgents basierend auf den Spezifikationen der Maschine berechnet. Auf modernen Computern kann dieser hoch sein. Sie können die Anzahl der Agenten mit -a oder --agents steuern. Hier ist ein Beispiellauf.
./emissary server -a 2
Ohne weitere Konfiguration startet es auf http://localhost:8001. Wenn Sie zu dieser URL navigieren, müssen Sie den in target/config/jetty-users.properties definierten Benutzernamen und das Passwort eingeben, nämlich emissary und emissary123.
Der standardmäßige PickUpPlace ist so konfiguriert, dass er Dateien aus target/data/InputData liest. Wenn Sie Dateien in dieses Verzeichnis kopieren, werden Sie sehen, wie Emissary sie verarbeitet. Beachten Sie, dass nur toUpper und toLower konfiguriert sind, sodass die Ausgabe nicht allzu interessant ist.
Der Befehl „agents“ zeigt die Anzahl der MobileAgents für den konfigurierten Host und was diese Agents tun. Standardmäßig ist der Port 9001, aber Sie können dies mit -p oder --port ändern.
Angenommen, Sie verwenden den obigen Serverbefehl auf 8001, versuchen Sie Folgendes:
./emissary agents -p 8001
Der Pool ist eine reduzierte Ansicht der Agenten für einen Knoten. Auch er ist standardmäßig auf Port 9001 eingestellt. Um ihn für den oben gestarteten Standalone-Server auszuführen, führen Sie ihn aus
./emissary pool -p 8001
Dieser Befehl ist für einen Cluster nützlicher, da er eine übersichtlichere Ansicht jedes Knotens bietet.
Für den Env-Befehl muss ein Server ausgeführt werden. Der Server wird nach einigen Konfigurationswerten gefragt, z. B. PROJECT_BASE und BIN_DIR. Ohne Argumente wird eine unformatierte JSON-Antwort ausgegeben.
./emissary env
Sie können aber auch eine für die Beschaffung geeignete Antwort in Bash ausgeben.
./emissary env --bashable
Beim Starten des Emissary-Servers wird dieser Endpunkt tatsächlich aufgerufen und $PROJECT_BASE}/env.sh mit den konfigurierten Variablen ausgegeben. Dies geschieht, damit Shell-Skripte source $PROJECT_BASE}/env.sh können und diese Variablen dann verfügbar haben, ohne sich um die Konfiguration an anderer Stelle kümmern zu müssen.
Mit dem Befehl config können Sie die effektive Konfiguration für einen bestimmten Ort/Dienst/eine bestimmte Klasse anzeigen. Da Emissary Flavors verwendet, zeigt dieser Befehl die resultierende Konfiguration einer Klasse an, nachdem alle Flavors angewendet wurden. Dieser Befehl kann verwendet werden, um eine Verbindung zu einem laufenden Emissary-Knoten herzustellen, indem -h für Host (Standard ist localhost) und -p für den Port (Standard ist 8001) angegeben wird. Um eine Verbindung zu einem lokal laufenden Emissary auf Port 8001 herzustellen, funktioniert jeder der folgenden Befehle:
./emissary config --place emissary.place.sample.ToLowerPlace ./emissary config --place emissary.place.sample.ToLowerPlace -h localhost -p 8001
Optional können Sie mit --offline den Offline-Modus angeben, um die in Ihrem lokalen CONFIG_DIR angegebenen Konfigurationsdateien zu verwenden:
./emissary config --place emissary.place.sample.ToLowerPlace --offline
Im Offline-Modus können Sie Varianten bereitstellen, um die Unterschiede in den Konfigurationen zu sehen:
./emissary config --place emissary.place.sample.ToLowerPlace --offline --flavor STANDALONE,TESTING
Diese sind nützlich, um die effektive Konfiguration anzuzeigen, wir können sie aber auch im ausführlichen Modus ausführen, um alle Konfigurationsdateien zusammen mit der endgültigen Ausgabe anzuzeigen. Dies wird mit dem Flag --detailed gesteuert:
./emissary config --place emissary.place.sample.ToLowerPlace --detailed
oder im Offline-Modus:
./emissary config --place emissary.place.sample.ToLowerPlace --offline --detailed
Emissary macht im Standalone-Modus Spaß, aber die Ausführung von Cluster ist für echte Arbeit besser geeignet. Die Art und Weise, Clustered auszuführen, ist ähnlich wie bei Standalone, Sie müssen jedoch -m Cluster verwenden, um den Knoten anzuweisen, eine Verbindung zu anderen Knoten herzustellen. Im Cluster-Modus startet Emissary auch den PickUpClient anstelle des PickUpPlace, Sie müssen also einen Feeder starten.
Schauen Sie sich die Datei target/config/peers.cfg an, um die Rendezvous-Peers zu sehen. In diesem Fall gibt es 3. Knoten, die auf den Ports 8001 und 9001 laufen, sind nur Emissary-Knoten. Der Knoten, der auf 7001 läuft, ist der Feeder. Starten wir also 8001 und 9001 in zwei verschiedenen Terminals.
./emissary server -a 2 -m cluster ./emissary server -a 2 -m cluster -p 9001
Da diese Knoten alle die Ports 8001, 9001 und 7001 kennen, werden in den Protokollen Fehler angezeigt, wenn sie weiterhin versuchen, eine Verbindung herzustellen.
Beachten Sie, dass wir in realen Bereitstellungen nicht mehrere Emissary-Prozesse auf demselben Knoten ausführen. Sie können den Hostnamen mit -h konfigurieren.
Da die Knoten auf den Ports 8001 und 9001 gestartet sind, müssen wir den Feeder starten. Der Feed-Befehl verwendet standardmäßig Port 7001, wir müssen jedoch ein Verzeichnis einrichten, aus dem der Feeder liest. In diesem Verzeichnis abgelegte Dateien stehen den Worker-Knoten zur Verfügung und die Arbeit sollte im Cluster verteilt werden. Starten Sie den Feed mit
mkdir ~/Desktop/feed1 ./emissary feed -i ~/Desktop/feed1/
Sie sollten in der Lage sein, im Browser auf http://localhost:8001, http://localhost:9001 und http://localhost:7001 zu klicken und sich die konfigurierten Orte anzusehen. Legen Sie einige Dateien in ~/Desktop/feed1 ab und sehen Sie, wie die beiden Knoten sie verarbeiten. Es kann eine Minute dauern, bis die Verarbeitung beginnt
Agenten im Clustermodus zeigen erneut Details zu den mobilen Agenten an. Es beginnt mit dem von Ihnen konfigurierten Knoten (standardmäßig localhost:9001), ruft dann alle ihm bekannten Knoten auf und erhält die gleichen Informationen. Führen Sie es aus mit:
./emissary agents --cluster
Ein Pool im Cluster-Modus macht dasselbe wie ein Pool im Standalone-Modus. Es beginnt standardmäßig am Knoten (locahost:9001), geht dann zu allen ihm bekannten Knoten und aggregiert eine reduzierte Ansicht des Clusters. Führen Sie es mit aus
./emissary pool --cluster
Die Topologie kommuniziert mit dem konfigurierten Knoten (standardmäßig localhost:8001) und mit jedem ihr bekannten Knoten. Die Antwort ist das, was allen Knoten bekannt ist, sodass Sie eine Netzwerktopologie Ihres Clusters erstellen können. Führen Sie es mit aus
./emissary topology
Der Keystore und das Keystore-Passwort befinden sich in der Datei emissary.client.EmissaryClient-SSL.cfg. Standardmäßig ist ein Beispiel-Keystore enthalten und konfiguriert, den Sie zum Testen dieser Funktionalität verwenden können. Wir empfehlen, den Beispiel-Keystore nicht in Produktionsumgebungen zu verwenden. Um Ihren eigenen Keystore zu verwenden, ändern Sie die Konfigurationswerte in der Datei emissary.client.EmissaryClient-SSL.cfg.
Standalone
./emissary server -p 8443 --ssl --disableSniHostCheck
Geclustert
./emissary server -p 8443 --ssl --disableSniHostCheck --mode cluster ./emissary server -p 9443 --ssl --disableSniHostCheck --mode cluster mkdir ~/Desktop/feed1 ./emissary feed -p 7443 --ssl --disableSniHostCheck -i ~/Desktop/feed1/
Wenn Sie Fragen oder Bedenken zu diesem Projekt haben, können Sie uns unter [email protected] kontaktieren
Informationen zu Sicherheitsfragen und zur Meldung von Schwachstellen finden Sie unter SECURITY.md
