Introdução
Requisitos Mínimos
Começando
Contate-nos
Emissary é um mecanismo de fluxo de trabalho orientado a dados baseado em P2P que é executado em uma rede P2P heterogênea, possivelmente amplamente dispersa, de recursos de computação em várias camadas. Os itinerários de fluxo de trabalho não são pré-planejados como nos mecanismos de fluxo de trabalho convencionais, mas são descobertos à medida que mais informações são descobertas sobre os dados. Normalmente não há interação do usuário em um fluxo de trabalho do Emissary; em vez disso, os dados são processados de maneira orientada a objetivos até atingirem um estado de conclusão.
O Emissary é altamente configurável, mas nesta implementação básica não faz quase nada. Espera-se que os usuários desta estrutura forneçam classes que estendam emissary.place.ServiceProviderPlace para realizar trabalho em cargas úteis de emissary.core.IBaseDataObject.
Uma variedade de coisas pode ser feita e o fluxo de trabalho é gerenciado em etapas, por exemplo, ESTUDAR, IDENTIFICAR, COORDENAR, TRANSFORMAR, ANALISAR, IO, REVISÃO.
As classes responsáveis por direcionar o fluxo de trabalho são emissary.core.MobileAgent e classes derivadas dele, que gerenciam o caminho de um conjunto de objetos de carga útil relacionados através do fluxo de trabalho e o emissary.directory.DirectoryPlace que gerencia os serviços disponíveis, seus custos e qualidade e manter a rede P2P conectada.
Sistema operacional Linux ou MacOSX
JDK 11
ApacheMaven 3.5+
Leia o guia DEVELOPING.md para obter informações sobre como instalar os componentes necessários, extrair o código-fonte, construir e executar o Emissary.
Execute mvn clean package
para compilar, testar e empacotar o Emissary
[INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 9.132 s [INFO] Finished at: 2022-01-10T22:31:05Z [INFO] ------------------------------------------------------------------------
Existe um script bash no Emissary que executa tudo. Está no diretório Emissário de nível superior. O script executa a classe emissary.Emissary que possui vários comandos Picocli disponíveis para lidar com diferentes funções.
Se o script do emissário for executado sem argumentos, você obterá uma lista de todos os subcomandos de configuração e uma breve descrição.
./emissary
A execução de ./emissary help
fornecerá a mesma saída que a execução sem argumentos. Se quiser ver informações mais detalhadas sobre um comando, adicione o nome do comando após a ajuda. Por exemplo, veja todos os argumentos com descrições para o comando do servidor , execute:
./emissary help server
Todos os demais comandos possuem argumentos (-b ou --projectBase) que podem ser definidos, mas devem corresponder a PROJECT_BASE.
O diretório de configuração é padronizado como /config mas também pode ser passado com (-c ou --config) . Ao executar a partir do checkout do git, você deve usar target como projectBase. Sinta-se à vontade para modificar os arquivos de configuração em target/config antes de começar.
O registro é tratado pelo logback. Você pode apontar para um arquivo personalizado com o argumento --logbackConfig .
Veja o help -c de cada comando para obter mais informações.
Este comando irá iniciar um servidor Emissary e inicializar todos os locais, um local de coleta e filtros de entrega que estão configurados. Ele iniciará no modo autônomo se -m ou --mode não for especificado. Por padrão, o número de MobileAgents é calculado com base nas especificações da máquina. Em computadores modernos, isso pode ser alto. Você pode controlar o número de agentes com -a ou --agents . Aqui está um exemplo de execução.
./emissary server -a 2
Sem configuração adicional, ele iniciará em http://localhost:8001. Se você navegar até esse URL, precisará inserir o nome de usuário e a senha definidos em target/config/jetty-users.properties, que é emissary e emissary123.
O PickUpPlace padrão está configurado para ler arquivos de target/data/InputData . Se você copiar os arquivos para esse diretório, verá o Emissary processá-los. Lembre-se de que apenas toUpper e toLower estão configurados, portanto a saída não será muito interessante.
O comando agents mostra o número de MobileAgents para o host configurado e o que esses agentes estão fazendo. Por padrão, a porta é 9001, mas você pode usar -p ou --port para alterar isso.
Supondo que você esteja executando o 8001 a partir do comando do servidor acima, tente:
./emissary agents -p 8001
Pool é uma visualização recolhida dos agentes de um nó. O padrão também é a porta 9001. Para executar no servidor independente iniciado acima, execute
./emissary pool -p 8001
Este comando é mais útil para um cluster, pois oferece uma visão mais compreensível de cada nó.
O comando Env requer que um servidor esteja em execução. Ele solicitará ao servidor alguns valores de configuração, como PROJECT_BASE e BIN_DIR. Sem argumentos, ele irá despejar uma resposta JSON não formatada.
./emissary env
Mas você também pode descartar uma resposta adequada para fornecimento no bash.
./emissary env --bashable
Iniciar o servidor Emissary realmente chama esse endpoint e despeja $PROJECT_BASE}/env.sh com as variáveis configuradas. Isso é feito para que os scripts shell possam source $PROJECT_BASE}/env.sh
e então ter essas variáveis disponíveis sem ter que se preocupar em configurá-las em outro lugar.
O comando config permite que você veja a configuração efetiva para um local/serviço/classe especificado. Como o Emissary usa variações, este comando mostrará a configuração resultante de uma classe após todas as variações terem sido aplicadas. Este comando pode ser usado para conectar-se a um nó Emissary em execução, especificando -h
para host (o padrão é localhost) e -p
para a porta (o padrão é 8001). Para conectar-se a um Emissary em execução local na porta 8001, qualquer um dos seguintes comandos funcionará:
./emissary config --place emissary.place.sample.ToLowerPlace ./emissary config --place emissary.place.sample.ToLowerPlace -h localhost -p 8001
Opcionalmente, você pode especificar o modo offline usando --offline
para usar os arquivos de configuração especificados em seu CONFIG_DIR local:
./emissary config --place emissary.place.sample.ToLowerPlace --offline
No modo offline, você pode fornecer variações para ver as diferenças nas configurações:
./emissary config --place emissary.place.sample.ToLowerPlace --offline --flavor STANDALONE,TESTING
Eles são úteis para ver a configuração efetiva, mas também podemos executar em modo detalhado para ver todos os arquivos de configuração junto com a saída final. Isso é controlado com o sinalizador --detailed
:
./emissary config --place emissary.place.sample.ToLowerPlace --detailed
ou no modo off-line:
./emissary config --place emissary.place.sample.ToLowerPlace --offline --detailed
O Emissary é divertido sozinho, mas executar o cluster é mais apropriado para o trabalho real. A maneira de executar em cluster é semelhante à autônoma, mas você precisa -m cluster para informar ao nó para se conectar a outros nós. No modo clusterizado, o Emissary também iniciará o PickUpClient em vez do PickUpPlace, portanto, você precisará iniciar um alimentador.
Veja target/config/peers.cfg para ver os peers de encontro. Neste caso, existem 3. Os nós em execução nas portas 8001 e 9001 são apenas nós Emissários. O nó executado em 7001 é o alimentador. Então, vamos iniciar o 8001 e o 9001 em dois terminais diferentes.
./emissary server -a 2 -m cluster ./emissary server -a 2 -m cluster -p 9001
Como todos esses nós conhecem as portas 8001, 9001 e 7001, você verá erros nos logs à medida que eles continuam tentando se conectar.
Observe que em implantações no mundo real não executamos vários processos do Emissary no mesmo nó. Você pode configurar o nome do host com -h .
Com os nós iniciados nas portas 8001 e 9001, precisamos iniciar o alimentador. O comando feed usa a porta 7001 por padrão, mas precisamos configurar um diretório de onde o alimentador fará a leitura. Os arquivos colocados nesse diretório estarão disponíveis para os nós de trabalho e o trabalho deverá ser distribuído entre o cluster. Inicie o feed com
mkdir ~/Desktop/feed1 ./emissary feed -i ~/Desktop/feed1/
Você deve conseguir acessar http://localhost:8001, http://localhost:9001 e http://localhost:7001 no navegador e ver os locais configurados. Solte alguns arquivos em ~/Desktop/feed1 e veja os 2 nós processá-los. Pode levar um minuto para que eles comecem a processar
Agentes no modo clusterizado mostram novamente detalhes sobre os mobileAgents. Ele começa com o nó que você configura (localhost:9001 por padrão), depois chama todos os nós que conhece e obtém as mesmas informações. Execute-o com:
./emissary agents --cluster
O pool no modo clusterizado também faz o mesmo que o pool no modo autônomo. Ele começa no nó (locahost:9001) por padrão e depois vai para todos os nós que conhece e agrega uma visão recolhida do cluster. Execute-o com
./emissary pool --cluster
A topologia se comunica com o nó configurado (localhost:8001 por padrão) e se comunica com todos os nós que conhece. A resposta é o que todos esses nós conhecem, para que você possa construir uma topologia de rede do seu cluster. Execute-o com
./emissary topology
O keystore e a senha do keystore estão no arquivo emissary.client.EmissaryClient-SSL.cfg. Incluído e configurado por padrão está um keystore de amostra que você pode usar para testar essa funcionalidade. Não recomendamos usar o keystore de amostra em ambientes de produção. Para usar seu próprio keystore, altere os valores de configuração no arquivo emissary.client.EmissaryClient-SSL.cfg.
Autônomo
./emissary server -p 8443 --ssl --disableSniHostCheck
Agrupado
./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/
Se você tiver alguma dúvida ou preocupação sobre este projeto, entre em contato conosco em: [email protected]
Para perguntas de segurança e relatórios de vulnerabilidade, consulte SECURITY.md