Table des matières

• Introduction
• Exigences minimales
• Pour commencer
• Nous contacter

Introduction

Emissary est un moteur de workflow piloté par les données basé sur le P2P qui s'exécute dans un réseau P2P hétérogène, potentiellement largement dispersé et multi-niveaux de ressources de calcul. Les itinéraires de workflow ne sont pas pré-planifiés comme dans les moteurs de workflow conventionnels, mais sont découverts à mesure que plus d'informations sont découvertes sur les données. Il n'y a généralement aucune interaction utilisateur dans un workflow Emissary ; plutôt, les données sont traitées de manière orientée vers un objectif jusqu'à ce qu'elles atteignent un état de complétion.

Emissary est hautement configurable, mais dans cette implémentation de base il ne fait presque rien. Les utilisateurs de ce framework sont censés fournir des classes qui étendent emissary.place.ServiceProviderPlace pour effectuer du travail sur les charges utiles emissary.core.IBaseDataObject.

Une variété de choses peut être faite et le workflow est géré par étapes, par ex. STUDY, ID, COORDINATE, TRANSFORM, ANALYZE, IO, REVIEW.

Les classes responsables de la direction du workflow sont le emissary.core.MobileAgent et les classes qui en dérivent, qui gèrent le chemin d'un ensemble d'objets de charge utile liés à travers le workflow et le emissary.directory.DirectoryPlace qui gère les services disponibles, leur coût et leur qualité et maintient le réseau P2P connecté.

Site Maven et Javadoc hébergés sur GitHub Pages : https://code.nsa.gov/emissary/

Exigences minimales

• Système d'exploitation Linux ou MacOSX
• JDK 11
• Apache Maven 3.6.3+

Pour commencer

Lisez le guide DEVELOPING.md pour des informations sur l'installation des composants requis, l'extraction du code source, la compilation et l'exécution d'Emissary.

Compilation

Exécutez mvn clean package pour compiler, tester et empaqueter Emissary

Exécution

Il y a un script bash dans Emissary qui exécute tout. Il se trouve dans le répertoire Emissary de niveau supérieur. Le script exécute la classe emissary.Emissary qui dispose de plusieurs commandes Picocli disponibles pour gérer différentes fonctions.

Sans arguments

Si le script emissary est exécuté sans aucun argument, vous obtiendrez une liste de toutes les sous-commandes de configuration et une brève description.

Aide

Exécuter ./emissary help vous donnera la même sortie que l'exécution sans arguments. Si vous voulez voir des informations plus détaillées sur une commande, ajoutez le nom de la commande après help. Par exemple, pour voir tous les arguments avec descriptions pour la commande server, exécutez :

Paramètres courants

Le reste des commandes ont toutes des arguments (-b ou --projectBase) qui peuvent être définis, mais ils doivent correspondre à PROJECT_BASE.

Le répertoire de configuration est par défaut /config mais peut également être passé avec (-c ou --config). Lors de l'exécution depuis le checkout git, vous devez utiliser target comme projectBase. N'hésitez pas à modifier les fichiers de configuration dans target/config avant de commencer.

La journalisation est gérée par logback. Vous pouvez pointer vers un fichier personnalisé avec l'argument --logbackConfig.

Voir le help -c pour chaque commande pour obtenir plus d'informations.

Serveur (Autonome)

Cette commande démarrera un serveur Emissary et initialisera tous les places, un place de ramassage, et les filtres de dépôt qui sont configurés. Il démarrera en mode autonome si -m ou --mode n'est pas spécifié. Par défaut, le nombre de MobileAgents est calculé en fonction des spécifications de la machine. Sur les ordinateurs modernes, cela peut être élevé. Vous pouvez contrôler le nombre d'agents avec -a ou --agents. Voici un exemple d'exécution.

Sans configuration supplémentaire, il démarrera sur http://localhost:8001. Si vous naviguez vers cette url, vous devrez saisir le nom d'utilisateur et le mot de passe définis dans target/config/jetty-users.properties, qui sont emissary et emissary123.

Le PickUpPlace par défaut est configuré pour lire les fichiers depuis target/data/InputData. Si vous copiez des fichiers dans ce répertoire, vous verrez Emissary les traiter. Gardez à l'esprit que seuls toUpper et toLower sont configurés, donc la sortie ne sera pas très intéressante.

Pause

Arrêter le service de prendre du travail

Reprise

Permettre à un service en pause de prendre du travail

Invalidation

Invalider les services qui sont actualisables. C'est une actualisation "légère" qui est une approche sans temps d'arrêt qui invalide un ServiceProviderRefreshablePlace. Lorsque le place est ensuite retiré de DirectoryPlace, le place est recréé en utilisant les mêmes clés pour DirectoryPlace et Namespace, mais le configurateur est rechargé et le place est capable de recharger un sous-ensemble de ses configurations.

Actualisation

Forcer l'actualisation des services. C'est une actualisation "dure", le serveur est mis en pause et il y a une attente pour que les MobileAgents se vident. Une fois que le serveur est complètement inactif, toutes les clés existantes de ServiceProviderRefreshablePlace sont supprimées de DirectoryPlace et Namespace, et les places sont entièrement recréés. Cela permet des changements de noms de services, de proxys, de listes de refus, etc. Le serveur est ensuite repris pour reprendre le traitement. Toute défaillance lors de l'actualisation mettrait le serveur dans un mauvais état, donc le serveur est arrêté.

Arrêt

Arrêter le service

Kill

Forcer l'arrêt du service

Agents (Autonome)

La commande agents affiche le nombre de MobileAgents pour l'hôte configuré et ce que ces agents font. Par défaut, le port est 9001, mais vous pouvez utiliser -p ou --port pour le changer. En supposant que vous exécutez sur 8001 avec la commande server ci-dessus, essayez :

Pool (Autonome)

Pool est une vue réduite des agents pour un nœud. Il utilise également par défaut le port 9001. Pour l'exécuter pour le serveur autonome démarré ci-dessus, exécutez

Cette commande est plus utile pour un cluster car elle offre une vue plus digeste de chaque nœud.

Env

La commande Env nécessite qu'un serveur soit en cours d'exécution. Elle demandera au serveur certaines valeurs de configuration, comme PROJECT_BASE et BIN_DIR. Sans arguments, elle videra une réponse json non formatée.

Mais vous pouvez également vider une réponse adaptée pour être sourcée dans bash.

Le démarrage du serveur Emissary appelle en fait ce point de terminaison et vide $PROJECT_BASE}/env.sh avec les variables configurées. Cela est fait pour que les scripts shell puissent source $PROJECT_BASE}/env.sh et ensuite avoir ces variables disponibles sans avoir à se soucier de les configurer ailleurs.

Config

La commande config vous permet de voir la configuration effective pour un place/service/classe spécifié. Puisqu'Emissary utilise des flavors, cette commande affichera la configuration résultante d'une classe après que tous les flavors aient été appliqués. Cette commande peut être utilisée pour se connecter à un nœud Emissary en cours d'exécution en spécifiant -h pour l'hôte (par défaut localhost) et -p pour le port (par défaut 8001). Pour se connecter à un Emissary local en cours d'exécution sur le port 8001, l'une des commandes suivantes fonctionnera :

Optionnellement, vous pouvez spécifier le mode hors ligne en utilisant --offline pour utiliser les fichiers de configuration spécifiés dans votre CONFIG_DIR local :

En mode hors ligne, vous pouvez fournir des flavors pour voir les différences dans les configurations :

Ceux-ci sont utiles pour voir la configuration effective, mais nous pouvons également exécuter en mode verbeux pour voir tous les fichiers de configuration ainsi que la sortie finale. Cela est contrôlé avec le drapeau --detailed :

ou en mode hors ligne :

Serveur (Cluster)

Emissary est amusant en autonome, mais l'exécution en cluster est plus appropriée pour un travail réel. La façon d'exécuter en cluster est similaire à l'autonome, mais vous devez utiliser -m cluster pour dire au nœud de se connecter à d'autres nœuds. En mode cluster, Emissary démarrera également le PickUpClient au lieu du PickUpPlace, donc vous devrez démarrer un feeder.

Regardez le fichier target/config/peers.cfg pour voir les pairs de rendez-vous. Dans ce cas, il y en a 3. Les nœuds exécutés sur les ports 8001 et 9001 sont juste des nœuds Emissary. Le nœud exécuté sur 7001 est le feeder. Donc démarrons 8001 et 9001 dans deux terminaux différents.

Parce que ces nœuds connaissent tous les ports 8001, 9001 et 7001, vous verrez des erreurs dans les journaux alors qu'ils continuent d'essayer de se connecter.

Notez que dans les déploiements du monde réel, nous n'exécutons pas plusieurs processus Emissary sur le même nœud. Vous pouvez configurer le nom d'hôte avec -h.

Feed (Cluster)

Avec les nœuds démarrés sur les ports 8001 et 9001, nous devons démarrer le feeder. La commande feed utilise le port 7001 par défaut, mais nous devons configurer un répertoire que le feeder lira. Les fichiers déposés dans ce répertoire seront disponibles pour que les nœuds de travail les prennent et le travail devrait être distribué parmi le cluster. Démarrez le feed avec

Vous devriez pouvoir accéder à http://localhost:8001, http://localhost:9001 et http://localhost:7001 dans le navigateur et regarder les places configurés. Déposez quelques fichiers dans ~/Desktop/feed1 et voyez les 2 nœuds les traiter. Cela peut prendre une minute pour qu'ils commencent à traiter.

Agents (Cluster)

Les agents en mode cluster affichent à nouveau des détails sur les mobileAgents. Cela commence par le nœud que vous configurez (localhost:9001 par défaut), puis appelle tous les nœuds qu'il connaît et obtient la même information. Exécutez-le avec :

Pool (Cluster)

Pool en mode cluster fait également la même chose que pool en autonome. Il commence au nœud (localhost:9001) par défaut puis va vers tous les nœuds qu'il connaît et agrège une vue réduite du cluster. Exécutez-le avec

Topologie (Cluster)

La topologie parle au nœud configuré (localhost:8001 par défaut) et parle à chaque nœud qu'il connaît. La réponse est ce que tous ces nœuds connaissent, donc vous pouvez construire une topologie réseau de votre cluster. Exécutez-le avec

Exécution du serveur avec SSL

Le keystore et le mot de passe du keystore sont dans le fichier emissary.client.EmissaryClient-SSL.cfg. Inclus et configuré par défaut est un keystore d'exemple que vous pouvez utiliser pour tester cette fonctionnalité. Nous ne recommandons pas d'utiliser le keystore d'exemple dans les environnements de production. Pour utiliser votre propre keystore, modifiez les valeurs de configuration dans le fichier emissary.client.EmissaryClient-SSL.cfg.

Autonome

Cluster

Nous contacter

Questions générales

Si vous avez des questions ou des préoccupations concernant ce projet, vous pouvez nous contacter à : [email protected]

Questions de sécurité

Pour les questions de sécurité et le signalement de vulnérabilités, veuillez vous référer à SECURITY.md